Skip to content
Breachfolio
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.

June 30, 20269 min read

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:

TechniqueHow
A port scanFrom your analyst VM, run nmap against the DVWA box. Scans are one of the most reliable things an IDS flags.
A known web attack patternUse DVWA's own SQL-injection or XSS exercises. Many ET Open rules match the request signatures these produce.
A suspicious user-agentFetch 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.