Wazuh Active Response: Wenn das SIEM selbst reagiert

Key Takeaways

• Wazuh Active Response führt bei ausgelösten Regeln automatisch Gegemaßnahmen aus — von IP-Blockierung bis Prozess-Kill.
• Die Konfiguration erfolgt in ossec.conf über <active-response>-Blöcke und benutzerdefinierte Skripte.
• Schwellenwerte, Timeouts und Whitelists sind entscheidend, um False-Positive-Aktionen zu verhindern.
• Im NIS-2-Kontext liefert Active Response prüfbare Reaktionsnachweise ohne manuellen Eingriff.
• Für KMU ohne 24/7-SOC schließt Active Response das kritische Zeitfenster zwischen Erkennung und Reaktion.

Was Active Response leistet — und was nicht

Ein SIEM, das nur Alarme erzeugt, ist ein Rauchmelder ohne Sprinkleranlage. Wazuh Active Response ist der Sprinkler: Sobald eine Regel auslöst und den konfigurierten Schwellenwert überschreitet, wird automatisch ein Skript auf dem betroffenen Agenten oder einem zentralen System ausgeführt.

Das klingt simpel, hat aber weitreichende Konsequenzen für die Reaktionszeit. Zwischen dem Moment, in dem ein Brute-Force-Angriff erkannt wird, und dem Moment, in dem ein Analyst die IP manuell sperrt, vergehen in KMU ohne dediziertes SOC-Team typischerweise Stunden — wenn der Alert überhaupt während der Geschäftszeit auftaucht. Active Response reduziert dieses Fenster auf zwei bis fünf Sekunden.

Was Active Response nicht ist: eine vollständige SOAR-Plattform. Es gibt keine komplexen Playbooks mit Bedingungsverzweigungen, keine nativen Ticketing-Integrationen und keine grafische Workflow-Engine. Der Mechanismus ist bewusst schlank — ein Trigger löst ein Skript aus. Wer komplexere Orchestrierung braucht, kombiniert Wazuh mit externen Tools wie Shuffle oder n8n.

Architektur: Manager, Agent und das Skript dazwischen

Wazuh Active Response funktioniert auf zwei Ebenen:

Lokal (auf dem Agenten): Der Wazuh-Agent auf dem betroffenen Host führt das Skript direkt aus. Das ist die häufigste Variante — z. B. eine Firewall-Regel setzen oder einen Prozess beenden.

Remote (auf einem anderen Host): Der Wazuh-Manager weist einen anderen Agenten an, zu reagieren. Nützlich, wenn ein Angriff von einem externen System kommt und eine zentrale Firewall gesteuert werden soll.

Die Skripte selbst liegen auf dem Agenten unter:

• Linux: /var/ossec/active-response/bin/
• Windows: C:\Program Files (x86)\ossec-agent\active-response\bin\

Wazuh liefert bereits eine Reihe eingebauter Skripte: firewall-drop (Linux iptables/nftables), win_route-null (Windows null route), restart-wazuh, disable-account und andere. Eigene Skripte können in jeder sprache geschrieben werden, die auf dem Zielsystem verfügbar ist.

Konfiguration Schritt für Schritt

Schritt 1: Command definieren

In /var/ossec/etc/ossec.conf auf dem Manager wird zunächst der Befehl definiert, der ausgeführt werden soll:

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

timeout_allowed erlaubt es, die Blockierung nach einer definierten Zeit automatisch aufzuheben — wichtig, um keine dauerhaften Sperren durch False Positives zu erzeugen.

Schritt 2: Active-Response-Block konfigurieren

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>600</timeout>
</active-response>

Die wichtigsten Parameter:

Parameter	Bedeutung
<command>	Referenz auf den definierten Command
<location>	local, server, defined-agent oder all
<rules_id>	Kommagetrennte Regel-IDs, die triggern
<level>	Minimaler Alert-Level (alternativ zu rules_id)
<timeout>	Sekunden bis zur automatischen Aufhebung

Empfehlung: Verwenden Sie spezifische <rules_id> statt eines generischen <level>-Schwellenwerts. Das verhindert, dass administrative Aktionen wie geplante Reboots versehentlich Active Response auslösen.

Schritt 3: Whitelist einrichten

Ohne Whitelist kann Active Response eigene Monitoring-Systeme, VPN-Konzentratoren oder legitime externe Partner sperren. In /var/ossec/etc/ossec.conf auf dem Manager:

<global>
  <white_list>10.0.0.0/8</white_list>
  <white_list>192.168.0.0/16</white_list>
  <white_list>203.0.113.50</white_list>
</global>

IPv6-Adressen werden ebenfalls unterstützt. Tragen Sie hier alle internen Netze, Management-IPs und bekannte legitime Quellen ein — bevor Sie Active Response aktivieren, nicht danach.

Praxisfall: SSH-Brute-Force automatisch stoppen

Ein typisches Szenario: Ein Linux-Server wird mit SSH-Brute-Force angegriffen. Wazuh-Regel 5763 (sshd: authentication failed) zählt Fehlversuche. Ab einer konfigurierten Häufigkeit (Standard: 8 Versuche in 2 Minuten, Regel 5712) greift die Dekoderlogik und erzeugt einen Alert mit Level 10.

Mit dem folgenden Active-Response-Block wird die angreifende IP für 10 Minuten per iptables gesperrt:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <level>10</level>
  <timeout>600</timeout>
</active-response>

Was im Hintergrund passiert:

1. Wazuh-Agent erkennt die Fehlversuche, sendet Events an den Manager.
2. Manager matcht die Regel, Level 10 wird erreicht.
3. Manager sendet Active-Response-Befehl an den Agenten.
4. Agent führt firewall-drop <angreifer-IP> aus — das Skript setzt eine iptables-DROP-Regel.
5. Nach 600 Sekunden ruft der Agent firewall-drop delete <angreifer-IP> auf und entfernt die Regel.
6. Der gesamte Vorgang wird als Events in Wazuh protokolliert.

Der Alert selbst ist im Wazuh-Dashboard unter dem Agenten sichtbar, inklusive des Active-Response-Events als separate Log-Zeile.

Windows-Umgebungen: Account deaktivieren nach verdächtigem Login

Für Windows-Agents existiert das disable-account-Skript. Relevant z. B. bei Erkennung eines Pass-the-Hash-Angriffs (Wazuh-Regel 60122) oder bei einem Login außerhalb der Geschäftszeiten kombiniert mit einer verdächtigen Aktivität.

<command>
  <name>disable-account</name>
  <executable>disable-account.cmd</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>disable-account</command>
  <location>local</location>
  <rules_id>60122</rules_id>
  <timeout>1800</timeout>
</active-response>

Das Skript deaktiviert den im Alert identifizierten Benutzer-Account via net user <username> /active:no. Nach dem Timeout wird der Account wieder aktiviert.

Hinweis zur DSGVO: Die automatische Deaktivierung eines Benutzerkontos ist eine Maßnahme mit direktem Personenbezug. Diese sollte in der Datenschutz-Folgenabschätzung und im Verarbeitungsverzeichnis dokumentiert sein. Informieren Sie die betroffenen Nutzer nach dem Vorfall entsprechend Art. 34 DSGVO, wenn ein hohes Risiko bestand.

Microsoft 365 und Azure: Active Response ohne lokalen Agenten

Für Cloud-Workloads in Microsoft 365 oder Azure gibt es keinen Wazuh-Agenten im klassischen Sinne. Logs kommen über die Wazuh-M365-Integration (via Microsoft Graph API) oder Azure Event Hub. Active Response in diesen Szenarien erfordert deshalb externe Skripte, die über die jeweiligen APIs agieren.

Ein realistisches Szenario: Ein kompromittiertes M365-Konto meldet sich von einer unbekannten IP an. Wazuh erkennt den Alert über die Graph-API-Integration. Ein Custom-Active-Response-Skript ruft dann die Microsoft Graph API auf und setzt die Conditional-Access-Richtlinie außer Kraft oder sperrt die Anmeldesitzung:

#!/usr/bin/env python3
# active-response/bin/m365-revoke-session.py
import sys
import json
import requests
import os

def get_token():
    tenant_id = os.environ['AZURE_TENANT_ID']
    client_id = os.environ['AZURE_CLIENT_ID']
    client_secret = os.environ['AZURE_CLIENT_SECRET']
    url = f"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    data = {
        "grant_type": "client_credentials",
        "client_id": client_id,
        "client_secret": client_secret,
        "scope": "https://graph.microsoft.com/.default"
    }
    return requests.post(url, data=data).json()["access_token"]

def revoke_sessions(user_id, token):
    url = f"https://graph.microsoft.com/v1.0/users/{user_id}/revokeSignInSessions"
    headers = {"Authorization": f"Bearer {token}"}
    requests.post(url, headers=headers)

if __name__ == "__main__":
    alert = json.loads(sys.stdin.read())
    user = alert.get("data", {}).get("userId", "")
    if user:
        token = get_token()
        revoke_sessions(user, token)

Dieses Skript wird im Active-Response-Block referenziert und durch den Wazuh-Manager bei Regelmatch aufgerufen. Die Credentials werden als Umgebungsvariablen auf dem Manager hinterlegt — nie als Klartext in ossec.conf.

Risiken und Gegenmaßnahmen

Active Response kann Schaden anrichten, wenn es falsch konfiguriert ist. Die häufigsten Probleme:

False Positives sperren legitime Nutzer: Lösung: Whitelist, hoher Level-Schwellenwert (≥ 10), kurze Timeouts zu Beginn (300–600 Sekunden).

Angreifer triggern Active Response gezielt gegen legitime IPs (Denial-of-Service durch Missbrauch): Lösung: repeated_offenders-Konfiguration aktivieren und Whitelist gepflegt halten. Für kritische IPs (z. B. Backup-Server, WSUS) immer Whitelist-Eintrag setzen.

Skripte mit zu weitreichenden Berechtigungen: Das Active-Response-Skript läuft unter dem Wazuh-Agent-Account. Auf Linux ist das standardmäßig root — überprüfen Sie, ob das für Ihr Skript tatsächlich notwendig ist.

Keine Sichtbarkeit über ausgeführte Maßnahmen: Lösung: Wazuh protokolliert Active-Response-Events als eigene Regelgruppe (active_response). Erstellen Sie ein separates Dashboard oder eine Alert-Regel für diese Events, damit Ihr Team immer weiß, was das System automatisch getan hat.

NIS-2 und Active Response: Automatische Nachweispflicht

NIS-2 (umgesetzt in Deutschland durch das NIS-2-Umsetzungsgesetz) verpflichtet betroffene Einrichtungen zu nachweisbaren Maßnahmen zur Erkennung und Bewältigung von Sicherheitsvorfällen. Active Response liefert hier einen direkten Mehrwert: Jede automatische Aktion wird als Event in Wazuh gespeichert, mit Zeitstempel, ausgelöster Regel, betroffener IP und ausgeführtem Kommando.

Dieser Audit-Trail ist bei Behördenanfragen oder Zertifizierungen (ISO 27001, TISAX) direkt verwertbar. Wichtig: Die Active-Response-Konfiguration selbst sollte im Incident-Response-Plan dokumentiert sein — als Nachweis, dass die automatischen Maßnahmen bewusst geplant und nicht zufällig entstanden sind.

Empfohlene Rollout-Reihenfolge

1. Beobachtungsmodus zuerst: Vor dem ersten Aktivieren von Active Response eine Woche lang nur auf Alerts achten, die potenziell triggern würden. False-Positive-Rate einschätzen.
2. Whitelist vervollständigen: Alle internen Systeme, Management-IPs und bekannte Partner eintragen.
3. Kurze Timeouts beginnen: Mit 300–600 Sekunden starten, nach zwei Wochen auf 1800–3600 erhöhen.
4. Spezifische Regeln vor generischen Leveln: <rules_id> statt <level>, so lange bis das Verhalten stabil und vorhersehbar ist.
5. Monitoring der Active-Response-Events: Dashboard-Widget oder Alert-Regel für die active_response-Regelgruppe einrichten.

---

Wazuh Active Response ist ein leistungsfähiges Werkzeug — aber kein Selbstläufer. Die Konfiguration erfordert Kenntnis der eigenen Infrastruktur, eine gepflegte Whitelist und regelmäßige Überprüfung der ausgelösten Aktionen. Für KMU, die Wazuh ohne dediziertes Security-Team betreiben, ist der Aufwand für initiale Konfiguration und laufendes Tuning oft der limitierende Faktor.

Genau hier setzt Vyrex Security an: Als Managed-SIEM/SOC-Anbieter übernimmt Vyrex nicht nur den Betrieb der Wazuh-Infrastruktur, sondern auch die kontinuierliche Pflege von Active-Response-Regeln, Whitelists und Custom-Skripten — abgestimmt auf die spezifische Umgebung des Kunden, inklusive Microsoft-365- und Azure-Integration. So erhalten KMU die Reaktionsfähigkeit eines 24/7-SOC, ohne eigenes Personal dafür vorhalten zu müssen.