Suricata IDS lab: write rules, catch a scan, then block it

Suricata is the IDS. nmap makes the port scan, jq reads JSON logs, curl makes web requests.

# apt update
# apt install -y suricata nmap jq curl
# systemctl disable --now suricata
# suricata -V

...
This is Suricata version 7.0.3 RELEASE

Why switch the service off? Ubuntu starts Suricata in the background as soon as it is installed, watching your real network card. In this lab you run your own copy by hand, so you can see every setting. If systemctl says the system was not booted with systemd (older WSL setups), skip that line.

Two pretend machines joined by one virtual cable called sg0. The client gets two addresses, 10.77.0.10 (a normal user) and 10.77.0.20 (a monitoring box, used in step 8). The server is 10.77.0.80.

# ip netns add client; ip netns add server
# ip link add sg0 netns client type veth peer name sg0 netns server
# ip -n client addr add 10.77.0.10/24 dev sg0; ip -n client addr add 10.77.0.20/24 dev sg0
# ip -n server addr add 10.77.0.80/24 dev sg0
# ip -n client link set lo up; ip -n client link set sg0 up
# ip -n server link set lo up; ip -n server link set sg0 up
# ip netns exec client ping -c 1 -W 1 10.77.0.80

The ping should report 1 received, 0% packet loss. A network namespace is a private copy of Linux networking: its own interfaces, addresses and firewall, so it behaves like a separate computer.

Make a lab folder and write a rule file. Copy the whole block; the three long lines are the rules.

# mkdir -p /tmp/surilab/log && cd /tmp/surilab
# cat > local.rules <<'EOF'
alert http any any -> $HOME_NET any (msg:"SGLAB canary word in a web request"; flow:established,to_server; http.uri; content:"sg-canary-7731"; nocase; classtype:policy-violation; sid:1000001; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"SGLAB possible port scan (many SYNs)"; flags:S,12; flow:stateless; threshold:type both, track by_src, count 20, seconds 60; classtype:attempted-recon; sid:1000002; rev:1;)
alert icmp any any -> $HOME_NET any (msg:"SGLAB ping to the home network"; itype:8; classtype:misc-activity; sid:1000003; rev:1;)
EOF
# : > threshold.config
# wc -l local.rules

3 local.rules

Reading a rule. Every rule is action (alert), protocol (http, tcp, icmp), from → to, then options in brackets. $HOME_NET means “our network”. Rule 1 looks inside the web address for the made-up word sg-canary-7731. Rule 2 counts connection attempts (TCP packets with only the SYN flag, the “knock” that starts every connection) and alerts once when one sender knocks 20 times within 60 seconds. Rule 3 alerts on every ping. sid is the rule’s ID number; 1,000,000 and up is the range kept for your own rules. The empty threshold.config is for step 8.

The server gets a small web server so there is something to visit. Then Suricata starts inside the server namespace, listening on its side of the cable.

# ip netns exec server python3 -m http.server 80 --bind 10.77.0.80 >/dev/null 2>&1 &
# ip netns exec server suricata -i sg0 -k none -S /tmp/surilab/local.rules -l /tmp/surilab/log --set vars.address-groups.HOME_NET="[10.77.0.0/24]" --set threshold-file=/tmp/surilab/threshold.config --pidfile /tmp/surilab/suricata.pid -D
# sleep 5; grep -E 'rules successfully loaded|Engine started' log/suricata.log | cut -d' ' -f6-

i: suricata: This is Suricata version 7.0.3 RELEASE running in SYSTEM mode
Info: detect: 1 rule files processed. 3 rules successfully loaded, 0 rules failed, 0
Notice: threads: Threads created -> W: 16 FM: 1 FR: 1   Engine started.

The switches. -i sg0 listens on that interface. -S loads only your rule file. -l is where logs go. -k none stops Suricata ignoring packets whose checksums look wrong, which is normal on virtual cables. --set overrides a setting from /etc/suricata/suricata.yaml without editing it. -D runs it in the background. W: 16 is the number of worker threads; yours will match your CPU.

Visit the server twice from the client: once with a normal search word, once with the canary word. Then read fast.log, Suricata’s one-line-per-alert log.

# ip netns exec client curl -s -o /dev/null -w '%{http_code}\n' 'http://10.77.0.80/?q=hello'
# ip netns exec client curl -s -o /dev/null -w '%{http_code}\n' 'http://10.77.0.80/?q=sg-canary-7731'
# sleep 2; cat log/fast.log

200
200
11/04/2026-21:01:58.551427  [**] [1:1000001:1] SGLAB canary word in a web request [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 10.77.0.10:54856 -> 10.77.0.80:80

Reading it. Both requests worked (200 means OK): an IDS only watches, it doesn’t block. Only the second request raised an alert. [1:1000001:1] is generator : rule ID : revision. Then the message, the category, and who talked to whom. This is how a real canary works: plant a word that should never appear in normal traffic, such as a fake customer record, and alert if anyone ever asks for it.

eve.json is Suricata’s detailed log: one JSON record per event. JSON (JavaScript Object Notation) is labeled data that tools like a SIEM (security information and event management system) read easily. jq picks out the fields you care about.

# jq -c 'select(.event_type=="alert") | {src: .src_ip, dst: .dest_ip, port: .dest_port, sid: .alert.signature_id, url: .http.url}' log/eve.json
# jq -r '.event_type' log/eve.json | sort | uniq -c

{"src":"10.77.0.10","dst":"10.77.0.80","port":80,"sid":1000001,"url":"/?q=sg-canary-7731"}
      1 alert
      2 fileinfo
      2 http

Why two logs? fast.log is for a human glancing at a screen. eve.json is for machines, and it holds far more than alerts: Suricata also wrote an http record for both web requests (the harmless one too) and a fileinfo record for each page it saw sent back. That extra record of normal activity is gold during an investigation. In a real setup you ship eve.json to a SIEM such as Wazuh or Splunk.

A port scan knocks on many doors to find which ones are open. Attackers do it early (it is the “reconnaissance” stage of the kill chain). Scan the first 200 ports of your own lab server.

# ip netns exec client nmap -sS -T4 -p 1-200 10.77.0.80
# sleep 2; grep 'port scan' log/fast.log

Nmap scan report for 10.77.0.80
Host is up (0.000026s latency).
Not shown: 199 closed tcp ports (reset)
PORT   STATE SERVICE
80/tcp open  http
...
11/04/2026-21:02:13.762809  [**] [1:1000002:1] SGLAB possible port scan (many SYNs) [**] [Classification: Attempted Information Leak] [Priority: 2] {TCP} 10.77.0.10:36975 -> 10.77.0.80:194

Reading it. nmap found the one open door, port 80, where your web server is. Suricata saw 200 knocks from one sender and raised one alert, not 200, because the rule’s threshold: type both means “alert once when the count is reached, then stay quiet for the rest of the 60 seconds”. The port in the alert (194 here) is just whichever knock was number 20; nmap tries ports in random order, so yours will differ.

Pretend 10.77.0.20 is your monitoring server. It pings every machine all day to check they are alive, and rule 3 alerts on every single ping. Count the alerts per sender, suppress rule 3 for the monitor only, reload the rules, and count again.

# ip netns exec client ping -c 5 -i 0.2 -q -I 10.77.0.20 10.77.0.80
# ip netns exec client ping -c 2 -i 0.2 -q -I 10.77.0.10 10.77.0.80
# sleep 2; grep 'ping to the home' log/fast.log | awk '{print $(NF-2)}' | sort | uniq -c

...
      2 10.77.0.10:8
      5 10.77.0.20:8

Seven alerts, five of them from the monitor (the :8 is the ping type, not a port). Now suppress, reload, clear the log and repeat:

# echo 'suppress gen_id 1, sig_id 1000003, track by_src, ip 10.77.0.20' > threshold.config
# kill -USR2 $(cat suricata.pid); sleep 3; grep 'rule reload complete' log/suricata.log | cut -d' ' -f6-
# : > log/fast.log
# ip netns exec client ping -c 5 -i 0.2 -q -I 10.77.0.20 10.77.0.80
# ip netns exec client ping -c 2 -i 0.2 -q -I 10.77.0.10 10.77.0.80
# sleep 2; grep 'ping to the home' log/fast.log | awk '{print $(NF-2)}' | sort | uniq -c

Notice: detect: rule reload complete
...
      2 10.77.0.10:8

Why suppress instead of delete? The monitor’s pings are harmless and expected: real alerts about nothing worth acting on, the everyday kind of noise people lump in with false positives. Deleting rule 3 would also hide pings from a stranger sweeping your network, which would make that sweep a false negative. Suppressing it for one known source keeps the rule working for everyone else, as the two alerts from 10.77.0.10 show. kill -USR2 tells a running Suricata to reload its rules and threshold file without stopping. Tuning like this is a daily job for a SOC (security operations center) analyst: an IDS that cries wolf all day gets ignored.

So far Suricata has only watched a copy of the traffic. To block, it has to stand in the path. Stop it, make a copy of the rules where the canary rule says drop instead of alert, tell the server’s firewall (nftables) to hand all web traffic to Suricata through a queue, and start Suricata reading that queue.

# kill $(cat suricata.pid); sleep 3
# sed 's/^alert http/drop http/' local.rules > ips.rules
# ip netns exec server nft add table inet sglab
# ip netns exec server nft add chain inet sglab in '{ type filter hook input priority 0; }'
# ip netns exec server nft add chain inet sglab out '{ type filter hook output priority 0; }'
# ip netns exec server nft add rule inet sglab in tcp dport 80 queue num 0
# ip netns exec server nft add rule inet sglab out tcp sport 80 queue num 0
# ip netns exec server suricata -q 0 -k none -S /tmp/surilab/ips.rules -l /tmp/surilab/log --set vars.address-groups.HOME_NET="[10.77.0.0/24]" --pidfile /tmp/surilab/suricata.pid -D
# sleep 5; grep -c 'binding this thread 0 to queue' log/suricata.log

i: suricata: This is Suricata version 7.0.3 RELEASE running in SYSTEM mode
1

Now the same two visits as step 5. The -m 5 gives up after five seconds.

# ip netns exec client curl -s -m 5 -o /dev/null -w '%{http_code}\n' 'http://10.77.0.80/?q=hello'
# ip netns exec client curl -s -m 5 -o /dev/null -w '%{http_code}\n' 'http://10.77.0.80/?q=sg-canary-7731'; echo "exit $?"
# sleep 2; grep Drop log/fast.log

200
000
exit 28
11/04/2026-21:02:33.209609  [Drop] [**] [1:1000001:1] SGLAB canary word in a web request [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 10.77.0.10:57678 -> 10.77.0.80:80

Reading it. The normal visit still works (200). The canary visit never gets an answer: 000 means no reply and curl’s exit 28 means “timed out”, because Suricata threw that packet away. The log line now starts with [Drop]. Both directions go through the queue because Suricata needs to see the whole conversation to understand a web request. The trade-off: an IPS is inline, so if it crashes or a rule is wrong, real traffic stops too. That is why new rules usually run in IDS (alert) mode first, and why many IPS devices are set to “fail open” (let traffic through if the IPS dies) or “fail closed” (block everything), a choice Security+ likes to ask about.

Stop Suricata and the web server, delete both namespaces (this also deletes the nftables queue rules inside the server), and remove the lab folder.

# kill $(cat /tmp/surilab/suricata.pid)
# pkill -f 'http.server 80 --bind 10.77.0.80'
# ip netns del client; ip netns del server
# cd / && rm -rf /tmp/surilab
# exit

Suricata stays installed but switched off. To remove it too: sudo apt remove suricata.