Wazuh Security Monitoring represents a critical architectural layer in the protection of enterprise assets and industrial control systems within energy, water, and dense network infrastructure. In these high-stakes environments, the transition from traditional signature-based detection to an Integrated Extended Detection and Response (XDR) model is mandatory. Modern tactical environments suffer from excessive noise and alert fatigue; Wazuh addresses this by providing an unified platform for endpoint security, integrity monitoring, and cloud security. For a Lead Systems Architect, implementing this stack ensures visibility into both the logical layer of the operating system and the physical health of industrial assets through log ingestion from logic-controllers and gateway sensors. The central problem in critical infrastructure is the isolation of legacy systems. The Wazuh solution bridges this gap by providing an encapsulation strategy for disparate log formats, transforming raw telemetry into actionable intelligence while maintaining low overhead on the monitored nodes. This manual outlines the rigorous deployment of Wazuh to ensure maximum throughput and minimal latency across the security fabric.
Technical Specifications
| Requirement | Default Port/Range | Protocol/Standard | Impact Level | Recommended Resources |
|:—|:—|:—|:—|:—|
| Wazuh Manager | 1514 (Agent) / 1515 (Auth) | TCP/UDP (TLS 1.2) | 10 | 8 vCPU / 16GB RAM |
| Wazuh Indexer | 9200 (HTTPS) | RESTful API | 9 | 16GB RAM (8GB JVM Heap) |
| Wazuh Dashboard | 443 (HTTPS) | TLS / NIST SP 800-52 | 7 | 4 vCPU / 8GB RAM |
| Agent Enrollment | 1515 | TCP | 8 | 512MB RAM / 2% CPU |
| API High Availability | 55000 | HTTPS | 6 | Load Balancer Managed |
Configuration Protocol
Environment Prerequisites:
Before proceeding with the installation, confirm the environment meets the following baseline requirements:
– Operating System: Ubuntu 22.04 LTS or RHEL 8/9 (64-bit architecture).
– Software: OpenSSL 1.1.1 or higher for secure payload encryption.
– Network: DNS resolution for the wazuh-manager hostname; internal firewall rules allowing bidirectional traffic on specified ports.
– Permissions: sudo or root access on all nodes.
– Clock Sync: NTP or Chrony must be active to prevent timestamp drift, which causes critical failures in event correlation.
Section A: Implementation Logic:
The engineering design of Wazuh relies on a decoupled architecture to ensure that the analysis engine does not become a bottleneck for the data ingestion pipeline. By separating the Indexer (storage), the Manager (analysis), and the Dashboard (visualization), the system gains horizontal scalability. The implementation follows an idempotent methodology: scripts and configuration states can be reapplied without changing the outcome beyond the initial successful application. This setup prioritizes data integrity over raw ingestion speed; we employ a persistent queue on the manager to mitigate packet-loss during spikes in network traffic. Furthermore, in industrial contexts, the system is designed to monitor for signal-attenuation in wireless gateway logs, treating physical layer degradation as a potential precursor to a security breach or hardware failure.
Step-By-Step Execution
Step 1: Initialize Repository and GPG Keys
Execute the command: curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | gpg –no-default-keyring –keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg –import && chmod 644 /usr/share/keyrings/wazuh.gpg.
System Note: This action imports the public key into the system’s trusted keyring. It ensures the integrity of the downloaded binaries by verifying the cryptographic signature at the kernel level during package extraction via apt or yum.
Step 2: Configure the Wazuh Indexer Cluster
Update the indexer.yml file located at /etc/wazuh-indexer/opensearch.yml. Set the network.host variable to the node’s private IP and define the initial cluster manager with cluster.initial_master_nodes.
System Note: This configures the underlying storage engine, assigning specific memory heaps through jvm.options to manage garbage collection. Proper heap sizing is essential to prevent high latency during heavy search queries.
Step 3: Deployment of the Wazuh Manager
Install the manager using apt-get install wazuh-manager. Once installed, enable the service with systemctl enable wazuh-manager and start it via systemctl start wazuh-manager.
System Note: The manager service initializes the analysis engine logic. It hooks into the system’s process tree to monitor internal health and opens the listeners defined in /var/ossec/etc/ossec.conf.
Step 4: Installation of the Wazuh Dashboard
Run apt-get install wazuh-dashboard. Modify /etc/wazuh-dashboard/opensearch_dashboards.yml to point the opensearch.hosts toward the indexer’s IP address and port 9200.
System Note: This step sets up the Kibana-based interface. It serves as a visual wrapper for the REST API. The service creates an internal socket for proxying requests between the web browser and the indexer cluster.
Step 5: Agent Enrollment and Cryptographic Pairing
On the target endpoint, install the agent and run: WAZUH_MANAGER='[MANAGER_IP]’ apt-get install wazuh-agent. After installation, start the service using systemctl start wazuh-agent.
System Note: The agent generates a unique ID and requests a key from the manager via port 1515. This key is used for the AES encryption of every payload sent to the manager. The agent monitors file changes via the syscheck daemon, which uses an Inotify kernel hook to record modifications in real-time.
Section B: Dependency Fault-Lines:
Installation failures frequently occur at the intersection of network security and library availability. A common bottleneck is the mismatch between the OpenSSL version on the agent and the manager, which leads to immediate connection rejection. If the manager is behind a proxy, the payload may be stripped of its headers, causing a failure in the encapsulation process. Furthermore, if the system’s thermal-inertia is high (frequently seen in fanless industrial PCs), the manager may experience CPU throttling, leading to a backlog in the analysis queue. Ensure that the libssl-dev and libcap2-bin libraries are present to allow the agent to run with the necessary capabilities without requiring full root privileges for every sub-process.
THE TROUBLESHOOTING MATRIX
Section C: Logs & Debugging:
When a component fails, the primary point of reference is the ossec.log file.
– Manager/Agent Logs: /var/ossec/logs/ossec.log
– Indexer Logs: /var/log/wazuh-indexer/wazuh-cluster.log
– Dashboard Logs: /usr/share/wazuh-dashboard/data/wazuh/logs/wazuhapp.log
If the agent status remains “Never Connected”, verify the port visibility using tcpdump -i any port 1514. If packets are arriving but the agent is not active, check for the error string “Process not responding” in the log, which usually indicates a conflict in the syscheck database lock file. For physical fault codes originating from industrial sensors, monitor for the “Input/Output error” or “Remote I/O error” in the system journal via journalctl -u wazuh-agent. These errors often correlate with signal-attenuation in the underlying hardware bus, such as I2C or Modbus, rather than a software failure within Wazuh itself.
OPTIMIZATION & HARDENING
Performance Tuning:
To maximize throughput, the Wazuh Indexer must be tuned for shard management. Avoid over-sharding by keeping shard sizes between 30GB and 50GB. Adjust the analysisd.max_events_per_second setting in the manager’s ossec.conf to match the calculated hardware capacity. Increasing the concurrency of the analysis engine allows for faster processing of complex regex rules, but it increases the CPU overhead. In environments with high event volumes, implement a Load Balancer (such as HAProxy) in front of multiple Wazuh Managers to distribute the cryptographic workload and reduce the processing latency per event.
Security Hardening:
Hardening the Wazuh infrastructure is non-negotiable.
– Disable the default “admin” password immediately using the wazuh-passwords-tool.sh.
– Implement IP-based firewall rules (iptables or ufw) to restrict access to port 1515 only to known deployment subnets.
– Enable File Integrity Monitoring (FIM) on the manager’s own configuration files to detect unauthorized changes.
– Use TLS 1.3 for all internal communication to reduce the handshake overhead and improve security against downgrade attacks.
Scaling Logic:
As the infrastructure expands from hundreds to thousands of endpoints, shift to a multi-node Indexer cluster. Use a dedicated “Worker” node strategy for the Wazuh Manager, where one node acts as the “Master” for configuration sync while others handle log analysis. This ensures that the system remains idempotent across the entire fleet. Monitor the network for packet-loss; if the loss exceeds 1%, consider deploying an intermediate Logstash layer to buffer logs before they reach the manager.
THE ADMIN DESK
Quick-Fix FAQs:
How do I restart the Wazuh stack to resolve minor hangs?
Use the command systemctl restart wazuh-manager followed by systemctl restart wazuh-indexer. This flushes the active memory buffers and restarts the analysis engine. Always verify the status with systemctl status to ensure a clean initialization.
Why is my Wazuh Indexer service failing to start after a reboot?
This is often caused by the JVM not being able to allocate the requested heap memory. Check /etc/wazuh-indexer/jvm.options and ensure the total allocated RAM does not exceed 50% of the available physical system memory.
How do I force an immediate File Integrity Monitoring (FIM) scan?
Execute agent_control -r -u [AGENT_ID] from the manager’s terminal. This forces the agent to bypass its scheduled interval and perform an immediate check of the monitored directories, reporting any checksum mismatches or metadata changes.
What causes delayed alerts in the dashboard?
High latency in the dashboard is usually a result of index congestion or poor query optimization. Verify the index health with curl -XGET “localhost:9200/_cluster/health?pretty” and ensure no indices are in a “red” or “yellow” state.
How do I update the agent’s manager IP remotely?
Update the manager block in /var/ossec/etc/ossec.conf on the agent node. In a managed environment, use an orchestration tool like Ansible to push this change as an idempotent task across the entire network to maintain consistency.
