Why I'm Adding Wazuh to My Homelab
I'm building my homelab into a professional-grade security lab, so I wanted a real SIEM-style platform that can ingest logs, detect suspicious activity, and help me learn detection engineering.
Wazuh is a solid fit because it can:
- Monitor Windows/Linux endpoints with agents
- Collect and analyze logs (security events, auth, system changes)
- Do integrity monitoring (watch files/registry for changes)
- Run vulnerability detection (package/software CVEs)
- Map detections to MITRE ATT&CK
- Support dashboards and alerting
This is also a stepping stone toward monitoring more than just the lab — eventually I want agents on my home network devices too.
VM Build: Ubuntu Server for Wazuh
OS Choice
I initially started with Ubuntu 24.04.x but hit package/dpkg issues during setup. To keep the platform stable and predictable, I moved to Ubuntu 22.04.5 LTS, which is a common "safe" baseline in homelabs and enterprise environments.
Proxmox VM Hardware Settings
These settings are geared toward an all-in-one Wazuh install (Indexer + Manager + Dashboard on one VM):
- CPU: 4 vCPU
- RAM: 15 GB
- Disk: 120 GB
- Machine: q35
- BIOS: OVMF (UEFI)
- NIC: VirtIO on the lab bridge (e.g., vmbr1)
- Storage Layout (Ubuntu Installer):
- Entire disk + LVM group (simple and clean)
- /boot and /boot/efi partitions created automatically
- Root volume on LVM
This gives enough headroom for OpenSearch/Wazuh Indexer memory and future growth (more agents, more logs, more retention).
Installing Wazuh (All-in-One)
Wazuh provides an installation assistant script that can deploy the full stack:
- Wazuh Manager (agent management + analysis)
- Wazuh Indexer (OpenSearch-based storage/search)
- Wazuh Dashboard (web UI)
After installation, I verified basic port listeners:
- Agent communications:
1514/tcp(events) - Agent enrollment:
1515/tcp(authd) - Dashboard:
443/tcp
The First Real Problem: Indexer Startup Failing (Timeout)
After install and upgrades, the Wazuh Indexer (OpenSearch) looked like it was "starting forever" and eventually showed:
- Failed to start with result timeout
- Java process would start, but systemd killed it because it didn't become "ready" fast enough
What I Learned
Indexer startup can be slow after upgrades, reboot, index recovery, or shard allocation. This can look like it's "hung" when it's actually doing recovery work.
Fix Strategy
The real solution is to check the indexer logs to ensure it's genuinely progressing, increase the systemd startup timeout if the service is being killed too quickly, and confirm kernel tunables (like vm.max_map_count) are correct for OpenSearch.
Once indexer becomes stable, the rest of the stack behaves normally.
Wazuh Dashboard: Admin Login + Password Reset
After getting into the dashboard, I needed to change credentials. Wazuh ships a password tool for internal users. I tried to change the password from the portal but kept getting errors about the admin resource being reserved.
In order to get around this I jumped back on the terminal and ran:
sudo WAZUH_PATH=/usr/share/wazuh-indexer /usr/share/wazuh-indexer/plugins/opensearch-security/tools/wazuh-passwords-tool.sh --user admin --password "YourNewPasswordHere"
After that I refreshed the terminal and the admin password was updated.
Important note: the tool enforces password complexity:
- 8–64 characters
- must include upper + lower + number + symbol
Onboarding My Windows PC (Agent Install)
Installing the Agent
On my Windows machine, I installed the Wazuh Agent via MSI, then pointed it at my manager's IP. I verified connectivity from Windows.
Version Mismatch: "Agent version must be lower or equal to manager version"
This is a classic gotcha. The agent log showed the agent refuses to connect because the agent is newer than the manager.
Fix: Either upgrade the server to match the agent, or install an agent version that matches the server version.
Once versions match, enrollment and reporting works normally.
Validating the Agent
After restarting the agent service and refreshing Wazuh, the agent appears in the dashboard.
At that point, the fun starts:
- Wazuh begins inventorying the endpoint (syscollector)
- You can see OS details, installed software, network adapters, services
- Alerts populate based on rules and activity
What Wazuh Enables in a Homelab
Here's what I can do now (and what I plan to do next).
1) Endpoint Visibility (Inventory + Health)
- System info (CPU, RAM, disk)
- Installed software inventory
- Running services/process monitoring
- Network interface and connection context
2) File Integrity Monitoring (FIM)
- Detect changes to sensitive paths on Windows/Linux
- Catch unauthorized config changes
- Monitor key folders like:
- Windows: System32, startup folders, critical registry keys
- Linux: /etc, SSH configs, docker compose directories
3) Log Collection + Correlation
- Windows Event Logs (Security, System, Application)
- Authentication events
- Service creation / scheduled task creation
- PowerShell activity (when configured)
4) MITRE ATT&CK Context
Wazuh can map detections and behaviors to MITRE techniques, which is perfect for learning TTP recognition, triage workflows, and improving detection fidelity.
5) Vulnerability Detection (Host-Based)
Wazuh can detect vulnerable packages/software on endpoints, track CVEs by installed version, and help prioritize patching in a structured way.
Results
By the end of this setup, I had a fully functional Wazuh all-in-one deployment running in my Proxmox lab and a Windows endpoint successfully enrolled and reporting.
Concretely, this setup delivered:
- A stable Wazuh server with Manager, Indexer (OpenSearch), and Dashboard running on a dedicated Ubuntu VM
- Verified agent communication over the correct ports (1514 and 1515)
- A Windows agent successfully enrolled and visible in the dashboard
- Real-time endpoint inventory collection (OS, software, services, hardware)
- Continuous log ingestion from the Windows host
- A foundation for file integrity monitoring, vulnerability detection, and behavioral alerts
Just as important as the end result was the operational understanding gained:
- How tightly coupled the Wazuh components are
- How version mismatches between agent and manager immediately break enrollment
- How resource allocation and service startup timing directly impact OpenSearch/Wazuh Indexer stability
- How to read and interpret Wazuh and OpenSearch logs when the UI alone isn't helpful
Instead of a "black box" SIEM, I now have a system I actually understand well enough to troubleshoot, tune, and expand.
Conclusion
Standing up Wazuh in a homelab is more than just installing another service — it's an exercise in real-world security operations.
This deployment reinforced several important lessons:
- SIEM platforms are resource-intensive and unforgiving of shortcuts
- Version control matters just as much for security tooling as it does for applications
- Logs and metrics tell the real story when services appear "stuck" or broken
- A clean network design and segmentation make troubleshooting far easier
With Wazuh now operational, my homelab has moved from "a collection of servers" to an actively monitored environment. I can observe behavior, detect changes, and reason about security events in a way that mirrors professional SOC workflows.
From here, the platform becomes a sandbox for testing detection logic, simulating attack techniques, tuning alerts, and eventually monitoring systems beyond the lab itself.
This setup isn't the end goal — it's the foundation for deeper blue-team skills, better visibility, and a more intentional approach to security engineering.