Sécurité d'un hôte Docker

Le trafic vers un port de conteneur publié est transféré au conteneur, pas remis à l'hôte : il passe donc par le chemin FORWARD. La documentation de Docker le dit sans détour à propos d'ufw : les paquets sont routés avant que les règles du pare-feu puissent s'appliquer. Docker laisse une chaîne pour vos propres règles, DOCKER-USER, qu'il évalue avant les siennes.

Un pare-feu qui n'écrit que des règles INPUT protège donc les services de l'hôte, pas les conteneurs. Un conteneur de base de données lancé avec -p 3306:3306 est ouvert au monde entier, même si ufw refuse le 3306.

• Les bannissements atteignent les conteneurs. Quand Docker est présent, l'agent saute vers sa propre chaîne INFRAFENCE depuis DOCKER-USER comme depuis INPUT, et garde ce saut en première position. Les bannissements, les listes de menaces et les blocages par pays s'appliquent donc aussi aux ports publiés par les conteneurs. Si un redémarrage de Docker ou un rechargement du pare-feu supprime le saut, l'agent le remet en place.
• Les ports de base de données exposés peuvent être fermés, conteneurs compris. Un port de base de données, de cache ou d'administration ouvert sur internet (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch, l'API Docker et les autres que l'agent connaît) peut être fermé depuis le tableau de bord. La règle correspond au port demandé par le client (--ctorigdstport), qui reste juste après la traduction d'adresse de Docker, en IPv4 comme en IPv6. Les connexions ouvertes avant la fermeture du port sont coupées aussi, avec l'outil conntrack quand il est installé.
• Les conteneurs et votre réseau gardent l'accès. Les adresses de loopback et privées, dont celles des réseaux Docker, ne sont jamais concernées par un port fermé, pas plus que ce qui figure dans votre liste blanche.
• Il ne coupe pas les clients habituels. L'agent compte qui se connecte à ces ports, à partir de la table des sockets et, pour les ports de conteneur publiés, de la table conntrack. Tant qu'une adresse vue 3 des 7 derniers jours n'est pas dans la liste blanche, le port n'est pas fermé (Clients habituels).
• Chaque changement est vérifié. L'agent ne ferme jamais SSH, le 80, le 443 ni un port sur lequel écoute un serveur web, et annule un changement si SSH ou un site cesse de répondre.

Ses règles vivent dans ses propres chaînes, et il ne modifie jamais les chaînes de Docker ni les vôtres. Si la commande iptables du système est passée au backend nf_tables alors que Docker tourne encore sur l'ancien backend legacy, l'agent garde son saut là où se trouve la chaîne de Docker, jusqu'au redémarrage de Docker.

Deux configurations n'ont pas de chaîne DOCKER-USER, et l'agent ne peut alors pas atteindre les ports publiés : Docker lancé avec "iptables": false, et le backend nftables de Docker, expérimental depuis Docker 29. Les bannissements s'appliquent toujours aux services de l'hôte via INPUT.

Depuis l'agent 1.0.42, le pare-feu web lit, via le socket Docker ou Podman et en lecture seule :

• les journaux d'accès des reverse proxies : Traefik (en JSON ou dans son format par défaut, depuis son fichier journal ou sa sortie), Caddy (JSON) et HAProxy ;
• la sortie des serveurs web en conteneur (images nginx, OpenResty, Apache httpd, WordPress, php:*-apache et LiteSpeed), quand ils publient le port 80 ou 443 ou se trouvent derrière un proxy dont le journal n'est pas lu.

Derrière un conteneur proxy, l'adresse du visiteur n'est prise dans X-Forwarded-For que pour les requêtes qui viennent du proxy lui-même. Derrière Cloudflare, le visiteur n'est pris dans CF-Connecting-IP que pour les requêtes venant des plages de Cloudflare, et une adresse Cloudflare n'est jamais bannie. La page du serveur montre chaque journal lu sous Réseau › Détection des attaques web, ou pourquoi aucun n'est lu. Détails : Journaux d'accès des reverse proxies et des conteneurs.

Trois labels permettent de le piloter conteneur par conteneur : infrafence.monitor (true ou false), infrafence.log-path (les chemins de ses journaux sur l'hôte) et infrafence.domain (ses domaines). Depuis l'agent 1.0.35, l'agent liste aussi les domaines derrière Traefik et Caddy à partir de leurs labels, pour que chaque site puisse recevoir le badge de surveillance, vérifié par un enregistrement DNS TXT.

Sur l'hôte (recommandé) : la commande d'installation en bas de cette page, en root. L'agent trouve alors les conteneurs web et lit leurs labels avec l'outil en ligne de commande docker. Lancez d'abord le contrôle en lecture seule si vous le souhaitez :

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

En conteneur : l'image ghcr.io/infrafence/infrafence-agent (aussi sur Docker Hub sous infrafence/infrafence-agent) est multi-architecture et signée avec cosign. Elle a besoin du réseau et de l'espace de noms des processus de l'hôte, des privilèges pour gérer le pare-feu de l'hôte, et de /var/log et du socket Docker en lecture seule :

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

L'image ne contient pas l'outil en ligne de commande docker : dans le conteneur, indiquez à l'agent les journaux en fichier avec WEB_LOG_PATH ; les journaux des proxies et la sortie des conteneurs restent lus via le socket. Docker Compose fonctionne de la même façon, et un fichier de stack Swarm lance un agent par nœud. Chaque variable et chaque montage sont décrits dans Docker.

• Le trafic entre conteneurs d'un même hôte : il ne quitte jamais les réseaux Docker, et les adresses privées ne sont jamais bannies.
• Les images de conteneurs : le contrôle des vulnérabilités porte sur les paquets installés sur l'hôte, pas sur le contenu de vos images.
• Les bannissements, la liste blanche et les blocages par pays s'appliquent à l'IPv4 ; les ports fermés, à l'IPv4 et à l'IPv6.

Pour un cluster plutôt qu'un seul hôte, voir Détection d'intrusion sur les nœuds Kubernetes. Pour un serveur Coolify, voir Sécuriser un serveur Coolify.