Niveau 🟡 intermédiaire
Durée estimée : 25 min · Prérequis : NAT et box
ufwufwUn pare-feu, c'est le videur à l'entrée d'un établissement : il vérifie chaque personne qui se
présente à la porte principale et refuse celles qui ne sont pas sur la liste. Le piège Docker
détaillé plus bas, c'est l'équivalent d'une porte de service, à l'arrière du bâtiment, que le
videur ne surveille pas — quelqu'un peut très bien entrer par là sans jamais croiser le videur,
mĂŞme si celui-ci fait parfaitement son travail Ă la porte principale.
Un pare-feu (firewall) filtre le trafic réseau entrant et sortant d'une machine selon des
règles explicites : autoriser tel port, bloquer tel autre, selon la source ou la destination.
Contrairement au NAT (page précédente), qui bloque par effet de bord, un pare-feu est un outil
de sécurité intentionnel, avec des règles qu'on définit et qu'on peut auditer.
ufw (Uncomplicated Firewall) est l'interface simplifiée la plus courante sous Ubuntu
pour configurer le pare-feu du noyau Linux (iptables/nftables en coulisses). Une règle ufw
typique ressemble Ă ufw allow 22/tcp (autoriser le SSH) ou ufw deny 80/tcp (bloquer le web).
Par défaut, ufw applique la politique « tout refuser en entrée, tout autoriser en sortie » —
on n'ouvre ensuite que ce qui est explicitement nécessaire.
⚠️ Le piège Docker qui contourne
ufw— le point le plus important de cette page.
Docker gère lui-même ses propres règles de pare-feu, indépendamment deufw, et les
insère à un niveau plus profond. Techniquement : quand un conteneur publie un port (par
exemple-p 8080:80), Docker ajoute une règle dans la chaînenat/PREROUTINGdu noyau, qui
réécrit la destination du paquet entrant. Ce paquet redirigé transite alors par la chaîne
FORWARD(via les chaînesDOCKER-USERpuisDOCKER, qui l'acceptent) — jamais par la
chaîneINPUT, celle où vivent précisément les règles configurées parufw.Concrètement : un port publié par Docker reste joignable même si
ufwne l'autorise
nulle part, et même siufw statusn'en montre aucune trace.ufwne ment pas — il affiche
fidèlement ses propres règles — mais ces règles ne s'appliquent tout simplement jamais au
trafic redirigé par Docker.
Les parades possibles, par ordre de préférence :
127.0.0.1 uniquement (-p 127.0.0.1:8080:80) — le port n'est alorsDOCKER-USER — cette chaîne, elle, est bien consultée/etc/ufw/after.rules pour survivre à un redémarrage) permettent de"iptables": false dans sa🧪 Concrètement, sur notre exemple : la première parade (publication sur
127.0.0.1
uniquement, le reverse proxy s'occupant de l'accès réseau réel) est la stratégie structurelle
retenue par défaut. La règleDOCKER-USERa en plus été activée concrètement pour un service
précis (Portainer) qui avait besoin d'un port publié plus largement. La désactivation
d'iptablescôté Docker a été explicitement écartée.
Un paquet destiné à un port publié par Docker est détourné dès PREROUTING, avant même
d'atteindre la chaîne INPUT où vivent les règles ufw. Seul le trafic qui n'est pas
redirigé par Docker passe par INPUT — c'est tout le piège, en une image.
sudo ufw status verbose
# Affiche les règles ufw actives -- fidèle, mais incomplet face à Docker
sudo iptables -t nat -L DOCKER -n
# Affiche les règles que Docker a lui-même ajoutées -- c'est ici, pas dans
# "ufw status", qu'apparaissent les ports réellement publiés par les conteneurs
sudo ss -tulnp | grep docker-proxy
# Liste les ports effectivement en écoute et gérés par Docker,
# indépendamment de ce que dit ufw
Le réflexe à retenir : ufw status ne suffit jamais à lui seul pour un serveur qui fait tourner
Docker. Il faut aussi vérifier les règles iptables propres à Docker, ou plus simplement
tester directement depuis l'extérieur si un port est joignable.
sudo ufw status verbose && sudo iptables -t nat -L DOCKER -n
Compare les deux sorties : un port publié par un conteneur (docker ps pour la liste) doit
apparaître dans la seconde commande, qu'il soit ou non mentionné dans la première.
| SymptĂ´me | Cause probable | Solution |
|---|---|---|
Un service Docker reste joignable malgré une règle ufw deny sur son port |
Le port est publié par Docker, donc redirigé via FORWARD, jamais filtré par INPUT/ufw |
Publier le port sur 127.0.0.1 uniquement, ou ajouter une règle dans DOCKER-USER |
Croire que ufw status donne une vue complète du pare-feu sur une machine avec Docker |
ufw status n'affiche que ses propres règles, pas celles ajoutées par Docker |
Toujours croiser avec iptables -t nat -L DOCKER -n sur une machine qui fait tourner des conteneurs |
Désactiver iptables dans Docker pour « simplifier » |
Solution qui semble radicale mais casse le routage interne de Docker | Préférer publier sur 127.0.0.1 (structurel) ou une règle DOCKER-USER ciblée et persistée |
ufw filtre la chaîne INPUT du pare-feu Linux — mais Docker redirige ses ports publiés viaPREROUTING/FORWARD, qui ne passe jamais par INPUT.ufw ne l'autorise nulleufw status ne le montrera pas.127.0.0.1 uniquement (reverse proxy en façade) est la parade la plusDOCKER-USER, persistée dans /etc/ufw/after.rules, est la paradeParce que Docker redirige ce trafic dès la chaîne nat/PREROUTING, qui l'achemine ensuite via
FORWARD — les règles ufw, elles, s'appliquent à la chaîne INPUT, jamais traversée par ce
trafic redirigé.
sudo iptables -t nat -L DOCKER -n (ou l'observation directe des ports en Ă©coute via
ss -tulnp | grep docker-proxy).
Publier le port du conteneur sur 127.0.0.1 uniquement (-p 127.0.0.1:port:port) plutĂ´t que
sur toutes les interfaces — le service reste alors inaccessible directement depuis le réseau.
Sur une machine avec Docker installé, lance un conteneur avec un port publié classiquement
(-p 8080:80), puis ajoute une règle sudo ufw deny 8080/tcp. Teste depuis une autre machine du
réseau si le service reste joignable malgré cette règle — puis explique pourquoi, avec le
vocabulaire de cette page.
pare-feu ·
ufw ·
iptables ·
DOCKER-USER
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.