1. Network isolation |
|
|
Restrict port 1516 to a
management-only network
segment. |
Set firewall rules (iptables or cloud security groups) to block port 1516
from public access. Place cluster nodes on a dedicated VLAN or private subnet. Use a VPN or private network link for clusters that span multiple data
centers. Test connectivity after setup to confirm only trusted nodes can connect.
|
Port 1516 is used by the Wazuh cluster nodes to talk to
one another. Exposing it publicly gives attackers a direct path into
your cluster. Network segmentation limits the blast radius if one part of your
environment is compromised.
|
2. Cluster key management |
|
|
Treat the cluster key like a
root password to protect it. |
Generate keys using a cryptographically secure method (e.g., openssl rand). Use a different key for each environment: production, staging, and
development. Lock down file permissions so only the Wazuh service account can read the key
file. Store the key in a secrets manager (e.g., HashiCorp Vault, AWS Secrets
Manager). Rotate the key on a scheduled basis and after any staff changes. Never commit the key to a version control system (Git).
|
The cluster key authenticates nodes to each other. Anyone who has it
can impersonate a node or intercept cluster traffic. Separate keys per environment will prevent a breach in one
environment from compromising the other.
|
3. Node hardening |
|
|
Secure cluster nodes as
critical infrastructure. |
Keep the OS and all packages up to date with security patches. Enable mandatory access controls: SELinux (RHEL/CentOS) or AppArmor
(Ubuntu/Debian). Restrict SSH: disable root login, use key-based auth only, limit which IPs can
connect. Enable audit logging to track who does what on each node. Install a host-based intrusion detection system (e.g., OSSEC, auditd). Disable or remove services and software that Wazuh does not need. Where possible, run Wazuh on dedicated servers - not shared with other
applications.
|
Cluster nodes hold sensitive security event data and control your
detection capabilities. A compromised node undermines your entire
SIEM. Ensuring defense in depth, so that if an attacker gets past your
network controls, hardened nodes slow them down.
|
4. Monitoring and alerting |
|
|
Monitor cluster communication
for anomalies. |
Alert on unexpected connections to port 1516 from unknown sources. Track and alert on repeated authentication failures between nodes. Monitor for node disconnections, especially unexpected ones. Log and review any configuration changes to cluster settings. Use Wazuh rules or custom rules to monitor the cluster logs (e.g.,
/var/ossec/logs/ossec.log, /var/ossec/logs/cluster.log).
|
Your security monitoring system is itself a high-value target.
Attackers who compromise it can blind you from other security
events. Early detection of cluster anomalies lets you respond before damage
is done.
|