Wazuh: bringing a SOC home

May 17, 2026

Somewhere around the time you spin up your tenth self-hosted service, a quiet question starts forming: who’s watching all this? You’ve got a reverse proxy, a secrets manager, a Git server, a monitoring stack — each one a potential entry point. You know the threat model is different from a Fortune 500, but you’d still like to know if something weird is happening before you find out the hard way.

That’s where a SIEM enters the picture.

What is a SIEM, in plain language?

SIEM stands for Security Information and Event Management, which is a mouthful that mostly means: a system that collects logs from everything, looks for patterns that suggest trouble, and gives you a single place to investigate.

Every service on your network is generating events — logins, file changes, process starts, failed connection attempts. Most of the time those events go nowhere. A SIEM is the thing that actually reads them, correlates them across systems, and fires an alert when the combination looks suspicious. Think of it as a security analyst that never sleeps and reads faster than any human.

A mature SIEM platform typically adds a few more capabilities on top of raw log aggregation:

• Intrusion detection (IDS): rules and heuristics that flag known-bad behavior patterns
• File Integrity Monitoring (FIM): alerts when important files change — system binaries, configuration files, /etc/passwd, and so on
• Vulnerability assessment: periodic scanning that tells you which of your services are running software with known CVEs
• Compliance dashboards: pre-built views mapping your environment against frameworks like PCI-DSS, HIPAA, or CIS benchmarks (less relevant at home, but useful if you run a small business or want to learn the frameworks)

The problem it solves

Without a SIEM, your logs are scattered. Server A’s auth log lives on server A. The web proxy’s logs are on the proxy host. Your secrets manager logs to a file somewhere else. To investigate anything, you’re SSHing into machines one at a time, reading logs with different formats, trying to mentally stitch together a timeline. That’s miserable when you’re doing it on purpose; it’s catastrophic in an actual incident when every minute matters.

Centralized log collection fixes the where are the logs problem. The detection layer fixes the would I even notice problem. A homelab without centralized logging is one where you’ll typically find out about compromises weeks later, if at all — often from a downstream service, a friend who noticed odd traffic, or a canary that happened to be watching the right thing.

There’s also the learning angle. Running a SIEM at home is one of the best ways to understand how enterprise detection actually works. Tuning rules, learning what normal looks like, and chasing down false positives teaches you more than any cert course. Security engineers who have run their own SIEM arrive at work interviews with practical intuitions that classroom-only candidates don’t have.

What the enterprise uses

Enterprise security teams generally land in one of two camps: the big SIEM platforms, and the endpoint detection vendors.

Splunk is the canonical enterprise SIEM. It’s extremely capable, battle-tested, and priced accordingly — licensing historically runs into six or seven figures per year for a large organization. A “Splunk admin” is a full-time job title, and organizations often have multiple of them. The free tier caps ingest volume low enough that it doesn’t translate to a real home environment, and the enterprise pricing is firmly out of reach for personal use.

⚠️ Unverified: Splunk’s current pricing model and tier limits — Cisco acquired Splunk in 2024 and pricing details shift frequently. Check Splunk’s current licensing directly.

Microsoft Sentinel is the cloud-native SIEM for Azure shops. If your workloads live in Microsoft 365 and Azure, it integrates deeply — you can pull sign-in logs, defender alerts, and activity logs with very little configuration. Ingestion pricing is more accessible than Splunk. It still isn’t free, it’s cloud-dependent by design, and it has essentially zero integration story for a self-hosted Linux stack.

CrowdStrike Falcon is more EDR (Endpoint Detection and Response) than SIEM — it lives on the endpoint rather than aggregating logs from a central server. Its threat intelligence and behavioral detection are industry-leading, and it’s what a lot of enterprise security teams reach for when they want host-level visibility. But it’s priced for corporate security budgets, its deployment model assumes managed endpoints, and it isn’t designed for the mix of Docker containers and custom Linux VMs that characterize a homelab.

⚠️ Unverified: CrowdStrike Falcon’s current pricing tiers — confirm at crowdstrike.com; enterprise pricing changes frequently.

For a homelab, none of these are the right tool. They’re either priced out of reach, locked to cloud infrastructure, or designed for IT departments with dedicated staff. The commercial tools solve real problems at scale, but they’re not designed for a self-managed environment where you control the whole stack.

The self-hosted options

When you go looking for open-source alternatives, a few names come up consistently:

Security Onion is a full network security monitoring distribution. It bundles Zeek (for network traffic analysis), Suricata (for IDS), and an Elastic stack for storage and search. It’s powerful but heavyweight — it’s really designed to run on dedicated hardware sniffing network traffic. For a VM-based homelab where you care more about host-level events than packet inspection, it’s more than you need.

ELK stack (Elasticsearch, Logstash, Kibana) + custom rules is the DIY approach. You can absolutely build a log aggregation and search system with these tools, and many teams do. The catch is that you’re also building all the detection logic yourself. Every rule, every alert, every dashboard starts as a blank page. The maintenance burden compounds quickly.

Wazuh is the one that hits the sweet spot for most homelab operators. It’s a purpose-built security platform — not a generic log aggregator you have to turn into a SIEM. It ships with a manager, an indexer (built on OpenSearch, the open-source Elasticsearch fork), and a dashboard. Agents go on each host and report back. The detection rules, FIM configuration, vulnerability scanning, and compliance dashboards are all included and maintained by the Wazuh team. You’re not starting from scratch.

Wazuh has strong roots in OSSEC, the long-running open-source host intrusion detection project, but it’s grown well beyond it — active development, modern UI, solid documentation, and a genuinely useful free tier for self-hosted deployments.

How it fits in this lab

This lab runs Wazuh as a containerized single-node stack — the manager, indexer, and dashboard all on one dedicated VM using Docker Compose. That single-node deployment is appropriate for a homelab; a production enterprise would run the indexer in a cluster for redundancy and throughput, but at home scale you don’t need that overhead.

The platform is deployed via Ansible, which means adding Wazuh to a new VM is a matter of running a playbook. The agent gets installed, registers with the manager automatically, and starts shipping events within a few minutes.

Coverage across the lab includes the services that most warrant watching: the reverse proxy (which faces the internet), the secrets manager, the internal Git server, the automation control node, and various supporting services. Every one of those has a Wazuh agent. When a file changes in a monitored directory, when an SSH login fails multiple times in a row, when a process starts that shouldn’t be running — the manager sees it and can fire an alert.

One wrinkle worth knowing about: Wazuh’s indexer is built on OpenSearch, which uses glibc internals that require a slightly modern x86-64 CPU feature set. If you’re running it in a virtual machine with an older emulated CPU type, the indexer will crash immediately on start with a cryptic error. Switching the VM’s CPU type to expose the right instruction set extensions fixes it. The Wazuh documentation covers this, but it’s the kind of thing that can eat an afternoon if you don’t know to look for it.

A few operational notes that come up when you actually run this:

• The password-change flow for the OpenSearch admin user is not a standard REST API call — it requires running a security tool inside the container. The dashboard and API users do expose normal API endpoints. This isn’t a dealbreaker, just a wrinkle to know about before you go looking for a simple settings page.
• Default credentials are a bad starting point. Change them before the service touches the network.
• Log retention is a disk planning question. The indexer stores everything, and a busy lab generates more events than you might expect. Figure out your retention policy before you start, not after the disk fills.

Who should run this?

Run Wazuh if:

• You have more than a handful of VMs or containers and want to know what’s actually happening across them
• You expose any services to the internet, even through a reverse proxy or tunnel
• You want to learn how enterprise security monitoring works from the inside
• You care about file integrity — knowing when configuration files change is surprisingly valuable
• You run anything that handles credentials, financial data, or anything a family member trusts you with

Skip it (for now) if:

• You’re just getting started with self-hosting and your stack is still small and simple
• You don’t have the VM resources to spare — the single-node stack needs a couple of dedicated cores and a few gigabytes of RAM to run comfortably
• You’re not ready to commit to tuning it — an untuned SIEM will alert on everything and nothing will feel meaningful. Budget some time to work through the false positives

The resourcing point deserves emphasis. Wazuh isn’t light. The indexer in particular is memory-hungry, and OpenSearch has opinions about memory settings at the OS level. Plan for a dedicated VM with enough headroom, and you’ll have a smooth experience. Cram it into leftover resources and it’ll give you grief.

Closing thought

There’s something clarifying about seeing your whole lab’s security posture in one place. The first time Wazuh catches something — an unexpected login, a configuration file that changed when it shouldn’t have, a vulnerability scan that surfaces a service running an outdated package — it makes the investment feel obvious in retrospect.

Security monitoring isn’t the most exciting part of running a homelab. It doesn’t feel as immediately satisfying as spinning up a new service or finishing a new automation. But it’s the part that means you find out about problems on your terms, with enough context to actually respond, rather than discovering something went wrong when someone else tells you.

Running a SIEM at home won’t make you paranoid. It’ll just make you informed.

← all posts