Wazuh Components - Agent, Server, Indexer, Dashboard
The Wazuh platform consists of four primary components: the agent, the server (manager), the indexer, and the dashboard. Each component is designed to fulfill a specific function in the security data processing pipeline. This page provides a detailed description of every component, its modules, supported platforms, and network requirements.
Wazuh Agent
The Wazuh Agent is a lightweight application installed on monitored endpoints: servers, workstations, virtual machines, and cloud instances. It collects security data and forwards it to the Wazuh server for analysis.
Agent Modules
The agent includes a set of specialized modules, each responsible for a specific aspect of security monitoring.
| Module | Function | Description |
|---|---|---|
| Log Collector | Log collection | Reads system and application logs (syslog, Windows Event Log, macOS ULS, JSON, multiline formats) |
| File Integrity Monitoring | Integrity monitoring | Tracks file creation, modification, and deletion. Supports YARA integration for malware detection |
| Syscollector | Inventory | Collects data about the OS, hardware, installed packages, open ports, network interfaces, and running processes |
| SCA | Configuration assessment | Evaluates system configuration against CIS Benchmark policies and custom rules |
| Vulnerability Detector | Vulnerability detection | Matches installed software against CVE databases (NVD, Red Hat, Canonical, Microsoft) |
| Rootcheck | Rootkit detection | Checks for rootkits, hidden processes, suspicious files, and kernel anomalies |
| Command Monitoring | Command monitoring | Periodically executes commands and analyzes their output (e.g., service state checks) |
| Active Response | Active response | Executes actions on the agent as instructed by the server: IP blocking, process termination, file quarantine |
| Docker Listener | Docker monitoring | Tracks Docker Engine events: container creation, start, stop, and configuration changes |
Server Communication
The agent maintains a persistent connection with the Wazuh server:
- Event transmission - TCP port 1514, AES-256 encryption
- Registration - TCP port 1515, TLS authentication
- Management - centralized configuration through shared configuration
- Upgrades - remote agent updates via WPK (Wazuh Package)
The agent operates with minimal resource consumption and adjusts scanning intensity based on current system load.
Supported Operating Systems
The Wazuh Agent supports a broad range of operating systems.
| OS Family | Supported Versions |
|---|---|
| Linux | Amazon Linux 1, 2, 2023; CentOS 6, 7, 8; Red Hat Enterprise Linux 6-9; Ubuntu 14.04-24.04; Debian 8-12; SUSE Linux Enterprise 12, 15; Oracle Linux 6-9; Fedora 31+; Arch Linux; Raspberry Pi OS |
| Windows | Windows 7, 8, 8.1, 10, 11; Windows Server 2008 R2 - 2022 |
| macOS | macOS 10.15 (Catalina) - 14 (Sonoma) |
| Solaris | Solaris 10, 11 (SPARC and x86) |
| AIX | AIX 6.1, 7.1, 7.2, 7.3 |
| HP-UX | HP-UX 11.31 (11i v3) |
Wazuh Server (Manager)
The Wazuh Server is the central component of the platform, responsible for analyzing security data received from agents. It accepts events, decodes them, matches them against detection rules, and generates alerts.
Analysis Engine
Event processing on the Wazuh server proceeds through several layers.
Decoders extract structured data from raw logs. Wazuh ships with over 4,000 built-in decoders for standard formats (syslog, Apache, Nginx, SSH, Windows Event Log, and others). Administrators can create custom decoders in /var/ossec/etc/decoders/local_decoder.xml.
Detection rules define the conditions for alert generation. Each rule has a unique identifier and a severity level from 0 to 15:
| Level | Classification | Description |
|---|---|---|
| 0 | Ignored | Rule does not generate an alert (used for filtering) |
| 1-3 | Informational | Normal system events |
| 4-6 | Low | Minor anomalies |
| 7-9 | Medium | Events requiring attention |
| 10-11 | High | Potential attacks, security errors |
| 12-15 | Critical | Confirmed attacks, serious incidents |
The built-in Wazuh ruleset contains over 4,500 rules covering standard detection scenarios. Custom rules are added to /var/ossec/etc/rules/local_rules.xml.
CDB lists (Constant Database) provide fast lookups against reference data: malicious IP lists, file hashes, and indicators of compromise.
Clustering
The Wazuh Server supports clustered configurations for fault tolerance and load distribution:
- Master node - the primary node holding the authoritative configuration
- Worker nodes - processing nodes that handle events from agents
- Synchronization - automatic replication of configuration, rules, and decoders between nodes over port 1516/TCP
Agents are distributed across worker nodes. If a node fails, its agents automatically reconnect to another cluster member.
RESTful API
The Wazuh Server exposes a RESTful API (port 55000/TCP) for programmatic platform management:
- Agent management (listing, status, configuration, restart)
- Alert and event queries
- Rule and decoder management
- Cluster state monitoring
- User and role administration
The API uses JWT authentication and supports RBAC (Role-Based Access Control) for access control. For more details, see the Server API section.
Active Response
The Wazuh server can execute automated actions when rules of a specified level are triggered:
- IP address blocking on the firewall (iptables, Windows Firewall, pf)
- Process termination
- Account disabling
- File quarantine
- Custom script execution
Actions can be executed on the agent, on the server, or across all agents simultaneously.
Wazuh Indexer
The Wazuh Indexer is the storage and search component, built on OpenSearch (an Elasticsearch fork). It receives alerts and events from the Wazuh server via Filebeat and provides long-term storage, full-text search, and aggregation capabilities.
Core Functions
| Function | Description |
|---|---|
| Indexing | Structured storage of JSON documents with full-text search |
| Clustering | Horizontal scaling through shards and replicas |
| ISM (Index State Management) | Automated index lifecycle management (rotation, deletion, archiving) |
| Security | TLS encryption, RBAC, access auditing via OpenSearch Security |
| Snapshots | Index backup to S3-compatible storage or the local file system |
Wazuh Indices
The indexer stores data in the following indices:
wazuh-alerts-*- alerts generated by detection ruleswazuh-archives-*- all events (including those that did not trigger an alert), when archive mode is enabledwazuh-monitoring-*- agent health monitoring datawazuh-statistics-*- Wazuh server operational statistics
Indexer Clustering
A clustered indexer configuration is recommended for production environments:
- A minimum of 3 nodes to maintain quorum
- Primary and replica shards for fault tolerance
- Dedicated master nodes for cluster stability
- Ports 9300-9400/TCP for inter-node communication
For more details, see the Indexer Cluster section.
Wazuh Dashboard
The Wazuh Dashboard is the platform’s web interface, built on OpenSearch Dashboards (a Kibana fork). It provides security data visualization, management tools, and reporting capabilities.
Dashboard Modules
| Module | Purpose |
|---|---|
| Security Events | Real-time alert viewing and filtering |
| Integrity Monitoring | File system change visualization |
| Vulnerability Detection | Detected vulnerabilities sorted by severity |
| SCA | Configuration assessment results against CIS standards |
| MITRE ATT&CK | Alert mapping to the MITRE ATT&CK matrix |
| Regulatory Compliance | Dashboards for PCI DSS, GDPR, HIPAA, NIST 800-53 |
| Agent Management | Agent, group, and configuration management |
| Dev Tools | Console for direct indexer queries |
| Reporting | Scheduled PDF report generation |
Dashboard Network Connections
The dashboard establishes two types of connections:
- To the indexer (port 9200/TCP) - retrieving data for visualization and search
- To the Wazuh server (port 55000/TCP) - retrieving configuration, managing agents, viewing cluster status
Users connect to the dashboard over HTTPS (port 443/TCP).
Port and Protocol Summary
| Component | Port | Protocol | Direction | Purpose |
|---|---|---|---|---|
| Agent | 1514/TCP | AES-256 | Agent -> Server | Event transmission |
| Agent | 1515/TCP | TLS | Agent -> Server | Registration |
| Server | 1516/TCP | TLS | Server <-> Server | Server cluster |
| Server | 55000/TCP | HTTPS | Dashboard -> Server | REST API |
| Server | 514/UDP,TCP | Syslog | External -> Server | Syslog (disabled) |
| Indexer | 9200/TCP | HTTPS | Server/Dashboard -> Indexer | Indexer API |
| Indexer | 9300-9400/TCP | TLS | Indexer <-> Indexer | Indexer cluster |
| Dashboard | 443/TCP | HTTPS | User -> Dashboard | Web interface |
Component Interaction
Understanding how the components interact assists with troubleshooting and network security planning:
- The agent registers with the server via port 1515 (one-time operation)
- The agent transmits events to the server via port 1514 (persistent connection)
- The server analyzes events and generates alerts
- Filebeat on the server forwards alerts to the indexer via port 9200
- The dashboard queries data from the indexer (port 9200) and configuration from the server (port 55000)
- The user accesses the dashboard through a browser (port 443)
For information on data flows and deployment models, see the Wazuh Architecture section. Practical application scenarios are described in Use Cases .