HOW TO: Automatic Persistent snort2c table (blocked hosts list) on Suricata


  • Banned

    I noticed that my Suricata Blocked Hosts list gets wiped every time I reboot.

    I think I read somewhere that this is just a fact of life with the way pfSense works.

    Anyways, I figured out that it is actually really easy to automatically keep this list persistent throughout reboots or crashes so I thought I'd share.

    Why would you care that your lists get dumped?
    Really, most people probably don't. I don't have any real reason to need this (I don't need suricata at all, I just geek out on it.)

    The theoretical advantages of keeping up with your lists (as I understand it at least) would be:

    • You have a really big network and suricata has to process a ton of traffic, once an IP is added to the blocked hosts list that traffic is already being dropped and suricata doesn't have to inspect it every time, thus saving CPU cycles. EDIT: See correction https://forum.pfsense.org/index.php?topic=126997.msg709876#msg709876

    • Suricata leaks a little bit of traffic before an IP is identified to be dropped, so if you lose your list of blocked IPs, suricata will leak a little every time it has to re-identify those IPs. If you keep the list of IPs then suricata won't leak any traffic to them as long as they stay on the list.

    • You don't really care about any of these things but you're curious to see how many hosts your current configuration is blocking over time (and either your system crashes occasionally for whatever reason or you reboot frequently). This is why I did it because I reboot frequently right now for 2.4.0 BETA updates.

    So anyways, if for any reason you are interested in doing this:

    Setup a cron job (either via shell or with the package) to output the contents of your snort2c table to a file, i.e.:

    
    pfctl -T show -t snort2c > /usr/local/etc/snort2c.bak
    
    

    To restore it on boot:

    Install the Shellcmd package and make a new Command:

    
    pfctl -t snort2c -T replace -f /usr/local/etc/snort2c.bak	          shellcmd          	Replace the contents of snort2c table from backup.
    
    

    EDIT: Text files compress really well, and this list could potentially get pretty big depending on your network size, so why not compress. If you'd like to compress then replace the above commands with the following

    Cron:

    pfctl -T show -t snort2c | gzip > /usr/local/etc/snort2c.gz
    

    Shellcmd:

    gunzip -c /usr/local/etc/snort2c.gz > /tmp/snort2c_TMP && pfctl -t snort2c -T replace -f /tmp/snort2c_TMP && rm /tmp/snort2c_TMP
    

    I use RAM disks for /var & /tmp to mitigate writes to my flash drive install, so I write the temporary uncompressed file to /tmp, use it then delete it so I don't write to my flash drives unnecessarily.
    There is probably a cleaner way to do this, if you know please share!

    This compression reduces my backup file size by about 60%.

    That's it, I hope this helps someone!



  • I am using Suricata but the snort2c is empty. I did install the snort package earlier but I did remove the snort package.


  • Banned

    If you are using suricata in inline mode then the snort2c table is not used or needed.

    If you are not blocking any hosts with suricata (alert only) then again the snort2c table will not be used.



  • Yes, I am running inline Suricata and did not know that. How do I unblock false positives in the alerts?
    Thanks



  • Just wanted to post up one small correction for Suricata and the snort2c table –

    This bullet in the theoretical advantages list is incorrect:

    You have a really big network and suricata has to process a ton of traffic, once an IP is added to the blocked hosts list that traffic is already being dropped and suricata doesn't have to inspect it every time, thus saving CPU cycles.

    That is unfortunately not the case in practice because Suricata always see traffic before the firewall module does.  Stated differently, traffic hits Suricata first and then the firewall.  Well, technically it hits both simultaneously in Legacy Mode as libpcap is utilized to make a copy of all incoming and outgoing packets.  The copies are sent to Suricata.  Since Suricata will always see the packet whether the firewall blocks it or not, then you don't really lessen Suricata's workload by preloading or persisting the snort2c table.  This is assuming we're talking about Suricata on the WAN.

    Now if you run Suricata on the LAN side, there can be some merit to the persistance mode of snort2c.  This is because the entry in snort2c would cause say inbound traffic from the WAN to the LAN to be dropped and thus Suricata on the LAN would not see the packet.

    Bill


  • Banned

    Thanks for straightening me out Bill, I fixed it in the OP!



  • I tried this but it doesn’t work with these commands.

    To use the cron job you have to use the absolute path to pfctl

    /sbin/pfctl -T show -t snort2c > /usr/local/etc/snort2c.bak
    

    The same for shellcmd

    /sbin/pfctl -t snort2c -T replace -f /usr/local/etc/snort2c.bak
    


  • one thing i have to say about this solution.

    I thought about it and came to the conclusion that it is not nessesary to save the block list as long you have a working supress list.

    or am I wrong ?



  • @pfsense_user12123:

    one thing i have to say about this solution.

    I thought about it and came to the conclusion that it is not nessesary to save the block list as long you have a working supress list.

    or am I wrong ?

    The Block List and a Suppress List are not at all related to each other.  I don't advocate saving the Block List as in my humble opinion that is a pointless exercise, but with that said there is no relationship between the block list and the suppress list (at least not directly).  The Block List is simply a dump of the pf snort2c table's contents.  In other words, the list of IP addresses that have been blocked since the last time that table was cleared.  A Suppress List is a collection of keywords identifying rule signatures that should be suppressed or prevented from firing under the conditions given by the keywords.  Examples are source or destination IP addresses, port numbers or rule signature IDs.

    Bill