Wazuh Container Monitoring - Versionsgeschichte

Thomas.will am 27. Juni 2026 um 16:28 Uhr

2026-06-27T16:28:36Z

Thomas.will am 27. Juni 2026 um 16:27 Uhr

2026-06-27T16:27:43Z

Thomas.will: Die Seite wurde neu angelegt: „Dieser Artikel baut auf dem Docker-Stack mit Traefik auf und integriert ihn in das SIEM. Der Wazuh-Agent läuft dabei auf dem '''Docke…“

2026-06-27T16:14:31Z

Die Seite wurde neu angelegt: „Dieser Artikel baut auf dem Docker-Stack mit Traefik auf und integriert ihn in das SIEM. Der Wazuh-Agent läuft dabei auf dem '''Docke…“

Neue Seite

Dieser Artikel baut auf dem [[Docker-Stack-Traefik|Docker-Stack mit Traefik]] auf und integriert ihn in das SIEM. Der Wazuh-Agent läuft dabei 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 <code>docker-listener</code>-Modul liest er die Events der Docker-Engine direkt vom Socket.

; Was im SIEM ankommt
* Container start, stop und die
* Image-Pulls
* <code>docker exec</code> in laufende Container (jemand klettert in den Container)
* Netzwerk- und Volume-Events

; Drei Quellen
* Engine-Events (docker-listener), Anwendungslogs (Traefik, Nextcloud, MediaWiki) und FIM auf den Daten-Volumes.

==Voraussetzung: Python-Modul docker==

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

; SDK in die Wazuh-Python-Umgebung installieren
* <code>/var/ossec/framework/python/bin/pip3 install docker</code>

; Installation prüfen
* <code>/var/ossec/framework/python/bin/pip3 show docker</code>

==Agent-Konfiguration (ossec.conf)==

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

===docker-listener aktivieren===

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

; interval / attempts
* Der Listener verbindet sich beim Start mit dem Docker-Socket. <code>attempts</code> regelt, wie oft er es bei Nichterreichbarkeit erneut versucht.

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

===Anwendungslogs einsammeln===

Die Container loggen auf <code>stdout</code>. Bei json-file-Logtreiber liegen die Logs auf dem Host und können direkt als Datei eingelesen werden. Einfacher und stabiler ist es, die relevanten Anwendungslogs auf ein gemountetes Verzeichnis zu schreiben und dieses zu überwachen.

<syntaxhighlight lang="xml">
<localfile>
<log_format>json</log_format>
<location>/var/lib/docker/containers/*/*-json.log</location>
</localfile>
</syntaxhighlight>

; json-Logtreiber
* Docker schreibt pro Container eine <code>*-json.log</code>. Wazuh kann diese als <code>json</code> einlesen und die Felder direkt auswerten.

==FIM auf den Volumes==

Datei-Integritätsüberwachung auf den Daten-Volumes der Anwendungen. Veränderungen an hochgeladenen Dateien oder an der Wiki-Konfiguration lösen ein FIM-Event aus (Rule 554 bei neuen Dateien).

<syntaxhighlight lang="xml">
<syscheck>
<directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_nextcloud_data/_data/data</directories>
<directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_mediawiki_data/_data</directories>
</syscheck>
</syntaxhighlight>

; realtime
* <code>realtime="yes"</code> meldet Änderungen sofort über inotify, statt erst beim nächsten Scan-Durchlauf.

; Volume-Pfade
* Die genauen Pfade hängen vom Compose-Projektnamen ab (Präfix des Verzeichnisses). Mit dem folgenden Befehl ermitteln.
* <code>docker volume inspect docker-stack_nextcloud_data</code>

==Kompletter ossec.conf-Block==

Alle drei Bausteine (docker-listener, Anwendungslogs, FIM) am Stück zum Einfügen in die <code>/var/ossec/etc/ossec.conf</code> des Agents auf dem Docker-Host. Die Volume-Pfade ggf. an den eigenen Compose-Projektnamen anpassen.

<syntaxhighlight lang="xml">
<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/docker-stack_nextcloud_data/_data/data</directories>
<directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_mediawiki_data/_data</directories>
</syscheck>
</syntaxhighlight>

==Agent neu starten==

<syntaxhighlight lang="bash">
systemctl restart wazuh-agent
</syntaxhighlight>

==Funktionsprüfung==

===Modul-Status im Agent-Log===

; ossec.log auf dem Agent prüfen
* <code>tail -f /var/ossec/logs/ossec.log</code>

; Auf docker-listener-Meldungen achten
* <code>grep docker-listener /var/ossec/logs/ossec.log</code>

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

===Event auslösen===

; Test-Container starten und wieder entfernen
* <code>docker run --rm hello-world</code>

; In einen laufenden Container klettern
* <code>docker exec -it nextcloud sh</code>

===Im Manager prüfen===

; archives.json mitlesen (alle Events)
* <code>tail -f /var/ossec/logs/archives/archives.json</code>

; alerts.json mitlesen (nur Alerts)
* <code>tail -f /var/ossec/logs/alerts/alerts.json</code>

Die Docker-Events erscheinen mit dem Decoder <code>docker</code>. Das <code>docker exec</code> 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 (z.B. gegen MediaWiki oder Nextcloud) 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).

← Nächstältere Version		Version vom 27. Juni 2026, 16:28 Uhr
Zeile 1:		Zeile 1:
−	Dieser Artikel baut auf dem [[Docker-Stack-Traefik\|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.	+	Dieser Artikel baut auf dem [[Docker Stack Traefik\|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==		==Konzept==

@@ Zeile 1: / Zeile 1: @@
-Dieser Artikel baut auf dem [[Docker-Stack-Traefik|Docker-Stack mit Traefik]] auf und integriert ihn in das SIEM. Der Wazuh-Agent läuft dabei 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.
+Dieser Artikel baut auf dem [[Docker-Stack-Traefik|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==
@@ Zeile 13: / Zeile 13: @@
 ; Drei Quellen
-* Engine-Events (docker-listener), Anwendungslogs (Traefik, Nextcloud, MediaWiki) und FIM auf den Daten-Volumes.
+* Engine-Events (docker-listener), Anwendungslogs (Container-stdout) und FIM auf den Daten-Volumes.
 ==Voraussetzung: Python-Modul docker==
@@ Zeile 24: / Zeile 24: @@
 ; Installation prüfen
 * <code>/var/ossec/framework/python/bin/pip3 show docker</code>
 ==Agent-Konfiguration (ossec.conf)==
@@ Zeile 29: / Zeile 39: @@
 Der folgende Block kommt in die <code>/var/ossec/etc/ossec.conf</code> des Agents auf dem Docker-Host.
-===docker-listener aktivieren===
+===docker-listener===
 <syntaxhighlight lang="xml">
@@ Zeile 39: / Zeile 49: @@
 </wodle>
 </syntaxhighlight>
 ; run_on_start
 * Startet das Modul direkt beim Hochfahren des Agents, nicht erst nach dem ersten Intervall.
-===Anwendungslogs einsammeln===
+; attempts
-Die Container loggen auf <code>stdout</code>. Bei json-file-Logtreiber liegen die Logs auf dem Host und können direkt als Datei eingelesen werden. Einfacher und stabiler ist es, die relevanten Anwendungslogs auf ein gemountetes Verzeichnis zu schreiben und dieses zu überwachen.
+===Anwendungslogs===
 <syntaxhighlight lang="xml">
@@ Zeile 58: / Zeile 66: @@
 ; json-Logtreiber
-* Docker schreibt pro Container eine <code>*-json.log</code>. Wazuh kann diese als <code>json</code> einlesen und die Felder direkt auswerten.
+* Docker schreibt pro Container eine <code>*-json.log</code>. Wazuh liest diese als <code>json</code> ein und kann die Felder direkt auswerten.
-==FIM auf den Volumes==
+===FIM auf den Volumes===
 <syntaxhighlight lang="xml">
 <syscheck>
-   <directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_nextcloud_data/_data/data</directories>
+   <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/docker-stack_mediawiki_data/_data</directories>
+   <directories check_all="yes" realtime="yes">/var/lib/docker/volumes/mediawiki_data/_data</directories>
 </syscheck>
 </syntaxhighlight>
 ; realtime
-* <code>realtime="yes"</code> meldet Änderungen sofort über inotify, statt erst beim nächsten Scan-Durchlauf.
+* <code>realtime="yes"</code> 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 (docker-listener, Anwendungslogs, FIM) am Stück zum Einfügen in die <code>/var/ossec/etc/ossec.conf</code> des Agents auf dem Docker-Host. Die Volume-Pfade ggf. an den eigenen Compose-Projektnamen anpassen.
+Alle drei Bausteine am Stück zum Einfügen. Volume-Pfade ggf. an die tatsächlichen Namen anpassen.
 <syntaxhighlight lang="xml">
@@ Zeile 96: / Zeile 98: @@
 <syscheck>
-   <directories check_all="yes" realtime="yes">/var/lib/docker/volumes/docker-stack_nextcloud_data/_data/data</directories>
+   <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/docker-stack_mediawiki_data/_data</directories>
+   <directories check_all="yes" realtime="yes">/var/lib/docker/volumes/mediawiki_data/_data</directories>
 </syscheck>
 </syntaxhighlight>
@@ Zeile 111: / Zeile 113: @@
 ===Modul-Status im Agent-Log===
-; ossec.log auf dem Agent prüfen
+; ossec.log auf dem Agent verfolgen
 * <code>tail -f /var/ossec/logs/ossec.log</code>
-; Auf docker-listener-Meldungen achten
+; Auf docker-listener-Meldungen filtern
 * <code>grep docker-listener /var/ossec/logs/ossec.log</code>
@@ Zeile 121: / Zeile 123: @@
 ===Event auslösen===
-; Test-Container starten und wieder entfernen
+; Test-Container starten und entfernen
 * <code>docker run --rm hello-world</code>
@@ Zeile 129: / Zeile 131: @@
 ===Im Manager prüfen===
-; archives.json mitlesen (alle Events)
+; alle Events mitlesen
 * <code>tail -f /var/ossec/logs/archives/archives.json</code>
-; alerts.json mitlesen (nur Alerts)
+; nur Alerts mitlesen
 * <code>tail -f /var/ossec/logs/alerts/alerts.json</code>
@@ Zeile 140: / Zeile 142: @@
 ; 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 (z.B. gegen MediaWiki oder Nextcloud) liefern die Anwendungslogs und FIM die Telemetrie.
+* 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).