Wazuh als Open-Source-SIEM und XDR: Einsatz, Grenzen, Einrichtung

Wazuh ist das Open-Source-Werkzeug, mit dem die meisten Blue Teams ihr erstes SIEM aufbauen, und für viele kleine und mittlere Organisationen bleibt es das einzige. Agent auf jedem System, zentrale Analyse, Dashboard, dazu Dateiintegritätsüberwachung, Konfigurationsprüfung gegen CIS-Benchmarks, Schwachstellenerkennung und automatische Reaktion, alles ohne Lizenzkosten. Das Marketing nennt es XDR und SIEM in einem; die Wahrheit liegt dazwischen und ist trotzdem beachtlich. Dieser Beitrag beschreibt, was Wazuh kann, wie es aufgebaut ist, wie du es in vier Schritten sinnvoll einrichtest, wo seine Grenzen liegen und für wen es die richtige Wahl ist. Versionsstand: Wazuh 4.14.

Was Wazuh ist

Wazuh entstand 2015 als Abspaltung des Host-IDS OSSEC und hat sich seither zu einer vollständigen Sicherheitsplattform entwickelt. Der Code steht unter GPL, hinter dem Projekt steht ein Unternehmen, das Cloud-Hosting und Support verkauft, die Software selbst bleibt frei. Vier Komponenten bilden das System: der Agent auf den überwachten Systemen (Windows, Linux, macOS), der Server, der die Daten entgegennimmt und gegen Regeln prüft, der Indexer, eine OpenSearch-Instanz, die Ereignisse und Alarme speichert, und das Dashboard als Weboberfläche. Netzwerkgeräte und Systeme ohne Agent liefern per Syslog.

Was Wazuh kann

• Logsammlung und Analyse. Der Agent liest Windows-Ereigniskanäle, Linux-Logs, Anwendungslogs und Kommandoausgaben; der Server zerlegt sie mit Decodern in Felder und prüft sie gegen Regeln mit Schweregraden von 0 bis 15. Tausende Regeln sind mitgeliefert, viele mit Zuordnung zu MITRE ATT&CK, die das Dashboard als Abdeckungsansicht darstellt.
• Dateiintegrität. Änderungen an Dateien und Registry-Schlüsseln, auf Wunsch mit dem Benutzer und Prozess, der sie ausgelöst hat. Für Webserver-Verzeichnisse, Systemdateien und Autostart-Schlüssel unverzichtbar.
• Konfigurationsprüfung. Der Agent prüft das System gegen CIS-Benchmarks und meldet Abweichungen: Passwortrichtlinien, offene Dienste, Dateiberechtigungen. Für Audits und Härtungsprojekte oft der erste Grund, Wazuh einzusetzen.
• Schwachstellenerkennung. Das Software-Inventar jedes Agenten wird gegen CVE-Datenbanken abgeglichen. Kein Ersatz für einen Schwachstellenscanner, aber ein laufender Überblick ohne Scan.
• Aktive Reaktion. Auf einen Alarm hin kann der Agent eine Adresse in der Firewall sperren, ein Konto deaktivieren oder ein Skript ausführen. Mit Bedacht einzusetzen, aber vorhanden.
• Cloud und Container. Integrationen für AWS, Azure, Google Cloud, Microsoft 365, Docker und Kubernetes holen deren Audit-Logs in dieselbe Analyse.

Einrichtung in vier Schritten

1. Server installieren

Für bis zu einigen Dutzend Agenten reicht die All-in-one-Installation auf einer Linux-VM mit 8 GB RAM, die das Installationsskript aus dem Quickstart der Wazuh-Dokumentation in einem Durchlauf einrichtet: Server, Indexer und Dashboard auf einem System, Zertifikate inklusive. Größere Umgebungen verteilen die Komponenten auf mehrere Systeme und betreiben Server und Indexer als Cluster; der Weg dorthin ist in der Dokumentation beschrieben und später ohne Neuanfang möglich.

2. Agenten verteilen

Das Dashboard erzeugt für jedes Betriebssystem den Installationsbefehl mit Serveradresse und Gruppenzuordnung. Unter Windows ist das ein MSI-Paket mit Parametern, das sich per Gruppenrichtlinie oder Softwareverteilung ausrollen lässt. Agenten registrieren sich selbst, tauchen im Dashboard auf und bekommen ihre Konfiguration über Gruppen zentral zugewiesen, sodass Domain Controller andere Einstellungen bekommen können als Arbeitsplätze.

3. Die Windows-Kanäle eintragen, die fehlen

Der Windows-Agent liest in der Standardkonfiguration die Kanäle Application, Security und System. Die Quellen, die für die Erkennung am meisten wert sind, fehlen: Sysmon und PowerShell. Sie werden in der Agentenkonfiguration der jeweiligen Gruppe ergänzt:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>
<localfile>
  <location>Microsoft-Windows-PowerShell/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Danach kommen die Ereignisse an, und die mitgelieferten Sysmon-Regeln greifen. Das ist der Schritt, der in fast jeder Wazuh-Installation vergessen wird und dazu führt, dass die Endpunkt-Telemetrie lokal vorliegt und zentral nie ankommt. Welche Windows-Ereignisse darüber hinaus lohnen, steht in der Referenz.

4. Eigene Regeln und Schwellen

Eigene Regeln stehen in einer separaten Datei für lokale Regeln und überleben Updates. Eine Regel baut auf einer mitgelieferten auf, prüft Felder und vergibt Schweregrad und ATT&CK-Zuordnung. Ein Beispiel, das den Zugriff auf den LSASS-Prozess auf Stufe 12 hebt:

<group name="local,sysmon,credential_access,">
  <rule id="100100" level="12">
    <if_group>sysmon</if_group>
    <field name="win.system.eventID">^10$</field>
    <field name="win.eventdata.targetImage" type="pcre2">(?i)\\lsass\.exe$</field>
    <description>Sysmon: Zugriff auf lsass.exe durch $(win.eventdata.sourceImage)</description>
    <mitre>
      <id>T1003.001</id>
    </mitre>
  </rule>
</group>

Nach dem ersten Betriebstag zeigt das Dashboard, welche Regeln das Volumen erzeugen. Dieselbe Regel-Hygiene wie bei jedem SIEM gilt hier: die lautesten Regeln anpassen, Schwellen nach oben nur mit Begründung, und jede aktivierte Regel einmal mit der passenden Technik testen. Wer seine Erkennungen zusätzlich als Sigma-Regeln pflegt, kann sie mit dem Wazuh-Backend von pySigma in dieses Format übersetzen.

Grenzen

• Korrelation. Die Regelmaschine arbeitet ereignisbasiert. Häufigkeit und Zeitfenster pro Regel gehen, komplexe Verknüpfungen über mehrere Quellen und Entitäten hinweg, wie sie kommerzielle SIEMs bieten, sind nur mit Umwegen über den Indexer möglich.
• Kein XDR im engeren Sinn. Wazuh sieht, was seine Agenten und Integrationen liefern, und reagiert über die aktive Reaktion. Die Tiefe eines kommerziellen EDR mit Speicheranalyse, Verhaltensmodellen und Isolierung per Knopfdruck erreicht es nicht; als Ergänzung zu Sysmon ist es dafür in seinem Element.
• Skalierung braucht Planung. Ab einigen hundert Agenten mit Sysmon-Telemetrie ist der Indexer der Engpass. Speicher, Aufbewahrung und Cluster-Aufbau müssen vorher dimensioniert werden.
• Betrieb kostet Zeit statt Geld. Updates, Zertifikate, Indexverwaltung, Regelpflege: alles Aufgaben, die bei einem kommerziellen Produkt der Hersteller übernimmt.
• Kein Fallmanagement. Alarme werden angezeigt, aber nicht als Fälle mit Status und Zuständigkeit geführt. Dafür braucht es ein Werkzeug daneben, etwa TheHive.

Wazuh im Vergleich

Für wen Wazuh die richtige Wahl ist

Für das Homelab und für Organisationen bis einige hundert Systeme, die zum ersten Mal zentrale Logs, Dateiintegrität und Konfigurationsprüfung brauchen, ist Wazuh die pragmatische Wahl: ein System, ein Agent, ein Dashboard, kein Lizenzgespräch. Für Managed-Service-Anbieter mit vielen kleinen Kunden ist es wegen der Mandantenfähigkeit über Gruppen und der Kostenstruktur beliebt. Wer dagegen komplexe Korrelation über Dutzende Quellen, ein Fallmanagement und Hersteller-Support braucht, betreibt Wazuh als Endpunkt-Ebene unter einem größeren SIEM oder wählt gleich ein kommerzielles Produkt. Beides ist legitim; falsch ist nur, Wazuh zu installieren und die Regelpflege dem Zufall zu überlassen.

Fazit

Wazuh gibt einem Blue Team ohne Budget das, was vor zehn Jahren sechsstellige Lizenzen kostete: zentrale Sicht auf jeden Endpunkt, Regeln mit ATT&CK-Bezug, Integritäts- und Konfigurationsüberwachung. Die Grenzen liegen bei Korrelation, Skalierung und Fallmanagement, und sie sind bekannt, bevor man anfängt. Wer die zwei Windows-Kanäle einträgt, die die Standardinstallation vergisst, und die Regeln pflegt wie bei jedem anderen SIEM, hat eine Erkennung, die den meisten Angreifern reicht.