Snort still clearing blocked ip's even though it is set to "never"
-
I have the latest pfsense and snort package. But if I let snort sit for awhile I find the block list has been cleared even though I have set it to never clear it. I see nothing in the logs indicating it was cleared. And doesn't seem to be on any time interval I can deduce.
The only thing that corresponds to the clearing of the list are these entries in the log.
Oct 22 06:59:00 check_reload_status: Reloading filter
Oct 22 06:59:00 php: rc.newwanip: rc.newwanip: on (IP address: 192.168.0.1) (interface: lan) (real interface: ue0).
Oct 22 06:59:00 php: rc.newwanip: rc.newwanip: Informational is starting ue0.
Oct 22 06:58:57 check_reload_status: rc.newwanip starting ue0
Oct 22 06:58:57 php: rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.168.0.1 )
Oct 22 06:58:57 php: rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.168.0.1 )
Oct 22 06:58:55 check_reload_status: Linkup starting ue0
Oct 22 06:58:55 kernel: ue0: link state changed to UP
Oct 22 06:58:55 kernel: ue0: link state changed to DOWN
Oct 22 06:58:55 check_reload_status: Linkup starting ue0
Oct 22 06:53:55 check_reload_status: Reloading filter
Oct 22 06:53:55 check_reload_status: Restarting OpenVPN tunnels/interfaces
Oct 22 06:53:55 check_reload_status: Restarting ipsec tunnels
Oct 22 06:53:55 check_reload_status: updating dyndns WAN_DHCP
Oct 22 06:53:00 check_reload_status: Reloading filter
Oct 22 06:53:00 check_reload_status: Restarting OpenVPN tunnels/interfaces
Oct 22 06:53:00 check_reload_status: Restarting ipsec tunnels
Oct 22 06:53:00 check_reload_status: updating dyndns WAN_DHCPThis happens once or twice a day, I have no idea if this is a hacker rebooting pfsense. Or this is normal.
But if it is normal then it ends up clearing the snort block list.
-
There are several threads on the Forum about this (Snort clearing the block list). I wish I could collect a dollar for each one.. ;)
The problem is not with Snort. The issue got introduced in the 2.1 pfSense code base. Anything that caused the filter_reload() process to execute results in all the pf (packet filter) tables getting cleared. Snort uses a pf table called "snort2c" to enter its blocks into. Any number of things appear to kick off the filter reload process. Some of them are a change in the WAN IP (or just a DHCP renewal cycle if your WAN is DHCP-based), any edits to Aliases, any edits to the firewall rules themselves; and there are several other reasons. Any one or more of these could be causing the process to run for you. In the past it seemed to leave Snort's table alone. That is no longer the case.
One of the pfSense Core Team has told me he will look at fixing it soon, but a hotfix release of pfSense would be required. That's probably not going to happen anytime too soon.
I will repeat it one more time, there is really no security issue with the block table getting cleared early. On the very next offending packet from a rogue host, Snort will dutifully block the IP again by putting the IP address in the "snort2c" block table.
Bill
-
Well whether the problem I had was real or not. I happened to try out binding to the Lan (instead of wan) for my snort interface. And I had the results I expected with blocked ip's staying blocked. I set it to "both" for direction. That seemed to fix it.
Only problem is snort cannot perform a portscan from this side of the network (lan). So I created two with this one on wan as a rule-less snort interface (with portscan enabled). Which seemed to work. But annoying to see it warn me about no rules on the interface. And I probably have redundant preprocessing now.
So not sure why I had the problem originally, but there is a solution in case anybody has had problems.
Hopefully one day snort for pfsense will create the block list as a simple "Alias" table. Then snort2C wont be needed. And if Snort could be part of the rules chain order. (instead of first) Then the Whitelist inside of snort won't be needed either. Along with speeding it up since it will not process ip's destined to be blocked by the rule chain ahead of it. including ip's it has previously blocked.
