Catching a Ping: Setting Up Suricata IDS to Detect ICMP Traffic

If you've ever wondered how network defenders actually "see" an attack happening in real time, this lab is a good first taste of it. I set up Suricata, an open-source Intrusion Detection System (IDS), on Ubuntu, wrote a custom rule to flag ICMP traffic, and then attacked my own machine from a Kali Linux VM — just a simple ping to watch Suricata catch it live.

Why This Matters

Suricata sits on a network and inspects every packet that crosses it, comparing traffic against a set of rules patterns that describe what "suspicious" looks like. This lab focuses on ICMP (the protocol behind ping) because it's simple enough to fully understand end-to-end: write one rule, generate one type of traffic, and watch the detection happen. The same logic scales up to detecting port scans, malware beaconing, or exploit attempts in a real SOC environment.

The Setup

• Target: Ubuntu Linux running Suricata

• Attacker: Kali Linux

• Both VMs on the same network so Kali could reach Ubuntu directly

What I Did

1. Installed Suricata via the official OISF PPA on Ubuntu.

2. Backed up the default config (suricata.yaml) before touching anything, a habit worth keeping, since one bad edit can break the whole service.

3. Found my real network interface with ip a and updated the config's HOME_NET and capture interface to match — this tripped me up initially, since the default config assumed an interface name (eth0) that didn't exist on my VM.

4. Wrote a custom detection rule: alert icmp any any -> $HOME_NET any (msg:"Incoming ICMP packets!"; sid:123; rev:1;)

In plain terms: "If any ICMP packet arrives heading into my network, raise an alert."

5. Started Suricata in live capture mode, then tailed its alert log (fast.log) in a second terminal so I could watch alerts appear in real time.

6. Switched to Kali and pinged the Ubuntu machine.

The Result

The moment the ping left Kali, Suricata logged it instantly:

[**] [1:123:1] Incoming ICMP packets! [**] [Classification: (null)] [Priority: 3] {ICMP} 192.168.1.7 -> 192.168.1.4

That single log line is the whole point of an IDS, that is, turning raw network traffic into a readable, actionable alert.

Biggest Takeaway

The technical setup wasn't the hard part — troubleshooting was. A wrong interface name and a missing rule reference both caused Suricata to fail silently or refuse to start, and tracing those errors back through journalctl and Suricata's own log file taught me more about how IDS tooling actually works than the installation steps did. Reading the right log (Suricata's own suricata.log, not just systemctl status) made all the difference in finding the real cause.