Ausgangslage & identifizierte Probleme

Nach dem initialen Deployment des Wazuh SIEM v4.14.1 wurde bei einer Sicherheitsanalyse festgestellt, dass die benutzerdefinierte Konfiguration nicht korrekt angewendet wurde. Der laufende Wazuh-Manager verwendete die Standard-Konfiguration statt der angepassten Version aus dem Repository.

Neue Architektur

Die aktualisierte Wazuh-Konfiguration implementiert ein mehrstufiges Sicherheitskonzept mit Multi-Channel-Benachrichtigungen und automatischer Bedrohungsabwehr.

Netzwerk-Konnektivität

Der Wazuh-Manager ist mit vier Docker-Netzwerken verbunden:

Gotify Push-Alerts

Wazuh unterstützt Custom Integrations über Python-Scripts. Das neue custom-gotify Script empfängt Alert-JSON und sendet formatierte Push-Notifications an den Gotify-Server.

Prioritäts-Mapping

Notification-Format

Jede Gotify-Nachricht enthält:

• Titel: Schweregrad + Rule ID
• Beschreibung: Alert-Text von der Wazuh-Rule
• Details: Level, Agent, Source-IP, Gruppen, Zeitstempel
• Format: Markdown für optimale Lesbarkeit

ossec.conf Konfiguration

<!-- Gotify Push Notification Integration -->
<integration>
  <name>custom-gotify</name>
  <hook_url>http://gotify:80/message?token=GOTIFY_WAZUH_TOKEN</hook_url>
  <level>7</level>
  <alert_format>json</alert_format>
</integration>

Active Response - Automatische IP-Blockierung

Active Response blockiert automatisch IP-Adressen, die verdächtige Aktivitäten zeigen. Drei Stufen wurden konfiguriert:

Stufe 1: SSH Brute-Force (10 Minuten)

Stufe 2: Authentication Failures (5 Minuten)

Stufe 3: Web-Service Brute-Force (15 Minuten)

Custom Detection Rules

Drei Custom-Rule-Dateien wurden erstellt, die spezifisch auf die matzka.cloud Infrastruktur zugeschnitten sind:

matzka_rules.xml (ID 100001-100299)

Service-spezifische Erkennung für alle Web-Services:

docker_rules.xml (ID 100300-100399)

Docker-spezifische Erkennung:

traefik_rules.xml (ID 100400-100499)

Traefik Reverse-Proxy Erkennung:

File Integrity Monitoring (FIM)

Das FIM wurde erheblich erweitert. Neben der Wazuh-eigenen Konfiguration werden jetzt auch alle Docker Compose Konfigurationsdateien überwacht.

Überwachte Verzeichnisse

Ausnahmen (Ignore-List)

• /var/ossec/logs, /var/ossec/queue, /var/ossec/var - Häufig ändernde Wazuh-Dateien
• /docker-configs/traefik/logs - Access Logs (werden separat analysiert)
• /docker-configs/traefik/acme.json - Let's Encrypt Zertifikate (ändern sich bei Renewal)
• Pattern: .log$|.swp$|.tmp$ - Temporäre Dateien

FIM-Konfiguration

<syscheck>
  <disabled>no</disabled>
  <frequency>43200</frequency>  <!-- 12 Stunden -->
  <scan_on_start>yes</scan_on_start>

  <!-- Wazuh-eigene Konfiguration -->
  <directories check_all="yes" realtime="yes" report_changes="yes">
    /var/ossec/etc
  </directories>

  <!-- Docker Compose Konfigurationen -->
  <directories check_all="yes" realtime="yes" report_changes="yes">
    /docker-configs
  </directories>

  <ignore>/docker-configs/traefik/logs</ignore>
  <ignore>/docker-configs/traefik/acme.json</ignore>
</syscheck>

Custom Decoders

Traefik JSON Access Log Decoder

Traefik schreibt Access Logs im JSON-Format. Ein Custom Decoder (traefik_decoder.xml) nutzt Wazuhs eingebauten JSON-Decoder zur Extraktion aller Felder.

<decoder name="traefik-accesslog">
  <prematch>^{"ClientAddr":|^{"StartUTC":|^{"level":</prematch>
  <plugin_decoder>JSON_Decoder</plugin_decoder>
</decoder>

Extrahierte Felder

Der Decoder stellt folgende Felder für die Custom Rules bereit:

• ClientHost - Source IP des Clients
• RequestHost - Angefragter Hostname (z.B. next.matzka.cloud)
• RequestPath - URL-Pfad
• RequestMethod - HTTP-Methode
• DownstreamStatus - HTTP Status Code
• TLSVersion - Verwendete TLS-Version
• RouterName - Traefik-Router der den Request bedient
• Duration - Request-Dauer in Nanosekunden

Deployment

Behobene Konfigurationsprobleme

Neue Volume-Mounts

volumes:
  # Konfiguration (korrekt gemountet)
  - ./wazuh-config/manager/ossec.conf:/var/ossec/etc/ossec.conf
  - ./wazuh-config/manager/rules:/var/ossec/etc/rules/custom:ro
  - ./wazuh-config/manager/decoders:/var/ossec/etc/decoders/custom:ro
  - ./wazuh-config/manager/integrations/custom-gotify:/var/ossec/integrations/custom-gotify:ro

  # Log-Quellen
  - /var/log:/host-logs:ro
  - ../traefik/logs:/traefik-logs:ro
  - /var/log/fail2ban.log:/fail2ban-logs/fail2ban.log:ro

  # Docker-Konfigurationen fuer FIM
  - /opt/docker/compose:/docker-configs:ro

Dateistruktur nach Update

security/wazuh-config/manager/
├── ossec.conf                    # Hauptkonfiguration (v4.14.1)
├── decoders/
│   └── traefik_decoder.xml       # Traefik JSON Decoder
├── integrations/
│   └── custom-gotify             # Gotify Push-Script (Python)
└── rules/
    ├── matzka_rules.xml          # Service-spezifische Rules (100001-100299)
    ├── docker_rules.xml          # Docker Container Rules (100300-100399)
    └── traefik_rules.xml         # Traefik Reverse-Proxy Rules (100400-100499)

Verifizierung

Nach dem Deployment sollten folgende Punkte geprüft werden:

1. Konfiguration geladen

# Prüfe ob die korrekte Config geladen wurde
docker exec wazuh-manager cat /var/ossec/etc/ossec.conf | grep smtp_server
# Erwartung: smtp-relay

2. Custom Rules aktiv

# Prüfe ob alle Rule-Dateien vorhanden sind
docker exec wazuh-manager ls /var/ossec/etc/rules/custom/
# Erwartung: matzka_rules.xml  docker_rules.xml  traefik_rules.xml

3. Log-Analyse testen

# Starte den Log-Test-Modus
docker exec -it wazuh-manager /var/ossec/bin/wazuh-logtest

# Beispiel-Input (Traefik JSON):
# {"ClientHost":"1.2.3.4","RequestHost":"next.matzka.cloud","RequestPath":"/login","DownstreamStatus":401}
# Erwartung: Rule 100001 matched (Nextcloud Auth-Fehler)

4. Gotify Push testen

# Generiere einen Test-Alert und prüfe Gotify
# Methode: Mehrere fehlgeschlagene Logins auslösen
# Gotify-App sollte Push-Notification mit Severity und Details empfangen

5. Active Response verifizieren

# Prüfe ob Active Response aktiv ist
docker exec wazuh-manager /var/ossec/bin/wazuh-control info
# active-response: enabled

Zusammenfassung der Verbesserungen