[Suricata 1.4.6 v1.0.2] Streaming Content issues
-
So I deployed this package to a medium LAN (3K users). It's a WiFi area for people to relax and watch videos. Since I've deployed this package I've identified a few baddies I've been trying to get kicked off my network for the past 3 months (thank you Suricata team). This was something I wasn't detecting through Snort, but that is most likely my fault for not configuring it properly. In any event, the new issue that's emerged is that my users are complaining that Youtube, Amazon Prime, and occasionally Netflix are experiencing errors. All three services are due to Suricata blocking the sites. Here are a couple formatted snippets from my logs:
1,2210000,1,SURICATA STREAM 3way handshake with ack in wrong dir,(null),3,TCP,54.221.36.251,443,[MyIP],32257 AMAZON 1,2210000,1,SURICATA STREAM 3way handshake with ack in wrong dir,(null),3,TCP,107.22.250.136,443,[MyIP],32394 AMAZON 1,2210017,1,SURICATA STREAM CLOSEWAIT invalid ACK,(null),3,TCP,[MyIP],55478,74.125.5.237,443 GOOGLE 1,2210017,1,SURICATA STREAM CLOSEWAIT invalid ACK,(null),3,TCP,[MyIP],54684,173.194.56.14,443 GOOGLE 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,74.125.129.95,443,[MyIP],47208 GOOGLE 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,173.194.33.38,443,[MyIP],43715 GOOGLE 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,176.32.98.166,443,[MyIP],42394 AMAZON 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,207.171.162.130,443,[MyIP],33027 AMAZON 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,198.45.53.178,80,[MyIP],62157 NETFLIX 1,2210045,1,SURICATA STREAM Packet with invalid ack,(null),3,TCP,[MyIP],42054,74.125.5.6,443 GOOGLE 1,2210045,1,SURICATA STREAM Packet with invalid ack,(null),3,TCP,[MyIP],9008 ,173.194.56.13,443 GOOGLE
Now, I believe these are happening due to latency between my network and the service. The question is, how do I handle these issues? I don't want to remove the rule, but I do want to drop in those domain's subnet ranges so it knows to ignore them. I've been trying to go through the documentation, but I don't know where to start.
Any suggestions?
-
So I deployed this package to a medium LAN (3K users). It's a WiFi area for people to relax and watch videos. Since I've deployed this package I've identified a few baddies I've been trying to get kicked off my network for the past 3 months (thank you Suricata team). This was something I wasn't detecting through Snort, but that is most likely my fault for not configuring it properly. In any event, the new issue that's emerged is that my users are complaining that Youtube, Amazon Prime, and occasionally Netflix are experiencing errors. All three services are due to Suricata blocking the sites. Here are a couple formatted snippets from my logs:
1,2210000,1,SURICATA STREAM 3way handshake with ack in wrong dir,(null),3,TCP,54.221.36.251,443,[MyIP],32257 AMAZON 1,2210000,1,SURICATA STREAM 3way handshake with ack in wrong dir,(null),3,TCP,107.22.250.136,443,[MyIP],32394 AMAZON 1,2210017,1,SURICATA STREAM CLOSEWAIT invalid ACK,(null),3,TCP,[MyIP],55478,74.125.5.237,443 GOOGLE 1,2210017,1,SURICATA STREAM CLOSEWAIT invalid ACK,(null),3,TCP,[MyIP],54684,173.194.56.14,443 GOOGLE 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,74.125.129.95,443,[MyIP],47208 GOOGLE 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,173.194.33.38,443,[MyIP],43715 GOOGLE 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,176.32.98.166,443,[MyIP],42394 AMAZON 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,207.171.162.130,443,[MyIP],33027 AMAZON 1,2210021,2,SURICATA STREAM ESTABLISHED retransmission packet before last ack,(null),3,TCP,198.45.53.178,80,[MyIP],62157 NETFLIX 1,2210045,1,SURICATA STREAM Packet with invalid ack,(null),3,TCP,[MyIP],42054,74.125.5.6,443 GOOGLE 1,2210045,1,SURICATA STREAM Packet with invalid ack,(null),3,TCP,[MyIP],9008 ,173.194.56.13,443 GOOGLE
Now, I believe these are happening due to latency between my network and the service. The question is, how do I handle these issues? I don't want to remove the rule, but I do want to drop in those domain's subnet ranges so it knows to ignore them. I've been trying to go through the documentation, but I don't know where to start.
Any suggestions?
First off, I think there are potentially some bugs in the stream code of the 1.4.x Suricata binary series. I see a lot of these kinds of errors in my test VMs. The Suricata package on pfSense currently is using the older 1.4.6 binary because that's what is in FreeBSD ports right now. It should update soon to the 2.0.x binary series. Maybe that will quiet down some of the TCP stream issues.
In the meantime, you can add the destination networks to the Pass List by creating an Alias (under Firewall…Aliases) and adding all the individual IP addresses to the alias. Then go to the PASS LISTS tab and add the alias you just created to a Pass List and be sure that Pass List is assigned to the corresponding Suricata interface. NOTE: unfortunately you cannot use a FQDN in aliases for Suricata (or Snort). This is because neither binary can "real time" resolve a FQDN to its IP address. This can make whitelisting something like Amazon or Netflix problematic because they use a CDN (content distribution network) with large and seemingly random IP pools. So your clients could be hitting vastly different IP blocks with each Netflix session.
In the end, your best bet might to either suppress the alert or disable the rule. There are some additional TCP stream settings on the FLOW STREAM tab that you can experiment with. They might help.
Bill
-
Cause: False positives caused by wifi clients moving around.
Solution: disable said rules.
All this talk about suricata is forcing me to speed up my upcoming suricata blueprint topic. ;D
-
In the end, your best bet might to either suppress the alert or disable the rule. There are some additional TCP stream settings on the FLOW STREAM tab that you can experiment with. They might help.
I will give it a shot, thanks! I'll let you know if it helps. Any ETA on the 2.x binaries?
@jflsakfja:
Cause: False positives caused by wifi clients moving around.
Solution: disable said rules.
While I thought that originally, I starting tracking the APs to see if this was the cause (i.e.should I loosen up my roaming profile). This was not the issue for 74.3% of clients. The other 25.7% were due to reauth attempts or other issues. I'd post an example, but it's proprietary info.
-
Those rules were evaluated as false positives on "closed" networks (limited number of users), all trusted. They mostly fired on wifi clients, hence the "wifi clients moving around" comment.
That "category" of rules (weird traffic) was generally either caused by a wifi client moving from point A to point B and missing a couple of packets OR more rarely by suricata itself, that is after suricata has cleared the states for a blocked host. Technically the firewall has no record of an active connection, which triggers the "weird traffic" category.
As I said, false positives. Disable.
Note: By category I'm talking about my categories. There are 3 categories: 1)Rules that should have their creators exiled from earth, subcategories idiotic rules (simple http request), stupidly outdated rules (firefox 3.x rules). 2)Weird traffic rules, includes "unknown" traffic, or theoretically impossible traffic (in theory, theory and practice are equal. Practically they are not) and finally 3) Rules that their creators should be honored with nobel prices and generally thought of as humanity's $deities.