The Watchtower: Deploying Fleet-Wide Security Monitoring with Wazuh SIEM
Category: Cybersecurity / SIEM / Infrastructure Architecture / Compliance
Introduction
A fleet without a watchtower is flying blind.
Before this deployment, security monitoring across the Alliance was reactive, checking logs manually after something felt off. That's not a security posture. That's hope. The objective: deploy a centralized SIEM platform capable of real-time threat detection, file integrity monitoring, and compliance assessment across every node in the Proxmox cluster.
The tool: Wazuh an open-source security platform that combines endpoint monitoring, log analysis, vulnerability detection, and regulatory compliance into a single manager-agent architecture.
Architecture Decision
Wazuh runs as a dedicated deployment on Node B (CR90 Corvette, QCM1255) the data and operations node. This placement is intentional:
Why Node B? Node B runs on ECC memory specifically because it hosts the data pipeline. Wazuh's log analysis, FIM databases, and vulnerability inventories are data-integrity-critical workloads. A silent bit-flip in a security alert or agent enrollment record could corrupt the entire trust chain. ECC eliminates that risk class.
Why not a separate VM? The Wazuh Manager is installed directly on the node hosting InfluxDB and Grafana, consolidating the observability and security control plane. This reduces network hops for internal telemetry and simplifies backup procedures. One snapshot captures the full monitoring stack.
Core Capabilities
The Watchtower processes telemetry through four logic engines, each tied to a specific operational requirement:
Log Data Analysis Collects and analyzes logs from all three Proxmox hypervisors. Identifies patterns like brute-force attempts at the gateway, unauthorized shell access, and failed authentication across services.
File Integrity Monitoring (FIM) Monitors critical system directories (/etc, /usr/bin, /var/ossec) for unauthorized changes. A modification to these paths on any node triggers an immediate high-severity alert.
Vulnerability Detection Automatically inventories installed packages across the Fleet and cross-references them against the National Vulnerability Database (NVD) to surface unpatched CVEs.
Security Configuration Assessment (SCA) Scans Proxmox hosts against CIS hardened benchmarks to identify misconfigurations before they become attack vectors.
Fleet Enrollment
All three nodes are actively reporting to the Watchtower:
| Agent | Node | Codename | Enrollment Method |
|---|---|---|---|
| 001 | Node A | Millennium Falcon | Manual — dependency remediation required |
| 002 | Node C | Gozanti Cruiser | Standard — renamed post-enrollment for documentation consistency |
| 003 | Node B | CR90 Corvette | Host-level — agent installed on physical hypervisor layer |
Why enroll the Wazuh host itself? Full-spectrum monitoring of the hypervisor layer is a non-negotiable security control. By installing an agent on the physical host running the manager, we ensure the underlying infrastructure is under active surveillance, not just the workloads it serves.
Network Requirements
Wazuh's agent-to-manager communication requires specific ports to be open across the VLAN topology. These are mapped through the UniFi Dream Machine's inter-VLAN firewall rules:
| Port | Protocol | Service | Direction | Purpose |
|---|---|---|---|---|
| 1515 | TCP | wazuh-authd | Fleet → Manager | Secure enrollment — initial handshake and RSA key exchange |
| 1514 | TCP | wazuh-remoted | Fleet → Manager | Data streaming — encrypted channel for all log, FIM, and inventory data |
| 55000 | TCP | wazuh-api | Management → Manager | Orchestration — administrative tasks and n8n integration |
Professional Rationale: These port mappings are explicitly defined in the firewall rather than using broad allow rules. Each port serves a documented function. If the threat response automation pipeline (n8n) is ever compromised, the blast radius is limited to port 55000, it cannot pivot to agent enrollment or data streaming channels.
Deployment Command Reference
Standardized enrollment sequence used across all Fleet nodes:
# Update package index and install dependencies
apt-get update && apt-get install lsb-release -y
# Set manager target and agent identity
export WAZUH_MANAGER='192.168.10.31'
export WAZUH_AGENT_NAME='[Node-Codename]'
# Clean install (remove any prior agent state)
apt-get purge wazuh-agent -y
dpkg -i ./wazuh-agent_4.14.1-1_amd64.deb
# Harden configuration, force manager address
sed -i 's/<address>.*<\/address>/<address>192.168.10.31<\/address>/g' /var/ossec/etc/ossec.conf
# Fix permissions and restart
chown -R wazuh:wazuh /var/ossec
systemctl daemon-reload
systemctl restart wazuh-agent
Verification Commands
Post-deployment health checks run from the Wazuh Manager:
# Verify manager internal health and module status
/var/ossec/bin/wazuh-control info
# Check API readiness
curl -u admin:admin -k -X GET "https://localhost:55000/ready?pretty=true"
# Review active agent list with last keep-alive timestamps
/var/ossec/bin/agent_control -l
What to look for: All three agents should show status='connected' with keep-alive timestamps within the last 30 seconds. A stale timestamp indicates a network path issue, check the inter-VLAN firewall rules for ports 1514 and 1515.
What's Next
The Watchtower is operational, but deployment is just the foundation. The upcoming work:
- Custom detection rules: Expanding beyond default rulesets to catch patterns specific to the Fleet's architecture (Proxmox API abuse, Tailscale ACL violations, Authentik brute-force attempts)
- n8n integration: Automated threat response pipeline: Wazuh alert → n8n webhook → firewall alias block → Discord notification
- Grafana dashboards: Visualizing Wazuh alert trends alongside the existing Telegraf/InfluxDB resource telemetry for a unified operational view
Professional Rationale
The primary rationale for this deployment is operational resilience. Security through obscurity is not a strategy. The Watchtower ensures that every system call on the Millennium Falcon, every configuration change on the Gozanti Cruiser, and every login attempt on the CR90 Corvette is accounted for, audited, and secured.
This is the same monitoring posture expected in enterprise environments, the difference is that here, I built it from scratch and can explain every decision.
Skills Demonstrated: Wazuh SIEM · Agent-Manager Architecture · Network Security · Firewall Policy · CIS Benchmarking · Vulnerability Management · Infrastructure Documentation
Related: Alliance Homelab Infrastructure · Technical Writeups