Good afternoon community!
-
Suricata is of version 7.0.8, compiled from source on Debian 12 with the following build-info (snipped):
$suricata --build-info | grep NFQu
NFQueue support: yes -
The start options are:
$ps ax | grep suri
192359 ? Ssl 0:33 /usr/bin/suricata -D -q 0 -c /etc/suricata/suricata.yaml --pidfile /run/suricata.pid -
The intent is to use NFQUEUE with repeat mode and reinjection back into iptables with certain mark for further processing. That said, based on the description of how “repeat” nfq mode operates, I’d expect Suricata to always reinject the packets back.
snippet of the suricata.yaml config:
…
nfq:
mode: repeat
repeat-mark: 8
repeat-mask: 8
fail-open: yes
snippet of the suricata.log file confirming that everything starts as expected:
[192357 - Suricata-Main] 2025-03-19 15:13:36 Notice: suricata: This is Suricata version 7.0.8 RELEASE running in SYSTEM mode
[192357 - Suricata-Main] 2025-03-19 15:13:36 Info: cpu: CPUs/cores online: 40
[192357 - Suricata-Main] 2025-03-19 15:13:36 Info: exception-policy: master exception-policy set to: auto
[192357 - Suricata-Main] 2025-03-19 15:13:36 Info: nfq: Enabling fail-open on queue
[192357 - Suricata-Main] 2025-03-19 15:13:36 Info: nfq: NFQ running in REPEAT mode with mark 8/8
[192359 - Suricata-Main] 2025-03-19 15:13:36 Info: suricata: Preparing unexpected signal handling
[192359 - Suricata-Main] 2025-03-19 15:13:36 Info: conf: Running in live mode, activating unix socket
[192359 - Suricata-Main] 2025-03-19 15:13:36 Info: logopenfile: fast output device (regular) initialized: fast.log
[192359 - Suricata-Main] 2025-03-19 15:13:36 Info: logopenfile: stats output device (regular) initialized: stats.log
[192359 - Suricata-Main] 2025-03-19 15:13:37 Info: detect: 1 rule files processed. 49101 rules successfully loaded, 0 rules failed, 0
[192359 - Suricata-Main] 2025-03-19 15:13:37 Info: threshold-config: Threshold config parsed: 0 rule(s) found
[192359 - Suricata-Main] 2025-03-19 15:13:37 Info: detect: 49104 signatures processed. 1288 are IP-only rules, 4333 are inspecting packet payload, 43267 inspect application layer, 108 are decoder event only
[192396 - RX-NFQ#0] 2025-03-19 15:13:44 Info: nfq: binding this thread 0 to queue ‘0’
- For most of the traffic that works OK. But strangerly, if I feed only half of TCP stream to Suricata (server->client packets only), it starts to block it (I can see it via “suricatasc -c dump-counters”) with stream engine.
The following 3 test rules go at the very beginning of FORWARD chain (IPs and ports sanitized):
iptables -A FORWARD -i eth0 -o eth1 -s a.b.c.d -p tcp --sport 55555 -d x.y.z.w -j NFLOG --nflog-prefix “before suri” --nflog-group 1
iptables -A FORWARD -i eth0 -o eth1 -s a.b.c.d -p tcp --sport 55555 -d x.y.z.w -m mark ! --mark 8/8 -j NFQUEUE --queue-bypass
iptables -A FORWARD -i eth0 -o eth1 -s a.b.c.d -p tcp --sport 55555 -d x.y.z.w -j NFLOG --nflog-prefix “after suri” --nflog-group 1
Then I have log file which reflects the nflog-group 1 (this part is totally non-related to Suricata) and there I can see only packets with the prefix “before suri”. If I disable the middle rule with “-j NFQUEUE…” I can see both prefixes as expected in the log.
-
Hm, I could not find any documentation mention that TCP stream engine is separate in the regard of nfq repeat mode, but nevertherless, I tried to change stream “drop-invalid” option from the default “yes” to “no” - zero effect. I then changed the stream “inline” option value from default “auto” (which equals to “yes” in IPS mode) to “no” - also with zero effect. Suricata continues to block this half TCP session related traffic and does not re-inject it back in spite of .
-
Strangerly, I’m running near of dozen of Suricata instances in prod now (using older versions of Suri, 6.x at max) with the similar approach (IPS with repeat nfq mode) and Suricata always re-injects all the packets back to iptables (even with the default stream settings).
Any ideas would be appreciated!
N.