· Henning Scholand · Security  · 5 Min. Lesezeit

Wazuh als SIEM/XDR — Architektur verstehen, Installation richtig aufsetzen

Wazuh ist mehr als ein Log-Kollektor. Wer die drei Kernkomponenten versteht und die Installation sauber aufsetzt, hat die Basis für ein ernstzunehmendes SIEM — ohne Cloud-Abhängigkeit und ohne Lizenzkosten.

Wazuh ist mehr als ein Log-Kollektor. Wer die drei Kernkomponenten versteht und die Installation sauber aufsetzt, hat die Basis für ein ernstzunehmendes SIEM — ohne Cloud-Abhängigkeit und ohne Lizenzkosten.

Wazuh taucht in vielen Empfehlungslisten auf — meistens als “kostenloses SIEM”. Das greift zu kurz. Wazuh ist ein vollständiges XDR-Framework: Intrusion Detection, File Integrity Monitoring, Vulnerability Assessment, Compliance-Checks und zentrales Log-Management in einem. Der entscheidende Unterschied zu SaaS-Produkten: alle Daten bleiben auf deiner eigenen Infrastruktur.

Dieser Artikel legt das Fundament. Wer die Architektur versteht und die Installation sauber macht, spart sich später viel Debugging.

Die drei Kernkomponenten

Wazuh besteht aus drei Diensten, die zusammenspielen müssen:

Wazuh Manager ist das Herzstück. Er empfängt die Events der Agents, verarbeitet sie durch Decoder und Regelwerk, löst Alarme aus und koordiniert Active Response. Alle Konfiguration — Decoder, Rules, Active-Response-Scripts — liegt hier.

Wazuh Indexer ist eine angepasste OpenSearch-Instanz. Alle Events, Alarme und Inventardaten werden hier gespeichert und indiziert. OpenSearch ist der freie Fork von Elasticsearch — kein Lizenzproblem, kein SSPL.

Wazuh Dashboard ist die Oberfläche auf Basis von OpenSearch Dashboards. Threat-Übersichten, Compliance-Reports, MITRE-ATT&CK-Matrix, Agent-Inventar — alles hier.

┌─────────────────────────────────────────────────────┐
│                   Wazuh Server                      │
│                                                     │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────┐  │
│  │   Manager    │  │   Indexer    │  │Dashboard │  │
│  │  (Port 1514) │→ │  (Port 9200) │← │(Port 443)│  │
│  └──────────────┘  └──────────────┘  └──────────┘  │
└─────────────────────────────────────────────────────┘
         ↑ (TLS, 1514/UDP oder 1514/TCP)
┌────────┴────────┐
│   Wazuh Agent   │ (Linux, Windows, macOS)
│  (alle Endpoints)│
└─────────────────┘

Die Kommunikation zwischen Agent und Manager läuft verschlüsselt über Port 1514. Der Manager schreibt Events über die Indexer-REST-API (Port 9200) in OpenSearch. Das Dashboard liest daraus.

Single-Node vs. Distributed

Für Umgebungen bis ca. 100 Agents und ~50.000 Events/Minute reicht ein Single-Node-Setup vollständig aus — alle drei Komponenten auf einer Maschine. Das ist der pragmatische Einstieg.

Ab ca. 200+ Agents oder hoher Event-Rate lohnt sich das Distributed-Setup: Manager und Indexer auf getrennten Nodes, Indexer als Cluster mit 3+ Nodes für Redundanz.

Dieser Artikel beschreibt das Single-Node-Setup. Die Konfiguration lässt sich später 1:1 in ein verteiltes Setup überführen.

Anforderungen

Für ein Single-Node-Setup mit bis zu 50 Agents:

RessourceMinimumEmpfehlung
CPU4 Kerne8 Kerne
RAM8 GB16 GB
Disk50 GB200 GB (SSD)
OSDebian 12 / Ubuntu 22.04Debian 12

Der Speicherbedarf hängt stark von der Retention-Zeit ab. Standard sind 90 Tage Events im Index. Bei 50 Agents und normalem Log-Volumen rechne ich mit ca. 2–5 GB/Tag.

Installation — der saubere Weg

Wazuh liefert ein Installationsskript, das alle drei Komponenten auf einmal einrichtet. Für Produktionsumgebungen ziehe ich das manuelle Paket-basierte Vorgehen vor — mehr Kontrolle, kein Curl-to-Bash.

Schritt 1: Systemvorbereitung

# Swap sicherstellen — OpenSearch braucht stabilen Heap
fallocate -l 4G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# vm.max_map_count für OpenSearch
echo 'vm.max_map_count=262144' >> /etc/sysctl.d/99-wazuh.conf
sysctl -p /etc/sysctl.d/99-wazuh.conf

# Zeitzone setzen
timedatectl set-timezone Europe/Berlin

Schritt 2: Wazuh-Repository einbinden

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

echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" \
  > /etc/apt/sources.list.d/wazuh.list

apt-get update

Schritt 3: Wazuh Indexer installieren

apt-get install wazuh-indexer -y

Die Konfiguration liegt unter /etc/wazuh-indexer/opensearch.yml. Für Single-Node minimal anpassen:

# /etc/wazuh-indexer/opensearch.yml
network.host: "0.0.0.0"
node.name: "wazuh-node1"
cluster.initial_master_nodes:
  - "wazuh-node1"
plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: /etc/wazuh-indexer/certs/indexer.pem
plugins.security.ssl.http.pemkey_filepath: /etc/wazuh-indexer/certs/indexer-key.pem
plugins.security.ssl.http.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem
plugins.security.ssl.transport.pemcert_filepath: /etc/wazuh-indexer/certs/indexer.pem
plugins.security.ssl.transport.pemkey_filepath: /etc/wazuh-indexer/certs/indexer-key.pem
plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/wazuh-indexer/certs/root-ca.pem
plugins.security.authcz.admin_dn:
  - "CN=admin,OU=Wazuh,O=Wazuh,L=California,C=US"
plugins.security.nodes_dn:
  - "CN=wazuh-node1,OU=Wazuh,O=Wazuh,L=California,C=US"

Zertifikate werden über das Wazuh-Cert-Tool erzeugt:

# Cert-Tool herunterladen
curl -sO https://packages.wazuh.com/4.x/wazuh-certs-tool.sh
curl -sO https://packages.wazuh.com/4.x/config.yml

# config.yml anpassen — Hostnamen eintragen
cat > config.yml << 'EOF'
nodes:
  indexer:
    - name: wazuh-node1
      ip: "127.0.0.1"
  server:
    - name: wazuh-1
      ip: "127.0.0.1"
  dashboard:
    - name: wazuh-dashboard
      ip: "127.0.0.1"
EOF

bash ./wazuh-certs-tool.sh -A

# Zertifikate verteilen
tar -xf ./wazuh-certificates.tar -C /etc/wazuh-indexer/certs/ \
  --wildcards --no-anchored 'wazuh-node1*' 'root-ca*' 'admin*'
mv /etc/wazuh-indexer/certs/wazuh-node1.pem /etc/wazuh-indexer/certs/indexer.pem
mv /etc/wazuh-indexer/certs/wazuh-node1-key.pem /etc/wazuh-indexer/certs/indexer-key.pem
chmod 500 /etc/wazuh-indexer/certs
chmod 400 /etc/wazuh-indexer/certs/*
chown -R wazuh-indexer:wazuh-indexer /etc/wazuh-indexer/certs

Indexer starten und initialisieren:

systemctl daemon-reload
systemctl enable --now wazuh-indexer

# Security-Plugin initialisieren (einmalig)
/usr/share/wazuh-indexer/bin/indexer-security-init.sh

Schritt 4: Wazuh Manager installieren

apt-get install wazuh-manager -y
systemctl enable --now wazuh-manager

Der Manager legt seine Konfiguration unter /var/ossec/etc/ossec.conf ab. Wichtigste Anpassung direkt nach der Installation — den Indexer-Output konfigurieren:

<!-- /var/ossec/etc/ossec.conf — im <ossec_config>-Block -->
<indexer>
  <enabled>yes</enabled>
  <hosts>
    <host>https://127.0.0.1:9200</host>
  </hosts>
  <ssl>
    <certificate_authorities>
      <ca>/etc/filebeat/certs/root-ca.pem</ca>
    </certificate_authorities>
    <certificate>/etc/filebeat/certs/filebeat.pem</certificate>
    <key>/etc/filebeat/certs/filebeat-key.pem</key>
  </ssl>
</indexer>

Schritt 5: Wazuh Dashboard installieren

apt-get install wazuh-dashboard -y

Dashboard-Konfiguration anpassen:

# /etc/wazuh-dashboard/opensearch_dashboards.yml
server.host: 0.0.0.0
server.port: 443
opensearch.hosts: https://localhost:9200
opensearch.ssl.verificationMode: certificate
opensearch.username: kibanaserver
opensearch.password: kibanaserver
server.ssl.enabled: true
server.ssl.key: /etc/wazuh-dashboard/certs/dashboard-key.pem
server.ssl.certificate: /etc/wazuh-dashboard/certs/dashboard.pem
systemctl enable --now wazuh-dashboard

Nach ca. 30 Sekunden ist das Dashboard erreichbar: https://<server-ip> — Standard-Login admin / admin, sofort ändern.

Agent-Deployment

Ein Agent ohne Verbindung zum Manager ist nutzlos. Die Registrierung läuft heute vollautomatisch über den Enrollment-Mechanismus — kein manuelles Keying mehr notwendig.

Linux-Agent

# Repository auf dem zu überwachenden Host einbinden
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
echo "deb [signed-by=/usr/share/keyrings/wazuh.gpg] \
  https://packages.wazuh.com/4.x/apt/ stable main" \
  > /etc/apt/sources.list.d/wazuh.list
apt-get update

# Agent installieren — WAZUH_MANAGER zeigt auf den Manager
WAZUH_MANAGER="192.168.10.5" \
WAZUH_AGENT_NAME="webserver-prod-01" \
WAZUH_AGENT_GROUP="linux-servers" \
  apt-get install wazuh-agent -y

systemctl enable --now wazuh-agent

Windows-Agent (PowerShell)

# MSI herunterladen und installieren
$url = "https://packages.wazuh.com/4.x/windows/wazuh-agent.msi"
$dest = "$env:TEMP\wazuh-agent.msi"
Invoke-WebRequest -Uri $url -OutFile $dest

msiexec.exe /i $dest /q `
  WAZUH_MANAGER="192.168.10.5" `
  WAZUH_AGENT_NAME="$env:COMPUTERNAME" `
  WAZUH_AGENT_GROUP="windows-workstations"

Start-Service WazuhSvc
Set-Service WazuhSvc -StartupType Automatic

Nach ca. 30 Sekunden taucht der Agent im Dashboard unter Agents auf — Status Active.

Agent-Gruppen und zentrale Konfiguration

Agent-Gruppen sind das mächtigste Werkzeug für skalierbare Konfiguration. Statt jeden Agent einzeln anzupassen, liegt die Konfiguration zentral auf dem Manager.

# Gruppe anlegen
/var/ossec/bin/agent_groups -a -g linux-servers

# Gruppen-Konfiguration bearbeiten
# Liegt unter /var/ossec/etc/shared/linux-servers/agent.conf
<!-- /var/ossec/etc/shared/linux-servers/agent.conf -->
<agent_config>
  <!-- Syslog überwachen -->
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/syslog</location>
  </localfile>
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>

  <!-- File Integrity Monitoring -->
  <syscheck>
    <frequency>43200</frequency>
    <directories check_all="yes" report_changes="yes" realtime="yes">
      /etc,/usr/bin,/usr/sbin,/bin,/sbin
    </directories>
    <directories check_all="yes" report_changes="yes">
      /var/www
    </directories>
    <ignore>/etc/mtab</ignore>
    <ignore>/etc/hosts.deny</ignore>
  </syscheck>

  <!-- Rootcheck -->
  <rootcheck>
    <frequency>43200</frequency>
  </rootcheck>
</agent_config>

Die Konfiguration wird automatisch an alle Agents der Gruppe verteilt — kein manuelles Ausrollen.

Erste Schritte im Dashboard

Nach dem Start zeigt das Dashboard unter Overview die wichtigsten Kennzahlen: Events der letzten Stunden, Security Alerts nach Level, MITRE-ATT&CK-Heatmap.

Unter Agents sieht man jeden registrierten Agent mit Status, OS, IP und letztem Heartbeat. Ein Klick öffnet die agent-spezifische Ansicht mit Events, FIM-Änderungen, Vulnerability-Assessment und Compliance-Status.

Threat Intelligence → MITRE ATT&CK zeigt, welche Techniken aus dem ATT&CK-Framework in der eigenen Umgebung bereits erkannt wurden — kategorisiert nach Taktik (Initial Access, Persistence, Lateral Movement, etc.).

Nächster Schritt

Die Standard-Installation erkennt viel — SSH-Brute-Force, Privilege-Escalation-Versuche, bekannte Angriffsmuster. Aber der eigentliche Mehrwert liegt im Schärfen des Regelwerks für die eigene Umgebung. Im nächsten Artikel zeige ich, wie eigene Decoder und Rules geschrieben werden — und wie Active Response automatisch auf Alarme reagiert.

Teilen:
Zum Blog

Ähnliche Artikel

Alle Artikel »