03.1 Docker-Grundüberwachung

Einleitung

Ein normal installierter Wazuh-Agent weiß schon eine ganze Menge über einen Docker-Host: Betriebssystem, Pakete, Prozesse, offene Ports, Schwachstellen und Änderungen an wichtigen Dateien. Was er nicht automatisch weiß, ist, wann ein Container gestartet, gestoppt, gelöscht oder plötzlich unhealthy wurde.

Genau diese Lücke schließt die Docker-Grundüberwachung. Ich trenne sie bewusst von den späteren Anwendungsseiten für Nextcloud, Vaultwarden oder einen Reverse-Proxy. Der Docker-Teil beantwortet erst einmal die allgemeine Frage: Was passiert auf der Containerplattform? Die Anwendungsseiten kümmern sich später darum, was innerhalb eines bestimmten Dienstes passiert.

Diese Trennung macht die Konfiguration übersichtlicher, wiederverwendbar und vor allem viel leichter zu tunen. Ein neuer Docker-Host bekommt dieselbe technische Basis; nur seine eigentlichen Anwendungen brauchen anschließend noch eigene Logquellen und Regeln.

Warum der normale Agent allein nicht reicht

Docker besteht aus mehreren Ebenen, die aus Sicht von Wazuh unterschiedliche Datenquellen sind:

Ebene	Was Wazuh dort sieht	Umsetzung
Docker-Host	Betriebssystem, Pakete, Prozesse, Ports, SCA und bekannte Schwachstellen	normaler Wazuh-Agent
Docker-Konfiguration	Änderungen an daemon.json, Registry- und Laufzeiteinstellungen	FIM über eine zentrale Agentengruppe
Docker Engine	Start, Stopp, Löschen, Health-Status und andere Laufzeitereignisse	lokaler Docker-Listener
Anwendung im Container	Loginfehler, HTTP-Fehler, Adminaktionen oder Backups	gezielt ausgewählte Anwendungslogs
Container-Image	Pakete und Schwachstellen innerhalb des Images	zusätzlicher Image-Scanner

Ein häufiger Denkfehler wäre, den installierten Docker-Prozess im Syscollector-Inventar schon als vollständige Containerüberwachung zu betrachten. Das beweist nur, dass Docker auf dem Host vorhanden ist. Erst der Docker-Listener verbindet den Wazuh-Agenten mit den Ereignissen der lokalen Docker Engine.

Umgekehrt macht auch der Listener nicht plötzlich alles sichtbar. Er liefert Engine-Ereignisse, aber keine vollständige semantische Auswertung aller Anwendungslogs und keinen Ersatz für einen Image-Scanner. Das ist kein Mangel, sondern eine sinnvolle Aufgabenteilung.

Mein Zielbild

Auf jedem Docker-Host läuft ein normaler, nativer Wazuh-Agent. Dieser Agent liest den lokalen Unix-Socket der Docker Engine über den von Wazuh mitgelieferten Docker-Listener. Der Socket wird dafür nicht im Netzwerk veröffentlicht.

Auf der Managerseite erhalten alle Docker-Hosts zusätzlich die Gruppe role-docker. Sie versieht die Ereignisse mit einem eindeutigen Label und überwacht /etc/docker per File Integrity Monitoring. Anwendungsspezifische Gruppen werden später additiv ergänzt:

default
└── role-docker
    ├── role-nextcloud
    ├── role-reverse-proxy
    └── role-vaultwarden

Ein Host kann also gleichzeitig mehreren Rollen angehören. Dadurch muss ich die Docker-Basis nicht in jeder Anwendungsgruppe kopieren und später an fünf Stellen pflegen.

Voraussetzungen

Bevor ich den Listener aktiviere, prüfe ich auf dem Docker-Host:

systemctl is-active docker wazuh-agent
systemctl is-enabled docker wazuh-agent

docker info
test -S /var/run/docker.sock

python3 --version
test -x /var/ossec/wodles/docker/DockerListener

Der Host braucht:

• einen bereits registrierten und aktiven Wazuh-Agenten;
• eine laufende Docker Engine mit lokalem Unix-Socket;
• Python 3 sowie Unterstützung für virtuelle Python-Umgebungen;
• genügend Rechte für Installation, Agentkonfiguration und Neustart;
• eine aktuelle Sicherung der lokalen ossec.conf.

Wazuh nennt für den Docker-Listener aktuell Python 3.8 bis 3.13 als unterstützten Bereich. Bei abweichenden Versionen würde ich nicht einfach auf gut Glück weitermachen, sondern zuerst die Kompatibilität mit der eingesetzten Wazuh-Version prüfen.

Schritt 1: Eine zentrale Docker-Rolle anlegen

Die zentrale Konfiguration liegt auf dem Wazuh-Manager unter /var/ossec/etc/shared/role-docker/agent.conf. Meine Grundfassung sieht so aus:

<agent_config os="Linux">
  <labels>
    <label key="environment">production</label>
    <label key="role.docker">true</label>
  </labels>

  <syscheck>
    <directories check_all="yes"
                 realtime="yes"
                 report_changes="no"
                 tags="docker_config">/etc/docker</directories>
  </syscheck>
</agent_config>

Die Labels machen Docker-Hosts später in Abfragen und Regeln eindeutig erkennbar. FIM überwacht die Docker-Konfiguration in Echtzeit. Mit check_all="yes" werden unter anderem Inhalt, Größe, Eigentümer, Rechte und Zeitstempel berücksichtigt. report_changes="no" verhindert, dass komplette Dateidifferenzen ungeprüft im Index landen. Für Konfigurationsdateien, die Registry-Zugangsdaten enthalten könnten, ist das die vorsichtigere Grundeinstellung.

Vor dem produktiven Austausch validiere ich die Datei:

sudo install -d -o wazuh -g wazuh -m 0770 \
  /var/ossec/etc/shared/role-docker

sudo install -o wazuh -g wazuh -m 0660 \
  /tmp/role-docker-agent.conf \
  /var/ossec/etc/shared/role-docker/agent.conf.new

sudo /var/ossec/bin/verify-agent-conf \
  -f /var/ossec/etc/shared/role-docker/agent.conf.new

Erst nach erfolgreicher Prüfung ersetze ich die produktive Datei und prüfe anschließend noch einmal den gesamten Shared-Bestand:

sudo mv \
  /var/ossec/etc/shared/role-docker/agent.conf.new \
  /var/ossec/etc/shared/role-docker/agent.conf

sudo chown wazuh:wazuh \
  /var/ossec/etc/shared/role-docker/agent.conf
sudo chmod 0660 \
  /var/ossec/etc/shared/role-docker/agent.conf

sudo /var/ossec/bin/verify-agent-conf

Schritt 2: Agents der Gruppe zuordnen

Die Gruppe wird einmal angelegt und anschließend additiv den vorgesehenen Agents zugewiesen:

sudo /var/ossec/bin/agent_groups -a -g role-docker
sudo /var/ossec/bin/agent_groups -a -i 001 -g role-docker
sudo /var/ossec/bin/agent_groups -s -i 001

001 ist hier nur eine neutrale Beispiel-ID. Ich entferne die vorhandene default-Gruppe nicht. Mehrere Gruppen sind gerade der Sinn dieses Aufbaus.

Ein Neustart des Managers ist für eine Änderung an der zentralen agent.conf nicht notwendig. Die Agents holen den neuen Stand über den normalen Konfigurationsabgleich. In der Wazuh-API beziehungsweise unter Endpoints muss der betroffene Agent anschließend den Status synced melden.

Schritt 3: Den Docker-Listener lokal vorbereiten

Der Listener läuft auf dem Docker-Host, nicht auf dem Wazuh-Manager. Er braucht das Python-Docker-SDK und passende HTTP-Bibliotheken. Ich installiere diese nicht in das systemweite Python, sondern in eine eigene virtuelle Umgebung:

sudo python3 -m venv /var/ossec/wodles/docker/venv

sudo /var/ossec/wodles/docker/venv/bin/python3 \
  -m pip install --disable-pip-version-check \
  docker==7.1.0 \
  urllib3==1.26.20 \
  requests==2.32.2

Die isolierte Umgebung hat für mich drei Vorteile:

1. Sie verändert keine Python-Pakete des Betriebssystems.
2. Die getesteten Versionen bleiben reproduzierbar.
3. Ein Betriebssystemupdate ersetzt nicht unbemerkt die Abhängigkeiten des Listeners.

Die Versionsstände sind Teil meiner getesteten Installation und keine ewige Empfehlung. Vor einem späteren Wazuh- oder Python-Upgrade prüfe ich sie erneut gegen die aktuelle Herstellerdokumentation.

Der mit Wazuh gelieferte Listener muss anschließend genau dieses Python verwenden. In meiner Installation zeigt seine erste Zeile deshalb auf:

#!/var/ossec/wodles/docker/venv/bin/python3

Vor dieser Änderung sichere ich die Originaldatei. Ein Wazuh-Paketupdate kann den mitgelieferten Listener ersetzen; deshalb gehört die Shebang-Prüfung auch in die Update-Abnahme.

Schritt 4: Den Listener in ossec.conf aktivieren

Der folgende Block kommt auf dem Docker-Host in die lokale Datei /var/ossec/etc/ossec.conf:

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

run_on_start startet die Überwachung direkt mit dem Agenten. Das Intervall ist das Wiederanlaufintervall des Moduls und bedeutet nicht, dass Docker nur alle zehn Minuten beobachtet wird. Während der Listener läuft, verarbeitet er die Engine-Ereignisse fortlaufend. attempts begrenzt die Wiederholungsversuche bei einem Startproblem.

Ich halte diesen Block absichtlich lokal. Der Socket, die Python-Umgebung und der Listener sind Eigenschaften des jeweiligen Hosts. Würde ich das Modul pauschal über eine Gruppe aktivieren, könnte eine versehentliche Gruppenzuweisung einen Agenten ohne Docker mit einer kaputten lokalen Konfiguration zurücklassen.

Vor dem Neustart prüfe ich die Modulkonfiguration:

sudo /var/ossec/bin/wazuh-modulesd -t
sudo systemctl restart wazuh-agent
sudo systemctl is-active wazuh-agent

Bei einem Fehler spiele ich die zuvor gesicherte ossec.conf und den ursprünglichen Listener zurück. Ein automatisches Installationsskript sollte genau diesen Rollback selbst erledigen.

Schritt 5: Das Installationsskript ausrollen

Die vorherigen beiden Schritte erklären, was auf dem Host eingerichtet wird. In meiner echten Umgebung führe ich diese Änderungen nicht auf jedem Docker-Host einzeln von Hand aus. Dafür gibt es das versionierte Skript:

scripts/install-docker-listener.sh

Die veröffentlichte und neutralisierte Fassung liegt zusammen mit der passenden sudoers-Vorlage im Repository wazuh-homelab:

• Installationsskript
• sudoers-Beispiel

Das öffentliche Repository enthält keine Zugangsdaten und keine internen Hostnamen. Für einen produktiven Einsatz prüfe ich trotzdem immer den konkreten Commit und den Skriptinhalt, bevor ich ihn auf einen Zielhost übertrage.

Das Skript übernimmt in einem reproduzierbaren Lauf:

1. Prüfung von Rootrechten und leerer Argumentliste;
2. Prüfung von ossec.conf, Docker-Listener und Docker-Socket;
3. Kontrolle von Python, Docker-CLI und erreichbarer Docker Engine;
4. Aufbau einer neuen virtuellen Python-Umgebung;
5. Installation der festgelegten Python-Pakete;
6. Sicherung von ossec.conf und vorhandenem Listener;
7. Anpassung der Listener-Shebang;
8. idempotentes Einfügen oder Aktualisieren des docker-listener-Blocks;
9. Syntaxprüfung mit wazuh-modulesd -t;
10. Neustart und Statusprüfung des Wazuh-Agenten;
11. abschließenden Docker-Ping aus der neuen virtuellen Umgebung.

Schlägt Syntaxprüfung oder Agentenstart fehl, stellt das Skript die beiden gesicherten Dateien wieder her und startet den Agenten mit dem vorherigen Stand. Die neue virtuelle Umgebung wird zunächst unter einem zeitgestempelten Arbeitsnamen aufgebaut und erst nach erfolgreicher Paketinstallation an ihre endgültige Stelle verschoben.

Ich habe diesen Rollout zunächst auf zwei Hosts vollständig abgenommen. Das ist ein wichtiger Unterschied zur zentralen Gruppenzuweisung: Ein Agent kann schon zu role-docker gehören und die FIM-Konfiguration synchronisiert haben, obwohl der lokale Docker-Listener dort noch nicht installiert wurde. Für den Rolloutstatus müssen deshalb beide Ebenen getrennt geprüft werden.

Skript übertragen und Prüfsumme vergleichen

Das Skript wird unprivilegiert auf den Zielhost übertragen. Der Stagingpfad ist bewusst fest vorgegeben:

scp \
  scripts/install-docker-listener.sh \
  dockeradmin@docker01.example.internal:/tmp/wazuh-docker-listener-install

Vor der Installation vergleiche ich die SHA-256-Prüfsumme der lokalen Repositoryfassung mit der übertragenen Datei:

sha256sum scripts/install-docker-listener.sh

ssh dockeradmin@docker01.example.internal \
  sha256sum /tmp/wazuh-docker-listener-install

Beide Werte müssen exakt gleich sein. Die Prüfsumme erkennt Übertragungsfehler und versehentliche Abweichungen. Sie beweist allein aber nicht, dass das Skript vertrauenswürdig ist: Wer Repository und Vergleichswert gleichzeitig manipulieren kann, kann natürlich auch zwei passende Werte erzeugen.

noexec auf /tmp bleibt erhalten

Der Upload nach /tmp bedeutet nicht, dass ich das Skript dort ausführe. Ein mit noexec gehärtetes /tmp darf und soll so bleiben. Die Datei wird dort nur geschrieben, gelesen und gehasht. Anschließend installiert install eine root-eigene ausführbare Kopie nach /usr/local/sbin:

sudo /usr/bin/install \
  -o root -g root -m 0755 \
  /tmp/wazuh-docker-listener-install \
  /usr/local/sbin/wazuh-docker-listener-install

sudo /usr/local/sbin/wazuh-docker-listener-install

Damit bleibt die Trennung sauber: /tmp ist nur Stagingbereich, /usr/local/sbin der kontrollierte Ausführungsort.

Automatisierung mit einer engen sudoers-Regel

Für den ersten Lauf kann ich die beiden Befehle ganz normal mit Kennworteingabe ausführen. Soll derselbe vertrauenswürdige Administrationsuser spätere Installationen ohne interaktives Kennwort durchführen, verwende ich keine pauschalen Freigaben für Paketmanager, systemctl, Python oder beliebige Dateikopien. Die sudoers-Regel erlaubt nur die exakt parametrierte Installation und das Zielskript ohne Argumente:

Cmnd_Alias WAZUH_DOCKER_INSTALL = \
    /usr/bin/install -o root -g root -m 0755 /tmp/wazuh-docker-listener-install /usr/local/sbin/wazuh-docker-listener-install

Cmnd_Alias WAZUH_DOCKER_RUN = \
    /usr/local/sbin/wazuh-docker-listener-install ""

dockeradmin ALL=(root) NOPASSWD: \
    WAZUH_DOCKER_INSTALL, WAZUH_DOCKER_RUN

Die leere Argumentliste hinter dem zweiten Kommando verhindert zusätzliche Skriptargumente. Die versionierte Vorlage enthält dafür den Platzhalter replace_me. Auf dem Administrationsrechner erzeuge ich daraus die Fassung für den echten Login und übertrage sie ebenfalls nur als Stagingdatei:

sed 's/replace_me/dockeradmin/g' \
  sudoers/wazuh-docker-listener.example \
  > /tmp/wazuh-docker-listener.sudoers

scp \
  /tmp/wazuh-docker-listener.sudoers \
  dockeradmin@docker01.example.internal:/tmp/wazuh-docker-listener.sudoers

Auf dem Zielhost wird die fertige Datei vor und nach der Installation mit visudo geprüft:

sudo visudo -cf /tmp/wazuh-docker-listener.sudoers

sudo install -o root -g root -m 0440 \
  /tmp/wazuh-docker-listener.sudoers \
  /etc/sudoers.d/wazuh-docker-listener

sudo visudo -cf /etc/sudoers.d/wazuh-docker-listener

Danach verwendet die Automatisierung ausdrücklich sudo -n, damit ein unerwarteter Kennwortdialog nicht unbemerkt hängen bleibt:

sudo -n /usr/bin/install \
  -o root -g root -m 0755 \
  /tmp/wazuh-docker-listener-install \
  /usr/local/sbin/wazuh-docker-listener-install

sudo -n /usr/local/sbin/wazuh-docker-listener-install

Diese Regel ist eng gegen Bedienfehler, aber keine echte Privilegientrennung. Der SSH-Benutzer kontrolliert die Quelldatei in /tmp, darf sie als root-eigenes Programm installieren und danach als root starten. Für diesen Benutzer entspricht das praktisch Root-Codeausführung. Ich setze sie deshalb nur für ein bewusst vertrauenswürdiges Administrationskonto ein. Eine stärkere Trennung bräuchte einen root-eigenen Updater, der ein kryptografisch signiertes Artefakt vor der Ausführung selbst verifiziert.

Update und erneute Ausführung

Das Skript akzeptiert absichtlich keine Argumente. Eine neue Repositoryfassung wird wieder über denselben Stagingpfad übertragen, erneut per SHA-256 geprüft, über das exakt erlaubte install-Kommando ersetzt und anschließend ohne Argumente gestartet.

Nach jedem Lauf prüfe ich Agentstatus, Listenerprozess, Docker-Ping und Gruppensynchronisation. Die datierten Sicherungen unter /var/ossec bleiben zunächst als Rückweg liegen und können später im Rahmen einer bewusst definierten Aufbewahrung bereinigt werden.

Schritt 6: Zugriff auf den Docker-Socket absichern

Der Docker-Socket ist keine harmlose Logdatei. Wer ihn kontrolliert, kann in einer normalen Rootful-Docker-Installation üblicherweise Container mit Host-Mounts und weitreichenden Rechten starten und damit faktisch den Host kontrollieren.

Deshalb gelten bei mir diese Regeln:

• /var/run/docker.sock bleibt ein lokaler Unix-Socket;
• Port 2375 wird nicht geöffnet;
• der Socket wird nicht in einen zusätzlichen Monitoring-Container gemountet;
• nur der native Wazuh-Agent beziehungsweise sein Listener greift lokal zu;
• ein eventuell notwendiger Remotezugriff würde ausschließlich bewusst über SSH oder gegenseitig authentisiertes TLS erfolgen;
• Änderungen an Rechten und Gruppenzugehörigkeiten des Sockets werden nicht als bequeme Problemlösung verwendet.

Das reduziert nicht die Macht des Listeners, aber die Zahl der Wege, über die der Socket erreichbar ist. Ein kompromittierter Prozess mit Socketzugriff bleibt ein ernstes Hostrisiko.

Schritt 7: Die Installation technisch prüfen

Zuerst prüfe ich, ob die virtuelle Umgebung Docker wirklich erreicht:

sudo /var/ossec/wodles/docker/venv/bin/python3 -c \
  'import docker; docker.from_env().ping()'

Danach suche ich Listenerprozess und Fehlermeldungen:

sudo pgrep -af DockerListener
sudo grep -iE 'docker-listener|dockerlistener|error' \
  /var/ossec/logs/ossec.log | tail -n 80

Auf dem Manager kontrolliere ich Gruppe und Synchronisation:

sudo /var/ossec/bin/agent_groups -s -i 001
sudo /var/ossec/bin/agent_control -i 001

Im Dashboard erscheint der Agent unter Endpoints als active und synced. Unter Docker müssen nach einem echten Ereignis Docker-Daten auftauchen.

Die echte Docker-Übersicht meiner Installation. Die auffällige Spitze stammt von sehr häufigen Healthchecks einer Containeranwendung und war genau der Anlass, die spätere Filterung nicht einfach dem Zufall zu überlassen.

Für einen Ende-zu-Ende-Test verwende ich kein beliebiges Image aus dem Internet, sondern ein bereits freigegebenes und lokal vorhandenes Testimage:

docker run --rm \
  --name wazuh-monitoring-test \
  <VORHANDENES-TESTIMAGE> \
  sleep 20

Damit entstehen mindestens Erzeugungs-, Start-, Stopp- und Löschereignisse. Der Test ist erst bestanden, wenn sie nicht nur im lokalen Agentenlog, sondern auch im Docker-Bereich des Dashboards sichtbar sind.

Schritt 8: Aus Ereignissen brauchbare Signale machen

Der Listener liefert zunächst Rohmaterial. Nicht jedes Docker-Ereignis ist automatisch ein Sicherheitsalarm. Containerstarts während eines Updates sind normal; ein dauerhaft unhealthy gemeldeter Dienst oder ständig sterbender Container ist dagegen interessant.

Meine generische Grundauswertung unterscheidet deshalb:

Ereignis	Behandlung
Container wird wieder healthy	sichtbar, aber keine Sofortmeldung
Container wird unhealthy	hoher Alarm mit Unterdrückungszeit
Container stirbt oder wird mehrfach beendet	erst nach Wiederholung hochstufen
interaktive Shell im Container	sicherheitsrelevantes Ereignis
wiederholte interaktive Shells im selben Container	höher priorisieren
erwarteter anwendungseigener Healthcheck	sehr gezielt unterdrücken

Wichtig ist das Wort gezielt. Eine Ausnahme darf nicht pauschal alle exec_start-Ereignisse oder einen kompletten Container ausblenden. Sie muss auf den bekannten Containernamen und den exakt erwarteten Befehl begrenzt sein. Sonst verschwindet zusammen mit dem Rauschen möglicherweise auch ein echter Angriff.

Die genauen Alarmlevel, Benachrichtigungswege und Wiederholungszeiten gehören in den späteren Bereich Alarmierung und Berichte. Auf dieser Seite reicht die technische Grundlage: Docker-Ereignisse kommen zuverlässig und mit genügend Kontext bei Wazuh an.

Warum ich nicht einfach alle Containerlogs einsammle

Der naheliegende Pfad /var/lib/docker/containers/*/*-json.log sieht verlockend aus. Eine pauschale Aufnahme würde aber mehrere Probleme erzeugen:

• verschiedene Anwendungen schreiben völlig unterschiedliche Formate;
• manche Container verwenden gar nicht den JSON-File-Logging-Treiber;
• Zugangsdaten, Tokens oder personenbezogene Inhalte könnten ungefiltert im Security-Index landen;
• Healthchecks und Debugausgaben können sehr große Datenmengen erzeugen;
• eine Regel, die für einen Webserver passt, passt nicht automatisch für eine Datenbank oder einen Passwortmanager.

Ich prüfe daher pro Anwendung erst Logging-Treiber, Mounts und tatsächliche Logpfade. Nur die benötigten Quellen werden aufgenommen und bekommen passende Decoder, Regeln und Filter. Genau dafür folgen später eigene Seiten.

Was diese Grundkonfiguration bewusst noch nicht macht

Die Docker-Grundüberwachung ist fertig, aber sie verspricht nicht mehr als sie leisten kann. Nicht enthalten sind:

• ein vollständiger Schwachstellenscan aller Container-Images;
• die Auswertung von Nextcloud-, Vaultwarden- oder Proxy-Logins;
• ein allgemeines Einsammeln sämtlicher Container-stdout-Ausgaben;
• Runtime-Blocking oder automatische Gegenmaßnahmen;
• eine eigene Regel für jede Anwendung;
• die Prüfung von Compose-Dateien außerhalb von /etc/docker.

Diese Punkte werden später bewusst einzeln ergänzt. So bleibt die Basis auch auf einem Docker-Host sinnvoll, auf dem eine völlig andere Anwendung läuft.

Kurze Abnahmecheckliste

• Docker und Wazuh-Agent laufen und starten automatisch.
• /var/run/docker.sock ist nur lokal erreichbar.
• Die Listener-Abhängigkeiten liegen in einer eigenen virtuellen Umgebung.
• wazuh-modulesd -t meldet keinen Fehler.
• Der DockerListener läuft mit dem Python der virtuellen Umgebung.
• Der Agent gehört additiv zu role-docker.
• Die zentrale Konfiguration steht auf synced.
• Das lokale Installationsskript stammt aus dem versionierten Stand und die SHA-256-Prüfsummen stimmen überein.
• Das Skript wurde aus /usr/local/sbin und nicht aus /tmp ausgeführt.
• Eine vorhandene NOPASSWD-Regel ist auf die beiden dokumentierten Kommandos begrenzt und ihre Root-Wirkung ist bewusst akzeptiert.
• Änderungen unter /etc/docker werden per FIM erkannt.
• Ein kontrollierter Containerlauf erscheint im Docker-Dashboard.
• Erwartete Healthchecks erzeugen keine dauerhafte Alertflut.
• Andere Engine-Ereignisse bleiben trotz Filterung sichtbar.
• Nach Wazuh- und Python-Updates wird der Listener erneut geprüft.

Typische Fehler

Symptom	Wahrscheinliche Ursache	Prüfung
Agent ist aktiv, Docker-Dashboard bleibt leer	Listener nicht aktiviert oder falsches Python	pgrep -af DockerListener, ossec.log
No module named docker	Docker-SDK fehlt im verwendeten Python	Shebang und virtuelle Umgebung prüfen
Permission denied am Socket	Listenerprozess erreicht /var/run/docker.sock nicht	Socketrechte und Agentprozess prüfen
Agent startet nach der Änderung nicht	fehlerhafter XML-Block	wazuh-modulesd -t und Backup zurückspielen
Gruppe ist zugewiesen, aber nicht synchron	ungültige Shared-Konfiguration oder Verbindungsproblem	verify-agent-conf, Endpointstatus
sehr viele gleichartige Events	anwendungseigener Healthcheck oder Debugschleife	Eventtyp, Containername und exakten Befehl auswerten
nach einem Wazuh-Update fehlen Events	Listener oder Shebang wurde ersetzt	Paketdatei und Pythonpfad erneut prüfen

Weiterlesen

• Wazuh: Docker überwachen
• Wazuh: zentrale Agentenkonfiguration
• Wazuh: Agentengruppen
• Wazuh: File Integrity Monitoring
• Docker: Zugriff auf den Daemon-Socket schützen
• Docker: Angriffsfläche des Daemons