Snort's Alert & blocking system
-
After using snort for some time now. it seems Snort is getting access before all the wan rules. And blocks via its own system without using the firewall list. (Snort2c)
This creates several problems as it bypasses the rules system, including blocks and re-process's IP'S already setup in the rules and analyzes the ips that would have been rejected by blacklists. Which is why it has it's own whiltelist because it ignores the rules. It should process at the end of the rules chain. and a snort whitelist would be unnecessary.
When it does block it creates its own internal list, and is not added to the firewall list, which then is invisible to logging tools and add-ins that can analyze the list. So no information about what it is blocking (or is) can be seen.
For the block list I propose that it put the ip's in an alias and then the user can add into his rules and do a variety of things including setting the order of these blocks, along with the ability to log the entries.
Then when the rules fire off. Snort blocks will naturally end up logged into the firewall table.
Which the user can then interact with these entries just like any other firewall ip entry. Add-ins will then be able to used to view what snort is doing instead of it being a ghost in the system. -
Using the scenario you describe with something like pfBlocker in concert with Snort, I would run only a single Snort instance on the LAN side. That way the firewall rules will "filter" incoming IP addresses using the rules you specify along with pfBlocker.
Snort then will run on the LAN side looking for malicious traffic to/from your LAN hosts. It can and will still block if you so configure it. What I do is set the block direction to "both". That way it will block the foreign malicious host whether it is the SRC or DST for the traffic. LAN hosts will automatically be whitelisted if you accept the defaults, so they won't be blocked. They will still alert and log, though.
Bill
