Running the af-packet quickstart example in the inline nfqueue mode

Hello,

I’m trying to run nfqueue IPS mode, running the quickstart example (I’m modifying the example in the following section I’ll mention):

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt update
sudo apt install suricata jq
sudo suricata --build-info # Features: NFQ and NFQueue support: yes
sudo systemctl status suricata
# not working yet, shows failed to start and that's OK, will start it from a terminal
# ip addr gives us :
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    link/ether 06:ba:aa:c6:89:07 brd ff:ff:ff:ff:ff:ff
    altname enp0s5
    inet 172.26.15.118/20 metric 100 brd 172.26.15.255 scope global dynamic ens5
sudo suricata-update

In a new terminal;

sudo tail /var/log/suricata/suricata.log

In another terminal(after configuring the af-packet.interface: ens5 in the suricata.yaml):

sudo suricata --af-packet -c /etc/suricata/suricata.yaml  --user suricata --group suricata

It works fine to alert the test packet:

curl http://testmynids.org/uid/index.html

Now, attempting to receive the same errors or even block them with nfqueue setup:

After setting up a suricata-test user and setting up nfqueue, I’m closing the suricata and since the packets sent by the user is waiting for suricata in the queue number 0, we expect the following command to get stuck and it times out as expected, verifying that nfqueue setup works:

sudo -u suricata-test curl http://testmynids.org/uid/index.html

Yes, it is stuck as expected. Now, starting suricata in the inline IPS mode:

sudo suricata -c /etc/suricata/suricata.yaml -q 0 -vv  --user suricata --group suricata

The following code now works and is routed by suricata to the destination; however, it should trigger alerts or get blocked, but it doesn’t:

sudo -u suricata-test curl http://testmynids.org/uid/index.html

This set up even doesn’t work even if I moved the test rule number 2100498 from /var/lib/suricata/rules/suricata.rules into /var/lib/suricata/rules/local.rules file and then change the /etc/suricata/suricata.yaml to include the local.rules file.

Now, how do I know that both the rule files are considered by suricata? Because I duplicated that rule first into the new file(by converting it from alert to drop) and then suricata gave a rule duplicate error, meaning that both the rule files are being read by suricata. Then I removed the original (the alert version) from the suricata.rules file and restarted the suricata, all fine no errors.

Hence, my question is, what might be wrong? This is the most fundamental example that suricata should work and I think I tried to debug it as much as I could. Thank you for your help. I’m using Ubuntu 24.04 in an AWS lightsail VM.

I think this issue must be easily debuggable, with the information I provided. Some more information to make it easier:

The rule number I mentioned above is a test rule ID, mentioned in the quickstart manual. Hence, by changing it from “alert“ to “drop“, we are attempting to configure the inline IPS mode to drop the matching packets. Unfortunately, my set up couldn’t achieve it. Hence, the issue was created.

Did you forward the packets to the queue with iptablese/nft?

yes, I configured the iptables/nftables rules so that traffic from the “suricata-test” user is sent to nfqueue 0. Above in my description, I share a sanity check that validates the set up. I can set up an AWS lightsail instance and share its credentials so that you could see it yourself?