Snort not blocking for a full day? v2.9.4.6 pkg v2.6.0
-
after reboot is change back to old 3600
-
after reboot is change back to old 3600
Yes, for now the minimum setting is one hour in the GUI. And on each reboot or restart of Snort, the crontab entry is updated. You can't go less than 5 minutes because that is the interval the cron job runs on.
Changing it now requires editing code in the snort.inc file in /usr/local/pkg/snort. Unless you are a skilled PHP programmer, I don't recommend toying around in that file as you can seriously break the Snort package that way.
In the upcoming 3.0.0 release I hope to put out in early November, I do provide new blocked IP clearing intervals of 15 mins and 30 mins in addition to the ones already available.
Bill
-
i saw a ton of IPs and then shortly after it cleared. Is it the crontab doing the clearing?
Hope the new code/version will be released soon, it was very handy to have the IPs all listed for other purposes
-
i saw a ton of IPs and then shortly after it cleared. Is it the crontab doing the clearing?
Hope the new code/version will be released soon, it was very handy to have the IPs all listed for other purposes
Unfortunately the premature clearing of the block list has nothing at all to do with the Snort package code. So any update to Snort will have no impact on the premature clearing of the block list. The problem is with a piece of pfSense code and not Snort. Hopefully the next pfSense hotfix release will address it.
Bill
-
i saw a ton of IPs and then shortly after it cleared. Is it the crontab doing the clearing?
Hope the new code/version will be released soon, it was very handy to have the IPs all listed for other purposes
Unfortunately the premature clearing of the block list has nothing at all to do with the Snort package code. So any update to Snort will have no impact on the premature clearing of the block list. The problem is with a piece of pfSense code and not Snort. Hopefully the next pfSense hotfix release will address it.
Bill
Well for some odd reason my IPs from 10/31 are still listed and they havent gotten cleared yet, i must have done something to solve the problem for me
-
Well for some odd reason my IPs from 10/31 are still listed and they havent gotten cleared yet, i must have done something to solve the problem for me
First up, just in case you are on 2.0.3, this clearing issue only impacts the new 2.1 release. The other factor is that something has to trigger the filter_reload() procedure within pfSense. It's the procedure that appears to be at fault with clearing of the block list table. I don't know all the triggers for it. At least one is a DHCP renew on the WAN IP for folks that have that setup from their ISP. Another is making any changes to firewall rules (especially time-based rules). There are probably several other triggers, too.
If you are on 2.1 and have not seen the premature clearing issue, then my guess is your particular setup is not triggering the filter_reload() process.
Bill
-
Well for some odd reason my IPs from 10/31 are still listed and they havent gotten cleared yet, i must have done something to solve the problem for me
First up, just in case you are on 2.0.3, this clearing issue only impacts the new 2.1 release. The other factor is that something has to trigger the filter_reload() procedure within pfSense. It's the procedure that appears to be at fault with clearing of the block list table. I don't know all the triggers for it. At least one is a DHCP renew on the WAN IP for folks that have that setup from their ISP. Another is making any changes to firewall rules (especially time-based rules). There are probably several other triggers, too.
If you are on 2.1 and have not seen the premature clearing issue, then my guess is your particular setup is not triggering the filter_reload() process.
Bill
On 2.1, have all blocks from 10/31 still and the list is growing
-
never done a hotfix for PFSense before, how would it work?
-
Unfortunately the premature clearing of the block list has nothing at all to do with the Snort package code. So any update to Snort will have no impact on the premature clearing of the block list. The problem is with a piece of pfSense code and not Snort. Hopefully the next pfSense hotfix release will address it.
Bill, thanks. I saw you and one other mentioned this earlier in this thread. I went looking but didn't find anything… is there a place where issues currently slated for the next minor release are discussed or at least listed?
Rick
-
Unfortunately the premature clearing of the block list has nothing at all to do with the Snort package code. So any update to Snort will have no impact on the premature clearing of the block list. The problem is with a piece of pfSense code and not Snort. Hopefully the next pfSense hotfix release will address it.
Bill, thanks. I saw you and one other mentioned this earlier in this thread. I went looking but didn't find anything… is there a place where issues currently slated for the next minor release are discussed or at least listed?
Rick
Hotfix is probably a poor word choice on my part. I did not mean to imply something akin to Microsoft's weekly patch updates or something that you apply as a one-off package. I really meant the next incremental release of pfSense (say, for example, if they were to release a 2.1.1 later on).
Bill
-
is there anyway i can edit the code myself to correct this? If you PM the location of the file causing the issue i would like to give it a shot
-
is there anyway i can edit the code myself to correct this? If you PM the location of the file causing the issue i would like to give it a shot
Sorry, but I don't know the exact file. Also, I think it is a compiled C++ program. No easy way to edit that without forking the pfSense GitHub repository and then creating your own ISO builder environment to compile it again with all the pfSense nuances.
Bill
-
The table get's cleared anytime there is a change in the rules (your updating them) , or your lan decides to go from a down to up state, Or a slew of other reasons that make pfsense decide to do the filter_reload.
I have one of the most common motherboards D2500CCE which has Intel Pro lans on it. And after a day pfsense will show in the logs that it is cycling the lan up/down. This will for sure clear the tables. (Peek with Diagnostics/tables). This is exacerbated if you have created a bridge to tie your wireless and lan together. I have tried the patches recommended for the cycling problem with no luck.
-
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>
