Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Why Snort Blocks Apple Domain?

    Scheduled Pinned Locked Moved IDS/IPS
    8 Posts 4 Posters 1.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • NollipfSenseN
      NollipfSense
      last edited by

      From what I understand, Apple owns the entire 17.0.0.0 blocks of IP addresses; so, I was surprised when I could not access Apple. When I had checked my log, it was blocked…so, I disable blocking and backed down to IPS policy of connectivity. All IPS policies should have known not to block those...a fair statement? Of course, I am new to Snort and realize it's a false positive.

      pfSense+ 23.09 Lenovo Thinkcentre M93P SFF Quadcore i7 dual Raid-ZFS 128GB-SSD 32GB-RAM PCI-Intel i350-t4 NIC, -Intel QAT 8950.
      pfSense+ 23.09 VM-Proxmox, Dell Precision Xeon-W2155 Nvme 500GB-ZFS 128GB-RAM PCIe-Intel i350-t4, Intel QAT-8950, P-cloud.

      1 Reply Last reply Reply Quote 0
      • bmeeksB
        bmeeks
        last edited by

        @NollipfSense:

        From what I understand, Apple owns the entire 17.0.0.0 blocks of IP addresses; so, I was surprised when I could not access Apple. When I had checked my log, it was blocked…so, I disable blocking and backed down to IPS policy of connectivity. All IPS policies should have known not to block those...a fair statement? Of course, I am new to Snort and realize it's a false positive.

        Which specific rule caused the block to the Apple IP addresses?  You can disable just that specific rule.

        If you are new to Snort or any IDS/IPS, I would suggest you not start with all rules enabled and the strictest policy in place.  You may well be fighting false positive blocks for a while.  Instead, if you want to start with the most secure settings, then do so using IDS mode (no blocking enabled) and watch your logs for at least a week and maybe two to see what types of alerts you are seeing.  From that list you can discern potential false positives and disable those rules.

        Bill

        1 Reply Last reply Reply Quote 0
        • NogBadTheBadN
          NogBadTheBad
          last edited by

          @bmeeks:

          specific rule caused the block to the Apple IP addresses?  You can disable just that specific rule.

          I'm guessing its the HTTP inspection Bill, maybe the OP should disable the blocking and create a base line as you suggest.

          I've disabled the following :-

          HI_CLIENT_DOUBLE_DECODE
          HI_CLIENT_SIMPLE_REQUEST
          HI_CLIENT_UNESCAPED_SPACE_IN_URI
          HI_SERVER_NO_CONTLEN
          HI_CLISRV_MSG_SIZE_EXCEPTION

          Andy

          1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

          1 Reply Last reply Reply Quote 0
          • bmeeksB
            bmeeks
            last edited by

            @NogBadTheBad:

            @bmeeks:

            specific rule caused the block to the Apple IP addresses?  You can disable just that specific rule.

            I'm guessing its the HTTP inspection Bill, maybe the OP should disable the blocking and create a base line as you suggest.

            I've disabled the following :-

            HI_CLIENT_DOUBLE_DECODE
            HI_CLIENT_SIMPLE_REQUEST
            HI_CLIENT_UNESCAPED_SPACE_IN_URI
            HI_SERVER_NO_CONTLEN
            HI_CLISRV_MSG_SIZE_EXCEPTION

            Yeah, HTTP_INSPECT rules would be my guess as well.  Those rules seem to be very problematic these days with the way modern web servers serve up HTTP responses.  Might be time for the Snort VRT folks to revisit the usefulness of those HTTP_INSPECT rules, or else "quiet them down" a bit to reduce false positives.

            Bill

            1 Reply Last reply Reply Quote 0
            • V
              Velcro
              last edited by

              Doesn't AppID rules block iTunes? I got a "potential Policy" violation with some rules when I enabled them. I saw these rules as a way for a system administrator to control whats allowed and whats not.

              I recently turned AppID off for my application as I didn't see them as a "threat" concern but more of a "Policy" concern.

              Could that be the issue?

              1 Reply Last reply Reply Quote 0
              • NollipfSenseN
                NollipfSense
                last edited by

                @bmeeks:

                @NollipfSense:

                From what I understand, Apple owns the entire 17.0.0.0 blocks of IP addresses; so, I was surprised when I could not access Apple. When I had checked my log, it was blocked…so, I disable blocking and backed down to IPS policy of connectivity. All IPS policies should have known not to block those...a fair statement? Of course, I am new to Snort and realize it's a false positive.

                Which specific rule caused the block to the Apple IP addresses?  You can disable just that specific rule.

                If you are new to Snort or any IDS/IPS, I would suggest you not start with all rules enabled and the strictest policy in place.  You may well be fighting false positive blocks for a while.  Instead, if you want to start with the most secure settings, then do so using IDS mode (no blocking enabled) and watch your logs for at least a week and maybe two to see what types of alerts you are seeing.  From that list you can discern potential false positives and disable those rules.

                Bill

                I actually don't know which rule…I had enabled Snort VRT, Snort GPLv2, Snort ET Open, and Snort OpenAppID, plus Block Offenders, with Kill States checked and IP to block set to both. After I had seen what was happening, I reread here:

                https://doc.pfsense.org/index.php/Setup_Snort_Package

                I then turned off blocking and, all is good...so far. I had policy set to connectivity then and still have it now. I still have implemented Barnyard2 yet...giving myself sometime to learn more.

                In the attachment, you'll see, it seems my Apple server saying hello to Apple.

                ![Screen Shot 2017-12-09 at 4.56.01 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2017-12-09 at 4.56.01 PM.png_thumb)
                ![Screen Shot 2017-12-09 at 4.56.01 PM.png](/public/imported_attachments/1/Screen Shot 2017-12-09 at 4.56.01 PM.png)

                pfSense+ 23.09 Lenovo Thinkcentre M93P SFF Quadcore i7 dual Raid-ZFS 128GB-SSD 32GB-RAM PCI-Intel i350-t4 NIC, -Intel QAT 8950.
                pfSense+ 23.09 VM-Proxmox, Dell Precision Xeon-W2155 Nvme 500GB-ZFS 128GB-RAM PCIe-Intel i350-t4, Intel QAT-8950, P-cloud.

                1 Reply Last reply Reply Quote 0
                • NogBadTheBadN
                  NogBadTheBad
                  last edited by

                  Thats HTTP inspection doing that.

                  View the following page on your pfSense router :-

                  Services -> Snort -> Alerts and select the WAN interface and write down the SID number, you get more details about the alert here.

                  Then goto  :-

                  Services -> Snort -> Edit Interface -> WAN -> WAN Rules and select pulldown preprocessor.rules.

                  You can serach for the SID there.

                  BTW I see these all the time :-

                  09:03:42 2 TCP Potentially Bad Traffic 172.16.2.41 52863 17.120.225.104 993 137:1 (spp_ssl) Invalid Client HELLO after Server HELLO Detected

                  IMO you'd be better running SNORT on the LAN interface rather than the WAN interface as you'll see the client IP address rather than the WAN IP address.

                  It also looks like you've got a double NAT going on as your WAN IP address is in RFC1918 address space.

                  Andy

                  1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

                  1 Reply Last reply Reply Quote 0
                  • NollipfSenseN
                    NollipfSense
                    last edited by

                    @NogBadTheBad:

                    Thats HTTP inspection doing that.

                    View the following page on your pfSense router :-

                    Services -> Snort -> Alerts and select the WAN interface and write down the SID number, you get more details about the alert here.

                    Then goto  :-

                    Services -> Snort -> Edit Interface -> WAN -> WAN Rules and select pulldown preprocessor.rules.

                    You can serach for the SID there.

                    BTW I see these all the time :-

                    09:03:42 2 TCP Potentially Bad Traffic 172.16.2.41 52863 17.120.225.104 993 137:1 (spp_ssl) Invalid Client HELLO after Server HELLO Detected

                    IMO you'd be better running SNORT on the LAN interface rather than the WAN interface as you'll see the client IP address rather than the WAN IP address.

                    It also looks like you've got a double NAT going on as your WAN IP address is in RFC1918 address space.

                    Thank you Nogbadthebad for responding with good insight. I plan to move soon; so, in the mean time, I am using my neighbor's WIFI, with permission of course, via a WIFI repeater that has an Ethernet port.

                    My setup is PFSense for WAN and Mikrotik for LAN…so, even when I move; that's my official home network. So, Snort will always on WAN...in fact, that's exactly I got pfSense machine because although the Mikrotik is robust, I wanted to use pfSense to complement it to bring about, hopefully, the ultimate UTM.

                    That's why I might have double NAT although only the Mikrotik has NAT enabled. I checked the SID...it's the same 137:1.

                    pfSense+ 23.09 Lenovo Thinkcentre M93P SFF Quadcore i7 dual Raid-ZFS 128GB-SSD 32GB-RAM PCI-Intel i350-t4 NIC, -Intel QAT 8950.
                    pfSense+ 23.09 VM-Proxmox, Dell Precision Xeon-W2155 Nvme 500GB-ZFS 128GB-RAM PCIe-Intel i350-t4, Intel QAT-8950, P-cloud.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.