Lab 03 — a SIEM you can actually read.
You have a lab and a target. Now add the thing that watches: a Wazuh SIEM, single-node, on the same hardware — and three detections to prove it works.
This is the third lab in the series. In Lab 01 you built a home lab on one laptop; in Lab 02 you added a deliberately vulnerable target. So far you can attack — but you cannot see. A SIEM (Security Information and Event Management) is the missing half: it collects logs from your machines, correlates them, and raises alerts when something matches a rule. Here you will stand up Wazuh, a free and open-source SIEM, and watch it light up.
What you need before you start
- The home lab from Lab 01 — a hypervisor with at least one Linux VM you can reach over the host-only network.
- A second VM (or a reasonably sized one) for the Wazuh server: 4 GB RAM is the practical minimum, 6–8 GB is comfortable. Wazuh bundles a search back-end, so it is the heaviest box in the lab.
- A working host-only or internal network so the agent and server can talk without touching your real LAN.
Install Wazuh, single-node
Wazuh ships an assisted installer that stands up the server, the indexer and the dashboard on one machine. On the VM you have chosen as the server, run the official quickstart:
# on the Wazuh SERVER vm (Ubuntu/Debian)
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
sudo bash ./wazuh-install.sh -aThe -a flag means "all-in-one". When it finishes it prints the dashboard URL and the generated admin password — save both. Browse to https://SERVER-IP from your host, accept the self-signed certificate (this is a lab), and log in. You now have an empty SIEM waiting for data.
Connect your first agent
An agent is a small piece of software on each monitored machine that ships logs to the server. Install it on the Linux VM you want to watch — for example your DVWA host from Lab 02:
- In the Wazuh dashboard, open Agents → Deploy new agent. Pick the OS, enter the server IP, and it generates the exact install command for you.
- Run that command on the target VM. It registers the agent and starts it.
- Back in the dashboard, the agent appears as Active within a minute. If it stays "Never connected", the usual cause is the two VMs not being on the same reachable network — revisit the Lab 01 networking.
Three detections to prove it works
An idle SIEM teaches you nothing. Generate activity on the agent VM and watch it appear under Security events:
| Detection | How to trigger it | What it shows |
|---|---|---|
| Failed logins | SSH into the agent VM with a wrong password a few times | The classic brute-force signature — flagged within seconds |
| New sudo command | Run something with sudo | Privilege escalation logging — spots an account doing something unusual |
| File integrity change | Create or edit a file under a monitored path (such as /etc) | An FIM integrity alert — the mechanism that catches tampering |
Each alert carries a rule ID and a severity level. Click one and read the raw log underneath it: the point of a home SIEM is to build the habit of going from "an alert fired" to "here is exactly what happened and why the rule matched".
Where this fits
A SIEM is not a replacement for the firewall you will add in Lab 04 or the IDS in Lab 05 — it is the layer that reads what those layers saw and turns scattered logs into one investigable timeline. Once Wazuh is running here, every later lab in the series feeds it: segmentation changes show up as new agent groups, IDS alerts correlate against the same host events. Get comfortable with this dashboard now, because it is where you will keep coming back.
When it does not work the first time
Two problems account for most first-run trouble, and both are quick to fix:
- The agent shows "Never connected". Almost always a network reachability issue: the agent VM cannot reach the server on the required ports (1514/1515). Confirm both VMs are on the same host-only or internal network, and that the server's firewall is not blocking the agent ports.
- The dashboard is slow or the server runs out of memory. Wazuh bundles an indexer that is genuinely memory-hungry. If the box has only 4 GB, close everything else on it; if you can spare more RAM to the VM, give it 6–8 GB and the sluggishness disappears.
With Lab 03 done, your lab has all three sides of practical security: an attacker's toolkit, a target to practise on, and a defender's view of what that activity looks like from the blue-team seat. That last part is what makes the difference between memorising tool commands and understanding detection. The next labs add network segmentation and an IDS so you can watch traffic, not just host logs.