# Wazuh Architecture - Components, Data Flow, and Ports

> Wazuh 4.14 platform architecture - agent-server interaction, OpenSearch indexer, deployment models, and comparison with Splunk, ELK, and QRadar

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


Wazuh employs a distributed architecture built around four primary components: the agent, the server (manager), the indexer, and the dashboard. Each component serves a distinct role in the collection, analysis, storage, and visualization of security data. A solid understanding of this architecture is essential for planning deployments and scaling the platform.

## Architecture Overview

The Wazuh architecture follows an "agent - server - storage - visualization" model. Agents deployed on monitored endpoints collect security events and forward them to a central server for analysis. The analysis results are sent to an indexer for long-term storage and search, while the dashboard provides a web interface for interacting with the data.

```
┌──────────────┐     1514/TCP      ┌──────────────┐     9200/TCP      ┌──────────────┐
│              │   (AES-256)       │              │    (TLS)          │              │
│  Wazuh Agent │ ────────────────> │ Wazuh Server │ ────────────────> │    Wazuh     │
│  (endpoint)  │                   │  (manager)   │    (Filebeat)     │   Indexer    │
│              │                   │              │                   │ (OpenSearch) │
└──────────────┘                   └──────┬───────┘                   └──────┬───────┘
                                          │                                  │
                                   55000/TCP                          9200/TCP
                                   (REST API)                          (API)
                                          │                                  │
                                          ▼                                  ▼
                                   ┌──────────────────────────────────────────┐
                                   │           Wazuh Dashboard                │
                                   │     (OpenSearch Dashboards, 443/TCP)     │
                                   └──────────────────────────────────────────┘
```

## Data Flow

Security event processing in Wazuh proceeds through several stages.

### Data Collection (Agent)

The Wazuh agent collects data from multiple sources on the monitored system:

- System logs (syslog, Windows Event Log, macOS Unified Logging System)
- File system changes (FIM)
- Configuration scan results (SCA)
- Installed software and open port inventories (Syscollector)
- Rootkit detection results
- Custom command output (command monitoring)

Collected events are encrypted using AES-256 and transmitted to the server over TCP port 1514.

### Analysis (Server)

The Wazuh server (manager) receives events from agents and processes them through several stages:

1. **Decoding** - extracting structured fields from raw logs using decoders
2. **Rule matching** - evaluating decoded events against a set of detection rules
3. **Enrichment** - adding context via CDB lists, threat intelligence feeds, and MITRE ATT&CK mapping
4. **Alert generation** - producing notifications when rules are triggered
5. **Active response** - executing automated actions (IP blocking, process termination)

The server also manages agent configuration, registration, and upgrades through a RESTful API on port 55000.

### Indexing and Storage (Indexer)

Filebeat, installed on the Wazuh server, forwards alerts and archived events to the indexer over TLS (port 9200). The OpenSearch-based indexer provides:

- Full-text search across security events
- Data aggregation for analytical queries
- Index lifecycle management (ISM)
- Clustering for fault tolerance and horizontal scaling

### Visualization (Dashboard)

Wazuh Dashboard (built on OpenSearch Dashboards) provides a web interface for:

- Real-time alert viewing and filtering
- Data visualization through charts, tables, and maps
- Agent, rule, and configuration management
- Compliance reporting against industry standards
- Threat hunting through built-in investigation tools

The dashboard communicates with the Wazuh server via the REST API (port 55000) for configuration data and with the indexer (port 9200) for event data.

## Agentless Monitoring

For devices where agent installation is not feasible - network switches, routers, firewalls, and IDS/IPS appliances - Wazuh supports agentless monitoring:

- **Syslog** - log reception over syslog protocol (UDP/TCP, port 514, disabled by default)
- **SSH** - periodic data collection through SSH connections
- **API** - integration through device APIs

Data from agentless sources flows directly to the Wazuh server and is processed by the same analysis engine.

## Deployment Models

Wazuh supports three deployment models depending on scale and availability requirements.

### All-in-one

All components - server, indexer, and dashboard - are installed on a single host. Suitable for lab environments, testing, and small infrastructures with up to 50-100 agents.

| Advantage | Limitation |
|---|---|
| Minimal resource requirements | No fault tolerance |
| Simple installation and maintenance | Limited performance |
| Rapid deployment for PoC | Not suitable for production |

### Single-node

Each component is installed on a separate server: one Wazuh server, one indexer, one dashboard. Recommended for medium-scale environments (100-500 agents).

| Advantage | Limitation |
|---|---|
| Workload separation between components | Each component is a single point of failure |
| Independent scaling per component | Requires more servers |
| Suitable for production environments | No clustering |

### Distributed (multi-node)

A clustered configuration with multiple server and indexer instances. A single dashboard connects to the server and indexer clusters. Designed for large infrastructures (500+ agents) with high-availability requirements.

| Advantage | Limitation |
|---|---|
| High availability for all components | Complex setup and maintenance |
| Horizontal scaling | Higher resource requirements |
| Load balancing | Requires cluster administration experience |

The Wazuh server cluster uses port 1516/TCP for inter-node synchronization. The indexer cluster uses ports 9300-9400/TCP for intra-cluster communication.

## Protocols and Ports

The following table lists all network ports used by Wazuh components.

| Port | Protocol | Component | Purpose |
|---|---|---|---|
| 1514/TCP | AES-256 | Agent - Server | Event transmission from agents |
| 1514/UDP | AES-256 | Agent - Server | Event transmission (optional) |
| 1515/TCP | TLS | Agent - Server | Agent enrollment |
| 1516/TCP | TLS | Server - Server | Server cluster synchronization |
| 514/UDP,TCP | Syslog | External sources - Server | Syslog reception (disabled by default) |
| 55000/TCP | HTTPS | Dashboard - Server | Management REST API |
| 9200/TCP | HTTPS | Server/Dashboard - Indexer | Indexer API (Filebeat, queries) |
| 9300-9400/TCP | TLS | Indexer - Indexer | Intra-cluster communication |
| 443/TCP | HTTPS | User - Dashboard | Web interface |

## Comparison with Alternative SIEM Solutions

The Wazuh architecture shares common principles with other SIEM platforms but differs in implementation.

### Wazuh vs. Splunk

| Aspect | Wazuh | Splunk |
|---|---|---|
| Collection agent | Wazuh Agent | Universal Forwarder / Heavy Forwarder |
| Data processing | Wazuh Server (decoders + rules) | Indexer (search-time/index-time) |
| Storage | Wazuh Indexer (OpenSearch) | Splunk Indexer (proprietary) |
| Visualization | Wazuh Dashboard | Search Head |
| Licensing | Open source (GPLv2) | Commercial license (volume-based) |
| Clustering | Native server and indexer clustering | Indexer Cluster + Search Head Cluster |

Splunk uses a proprietary storage format and is licensed based on the volume of indexed data. Wazuh uses OpenSearch and imposes no license-level data volume restrictions.

### Wazuh vs. ELK Stack (Elastic Security)

| Aspect | Wazuh | ELK Stack |
|---|---|---|
| Collection agent | Wazuh Agent | Elastic Agent / Beats |
| Data processing | Wazuh Server | Logstash / Elasticsearch Ingest Pipelines |
| Storage | Wazuh Indexer (OpenSearch) | Elasticsearch |
| Visualization | Wazuh Dashboard | Kibana |
| Detection rules | Wazuh Rules (XML) | Detection Rules (KQL/EQL) |
| Licensing | Open source (GPLv2) | Elastic License 2.0 / SSPL |

Wazuh originated as a fork of OSSEC and has always focused on security operations. The ELK Stack is a general-purpose log platform that later gained security features through Elastic Security.

### Wazuh vs. IBM QRadar

| Aspect | Wazuh | QRadar |
|---|---|---|
| Data collection | Wazuh Agent + Syslog | Event Collectors / Flow Collectors |
| Processing | Wazuh Server | Event Processors / Flow Processors |
| Correlation | Rules with severity levels (0-15) | Offense Engine |
| Visualization | Wazuh Dashboard | QRadar Console |
| Licensing | Open source (GPLv2) | Commercial license (EPS-based) |
| Deployment | On-premise, Docker, Kubernetes | On-premise, virtual appliances |

QRadar uses the Offense concept for event correlation and is licensed based on events per second (EPS). Wazuh uses a rule system with severity levels from 0 to 15 and has no EPS restrictions.

## Deployment Model Selection Guidelines

When planning a Wazuh deployment, consider the following factors:

- **Agent count** - determines server compute resource requirements
- **Event volume** - affects indexer storage size and network throughput
- **Availability requirements** - clustered configurations are recommended for production
- **Data retention period** - determines indexer disk space
- **Network topology** - influences component placement and firewall configuration

For an initial evaluation, consider starting with a [Docker deployment](/docs/wazuh/deployment/wazuh-docker-deployment/), which allows all components to run on a single host. A detailed breakdown of each component is available in the [Wazuh Components](/docs/wazuh/getting-started/wazuh-components/) section.