Snort S5 Session Exceeded
-
I recently, about a month ago(?) started receiving S5 session exceeded notifications.
"S5: Session exceeded configured max bytes to queue 1048576 using 1049648 bytes"
I've increased the max sessions to the stated max in the gui and this alert seems to suggest that it has increased the maximum possible TCP sessions to a value that exceeds the maximum possible TCP sessions.
From the GUI for the Max TCP sessions field:
Configured Maximum TCP Sessions: 1048576
"Maximum number of concurrent TCP sessions that will be tracked. Min is 1 and max is 1048576. Default is 262144."
Does this alert mean that the maximum TCP sessions is actually higher than the value stated in the GUI?
I also have an arpwatch post here:
https://forum.netgate.com/topic/157512/arpwatch-reports-bogons-frequently
and wonder if they are related?
Is there a way to stop this or find out wahts causing it.
-
Check out this answer to a similar problem from a user on the Snort Mailing List. The post is old (2012), but sounds relevant to your problem. My guess is asymmetric traffic as postulated in this post: https://seclists.org/snort/2012/q3/124.
The defaults for the Stream5 processor in the Snort are usually more than sufficient for any situation. You have some kind of abnormal thing going on if you are exhausting the Stream5 tracked sessions count. For some mysterious reason, it looks like TCP sessions on your firewall are not getting closed (or at least Snort is not seeing them get closed) while new ones are still being created. Under that scenario, you will at some point run out of Stream5 memory. But that scenario is not normal, so I would start checking to see if you have asymmetric traffic or something. Packet captures would be the place to start.
I don't think the bogons issue is related to the Stream5 problem. Plus I see that @johnpoz has already responded with a solution to the bogons problem in your other linked thread.
-
moocho thank you's Mr.Meeks. I will scan that thread today and read deeply tomorrow - today is family, turkey dinner and wine:-)
Enjoy Thanksgiving everyone who celebrates it!
-
Hi Again,
I noticed today that all the affect clients mentioned in the S5 alerts were WIFI clients.
Could this issue be related to my setup?
I have PFsense +Asus AC5300 (used for WIFI only) + 2x 8 port switch.
SO, my network setup
PFsense LAN1 -> switch#1 (all clients)
Asus WIfi LAN port -> switch#1
PFSense LAN2 -> switch#2 (media/file/web srv's)The Asus wifi router had all router functions disabled as far as I know. I could not disable the WAN port on the Asus so I configured it with 10.10.x.x range and left it alone (no RJ45 in WAN port so no connection from/to WAN port).
I configured the Asus LAN/Administration IP to a valid IP/subnet for my network. I can reach and login to the Asus webmin with no issues, all my wifi clients get pfsense delivered dhcp and have internet access. All clients have ad, dns, snort and firewall filtering via pfsense - I know at least snort and ad blocking are affecting the wifi clients in this configuration because I had to suppress some snort rules that were adversely affecting some wifi clients and the wifi clients cannot load googleads for example which are blocked by pfblockerng lists. Other than busybox complaining about not being able to contact an NTP server it has always worked fine.
I logged into the Asus router today to verify the settings and the firewall for the LAN had been turned on. I must have turned it on one night when I was playing around on the router and forgot to turn it off again. I disabled it again. I am hoping this will resolve the S5 alerts.
With this firewall active I imagine it would stop pfsense from "seeing" any traffic behind it?
Could that have caused the S5 error?
I mean, I only have one route to the internet and it is via the pfsense WAN connection. There IS no other route to take, but there IS another router (Asus WIFI) which, as far as I know is NOT being used as a router.
SO, if a packet goes out to the internet by the one route that allows it, it MUST come back in the same route because there is only one route.
-
It's hard to say without having a full diagram, but what the note I linked to was essentially saying is if there is a way for a connection to be see on more than one interface, or if there is a way for the some traffic to take one route while other traffic can take another, and these alternate routes allowed traffic to escape notice by Snort, then you would have the asymmetric issue.
Maybe the firewall is it, but I'm not too sure it is.
