Niveau 🔴 avancé
Durée estimée : 15 min · Prérequis : Gestion des secrets
Cette page ne réexplique pas le mécanisme — détaillé en profondeur en
M2, schéma des chaînes iptables compris. Elle pose la question de
sécurité qui en découle : à quoi bon un videur (le pare-feu) qui contrôle scrupuleusement la
porte principale, si une porte de service reste grande ouverte sans qu'il le sache ?
Rappel technique (détaillé en M2) : Docker insère ses propres
règles dans la chaîne nat/PREROUTING, qui redirige le trafic des ports publiés via FORWARD —
jamais via INPUT, où vivent les règles ufw. Un port publié par un conteneur reste donc
joignable même si ufw prétend le bloquer.
Pourquoi cette page existe dans le module Sécurité, et pas seulement en M2 : ce piège n'est
pas qu'une curiosité technique amusante — c'est un cas d'école de ce qui rend un pare-feu
dangereux en pratique : une fausse impression de sécurité. Un administrateur qui vérifie
ufw status, voit une règle de blocage, et en déduit à tort qu'un port est réellement protégé,
prend une décision de sécurité sur une information incomplète. Le risque n'est pas le piège
lui-même — c'est de ne pas savoir qu'il existe, et donc de ne jamais penser à vérifier
autrement.
Les parades, reliées au moindre privilège (vu en page précédente) :
publier un port en 127.0.0.1 uniquement n'est pas qu'une astuce réseau — c'est une application
directe du principe « n'accorder l'accès qu'à qui en a strictement besoin ». Un service derrière
un reverse proxy n'a besoin d'être joignable que depuis la machine elle-même ; la parade
structurelle du moindre privilège et la parade technique à ce piège précis sont, ici, une seule
et même décision.
⚠️ La leçon générale à retenir, au-delà de Docker. Ce piège illustre un principe plus
large : deux outils de sécurité qui opèrent à des niveaux différents (ufw, une surcouche ;
Docker, qui manipule directement des règles plus bas niveau) peuvent coexister sans se voir
l'un l'autre. La vérification d'un seul outil ne suffit jamais à garantir qu'un système dans
son ensemble se comporte comme prévu — un réflexe qui dépasse largement le seul cas Docker/ufw.
🧪 Concrètement, sur notre exemple : la parade retenue par défaut est la publication en
127.0.0.1, cohérente avec le modèle de menace de ce module (rien à exposer sur le réseau
local au-delà du strict nécessaire). Une règleDOCKER-USERexplicite a été utilisée pour le
seul cas où un port devait, pour des raisons temporaires, être publié plus largement (vu en
M6) — puis retirée dès que ce besoin a disparu.
Le danger n'est pas dans le mécanisme technique lui-même (déjà détaillé en M2), mais dans l'écart
entre ce qu'un outil de sécurité affiche et ce qui se passe réellement — un écart qui reste
invisible tant qu'on ne sait pas qu'il peut exister.
Les commandes de diagnostic (ufw status verbose, iptables -t nat -L DOCKER -n) sont
détaillées en M2. Le réflexe de sécurité à ajouter ici :
# Après CHAQUE nouveau service Docker déployé, vérifier ce qui est
# réellement exposé, pas seulement ce que ufw en dit :
sudo ss -tulnp | grep docker-proxy
Pour tout service qu'on croit protégé par ufw seul, confirmer avec
iptables -t nat -L DOCKER -n (détaillé en M2) qu'aucune règle Docker ne redirige ce port vers
l'extérieur en contournant cette protection supposée.
| Symptôme | Cause probable | Solution |
|---|---|---|
Confiance excessive dans ufw status seul, sur une machine avec Docker |
Absence de vérification croisée avec les règles propres à Docker | Systématiser la vérification iptables -t nat -L DOCKER -n après chaque déploiement de service |
| Généraliser abusivement ce piège à tout usage d'ufw, même sans Docker | Confusion entre le cas Docker précis et le fonctionnement général d'ufw | Le piège est spécifique à l'interaction avec Docker — ufw seul, sans Docker, fonctionne comme attendu |
| Ne considérer ce piège que comme une curiosité technique, sans en tirer de leçon générale | Lecture superficielle du mécanisme | Retenir la leçon générale : deux outils de sécurité à des niveaux différents peuvent ne pas se voir l'un l'autre |
127.0.0.1 est à la fois la parade technique et une application du moindreParce qu'il crée une fausse impression de sécurité : un administrateur qui vérifie ufw status
peut croire un port protégé alors qu'il reste joignable, et prendre des décisions sur une
information incomplète.
Parce qu'elle n'accorde l'accès qu'à ce qui en a strictement besoin (la machine elle-même, via
le reverse proxy), plutôt que d'exposer le port à tout le réseau par défaut.
Que deux outils de sécurité opérant à des niveaux différents peuvent coexister sans se voir
mutuellement — la vérification d'un seul outil ne garantit jamais le comportement de l'ensemble
du système.
Sur une machine avec Docker et ufw, reproduis le piège (un conteneur avec un port publié
classiquement, une règle ufw deny sur ce port), puis applique la parade 127.0.0.1 et
confirme, avec les deux commandes de vérification, que le port n'est plus accessible depuis
l'extérieur de la machine.
Aucun terme technique nouveau — voir DOCKER-USER,
ufw et
iptables, déjà posés en M2.
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.