Detection at Home: Building a SIEM with Security Onion and Wazuh

The home cybersecurity lab guide names detection as the module most self-taught practitioners skip — and I’d stand by that even more strongly after actually writing up the full setup. The offensive modules (CTF practice, malware analysis) get all the attention because they’re visibly active: you run an exploit, you get a shell, you watch a sample detonate. Detection is quieter. You build it, and then mostly what you get back is silence, punctuated by the occasional alert that turns out to be nothing. That quiet is exactly why it’s the module that teaches you the most about how security actually works in practice, and exactly why almost nobody builds it voluntarily.

This is the full walkthrough the pillar guide pointed to but didn’t have room for: getting Security Onion running as your network sensor, understanding what it actually shows you, adding Wazuh alongside it for the host-based side Security Onion doesn’t cover, and — the part every SIEM tutorial skips — what to do about alert volume once you have both running.

Why Network Monitoring and Host Monitoring Are Different Problems

The distinction that took me longer than it should have to internalize: a network sensor and a host agent answer different questions, and you need both to get a complete picture.

Security Onion watches traffic. It sits as a passive tap (or inline, if you want it blocking as well as watching) and sees everything that crosses the wire — a port scan, a suspicious DNS query, a C2 beacon, lateral movement between VLANs. What it can’t see is what’s happening inside a host that never generates unusual traffic — a process injection, a registry persistence mechanism, a local privilege escalation that never touches the network.

Wazuh watches hosts. An agent runs on each machine you want visibility into and reports file integrity changes, process execution, log events, and configuration drift back to a central manager. It catches the host-level activity Security Onion is blind to, but it only sees machines you’ve actually installed the agent on — anything unmanaged is invisible to it by definition.

Run only Security Onion and you’ll catch network-visible attacks but miss anything that stays local to a compromised host. Run only Wazuh and you’ll catch host-level compromise on your managed machines but miss anything happening on devices you haven’t instrumented — which, in a home lab, is usually most of your IoT and personal-device traffic. The pillar guide’s own network segmentation setup is what makes Security Onion’s view actually useful here — without VLAN separation, “watch the network” just means watching one big undifferentiated broadcast domain.

Security Onion: The Network Layer

Security Onion bundles Zeek (network metadata and protocol logging), Suricata (signature and anomaly-based IDS), and an Elasticsearch/Kibana stack for storage and search into a single distribution that’s genuinely closer to “download and mostly-configured” than anything else in this space.

Deployment shape. For a home lab, a standalone install (all components on one box) is the right starting point — the distributed manager/sensor/search-node architecture Security Onion supports is built for enterprise deployments monitoring multiple network segments, and it’s needless complexity for a single-location lab. 16GB RAM and a decent multi-core CPU is a realistic minimum if you want Kibana to stay responsive while Suricata and Zeek are both actively processing traffic; 8GB will technically run but you’ll spend more time waiting on searches than looking at results.

Getting traffic to it. This is the part every quickstart glosses over. Security Onion needs a copy of your traffic, which means either a SPAN/mirror port on your managed switch (configure the switch to copy traffic from your other ports to the one Security Onion’s monitoring interface is plugged into) or, if your firewall supports it, a packet capture interface fed directly from the firewall. On the OPNsense setup from the segmentation guide, this is a straightforward interface configuration; on a consumer switch without SPAN port support, you’re limited to what you can capture from a single segment at a time, which is a real argument for the managed-switch recommendation elsewhere on this site.

What you’ll actually see. Once traffic is flowing, Kibana’s default dashboards surface DNS query logs, HTTP/TLS connection metadata, file transfers Zeek extracted from the wire, and Suricata alerts matching its signature set. The Suricata alerts are the least useful output on day one — a stock Emerging Threats ruleset generates a meaningful volume of alerts on totally benign traffic (this is the alert-fatigue problem, covered below). The Zeek connection and DNS logs are more immediately valuable: they let you answer “what did this host actually talk to” without needing to know in advance what you’re looking for.

Wazuh: The Host Layer

Wazuh runs as a manager (the central collection and analysis point) plus lightweight agents installed on whichever hosts you want visibility into — your lab VMs, your CTF practice machines, and arguably your actual daily-use machines if you want real coverage rather than just lab coverage.

What it catches that Security Onion doesn’t. File integrity monitoring (alerting when specific files or directories change — the classic use case is catching a webshell dropped on a compromised web server, or unexpected changes to system binaries). Log-based detection across the OS’s own event logs (Windows Event Log, Linux auth logs) for things like failed login patterns, privilege escalation attempts, and scheduled task creation. Rootkit and malware signature scanning at the host level, independent of anything visible on the wire.

Setup reality. The manager install is straightforward (Docker Compose deployment is the fastest path, a native install is more involved but more controllable). The agent side is where the actual work is — you’re installing and configuring an agent on every machine you want covered, and the value of the whole system scales with how thoroughly you do that. A Wazuh deployment with three agents installed gives you visibility into exactly three machines. This sounds obvious written down; in practice it’s the single biggest reason home Wazuh deployments underdeliver — people install the manager, add one or two agents, and then the coverage gap does the rest of the damage silently.

The Alert Fatigue Problem Nobody Warns You About

Here’s the part that isn’t in most Security Onion or Wazuh tutorials, and it’s the thing that actually determines whether your detection module gets used or quietly ignored after week two.

Out of the box, both tools generate a genuinely uncomfortable volume of alerts. Suricata’s default Emerging Threats ruleset fires on a lot of traffic that is completely normal for a home network — smart TVs phoning home, routine TLS handshake patterns, DNS queries to ad-tech domains that happen to match a signature written for something else entirely. Wazuh’s default ruleset similarly surfaces a lot of routine system activity (package updates, scheduled maintenance tasks, normal log rotation) as at least low-severity events.

The honest first-week experience: you turn everything on, get a wall of alerts, decide none of it is meaningful, and either tune it into silence or stop looking at the dashboard. Both outcomes defeat the purpose.

What actually works: spend the first week doing nothing but suppressing and tuning, not detecting. Go through the alert volume, identify what’s routine noise specific to your environment (your smart TV’s phone-home behavior, your NAS’s backup schedule, whatever your specific device mix generates), and write suppression rules for exactly those patterns — not broad categories, the specific signatures matching your specific known-benign traffic. This is tedious and it is the actual job. A tuned system with twenty alerts a day you can meaningfully evaluate is worth more than an untuned system with two thousand you’ve learned to ignore.

Where This Compounds With the Rest of the Lab

The most useful exercise once both systems are running: attack your own CTF or malware-analysis lab traffic on purpose and watch what it looks like from the detection side. Run an Nmap scan against a vulnerable target on your CTF VLAN and watch it show up in Suricata. Run a Metasploit exploitation attempt and watch the resulting process activity surface in Wazuh’s agent on that target VM, if you’ve installed one. Detonate a malware sample in your sandbox and watch its network callback attempt get logged by Zeek even if Suricata doesn’t have a signature for the specific C2 infrastructure.

This is where detection stops being an abstract “monitor everything” exercise and becomes pattern recognition — you start to know what your own attacks look like from the defender’s seat, which is a different and complementary skill from knowing how to run the attacks in the first place.

What I’d Do Differently

I ran Security Onion for about two months before I added Wazuh, treating network visibility as sufficient on its own. It isn’t. The gap became obvious the first time I deliberately left a persistence mechanism on a compromised lab VM as a self-test and realized Security Onion had nothing to say about it — the persistence mechanism itself generated no network traffic at all. That’s the exact host-vs-network gap described above, and I’d install both from the start if I were rebuilding today rather than treating Wazuh as an optional add-on.

The alert-tuning week is also something I skipped originally and paid for later. I ran an untuned Suricata instance for close to a month, decided the alert volume was useless noise, and nearly turned the whole thing off before I forced myself to actually go through and tune it properly. Once tuned, the same system became genuinely useful within days. If you do one thing differently than I did, budget that tuning week explicitly instead of treating it as optional cleanup you’ll get to eventually.

Is This Actually Worth Running at Home?

Honest answer: not for everyone, and not from day one. If you’re still building out the offensive and malware-analysis modules, detection is reasonably deferred — it has the least payoff until you have something worth detecting against. Where it earns its keep is once you have a working CTF practice environment and want to close the loop between attacking and defending, or if blue-team and detection engineering work is actually part of your career direction rather than a side interest. The resource cost is real (a dedicated 16GB+ box, ideally, rather than squeezed onto hardware doing other lab duty) and the tuning-week time cost is real. Go in expecting both.

Sources:

1. Security Onion documentation — https://docs.securityonion.net/
2. Wazuh documentation — https://documentation.wazuh.com/
3. Zeek documentation — https://docs.zeek.org/
4. Suricata rule documentation, Emerging Threats — https://rules.emergingthreats.net/