Wazuh for Enterprises: Architecture, Deployment, and Hardening Guide

Overview

Wazuh is an open-source security operations platform built around endpoint agents, centralized analysis, log collection, threat detection, and compliance monitoring. Enterprises use it to unify host telemetry, detect suspicious activity, monitor configuration drift, and support regulatory controls without committing to a fully proprietary SIEM stack.

Its core value is broad coverage: log analysis, file integrity monitoring (FIM), vulnerability detection, rootkit detection, security configuration assessment, and cloud or container telemetry through integrations. In practice, Wazuh is often used as a cost-efficient detection layer for servers, workstations, and cloud workloads, especially where teams want direct control over rules, decoders, retention, and deployment topology.

Architecture

Wazuh typically consists of four major layers:

• Wazuh agents on Linux, Windows, and macOS endpoints
• Wazuh server/manager for rule processing, alert generation, and agent coordination
• Indexer based on OpenSearch for storage and search
• Dashboard for visualization, investigations, and administration

Common deployment models:

• Single-node for labs or small environments
• Distributed cluster with dedicated manager, indexer, and dashboard nodes
• Hybrid enterprise with on-prem managers and cloud-hosted dashboards or storage

Data flow:

[Endpoints with Wazuh Agent] ---- 1. events/FIM/vuln data ----> [Wazuh Manager Cluster]
[Wazuh Manager Cluster] ---- 2. normalized alerts ----> [Wazuh Indexer]
[Security Analysts] ---- 3. queries/dashboards ----> [Wazuh Dashboard]
[Wazuh Dashboard] ---- 4. search/API ----> [Wazuh Indexer]
[Wazuh Manager Cluster] ---- 5. active response ----> [Endpoints with Wazuh Agent]

For enterprise scale, separate ingestion from storage, place indexers behind load balancers, and use TLS on every hop. Keep agents enrolled to local or regional managers to reduce latency and simplify segmentation.

Implementation Guide

1. Install the Wazuh stack on Ubuntu

curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.7/config.yml
sudo bash wazuh-install.sh --generate-config-files
sudo bash wazuh-install.sh --wazuh-indexer node-1
sudo bash wazuh-install.sh --wazuh-server wazuh-1
sudo bash wazuh-install.sh --wazuh-dashboard dashboard-1

2. Enroll a Linux agent

curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --dearmor -o /usr/share/keyrings/wazuh.gpg
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt-get update
sudo apt-get install wazuh-agent -y
sudo sed -i 's|<address>MANAGER_IP</address>|<address>10.0.10.15</address>|' /var/ossec/etc/ossec.conf
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

3. Enable FIM and vulnerability detection

Edit /var/ossec/etc/ossec.conf on the agent:

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>
  <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin</directories>
  <ignore>/etc/mtab</ignore>
</syscheck>

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Restart the agent:

sudo systemctl restart wazuh-agent

4. Add a custom detection rule on the manager

Create /var/ossec/etc/rules/local_rules.xml:

<group name="local,authentication,">
  <rule id="100100" level="10">
    <if_group>syslog,sshd,</if_group>
    <match>Failed password for invalid user</match>
    <description>SSH invalid user brute-force attempt detected</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

Validate and restart:

sudo /var/ossec/bin/wazuh-logtest
sudo systemctl restart wazuh-manager

Code Examples

# Verify manager and agent health
sudo systemctl status wazuh-manager
sudo systemctl status wazuh-agent
sudo tail -f /var/ossec/logs/ossec.log

# Filebeat-style forwarding example for external pipeline integration
output.elasticsearch:
  hosts: ["https://wazuh-indexer01.example.com:9200"]
  username: "wazuh_ingest"
  password: "REDACTED"
  ssl.certificate_authorities: ["/etc/filebeat/certs/root-ca.pem"]
setup.template.enabled: false

import requests
from requests.auth import HTTPBasicAuth
url = "https://wazuh-dashboard.example.com/api/security/user/authenticate"
r = requests.get(url, auth=HTTPBasicAuth("admin", "StrongPassword!"), verify=False)
print(r.status_code)
print(r.text[:200])

Security Hardening

• Enforce TLS between agents, manager, dashboard, and indexer; rotate certificates through enterprise PKI.
• Restrict dashboard access with SSO, MFA, and role-based access control.
• Isolate manager and indexer nodes in dedicated security zones; only expose required ports such as 1514/udp, 1515/tcp, and dashboard HTTPS.
• Disable unused modules and remove default credentials immediately after installation.
• Forward Wazuh audit logs to a separate immutable store for administrator accountability.
• Use OS hardening on servers: CIS-aligned baselines, EDR, disk encryption, and restricted sudo.

Comparison

Troubleshooting

1. Agent cannot connect to manager

Log sample:

2024/11/18 09:14:22 wazuh-agentd: ERROR: Unable to connect to enrollment service at '10.0.10.15:1515'
2024/11/18 09:14:22 wazuh-agentd: ERROR: Connection refused

Fix:

• Confirm 1515/tcp is open on firewalls and load balancers
• Verify manager service is listening: sudo ss -lntp | grep 1515
• Check agent <address> in ossec.conf

2. Custom rule does not trigger

Log sample:

2024/11/18 10:02:11 wazuh-analysisd: WARNING: Rule ID '100100' duplicated. Only the first occurrence will be loaded.

Fix:

• Ensure unique rule IDs in local_rules.xml
• Test with wazuh-logtest
• Restart manager after rule updates

3. Indexer authentication failure

Log sample:

[2024-11-18T10:21:44,551][WARN ][o.o.s.a.BackendRegistry] Authentication finally failed for wazuh-server from 10.0.10.20:53412

Fix:

• Revalidate indexer credentials in Wazuh server configuration
• Confirm certificate trust chain and node time synchronization
• Review OpenSearch security plugin mappings

Best Practices

Do

• Segment by function: dedicated nodes for manager, indexer, and dashboard in production
• Tune retention based on alert value, not unlimited storage
• Use custom rules carefully with version control and peer review
• Map alerts to MITRE ATT&CK for triage consistency

Don't

• Don't run all components on one VM for production critical workloads
• Don't expose dashboard or enrollment ports directly to the internet
• Don't enable noisy FIM paths like /var/log realtime monitoring without exclusions
• Don't skip backup and restore testing for index snapshots and manager configs