Réparer un ruleset ufw qui bloque votre accès

Revenir en arrière

Si ufw vous a bloqué l’accès à votre VPS, le seul moyen de reprendre la main est d’utiliser la console du fournisseur ou le mode rescue, car aucune correction via SSH n’est possible une fois la règle bloquante active. Le kernel supprime votre paquet avant que sshd ne le voie. Il n’y a donc rien auquel se connecter ni rien à corriger sur le réseau. Ouvrez la console dans le panneau de contrôle de votre fournisseur, connectez-vous à l’invite, puis exécutez une commande.

sudo ufw disable

Vous devriez voir Firewall stopped and disabled on system startup. Les nouvelles connexions SSH refonctionnent en une ou deux secondes. Rien de ce que vous avez configuré n’est perdu : disable décharge les règles du kernel et écrit ENABLED=no dans /etc/ufw/ufw.conf, tandis que vos règles restent stockées sur disque dans /etc/ufw/user.rules, en attente du prochain ufw enable.

Ne redémarrez pas le serveur en espérant que le problème se résoudra. ufw se lance automatiquement au démarrage, donc ENABLED=yes recharge le même jeu de règles avant que le réseau soit disponible. Un redémarrage ne change rien à un blocage par ufw.

La console demande un mot de passe que vous n’avez peut-être pas

La console web (VNC ou série) correspond à un clavier connecté à la machine. Elle n’emprunte pas le réseau : aucune règle de pare-feu ne peut donc la bloquer. Elle nécessite toutefois une connexion locale. C’est là que les configurations avec authentification par clé uniquement échouent : si vous n’avez jamais défini de mot de passe pour votre utilisateur sudo et que la connexion de root est verrouillée, la console affiche une invite à laquelle vous ne pouvez pas répondre. Définissez ce mot de passe maintenant, tant que vous avez encore accès à SSH : sudo passwd yourname. La plupart des panels permettent également de réinitialiser le mot de passe de root, ce qui force généralement un redémarrage.

Si la console est inutilisable, démarrez le système de secours du fournisseur. Il exécute un système d’exploitation distinct, avec votre disque non monté. Vous pouvez ainsi désactiver ufw depuis l’extérieur.

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

Exécutez d’abord lsblk, car la partition root n’est pas toujours /dev/vda1. Redémarrez sur le système normal. ufw reste désactivé jusqu’à ce que vous le réactiviez manuellement.

La séquence minimale de récupération

Procédez dans cet ordre. Les quatre premières étapes sont sans risque. La suivante ne l’est pas.

1. sudo ufw disable pour décharger les règles et récupérer l’accès.
2. sudo ufw show added pour afficher les règles que vous avez ajoutées, sous la forme des commandes qui les ont ajoutées. Cette commande fonctionne lorsque ufw est inactif, contrairement à ufw status.
3. sudo sshd -T | grep -i '^port' pour confirmer le port sur lequel sshd est réellement en écoute. La commande affiche port 22, sauf si vous l’avez modifié.
4. sudo ufw allow 22/tcp, avec votre véritable port, afin que la prochaine activation ne provoque pas de nouveau le verrouillage.
5. sudo ufw enable, après avoir planifié un rollback. La procédure est détaillée plus bas dans cette page.

Ce que fait réellement ufw reset

ufw reset est une solution de dernier recours, pas la première mesure à prendre. La commande désactive le pare-feu, sauvegarde chaque fichier de règles et rétablit les valeurs par défaut pour refuser les connexions entrantes et autoriser les connexions sortantes. Elle affiche une ligne de sauvegarde par fichier :

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

Après une réinitialisation, aucune règle d’autorisation ne subsiste. Exécutez donc la commande depuis la console plutôt qu’en SSH, puis ajoutez la règle SSH avant de réactiver le pare-feu. Ces sauvegardes sont des fichiers texte simples. sudo grep -n dport /etc/ufw/user.rules.20260813_101500 affiche les anciennes règles. Vous pouvez ainsi reconstruire un ruleset que vous ne vouliez pas supprimer.

Règles conservées par ufw

Lire les fichiers est plus fiable que de se fier à sa mémoire. Cinq chemins contiennent l’ensemble de l’état :

• /etc/ufw/user.rules et /etc/ufw/user6.rules : les règles que vous avez ajoutées, dans l’ordre dans lequel elles sont évaluées.
• /etc/ufw/before.rules et /etc/ufw/after.rules, ainsi que les variantes 6 : l’infrastructure que ufw place autour de vos règles, notamment l’autorisation des connexions établies et les règles de loopback.
• /etc/default/ufw : les stratégies par défaut et le commutateur IPV6.
• /etc/ufw/ufw.conf : ENABLED et le niveau de journalisation.
• /var/log/ufw.log : ce qui a été bloqué, une fois la journalisation activée.

ufw enregistre une copie horodatée d’un fichier avant de le réécrire. ls /etc/ufw/ se remplit donc de noms tels que user.rules.20260813_101500. Il s’agit de votre historique d’annulation. Il est utile de le consulter avant de commencer à rétablir les anciennes règles.

Pour voir ce qui est chargé dans le noyau plutôt que ce qui se trouve sur le disque, utilisez sudo ufw show raw, ou sudo iptables -S et sudo ip6tables -S. Sur Ubuntu 22.04 et 24.04, ces commandes utilisent le backend nft. sudo nft list ruleset affiche donc les mêmes règles avec la nouvelle syntaxe.

Pourquoi l’activation d’ufw a-t-elle interrompu ma session SSH ?

La stratégie d’entrée par défaut est deny. Activer ufw sans règle autorisant votre port SSH bloque toute nouvelle connexion. ufw vous avertit bien : Command may disrupt existing ssh connections. Proceed with operation (y|n)? Répondre y sans règle autorisant SSH est la cause la plus fréquente des problèmes décrits sur cette page.

Le délai est trompeur. /etc/ufw/before.rules accepte les paquets dans l’état ESTABLISHED,RELATED avant d’appliquer vos propres règles. La session dans laquelle vous avez exécuté la commande continue donc normalement à fonctionner. Le blocage n’apparaît qu’à la connexion suivante, parfois plusieurs heures plus tard. Le changement de pare-feu ne semble alors plus lié au problème. Ouvrez toujours une deuxième session SSH et vérifiez qu’elle fonctionne avant de fermer la première.

Pourquoi apt et le DNS ont-ils cessé de fonctionner après une modification de la policy ?

sudo ufw default deny outgoing bloque les requêtes DNS (domain name system) sortantes et les connexions HTTP sortantes. La résolution de noms cesse donc de fonctionner et les mises à jour des paquets s’arrêtent. apt update signale Temporary failure resolving 'archive.ubuntu.com'. Les connexions SSH entrantes fonctionnent toujours, car leurs réponses sont à l’état ESTABLISHED et passent les règles du framework. Le firewall semble donc ne pas être en cause, alors qu’il est bien à l’origine du problème.

Si vous voulez une policy qui refuse les connexions sortantes, autorisez ce dont la machine a réellement besoin :

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

Sans la dernière règle, l’horloge dérive. Une horloge incorrecte fait échouer la validation des certificats TLS (transport layer security), et curl commence alors à échouer à cause des dates plutôt qu’à cause des ports. Ce symptôme apparaît plusieurs jours après la modification. C’est pourquoi une policy qui refuse les connexions sortantes convient aux machines que vous surveillez, et non à un serveur que vous configurez une seule fois.

Pourquoi ma règle ufw ne s’applique-t-elle jamais ?

ufw évalue les règles utilisateur dans l’ordre et s’arrête à la première correspondance. Un deny ajouté après un allow général ne s’applique jamais, car la règle allow a déjà déterminé le traitement du paquet. Affichez l’ordre avec les numéros, puis insérez la règle à la position voulue.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

sudo ufw --dry-run allow 8080/tcp affiche les règles qui seraient écrites sans rien modifier. C’est la méthode sûre pour vérifier une règle avant son activation.

Un autre piège concerne les profils d’application. sudo ufw allow OpenSSH utilise le profil défini dans /etc/ufw/applications.d/openssh-server, et ce profil correspond au port 22. Si sshd écoute sur 2222, la règle ouvre un port qui n’est utilisé par aucun service et vous risquez de perdre l’accès au serveur, alors que le ruleset semble correct. Utilisez le numéro de port après l’avoir modifié. Le reste de la syntaxe est expliqué dans les bases du pare-feu ufw pour un VPS.

Pourquoi les règles IPv4 n’expliquent-elles pas ce que j’observe ?

Parce que la moitié du trafic n’est pas IPv4. Ubuntu fournit IPV6=yes dans /etc/default/ufw, puis ufw conserve un jeu de règles IPv6 parallèle dans /etc/ufw/user6.rules. Une règle écrite avec une adresse IPv4, comme ufw allow from 203.0.113.10 to any port 22, ne crée aucune règle IPv6. Si votre VPS possède un enregistrement AAAA, votre client privilégie IPv6 et la connexion expire alors que ufw status affiche une règle qui semble correcte. Testez la différence avec ssh -4 user@host et ssh -6 user@host. Si la première commande fonctionne et pas la seconde, le problème vient du jeu de règles IPv6.

Le cas inverse est plus grave pour la sécurité. Avec IPV6=no, ufw ne gère pas du tout ip6tables. La stratégie IPv6 reste donc définie sur ACCEPT par défaut dans le noyau. Un port que vous pensez fermé répond sur son adresse IPv6, et aucune commande ufw ne le mentionnera. Vérifiez avec sudo ip6tables -S et ss -tlnp, puis consultez le fonctionnement de la gestion des ports IPv6 par ufw pour avoir une vue complète.

Pourquoi un port Docker est-il ouvert alors que ufw le bloque ?

Docker publie un port en écrivant des règles DNAT (destination network address translation) dans la table nat et en insérant sa propre chaîne dans FORWARD. Les règles de ufw se trouvent dans le chemin INPUT. Le trafic destiné à un conteneur est transféré, et non remis à l’hôte. Il n’atteint donc jamais la chaîne qui contient votre règle de refus. docker run -p 5432:5432 est accessible depuis Internet alors que ufw est actif et bloque tout.

sudo iptables -t nat -S DOCKER

La solution la plus simple consiste à publier le port sur loopback : -p 127.0.0.1:5432:5432 lie le côté hôte à 127.0.0.1, et aucune connexion externe ne peut alors l’atteindre, quelles que soient les règles de ufw. Publication des ports Docker avec ufw couvre les cas où le service doit être public.

Planifiez le rollback avant d’appliquer la règle

C’est l’habitude qui rend l’administration du firewall fiable. Avant toute modification risquée, planifiez l’annulation. Si la modification vous bloque l’accès, la machine revient automatiquement à son état précédent en cinq minutes et vous n’avez pas besoin d’ouvrir la console.

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

systemd affiche Running timer as unit: ufw-rollback.timer. Effectuez maintenant votre modification. Si vous pouvez encore ouvrir une nouvelle session SSH, annulez le rollback :

sudo systemctl stop ufw-rollback.timer

Si vous ne pouvez pas ouvrir cette session, attendez. ufw s’arrête automatiquement et votre tentative suivante aboutit. L’astuce classique shutdown -r +5 ne fonctionne pas avec ufw, car ufw recharge le même ruleset au démarrage.

Gardez une deuxième méthode d’accès

• Connectez-vous une fois à la console du fournisseur, avant d’en avoir besoin, et vérifiez que le mot de passe fonctionne. Une console que vous n’avez jamais testée n’est pas une solution de secours.
• Gardez un deuxième utilisateur sudo avec sa propre clé, afin qu’un fichier authorized_keys défectueux ne suffise pas à vous couper l’accès.
• Vérifiez si votre fournisseur applique un firewall réseau depuis son panneau de contrôle, indépendamment de ufw. Il bloque les mêmes ports, et ufw status n’en fera jamais mention.
• Ne faites pas de ufw allow from <your home address> votre seule règle SSH si cette adresse est dynamique. Votre fournisseur la change pendant la nuit et vous perdez l’accès.

Le meilleur moment pour faire tout cela est juste après la création du serveur, en même temps que les autres opérations de configuration, dans les dix premières minutes sur un nouveau VPS.

Un refus ou un délai d’attente indique la couche défaillante

Connection refused signifie qu’un paquet a atteint le serveur et qu’un composant a renvoyé un TCP reset. Le chemin réseau fonctionne donc correctement. sshd est arrêté ou écoute sur un autre port. Un pare-feu est rarement en cause, car ufw bloque par défaut les connexions au lieu de les refuser.

Connection timed out signifie qu’aucune réponse n’est revenue. C’est la signature d’un paquet bloqué : par ufw, par le pare-feu réseau du fournisseur ou à cause d’une adresse incorrecte. Interpréter correctement ces deux erreurs vous évite de perdre une heure en suppositions. La différence entre une connexion refusée et un délai d’attente permet de traiter les autres cas.

Activez la journalisation avant la prochaine modification

sudo ufw logging on
sudo tail -f /var/log/ufw.log

Un paquet bloqué apparaît comme ceci :

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

DPT=22 avec votre propre adresse dans SRC= prouve que c’est ufw qui vous bloque, et non le réseau ou sshd. Sur une image minimale sans rsyslog, il n’y a pas de /var/log/ufw.log, et les mêmes lignes proviennent de sudo journalctl -k | grep UFW. ufw applique une limitation de débit à ses propres règles de journalisation. L’absence d’une ligne ne prouve donc pas qu’un paquet a été autorisé.

Si vous trouvez des règles que vous n’avez jamais ajoutées

Un ruleset qui a changé tout seul n’est pas un problème de firewall. Quelqu’un disposant de l’accès root l’a modifié. Exécutez sudo grep ufw /var/log/auth.log pour voir quelles commandes sudo ont été exécutées et avec quel compte, puis last pour consulter les connexions autour de cet horodatage. Si les comptes ne correspondent à aucune personne que vous connaissez, arrêtez de déboguer le firewall et suivez la checklist d’un VPS compromis. Réactiver un firewall sur une machine contrôlée par quelqu’un d’autre ne fait que masquer le problème.

Remettez la configuration en place

Une fois la cause identifiée, réactivez ufw de manière à éviter une nouvelle perte d’accès. Autorisez votre véritable port SSH, planifiez l’annulation de la modification, activez ufw, puis ouvrez une toute nouvelle session SSH depuis un autre terminal et vérifiez qu’elle se connecte. Fermez la session actuelle uniquement après l’établissement de cette nouvelle session. Laissez la journalisation activée pendant une journée : les journaux indiquent bien plus rapidement ce que vous avez oublié d’autoriser que la lecture de user.rules.

FAQ

ufw disable supprime-t-il mes règles ?

Non. disable décharge le ruleset du kernel et écrit ENABLED=no dans /etc/ufw/ufw.conf. Vos règles restent dans /etc/ufw/user.rules et /etc/ufw/user6.rules, et sudo ufw show added les affiche lorsque le firewall est inactif. ufw reset est la commande qui les efface, après avoir d’abord sauvegardé chaque fichier. Elle affiche une ligne comme Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

Le redémarrage de mon VPS annule-t-il un blocage ufw ?

Non. ufw démarre au boot depuis ENABLED=yes dans /etc/ufw/ufw.conf. Les mêmes règles sont donc chargées avant que le réseau soit disponible, et vous êtes de nouveau bloqué. Un redémarrage n’aide qu’après avoir désactivé ufw ou modifié ce fichier depuis le rescue mode, avec le disque monté. Utilisez la console du fournisseur et exécutez sudo ufw disable depuis cette console.

Pourquoi mon conteneur Docker est-il accessible alors que ufw refuse le port ?

Docker écrit ses propres règles DNAT et FORWARD pour chaque port publié. Ce trafic est redirigé vers le conteneur au lieu d’être remis à l’hôte. Il ne passe donc jamais par la chaîne INPUT où se trouve votre règle de refus ufw. Publiez le port sur loopback avec -p 127.0.0.1:5432:5432 lorsqu’il est uniquement destiné à l’hôte, et vérifiez les règles installées par Docker avec sudo iptables -t nat -S DOCKER.

Je n’ai pas de mot de passe pour la console ni de rescue mode. Quelles sont mes options ?

Les options restantes dépendent de votre fournisseur : réinitialiser le mot de passe depuis le control panel, ce qui redémarre généralement le serveur, ou attacher le disque à une autre instance afin de modifier /etc/ufw/ufw.conf depuis celle-ci. Contactez le support avant de reconstruire le serveur, car cette opération détruit les données qu’il contient. Une fois l’accès rétabli, exécutez sudo passwd yourname et testez une fois la connexion à la console. Ainsi, le prochain blocage ne vous coûtera que deux minutes.