Wazuh SIEM einrichten: 12 Schritte, 45 Min [2026]

Wazuh SIEM erkennt Angriffe, die andere Tools übersehen. Das quelloffene Security-Information-and-Event-Management-System verarbeitet Protokolle von Tausenden Endpunkten, korreliert Ereignisse in Echtzeit und liefert Alerts nach dem MITRE ATT&CK-Framework. In diesem Tutorial installierst du Wazuh 4.9 auf einem Ubuntu 24.04 Server, verbindest drei Agenten (Linux, Windows, Docker) und konfigurierst aktive Reaktionen auf Brute-Force-Angriffe. Zeitaufwand: 45 Minuten.

Was ist Wazuh SIEM und warum setzen 25 Millionen Endpunkte darauf?

Wazuh ist eine Open-Source-Sicherheitsplattform, die SIEM, XDR (Extended Detection and Response) und CSPM (Cloud Security Posture Management) in einem einzigen Stack vereint. Laut der Wazuh-Projektseite schützt die Plattform Stand 2026 mehr als 25 Millionen Endpunkte weltweit. Das GitHub-Repository zählt über 10.000 Sterne. Die Wazuh-Community ist aktiv, mit wöchentlichen Releases und einem Forum mit über 40.000 registrierten Mitgliedern.

Wazuh basiert auf dem Fork des eingestellten OSSEC-Projekts, wurde aber grundlegend neu entwickelt. Heute bietet es eine vollständige REST-API, eine Kibana-ähnliche Weboberfläche (Wazuh Dashboard, intern auf OpenSearch aufgebaut) und native Integrationen mit AWS, Azure, Google Cloud, Microsoft 365 und GitHub. Für deutsche Unternehmen, die NIS-2 oder das KRITIS-Dachgesetz einhalten müssen, liefert Wazuh die Audit-Protokollierung und Incident-Detection-Funktionen, die Regulatoren erwarten, ohne Lizenzkosten.

Der Wazuh-Stack besteht aus drei Hauptkomponenten: dem Wazuh Manager (Regelmaschine, Alerting, Active Response), dem Wazuh Indexer (auf OpenSearch basierend, Speicher und Suche der Sicherheitsereignisse) und dem Wazuh Dashboard (Web-UI auf OpenSearch Dashboards). Auf den überwachten Hosts läuft ein leichtgewichtiger Wazuh Agent, der Protokolle, Systemzustandsdaten und Dateiintegritätsergebnisse verschlüsselt an den Manager sendet. Die Kommunikation zwischen Agent und Manager erfolgt über TLS-verschlüsselte Verbindungen auf Port 1514.

Gegenüber klassischen SIEM-Lösungen hat Wazuh einen entscheidenden Vorteil: Es denkt vom Endpunkt aus. Statt Protokolle nachträglich in ein zentrales System zu laden, verarbeitet der Agent auf dem Host bereits einen Teil der Analyse. Das reduziert die Netzwerklast, beschleunigt die Reaktionszeit bei Active-Response-Regeln und ermöglicht Offline-Erkennung, wenn der Netzwerkzugang zum Manager unterbrochen ist.

Voraussetzungen: Hardware, Software und Versionen

Bevor du anfängst, stelle sicher, dass dein Server diese Mindestanforderungen erfüllt. Wazuh ist ressourcenhungrig, besonders der OpenSearch-basierte Indexer. Die folgende Tabelle zeigt die Anforderungen für unterschiedliche Umgebungsgrößen:

Komponente	Mindest (Lab)	Klein (bis 100 Agenten)	Produktion (500+ Agenten)
CPU	2 vCPU	4 vCPU	8+ vCPU
RAM	4 GB	8 GB	16 GB+
Festplatte	50 GB SSD	200 GB SSD	500 GB SSD (RAID)
Betriebssystem	Ubuntu 22.04 / 24.04	Ubuntu 24.04 LTS	Ubuntu 24.04 LTS oder RHEL 9
Wazuh-Version	4.9.x	4.9.x	4.9.x (Cluster)
Netzwerk-Ports	1514, 1515, 55000, 9200, 443	gleich	+ 9300, 1516 (Cluster)

Du benötigst Root-Zugriff oder sudo-Rechte auf dem Server, einen gültigen DNS-Eintrag (optional, aber für TLS-Zertifikate empfohlen) und Python 3.8 oder höher für das Wazuh-Installationsskript. Für den Windows-Agenten benötigst du Windows 10 21H2 oder neuer (Windows Server 2019+). Für Docker-Agenten brauchst du Docker Engine 24.0 oder neuer. Java wird nicht separat benötigt; der Wazuh Indexer bringt eine gebündelte JVM mit.

Netzwerktopologie für dieses Tutorial

In diesem Tutorial verwenden wir folgende Struktur: Der Wazuh-Server läuft auf 192.168.1.10, ein Linux-Agent auf 192.168.1.20, ein Windows-Agent auf 192.168.1.30 und ein Docker-Host auf 192.168.1.40. Alle Maschinen befinden sich im selben privaten Subnetz. Im Produktionsbetrieb empfiehlt sich der Wazuh-Server in einem dedizierten Management-VLAN, das nur von Agenten erreichbar ist, um die Angriffsfläche zu minimieren. Ein Angreifer, der Zugang zu einem überwachten Host bekommt, sollte den Manager nicht direkt erreichen können.

Die Port-Übersicht für deine Firewall-Regeln: Port 1514/TCP+UDP ist der Datentransfer-Port von Agenten zum Manager. Port 1515/TCP ist der Enrollment-Port für neue Agenten. Port 1516/TCP ist für den Manager-Cluster (nur bei Multi-Node-Setup). Port 55000/TCP ist die REST-API des Managers. Port 9200/TCP ist der OpenSearch-HTTP-Endpunkt (intern). Port 443/TCP ist das Wazuh Dashboard. Port 9300/TCP ist der OpenSearch-Cluster-Kommunikationsport (nur bei Multi-Node-Indexer).

Schritt 1: System vorbereiten und Updates einspielen

Beginne mit einem frischen Ubuntu-24.04-Server. Spiele alle Sicherheitsupdates ein und stelle die korrekte Zeitzone ein. Wazuh-Timestamps sind für die Ereigniskorrelation kritisch; Uhrzeitabweichungen zwischen Server und Agenten führen zu verpassten Alerts oder falschen Zeitfenstern bei Korrelationsregeln.

sudo apt update && sudo apt upgrade -y
sudo apt install curl wget gnupg2 apt-transport-https lsb-release ca-certificates -y

# Zeitzone auf Europe/Berlin setzen
sudo timedatectl set-timezone Europe/Berlin
sudo timedatectl set-ntp true

# Hostname korrekt setzen (wichtig für TLS-Zertifikate)
sudo hostnamectl set-hostname wazuh-server
echo "192.168.1.10 wazuh-server" | sudo tee -a /etc/hosts

# Swap deaktivieren (OpenSearch-Anforderung)
sudo swapoff -a
sudo sed -i '/swap/d' /etc/fstab

# Kernel-Parameter für OpenSearch
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf
echo "net.core.somaxconn=65535" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Der Parameter vm.max_map_count=262144 ist zwingend notwendig. Ohne ihn startet der Wazuh Indexer (OpenSearch) nicht und gibt den Fehler max virtual memory areas vm.max_map_count [65530] is too low aus. Das ist einer der häufigsten Installationsfehler. Vergiss außerdem nicht, Swap zu deaktivieren. OpenSearch-Dokumentation schreibt dies explizit vor, da Swap die Suchperformance massiv degradiert und zu sporadischen Timeouts bei Abfragen führen kann. Der Zusatz net.core.somaxconn=65535 erhöht den maximalen Socket-Backlog, was bei vielen gleichzeitigen Agentenverbindungen relevant ist.

Schritt 2: Wazuh-Installationsskript herunterladen und konfigurieren

Wazuh bietet ein All-in-One-Installationsskript, das alle drei Komponenten (Indexer, Manager, Dashboard) automatisch einrichtet. Lade es von der offiziellen Wazuh-Quelle herunter und verifiziere die SHA256-Prüfsumme vor der Ausführung. Das Skript basiert auf signierten Paketen und dem offiziellen Wazuh-APT-Repository.

# Installationsskript und Konfigurationsvorlage herunterladen
curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
curl -sO https://packages.wazuh.com/4.9/config.yml

# SHA256 prüfen (Ausgabe mit offizieller Dokumentation vergleichen)
sha256sum wazuh-install.sh

# Konfigurationsdatei anpassen
nano config.yml

Die Datei config.yml definiert, welche Knoten installiert werden und welche IP-Adressen sie verwenden. Für eine Single-Node-Installation (ein Server für alle Rollen) passe sie wie folgt an:

# config.yml für Single-Node-Installation
nodes:
  indexer:
    - name: node-1
      ip: "192.168.1.10"
  server:
    - name: wazuh-1
      ip: "192.168.1.10"
  dashboard:
    - name: dashboard
      ip: "192.168.1.10"

Starte die Installation. Der Prozess lädt die Wazuh-Pakete herunter, generiert TLS-Zertifikate für die interne Kommunikation, konfiguriert OpenSearch, startet alle drei Dienste und erstellt die initiale Passwortdatei. Auf einem schnellen Server mit guter Internetverbindung dauert das 8 bis 12 Minuten:

sudo bash wazuh-install.sh -a

# Ausgabe am Ende der Installation (Beispiel):
# INFO: --- Summary ---
# INFO: You can access the web interface https://192.168.1.10
#    User: admin
#    Password: Ab1Cd2Ef3Gh4Ij5K
# INFO: Installation finished.

# Passwortdatei sichern
sudo cat /home/$USER/wazuh-passwords.txt > ~/wazuh-passwords-backup.txt
chmod 600 ~/wazuh-passwords-backup.txt

Das Skript generiert am Ende eine Passwortdatei wazuh-passwords.txt. Speichere diese Datei sofort an einem sicheren Ort. Sie enthält Credentials für den Admin-Account, den Wazuh-API-User, den Indexer-Admin und mehrere interne Service-Accounts. Die Passwörter können nachträglich geändert werden, aber vergessene Indexer-Admin-Passwörter erfordern eine aufwendige Reset-Prozedur über die OpenSearch Security-Tools.

Schritt 3: Installation verifizieren und Services prüfen

Nach der Installation prüfe den Status aller drei Dienste. Alle müssen active (running) zeigen. Falls einer der Dienste im Status failed ist, prüfe das Journal-Log des betroffenen Dienstes.

# Status aller Wazuh-Dienste prüfen
sudo systemctl status wazuh-indexer --no-pager
sudo systemctl status wazuh-manager --no-pager
sudo systemctl status wazuh-dashboard --no-pager

# Wazuh Indexer-Gesundheit prüfen
curl -k -u admin:DEIN_PASSWORT https://localhost:9200/_cat/health?v

# Erwartete Ausgabe:
# epoch      timestamp cluster       status node.total node.data shards pri relo init unassign
# 1750000000 12:00:00  wazuh-cluster green           1         1      0   0    0    0        0

# Manager-Status direkt prüfen
sudo /var/ossec/bin/wazuh-control status

# Erwartete Ausgabe:
# wazuh-execd is running...
# wazuh-analysisd is running...
# wazuh-syscheckd is running...
# wazuh-monitord is running...
# wazuh-logcollector is running...
# wazuh-remoted is running...
# wazuh-db is running...
# wazuh-apid is running...
# wazuh-authd is running...

Greife nun auf das Dashboard zu: Öffne https://192.168.1.10 im Browser (HTTPS, Port 443). Der Browser zeigt eine Zertifikatswarnung, da ein selbst signiertes Zertifikat verwendet wird. Klicke auf “Erweitert” und dann “Weiter zur Seite”. Melde dich mit dem Benutzernamen admin und dem Passwort aus der wazuh-passwords.txt an. Nach dem Login siehst du das Wazuh-Hauptdashboard mit der Übersicht der aktiven Agenten, aktuellen Alerts und MITRE ATT&CK-Abdeckung.

Schritt 4: Ersten Linux-Agenten installieren und registrieren

Wazuh-Agenten senden Protokolle, Datei-Integritätsprüfungen, Schwachstellen-Inventar und System-Metadaten an den Manager. Die Kommunikation ist TLS-verschlüsselt; der Agent authentifiziert sich beim ersten Start automatisch über den Enrollment-Mechanismus auf Port 1515. Installiere den Agenten auf dem Linux-Rechner (192.168.1.20):

# Auf dem Linux-Agent (192.168.1.20) ausführen
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" | \
  sudo tee /etc/apt/sources.list.d/wazuh.list

sudo apt update
sudo apt install wazuh-agent -y

# Agent mit dem Manager verbinden (Umgebungsvariablen-Methode)
sudo WAZUH_MANAGER="192.168.1.10" \
  WAZUH_AGENT_NAME="linux-server-01" \
  WAZUH_AGENT_GROUP="linux-servers" \
  dpkg-reconfigure wazuh-agent

# Service aktivieren und starten
sudo systemctl daemon-reload
sudo systemctl enable wazuh-agent
sudo systemctl start wazuh-agent

# Verbindungsstatus prüfen
sudo /var/ossec/bin/wazuh-control status | grep agent

Nach dem Start muss der Agent beim Manager registriert werden. Das geschieht bei Wazuh 4.x automatisch über den Enrollment-Mechanismus ohne manuelle Zertifikatsverteilung. Du siehst den Agenten nach etwa 30 Sekunden im Dashboard unter “Agents” mit dem Status “Active”. Falls er nach 2 Minuten noch “Never connected” zeigt, prüfe die Konnektivität: der Agent muss Port 1514 (UDP/TCP) und Port 1515 (TCP, Enrollment) auf dem Manager-Server erreichen können. Nutze telnet 192.168.1.10 1514 für den schnellen Test.

Schritt 5: Windows-Agenten per PowerShell installieren

Für Windows-Hosts steht ein MSI-Installer bereit. Die unbeaufsichtigte PowerShell-Installation ist für GPO-Rollouts in Active-Directory-Umgebungen bevorzugt, weil sie ohne Benutzerinteraktion funktioniert und über Group Policy Software Installation oder Softwareverteilungswerkzeuge wie SCCM/Intune ausgerollt werden kann.

# PowerShell auf dem Windows-Host (als Administrator ausführen)
# Verzeichnis erstellen und MSI herunterladen
New-Item -ItemType Directory -Force -Path "C:\Temp"
Invoke-WebRequest -Uri "https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.0-1.msi" `
  -OutFile "C:\Temp\wazuh-agent.msi"

# Signatur prüfen (empfohlen)
Get-AuthenticodeSignature "C:\Temp\wazuh-agent.msi"

# Unattended Installation mit Manager-Konfiguration
Start-Process msiexec.exe -Wait -ArgumentList `
  '/i C:\Temp\wazuh-agent.msi `
  WAZUH_MANAGER="192.168.1.10" `
  WAZUH_AGENT_NAME="windows-client-01" `
  WAZUH_AGENT_GROUP="windows-clients" `
  /qn /l*v C:\Temp\wazuh-install.log'

# Service starten und auf automatisch setzen
Start-Service WazuhSvc
Set-Service WazuhSvc -StartupType Automatic

# Verbindungsstatus prüfen
Get-Service -Name WazuhSvc | Select-Object Status, DisplayName, StartType

Der Windows-Agent überwacht standardmäßig die Windows-Ereignisprotokolle (Security Log für Anmelde-Events, System Log für Service-Änderungen, Application Log für Softwarefehler), den Registry-Pfad HKLM\Software auf Änderungen (wichtig für Malware-Persistenz-Erkennung) und ausgewählte Systemordner auf Dateiänderungen. Diese Konfiguration liegt in C:\Program Files (x86)\ossec-agent\ossec.conf und kann angepasst werden. Für Sicherheits-Auditing ist besonders der Windows Security Event Log mit den Event-IDs 4624 (Login), 4625 (Login-Fehler), 4688 (Prozessstart) und 4698 (geplante Task erstellt) relevant.

Schritt 6: Docker-Container mit dem Wazuh Docker Listener überwachen

Wazuh kann Docker-Ereignisse direkt abhören: Container-Starts und -Stopps, Image-Pulls, Volume-Mounts, Netzwerk-Konfigurationsänderungen und besonders gefährliche Aktionen wie das Starten privilegierter Container. Das Docker-Listener-Modul kommuniziert mit dem Docker-Daemon über den Unix-Socket und benötigt entsprechende Gruppenrechte.

# Auf dem Docker-Host (192.168.1.40) nach Agent-Installation
# Wazuh-Benutzer zur Docker-Gruppe hinzufügen
sudo usermod -aG docker wazuh

# Docker-Listener in /var/ossec/etc/ossec.conf aktivieren
# Füge innerhalb von  hinzu:

cat << 'EOF' | sudo tee /tmp/docker-listener.xml

  no
  10
  5
  yes

EOF

# Manuelle Einfügung: Füge den obigen Block in /var/ossec/etc/ossec.conf ein
# (vor dem schließenden -Tag)

# Agent neustarten
sudo systemctl restart wazuh-agent

# Testweise einen privilegierten Container starten
# (Wazuh sollte Alert Stufe 12 generieren)
docker run --rm --privileged alpine echo "Privilege-Escalation-Test"

# Events im Log prüfen
sudo tail -50 /var/ossec/logs/ossec.log | grep docker

Im Wazuh-Dashboard siehst du nach 60 Sekunden unter dem Agenten Docker-Events wie Docker: Container started, Docker: Image pulled und bei privilegierten Containern: Docker: Privileged container started (T1611). Das MITRE ATT&CK-Framework ordnet privilegierte Container-Starts der Technik T1611 (Escape to Host) unter der Taktik Privilege Escalation zu. Wazuh mappt dies automatisch und zeigt den MITRE-Link im Alert-Detail. Für Kubernetes-Umgebungen gibt es das separate Wazuh-Kubernetes-Modul, das Audit-Logs des API-Servers auswertet.

Schritt 7: Regelwerk verstehen und eigene Erkennungsregeln schreiben

Wazuh enthält über 3.000 vorinstallierte Erkennungsregeln, die vom Wazuh-Team regelmäßig aktualisiert werden. Die Regeln liegen im Verzeichnis /var/ossec/ruleset/rules/. Wichtig: Bearbeite Dateien in diesem Verzeichnis nie direkt, da sie bei jedem Update überschrieben werden. Eigene Regeln gehören ausschließlich in /var/ossec/etc/rules/local_rules.xml.

Jede Regel besteht aus einer eindeutigen ID (100000-119999 für eigene Regeln), einer Schweregradbewertung (Level 0-15) und einer Bedingung (regulärer Ausdruck, Elternregel-Referenz oder Decoder-Ausgabe). Hier sind praxisnahe Beispielregeln für häufige Angriffsmuster:

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="local,custom,">

  <!-- Alert wenn sudoers-Datei geändert wird (Privilege Escalation) -->
  <rule id="100001" level="12">
    <if_sid>5402</if_sid>
    <match>sudo: .* COMMAND=/usr/sbin/visudo</match>
    <description>Sudoers-Datei wurde bearbeitet - Privilege Escalation moeglich</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>

  <!-- Alert bei Root-Shell via sudo -->
  <rule id="100002" level="10">
    <if_sid>5402</if_sid>
    <match>sudo: .* COMMAND=/bin/bash|COMMAND=/bin/sh</match>
    <description>Root-Shell ueber sudo ausgefuehrt (T1548)</description>
    <mitre>
      <id>T1548.003</id>
    </mitre>
  </rule>

  <!-- Alert bei neuen cron-Jobs (Persistence) -->
  <rule id="100003" level="8">
    <if_group>syscheck</if_group>
    <match>/etc/cron|/var/spool/cron</match>
    <description>Cron-Verzeichnis geaendert - moegliche Persistence (T1053)</description>
    <mitre>
      <id>T1053.003</id>
    </mitre>
  </rule>

  <!-- Massendownload via curl/wget erkennen -->
  <rule id="100004" level="6">
    <if_sid>0</if_sid>
    <program_name>bash|sh</program_name>
    <match>curl.*http|wget.*http</match>
    <description>Download-Tool in Shell ausgefuehrt - Staging moeglich (T1105)</description>
    <mitre>
      <id>T1105</id>
    </mitre>
  </rule>

</group>

Nach dem Erstellen eigener Regeln muss die Syntax validiert und der Manager neugeladen werden:

# Regelvalidierung mit wazuh-logtest
sudo /var/ossec/bin/wazuh-logtest

# Beispieleingabe zum Testen der Regel 100001:
# Apr 10 12:00:00 server sudo:  admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/usr/sbin/visudo

# Manager-Regeln neu laden (kein Neustart nötig seit Wazuh 4.2)
sudo /var/ossec/bin/wazuh-control reload

# Oder vollständiger Neustart:
sudo systemctl restart wazuh-manager

Die Schweregradbewertung (Level) folgt einer festen Semantik: Level 0-2 sind Debug-Informationen, 3-5 niedrige Ereignisse (Login-Erfolge, Systemstarts), 6-9 mittlere Bedrohungen (fehlgeschlagene Logins, Konfigurationsänderungen), 10-12 hohe Bedrohungen (Privilege Escalation, Brute Force erkannt) und 13-15 kritische Angriffe (aktiver Einbruch, Rootkit-Erkennung). Standard-E-Mail-Alerts beginnen bei Level 10; Active Response bei Level 6 (konfigurierbar).

Schritt 8: Datei-Integritätsüberwachung (FIM) für kritische Pfade einrichten

File Integrity Monitoring (FIM) ist für Compliance-Anforderungen nach BSI-Grundschutz (OPS.1.1.5), PCI DSS (Anforderung 11.5) und NIS-2 unverzichtbar. FIM erkennt Änderungen an kritischen Systemdateien in Echtzeit oder nach einem festgelegten Zeitplan. Ein Angreifer, der /etc/passwd, /etc/sudoers oder Webserver-Skripte manipuliert, wird innerhalb von Sekunden entdeckt.

<!-- Erweiterte FIM-Konfiguration im Agent (/var/ossec/etc/ossec.conf) -->
<syscheck>
  <disabled>no</disabled>

  <!-- Vollständiger Scan alle 6 Stunden -->
  <frequency>21600</frequency>

  <!-- Echtzeit-Überwachung kritischer Systemdateien -->
  <directories realtime="yes" check_all="yes">/etc</directories>
  <directories realtime="yes" check_all="yes">/usr/bin,/usr/sbin</directories>
  <directories realtime="yes" check_all="yes" report_changes="yes">/root</directories>
  <directories realtime="yes" check_all="yes">/boot</directories>

  <!-- Webanwendungen überwachen -->
  <directories realtime="yes" check_all="yes" report_changes="yes">
    /var/www/html
  </directories>

  <!-- SSH-Konfiguration besonders schützen -->
  <directories realtime="yes" check_all="yes" report_changes="yes">
    /etc/ssh
  </directories>

  <!-- Ausnahmen für häufig ändernde Dateien (Rauschreduzierung) -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/resolv.conf</ignore>
  <ignore type="sregex">.log$|.tmp$|.pid$|.swp$</ignore>
  <ignore type="sregex">^/proc</ignore>
  <ignore type="sregex">^/sys</ignore>

  <!-- Scan-Geschwindigkeit begrenzen (CPU-Schonung) -->
  <max_files_per_second>100</max_files_per_second>

  <!-- Datenbankgröße begrenzen -->
  <database>disk</database>
</syscheck>

FIM erkennt sieben Arten von Änderungen: MD5/SHA1/SHA256-Hashänderungen, Besitzeränderungen (UID/GID), Berechtigungsänderungen (chmod), Dateigrößenänderungen, Erstellungsvorgänge (neue Dateien), Löschvorgänge und Inhaltsänderungen (bei aktiviertem report_changes="yes"). Im Wazuh-Dashboard erscheinen FIM-Events unter dem Modul “Integrity Monitoring”. Du kannst nach Dateipfad, Benutzer, Änderungstyp und Zeitraum filtern. Die historischen FIM-Events sind 90 Tage durchsuchbar (konfigurierbar über ILM).

Schritt 9: Brute-Force-Erkennung und automatische IP-Sperrung

Active Response ist eine der stärksten Wazuh-Funktionen für Systemhärtung in Echtzeit. Sie führt automatisch Gegenmaßnahmen aus, wenn definierte Regeln ausgelöst werden. Der häufigste Anwendungsfall: automatisches Blockieren von IP-Adressen, die SSH-Brute-Force-Angriffe durchführen.

<!-- Active Response in /var/ossec/etc/ossec.conf auf dem Manager -->

<!-- SSH Brute Force: Blockierung bei erkanntem Angriff (Regel 5763) -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>600</timeout>
  <!-- Whitelist: Admin-Netzwerke nie blockieren -->
  <white_list>192.168.1.0/24</white_list>
  <white_list>10.0.0.0/8</white_list>
</active-response>

<!-- Allgemeine Authentifizierungsfehler: Blockierung bei Level 6+ -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <level>6</level>
  <rules_group>authentication_failures</rules_group>
  <timeout>1800</timeout>
  <white_list>192.168.1.0/24</white_list>
</active-response>

<!-- Host-Blocking auch auf Agenten ausführen (location: all) -->
<active-response>
  <command>firewall-drop</command>
  <location>all</location>
  <rules_id>5763</rules_id>
  <timeout>600</timeout>
</active-response>

Das firewall-drop-Skript verwendet auf Linux-Systemen iptables oder nftables, auf macOS pf und auf Windows die Windows Firewall. Nach der Aktivierung teste die Funktion mit einem kontrollierten Brute-Force-Test von einer isolierten Test-IP (nicht der Produktionsmaschine):

# Active Response manuell auslösen (Test)
# Auf dem Manager ausführen:
sudo /var/ossec/bin/agent_control -b 203.0.113.5 -f firewall-drop0 -u 001

# Blockierte IPs auf dem Agenten prüfen
sudo iptables -L INPUT -n | grep DROP

# Wazuh Active Response Log
sudo tail -f /var/ossec/logs/active-responses.log

# Alert-Log auf Active Response Events prüfen
sudo grep "active-response" /var/ossec/logs/alerts/alerts.log | tail -20

Schritt 10: Vulnerability Detection für alle Endpunkte aktivieren

Das Vulnerability-Detection-Modul vergleicht die installierten Pakete aller Agenten gegen bekannte CVEs aus der National Vulnerability Database (NVD), RedHat Security Advisories, Canonical USN (Ubuntu Security Notices) und OVAL-Feeds. Die Schwachstellendatenbank wird automatisch alle 60 Minuten aktualisiert.

<!-- Vulnerability Detection im Manager (/var/ossec/etc/ossec.conf) -->
<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

<!-- Syscollector auf Agenten aktivieren (Software-Inventar) -->
<wodle name="syscollector">
  <disabled>no</disabled>
  <interval>1h</interval>
  <scan_on_start>yes</scan_on_start>
  <packages>yes</packages>
  <os>yes</os>
  <processes>yes</processes>
  <ports all="no">yes</ports>
  <network>yes</network>
  <hotfixes>yes</hotfixes>
</wodle>

Nach Aktivierung zeigt das Dashboard unter “Vulnerability Detection” alle gefundenen CVEs je Agent, sortiert nach Schweregrad (Critical, High, Medium, Low, Informational). Jeder Eintrag enthält die CVSS-Bewertung (v2 und v3), die betroffene Paketversion, ob ein Patch verfügbar ist, und einen direkten Link zur NVD-Datenbank. Die Hotfix-Erkennung auf Windows vergleicht installierte KB-Patches mit den aktuellen Microsoft Security Updates und meldet fehlende Patches als Schwachstellen.

In einem typischen Ubuntu-24.04-System, das 30 Tage ohne Updates lief, findet Wazuh zwischen 15 und 80 bekannte Schwachstellen. Ein frisch gepatchtes System zeigt in der Regel 0-5 Low-Severity-CVEs, die auf Kernel-Versionen zurückgehen, die noch keinen öffentlichen Patch haben.

Schritt 11: E-Mail-Benachrichtigungen und Slack-Integration

Wazuh-Alerts sind nur nützlich, wenn das Team sie sieht. Konfiguriere E-Mail-Benachrichtigungen für kritische Alerts und optionale Slack-Webhooks für schnelle Reaktionszeiten im SOC-Team. Die E-Mail-Konfiguration erfolgt im <global>-Block der Manager-Konfiguration:

<!-- E-Mail-Konfiguration in /var/ossec/etc/ossec.conf -->
<global>
  <jsonout_output>yes</jsonout_output>
  <alerts_log>yes</alerts_log>
  <email_notification>yes</email_notification>
  <smtp_server>smtp.example.de</smtp_server>
  <smtp_port>587</smtp_port>
  <email_from>[email protected]</email_from>
  <email_to>[email protected]</email_to>
  <email_maxperhour>12</email_maxperhour>
  <email_alert_level>10</email_alert_level>
</global>

<!-- Slack-Integration (Webhook) -->
<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/DEIN/WEBHOOK/TOKEN</hook_url>
  <level>10</level>
  <alert_format>json</alert_format>
</integration>

<!-- PagerDuty-Integration für On-Call-Teams -->
<integration>
  <name>pagerduty</name>
  <api_key>DEIN_PAGERDUTY_INTEGRATION_KEY</api_key>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>

Wazuh unterstützt neben Slack und PagerDuty auch Microsoft Teams, TheHive (Open-Source-Incident-Response-Plattform), Jira und IBM QRadar über die Integration-Engine. Für komplexe SOAR-Workflows ist die REST-API auf Port 55000 besser geeignet: Sie ermöglicht vollständige Automatisierung von Alert-Triage, Ticket-Erstellung und Gegenmaßnahmen-Auslösung über Tools wie Shuffle oder n8n.

Schritt 12: MITRE ATT&CK-Dashboard und Compliance-Berichte nutzen

Das Wazuh-Dashboard enthält ein eingebautes MITRE ATT&CK-Panel, das alle Alerts automatisch den entsprechenden Taktiken und Techniken zuordnet. Die Heatmap zeigt auf einen Blick, welche ATT&CK-Phasen in deiner Umgebung am häufigsten ausgelöst werden. Das ist besonders wertvoll für das Reporting an CISO-Ebene und für externe Audits.

Für Compliance-Berichte (PCI DSS, HIPAA, GDPR, NIS-2) navigiere im Dashboard zu “Regulatory Compliance”. Wazuh mappt seine Regeln automatisch auf diese Standards. Berichte lassen sich als PDF exportieren oder über die API abrufen:

# Wazuh REST-API: Authentifizierung und Abfragen
# Schritt 1: JWT-Token abrufen
TOKEN=$(curl -k -s -u "wazuh:DEIN_API_PASSWORT" \
  -X POST "https://192.168.1.10:55000/security/user/authenticate?raw=true")

# Schritt 2: Alle aktiven Agenten auflisten
curl -k -s -X GET "https://192.168.1.10:55000/agents?status=active&limit=50" \
  -H "Authorization: Bearer $TOKEN" | python3 -m json.tool | head -50

# Schritt 3: Kritische Schwachstellen aller Agenten abfragen
curl -k -s -X GET "https://192.168.1.10:55000/vulnerability/agents?severity=critical" \
  -H "Authorization: Bearer $TOKEN" | python3 -m json.tool

# Schritt 4: Letzte 10 kritischen Alerts (Level 12+) exportieren
curl -k -s -X GET "https://192.168.1.10:55000/alerts?level=12&limit=10&sort=-timestamp" \
  -H "Authorization: Bearer $TOKEN" | python3 -m json.tool

Wazuh deckt folgende PCI-DSS-Anforderungen ab: 10.5 (Protokollschutz), 10.6 (Protokollauswertung), 11.5 (Dateiintegritätsüberwachung) und 11.4 (Intrusion Detection). Für NIS-2-konforme Unternehmen in Deutschland liefert die automatische Protokollierung mit Index-basierter Tamper-Evidenz die geforderte Aufzeichnung sicherheitsrelevanter Ereignisse. Verlängere die Aufbewahrungsdauer im ILM-Policy auf 365 Tage (statt Standard 90 Tage), um die NIS-2-Anforderung für die 12-monatige Protokollaufbewahrung zu erfüllen.

5 häufige Fehler bei der Wazuh-Installation und wie du sie vermeidest

Diese Fallstricke kosten bei der Erstinstallation regelmäßig Stunden und frustrieren Einsteiger:

Fehler	Symptom	Ursache	Lösung
`vm.max_map_count` zu niedrig	Wazuh Indexer startet nicht	OpenSearch-Anforderung nicht erfüllt	`sysctl -w vm.max_map_count=262144` + /etc/sysctl.conf
Swap aktiviert	Indexer-Timeouts, schlechte Performance	OpenSearch braucht kein Swap	`swapoff -a` + /etc/fstab bereinigen
Port 1514/1515 blockiert	Agent “Never connected”	Firewall blockiert Enrollment-Port	UFW/iptables: Port 1514 und 1515 öffnen
Falsche Zeitzone auf Agenten	Timestamps falsch, Korrelation schlägt fehl	NTP nicht aktiv oder falsche Zone	`timedatectl set-ntp true` auf allen Hosts
Eigene Regeln in /ruleset/ gespeichert	Regeln nach Update verschwunden	Update überschreibt /ruleset/	Nur `/var/ossec/etc/rules/local_rules.xml` verwenden
Active Response ohne Whitelist	Admin-IPs werden gesperrt	Eigene IPs nicht ausgenommen	`<white_list>` für interne Netze setzen
Dashboard-Zertifikat abgelaufen	Browser-Fehler 525 nach einem Jahr	Selbst signierte Certs (1 Jahr Gültigkeit)	Zertifikate mit wazuh-certs-tool.sh erneuern

Kritischer Pitfall: Pseudo-Dateisysteme in FIM überwachen

Ein häufiger Fehler bei der FIM-Konfiguration ist es, /proc oder /sys in die Überwachungsliste aufzunehmen. Diese Pseudo-Dateisysteme ändern sich ständig (Tausende Änderungen pro Sekunde), überfluten das Dashboard mit False Positives und verursachen hohe CPU-Last auf dem Agenten (wazuh-syscheckd-Prozess). Schließe sie immer explizit aus:

<!-- Immer diese Ausnahmen in syscheck setzen -->
<ignore type="sregex">^/proc</ignore>
<ignore type="sregex">^/sys</ignore>
<ignore type="sregex">^/dev</ignore>
<ignore type="sregex">^/run</ignore>

Wazuh SIEM vs. Splunk vs. ELK Stack: Direkter Vergleich

Wazuh positioniert sich als sicherheitsspezialisierte, kostenfreie Alternative zu Splunk und zum generischen ELK-Stack. Der wichtigste Unterschied: Wazuh wurde von Grund auf als Sicherheitsplattform gebaut, während ELK ein generisches Log-Analyse-Tool ist und Splunk erst durch Erweiterungen Sicherheitsfunktionen erhält.

Kriterium	Wazuh 4.9	Splunk Enterprise	ELK Stack 8.x
Kosten (100 Agenten/Jahr)	0 € (Open Source)	ca. 47.000 $	0 € (Basis) / 10.560 $ (Elastic Security)
MITRE ATT&CK-Mapping	Eingebaut, 3.000+ Regeln	Erweiterung (MITRE ATT&CK App)	Nur mit Elastic Security
Vulnerability Detection	Eingebaut (NVD, RedHat, Canonical)	Kostenpflichtige Add-ons	Nicht eingebaut
File Integrity Monitoring	Eingebaut, Echtzeit	Add-on (Splunk UBA)	Nicht eingebaut
Active Response	50+ eingebaute Skripte	SOAR-Integration nötig	Nicht eingebaut
Endpoint-Agent	Eigener Lightweight-Agent	Splunk UF/HF	Beats/Elastic Agent
Setup-Aufwand	45 Min (All-in-One-Skript)	1-3 Tage	4-8 Stunden (Basis)
Max. skalierbar	100.000+ (Cluster)	Unbegrenzt (Splunk Cloud)	Unbegrenzt (Managed)
NIS-2-Compliance	Eingebaut (GDPR, PCI, NIS-2)	Mit Enterprise Security App	Nur mit kostenpfl. Erweiterung

Für KMUs und Organisationen ohne dediziertes SOC-Team ist Wazuh die beste Wahl: es liefert sofort einsetzbare Sicherheitsfunktionen ohne Lizenzkosten und ohne tiefes SIEM-Expertenwissen. Splunk überzeugt bei Enterprise-Deployments mit komplexen Korrelationsanforderungen und dediziertem Analyse-Team. Der ELK-Stack eignet sich, wenn die primäre Anforderung Log-Analyse für Anwendungen ist und Sicherheitsüberwachung sekundär bleibt. Wazuh und ELK können kombiniert werden: Wazuh-Indexer basiert auf OpenSearch (einem OpenSearch-Fork), und Wazuh-Alerts lassen sich in einen separaten ELK-Stack weiterleiten.

Hochverfügbarkeit: Wazuh Manager-Cluster einrichten

Für Produktionsumgebungen mit Verfügbarkeitsanforderungen empfiehlt sich ein Wazuh-Manager-Cluster mit mindestens zwei Knoten (Master + Worker). Ein Ausfall des Single-Node-Setups bedeutet blinde Flecken in der Sicherheitsprotokollierung. Der Manager-Cluster funktioniert im Master/Worker-Modell: der Master verwaltet die Konfiguration und Agenten-Zuordnung, Worker-Knoten verarbeiten die Agenten-Events.

# Cluster-Konfiguration auf dem Master-Node
# /var/ossec/etc/ossec.conf (Master)
<cluster>
  <name>wazuh-cluster-prod</name>
  <node_name>master-node</node_name>
  <node_type>master</node_type>
  <key>$(openssl rand -hex 16)</key>
  <port>1516</port>
  <bind_addr>0.0.0.0</bind_addr>
  <nodes>
    <node>192.168.1.10</node>
    <node>192.168.1.11</node>
  </nodes>
  <hidden>no</hidden>
  <disabled>no</disabled>
</cluster>

# Auf Worker-Nodes: node_type auf "worker" setzen
# Cluster-Status überwachen:
sudo /var/ossec/bin/cluster_control -l

# Erwartete Ausgabe:
# NAME         TYPE    VERSION  ADDRESS
# master-node  master  4.9.0    192.168.1.10
# worker-node  worker  4.9.0    192.168.1.11

Der Cluster-Key muss auf allen Knoten identisch sein. Generiere ihn einmalig mit openssl rand -hex 16 und verteile ihn sicher (z.B. über HashiCorp Vault oder Ansible Vault). Ein kompromittierter Cluster-Key ermöglicht es einem Angreifer, einen gefälschten Worker-Knoten einzuschleusen und Alerts zu manipulieren. Wechsle den Cluster-Key alle 90 Tage oder nach mutmaßlicher Kompromittierung.

8 Troubleshooting-Tipps für Wazuh SIEM Probleme

1. Agent zeigt “Never connected” im Dashboard. Prüfe die Manager-IP-Adresse in /var/ossec/etc/ossec.conf auf dem Agenten. Teste die Port-Erreichbarkeit mit telnet 192.168.1.10 1514 und telnet 192.168.1.10 1515. Falls telnet nicht verfügbar: nc -zv 192.168.1.10 1514. Prüfe die UFW-Regeln auf dem Manager: sudo ufw status verbose.

2. Dashboard zeigt “No results” obwohl Agenten aktiv sind. Prüfe den Indexer-Cluster-Status: curl -k -u admin:PASSWORT https://localhost:9200/_cat/health. Ein “red” Status bedeutet nicht beschreibbare Indizes. Häufigste Ursache: Festplatte zu über 85 % belegt (OpenSearch Flood Watermark). Lösung: Speicher freimachen oder ILM-Löschpolicy verschärfen.

3. Wazuh Indexer startet nach Update nicht. Prüfe das Journal: journalctl -u wazuh-indexer -n 200 --no-pager. OpenSearch-Major-Updates erfordern manchmal Index-Migration. Der Fehler “index.version.created” zeigt veraltete Index-Mappings. Lösung: Indizes mit veralteten Mappings löschen (außer Produktionsdaten) oder mit einer Snapshot-Strategie migrieren.

4. Zu viele False-Positive-Alerts überfluten das Dashboard. Nutze /var/ossec/bin/wazuh-logtest, um problematische Protokollzeilen durch das Regelwerk zu testen und die auslösende Regel zu identifizieren. Erhöhe den Level-Schwellenwert der betroffenen Regel um 2-3 Stufen in local_rules.xml oder füge eine Ausnahme-Regel mit overwrite="yes" hinzu.

5. Windows-Agent sendet nach Windows-Update keine Events mehr. Windows Defender kann den Wazuh-Agent-Prozess nach Updates blockieren. Füge den Wazuh-Installationspfad (C:\Program Files (x86)\ossec-agent\) als Ausnahme in Windows Defender Antivirus ein. Prüfe im Windows Event Log, ob der WazuhSvc-Service einen Startfehler zeigt (Event ID 7000).

6. Hohe CPU-Last durch wazuh-syscheckd-Prozess. FIM-Konfiguration überwacht zu viele Dateien oder zu häufig. Prüfe, ob /proc, /sys oder /dev versehentlich überwacht werden. Erhöhe <frequency> auf 43200 (12 Stunden) für Nicht-Echtzeit-Verzeichnisse. Setze <max_files_per_second>50</max_files_per_second> für CPU-Schonung.

7. Dashboard-Timeout bei vielen Agenten und Abfragen. Erhöhe den OpenSearch-Request-Timeout in /etc/wazuh-dashboard/opensearch_dashboards.yml: opensearch.requestTimeout: 120000. Bei mehr als 500 Agenten sollte der Indexer mit 3 Knoten geclustert werden. Überprüfe außerdem, ob Abfragen zu breite Zeitfenster (z.B. “Letzte 90 Tage”) abfragen.

8. API-Aufrufe schlagen mit “401 Unauthorized” fehl. Wazuh-API-JWT-Tokens laufen nach 900 Sekunden (15 Minuten) ab. Skripte müssen Tokens regelmäßig erneuern. Prüfe die Token-Gültigkeit mit jwt.io (Decode des Bearer-Tokens). Für lang laufende Automatisierungen: erhöhe die Token-Laufzeit in /var/ossec/api/configuration/api.yaml unter auth_token_exp_timeout.

Wazuh SIEM für NIS-2 und KRITIS-Dachgesetz in Deutschland

Deutsche Unternehmen stehen 2026 unter erheblichem Regulierungsdruck. Das NIS-2-Umsetzungsgesetz betrifft 29.500 Organisationen und schreibt technische Sicherheitsmaßnahmen, Protokollierung und Vorfallsmeldung innerhalb von 24 Stunden vor. Das KRITIS-Dachgesetz mit Deadline 17. Juli 2026 verschärft die Anforderungen für kritische Infrastrukturen mit Bußgeldern bis 1 Million Euro.

Wazuh adressiert konkrete NIS-2-Anforderungen aus Artikel 21: Das FIM-Modul liefert die nach BSI-Grundschutz-Baustein OPS.1.1.5 geforderte Integritätsüberwachung. Das Vulnerability-Detection-Modul unterstützt das Patch-Management nach BSI-Grundschutz-Baustein OPS.1.1.3. Die Active-Response-Funktion ermöglicht automatisierte Gegenmaßnahmen nach DER.2.1 (Behandlung von Sicherheitsvorfällen). Die Compliance-Reports im Dashboard dokumentieren den Sicherheitsstatus für externe Audits nach ISO 27001 und BSI-Grundschutz.

Für vollständige NIS-2-Konformität empfiehlt sich eine Aufbewahrungsdauer von 12 Monaten (Verlängerung über ILM), tägliche Compliance-Reports als PDF (automatisierbar per API) und die Integration mit einem Ticket-System für Vorfallsmeldungen (TheHive oder Jira) mit definierten SLAs für kritische Alerts. Die automatische 24-Stunden-Meldepflicht bei erheblichen Sicherheitsvorfällen lässt sich durch Wazuh-Active-Response-Skripte an das BSI-Meldungsportal ankoppeln.

Fortgeschrittene Optimierungen für Langzeitbetrieb

Index Lifecycle Management (ILM) konfigurieren: Ohne ILM füllt die tägliche Indexerstellung die Festplatte innerhalb von Wochen. Richte über das Dashboard unter “Stack Management > Index Lifecycle Policies” einen automatischen Rollover (nach 30 GB oder 30 Tagen) und eine automatische Löschung (nach 90 oder 365 Tagen) ein. Für NIS-2 nutze eine 12-Monats-Retention-Policy.

Agenten-Gruppen für skalierbare Konfiguration: Statt jede Agent-Konfiguration manuell zu verwalten, nutze Wazuh-Gruppen. Erstelle Gruppen (linux-servers, windows-desktops, docker-hosts, web-servers) über die API oder das Dashboard. Konfigurationsänderungen werden automatisch an alle Gruppenagenten verteilt, ohne jeden Host einzeln anzupassen.

Alert-Aggregation mit Deduplication: Wiederholende Events aus cron-Jobs, Backup-Software oder Log-Rotation können das Dashboard überfluten. Nutze <frequency> und <timeframe> in Regeln: <same_source_ip /> bündelt wiederholende Alerts von der gleichen Quelle zu einem einzigen aggregierten Alert.

Automatische Regelupdates via Cron: Wazuh veröffentlicht wöchentlich aktualisierte Regeln für neue CVEs und Angriffsmuster. Automatisiere Updates mit einem Cron-Job, der nachts läuft und nach dem Update den Manager-Reload auslöst: 0 2 * * 0 apt update && apt install --only-upgrade wazuh-manager -y && /var/ossec/bin/wazuh-control reload.

FAQ: Wazuh SIEM

Ist Wazuh wirklich kostenlos, oder gibt es versteckte Kosten?

Wazuh ist vollständig Open Source unter der GPL-2.0-Lizenz. Das gilt für alle Komponenten: Manager, Indexer, Dashboard und Agenten. Es gibt keine Agentenlizenzen, keine Datenmengen-Beschränkungen und keine kommerziellen Features hinter einer Paywall. Wazuh Inc. bietet kommerzielle Support-Pakete an, die Hosting, professionellen Support und dedizierte Threat-Intelligence-Feeds einschließen. Die Software selbst bleibt ohne jede Einschränkung kostenlos nutzbar.

Wie viele Agenten kann ein einzelner Wazuh-Server verwalten?

Ein Single-Node-Wazuh-Server mit 8 CPU-Kernen und 16 GB RAM verwaltet nach Wazuh-Dokumentation zuverlässig bis zu 500 Agenten. Mit einem Manager-Cluster (Master + Worker) skaliert Wazuh auf über 100.000 Agenten. Der Wazuh-Indexer ist der Flaschenhals bei der Skalierung; für mehr als 1.000 Agenten empfiehlt Wazuh einen 3-Knoten-OpenSearch-Cluster mit dedizierten Coordinator-Nodes.

Kann Wazuh einen kommerziellen EDR ersetzen?

Wazuh liefert viele Kernfunktionen eines EDR: Prozessüberwachung, FIM, Schwachstellenerkennung und Active Response. Für KMUs ist es ein vollwertiger EDR-Ersatz. Enterprise-EDR-Produkte wie CrowdStrike Falcon oder SentinelOne bieten darüber hinaus ML-basierte Verhaltensanalyse, automatische Forensik-Snapshots und integrierte Threat-Intelligence-Feeds mit IOC-Matching in Echtzeit. Wazuh lässt sich mit MISP oder OTX-Threat-Intelligence-Feeds erweitern, erfordert aber mehr Konfigurationsaufwand als kommerzielle Lösungen.

Wie lange dauert die Einrichtung in einem Unternehmensumfeld realistisch?

Die reine Server-Installation dauert 45 Minuten. Das Onboarding der ersten 10 Agenten benötigt weitere 1-2 Stunden. Die Erstanpassung der Regelkonfiguration an die Unternehmensumgebung (False-Positive-Tuning, eigene Regelkonfiguration, Integrations-Setup) dauert in einem 50-Personen-Unternehmen typischerweise 2 bis 3 Werktage. Die laufende Pflege beträgt ca. 2 bis 4 Stunden pro Woche für einen erfahrenen Administrator.

Kann Wazuh Cloud-Dienste wie AWS CloudTrail überwachen?

Ja. Wazuh hat eingebaute Module für AWS CloudTrail, AWS S3, AWS Config, AWS GuardDuty, Azure Active Directory, Azure Log Analytics, Azure Activity und Google Cloud Pub/Sub. Die Protokolle werden direkt über die jeweiligen Cloud-APIs abgeholt, ohne einen Agenten auf Cloud-Infrastruktur zu benötigen. Für Microsoft 365 gibt es das Microsoft Graph API-Modul, das Teams-, Exchange- und SharePoint-Aktivitäten erfasst.

Welche Protokollformate versteht Wazuh nativ?

Wazuh versteht nativ über 400 Protokollformate: Syslog (RFC 3164 und 5424), Apache/Nginx/IIS-Zugriffsprotokolle, Windows Event Log (EVTX und XML), MySQL/PostgreSQL Query Logs, Cisco IOS, Palo Alto PAN-OS, Fortinet FortiGate, Auditd, Suricata-EVE-JSON, Zeek (früher Bro), OpenVPN und viele mehr. Für unbekannte Formate definierst du eigene Decoder mit regulären Ausdrücken in /var/ossec/etc/decoders/local_decoder.xml.

Wie sichere ich das Wazuh-Dashboard gegen unbefugten Zugriff ab?

Das Dashboard läuft standardmäßig auf Port 443 mit einem selbst signierten Zertifikat. Empfohlene Härtungsmaßnahmen: Erstens, ersetze das selbst signierte Zertifikat durch ein Let’s-Encrypt- oder Unternehmens-CA-Zertifikat. Zweitens, aktiviere TOTP-basierte Zwei-Faktor-Authentifizierung über das OpenSearch Security Plugin. Drittens, beschränke den Dashboard-Zugriff per iptables oder Nginx Reverse Proxy auf definierte Admin-IP-Ranges. Viertens, ändere alle Standard-Credentials aus der Passwortdatei unmittelbar nach der Installation und setze starke Passwörter (min. 24 Zeichen).

Wazuh SIEM einrichten: Open-Source Security in 12 Schritten [2026]