Snort not blocking for a full day? v2.9.4.6 pkg v2.6.0
-
I'm not entirely sure yet, but my SNORT 2.9.4.6 pkg v2.6.0 block list is far, far too short (3 entries, with the GPL and ET rulesets, minus a lot of the ET POLICY set) to seem right, and I see more alerts in the log.
I've set blocking to remain for 1 full day. I'm not sure yet, though - I haven't run any scientific tests, nor will I have time to do so for awhile, but I wanted to see if anyone else with >1 hour blocking was seeing anything similar?
-
Snort blocking isn't working properly anymore since pfSense 2.1
This is a known bug in pfSense filter-reload and will hopefully be fixed in the next pfSense hotfix.It's not a Snort package bug.
-
As digdug3 noted, this is a problem in pfSense itself. However, it does not mean Snort is not blocking. It just means the blocks are cleared at intervals not of the user's choosing. However, on the next offending packet from a formerly blocked IP address, Snort should block it again. It just might not stay blocked forever (if you have "never" chosen as the time to clear blocks) or whatever interval you have set. That bug with filter_reload() is clearing Snort's block table on its own schedule.
Again, though, remember Snort should just "re-block" the IP on the next offending traffic. So really no permanent harm done.
Bill
-
Is there a way to upload the previously downloaded list of blocked ips?
-
Is there a way to upload the previously downloaded list of blocked ips?
No, not currently. Not sure that really serves any purpose, though. Remember what I said, on the next offending packet the intruder will be blocked again (just like he was the first time).
Bill
-
How to setup to 5 min? Please
-
How to setup to 5 min? Please
5 minutes for what? Do you mean clear blocks every 5 minutes? If so, currently that time interval is not part of the GUI selection. You can manually edit the cron job to run more often if you wish.
Here is the crontab entry from /etc/crontab:
*/5 * * * * root /usr/bin/nice -n20 /usr/local/sbin/expiretable -t 3600 snort2cYou would change the -t 3600 parameter to something shorter. It is the number of seconds of inactivity for a blocked IP address that make it eligible for clearing out.
Bill
-
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.
