I am working to setup IDS + source IP blocking on a VPS with a single interface. I have previously used PSAD, and it was easy to configure it to block source IPs (using iptables), send email alerts, etc. I’d like to use Suricata in a similar way, but it seems that you need to route all your traffic through suricata (NFQueue mode). Does anyone know of a simple config with Suricata in monitoring mode (e.g. af-packet mode instead of the in-line NFQueue mode) that allows building up blocklists of offending IPs, and actively blocking those IPs with iptables rules, etc.? It seems you have to route all your traffic through suricata as an active filter in IPS mode if you want this. I just want Suricata listening to the network port and blocking offenders from accessing my server in the future by adding new iptables DROP rules–Is there an easy way to do this with Suricata? Maybe I’ve just missed a basic config option.
Am I trying to do something that no one else does? Am I just thinking about this in a strange way?
Is the best/only way to block source IPs that engage in suspicious interactions with Suricata (without writing a script/app that processes Suricata log/socket output) to put Suricata inline with all incoming traffic?
Have you had a look at 13. Setting up IPS/inline for Linux — Suricata 7.0.0-dev documentation, specifically “scenario 2”?
Yes. The scenario 2 has Suricata inline with all traffic to the server.
What I’m trying to setup is a scenario where I have Suricata not inline, but watching for suspicious traffic and adding in iptable drops for all source IPs engaged in suspicious activity.
If I want this it soundly like the best solution might be monitoring the Suricata JSON feed, and adding in blocks with a script/app.
Does any such extension/add-on exist?
Is there a mode where Suricata performs the blocking but is not inline with all traffic to the server?
How should Suricata perform the block if it’s not inline and just passively listening?
But yes you could write a tool that would check the Suricata output and use the information to feed the netfilter part that would be able to block. This sounds like a very custom use case.
i am trying to do same thing with you hive. I have been using suricata on Legacy Mode and i wanna block the package if it hits the drop rules. However, what i understand is that if ur using suricata on legacy mode, you can’t block packages. Which is not make sense for me. isnt it one of the reasons why we use suricata 
when the package hits the drop rule, suricata just generates an alert(which is not drop alert) and passes the package.
pfsense uses snort to block packages , if u use suricata on legacy mode. Dont we have any other reasonable why to block packages ? (i dont wanna use nfq either)
Hi. Blocking packages is a lot easier when Suricata is responsible for transferring the packet from one interface to another. If Suricata is listening passively and not involved in the packet path then there will be a race condition where Suricata needs to update some localhost fw rule before the packet is sent to the application. That sounds like a race that Suricata will lose every time and I don’t see any way it could be different. You could of course block the following packets in the same flow, the source IP, etc. But that sounds hard to deal with for Suricata as the needs could differ a lot from deployment to deployment.
Note that I have little experience myself with IPS deployments.
My goal was to have Suricata detect suspicious source IPs, then to use iptables to block them from future connection attempts.
I am a bit concerned about all traffic running through Suricata, as it is one more point of failure & one more source of latency, but maybe I should not be thinking about it like this.
I think there is a way that could solve this request and is actually the reason why I stumbled upon this post.
In my case Suricata logs the suspicous traffik into the fast.log. I also have fail2ban running, which blocks IPs that apear in my log files.
My idea is, why not continue to log suspicous traffic through into the fast.log, have fail2ban scan it for entries and have those IPs listed in the fast.log than baned (in almost realtime)? I am pretty sure this would work perfectly, the only thing I am missing is the definition of the filters in fail2ban (as I haven’t figured regex out).
Im looking for solution for the same problem ,Did the above work for you? .