Sécuriser un serveur sans casser ses applications
Votre firewall UFW est actif, vous pensez votre serveur protégé. Pourtant Docker publie des ports qui contournent UFW : une base de données ou un panel d'administration peuvent répondre au monde entier sans que rien, dans votre configuration apparente, ne le laisse deviner. Vous découvrez le trou le jour où quelqu'un d'autre le trouve.
Cette masterclass vous donne une méthode en quatre temps, comprendre, refermer, vérifier, tenir, pour refermer cette porte avec la chaîne DOCKER-USER : tout le trafic externe vers vos conteneurs est bloqué par défaut, seuls les ports que vous avez choisis restent ouverts, et vos applications comme votre reverse proxy continuent de fonctionner.
Ce que cet exercice ne peut pas casser
L'exercice de cette page ne modifie rien sur votre serveur : vous observez et vous notez. Le seul moment qui change quelque chose, c'est l'application des règles, et la méthode l'encadre : chaque règle est expliquée avant d'être appliquée, et vous la vérifiez immédiatement depuis une autre machine.
Ce que vous saurez faire à la fin
- Voir votre serveur comme un attaquant le voit, avec un scan lancé depuis l'extérieur, et trancher port par port entre le normal et le risque.
- Refermer les ports publiés par Docker avec la chaîne DOCKER-USER, sans casser vos applications ni votre reverse proxy.
- Prouver, test extérieur à l'appui, que chaque port censé être fermé l'est vraiment, puis tenir cette fermeture dans la durée.
- Niveau membre· le prompt prêt à coller qui analyse votre inventaire, génère votre bloc DOCKER-USER commenté ligne par ligne et vous donne la commande de vérification.
- Niveau Pro· je passe votre serveur en revue avec vous et nous refermons les ports ensemble, règle par règle.
Quatre temps pour refermer la porte que Docker ouvre dans votre firewall, et la garder fermée.
Comprendre, refermer, vérifier, tenir
Le piège est là : UFW vous montre ce que vous croyez avoir fermé, pendant que Docker publie ses ports en passant devant. La réponse n'est pas de désactiver quoi que ce soit, ni de mémoriser la syntaxe iptables : c'est une méthode en quatre temps qui part de ce qui est réellement ouvert, le referme proprement par la chaîne prévue pour ça, le prouve de l'extérieur, et empêche le trou de se rouvrir au prochain conteneur.
1Comprendre : voir le serveur de l'extérieurdoute : « mon firewall est actif, je suis couvert, non ? »
Votre configuration UFW dit ce que vous croyez avoir fermé. Seul un scan lancé depuis une autre machine dit ce qui est réellement ouvert. À la main : lancez nmap sur votre serveur depuis l'extérieur, listez vos conteneurs et les ports qu'ils publient, notez votre reverse proxy (Cloudron, Nginx, Traefik, ou aucun). Puis séparez clairement : ce qui est normal (par exemple 22, 80, 443) et ce qui est un risque (une base de données, un panel d'administration accessibles de l'extérieur).
2Refermer : la chaîne DOCKER-USERdoute : « et si je casse mes applications ? »
Une fausse bonne idée d'abord : désactiver iptables dans Docker. Jamais. Ça casse le réseau interne de vos conteneurs. La solution passe toujours par la chaîne DOCKER-USER : un bloc de règles placé dans /etc/ufw/after.rules, qui bloque par défaut tout le trafic externe vers les conteneurs et n'autorise que les ports que vous avez décidé de garder ouverts au monde, en général 80 et 443. Et une discipline : chaque règle est précédée de son explication en clair. Une règle que vous ne comprenez pas, c'est soit une porte ouverte, soit une application en panne.
3Vérifier : la preuve vient de l'extérieurdoute : « comment savoir que ça a vraiment marché ? »
Appliquez le bloc, rechargez votre firewall, puis lancez tout de suite la commande de vérification depuis une autre machine, pour chaque port censé être fermé. Tant que vous n'avez pas vu de vos yeux que le port est fermé, considérez qu'il est ouvert. La preuve est toujours dans le test extérieur, jamais dans le fichier.
4Tenir : la routine qui empêche de rouvrir un troudoute : « et au prochain conteneur ? »
Chaque nouveau conteneur peut publier un port et rouvrir la porte sans bruit. D'où une checklist courte, en deux rendez-vous : avant chaque nouveau conteneur, et une fois par mois. C'est elle qui fait la différence entre un serveur refermé un jour et un serveur tenu dans la durée.
À vous de jouer : l'inventaire de votre serveur
Munissez-vous d'une autre machine que votre serveur. Rien n'est modifié dans cet exercice : vous observez et vous notez.
Le résultat, en 30 secondes
À partir de votre seule matière (votre sortie nmap, votre liste de conteneurs, votre reverse proxy, votre liste blanche), le prompt produit quatre choses : le diagnostic port par port, le bloc à coller dans /etc/ufw/after.rules commenté ligne par ligne, la commande de vérification avec son résultat attendu, et votre routine en cinq lignes.
Diagnostic : un port de panel d'administration vu ouvert depuis l'extérieur, classé risque. Le bloc à coller : tout le trafic externe vers les conteneurs bloqué par défaut, 80 et 443 autorisés, chaque ligne précédée de sa phrase d'explication. Puis la commande à lancer depuis une autre machine, avec ce que vous devez voir si le port est bien fermé, et la checklist à reprendre avant chaque nouveau conteneur.
Le prompt prêt à coller
# RÔLE Tu es un ingénieur en sécurité serveur, spécialiste de Docker et du firewall Linux, pédagogue et prudent. Tu expliques chaque règle en clair avant de la donner. Tu ne t'appuies QUE sur ce que je te fournis : ma configuration réelle. Ce qui manque, tu me le demandes, tu ne l'inventes jamais. Si tu n'es pas certain qu'une règle est sûre pour ma situation, tu me le signales au lieu de l'affirmer. # CONTEXTE Je fais tourner un serveur (VPS) avec Docker. Mon firewall UFW est actif mais Docker publie des ports qui contournent UFW. Je veux refermer cette porte avec la chaîne DOCKER-USER, sans casser mes applications ni mon reverse proxy. Ma matière (si j'en ai) :
Le prompt analyse votre inventaire, sépare le normal du risque, génère votre bloc DOCKER-USER expliqué ligne par ligne, vous donne la commande de vérification à lancer depuis une autre machine et votre routine en cinq lignes. Si vous n'avez pas encore de matière, il passe en mode interview, conteneur par conteneur. Laissez votre email, je vous l'envoie.
Vérifiez que c'est à vous
Vous venez de coller votre bloc de règles dans /etc/ufw/after.rules et de recharger votre firewall. Le fichier est en place, tout semble propre. Que faites-vous avant de considérer vos ports fermés ?
D'abord avec vos mots, sans regarder les options :
Expliquez-le pour l'ancrer
Expliquez à un collègue qui héberge ses applications sur un VPS pourquoi un firewall UFW actif ne prouve pas que ses ports sont fermés, et ce qu'il doit faire pour le savoir vraiment. Si vous tenez l'explication en deux phrases, c'est à vous.
Ce que vous savez faire maintenant
- Lire votre serveur comme un attaquant : ce qui est réellement ouvert, pas ce que le firewall affiche.
- Refermer les ports publiés par Docker via la chaîne DOCKER-USER, sans casser vos applications ni votre reverse proxy.
- Ne jamais croire une règle sur parole : la preuve vient du test lancé depuis une autre machine.
- Tenir dans la durée avec une routine avant chaque nouveau conteneur et une fois par mois.
Tant que vous n'avez pas vu de vos yeux que le port est fermé, considérez qu'il est ouvert.
Faites-le avec moi
Je passe votre serveur en revue avec vous : inventaire, règles, vérification extérieure, routine. Vous repartez avec un serveur refermé et la discipline pour qu'il le reste.