Wazuh Alerting und Korrelation verstehen: Von Out-of-the-Box-Regeln bis zu eigenen Frequency/Timeframe-Detections

von

Einleitung

Wazuh wird häufig zuerst als „SIEM mit Indexer“ wahrgenommen: Logs werden eingesammelt, indexiert und sind im Dashboard durchsuchbar. Der eigentliche Sicherheitsmehrwert entsteht aber nicht in der Datenbank, sondern im Analyse- und Regelwerk des Wazuh Managers: Rohdaten werden dekodiert, zu Events normalisiert und anschließend über Regeln, Schwellenwerte und Korrelation in Alerts verwandelt. Wer verstehen will, warum ein einzelner SSH-Fehllogin meist „nur“ ein Low-Level-Alert ist, aber fünf Fehlschläge in kurzer Zeit als Brute-Force-Verdacht hochgestuft werden können, muss die Wazuh-Regel-Engine und ihre Mechanismen kennen.

Dieser Beitrag liefert einen praxisnahen Einstieg: Welche Alerting-Funktionalitäten Wazuh standardmäßig mitbringt, wie die Korrelation technisch funktioniert, wo man die Regeln findet (lokal und auf GitHub) und wie man typische Anwendungsfälle wie „x Fehlversuche pro Minute“ sauber modelliert.

Ausgangslage / Problemstellung

  • Es gibt bereits viele Logdaten im Indexer (OpenSearch-basiert), aber die Frage ist: Wie entstehen Alerts daraus?
  • Wunsch nach „echter“ Korrelation:
    • Ein einzelner SSH-Fehllogin ist meist unkritisch
    • Häufungen (z. B. x Versuche pro Minute) oder Muster (Fehlschläge → erfolgreicher Login) sind relevant
  • Verständnisfragen:
    • Was kann Wazuh „out of the box“?
    • Wo liegen die Regeldateien?
    • Gibt es eine übersichtliche Quelle außerhalb der XML-Dateien?

Technische Analyse

1) Wo Alerting in Wazuh tatsächlich passiert

Alerts werden in Wazuh nicht „in Elasticsearch/OpenSearch“ definiert. Der Indexer speichert und macht suchbar – die Detektion entsteht im Wazuh Manager, konkret in der Analyse-Pipeline:

  1. Pre-decoding (Syslog-Header, program_name, Host, Timestamp)
  2. Decoding (Decoder transformieren Rohlog → Felder/Struktur)
  3. Rule-Matching & Korrelation (Regeln bewerten Events, bilden Schwellenwerte/Sequenzen, erzeugen Alerts)

Die zentrale Komponente hierfür ist die Regel- und Korrelationslogik im Manager (regelbasiert, eventgetrieben, in Echtzeit).

2) „Korrelation“ in Wazuh: mehr als nur ein einzelnes Match

Wazuh korreliert Events über Mechanismen wie:

  • frequency + timeframe: „N Ereignisse in T Sekunden“
  • same_srcip / same_user / same_location / same_field: Aggregation/Korrelation über gemeinsame Attribute
  • if_sid / if_matched_sid: Abhängigkeiten zwischen Regeln (Stufenmodell)
  • Mehrstufige Patterns: z. B. „mehrere Fehlschläge“ gefolgt von „Erfolg“

Damit lässt sich genau der klassische Use Case abbilden:

  • Einzelner SSH-Fehler = low
  • Mehrere SSH-Fehler von derselben Quelle in kurzer Zeit = medium/high
  • Danach erfolgreicher Login = sehr hoch (Verdacht auf Credential Stuffing/Brute Force Erfolg)

3) „Was ist standardmäßig da?“ – sehr viel

Viele Administratoren unterschätzen die Menge an mitgelieferten Regeln. Wazuh liefert umfangreiche Regeln für:

  • Authentifizierung (SSH, sudo, PAM)
  • System- und Security-Events (Linux/Windows)
  • Audit-/Compliance-Mappings (z. B. PCI DSS, NIST, GDPR – als Klassifizierung/Tagging)
  • Häufige Angriffs- und Fehlkonfiguration-Muster

Wichtig dabei: Nicht jede Regel ist automatisch „Pager-tauglich“. Viele Out-of-the-Box-Regeln sind bewusst niedrig eingestuft und dienen als Signalbasis.

Lösung / Best Practices

1) Der beste Einstieg: Default Rules lesen, verstehen, testen

Auf dem Wazuh Manager liegen die Regeln typischerweise unter:

  • /var/ossec/ruleset/rules/ (mitgelieferte Regeln)
  • /var/ossec/etc/rules/ (eigene/angepasste Regeln)

Ein schneller Einstieg ist:

  • Eine bekannte Aktion auslösen (z. B. bewusstes sudo-Fehlpasswort, SSH-Fehllogin)
  • Im Dashboard nach dem Alert suchen
  • In den Rule-Dateien die Rule-ID nachschlagen und verstehen, welche Felder/Decoder dahinterstehen

Das beantwortet auch die praktische Frage:
„Wenn ich sudo ausführe und ein falsches Passwort nutze, sehe ich das in Wazuh?“
Ja – sofern die Logquelle erfasst wird (z. B. /var/log/auth.log oder journald je nach System) und der passende Decoder/Rule greift, wird ein Alert generiert. Ob das im Betrieb „alarmiert“ (E-Mail, Ticket, etc.) hängt dann von Alert-Management/Integrationen ab.

2) Regeln außerhalb des Managers zeigen: GitHub-Repository als Referenz

Wenn man Kollegen einen Überblick geben will, ohne auf dem Manager in XML zu wühlen, ist das öffentliche Ruleset-Repo der passende Einstieg: Dort sind die Rule-Dateien strukturiert und versioniert einsehbar. Für Reviews und „Was bringt Wazuh mit?“ ist das oft besser als ein Dump vom Server.

3) Korrelation bauen: Das klassische SSH-Beispiel in Wazuh-Regelsyntax

Beispiel A – Brute-Force-Verdacht (3 Fehlschläge in 20 Sekunden, gleiche Source IP):

<rule id="100100" level="8" frequency="3" timeframe="20">
  <if_matched_sid>5760</if_matched_sid>
  <same_srcip />
  <description>Multiple (3) SSH failed attempts from IP $(srcip) in 20 seconds.</description>
  <group>authentication_failed,</group>
</rule>

Beispiel B – Erfolg nach Fehlschlägen (hoch kritisch):

<rule id="100101" level="12" timeframe="10">
  <if_sid>5715</if_sid>
  <if_matched_sid>100100</if_matched_sid>
  <same_srcip />
  <description>Successful SSH connection from IP $(srcip) after 3 failed attempts.</description>
  <group>authentication_success,</group>
</rule>

Was hier passiert:

  • Regel 100100 korreliert mehrere Events (Fehlschläge) im Zeitfenster und erzeugt erst dann einen Alert.
  • Regel 100101 triggert nur, wenn zuvor 100100 aktiv war und nun ein passendes „Success“-Event kommt.

Das Muster ist universell und lässt sich auf VPN-Logins, API-Auth, SMTP, Web-Logins etc. übertragen.

4) Alerting „richtig“ nutzen: Stufen statt Lärm

Ein bewährtes Vorgehen ist ein mehrstufiges Regelwerk:

  • Low: einzelne Events (zur Sichtbarkeit)
  • Medium: Häufungen (frequency/timeframe)
  • High: Sequenzen/Erfolg nach Fehlversuchen, privilegierte Aktionen, ungewöhnliche Orte/Hosts
  • Optional: Active Response erst ab High (um False Positives zu vermeiden)

Lessons Learned / Best Practices

  1. Indexer ist nicht die Alert-Engine
    Der Indexer speichert und visualisiert. Die Detektion entsteht im Manager über Decoder + Rules.
  2. Korrelation ist in Wazuh regelbasiert und praxistauglich
    frequency/timeframe + same_* + if_matched_sid decken viele SIEM-Klassiker ab, ohne externe Correlation Engines.
  3. Out-of-the-box-Regeln sind Signalbasis, nicht automatisch Incident-Paging
    Viele Regeln sind bewusst niedrig priorisiert. Das ist kein Mangel, sondern ein Design für anpassbare Umgebungen.
  4. Beste Lernkurve: „Triggern → finden → Rule-ID lesen → nachbauen“
    Ein praktischer Test-Loop ist schneller als Dokumentation „von vorn“.
  5. Für Teamkommunikation: GitHub-Regelsatz als „Katalog“ nutzen
    Für Kollegen ist ein verlinkbarer, versionierter Überblick oft hilfreicher als lokale XML-Verzeichnisse.

Fazit

Wazuh-Alerting basiert nicht primär auf „Daten in OpenSearch“, sondern auf der Echtzeit-Analyse im Manager: Decoder strukturieren, Regeln bewerten und Korrelationsmechanismen verdichten Einzelevents zu relevanten Mustern. Für den Einstieg lohnt es sich, die mitgelieferten Regeln lokal oder im GitHub-Ruleset zu sichten und anhand einfacher Übungen (SSH/sudo) nachzuvollziehen, wie Rule-IDs greifen. Der klassische Use Case „x Fehlschläge in y Sekunden“ ist mit frequency/timeframe und same_srcip sauber umsetzbar – und wird mit if_matched_sid zu echten Sequenz-Detections erweitert.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1769432328047559