Snort - Maintain session state on blocked traffic
-
When Snort is not configured to block offenders, the state is maintained and I can tell which machine on my LAN may have made an outbound request that triggered an alert.
When it is configured to block offenders, the state is not kept in the states list so I'm unable to identify the local machine making the request (the LAN IP shown in the alerts is the public IP address of my router, not the local machine IP address).
Is there a way to pinpoint which local machine made a request that raised an alert in any other way? The log shows the same info as the alerts page (I also send the logs to a SYSLOG but it too only shows the public IP address of my router).
I'm getting this alert and I'd like to check out the machine that is generating it:
ET CNC Zeus Tracker Reported CnC Server TCP group 4
TIA!
-
Looks like you are running Snort on the "WAN" interface… Best to use the "LAN" interface instead, as that will show the actual LAN IP involved....
For the "WAN" you only need to include the rules that are specific to the WAN... IE: Drop/dShield/Scan rules etc
-
That's what I get for going with the "Hint: In most cases, you'll want to use WAN here".
If I change to the LAN interface, will it impact anything else that I have configured? Suppresses hosts and the like?
Thank you!
-
That's what I get for going with the "Hint: In most cases, you'll want to use WAN here".
If I change to the LAN interface, will it impact anything else that I have configured? Suppresses hosts and the like?
Thank you!
The hint is applicable to say an enterprise or other corporate install that would likely not be using NAT (at least not for all traffic) like a home user would. Nothing wrong with running on the WAN, but with NAT it does make finding the offender on the LAN difficult.
To quickly copy your current WAN config over to the LAN, use the "clone" icon on the SNORT INTERFACES tab next to your WAN interface. That will clone everything onto the LAN. During the clone operation the LAN $HOME_NET, $EXTERNAL_NET and Pass List values will be set to "default", but you can easily select the original values before saving the cloned interface.
You can tell Snort not to clear states for blocked traffic, but that will have the nasty side effect of allowing the blocked traffic to continue through the open state session. There is a checkbox in the section for enabling blocking that determines whether or not associated state table entries are cleared. Please note that turning off the state table clearing will more or less render blocking pretty much useless for the session that triggered the alert.
Bill
-
This is for an enterprise, but we do NAT all traffic. I've cloned the WAN interface to a LAN interface, but only after I ran on the LAN for awhile and then realized that it's not blocking incoming scans.
Is it safe to run on BOTH interfaces at the same time?
-
This is for an enterprise, but we do NAT all traffic. I've cloned the WAN interface to a LAN interface, but only after I ran on the LAN for awhile and then realized that it's not blocking incoming scans.
Is it safe to run on BOTH interfaces at the same time?
Sure, but you would not want to run the exact same rules on both interfaces. That would waste resources. I would run rules specifically designed to protect say public-facing resources like web servers or mail servers on the WAN. You could also run some of the scan rules on the WAN. You would not need those on the LAN side. I'm assuming here also that any public-facing hosts are hopefully in a separate DMZ network and not directly on the LAN.
Bill
-
Great, thank you!!
