Pare-feu Linux avec UFW : les règles à poser avant d'ouvrir un serveur

C’est quoi UFW ?

UFW, pour Uncomplicated Firewall, est le pare-feu intégré à la plupart des distributions Linux modernes, notamment Ubuntu et Debian. Il repose sur iptables ou nftables, mais sa vraie force, c’est qu’il rend les règles de filtrage accessibles sans avoir à écrire des commandes complexes à la main.

Sur un serveur fraîchement installé, UFW est généralement présent mais désactivé. L’activer sans précaution, c’est le meilleur moyen de perdre votre connexion SSH au prochain reboot. Voici comment poser les bonnes règles avant d’appuyer sur le bouton.

Avant d’activer UFW : autorisez d’abord SSH

La règle numéro un, celle qui vous évitera de courir au datacenter : autorisez votre port SSH avant d’activer le pare-feu. Si vous activez UFW sans règle SSH, votre connexion sera bloquée immédiatement.

sudo ufw allow ssh

Cette commande ouvre le port 22. Vous pouvez aussi préciser un port personnalisé si vous avez changé le port SSH par défaut :

sudo ufw allow 2222/tcp

À ce stade, sudo ufw status vous montrera la règle en attente, mais le pare-feu n’est pas encore actif. C’est exactement ce que vous voulez : les règles sont prêtes, mais rien ne bloque encore.

Activer UFW et vérifier l’état

Une fois SSH autorisé, vous pouvez activer UFW :

sudo ufw enable

UFW vous demandera confirmation (il vous prévient que l’activation peut interrompre les connexions en cours). Validez, puis vérifiez immédiatement l’état :

sudo ufw status

Vous devriez voir le statut active et la règle SSH présente. Pour une vue plus exploitable, utilisez l’option numbered :

sudo ufw status numbered

Chaque règle reçoit un numéro, ce qui facilite les suppressions ciblées. Sur un serveur qui commence à accumuler des règles, cette numérotation devient vite indispensable.

Ajouter des règles utiles sans tout ouvrir

La philosophie d’un pare-feu, c’est de refuser par défaut et n’autoriser que ce qui est nécessaire. Voici les règles les plus courantes pour un serveur web classique :

# HTTP et HTTPS
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Un service précis, par exemple un serveur de monitoring sur le port 9090
sudo ufw allow 9090/tcp

# Autoriser une IP spécifique pour SSH (plus restrictif que "allow ssh")
sudo ufw allow from 192.168.1.100 to any port 22 proto tcp

La dernière règle est un bon réflexe de sécurisation : plutôt que d’ouvrir le port SSH au monde entier, vous le limitez à une adresse de management connue. Si vous gérez plusieurs serveurs, combinez cette approche avec une passerelle SSH dédiée.

Pour ouvrir une plage de ports, UFW accepte aussi la syntaxe avec deux-points :

sudo ufw allow 6000:6007/tcp

Supprimer ou modifier une règle existante

La suppression est plus propre avec l’option numbered. Affichez d’abord les règles numérotées :

sudo ufw status numbered

Vous obtenez une sortie comme celle-ci :

[ 1] 22/tcp                     ALLOW IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 443/tcp                    ALLOW IN    Anywhere

Pour supprimer la règle HTTP (numéro 2), exécutez :

sudo ufw delete 2

UFW demande confirmation, puis la règle est retirée. Ne supprimez jamais la règle SSH pendant que vous êtes connecté à distance : UFW ne vous rattrapera pas, et votre session sera coupée.

Alternative : vous pouvez supprimer par la règle exacte que vous aviez posée, en préfixant la commande par delete :

sudo ufw delete allow 80/tcp

Tester les ports réellement exposés

Une fois vos règles en place, ne vous contentez pas du ufw status. Vérifiez ce que le réseau voit réellement avec ss (Socket Statistics), le successeur de netstat :

sudo ss -tlnp

Cette commande liste les ports TCP en écoute (-t pour TCP, -l pour listening, -n pour afficher les numéros de ports plutôt que les noms de services, -p pour le processus propriétaire).

L’important, c’est que la colonne Local Address:Port montre seulement les ports que vous avez explicitement autorisés dans UFW. Si vous voyez un service inconnu en écoute, identifiez-le et décidez s’il mérite d’être exposé.

Pour un test complet depuis l’extérieur, utilisez nmap depuis une autre machine :

nmap -p 22,80,443 votre-serveur.com

Les ports filtrés par UFW apparaîtront comme filtered dans le scan. Ceux que vous avez autorisés répondront open. C’est le test le plus fiable pour confirmer que votre pare-feu bloque bien ce qu’il doit bloquer.

Désactiver UFW en urgence

Si vous vous piégez avec une règle trop restrictive, et que vous avez encore un accès console (physique, IPMI, ou console VPS) :

sudo ufw disable

Cela désactive toutes les règles immédiatement. Les règles elles-mêmes restent sauvegardées et seront réappliquées au prochain ufw enable. Pour repartir d’une configuration propre :

sudo ufw reset

Cette commande supprime toutes les règles et remet UFW à son état initial. Pensez à sauvegarder votre configuration avant si vous avez des règles complexes : sudo ufw status numbered > ~/ufw-backup.txt.

Les précautions à prendre avant de modifier les règles

UFW est simple, mais une erreur de manipulation sur un serveur distant peut vous coûter votre accès. Voici ce que je vous conseille de vérifier systématiquement :

Gardez une session SSH de secours. Ouvrez un second terminal connecté au serveur avant toute modification, et ne le fermez pas tant que vous n’avez pas confirmé que la nouvelle règle fonctionne. Si vous coupez la première session, la seconde reste active.
Testez avant de déconnecter. Après avoir modifié UFW, ouvrez une nouvelle connexion SSH vers votre serveur depuis un autre terminal. Si elle passe, vos règles sont bonnes.
Sauvegardez vos règles. Un simple copier-coller du ufw status numbered dans un fichier texte local vous évitera de reconstruire la config de zéro après un reset.
Ne testez pas en production directement. Si vous avez un serveur de test ou une VM, répétez la procédure dessus avant de l’appliquer sur un serveur critique. Cinq minutes de test vous économiseront une heure de console de secours.

UFW et Docker : le conflit à connaître

Si vous utilisez Docker sur le même serveur, sachez qu’UFW et Docker ne coopèrent pas toujours par défaut. Docker modifie directement les règles iptables, et un conteneur exposé sur le port 80 restera accessible même si UFW bloque le port 80.

La raison : Docker insère ses propres règles iptables avant celles d’UFW. Pour forcer le respect d’UFW avec Docker, vous devez passer le daemon Docker en mode iptables=false ou utiliser un fichier de configuration UFW dédié. Ce n’est pas trivial, et c’est un sujet qui mérite son propre article. Retenez simplement que si un conteneur est exposé, ne comptez pas sur UFW seul pour le protéger.

Avec ces règles en place, votre serveur Linux a un pare-feu actif, lisible et facile à maintenir. Le plus important reste de tester chaque ouverture de port avant de fermer votre session SSH. Si vous avez un retour d’expérience sur UFW ou une erreur classique à signaler, les commentaires sont là pour ça.