Pare-feu · nftables contre UFW

« UFW n'est pas installé » ne veut pas dire que tu n'as pas de pare-feu (le piège Debian 13)

2026-08-03 · HardStacked · 6 min de lecture

Tu as lancé un audit de sécurité sur un serveur Debian 13 et le rapport affiche « no firewall detected », ou la variante à peine plus honnête, « UFW is not installed ». Et là tu te demandes si ta machine traîne sur internet sans protection depuis le début.

Réponse courte : probablement pas, et cette alerte t'en dit plus sur l'outil d'audit que sur ton serveur.

1. Ce que Debian livre réellement

Debian 13 (trixie) n'installe pas UFW par défaut. Ça n'a jamais été le cas. UFW est une surcouche de confort venue d'Ubuntu, et beaucoup de tutoriels écrits pour Ubuntu se font recopier dans des « guides de hardening Debian » sans que personne vérifie ce que Debian met vraiment sur le disque.

Ce que Debian livre, c'est nftables. Sur une installation trixie fraîche, le paquet nftables est présent et le binaire nft est là. On l'a vérifié nous-mêmes sur une VM Debian 13 propre, entièrement à jour, zéro modification, pendant la construction de notre propre outil d'audit : nftables présent d'origine, UFW absent. C'est l'état normal et attendu d'un serveur Debian.

Donc quand un audit cherche le binaire ufw, ne trouve rien et imprime « pas de pare-feu », il a testé la présence d'un paquet spécifique à la culture Ubuntu et il en a conclu quelque chose sur toute ta capacité de filtrage. Ce n'est pas la même question.

2. Vérifie toi-même, en deux minutes

Ne crois pas l'audit sur parole, et ne me crois pas non plus. Demande au noyau.

Cette commande affiche toutes les règles nftables chargées. Pas ce qui est configuré dans un fichier quelque part : ce qui est actif, maintenant. Trois issues possibles :

Ensuite, la persistance :

Des règles chargées à la main avec des commandes nft meurent au redémarrage. Des règles dans /etc/nftables.conf avec le service nftables activé reviennent. Un pare-feu qui s'évapore au reboot est un pare-feu que tu n'as pas.

3. Pourquoi tant d'outils d'audit se trompent

La cause racine mérite qu'on s'y arrête, parce qu'elle dépasse largement les pare-feu : la plupart des vérifications d'audit testent la présence d'un paquet au lieu de la présence d'une capacité.

Tester « le binaire ufw est-il sur le disque » est simple et portable. Tester « du trafic est-il réellement filtré, par quoi que ce soit, en ce moment » demande de comprendre que Linux a un seul filtre de paquets (netfilter/nftables dans le noyau) et une demi-douzaine de frontaux qui le pilotent : ufw, firewalld, iptables-nft, nft brut, plus des démons comme Docker et fail2ban qui injectent leurs propres règles. Une vérification écrite sur Ubuntu, où ufw est le frontal officiel, est livrée telle quelle et produit une fausse alarme permanente sur chaque machine Debian qu'elle touche.

Tu retrouveras le même schéma partout dans l'outillage de sécurité. « Antivirus non installé » sur une machine où la vraie question est de savoir si quelque chose analyse quoi que ce soit. « Fail2ban absent » sur un hôte où sshd n'accepte que des clés et où le port est de toute façon filtré en amont. La présence d'un paquet est une métrique de substitution, et les métriques de substitution mentent dès qu'on change de distribution.

Quand on a rencontré ce piège dans notre propre outil, le correctif n'a pas été d'étouffer le message. Ça a été de rendre la règle consciente de la distribution : sur Debian, l'absence d'ufw est énoncée comme un fait neutre, et le vrai jugement porte sur nftables, avec trois verdicts distincts. nftables absent n'est pas le même constat que nftables présent avec zéro règle, et aucun des deux n'équivaut à des règles chargées. Et quand l'outil ne peut pas vérifier quelque chose, il écrit « non vérifié » au lieu de « rien détecté ». Ces deux-là sont confondus en permanence, et la différence compte : « rien détecté » est une affirmation sur ton serveur, « non vérifié » est un aveu de l'outil.

4. Le piège : installer UFW pour faire taire l'alerte

C'est ici qu'un faux positif devient un vrai incident. L'audit dit « installe ufw », tu fais apt install ufw && ufw enable, l'alerte disparaît, ticket fermé.

Sur une machine qui avait déjà des règles nftables, tu as maintenant deux jeux de règles dans le même noyau. nftables évalue toutes les chaînes de base accrochées à un point donné, dans l'ordre de leurs priorités. Un verdict accept dans une chaîne n'exempte pas le paquet des autres chaînes, et un drop n'importe où est définitif. Tes règles existantes et celles d'ufw sont donc toutes les deux actives, et la politique effective est l'intersection de deux configurations écrites chacune en supposant être seule.

Deux modes d'échec, au choix. Soit le deny entrant par défaut d'ufw avale du trafic que tes règles existantes autorisaient volontairement, et si ce trafic est du SSH sur un port non standard, tu viens de t'enfermer dehors d'un serveur distant pour corriger un constat qui n'a jamais existé. Soit tes règles permissives et celles d'ufw s'entremêlent en quelque chose qu'aucune des deux configs ne décrit, et tu repars convaincu que « ufw enable » signifie ce que la doc d'ufw raconte, alors que la politique réelle n'a jamais été lue par personne. Un pare-feu que tu comprends mal est sans doute pire que le jeu de règles vide du départ, parce que maintenant tu as arrêté de regarder.

Si le jeu de règles était vraiment vide et que tu préfères l'ergonomie d'ufw, très bien, installe-le sur la machine vide, il pilote nftables en dessous de toute façon. Mais prends cette décision à partir de la sortie de nft list ruleset, pas d'une ligne d'audit écrite pour une autre distribution.

5. Ce qu'il faut vérifier à la place

Oublie « le paquet X est-il installé ». Trois questions, dans l'ordre :

Des règles sont-elles chargées ? sudo nft list ruleset. Lis la sortie. Si c'est trop pour aujourd'hui, identifie au minimum la politique de la chaîne d'entrée : policy drop avec des accepts explicites, c'est un pare-feu ; policy accept sans rien d'autre, c'est de la décoration.

Survivent-elles au redémarrage ? Service activé, règles dans le fichier de config, et idéalement tu as redémarré une fois pour regarder à nouveau. Une supposition n'est pas une vérification.

Que laissent-elles passer, et vers quoi ? ss -tlnp montre ce qui écoute réellement. Croise-le avec tes règles. Un pare-feu parfait devant un service qui ne devrait pas tourner résout le mauvais problème. Et si tu es sur un VPS cloud, rappelle-toi que les security groups du fournisseur filtrent avant même que tes paquets atteignent nftables : ton pare-feu hôte est la deuxième couche, pas la seule.