Dear All,
my environment is Debian bookworm Version 12 with the following packages from Debian suricata, suricata-oinkmaster and suricata-update. It’s
Suricata version 6.0.10 RELEASE
To view the logs I use EveBox.
I don’t run a firewall on this server as there is a dedicated FW in front of it.
I start the process with
/usr/bin/suricata -D --af-packet -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid
So far so good. I see a lot of alerts ( identical with events ) in EveBox from those many (67) rules files in the “rules” directory.
When I look at the details of such alerts then I see always as “action: allowed”
It seems that suricata is running only as IDS and not as IPS. When I check the rules I find only one rule with “drop” all others have “alert”.
What I don’t want to have is to deny an attacker IP for a certain time. I just want to drop bad packets.
Obviously I miss something essential to run suricata as IPS to protect the server itself.
Any help is welcome. Not sure which information you need additional to support me.
If you want to drop traffic while only having a single physical interface on the device, you need a method to route traffic to/from the host stack via a pipe between the physical NIC and the host stack. You can do this using the netmap kernel device. That device is available natively on FreeBSD, but it can also be installed on Linux machines. Here is a link: Netmap Installation on Linux - zenarmor.com.
Once you have the netmap device installed and working, you can configure it within Suricata (via the appropriate YAML configuration) to route traffice between the single physical NIC and the host stack. Here is how to configure that: 21.5. Netmap — Suricata 8.0.0-dev documentation.
Later Follow-Up: you could also choose to utilize NFQ in a Linux Suricata install. Here is a link describing that configuration: 15. Setting up IPS/inline for Linux — Suricata 8.0.0-dev documentation. Although I’ve never tested it, I have a suspicion that NFQ is substantially slower with packet processing than netmap. But NFQ should be natively ready to run on your LInux distro whereas netmap will have to be specifically installed and configured in the kernel.
Hi Bill,
many thanks for your swift and very detailed explanation and links to documentation.
If I understand correctly then Suricata is not able to drop an established connection with RST / FIN for a bad/malformed detected IP flow. It has to use any type of firewall to deny the traffic. And therefore it must be inline or virtuell inline, which I still do not completely understand why this is a must.
My server has 4 interfaces and I use already 2 of them in a bridge without IP addresses attached to snoop the traffic in fron of the FW. But using this interfaces will probably not work as it must be routed and not bridged. Therefore the solution you recommend with Netmap.
But still a question: Assuming I have a setup with Netmap. In all these rules I have, I saw only alerts and no drops. Which rule would now really drop a connection ? Or is there a need to install a different set of rules acting as IPS ? I used the one coming with the package.
Suricata can’t really drop packets without interfacing with some other mechanism to do so. On Linux there are 2 ways to perform this without extra software like netmap.
NFQ: Yes, this means running a firewall on the host even if you want to just drop packets to and from the host. The inline docs cover this, 15. Setting up IPS/inline for Linux — Suricata 8.0.0-dev documentation essentially using the INPUT and OUTPUT chains. If you were also routing you’d use the FORWARD chain as well.
AF_PACKET bridge: In this mode Suricata acts as a userland bridge, copying packets between 2 interfaces. This would replace the built-in Linux bridging, it doesn’t work with it. Dropping is then down by not copying the packets that have a drop action.
As for your other question and only seeing alerts and no drops. Most rules are alert only. You’ll need to decide what you want to convert to drop rules and convert them as-needed. Suricata-Verify has a drop.conf where you can set rules to convert to drop by signature ID or regular expression.
Jason is the expert in this area, and he offers excellent advice, so follow his suggestions. I’ve only used Suricata on FreeBSD machines - primarily in the pfSense firewall distro that is based off FreeBSD. There netmap is used as the interface Suricata utilizes to drop traffic.
Hi Bill, hi Jason,
many thanks for your advice.
So we can say, Suricata is an IDS and not an IPS. It acts as IPS with a third party tool, like a firewall.
Thanks for information, I will dig deeper into the documentation.
That is correct. Technically it is an IDS, but it can perform as an IPS with the addition of a third-party interface such as a native firewall app or similar features available via the operating system. It is not an all-in-one application. It requires some assistance from another tool to perform its IPS role.
If you want to be cooperative with the kernel IP stack, such as operating as an IPS on the same machine that is generating and handling incoming packets, it makes sense that it needs to work in concert with the kernel IP stack. That is what integrating with nftables is going to get you, at least its the interface Suricata has to work with the kernel IP stack.
This is also true if you need to integrate the IPS functionality on a router, where the kernel is doing the routing/forwarding of the packets.
However, if you just want a standalone IPS device, you can put Suricata in bridge mode and where it copies packets from one interface to another without any third party tool. If you do this with DPDK you can even “take away” the interfaces from the kernel. However, in this type of IPS you’re a bump in the wire (bridge), and its not going to be an IPS for the IPS device itself.
So it depends on what you need from IPS and what type of deployment scenario meets those needs.