Labs · Cyber Security

Lab: Write and Test Simple Suricata Detection Rules for Ping and SSH Traffic in Your Own Isolated Lab

By Ravindra Bagale Last updated: 8 October 2026

Intermediate45 minYour own Ubuntu Server VM in the lab · Suricata (free, open source IDS) · Kali or your laptop to send test traffic

Course: Cyber Security · Chapter 42: Evading IDS, Firewalls and Honeypots – Detection Games

Chapter 42 explains IDS, firewall and honeypot evasion; this lab builds the detection side by writing and testing your own IDS rules.

Chala mitrano! An IDS is a guard that reads network traffic and raises an alert when something matches a rule. Big companies use thousands of rules, but every rule follows the same simple pattern. Today we write two rules ourselves, test them, create the traffic ourselves and watch the alerts appear. Detection engineer banuya!

Suppose we are…

Suppose we are a junior detection engineer at Reliance Jio's security operations centre. Our first task: learn how network detection rules are written, tested and verified before anything goes into production. We use Suricata (a free, open-source IDS used by many SOCs) on our lab Ubuntu VM and write two simple rules for traffic we generate ourselves.

Goal of this lab

By the end you will be able to:

Install Suricata and find your network interface.
Write two rules in local.rules (ICMP ping, new SSH connection) and validate them with -T.
Generate matching traffic and read the alerts in fast.log.

What you need (all free)

Your Ubuntu Server VM. Install Suricata while it is on NAT, then switch it to the host-only lab network (Lab 18).
Kali or your laptop on the same lab network. About 45 minutes.

Safety and ethics

Monitor only your own lab network. Running an IDS on a shared network (office, college, hostel Wi-Fi) captures other people's traffic and needs written permission.

Steps

On the Ubuntu VM (on NAT for now) install Suricata, then switch the VM back to the host-only network:
```
sudo apt update && sudo apt install -y suricata
suricata --build-info | head -n 3
```
Find your lab interface name and IP:
```
ip -br a
```
What you should see: something like enp0s3 UP 192.168.56.105/24. Note the name.

Write your rules. Each rule is: action, protocol, source, port, direction, destination, port, (options):

sudo tee /etc/suricata/rules/local.rules > /dev/null <<'RULES'
alert icmp any any -> $HOME_NET any (msg:"LAB ping to my server"; itype:8; sid:1000001; rev:1;)
alert tcp any any -> $HOME_NET 22 (msg:"LAB new SSH connection to my server"; flags:S; sid:1000002; rev:1;)
RULES

itype:8 is an echo request (ping), flags:S is the first packet of a TCP connection, and sid numbers from 1000000 are reserved for your own rules.

Validate the rules before running them:
```
sudo suricata -T -c /etc/suricata/suricata.yaml -S /etc/suricata/rules/local.rules -v
```
What you should see: 2 rules successfully loaded and Configuration provided was successfully loaded. Exiting.
Stop the background service and run Suricata in the foreground with only your rules (replace the interface name):
```
sudo systemctl stop suricata
sudo suricata -c /etc/suricata/suricata.yaml -S /etc/suricata/rules/local.rules -i enp0s3
```
Leave this terminal running. In a second SSH session to the VM, watch the alert file:
```
sudo tail -f /var/log/suricata/fast.log
```
From Kali or your laptop, generate the traffic yourself: ping -c 3 192.168.56.105.

What you should see: lines like [**] [1:1000001:1] LAB ping to my server [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.56.101:8 -> 192.168.56.105:0.
Now SSH to the VM from Kali or your laptop (you can cancel at the password prompt).

What you should see: [1:1000002:1] LAB new SSH connection to my server ... {TCP} 192.168.56.x:5xxxx -> 192.168.56.105:22.
Improve a rule: a single ping is normal, but many pings in a short time are not. Add a threshold to rule 1, change rev:1 to rev:2, re-validate with step 4 and restart step 5:
```
alert icmp any any -> $HOME_NET any (msg:"LAB ping burst to my server"; itype:8; threshold:type both, track by_src, count 5, seconds 10; sid:1000001; rev:2;)
```
Test with ping -c 10 -i 0.2 192.168.56.105. You now get one alert per burst instead of one per packet.
Stop Suricata with Ctrl + C. Write each rule with: what it detects, why it matters, how you tested it, and how noisy it was.

Ravindra Bagale's Tip

Every good detection rule has three parts: it matches what you want, it does not match too much (noise), and it is tested with real traffic before production. That is why we always run -T first and generate our own test traffic. Rule lihila, test kela, mag vishwas!

Ravindra Bagale's Tip – मराठी

प्रत्येक चांगल्या detection rule चे तीन भाग: हवं ते match करतो, खूप जास्त match करत नाही (noise), आणि production आधी खऱ्या traffic ने test केलेला असतो. म्हणूनच आपण नेहमी आधी -T चालवतो आणि स्वतःचं test traffic बनवतो. Rule लिहिला, test केला, मग विश्वास!

Ravindra Bagale's Tip – हिंदी

हर अच्छे detection rule के तीन हिस्से: जो चाहिए वो match करे, बहुत ज़्यादा match न करे (noise), और production से पहले असली traffic से test हो। इसीलिए हम हमेशा पहले -T चलाते हैं और अपना test traffic खुद बनाते हैं। Rule लिखा, test किया, फिर भरोसा!

Common mistakes

Mistake	What happens	Fix
Wrong interface name (`eth0` instead of `enp0s3`)	Suricata sees no traffic	Check with `ip -br a`
Forgetting `sid` or reusing one	Rule fails to load	Unique sid from 1000000 upward
Editing a rule without changing `rev`	Hard to track which version fired	Increase `rev` on every change
Not running `-T` first	Suricata exits with an error	Always validate before running
Pinging the VM's NAT address	Traffic does not cross the lab interface	Use the `192.168.56.x` address

Self-check checklist

Suricata is installed and I know my lab interface.
local.rules has two rules with unique sids.
-T loaded 2 rules successfully.
I saw ping and SSH alerts in fast.log.
I added a threshold and saw fewer, more useful alerts.

0 of 5 done

Try-at-home challenge

Write a third rule that alerts when anyone connects to port 23 (Telnet) on your lab network, test it, and explain why a defender would want this rule.

Check your answer

alert tcp any any -> $HOME_NET 23 (msg:"LAB Telnet connection attempt"; flags:S; sid:1000003; rev:1;). Validate with -T, restart Suricata, then from Kali run nc -vz 192.168.56.10x 23 towards your lab VM. Telnet sends passwords in plain text (Lab 19), so any use of it on your network is worth an alert.

Samjla ka? Write the rule, validate it, generate the traffic, tune the noise. Aata pudhe jaauya: Chapter 43 secures smart devices at home.