Einen Docker-Host absichern

Verkehr zu einem veröffentlichten Container-Port wird an den Container weitergeleitet, nicht an den Host zugestellt, und läuft daher über den FORWARD-Pfad. Die Docker-Dokumentation sagt es für ufw ganz deutlich: Pakete werden geroutet, bevor die Firewall-Regeln greifen können. Für deine eigenen Regeln lässt Docker eine Chain frei, DOCKER-USER, die es vor seinen eigenen auswertet.

Eine Firewall, die nur INPUT-Regeln schreibt, schützt also die Dienste des Hosts, nicht die Container. Ein Datenbank-Container, der mit -p 3306:3306 gestartet wurde, ist für die ganze Welt offen, auch wenn ufw 3306 verbietet.

• Sperren erreichen die Container. Ist Docker vorhanden, springt der Agent nicht nur aus INPUT, sondern auch aus DOCKER-USER in seine eigene INFRAFENCE-Chain und hält diesen Sprung an erster Stelle. Sperren, Bedrohungslisten und Ländersperren gelten deshalb auch für veröffentlichte Container-Ports. Entfernt ein Neustart von Docker oder ein Neuladen der Firewall den Sprung, setzt der Agent ihn wieder.
• Offene Datenbank-Ports lassen sich schließen, auch bei Containern. Ein Datenbank-, Cache- oder Admin-Port, der aus dem Internet erreichbar ist (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, die Docker-API und die anderen, die der Agent kennt), lässt sich im Dashboard schließen. Die Regel prüft den Port, den der Client angefragt hat (--ctorigdstport), der auch nach der Adressumsetzung von Docker noch stimmt, für IPv4 und IPv6. Verbindungen, die vor dem Schließen geöffnet wurden, werden ebenfalls getrennt, mit dem Tool conntrack, wenn es installiert ist.
• Container und dein Netz behalten den Zugriff. Loopback und private Adressen, darunter die Docker-Netze, sind von einem geschlossenen Port nie betroffen, ebenso wenig alles, was auf deiner Whitelist steht.
• Regelmäßige Clients werden nicht abgeschnitten. Der Agent zählt, wer sich mit diesen Ports verbindet, aus der Socket-Tabelle und, bei veröffentlichten Container-Ports, aus der conntrack-Tabelle. Solange eine Adresse, die an 3 der letzten 7 Tage gesehen wurde, nicht auf der Whitelist steht, wird der Port nicht geschlossen (Regelmäßige Clients).
• Jede Änderung wird geprüft. Der Agent schließt nie SSH, 80, 443 oder einen Port, auf dem ein Webserver lauscht, und nimmt eine Änderung zurück, wenn SSH oder eine Website nicht mehr antwortet.

Seine Regeln liegen in eigenen Chains, und die Chains von Docker oder deine eigenen ändert er nie. Ist das iptables des Systems auf das nf_tables-Backend umgestiegen, während Docker noch auf dem Legacy-Backend läuft, lässt der Agent seinen Sprung dort, wo die Chain von Docker liegt, bis Docker neu startet.

Zwei Setups haben keine DOCKER-USER-Chain, dort kann der Agent veröffentlichte Ports nicht erreichen: Docker mit "iptables": false und das nftables-Backend von Docker, seit Docker 29 experimentell. Für die Dienste des Hosts selbst gelten Sperren über INPUT weiterhin.

Ab Agent 1.0.42 liest die Web-Firewall über den Docker- oder Podman-Socket, nur lesend:

• die Access-Logs von Reverse Proxys: Traefik (JSON oder sein Standardformat, aus seiner Logdatei oder seiner Ausgabe), Caddy (JSON) und HAProxy;
• die Ausgabe von Webservern in Containern (Images von nginx, OpenResty, Apache httpd, WordPress, php:*-apache und LiteSpeed), wenn sie Port 80 oder 443 veröffentlichen oder hinter einem Proxy stehen, dessen Log nicht gelesen wird.

Hinter einem Proxy-Container wird die Adresse des Besuchers nur bei Anfragen, die vom Proxy selbst kommen, aus X-Forwarded-For genommen. Hinter Cloudflare wird der Besucher nur bei Anfragen aus den Adressbereichen von Cloudflare aus CF-Connecting-IP genommen, und eine Cloudflare-Adresse wird nie gesperrt. Die Serverseite zeigt jedes gelesene Log unter Netzwerk › Erkennung von Web-Angriffen, oder warum keins gelesen wird. Details: Access-Logs von Reverse Proxys und Containern.

Mit drei Labels steuerst du das pro Container: infrafence.monitor (true oder false), infrafence.log-path (Host-Pfade seiner Logs) und infrafence.domain (seine Domains). Ab Agent 1.0.35 listet der Agent außerdem die Domains hinter Traefik und Caddy aus deren Labels auf, so kann jede Website das Monitoring-Badge bekommen, verifiziert über einen DNS-TXT-Eintrag.

Auf dem Host (empfohlen): der Installationsbefehl am Ende dieser Seite, als root. Der Agent findet dann Web-Container und liest ihre Labels mit dem Kommandozeilen-Tool docker. Wenn du willst, führ vorher die Prüfung nur lesend aus:

curl -fsSL https://github.com/infrafence/infrafence-agent/releases/latest/download/install.sh | sudo bash -s -- --dry-run

Als Container: Das Image ghcr.io/infrafence/infrafence-agent (auch auf Docker Hub als infrafence/infrafence-agent) gibt es für mehrere Architekturen, signiert mit cosign. Es braucht das Netzwerk und den Prozess-Namespace des Hosts, Rechte zum Verwalten der Host-Firewall sowie /var/log und den Docker-Socket nur lesend:

docker run -d --name infrafence-agent --restart unless-stopped \
  --privileged --network host --pid host \
  -v /var/log:/var/log:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v infrafence-config:/etc/infrafence \
  -e INFRAFENCE_TOKEN=<TOKEN> \
  ghcr.io/infrafence/infrafence-agent:latest

Das Image enthält kein Kommandozeilen-Tool docker, also gibst du dem Agent im Container Logdateien mit WEB_LOG_PATH an; Proxy-Logs und die Ausgabe von Containern liest er weiterhin über den Socket. Mit Docker Compose funktioniert es genauso, und eine Swarm-Stack-Datei startet einen Agent pro Node. Alle Variablen und Mounts stehen unter Docker.

• Verkehr zwischen Containern auf demselben Host: Er verlässt die Docker-Netze nie, und private Adressen werden nie gesperrt.
• Container-Images: Die Schwachstellenprüfung deckt die installierten Pakete des Hosts ab, nicht den Inhalt deiner Images.
• Sperren, die Whitelist und Ländersperren gelten für IPv4; geschlossene Ports für IPv4 und IPv6.

Für einen Cluster statt eines einzelnen Hosts siehe Intrusion Detection für Kubernetes-Nodes. Für einen Coolify-Server siehe Einen Coolify-Server absichern.