Configurer un pare-feu Linux avec UFW

Un serveur Linux exposé sur Internet reçoit des tentatives de connexion en continu, sur tous les ports ouverts. UFW (Uncomplicated Firewall) met en place une politique de filtrage claire en quelques commandes, sans écrire de règles iptables ou nftables à la main.

Ce guide couvre l’installation et la configuration sur Debian et Ubuntu, les commandes équivalentes pour Fedora, RHEL et openSUSE, et surtout les trois pièges qui font croire à tort qu’un pare-feu UFW protège une machine : les conteneurs Docker, les connexions déjà établies et le pare-feu du fournisseur.

Règle de sécurité essentielle : autorisez toujours votre port SSH avant d’activer UFW. Activer un pare-feu avec une politique de refus entrant sans avoir ouvert SSH au préalable coupe immédiatement l’accès distant à la machine.

Prérequis

Avant de configurer un pare-feu Linux avec UFW, réunissez trois éléments. Un accès sudo ou root sur la machine. Le port SSH réellement utilisé : le port par défaut est 22, mais si vous l’avez modifié en suivant le guide de configuration SSH, c’est ce port personnalisé qu’il faut autoriser, pas 22. Si possible, un accès console indépendant de SSH (console série ou KVM du fournisseur VPS, IPMI) : c’est la seule façon de reprendre la main si une règle vous coupe l’accès.

Installer UFW sur Debian et Ubuntu

UFW est préinstallé sur Ubuntu. Sur Debian, il faut l’installer : c’est la cause la plus fréquente du message ufw : commande introuvable sur une image VPS minimale.

sudo apt update
sudo apt install ufw

Le paquet dépend directement du paquet iptables : UFW ne réimplémente pas le filtrage, il génère des règles à partir de commandes simplifiées. Vérifiez la version installée.

ufw --version

Sortie réelle obtenue lors de la vérification de ce guide :

ufw 0.36.2
Copyright 2008-2023 Canonical Ltd.

Ne confondez pas ce cas avec un autre message, très différent : ERROR: You need to be root to run this script. Celui-là signifie que le paquet est bien installé et que seul sudo manque.

UFW, iptables et nftables : ce qui tourne réellement

UFW dépend du paquet iptables, mais ce paquet n’est plus un backend unique. Sur un système Debian ou Ubuntu récent, la commande iptables est un lien géré par update-alternatives, qui pointe soit vers iptables-legacy (l’implémentation historique), soit vers iptables-nft (une couche de compatibilité qui traduit les règles vers le moteur nftables du noyau).

sudo update-alternatives --display iptables

Sortie réelle sur le système de test :

iptables - auto mode
  link best version is /usr/sbin/iptables-nft
  link currently points to /usr/sbin/iptables-nft

Ce choix de priorité pour iptables-nft est celui de Debian depuis Debian 10 (Buster) : les notes de version officielles le formulent sans ambiguïté, « the nftables-based variant, using the nf_tables Linux kernel subsystem, is the default in buster ». Debian 13 et Ubuntu 26.04 LTS en héritent directement.

La conséquence est visible directement dans le noyau. Une fois UFW actif, nft list ruleset affiche les tables générées, précédées d’un avertissement explicite :

# Warning: table ip filter is managed by iptables-nft, do not touch!

Concrètement : vos règles UFW sont bien stockées et évaluées par nftables, même si les commandes et les sorties d’UFW parlent encore le vocabulaire iptables.

Deux règles pratiques en découlent. Ne modifiez pas l’alternative iptables sans raison précise : UFW n’est testé et maintenu par Canonical que dans cette configuration standard. Et n’ajoutez pas de règles nftables natives à la main sur une machine gérée par UFW : la documentation de sécurité Ubuntu déconseille explicitement de faire cohabiter les deux.

Définir la politique par défaut avant d’activer

Avant toute activation, décidez du comportement par défaut. La pratique recommandée refuse tout le trafic entrant et autorise tout le trafic sortant.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Avertissement — risque de perte d’accès immédiat. Le moment où ces commandes prennent effet dépend de l’état d’UFW, et c’est une distinction critique. Si UFW n’a jamais été activé, elles ne font qu’écrire une valeur dans /etc/default/ufw : rien n’est bloqué avant ufw enable. Mais si UFW tourne déjà, sudo ufw default deny incoming s’applique instantanément et coupe votre session SSH s’il n’existe pas encore de règle l’autorisant. Vérifiable en comparant sudo iptables -S ufw-skip-to-policy-input avant et après la commande : la cible bascule de ACCEPT à DROP sans aucun rechargement. Sur une machine où UFW est actif, posez donc la règle SSH d’abord.

Ces valeurs sont écrites dans /etc/default/ufw. Sur une installation neuve, le fichier contient bien :

DEFAULT_INPUT_POLICY="DROP"
DEFAULT_OUTPUT_POLICY="ACCEPT"
DEFAULT_FORWARD_POLICY="DROP"

Une recommandation circule souvent : passer aussi le trafic sortant en deny. Ne le faites pas sans mesurer la conséquence. sudo ufw default deny outgoing casse immédiatement la résolution DNS, apt update et la synchronisation horaire. Si vous y tenez, il faut ouvrir explicitement au minimum les ports 53 (DNS), 80 et 443 (dépôts de paquets) et 123 (NTP) en sortie, et accepter de déboguer chaque service qui sortira ensuite.

Autoriser SSH avant d’activer

Autorisez le port SSH réellement utilisé. Avec le port par défaut :

sudo ufw allow ssh

Avec un port personnalisé (exemple : 2222, comme dans le guide de configuration SSH) :

sudo ufw allow 2222/tcp

ufw allow ssh fonctionne par résolution du nom de service ssh dans /etc/services (port 22/tcp), pas par lecture de votre sshd_config. Le profil applicatif OpenSSH a exactement la même limite : il ne couvre que le port 22. Si vous avez déplacé SSH, ces deux formes n’ouvrent pas le bon port et vous coupent l’accès à l’activation. Utilisez la forme numérique.

UFW reconnaît aussi des profils applicatifs, déposés par certains paquets dans /etc/ufw/applications.d/.

sudo ufw app list

Sur un serveur accessible en SSH, seul le profil OpenSSH apparaît en général : c’est le paquet openssh-server qui le dépose. Les autres arrivent avec les paquets correspondants — un serveur Nginx ajoute par exemple un profil « Nginx Full ».

Activer UFW et vérifier l’état

Une fois la règle SSH en place, activez le pare-feu.

sudo ufw enable

Une invite de confirmation apparaît si la commande est exécutée depuis une connexion SSH active — c’est un avertissement normal, pas une erreur.

Vérifiez ensuite l’état et les règles en place.

sudo ufw status verbose
sudo ufw status numbered

status numbered affiche chaque règle précédée d’un numéro. Ce numéro sert à la supprimer précisément, plutôt que de reconstruire la règle pour la retirer.

Gérer les règles au quotidien

Autoriser une IP ou un sous-réseau précis

Pour restreindre un port à une plage d’adresses plutôt que de l’ouvrir à tout Internet :

sudo ufw allow from 10.10.10.0/24 to any port 2222 proto tcp

Autoriser une plage de ports

sudo ufw allow 8080:8081/tcp

Sur une plage, le protocole est obligatoire : ufw allow 8080:8081 seul est refusé.

Bloquer une adresse IP

sudo ufw deny from 192.168.100.10

L’ordre des règles compte

UFW applique la première règle qui correspond, puis arrête l’évaluation. Ajouter un deny après un allow qui couvre déjà le même trafic ne produit donc aucun effet. Pour insérer un blocage en tête de liste :

sudo ufw insert 1 deny from 203.0.113.10

insert exige qu’au moins une règle existe déjà : sur une liste vide, la commande renvoie ERROR: Invalid position '1'.

Supprimer une règle par son numéro

Listez d’abord les règles pour connaître le numéro exact.

sudo ufw status numbered
sudo ufw delete 3

Les numéros se décalent après chaque suppression : la règle 4 devient la règle 3. Si vous devez en retirer plusieurs, supprimez-les du numéro le plus grand vers le plus petit, ou relistez entre chaque suppression. La forme littérale évite entièrement ce piège :

sudo ufw delete allow 8080:8081/tcp

Limiter les tentatives de connexion avec ufw limit

ufw allow autorise un port sans limite de fréquence. ufw limit ajoute une protection contre le brute-force directement au niveau du pare-feu.

sudo ufw limit 2222/tcp

Le seuil est souvent cité sans preuve. Il est lisible dans la règle réellement générée par UFW, dans /etc/ufw/user.rules :

-A ufw-user-input -p tcp --dport 2222 -m conntrack --ctstate NEW -m recent --set
-A ufw-user-input -p tcp --dport 2222 -m conntrack --ctstate NEW -m recent --update --seconds 30 --hitcount 6 -j ufw-user-limit
-A ufw-user-input -p tcp --dport 2222 -j ufw-user-limit-accept

--seconds 30 --hitcount 6 : une adresse IP qui ouvre six connexions ou plus en 30 secondes sur ce port est refusée. Le seuil n’est pas configurable depuis la ligne de commande.

Trois limites à connaître avant de compter dessus. limit ne s’applique qu’au TCP. Il ne distingue pas un attaquant d’un utilisateur légitime derrière un NAT partagé, qui peut se retrouver bloqué. Et il est inefficace contre un botnet qui change d’adresse à chaque tentative, puisque le compteur est par adresse source.

Une précision sur l’IPv6, souvent mal rapportée : de nombreux articles affirment que ufw limit ne fonctionne qu’en IPv4, en s’appuyant sur un rapport de bogue de 2012. Le code source d’UFW montre que ce n’est plus le cas — la prise en charge est détectée à l’exécution, selon que ip6tables expose ou non le module recent :

if 'recent-set' in nf_caps and 'recent-update' in nf_caps:
    self.caps['limit']['6'] = True

Sur un système où l’IPv6 est actif dans UFW et où le module est disponible, limit protège donc les deux protocoles.

ufw limit ne remplace pas fail2ban, dont la configuration est détaillée dans son guide dédié. Fail2ban lit les journaux applicatifs et bannit sur des critères plus fins ; ufw limit ne regarde que la fréquence des nouvelles connexions. Les deux sont complémentaires sur le port SSH.

Filtrer le trafic routé avec ufw route

ufw allow filtre le trafic destiné à la machine elle-même. Il ne filtre pas le trafic que la machine transmet à une autre — machine virtuelle, conteneur, client VPN. Ce trafic traverse la chaîne FORWARD, et se règle avec ufw route :

sudo ufw route allow proto tcp from any to any port 80
sudo ufw route allow from 10.8.0.0/24 to any

Ces règles apparaissent avec l’action ALLOW FWD, distincte du ALLOW IN des règles ordinaires. Sortie réelle de sudo ufw status numbered :

[ 4] 80/tcp                     ALLOW FWD   Anywhere
[ 5] Anywhere                   ALLOW FWD   10.8.0.0/24

La politique de routage par défaut est DROP (DEFAULT_FORWARD_POLICY dans /etc/default/ufw). C’est la commande à connaître dès que la machine sert de routeur, de passerelle VPN ou d’hôte de conteneurs.

Le piège Docker : UFW est contourné

C’est le décalage le plus dangereux entre ce qu’affiche UFW et ce que voit réellement Internet. Sur une machine où Docker tourne, un conteneur lancé avec -p 8080:80 est joignable depuis l’extérieur même si UFW refuse tout le trafic entrant et n’a aucune règle pour le port 8080.

La cause est vérifiable en une commande. Voici l’ordre réel des sauts dans la chaîne FORWARD, relevé sur une machine où UFW est actif et Docker installé :

sudo iptables -S FORWARD

Extrait de la sortie réelle, chaînes de journalisation retirées pour la lisibilité :

-P FORWARD DROP
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-FORWARD
[...]
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward

Docker place ses propres chaînes avant celles d’UFW. Le trafic destiné à un port publié est redirigé dès la table nat (PREROUTING saute vers la chaîne DOCKER), puis accepté par DOCKER-FORWARD — bien avant qu’UFW ait son mot à dire. L’ordre est le même que dockerd démarre avant ou après ufw enable.

Second point décisif : les règles que vous créez avec ufw allow vivent dans la chaîne INPUT, que le trafic vers un conteneur ne traverse jamais.

-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input

Ce n’est donc pas un bogue mais une conséquence d’architecture : ufw deny 8080 ne peut structurellement rien contre un port publié par Docker.

La réponse la plus simple, et suffisante dans la majorité des cas, consiste à ne jamais publier un port sur toutes les interfaces. En liant la publication à la boucle locale, le service reste accessible depuis la machine et depuis un reverse proxy, mais jamais directement depuis Internet :

docker run -d -p 127.0.0.1:8080:80 nginx

Les corrections plus complètes existent — rediriger DOCKER-USER vers ufw-user-forward dans /etc/ufw/after.rules, puis n’ouvrir qu’avec ufw route allow en visant le port interne du conteneur et non le port publié. Elles changent la façon d’ouvrir un port pour toute la machine et méritent leur propre procédure ; elles feront l’objet d’un article dédié.

Note de version : les noms de chaînes relevés ici (DOCKER-FORWARD, DOCKER-CT, DOCKER-INTERNAL, DOCKER-BRIDGE) correspondent aux notes de version officielles de Docker 29.4.3. Les articles décrivant uniquement DOCKER et DOCKER-USER se réfèrent à une structure antérieure. DOCKER-USER reste toutefois la première chaîne évaluée, donc le point d’accroche des correctifs reste valable.

Vérifier ce que le pare-feu applique réellement

ufw status affiche vos intentions telles qu’UFW les a enregistrées. Il n’affiche ni les règles posées par Docker, ni celles insérées par fail2ban, ni d’éventuelles règles nftables natives. Une machine peut afficher un ufw status irréprochable et exposer des ports. Quatre niveaux de vérification, du déclaratif au réel.

1. Ce qu’UFW croit appliquer.

sudo ufw status verbose

2. Ce qui écoute réellement sur la machine.

sudo ss -tulpen

Un port fermé au pare-feu mais avec un service en écoute reste une surface d’attaque dès que la règle saute.

3. Ce que le noyau applique vraiment. C’est le niveau que presque aucun tutoriel ne montre, et le seul qui fasse foi :

sudo nft list ruleset

Les chaînes ufw-user-input, DOCKER, f2b-sshd y apparaissent côte à côte, dans leur ordre d’évaluation réel. sudo ufw show raw donne la même information au format iptables.

4. Ce que voit l’extérieur. Un scan depuis la machine elle-même passe par la boucle locale et ne prouve rien. Le test doit venir d’une autre machine :

nmap -Pn -p 22,80,443,8080 adresse_ip

Pourquoi un port refusé reste parfois joignable

Trois causes, par ordre de fréquence. Docker, traité plus haut. Une règle plus permissive évaluée avant la vôtre — l’ordre est décisif, ufw status numbered le révèle. Et un cas méconnu : une connexion déjà établie n’est pas coupée par une nouvelle règle deny. Le suivi de connexions laisse passer les sessions en cours. Pour vérifier et forcer la coupure :

sudo ss -atp
sudo ss -K dst 203.0.113.10

ss -K demande le support CONFIG_INET_DIAG_DESTROY dans le noyau, présent sur les noyaux Debian et Ubuntu standards mais pas partout. Détail piégeux : en cas d’échec, la commande affiche RTNETLINK answers: Invalid argument tout en renvoyant un code de retour 0. Contrôlez le résultat avec un second ss -atp plutôt qu’avec le code de sortie.

Quand l’IP bloquée n’est pas celle que vous croyez

Bloquer une adresse reste sans effet si le trafic arrive via un reverse proxy, un répartiteur de charge ou un CDN : UFW ne voit alors que l’adresse de l’intermédiaire, jamais celle du client final. Le blocage doit se faire au niveau applicatif ou chez le fournisseur du CDN. Pour trancher, observez l’adresse source réellement reçue :

sudo tcpdump -n -i any port 443 -c 20

Le double pare-feu : UFW et le pare-feu du fournisseur

Sur un VPS, deux pare-feu se superposent presque toujours : UFW sur la machine, et le pare-feu réseau du fournisseur (groupes de sécurité, Network Firewall) en amont. Ils produisent deux échecs symétriques.

Une règle UFW allow correcte sans que rien n’arrive : le blocage est en amont, chez le fournisseur. Un tcpdump sur le port concerné le confirme — si aucun paquet n’arrive, le problème n’est pas sur la machine. À l’inverse, un pare-feu fournisseur bien configuré ne dispense pas d’UFW : il ne filtre pas le trafic entre vos propres machines du même réseau privé.

Écarts par distribution

UFW est propre à l’écosystème Debian/Ubuntu. Fedora, RHEL et openSUSE utilisent firewalld par défaut ; Arch Linux et Alpine n’imposent aucun outil de gestion de pare-feu.

Distribution	Outil	Paquet	Commande de base
Debian, Ubuntu	UFW	ufw	ufw status verbose
Fedora, RHEL	firewalld	firewalld	firewall-cmd --list-all
openSUSE	firewalld	firewalld	firewall-cmd --list-all
Arch Linux, Alpine	aucun par défaut	—	nft list ruleset

Différence de conception à retenir : UFW ajoute des règles séquentielles, firewalld organise les règles par zones attribuées à des interfaces. Les deux pilotent le même moteur netfilter.

Fedora, RHEL et openSUSE avec firewalld

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --permanent --zone=public --add-port=2222/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-all

--permanent écrit la règle de façon persistante, mais elle ne s’applique qu’après --reload. Sans --permanent, la règle disparaît au prochain redémarrage du service.

Arch Linux et Alpine Linux

Ces distributions ne fournissent pas d’outil de gestion par défaut. La configuration passe directement par nftables, ou par un outil installé volontairement. Vérifiez d’abord ce qui est actif avant d’ajouter une couche supplémentaire.

sudo nft list ruleset

Où sont stockées les règles, et dans quel ordre

UFW conserve ses règles dans des fichiers, ce qui explique qu’elles survivent au redémarrage sans outil de persistance supplémentaire. Trois fichiers comptent, évalués dans cet ordre :

Fichier	Contenu	Modifiable
/etc/ufw/before.rules	Règles évaluées avant les vôtres (boucle locale, ping, DHCP)	Oui, avec prudence
/etc/ufw/user.rules	Vos règles, créées par ufw allow/deny/limit	Non — utilisez les commandes
/etc/ufw/after.rules	Règles évaluées après les vôtres	Oui

Les fichiers before6.rules, user6.rules et after6.rules sont leurs équivalents IPv6. Cet ordre explique un symptôme déroutant : une règle allow sans effet parce qu’une règle ACCEPT ou DROP de before.rules a déjà tranché.

sudo grep -nE "ACCEPT|DROP" /etc/ufw/before.rules | head

Désinstaller / revenir en arrière

Avertissement. Désactiver UFW retire immédiatement toute protection par pare-feu sur la machine. Ne le faites que si vous savez pourquoi, et idéalement pas sur une machine directement exposée à Internet. ufw reset désactive également le pare-feu le temps de la remise à zéro : les deux commandes exposent la machine.

sudo ufw disable

Pour repartir d’une configuration vierge sans désinstaller le paquet :

sudo ufw reset

Cette commande demande toujours une confirmation, y compris hors session SSH — ajoutez --force si vous l’appelez depuis un script. Elle sauvegarde les fichiers de règles avant de les réinitialiser. Sortie réelle observée :

Backing up 'user.rules' to '/etc/ufw/user.rules.20260817_200439'

Pour retirer complètement le paquet :

sudo apt remove ufw

Erreurs courantes

ufw status affiche « inactive » alors que je l’ai activé

Quatre causes distinctes, à écarter dans cet ordre.

UFW n’a jamais été activé. À l’installation, il est désactivé. systemctl enable ufw ne suffit pas : il faut sudo ufw enable, qui bascule le fichier de configuration. Vérifiez :

sudo grep ENABLED /etc/ufw/ufw.conf

Sur une installation neuve, ce fichier contient bien ENABLED=no.

Un autre pare-feu occupe la place. iptables.service, iptables-persistent, netfilter-persistent ou firewalld écrasent les règles au démarrage. Deux gestionnaires ne peuvent pas coexister : désactivez celui dont vous ne voulez pas.

ufw-init échoue au démarrage. Voir le point suivant.

Le pare-feu a été activé via une interface graphique qui n’a pas écrit ENABLED=yes.

ERROR: problem running ufw-init

Ce message vient généralement d’un noyau incomplet : absence de support IPv6, ou modules netfilter manquants. C’est fréquent en conteneur LXC/LXD, sur certaines images VPS et sur du matériel ARM. Un indice fiable :

ls /proc/net/if_inet6

Si le fichier n’existe pas, la machine n’a pas d’IPv6 et UFW ne générera aucune règle IPv6 — comportement observé lors des tests de ce guide, où user6.rules est resté vide même pour une règle simple.

Trois remèdes, à essayer dans cet ordre. Passez IPV6=no dans /etc/default/ufw, puis désactivez et réactivez UFW. Si le blocage vient de la journalisation sur un noyau limité, lancez sudo ufw logging off avant ufw enable. Sur un conteneur non privilégié enfin, le pare-feu doit être géré sur l’hôte : le conteneur n’a pas la main sur netfilter.

Je me suis coupé l’accès SSH

La prévention est connue : autoriser SSH avant d’activer. La récupération l’est moins. Il n’existe aucune solution depuis le réseau — il faut un accès hors bande : console série ou KVM du fournisseur VPS, mode rescue, ou accès physique. Une fois connecté localement :

sudo ufw disable
sudo ufw allow 2222/tcp
sudo ufw enable

Le cas le plus fréquent reste un SSH déplacé sur un port non standard, avec un ufw allow OpenSSH qui n’ouvre que le port 22.

Une règle ajoutée n’a aucun effet

Vérifiez dans l’ordre : la position de la règle (ufw status numbered), une règle antérieure de before.rules, une connexion déjà établie non coupée, et si un conteneur Docker est en jeu.

Questions fréquentes

UFW remplace-t-il iptables ou nftables ?
Non. UFW est une interface simplifiée qui génère des règles iptables, elles-mêmes traduites vers nftables par la couche iptables-nft, active par défaut sur Debian et Ubuntu depuis Debian 10. UFW ne remplace ni l’un ni l’autre, il les pilote. C’est vérifiable avec sudo nft list ruleset, qui affiche les règles UFW précédées de l’avertissement table ip filter is managed by iptables-nft.

Pourquoi mes conteneurs Docker sont-ils joignables malgré UFW ?
Parce que Docker insère ses chaînes avant celles d’UFW dans la chaîne FORWARD, et que les règles ufw allow vivent dans la chaîne INPUT, que le trafic vers un conteneur ne traverse pas. La parade la plus simple est de publier les ports sur la boucle locale (-p 127.0.0.1:8080:80) plutôt que sur toutes les interfaces.

Comment savoir si mon pare-feu fonctionne vraiment ?
ufw status ne suffit pas : il affiche vos intentions, pas l’état du noyau. Utilisez sudo nft list ruleset pour voir les règles réellement chargées, sudo ss -tulpen pour les services en écoute, et un scan nmap depuis une autre machine pour le point de vue extérieur.

Les règles UFW survivent-elles au redémarrage ?
Oui, nativement. Elles sont stockées dans /etc/ufw/user.rules et rechargées par le service ufw. Si elles disparaissent, c’est qu’UFW n’a jamais été activé avec ufw enable, ou qu’un autre gestionnaire de pare-feu écrase les règles au démarrage.

Faut-il UFW et fail2ban en même temps ?
Oui, ils sont complémentaires. UFW filtre les ports et limite la fréquence des connexions avec ufw limit. Fail2ban analyse quant à lui les journaux et bannit sur des critères applicatifs plus précis. Les deux tournent ensemble sans conflit.

UFW fonctionne-t-il avec IPv6 ?
Oui, par défaut, via la directive IPV6=yes dans /etc/default/ufw. Chaque règle génère un pendant IPv6 dans user6.rules. Sur une machine sans support IPv6 dans le noyau, aucune règle v6 n’est produite, ce qui est normal et sans danger.

Quelle est la différence entre UFW et firewalld ?
UFW ajoute des règles simples de façon séquentielle, tandis que firewalld organise les règles par zones nommées attribuées à des interfaces réseau. UFW équipe Debian et Ubuntu, firewalld équipe Fedora, RHEL et openSUSE. Les commandes ne sont pas interchangeables, mais couvrent le même besoin.

Un port ouvert avec UFW est-il joignable depuis Internet ?
Pas nécessairement. Sur un VPS, le pare-feu réseau du fournisseur filtre en amont d’UFW. Derrière une box, une redirection de port est aussi nécessaire sur le routeur. Un tcpdump sur le port concerné tranche : si aucun paquet n’arrive, le blocage est en amont de la machine.

Conclusion

Un pare-feu UFW correctement configuré repose sur un ordre précis : définir la politique par défaut, autoriser SSH sur le bon port, activer, puis vérifier. La vérification est la partie que la plupart des procédures négligent, alors que c’est la seule qui prouve quelque chose : ufw status affiche des intentions, nft list ruleset affiche ce que le noyau applique, et un scan depuis l’extérieur affiche ce qu’Internet voit. Ces trois vues divergent dès que Docker, fail2ban ou un pare-feu de fournisseur entrent en jeu.

Retenez trois angles morts : les ports publiés par Docker échappent structurellement à ufw allow, une connexion déjà établie survit à une nouvelle règle de blocage, et le pare-feu du fournisseur peut bloquer un port qu’UFW autorise. Avant toute activation en production, gardez un accès console de secours : c’est la seule garantie contre un lockout.

Pour renforcer l’accès distant lui-même, consultez le guide de configuration SSH, qui couvre l’authentification par clé ; fail2ban, vu plus haut, complète utilement ce pare-feu. Si vous faites tourner des conteneurs, le guide pour installer Docker sur Linux précise le contexte dans lequel le contournement décrit ici se produit. Les modes des fichiers de règles suivent les principes du mémo sur la commande chmod.

Dernière vérification des commandes et des procédures : 17 août 2026, d’après la documentation officielle des projets cités et des tests réels menés sur Ubuntu 24.04 LTS (ufw 0.36.2-6, Docker 29.4.3).

Sources officielles

• Debian 10 « Buster » — notes de version officielles (passage à nftables par défaut)
• Ubuntu Security — nftables et compatibilité avec UFW
• ufw(8) — page de manuel officielle (Ubuntu 24.04 LTS)
• firewalld — documentation officielle
• Docker Engine 29 — notes de version officielles