Wazuh Container Monitoring

Dieser Artikel baut auf dem Docker-Aufbau mit Traefik auf und integriert ihn in das SIEM. Der Wazuh-Agent läuft auf dem Docker-Host, nicht in den Containern. Drei Telemetriequellen werden eingebunden: Docker-Engine-Events, die Anwendungslogs und Datei-Integritätsüberwachung auf den Volumes.

Konzept

Agent auf dem Host

• Der Wazuh-Agent wird auf dem Docker-Host installiert. Über das docker-listener-Modul liest er die Events der Docker-Engine direkt vom Socket.

Was im SIEM ankommt

• Container start, stop und die
• Image-Pulls
• docker exec in laufende Container (jemand klettert in den Container)
• Netzwerk- und Volume-Events

Drei Quellen

• Engine-Events (docker-listener), Anwendungslogs (Container-stdout) und FIM auf den Daten-Volumes.

Voraussetzung: Python-Modul docker

Das docker-listener-Modul benötigt das Python-docker-SDK in der Wazuh-eigenen Python-Umgebung. Ohne dieses Modul startet der Listener still nicht.

SDK in die Wazuh-Python-Umgebung installieren

• /var/ossec/framework/python/bin/pip3 install docker

Installation prüfen

• /var/ossec/framework/python/bin/pip3 show docker

Volume-Pfade ermitteln

Da jede Anwendung ein eigenes Compose-Projekt ist, lautet der Volume-Name <verzeichnis>_<volume>. Bei den Verzeichnissen nextcloud/ und mediawiki/ also nextcloud_data und mediawiki_data. Im Zweifel prüfen:

Volumes auflisten

• docker volume ls

Mountpoint eines Volumes anzeigen

• docker volume inspect nextcloud_data

Agent-Konfiguration (ossec.conf)

Der folgende Block kommt in die /var/ossec/etc/ossec.conf des Agents auf dem Docker-Host.

docker-listener

<wodle name="docker-listener">
  <interval>10m</interval>
  <attempts>5</attempts>
  <run_on_start>yes</run_on_start>
  <disabled>no</disabled>
</wodle>

run_on_start

• Startet das Modul direkt beim Hochfahren des Agents, nicht erst nach dem ersten Intervall.

attempts

• Anzahl der Verbindungsversuche zum Docker-Socket, falls dieser beim Start noch nicht bereit ist.

Anwendungslogs

<localfile>
  <log_format>json</log_format>
  <location>/var/lib/docker/containers/*/*-json.log</location>
</localfile>

json-Logtreiber

• Docker schreibt pro Container eine *-json.log. Wazuh liest diese als json ein und kann die Felder direkt auswerten.

FIM auf den Volumes

<syscheck>
  <directories check_all="yes" realtime="yes">/var/lib/docker/volumes/nextcloud_data/_data/data</directories>
  <directories check_all="yes" realtime="yes">/var/lib/docker/volumes/mediawiki_data/_data</directories>
</syscheck>

realtime

• realtime="yes" meldet Änderungen sofort über inotify, statt erst beim nächsten Scan-Durchlauf. Neue Dateien lösen Rule 554 aus.

Kompletter ossec.conf-Block

Alle drei Bausteine am Stück zum Einfügen. Volume-Pfade ggf. an die tatsächlichen Namen anpassen.

<wodle name="docker-listener">
  <interval>10m</interval>
  <attempts>5</attempts>
  <run_on_start>yes</run_on_start>
  <disabled>no</disabled>
</wodle>

<localfile>
  <log_format>json</log_format>
  <location>/var/lib/docker/containers/*/*-json.log</location>
</localfile>

<syscheck>
  <directories check_all="yes" realtime="yes">/var/lib/docker/volumes/nextcloud_data/_data/data</directories>
  <directories check_all="yes" realtime="yes">/var/lib/docker/volumes/mediawiki_data/_data</directories>
</syscheck>

Agent neu starten

systemctl restart wazuh-agent

Funktionsprüfung

Modul-Status im Agent-Log

ossec.log auf dem Agent verfolgen

• tail -f /var/ossec/logs/ossec.log

Auf docker-listener-Meldungen filtern

• grep docker-listener /var/ossec/logs/ossec.log

Erscheint hier eine Meldung über ein fehlendes Python-Modul, wurde das docker-SDK nicht in die Wazuh-Python-Umgebung installiert (siehe oben).

Event auslösen

Test-Container starten und entfernen

• docker run --rm hello-world

In einen laufenden Container klettern

• docker exec -it nextcloud sh

Im Manager prüfen

alle Events mitlesen

• tail -f /var/ossec/logs/archives/archives.json

nur Alerts mitlesen

• tail -f /var/ossec/logs/alerts/alerts.json

Die Docker-Events erscheinen mit dem Decoder docker. Das docker exec ist didaktisch der interessanteste Fall: Es zeigt, dass ein Eindringen in einen laufenden Container im SIEM sichtbar wird.

Hinweis zum Datenfluss

Engine-Events vs. Anwendungslogs

• Der docker-listener meldet, dass ein Container gestartet oder betreten wurde – nicht, was innerhalb der Anwendung passiert. Für Angriffe auf die Webanwendung liefern die Anwendungslogs und FIM die Telemetrie.

Zusammenspiel

• Erst die Kombination macht das Bild vollständig: Engine-Ebene (Container-Lifecycle), Anwendungs-Ebene (Logs) und Datei-Ebene (FIM).