Wazuh SIEM: Open-Source XDR for a Home Lab or Small Team

I have written a lot here about offensive tooling and almost nothing about the other side of the desk. Wazuh SIEM is where I would start if you want to detect the things those tools do, rather than only run them. It is free, it runs on hardware you already own, and it gives you log collection, file integrity monitoring and endpoint response in one stack.

Where Wazuh SIEM sits in a defensive stack

Wazuh is three moving parts. An agent runs on each endpoint and ships logs and telemetry to the manager. The manager decodes each event, matches it against a rule set and raises an alert. The indexer (an OpenSearch fork) stores alerts, and the dashboard queries them. You get more than log search out of the box:

• File integrity monitoring, with real-time inotify watches on Linux
• Security configuration assessment against CIS benchmarks
• A vulnerability detector that correlates installed packages against CVE feeds
• Active response, so a rule can fire a script that firewalls an attacking IP
• MITRE ATT&CK mapping on most built-in rules

That vulnerability detector is inventory-based, not an active scan. It tells you the box has a vulnerable openssl package; it will not tell you whether a service is exploitable from outside. For that you still want something like Nuclei pointed at your own estate. The two answer different questions.

Installing Wazuh with Docker

The single-node Docker deployment is the fastest honest install. Do not use the all-in-one script on a box you care about; the container stack is easier to throw away.

git clone https://github.com/wazuh/wazuh-docker.git -b v4.9.2
cd wazuh-docker/single-node
docker compose -f generate-indexer-certs.yml run --rm generator
docker compose up -d
docker compose ps

The dashboard comes up on https://<host> with a self-signed certificate. Change INDEXER_PASSWORD and DASHBOARD_PASSWORD in docker-compose.yml before you expose it to anything, including your own LAN. The defaults are published in the documentation.

Getting an agent reporting

curl -sO https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.2-1_amd64.deb
sudo WAZUH_MANAGER='192.168.1.50' WAZUH_AGENT_NAME='lab-web01' \
  dpkg -i ./wazuh-agent_4.9.2-1_amd64.deb
sudo systemctl daemon-reload
sudo systemctl enable --now wazuh-agent

An agent with the stock config is already useful, but two additions in /var/ossec/etc/ossec.conf buy you most of the value:

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/auth.log</location>
</localfile>

<syscheck>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" realtime="yes">/var/www</directories>
</syscheck>

A real alert, start to finish

Point a few failed SSH logins at the agent and watch /var/ossec/logs/alerts/alerts.json on the manager. This is what a genuine brute-force correlation looks like, trimmed for width:

{
  "timestamp": "2026-09-14T21:04:11.882+0100",
  "rule": {
    "level": 10,
    "id": "5712",
    "description": "sshd: brute force trying to get access to the system.",
    "frequency": 8,
    "mitre": { "id": ["T1110"], "technique": ["Brute Force"] }
  },
  "agent": { "id": "003", "name": "lab-web01" },
  "data": { "srcip": "45.134.26.7", "srcuser": "admin" }
}

The detail that matters is frequency. Rule 5710 fires on every single failed login at level 5, which is noise. Rule 5712 only fires when 5710 matches eight times inside the configured window, and that composite is the thing worth alerting a human about.

Tuning out the false positives

Never edit the shipped rules in /var/ossec/ruleset/rules; they are overwritten on upgrade. Put overrides in /var/ossec/etc/rules/local_rules.xml and set level 0 to silence a match without deleting the underlying logic.

<group name="local,syslog,sshd,">
  <rule id="100010" level="0">
    <if_sid>5710</if_sid>
    <srcip>192.168.1.0/24</srcip>
    <description>Ignore failed SSH logins from the lab subnet</description>
  </rule>
</group>

Restart the manager with docker compose restart wazuh.manager and test the decoder chain with /var/ossec/bin/wazuh-logtest before you trust it. Pasting a raw log line into logtest and watching which rule wins is the single most useful habit when you start writing detections rather than consuming them.

Honest resource requirements

• 4 GB RAM is the absolute floor and it will swap. 8 GB is where the stack stops annoying you.
• The indexer is the expensive part. Pin its heap with OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g or it will take half the box.
• Budget 50 GB of disk for a handful of agents and set an index lifecycle policy. Alert indices grow quietly until they do not.
• Each agent costs roughly 30 MB of RAM and negligible CPU, except during a full FIM baseline scan.

Would I run it at home?

Yes, and it is the first blue-team tool I would install. Nothing else gets you endpoint telemetry, FIM and a searchable alert history for the price of one spare mini PC. Give it a week of tuning before you judge the signal, because a fresh install is loud by design. Once it is quiet, the alerts that do arrive are worth reading, and that is the point where you can start on real threat hunting and detection engineering instead of just watching a dashboard.