# Wazuh Components - Agent, Server, Indexer, Dashboard

> Detailed description of Wazuh 4.14 components - agent analysis modules, server rule engine, OpenSearch indexer, and dashboard visualization interface

Source: https://opennix.org/en/docs/wazuh/getting-started/wazuh-components/


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](/docs/wazuh/infrastructure/wazuh-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 rules
- `wazuh-archives-*` - all events (including those that did not trigger an alert), when archive mode is enabled
- `wazuh-monitoring-*` - agent health monitoring data
- `wazuh-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](/docs/wazuh/infrastructure/wazuh-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:

1. The agent registers with the server via port 1515 (one-time operation)
2. The agent transmits events to the server via port 1514 (persistent connection)
3. The server analyzes events and generates alerts
4. Filebeat on the server forwards alerts to the indexer via port 9200
5. The dashboard queries data from the indexer (port 9200) and configuration from the server (port 55000)
6. The user accesses the dashboard through a browser (port 443)

For information on data flows and deployment models, see the [Wazuh Architecture](/docs/wazuh/getting-started/wazuh-architecture/) section. Practical application scenarios are described in [Use Cases](/docs/wazuh/getting-started/wazuh-use-cases/).