Wazuh — Open-Source SIEM & XDR Setup Guide

EDR?, XDR?, SIEM? do these acronyms just sound like a bunch of jibberish? These are very simple concepts made difficult by accessive use of acronyms. Let's see what each of these mean.

1. Endpoint Detection and Response (EDR)

This is the simplet and the most minimal form of defence in any system. As the name suggests EDR monirots activity on individual devices like laptops, servers and workstations. It watches for malicious processes, file changes, registry modifications, and lateral movement on the endpoint itself.

(Lateral movement is a technique an attacker uses to prograssively move through a network after gaining initial access, working towards their ultimate target. Before an attacker hops to another machine, they do significant work on the compromised endpoint itself like escalating privileges, harvesting credentials, and staging their next move. This is the local phase of lateral movement ie lateral movement within a endpoint.)

It works in two stages:

1. Collect: Process tress, file activity, network connections from the device.
2. Responds: Isolates and host, kill a process, roll back changes.

EDR is best is you want deep visibility into what's happening in a machine. It is a minimum security tool every company must use.
Example tools are CrowdStrike Falcon, SentinelOne.

2. Extended Detection and Response (XDR)

As the name suggests, XDR is an extension of EDR. EDR is scoped to a single endpoint only but XDR has a broader scope of endpoints + networks + cloud + email + identity.
XDR correlates *telemetry across the entire environment. Instead of getting alerts from each tool, XDR stiches every alert to give the complete story.

(WHAT IS TELEMETRY? It is the automated process of collecting data and from remote sources and transmitting them to a central location for monitoring and analysis).

XDR's two step process is:

1. Collects: endpoints, network traffic, email, cloud workloads, identity providers.
2. Responds: coordinated response across multiple layers simultaneously.

It is best for reducing alert fatigue and seeing the full kill chain. Examples are Palo Alto Cortex XDR, Trend Vision One (which is the flagship product of trend micro), Wazuh platform etc.

3. Security Information and Event Management (SIEM)

We saw EDR was scoped to an endpoint, XDR extended the scope to emails, clouds, network and identity providers. This still doesnot cover the entire network of an organization, we expand the scope further now and introduce SEIM. While EDR zooms in on individual devices and XDR connects the dots between a few critical security layers, a SIEM (pronounced "sim") acts as the ultimate brain of a Security Operations Center (SOC). SIEM tools do not just monitor endpoints or networks, they ingest massive quantities of log data from absolutely everywhere in an enterprise ecosystem. This includes domain controllers, firewalls, databases, switches, antivirus software, and custom applications.

A SIEM serves two primary functions:

1. Log Aggregation & Management: Gathering, normalizing, and archiving terabytes of historical logs from diverse sources into a central, searchable repository.
2. Security Analytics & Correlation: Running complex, real-time query rules across those logs to catch sophisticated threats that look innocent in isolation but reveal an attack when viewed together.

The Correlation Difference: If a single user fails a login on a laptop, EDR notes it locally. If that same user fails a login across 40 different servers and a firewall simultaneously, a SIEM flags it as a coordinated brute-force attack.

So why even bother with XDR if siem has bigger scope?
→ SIEM has broader visibility and centralized log analysis, while XDR focuses on deeper detection and faster automated response across integrated security tools.

NOTE: A big misconception is that SIEM is a passive tool that cannot take automated action. SIEM platforms can absolutely support automated actions, especially when integrated with SOAR.
SOAR stands for Security Orchestration, Automation, and Response. It is a stack of software solutions that allows organizations to streamline their security operations by integrating disjointed tools, automating repetitive tasks, and executing predefined incident response workflows without human intervention.

Introducing Wazuh

Wazuh is a popular open source security platform that began as a fork of the OSSEC project. (learn more on ossec)
It has now evolved into a unified system by combining SIEM analytics with Host Intrusion Detection and EDR/XDR capabilities.

Key capabilities of wazuh

1. Log Data Analysis: Wazuh agents extract raw log data from operating systems and applications, while the Wazuh Manager uses built-in "decoders" and rules to parse and alert on malicious behavior in real time.
2. HIDS (Host-Based Intrusion Detection): It monitors system calls, handles rootkit/malware detection, and spots anomalies or indicators of compromise (IoCs) occurring directly on your infrastructure.
3. File Integrity Monitoring (FIM): FIM tracks sensitive directories and registry keys. If an unauthorized user or process creates, modifies, or deletes a critical system file, Wazuh logs the user ID, the application responsible, and triggers an immediate alert.
4. Vulnerability Detection: The Wazuh agent inventories all installed software on an endpoint and correlates it with continuously updated CVE (Common Vulnerabilities and Exposures) databases, highlighting unpatched security flaws automatically.
5. Regulatory Compliance: Out of the box, Wazuh maps its alerts and Security Configuration Assessments (SCA) to major compliance frameworks. Dashboard views can be filtered cleanly by specific control tags for PCI DSS, HIPAA, GDPR, and NIST 800-53, making it incredibly easy to provide audit-ready proof to regulators.

Wazuh has four primary components:

1. Wazuh server (Manager + Filebeat)
2. Indexer
3. Dashboard
4. Agent

To understand all these, lets take a look at how things flow within wazuh.

Wazuh Agent

This is the program that is installed on all clients (endpoints). These agents collect logs and send the raw logs to the wazuh server.
The primary service is: wazuh-agent

Important files of agent

• /var/ossec/etc/ossec.conf — Main agent config
• /var/ossec/logs/ossec.log — Agent logs
• /var/ossec/etc/client.keys — Authentication key
• /var/ossec/queue/ — Event queues
• /var/ossec/etc/shared/ — Shared configs from manager

Agent communicates with manager using 2 ports:
TCP port 1514 for agent event/log forwarding
TCP port 1515 for agent enrollment

Overwhelmed? Don't be — we will cover all of these during our lab setup section.

Wazuh Manager

The main service is: wazuh-manager
The roles of wazuh manager (and the daemons that perform specific roles) are:

How Logs Flow Through the Manager

<localfile>
  <location>/var/log/auth.log</location>
  <log_format>syslog</log_format>
</localfile>

/var/ossec/etc/ossec.conf

1514/TCP

wazuh-remoted

wazuh-analysisd

Failed password for root from 192.168.1.5

{
  "user": "root",
  "srcip": "192.168.1.5"
}

<rule id="5710" level="5">
  <if_sid>5700</if_sid>
  <match>Failed password</match>
  <description>SSH authentication failed</description>
</rule>

ALERT GENERATED

Read alerts.json → Send to Indexer

alerts.json
     ↓
Filebeat reads JSON
     ↓
Converts to OpenSearch docs
     ↓
Sends HTTPS requests
     ↓
Indexer stores documents

{
  "rule": {
    "level": 5,
    "description": "SSH login failed"
  },
  "agent": {
    "name": "ubuntu-server"
  }
}

1.  Attacker attempts SSH login
          ↓
2.  auth.log updated
          ↓
3.  wazuh-logcollector reads log
          ↓
4.  Agent sends event to manager (1514/TCP)
          ↓
5.  wazuh-remoted receives event
          ↓
6.  wazuh-analysisd decodes log
          ↓
7.  Rules matched
          ↓
8.  Alert generated
          ↓
9.  alerts.json updated
          ↓
10. Filebeat reads alerts.json
          ↓
11. Sends HTTPS JSON to indexer (9200)
          ↓
12. Indexer indexes document
          ↓
13. Dashboard queries index
          ↓
14. Alert visible in UI

The installation process of wazuh is pretty straight forward. I am using a ubuntu server VM to install my wazuh server (manager + indexer + Dashboard).

You can install the Wazuh indexer, Wazuh server, and Wazuh dashboard on a single host or distribute them in cluster configurations.

Installing these components in different host is not a complicated job. We have already seen how agents communicate to managers, how managers communicate to indexer and how indexers communicate with the dashboard, the same concept applies.

A important thing to note is that redundancy can be introduced. I will briefly introduce this concept now.

1. Wazuh Manager Layer (Active-Worker Cluster)

Unlike the backend database, the Wazuh Manager layer does not operate in a traditional "multi-master" fashion. Instead, it operates on a Master/Worker protocol.

1. The Master Node: Acts as the central authority. It handles agent enrollment (authd), coordinates configuration files (shared groups, rules, decoders), and pushes global states down to the worker nodes.
2. The Worker Node: Do the heavy lifting. They receive raw log events from agents, decode them, and run them against the analysis engine to generate alerts.
3. Redundancy Mechanics:
   1. Agent Failover: A Network Load Balancer (NLB) is typically placed in front of the Wazuh Managers (listening on TCP port 1514). Wazuh agents connect to the VIP (Virtual IP) of the load balancer, which distributes traffic across all active workers and the master. If a manager node dies, the NLB dynamically shifts agent traffic to the healthy managers
   2. Manager Synchronization: Worker nodes send periodic keep-alives to the master. If a worker accepts an enrollment request from an agent, it uses an internal thread called sendsync to forward that registration to the master, which then replicates the new agent keys back out to all workers.

2. Wazuh Indexer Layer (Distributed Search Cluster)

The Wazuh Indexer is built on OpenSearch, which utilizes a true distributed database design. To achieve proper redundancy and avoid split-brain scenarios, a minimum of 3 Indexer nodes is highly recommended.

If you are interested in inverse index and how distributed index works I highly recommended you study apache lucene and opensearch/elastic search. Click here to understand lucene and elasticsearch

1. Sharding and Replication: When the manager generates an alert, it is sent to the Indexer cluster. OpenSearch splits these indices into Primary Shards and copies them into Replica Shards.
2. Redundancy Mechanics:No two identical shards (Primary and its direct Replica) are stored on the same physical host.
   
   1. If Node 1 fails, Node 2 or Node 3 will instantly promote their replica shards to "Primary" status. Data ingestion and search capabilities continue without data loss.
   2. Quorum: With 3 nodes, if one host dies, the remaining 2 nodes maintain a quorum to elect a new cluster manager (master-eligible node) and track the state of the database safely.

Understanding these concepts are important. To install wazuh is very straighforward, jut refer to the official docs here.