Why Snort Blocks Apple Domain?

[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.

[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

[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

[bmeeks]

@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

[Velcro]

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?

[NollipfSense]

@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.


[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.

[NollipfSense]

@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.