Docker Stack Traefik: Unterschied zwischen den Versionen

@@ 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.
-==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).

Docker Stack Traefik: Unterschied zwischen den Versionen

Version vom 27. Juni 2026, 16:25 Uhr

Navigationsmenü

Suche