Test Suricata Inline Prevention¶

Prove a narrow NFQUEUE blocking path without placing management access or unrelated traffic at risk.

Inline testing can disconnect the host

Use a disposable VM, keep hypervisor console access, take a snapshot, and prepare rollback commands before adding NFQUEUE rules. Never start by queueing all INPUT, OUTPUT, or FORWARD traffic on a remote production host.

Plain-language refresher

A passive IDS watches a copy of traffic and normally cannot block it. An inline IPS handles the real traffic and can allow or drop it. NFQUEUE asks Suricata for a verdict on packets selected by the Linux firewall; AF_PACKET inline uses a paired set of sensor interfaces. See Understand sensor placement for diagrams and explanations of TAP, SPAN, NSM, host IDS, and inline IPS.

Understand the verdict path¶

1iptables match2NFQUEUE 03Suricata verdict4allow or drop5EVE evidence

Verify the installed engine has NFQUEUE support:

sudo suricata --build-info | grep -i NFQ

For additional historical implementation context, compare the community Suricata IPS installation example with the installed release's official documentation before adopting any of its commands.

Start with an alert rule and one scoped destination. After the alert path is proven, change only the action to drop and increment rev:

drop icmp any any -> <LAB_TEST_IP> any (
    msg:"LOCAL LAB blocked ICMP echo request";
    itype:8;
    classtype:misc-activity;
    sid:1000002;
    rev:2;
)

Stage a scoped NFQUEUE test¶

Run Suricata on an explicit queue, then insert a rule that matches only the test destination:

sudo suricata -c /etc/suricata/overview.yaml -q 0
sudo iptables -I OUTPUT 1 -p icmp -d <LAB_TEST_IP> \
  -j NFQUEUE --queue-num 0 --queue-bypass
sudo iptables -L OUTPUT --line-numbers -v -n

--queue-bypass favors availability if no userspace listener is attached. If the security design requires fail-closed behavior, document and test that choice separately. For a gateway, scope a FORWARD rule by ingress, egress, source, destination, and protocol rather than queueing the whole chain.

Run one positive and one negative test. Confirm the firewall counter increases, the intended packet is dropped, unrelated traffic still works, and EVE records alert.action: blocked.

sudo iptables -L OUTPUT -v -n
sudo jq 'select(.event_type=="alert" and .alert.signature_id==1000002)' \
  /var/log/suricata/eve.json

Detailed NFQUEUE demonstration¶

The complete PoC procedure is included here with its NFQUEUE capability check, IDS and IPS rules, queue commands, drop alert, and iptables counters. Its broad INPUT, OUTPUT, and FORWARD examples are evidence from a disposable lab, not the recommended default. Apply the scoped rule above for a new test.

Setting up IPS with Netfilter¶

Broad NFQUEUE demonstration

The commands below can queue all host or gateway traffic and disconnect management access. Before reproducing them, use a disposable VM, retain console access, take a snapshot, and prepare the scoped rules and rollback described above.

To check if you have NFQ enabled in your Suricata build, enter the following command:

suricata --build-info

and make sure that NFQueue support: yes is listed in the output.

Edit local.rules to add a sample rule for IPS mode:

sudo nano /usr/share/suricata/rules/local.rules

#IDS Mode
alert icmp any any -> $HOME_NET any (msg: "ICMP Ping Detected"; sid:1; rev:1;)

#IPS Mode
drop icmp any any -> 1.1.1.1 any (msg:"ICMP Detected and Blocked to 1.1.1.1"; sid:2; rev:1;)

Run Suricata with the NFQ mode and use the -q option. This option tells Suricata which queue numbers it should use.

sudo suricata -c /etc/suricata/suricata.yaml -q 0

In this scenario, you are sending traffic that is generated by your computer to Suricata. Run:

sudo iptables -I INPUT -j NFQUEUE
sudo iptables -I OUTPUT -j NFQUEUE

If Suricata is installed on the gateway (e.g. Firewall), you can send traffic that passes through Suricata by running:

sudo iptables -I FORWARD -j NFQUEUE

Execute ping 1.1.1.1 and check Suricata alerts:

ping 1.1.1.1
tail -f /var/log/suricata/fast.log

09/14/2024-16:11:08.050136  [Drop] [**] [1:2:1] ICMP Detected and Blocked to 1.1.1.1 [**] [Classification: (null)] [Priority: 3] {ICMP} 10.0.0.27:8 -> 1.1.1.1:0

To see if you have set your iptables rules correct make sure Suricata is running and enter:

sudo iptables -vnL

In the example you can see if packets are being logged.

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1032 1101K NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            NFQUEUE num 0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1469  126K NFQUEUE    all  --  *      *       0.0.0.0/0            0.0.0.0/0            NFQUEUE num 0

Rollback¶

Remove the exact scoped rule by specification; do not rely on a line number that can change during troubleshooting:

sudo iptables -D OUTPUT -p icmp -d <LAB_TEST_IP> \
  -j NFQUEUE --queue-num 0 --queue-bypass
sudo iptables -L OUTPUT -v -n

Stop the foreground Suricata process, restore the alert rule, validate, and restart the normal service. Confirm the test destination and management path work again.

Completion criteriaThe queue counter, Suricata verdict, EVE action, unaffected traffic, and successful rollback are all evidenced.