Wazuh Detection Rules — Praxis-Guide

Das Wichtigste in Kürze

SSH-Brute-Force-Regel: Die erste Detection Rule schlägt bei 10 fehlgeschlagenen SSH-Anmeldeversuchen von derselben IP innerhalb von 2 Minuten Alarm (Level 10).
Eigene Rule-IDs: Alle Beispiel-Regeln in diesem Artikel nutzen IDs ab 100001, weil Wazuh IDs unter 100000 für eingebaute Regeln reserviert.
Fünf Detection Rules decken die häufigsten Angriffsszenarien ab: SSH-Brute-Force, Privilege Escalation, File Integrity, Web-Attacken und Ransomware-Indikatoren.
Ransomware-Alerts eskalieren: Schattenkopien-Löschung und massenhafte Dateiverschlüsselung lösen Level-14- bis Level-15-Alarme aus und sollten automatische Gegenmaßnahmen anstoßen.
Regelpflege bindet Kapazität: Wer Tuning und Alert-Triage nicht laufend selbst leisten kann, lagert Betrieb und Pflege der Rules an ein Managed SOC aus.

KI-Transparenzhinweis: Dieser Beitrag wurde teilweise mit Unterstützung von KI-Systemen erstellt und vor der Veröffentlichung redaktionell geprüft. Kennzeichnung gemäß EU-KI-Verordnung (Verordnung (EU) 2024/1689).

Wazuh bringt bereits tausende vordefinierte Regeln mit. Doch für einen effektiven Schutz braucht es angepasste Detection Rules - zugeschnitten auf Ihre Umgebung und die relevantesten Bedrohungen.

/01Warum eigene Detection Rules?

Die Standard-Regeln von Wazuh sind ein guter Ausgangspunkt. Sie decken viele gängige Szenarien ab. Aber: Jede Umgebung ist anders, und Angreifer entwickeln ständig neue Methoden.

Mit eigenen Rules können Sie:

Spezifische Bedrohungen für Ihre Branche erkennen
False Positives reduzieren durch praezisere Definitionen
Die Alert-Schwere an Ihre Risikobewertung anpassen
Compliance-Anforderungen wie NIS2 erfüllen

Hinweis: Alle Rules in diesem Artikel verwenden IDs ab 100001. Wazuh reserviert IDs unter 100000 für eingebaute Regeln. Passen Sie die IDs an, falls Sie bereits eigene Rules nutzen.

Regelwerk-Pflege bindet dauerhaft Kapazität. Managed Wazuh von HostSpezial übernimmt Tuning, False-Positive-Reduktion und Dokumentation im laufenden Betrieb.

/02Rule 1: SSH Brute-Force Erkennung

SSH Brute-Force Detection

Erkennt wiederholte fehlgeschlagene SSH-Anmeldeversuche von derselben IP-Adresse innerhalb kurzer Zeit - ein klassisches Zeichen für Brute-Force-Angriffe.

Level: 10 (High) Timeframe: 2 Minuten Threshold: 10 Versuche

<!-- SSH Brute-Force Detection -->
<group name="ssh,authentication_failures">

  <rule id="100001" level="10" frequency="10" timeframe="120">
    <if_matched_sid>5710</if_matched_sid>
    <same_source_ip />
    <description>SSH Brute-Force-Angriff erkannt: $(srcip)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <group>authentication_failures,pci_dss_10.2.4,pci_dss_10.2.5</group>
  </rule>

  <!-- Erfolgreicher Login nach Brute-Force (besonders verdaechtig) -->
  <rule id="100002" level="12">
    <if_sid>5715</if_sid>
    <if_matched_sid>100001</if_matched_sid>
    <same_source_ip />
    <description>Erfolgreicher SSH-Login nach Brute-Force: $(srcip)</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

</group>

Warum diese Rule wichtig ist: SSH ist der primäre Remote-Zugang zu Linux-Servern. Brute-Force-Angriffe gehören zu den häufigsten Attacken - und sind mit dieser Rule zuverlässig erkennbar.

/03Rule 2: Privilege Escalation Detection

Privilege Escalation Detection

Erkennt verdächtige Sudo-Nutzung und Versuche, Root-Rechte zu erlangen - ein wichtiger Indikator für kompromittierte Systeme.

Level: 12 (Critical) Timeframe: 5 Minuten Threshold: 5 Versuche

<!-- Privilege Escalation Detection -->
<group name="privilege_escalation,sudo">

  <!-- Wiederholte fehlgeschlagene Sudo-Versuche -->
  <rule id="100010" level="12" frequency="5" timeframe="300">
    <if_matched_sid>5401</if_matched_sid>
    <same_user />
    <description>Privilege Escalation Versuch: User $(dstuser) - wiederholte sudo Fehler</description>
    <mitre>
      <id>T1548</id>
    </mitre>
    <group>privilege_escalation,pci_dss_10.2.5</group>
  </rule>

  <!-- Erster Sudo eines Users (Baseline-Abweichung) -->
  <rule id="100011" level="8">
    <if_sid>5402</if_sid>
    <user negate="yes">admin|deploy|ansible</user>
    <description>Ungewöhnlicher Sudo-Zugriff: $(dstuser) ist kein Admin</description>
    <mitre>
      <id>T1548</id>
    </mitre>
  </rule>

  <!-- Kritische Befehle mit sudo -->
  <rule id="100012" level="10">
    <if_sid>5402</if_sid>
    <match>passwd|shadow|sudoers|useradd|usermod|visudo</match>
    <description>Kritischer Befehl mit sudo: $(data)</description>
    <mitre>
      <id>T1098</id>
    </mitre>
  </rule>

</group>

Anpassung erforderlich: Die Liste der Admin-User (admin|deploy|ansible) muss an Ihre Umgebung angepasst werden. Fügen Sie alle legitimen Administratoren hinzu.

/04Rule 3: File Integrity Monitoring

Critical File Changes

Überwacht Änderungen an kritischen Systemdateien wie /etc/passwd, /etc/shadow und SSH-Konfiguration - typische Ziele für Angreifer.

Level: 12 (Critical) FIM erforderlich

<!-- Critical File Changes Detection -->
<group name="syscheck,file_integrity">

  <!-- Änderung an /etc/passwd -->
  <rule id="100020" level="12">
    <if_sid>550</if_sid>
    <match>/etc/passwd</match>
    <description>KRITISCH: /etc/passwd wurde geändert</description>
    <mitre>
      <id>T1136</id>
    </mitre>
    <group>file_integrity,pci_dss_11.5</group>
  </rule>

  <!-- Änderung an /etc/shadow -->
  <rule id="100021" level="12">
    <if_sid>550</if_sid>
    <match>/etc/shadow</match>
    <description>KRITISCH: /etc/shadow wurde geändert</description>
    <mitre>
      <id>T1003</id>
    </mitre>
  </rule>

  <!-- SSH-Konfiguration geändert -->
  <rule id="100022" level="10">
    <if_sid>550</if_sid>
    <match>/etc/ssh/sshd_config</match>
    <description>SSH-Konfiguration wurde geändert</description>
    <mitre>
      <id>T1098</id>
    </mitre>
  </rule>

  <!-- Neue Datei in cron.d -->
  <rule id="100023" level="10">
    <if_sid>554</if_sid>
    <match>/etc/cron</match>
    <description>Neue Cron-Job Datei erstellt: $(file)</description>
    <mitre>
      <id>T1053</id>
    </mitre>
  </rule>

</group>

Diese Rules erfordern, dass File Integrity Monitoring (FIM) in der Wazuh-Agent-Konfiguration aktiviert ist:

<!-- ossec.conf auf dem Agent -->
<syscheck>
  <directories check_all="yes" realtime="yes">/etc</directories>
  <directories check_all="yes" realtime="yes">/bin,/sbin,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/home</directories>
</syscheck>

/05Rule 4: Web Application Attacks

Web Application Attack Detection

Erkennt gängige Web-Angriffe wie SQL Injection, XSS und Path Traversal durch Analyse der Webserver-Logs.

Level: 10-12 Webserver-Logs

<!-- Web Application Attack Detection -->
<group name="web,attacks">

  <!-- SQL Injection Versuch -->
  <rule id="100030" level="12">
    <if_sid>31100</if_sid>
    <match>select.*from|union.*select|insert.*into|delete.*from|drop.*table</match>
    <description>SQL Injection Versuch erkannt: $(srcip)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>web_attacks,sql_injection,pci_dss_6.5.1</group>
  </rule>

  <!-- XSS (Cross-Site Scripting) Versuch -->
  <rule id="100031" level="10">
    <if_sid>31100</if_sid>
    <match><script|javascript:|onerror=|onload=|onclick=</match>
    <description>XSS-Versuch erkannt: $(srcip)</description>
    <mitre>
      <id>T1189</id>
    </mitre>
    <group>web_attacks,xss,pci_dss_6.5.7</group>
  </rule>

  <!-- Path Traversal Versuch -->
  <rule id="100032" level="10">
    <if_sid>31100</if_sid>
    <match>../|..%2f|%2e%2e/|/etc/passwd|/etc/shadow</match>
    <description>Path Traversal Versuch erkannt: $(srcip)</description>
    <mitre>
      <id>T1083</id>
    </mitre>
    <group>web_attacks,path_traversal</group>
  </rule>

  <!-- Mehrere Web-Angriffe von gleicher IP -->
  <rule id="100033" level="14" frequency="5" timeframe="60">
    <if_matched_group>web_attacks</if_matched_group>
    <same_source_ip />
    <description>Koordinierter Web-Angriff von $(srcip)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

</group>

/06Rule 5: Ransomware Indicators

Ransomware Early Warning

Erkennt frühe Anzeichen von Ransomware-Aktivität: Massenhaftes Umbenennen von Dateien, verdächtige Prozesse und Löschung von Backups.

Level: 14-15 (Critical) Echtzeit-Erkennung

<!-- Ransomware Early Warning Detection -->
<group name="ransomware,malware">

  <!-- Massenhaftes Umbenennen (verschlüsselte Dateien) -->
  <rule id="100040" level="14" frequency="20" timeframe="60">
    <if_sid>550</if_sid>
    <match>.encrypted|.locked|.crypto|.crypt|.enc</match>
    <description>RANSOMWARE WARNUNG: Massenhaftes Verschlüsseln erkannt!</description>
    <mitre>
      <id>T1486</id>
    </mitre>
    <group>ransomware,critical</group>
  </rule>

  <!-- VSS/Schattenkopien Löschung (Windows) -->
  <rule id="100041" level="15">
    <if_sid>60000</if_sid>
    <match>vssadmin.*delete|wmic.*shadowcopy.*delete</match>
    <description>KRITISCH: Schattenkopien werden geloescht - Ransomware-Indikator!</description>
    <mitre>
      <id>T1490</id>
    </mitre>
    <group>ransomware,critical</group>
  </rule>

  <!-- Verdächtige Batch/Script-Ausführung -->
  <rule id="100042" level="12">
    <if_sid>60000</if_sid>
    <match>powershell.*-enc|powershell.*downloadstring|certutil.*-urlcache</match>
    <description>Verdächtiger Download-/Ausführungsbefehl erkannt</description>
    <mitre>
      <id>T1059</id>
    </mitre>
    <group>ransomware,execution</group>
  </rule>

  <!-- Ransom Note Erstellung -->
  <rule id="100043" level="14">
    <if_sid>554</if_sid>
    <match>readme.*txt|decrypt.*txt|how.*recover|ransom</match>
    <description>RANSOMWARE: Erpresser-Nachricht wurde erstellt</description>
    <mitre>
      <id>T1486</id>
    </mitre>
    <group>ransomware,critical</group>
  </rule>

</group>

Wichtig bei Ransomware-Alerts: Bei Level 14+ sollten Sie automatische Aktionen konfigurieren - zum Beispiel das Isolieren des betroffenen Systems vom Netzwerk oder das Senden von SMS-Alerts.

/07Installation der Rules

Schritt 1: Rules-Datei erstellen

Kopieren Sie alle Rules in eine Datei unter /var/ossec/etc/rules/local_rules.xml:

# Auf dem Wazuh-Manager:
sudo nano /var/ossec/etc/rules/local_rules.xml

# Alle Rules einfügen, dann speichern

Schritt 2: Syntax prüfen

# Rules-Syntax validieren
sudo /var/ossec/bin/wazuh-logtest

# Test-Logs eingeben und Erkennung prüfen

Schritt 3: Wazuh-Manager neustarten

# Wazuh-Manager neustarten
sudo systemctl restart wazuh-manager

# Status prüfen
sudo systemctl status wazuh-manager

/08Best Practices für Detection Rules

Detection Rule Best Practices

Immer MITRE ATT&CK IDs referenzieren

Beschreibende Namen und Descriptions

Rules in Gruppen organisieren

Level-System konsistent nutzen

False Positives dokumentieren

Regelmäßig überprüfen und anpassen

Correlation Rules für komplexe Szenarien

Active Response für kritische Alerts

/09Fazit: Proaktive Erkennung ist der Schlüssel

Diese fünf Detection Rules decken die häufigsten Angriffsszenarien ab und sind sofort einsetzbar. Sie bilden eine solide Basis für Ihr Security Monitoring.

Denken Sie daran: Rules sind nur so gut wie ihre Pflege. Überprüfen Sie regelmäßig False Positives, passen Sie Schwellenwerte an und erweitern Sie Ihre Rule-Sammlung basierend auf neuen Bedrohungen und den Erkenntnissen aus Ihrem SOC. Wer dieses kontinuierliche Tuning und die Alert-Triage nicht selbst rund um die Uhr leisten kann, lagert Rule-Pflege und Betrieb an ein Managed SOC aus.

Für eine umfassende NIS2-Compliance und professionelles Security Monitoring unterstützen wir Sie gerne bei der Konfiguration und dem Betrieb Ihrer Wazuh-Installation.

Wazuh Implementierung

Wir richten Ihr Wazuh-SIEM ein und konfigurieren maßgeschneiderte Detection Rules für Ihre Umgebung.

Beratung anfragen

Quellen

MITRE ATT&CK, Technik-IDs zur Klassifizierung der Detection Rules (u.a. T1548, T1098, T1003, T1053, T1083, T1486, T1490, T1059).

Herausgeber

HostSpezial-Redaktion — HostSpezial betreibt seit 2010 Managed Services für den Mittelstand aus deutschen Rechenzentren, zertifiziert nach ISO/IEC 27001 (Zertifikat 202787), Sitz in Lichtenfels. Fachliche Prüfung und Freigabe dieses Beitrags liegen bei der Redaktion. Impressum · Kontakt

Wazuh in der Praxis: 5 Detection Rules die jedes KMU braucht

/01Warum eigene Detection Rules?

/02Rule 1: SSH Brute-Force Erkennung

/03Rule 2: Privilege Escalation Detection

/04Rule 3: File Integrity Monitoring

/05Rule 4: Web Application Attacks

/06Rule 5: Ransomware Indicators

/07Installation der Rules

Schritt 1: Rules-Datei erstellen

Schritt 2: Syntax prüfen

Schritt 3: Wazuh-Manager neustarten

/08Best Practices für Detection Rules

/09Fazit: Proaktive Erkennung ist der Schlüssel

Wazuh Implementierung

Weiterlesen zum gleichen Thema.

SIEM-Aufbau besprechen.

Wazuh in der Praxis: 5 Detection Rules die jedes KMU braucht

/01Warum eigene Detection Rules?

/02Rule 1: SSH Brute-Force Erkennung

/03Rule 2: Privilege Escalation Detection

/04Rule 3: File Integrity Monitoring

/05Rule 4: Web Application Attacks

/06Rule 5: Ransomware Indicators

/07Installation der Rules

Schritt 1: Rules-Datei erstellen

Schritt 2: Syntax prüfen

Schritt 3: Wazuh-Manager neustarten

/08Best Practices für Detection Rules

/09Fazit: Proaktive Erkennung ist der Schlüssel

Wazuh Implementierung

Weiterlesen zum gleichen Thema.

Wazuh: Open-Source SIEM-Plattform

NIS2-Compliance

Linux Server härten

Managed SOC · 24/7

SIEM-Aufbau besprechen.