En 2026, parler firewall sur Linux, ça a un petit côté « on en est encore là ? ». Et pourtant oui. Parce que même si les cloud providers filtrent déjà plein de choses, même si les apps se mettent des proxy et des tunnels partout, au bout du compte… ton serveur (ou ton laptop) a toujours une pile réseau. Et elle mérite un filtre propre.
Le truc, c’est qu’on mélange souvent tout : UFW, nftables, iptables, firewalld… Et on finit par choisir « ce qu’on a déjà vu sur un tuto ». Sauf qu’en 2026, la vraie question est plutôt : est ce que tu veux une interface simple pour faire le job ou est ce que tu veux un pare feu natif, programmable, optimisable, qui colle aux besoins modernes ?
Ici on va comparer UFW et nftables. Pas en mode guerre de chapelles. Juste : dans quel cas tu prends quoi, pourquoi, et comment éviter les pièges classiques.
Le point de départ : ce que sont vraiment UFW et nftables
UFW, c’est « Uncomplicated Firewall ». Un outil en ligne de commande, surtout populaire sur Ubuntu et Debian, qui sert à gérer des règles de filtrage sans toucher directement à iptables. En pratique, tu écris des règles haut niveau du genre : autoriser SSH, refuser tout le reste, ouvrir tel port. Et UFW s’occupe du reste.
nftables, c’est autre chose. C’est le framework pare feu moderne du noyau Linux, prévu pour remplacer iptables. Tu écris des règles dans une syntaxe dédiée, tu manipules des tables, des chaînes, des sets, des maps. Et surtout tu profites de ce que le noyau sait faire aujourd’hui : performances, logique plus propre, atomique, et plus de cohérence.
Donc déjà, premier point important : UFW n’est pas « un pare feu » au sens noyau. C’est une surcouche. nftables, lui, c’est le moteur.
Ce qui a changé en 2026 (et pourquoi ça compte)
Il y a quelques années, on pouvait dire : « UFW est simple, nftables est puissant ». C’est encore vrai. Mais en 2026, plusieurs tendances rendent nftables encore plus pertinent qu’avant :
- Plus de micro services et de trafic est ouest (même sur un simple VPS via containers).
- Plus de dual stack IPv4 et IPv6, et plus d’oublis côté IPv6… qui font mal.
- Plus d’automatisation, IaC, CI/CD, déploiements qui reconfigurent le réseau.
- Plus d’usages nomades, PC portables qui changent de réseau, VPN, split tunneling.
Du coup, la question n’est pas juste « ouvrir le port 22 ». C’est souvent : gérer des ensembles d’IP, faire du rate limiting, logguer proprement, et garder une config versionnable.
Comparatif rapide : UFW vs nftables
| Critère | UFW | nftables |
| Facilité de prise en main | Très facile | Moyen à avancé |
| Granularité | Limitée (mais suffisante pour beaucoup) | Très élevée |
| Performance | Correcte | Excellente, surtout avec sets |
| IPv6 | Oui, mais parfois mal compris | Oui, natif et propre |
| Gestion de règles complexes | Peu ergonomique | Parfait pour ça |
| Maintenabilité en prod | OK si simple | Très bonne si bien structuré |
| Standardisation Linux moderne | En déclin relatif | En montée, noyau first |
| Compat containers, orchestration | OK | Très bon, plus flexible |
Quand UFW est le bon choix (oui, ça arrive souvent)
UFW est parfait quand tu veux :
- Un firewall simple pour un VPS basique
Exemple : un serveur web avec SSH + HTTP/HTTPS. Tu veux un truc lisible et vite fait. - Une surface de risque faible
Pas de règles exotiques, pas de NAT tordu, pas de ports dynamiques. - Un workflow “je veux pas y passer la journée”
Et franchement, je comprends.
Exemple de config UFW typique (serveur web)
bash sudo ufw default deny incoming sudo ufw default allow outgoing
sudo ufw allow OpenSSH sudo ufw allow 80/tcp sudo ufw allow 443/tcp
sudo ufw enable sudo ufw status verbose
Tu as un résultat correct, immédiatement. Et si ton but c’est juste de ne pas exposer Redis ou PostgreSQL au monde entier, UFW suffit largement.
Le vrai avantage de UFW
C’est sa lisibilité et le fait que beaucoup de guides Ubuntu partent de là. Si tu gères des machines pour des clients, ou des stacks simples, ça a de la valeur. Tu réduis les erreurs humaines.
Mais attention à deux pièges UFW
- L’IPv6
Beaucoup activent UFW et croient être protégés, mais oublient qu’IPv6 peut rester ouvert selon la config. Il faut vérifier/etc/default/ufwet s’assurer que l’IPv6 est géré comme tu veux. - La complexité qui s’accumule
Au début c’est propre. Puis tu ajoutes 12 exceptions, 4 sous réseaux, du rate limit, une règle “temporaire” jamais enlevée… et tu perds l’avantage « uncomplicated ».
Quand nftables est clairement le bon choix
nftables devient le meilleur choix si tu coches un de ces points :
- Tu utilises des containers (Docker, Podman, LXC) et tu veux maîtriser le filtrage fin
Pas juste « ça marche », mais comprendre et contrôler. - Tu veux des règles performantes avec des listes d’IP
Genre allowlist de pays, IP partenaires, IP d’admin, anti bruteforce. Avec nftables, les sets changent la vie. - Tu veux versionner ta config firewall
Avec un fichier/etc/nftables.confclair, commitable dans Git, déployable par Ansible. - Tu as besoin de logique avancée
Rate limiting, marquage, filtrage par interface, par plage, par protocole, logging structuré.
Exemple nftables minimal (serveur web)
Un exemple simple, mais déjà propre. À adapter évidemment.
nft
flush ruleset
table inet filter { chain input { type filter hook input priority 0; policy drop;
# loopback
iif "lo" accept
# connexions établies
ct state established,related accept
# ping (optionnel)
ip protocol icmp accept
ip6 nexthdr icmpv6 accept
# SSH
tcp dport 22 accept
# HTTP/HTTPS
tcp dport { 80, 443 } accept
# tout le reste drop (policy)
}
chain forward { type filter hook forward priority 0; policy drop; }
chain output { type filter hook output priority 0; policy accept; } }
Activation :
bash sudo systemctl enable --now nftables sudo nft -f /etc/nftables.conf sudo nft list ruleset
Ce que tu gagnes là, même sur une config simple, c’est une base nette. Et surtout, tu es déjà dans le langage natif du noyau.
Le match sur un point clé : lisibilité vs évolutivité
C’est là que ça se joue.
- UFW est lisible tant que tu restes dans le modèle « ports et services ».
- nftables est lisible quand tu prends le temps d’écrire une vraie structure, avec des commentaires, des sets, et des blocs.
Mais si tu sais déjà que ton infra va bouger, nftables te fait gagner du temps à moyen terme. Le coût d’entrée est plus haut, oui. Mais tu évites le moment où tu dois « migrer en urgence » parce que UFW ne suit plus.
Et en pratique, je choisis quoi en 2026 ?
Choix recommandé pour la plupart des débutants (et beaucoup de pros pressés)
UFW, si ton besoin est simple et que tu veux une mise en place rapide sur Ubuntu/Debian.
Typiquement : VPS, serveur perso, petit site vitrine, reverse proxy, machine de dev.
Choix recommandé pour une approche sysadmin propre et durable
nftables, si tu veux un pare feu maîtrisé, versionnable, extensible, et cohérent avec l’évolution Linux.
Typiquement : serveurs exposés, multi interfaces, IPv6 sérieux, containers, règles avancées, audit.
Ma règle mentale
Si tu lis cette phrase et que tu te reconnais : « je veux juste fermer ce qui traine », prends UFW.
Si tu te dis : « je veux savoir exactement ce qui passe, pourquoi, et je veux pouvoir le prouver », prends nftables.
Deux scénarios concrets pour trancher vite
Scénario 1 : laptop nomade + VPN + Wi-Fi publics
Ici, UFW peut suffire, mais nftables peut être plus agréable si tu veux faire des profils : maison, coworking, hotspot. Avec nftables, tu peux filtrer par interface (wlan0, tun0, wg0), mettre des règles conditionnelles, et éviter les surprises.
Scénario 2 : VPS avec Docker + services internes
Tu peux faire UFW, mais tu vas souvent tomber sur des cas où Docker modifie iptables ou interagit avec le firewall de manière non intuitive. En 2026, le conseil que je donne le plus souvent est : si tu fais du container sérieux, apprends nftables. Tu vas arrêter de « debug à l’aveugle ».
Une note importante : iptables n’est pas “mort”, mais…
En 2026, iptables est encore là, parfois via compatibilité, parfois via outils qui l’utilisent. Mais nftables est la direction naturelle. Donc apprendre nftables maintenant, c’est un investissement raisonnable. Surtout si tu écris des contenus, des scripts, des playbooks, ou des guides pour d’autres.
D’ailleurs, sur Le Blog Tech Pro de Samyn-Antoy ABASSE ( https://monblog-sa-abasse.blogspot.com/ ), je partage souvent ce genre de choix « pragmatiques » côté Linux et sysadmin, pas juste des commandes copiées collées. Si tu veux, garde le site en favori, ça sert quand tu retombes sur ces sujets deux mois plus tard. Ça arrive à tout le monde.
Petit guide de décision (ultra simple)
Choisis UFW si :
- tu veux une config rapide
- tu as 3 à 6 règles
- tu veux un truc facile à relire
- tu es sur Ubuntu et tu suis une doc standard
Choisis nftables si :
- tu veux gérer des sets d’IP
- tu as des règles avancées (rate limit, interface, logs)
- tu veux versionner et déployer proprement
- tu as des containers, ou une infra qui grandit
Conclusion : en 2026, le “meilleur” dépend de ton futur proche
UFW reste très bon. Je le dis clairement. Pour beaucoup de serveurs simples, c’est même le meilleur choix, parce qu’un firewall que tu comprends vaut mieux qu’un firewall parfait que tu n’oses pas toucher.
Mais nftables, lui, gagne sur la trajectoire. Si tu te vois évoluer côté sysadmin, sécurité, infra, ou juste si tu veux arrêter de bricoler, c’est celui à choisir.
Et si tu hésites encore, fais ce compromis très réaliste : commence avec UFW sur ta machine perso, puis prends un petit VPS de test et reproduis la même politique en nftables. Une soirée. Tu vas comprendre vite où tu veux aller.
Questions fréquemment posées
Qu'est-ce que UFW et en quoi diffère-t-il de nftables ?
UFW (Uncomplicated Firewall) est une surcouche en ligne de commande populaire sur Ubuntu et Debian qui facilite la gestion des règles de filtrage réseau sans manipuler directement iptables. En revanche, nftables est le framework pare-feu moderne intégré au noyau Linux, conçu pour remplacer iptables, offrant une syntaxe dédiée, une meilleure performance et une granularité élevée dans la gestion des règles.
Pourquoi parler de firewall Linux en 2026 est toujours pertinent ?
Malgré les filtrages effectués par les fournisseurs cloud et l'utilisation généralisée de proxies et tunnels, chaque serveur ou ordinateur portable Linux possède toujours une pile réseau qui nécessite un filtre propre. Ainsi, gérer un firewall local reste essentiel pour assurer la sécurité et le contrôle fin du trafic réseau.
Dans quels cas privilégier l'utilisation de UFW ?
UFW est idéal lorsque vous souhaitez un firewall simple pour un VPS basique, avec une surface de risque faible, sans règles complexes ni NAT avancé. Par exemple, pour un serveur web avec SSH et HTTP/HTTPS, UFW offre une configuration rapide, lisible et suffisante pour éviter d'exposer des services sensibles comme Redis ou PostgreSQL.
Quels sont les avantages majeurs de nftables en 2026 ?
En 2026, nftables bénéficie d'une pertinence accrue grâce à sa capacité à gérer des environnements complexes : microservices, trafic est-ouest via containers, dual stack IPv4/IPv6 natif, automatisation via IaC/CI/CD, mobilité accrue avec VPNs et split tunneling. Il offre aussi une excellente performance, une gestion avancée des règles complexes et une meilleure maintenabilité en production.
Comment choisir entre UFW et nftables selon ses besoins ?
Le choix dépend principalement du niveau de complexité désiré. Si vous cherchez simplicité et rapidité pour des règles basiques, UFW suffit amplement. Si vous avez besoin d'une granularité fine, d'automatisation poussée, d'un support natif IPv6 propre ou d'intégration dans des environnements containerisés modernes, nftables est le choix recommandé.
Quels sont les pièges classiques à éviter lors de la configuration d'un firewall Linux ?
Il faut éviter de confondre les outils (UFW n'est pas un firewall noyau mais une surcouche), ne pas oublier la gestion correcte d'IPv6 qui peut créer des failles si négligée, ne pas se limiter à ouvrir simplement le port 22 sans penser aux ensembles d'IP ou au rate limiting. Enfin, il est important de choisir un outil dont la configuration peut être versionnée et automatisée pour éviter les erreurs humaines.
0 Commentaires