LAB · SERIES

Lab 05 – see the packets, not just the logs.

Host logs tell you what happened on a machine. An IDS tells you what crossed the wire. Add Suricata, point it at your own traffic, and read the alerts.

July 10, 20269 min readDaniel A. & Óscar S.

Lab 03 gave you host-based visibility with a SIEM; Lab 04 segmented the network. This lab adds the third kind of sight: network detection. An IDS (Intrusion Detection System) inspects packets as they pass and matches them against signatures of known-bad traffic. You will install Suricata, a free open-source IDS, and watch it flag activity you generate against your own DVWA target from Lab 02.

Where to run it

In a lab, the simplest useful placement is to run Suricata on a monitoring VM that can see the traffic to your targets – either on the pfSense box from Lab 04, or on a dedicated VM whose interface is watching the targets segment. You do not need a network tap; for learning, running Suricata directly on the path the traffic takes is enough.

Install Suricata and its rules

# on the monitoring vm (Ubuntu/Debian)
$ sudo apt update && sudo apt install -y suricata

# fetch and enable the ET Open ruleset
$ sudo suricata-update
$ sudo systemctl restart suricata

suricata-update pulls the Emerging Threats (ET) Open ruleset: a large, free set of community signatures for known attacks and suspicious patterns. Confirm Suricata is watching the right interface by checking /etc/suricata/suricata.yaml for your targets-segment adapter, then restart.

Generate traffic worth detecting

Now make some noise – all of it against your own DVWA host from Lab 02:

Technique	How
A port scan	From your analyst VM, run `nmap` against the DVWA box. Scans are one of the most reliable things an IDS flags.
A known web attack pattern	Use DVWA's own SQL-injection or XSS exercises. Many ET Open rules match the request signatures these produce.
A suspicious user-agent	Fetch a page from DVWA with a tool whose default user-agent is on the ET blocklist (some scanners announce themselves). It is a gentle way to trigger a rule on demand.

Read the alerts

Suricata writes alerts to /var/log/suricata/fast.log (one line per alert) and richer JSON to eve.json. Tail the simple one while you generate traffic:

$ sudo tail -f /var/log/suricata/fast.log

Each line names the rule that matched, a classification, and the source and destination. Correlate what you see there with what your Wazuh SIEM from Lab 03 recorded on the host side: the same event, seen from two vantage points. That is the whole idea of defence in depth made concrete on hardware you control.

IDS vs IPS, and false positives

Two things are worth understanding once the alerts are flowing. First, an IDS detects: it watches and reports. Its close cousin the IPS (Intrusion Prevention System) sits inline and can block traffic that matches a rule. Suricata can run in either mode; you started in IDS mode because in a learning lab you want to see everything, not silently drop it. Switching to inline prevention is a deliberate later step, once you trust your rules.

Second, you will see alerts you did not cause, and that is the real lesson. The ET Open ruleset is broad, so ordinary lab traffic sometimes matches a signature. Learning to tell a genuine detection from a false positive is the single most valuable skill an IDS teaches. Read the triggering rule, look at the packet it matched, and decide: real, or noise? Analysts spend a large fraction of their time on exactly that judgement, and your lab is the safest possible place to start building it.

A practical habit: when a rule fires that you know is benign in your lab, do not just ignore it – note why it is benign. That reasoning is what you would document when tuning a rule set in a real environment, and practising it here makes the production version routine.

You have built a real lab

Five labs in, you have an attacker box, a segmented network, a vulnerable target, host-based detection and network-based detection: a miniature but genuine security environment. Every future technique you want to learn now has a safe place to run. Whether you go deeper into blue-team detection engineering or red-team tradecraft from here, the environment is ready and the rule never changes: everything stays inside the lab you own. That is the payoff of building it up one layer at a time.

Legal & scope. Every scan, injection and probe in this series is aimed at machines you built, inside a private lab you control. Running these techniques against systems, sites or networks you do not own – or lack explicit written authorization to test – is unlawful in most jurisdictions. The lab exists precisely so you never have to.

Frequently asked questions

What does an IDS like Suricata add that a SIEM doesn't?

A SIEM such as Wazuh gives host-based visibility: what happened on a machine. An IDS like Suricata inspects packets as they cross the wire and matches them against signatures of known-bad traffic, giving network-based visibility. Running both lets you correlate the same event from two vantage points, which is the core idea of defence in depth.

Where should Suricata run in a segmented home lab?

The simplest useful placement is a monitoring VM that can see traffic to your targets - either the pfSense box from Lab 04 or a dedicated VM whose interface watches the targets segment. A network tap is not required for learning purposes; running Suricata directly on the path the traffic takes is enough.

What is the difference between an IDS and an IPS?

An IDS (Intrusion Detection System) watches traffic and reports matches without acting on them. Its close cousin, the IPS (Intrusion Prevention System), sits inline and can actively block traffic that matches a rule. Suricata can run in either mode; a learning lab typically starts in IDS mode so you see everything before deciding what to block.

How do I tell a real Suricata alert from a false positive?

Read the rule that triggered the alert and look at the packet it matched, then judge whether the traffic is genuinely malicious or just noise from the broad ET Open ruleset. This judgement call is one of the most valuable skills an IDS teaches, and it helps to note down why a benign rule fired so the reasoning is documented for later tuning.