A homelab that nobody is watching is just a collection of computers waiting for something to go wrong quietly. I wanted to know when something changes, when something strange talks to something else and when something fails to log in forty times in a row.
The answer was not one tool, it was two, joined into one pipeline. Each sees the network from a different angle, and Wazuh sits in the middle of everything.
Two lenses, one pipeline
| Lens | Tool | Question it answers |
|---|---|---|
| Host | Wazuh | What is happening on this machine? |
| Network | Suricata | What is crossing the wire? |
| Hub | Wazuh | Where do logs and alerts all end up, and why |
No single view is enough. An attacker who evades the network sensor still leaves traces on a host. A noisy host log means little without context from the network around it. Overlap is the point, and a single place to look is what makes the overlap usable.
Wazuh: host detection and the central pipeline
Wazuh is the SIEM and host-based detection layer. Agents on my machines report file integrity changes, authentication events, running processes and configuration problems, and the manager matches them against rules.
It is also where logs go. Rather than running a separate log platform, I ship logs to Wazuh and let it be the one place where collection, parsing, correlation and alerting happen. One pipeline means one set of rules to tune, one search interface and one place to look when something is wrong.
What I like most is that it is both a detector and an auditor. Out of the box it tells me about suspicious behaviour, and it also tells me when a machine drifts away from a hardened baseline. That second job pairs nicely with infrastructure as code: if a host changes in a way my automation did not make, I want to know.
Suricata: the wire does not lie
Suricata is the network intrusion detection system. It inspects traffic against a ruleset and raises alerts for known-bad patterns and policy violations, and it records structured metadata about the traffic it sees, which is useful even when nothing is wrong.
I moved to it from another open source IDS, and the reasons were practical: a modern multi-threaded engine, rich structured output that is easy to ingest and good protocol awareness. Host logs can be tampered with by someone who has control of the host. Traffic seen from the outside is much harder to rewrite.
Suricata’s alerts are forwarded into Wazuh, so a network event can be lined up against what the hosts were doing at that moment. That is when the stack stops being two tools and starts being one picture.
Tuning is the job
Here is the honest part: the first week of any new detection tool is a flood. Defaults are written for the average network and mine is not average.
Most of the real work has been tuning:
- suppressing rules that are correct but irrelevant to my environment
- thresholding noisy but legitimate behaviour so it alerts on change, not presence
- adding local rules for the things I actually care about
- reviewing alerts regularly, because a rule nobody reads is not a control
The goal is an alert queue short enough that every item deserves a look. When an alert fires and I feel interested rather than tired, the tuning is working.
Closing the loop
Detection that ends in a dashboard nobody opens is theatre. I have connected the stack to the rest of my tooling, including a read-only MCP server for Wazuh, so I can ask plain-language questions about recent alerts and agent health. High-severity alerts also feed an AI-assisted triage layer, which I describe in Teaching my SIEM to triage itself.
What I would do again
- Overlap your sensors on purpose. Each lens covers the other’s blind spots.
- Centralise early, in one place. You cannot investigate evidence you did not keep, and two pipelines is one too many to tune.
- Budget time for tuning, not just for installation.
- Review regularly. Monitoring is a habit, not a product.