Snort not blocking for a full day? v2.9.4.6 pkg v2.6.0
-
It seems to me whatever pfblocker is doing internally to create it's alias tables, snort should do the same. As far as I can tell pfblocker (using "Alias_Only" mode) has been blocking well.
Here's a link to the code inside pfblocker that creates those tables…
http://www.pfsense.org/packages/config/pf-blocker/pfblocker.inc
So the idea is to let snort use snort2c tables for the immediate blocking. Then append the ip's it finds into an alias for long term blocking (one that survives filter_reload, and reboots). using a normal incoming wan/outgoing lan rule.
-
It seems to me whatever pfblocker is doing internally to create it's alias tables, snort should do the same. As far as I can tell pfblocker (using "Alias_Only" mode) has been blocking well.
Here's a link to the code inside pfblocker that creates those tables…
http://www.pfsense.org/packages/config/pf-blocker/pfblocker.inc
So the idea is to let snort use snort2c tables for the immediate blocking. Then append the ip's it finds into an alias for long term blocking (one that survives filter_reload, and reboots). using a normal incoming wan/outgoing lan rule.
I like where the <snort2c>table is currently located up high in the pf rule chain such that it is hit very early in the packet's traversal of the firewall. This gives Snort a chance to block early and protect users from "quick pass" rules farther down that would bypass Snort.
It occurred to me last night there may a fix for the clearing problem triggered by the filter reloads. I need to talk it over with the Core Team, but maybe the filter reload process could persist the <snort2c>block table out to a temp file during the reload process, and then read the file back in as part of the filter reload. It is trivial to do this with the pfctl utility (dumping a table to a file and loading a table from a file).
Bill</snort2c></snort2c>
