Wazuh Active Response: IPS-Bug behoben

Wazuh fungiert auf matzka.cloud nicht nur als SIEM (Erkennung), sondern auch als aktives IPS (Intrusion Prevention): Erkannte Angreifer werden automatisch via iptables geblockt. Dafür ist ein benutzerdefiniertes Active-Response-Script zuständig, das Firewall-Regeln unterhalb der Mailcow-Chain einfügt — so wird Mailcows netfilter-Setup nicht gestört.

Das Problem: Silent Fail bei leerem SSH-Benutzernamen

Beim Review des Active-Response-Logs zeigte sich ein wiederkehrendes Fehlerbild: Ein Teil der SSH-Brute-Force-Versuche wurde erkannt, aber nicht geblockt. Betroffen waren Verbindungsversuche mit leerem Benutzernamen — eine gängige Scanner-Technik, bei der kein gültiger User übermittelt wird.

In diesen Fällen liefert der Wazuh SSH-Decoder keine srcip im strukturierten Datenfeld. Das Active-Response-Script erwartete die IP ausschließlich dort — fehlte sie, brach das Script mit einem Fehler ab:

# Fehlerhafte Zeile im Active-Response-Log:
ERROR - Missing command or srcip.

# Die IP war vorhanden, aber im Freitext-Log, nicht im strukturierten Feld:
full_log: "Invalid user  from <ip> port 48326"
data: {"srcport": "48326"}  # srcip fehlt

Die Lösung: Fallback auf full_log

Das Script wurde um eine Fallback-Extraktion erweitert: Fehlt srcip im strukturierten Feld, wird die IP per Regex aus dem Roh-Log extrahiert — aus den Mustern from <ip> und rhost=<ip>, die sshd in allen relevanten Fehlermeldungen verwendet.

# Vorher: nur strukturiertes Feld
SRCIP=$(echo "$INPUT_JSON" | jq -r '.parameters.alert.data.srcip // empty')

# Nachher: Fallback auf full_log wenn srcip fehlt
if [ -z "$SRCIP" ]; then
    FULL_LOG=$(echo "$INPUT_JSON" | jq -r '.parameters.alert.full_log // empty')
    SRCIP=$(echo "$FULL_LOG" | grep -oP '(?<=from )\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}')
fi

Bonus-Fix: Keine doppelten Firewall-Regeln

Wenn mehrere Wazuh-Regeln gleichzeitig auf denselben Angriff ansprechen, wurde das Script mehrfach ausgelöst — und für dieselbe IP mehrfach eine DROP-Regel angelegt. Das Script prüft jetzt vor dem Einfügen, ob eine Regel bereits existiert:

# Idempotentes Hinzufügen: nur einfügen wenn noch nicht vorhanden
if ! iptables -C INPUT -s "$SRCIP" -j DROP 2>/dev/null; then
    iptables -I INPUT 2 -s "$SRCIP" -j DROP
    # Log: ADD - Blocked
else
    # Log: SKIP - bereits geblockt
fi

Trivy: Alert-Deduplizierung

Wazuh ist mit Trivy integriert: Ein täglicher Scan prüft alle laufenden Container-Images auf bekannte Schwachstellen. Bisher wurde bei jedem Scan-Lauf für jedes Image mit Findings ein Alert ausgelöst — unabhängig davon, ob sich seit dem letzten Scan überhaupt etwas geändert hatte. Das Ergebnis: Dieselben bekannten CVEs in einem Image, das der Upstream-Maintainer noch nicht gepatcht hat, erzeugten Tag für Tag identische Push-Benachrichtigungen.

Lösung: Zustands-Tracking

Das Scan-Script speichert jetzt nach jedem Lauf den aktuellen Vuln-Stand pro Image in einer State-Datei. Beim nächsten Scan wird verglichen:

Directus v11 → v12: License Enforcement

Directus CMS wurde von v11.17.4 auf v12.0.2 aktualisiert. Das war kein reines Version-Bump: Directus 12 führt aktives License Enforcement ein.

Was sich in v12 ändert

Ohne Lizenzschlüssel läuft Directus 12 im eingeschränkten Core-Modus. Bestimmte Features — darunter SSO — sind lizenzpflichtig. Für Einzelpersonen und kleine Organisationen bietet Directus jedoch das Open Innovation Grant (OIG): eine kostenlose Lizenz für Selbsthosting-Projekte unter bestimmten Größenkriterien.

Upgrade-Ablauf

1. Datenbank-Backup — PostgreSQL-Dump vor dem Update erstellt
2. OIG-Lizenz holen — kostenlosen Schlüssel unter directus.com/oig beantragen (Gültigkeit: 1 Jahr, erneuerbar)
3. Lizenzschlüssel in .env — als LICENSE_KEY eingetragen, referenziert aus docker-compose.yml (nicht im Repository)
4. Image-Tag ändern — directus/directus:11.17.4 → directus/directus:12.0.2
5. Container neu starten — automatische DB-Migrationen beim Start

# docker-compose.yml Ausschnitt
directus:
  image: directus/directus:12.0.2
  environment:
    LICENSE_KEY: ${DIRECTUS_LICENSE_KEY}  # aus .env, nicht im Repo
    # ... DB, SSO, CORS wie bisher ...

Migrations-Log beim Start

INFO: Running migrations...
INFO: Applying Add Licensing...
INFO: Applying Add MCP Oauth...
INFO: Done
INFO: Server started at http://0.0.0.0:8055

Ergebnis