Suricata: how to make it less triggerhappy?



  • Here's the issue: say you're across the globe or on a mobile connection, occasional packet loss: so now all of a sudden your protocol sniffer finds minor protocol violations, and suddenly e.g. your VPN connection end point is part of the blocked hosts list, or your pfSense web session stalls, because your current remote access IP is a blocked host. Now you can wait for an hour (or however long the blocking lasts), or find a different IP from which to log in to purge the IP from the blocked list.

    The alternative is, to disable blocking, but that would allow miscreants to run wild and continue attacking the system while my log files simply fill up.

    Is there some sort of setting that requires a certain level/number/rate/severity of missteps per time unit from a particular source, before it's being blocked? Basically, I don't want unreliable links, dropped packages, etc. lead to be being locked out of my own system, or be forced to just turn off blocking, if anyhow possible.

    Ideas anyone?

    PS: IDS/IPS management noob, so don't chop my head off, if I missed something obvious ;)


  • Banned

    Thats because your setup is wrong… ;)

    If you connect via VPN then you need to use LAN instead of WAN on your setup...make sure that your WAN is not on the same IP as the internet facing services....



  • Supermule has a valid point.  I also find that Suricata tends to be super aggressive with a lot of the protocol related blocks like SYN/ACK issues and all those other stream decoder related alerts.  I usually disable a large majority of those decoder rules on my testing machines.  They are just too noisy in my view.

    I have a VPN for remote access into my system, but admittedly I only use it infrequently.  I've never been locked out, though.  I only use it for RDP (remote desktop) back into my LAN where I connect to a Windows machine.  I run Snort instead of Suricata on my production firewall, but the principles are more or less the same.  Snort is not as trigger happy with all the stream alerts as is Suricata.

    Bill



  • @Supermule:

    Thats because your setup is wrong… ;)

    If you connect via VPN then you need to use LAN instead of WAN on your setup...make sure that your WAN is not on the same IP as the internet facing services....

    Thanks, but that's a bit too cryptic for me.
    Below is what I have, what do you suggest I should have?

    ![Screen Shot 2015-01-02 at 04.28.10.png](/public/imported_attachments/1/Screen Shot 2015-01-02 at 04.28.10.png)
    ![Screen Shot 2015-01-02 at 04.28.10.png_thumb](/public/imported_attachments/1/Screen Shot 2015-01-02 at 04.28.10.png_thumb)



  • @bmeeks:

    Supermule has a valid point.  I also find that Suricata tends to be super aggressive with a lot of the protocol related blocks like SYN/ACK issues and all those other stream decoder related alerts.  I usually disable a large majority of those decoder rules on my testing machines.  They are just too noisy in my view.

    I assume that's what the "Supress" tab is for? I wish I had an idea what to put there to calm down that class of filters/rules…

    @bmeeks:

    I run Snort instead of Suricata on my production firewall, but the principles are more or less the same.  Snort is not as trigger happy with all the stream alerts as is Suricata.

    Aside from the better performance (less overhead) suricata seems to have, the reason I tried it, because Snort used to lock my out in similar ways (in addition to giving me a bunch of other strange problems which so far I didn't have with suricata)


Log in to reply