Wazuh SIEM on Raspberry Pi (Homelab)

How I built a small Wazuh deployment on a Raspberry Pi to collect logs from my homelab, generate alerts, and start thinking like a SOC analyst.

Wazuh Homelab Blue Team SIEM
Date: 2026
Focus: Detection, logging, alerting

1. Goal and high-level design

I wanted a small SIEM stack I could break and fix without touching production. The goal was:

  • Run the Wazuh manager on a Raspberry Pi.
  • Forward logs from a few lab systems (Linux + Windows).
  • Create at least one meaningful alert that would matter in a real SOC.
Architecture (simple):
  • Raspberry Pi → Wazuh manager + API + dashboard
  • Lab endpoints → Wazuh agents sending OS, auth, and security logs

2. Installation notes (Pi)

I followed Wazuh's official install docs, but a few Pi-specific things mattered:

  • Hardware: Raspberry Pi 4 Model B.
  • OS: Ubuntu Server LTS for Raspberry Pi.
  • Made sure the Pi had enough resources (at least 4 GB RAM recommended for small labs).
  • Kept the OS fully updated before installing Wazuh.
  • Used the Wazuh all-in-one install for a simple manager + dashboard setup.
# OS update first
sudo apt update && sudo apt full-upgrade -y

# (Pseudo) Wazuh install command
# Actual command depends on the current Wazuh docs / repo
curl -sO https://packages.wazuh.com/4.x/install.sh
sudo bash install.sh
Lesson learned: treat the Pi like a real server. Updates, firewall, and resource limits matter even for "just a lab" when you're running a SIEM.

3. Adding agents and log sources

Once the manager was up, I added real endpoints I actually use day-to-day:

  • My MacBook (for auth, sudo, and system events).
  • My Windows laptop (for logon events and basic security logs).

From the Wazuh UI, I generated agent install commands for each host and verified they were checking in:

# Example (Linux agent)
sudo wazuh-agent-4.x.deb
sudo systemctl enable --now wazuh-agent

4. Example detection: suspicious SSH brute-force

To prove the stack was actually useful, I simulated a noisy SSH brute-force attempt against a lab box and watched how Wazuh handled it.

  • Generated multiple failed SSH logins from a single source IP.
  • Verified the events landed in Wazuh as auth failure logs.
  • Tuned the rule threshold so a burst of failures would trigger an alert.
# Simple brute-force simulation from another host
for i in {1..20}; do
  ssh invaliduser@lab-host "exit" || true
done

In the Wazuh dashboard I looked for an alert similar to: 

Rule: 5710 (level 10) - Multiple SSH authentication failures.
SrcIP: 192.168.x.x
User: invaliduser
Location: /var/log/auth.log
Why this matters for SOC work: this is the same pattern you see behind real brute-force alerts in enterprise SIEMs. Building it in homelab form forces you to understand where the logs come from and how thresholds work.

5. What I’d do next

  • Add file integrity monitoring (FIM) rules for sensitive directories.
  • Ingest logs from a small web app (e.g., Nginx + app logs) and build HTTP-focused rules.
  • Pair Wazuh data with a real incident response scenario (e.g., phishing → initial access → privilege escalation) and write that up end-to-end.

The point of this project isn’t that Wazuh on a Pi is production-ready — it’s that I can practice the full flow: collect logs, tune rules, and interpret alerts like a SOC analyst.