snort not keeping blocked hosts on reboot
-
Hi,
pfSense 2.4.4-p3, snort 3.2.9.9_1Snort working fine, but! When I restart the firewall, the blocked host are clean.
I need that the offenders remain blocked as long as possible.
Thanks.
-
It doesn't the tables are cleared on reboot.
You can set the entry to a maximum of 28 days.
-
@heliop100 said in snort not keeping blocked hosts on reboot:
Hi,
pfSense 2.4.4-p3, snort 3.2.9.9_1Snort working fine, but! When I restart the firewall, the blocked host are clean.
I need that the offenders remain blocked as long as possible.
Thanks.
Why do you need to keep the offenders blocked as long as possible? Do you not realize that if they repeat the same packet sequence that Snort will block them again? If Snort blocked them on the first malicious packet they sent, why do you think it will not block them on any subsequent packets it detects from the same host?
There is absolutely no point whatsoever for keeping blocked hosts persistent through a reboot. In fact, there really is no security-valid argument for keeping a host blocked for more than 10 or 15 minutes at most. As I stated, if the same host "re-offends" by sending more malicious traffic, that host will be blocked again.
-
The only potential "benefit" that I could see, as I was once wondering the same thing with Suricata (which makes no difference in this case) but would really be dependent on how the logic was handled, is that if a offender that was already on the block list would skip being processed by the IPS and simply be immediately blocked then having the list persist through things like reboots could save some CPU time. As it would not have to re-look at things from a host that was already block and thus resulting in the same outcome again. However it can also be said if the IPS doesn't look at the packets from that host again then you would not be able to generate alerts for subsequent connection attempts; that would trip that same rule.
And yes I know you can always take specific address and add them to the firewall rules to be blocked that way. Not to mention that just cause a host at one point was compromised does not mean that it will always be etc.
Just my two cents.
-
@jchud said in snort not keeping blocked hosts on reboot:
The only potential "benefit" that I could see, as I was once wondering the same thing with Suricata (which makes no difference in this case) but would really be dependent on how the logic was handled, is that if a offender that was already on the block list would skip being processed by the IPS and simply be immediately blocked then having the list persist through things like reboots could save some CPU time. As it would not have to re-look at things from a host that was already block and thus resulting in the same outcome again. However it can also be said if the IPS doesn't look at the packets from that host again then you would not be able to generate alerts for subsequent connection attempts; that would trip that same rule.
And yes I know you can always take specific address and add them to the firewall rules to be blocked that way. Not to mention that just cause a host at one point was compromised does not mean that it will always be etc.
Just my two cents.
No, Snort always processes all packets. It is positioned in the input stream such that the first thing a packet directly off the NIC driver hits is Snort. That's true for any interface. So Snort sees traffic before any firewall rules for the interface are applied.
Snort itself does not actually block traffic. Instead, it extracts the IP addresses from offending packets and passes those to a special
pftable maintained by the pfSense code. Any IP address added to that special table (called snort2c) is blocked by the firewall. Even still, Snort will still process all packets, so even if an IP address is already in the snort2c table, that does not mean Snort won't still inspect packets containing that IP address. -
@bmeeks Exactly my point, given that the current logic has it that Snort/Suricata will always look at the packet first (before the firewall) regardless then it makes no difference whether or not the block list is kept as like you said if an offender was already blocked once it will do so again. I was simply stating that if things were handled differently I could see a reason for it.
-
This complaint that Snort (or Suricata) does not persist blocks across firewall reboots and that it does not persist blocks basically forever comes up about every 3 to 6 months. Each time I explain the logic, but the next new user comes along later and complains about the same thing all over again without really understanding what they are complaining about nor why it is not useful. It triggers my <rant> switch sometimes ...
.I'm turning into a curmudgeon, I guess ... LOL.
-
I completely understand, especially since I work in IT security. Personally I blame it on the fact that there is not one central comprehensive guide book out there for given products, so when a new user comes around their choices basically are either just ask the question over again for the millionth time or pour through thousands of form posts and hope to find the one that has the specific info they are looking for.
For example I run into the issue all time when I am trying to do something via the command line for pfsense I end up spending like an hour or more trying to track down a specific file location or command cause even though its based on freebsd things do not always line up exactly; and like I said those differences aren't really clearly documented anywhere.
-
@bmeeks said in snort not keeping blocked hosts on reboot:
Why do you need to keep the offenders blocked as long as possible? Do yo
I want to block torrents downloads, As the seeds keep changing, torrents slow down, but not stops. As the blocked hosts list grows, the download speed slow down. After the pfsense reboot the process need to begin from scratch again.
Thanks.
-
@heliop100 said in snort not keeping blocked hosts on reboot:
@bmeeks said in snort not keeping blocked hosts on reboot:
Why do you need to keep the offenders blocked as long as possible? Do yo
I want to block torrents downloads, As the seeds keep changing, torrents slow down, but not stops. As the blocked hosts list grows, the download speed slow down. After the pfsense reboot the process need to begin from scratch again.
Thanks
I fail to see a connection between persistent blocks and the action you describe. Explain to me how you think that persistent blocks make a difference in your scenario. A block is a block, it does not matter if it just happened or if it happened three months ago.
If you have blocking enabled and "kill states" enabled, the torrent from that specific seeder will stop. Will the client perhaps try and find another seeder, sure, but then that seeder will be blocked if the rule is there to trigger on the packets.
No IDS I am aware of has persisent blocks. In fact, an IPS does not even have the capability of persisting a block for any period of time. An IPS performs real-time drops of packet data, but there is no persisted block.
Persistent blocks that hold across a firewall reboot is not a design feature of the Snort package and no such feature is ever planned. There is no need for it.
