nftables : netfilter tables
Sécurité
Cadre de filtrage de paquets du noyau Linux, successeur d'iptables. Il sert à écrire les règles de pare-feu, de traduction d'adresses et de classification du trafic avec une seule syntaxe et un seul outil, nft.
Successeur d'iptables : Il est intégré au noyau depuis la version 3.13 (2014). Il remplace iptables, ip6tables, arptables et ebtables par un seul cadre, et la famille inet traite IPv4 et IPv6 dans la même table.
Machine virtuelle noyau : L'outil nft compile les règles en bytecode, et une petite machine virtuelle du noyau exécute ce bytecode. Ajouter un nouveau critère de correspondance ne demande donc plus d'écrire un module noyau dédié.
Sets, maps et atomicité : Les sets et les maps testent des milliers d'adresses ou de ports en une seule règle, au lieu de milliers de règles lues à la file. Un `nft -f` charge tout le jeu de règles en une transaction atomique : le pare-feu n'est jamais à moitié chargé.
Migration : Debian, RHEL et firewalld utilisent nftables par défaut. La couche iptables-nft et l'outil iptables-translate reprennent l'existant. Vingt ans de pare-feu apprennent que le script iptables de quatre cents lignes « qui marche » survit à toutes les migrations, recopié tel quel, commentaires périmés compris.
Ce qui arrive si on s'en passe
Sans jeu de règles nftables chargé (et sans autre filtre actif), les points d'accroche netfilter du noyau laissent passer tous les paquets, car la politique implicite est d'accepter. Tout service qui écoute sur toutes les interfaces devient joignable depuis n'importe quel réseau, même s'il est prévu pour un usage local : par exemple une base de données ou une interface d'administration liée à 0.0.0.0. Si le transfert IP est activé, la machine route librement les paquets entre ses réseaux et rien ne sépare les segments. Aucune limite de débit ne freine les tentatives d'authentification répétées ni les balayages de ports. Aucune règle de journalisation ne garde la trace des connexions refusées ou suspectes, ce qui prive la détection et l'analyse après coup de cette source. Enfin, la traduction d'adresses disparaît : les postes situés derrière une passerelle en masquerade perdent leur accès sortant et les redirections de ports cessent de fonctionner.
Explication de la marmotte
Imagine le videur à l'entrée d'une boîte de nuit. Chaque personne qui arrive, il la regarde : d'où elle vient, où elle veut aller, si son nom est sur la liste. Ensuite il décide : elle entre, elle repart, ou on l'envoie vers une autre porte. Sur un ordinateur, des messages arrivent sans arrêt depuis Internet, par petits morceaux. Cet outil, c'est le videur : on lui écrit une liste de consignes, et il trie chaque morceau selon ces consignes. Sa version moderne a une liste mieux rangée, et quand on change les consignes, il les remplace toutes d'un seul coup. Comme ça, il n'y a jamais un moment où la porte reste sans surveillance.
Où ce terme est utilisé
- EBPF pour observabilité et enforcement Linux (3 occurrences)
- Filtrage, segmentation, NAC et Zero Trust (3 occurrences)
- Durcir un serveur Linux avant la mise en production, checklist (2 occurrences)
- Concevoir une défense en profondeur par couches (1 occurrence)
- Docker ou Podman en auto-hébergement : root, rootless, isolation (1 occurrence)
- IPv6, autoconfiguration et coexistence (1 occurrence)
- NAT, translations et publication de services (1 occurrence)
- Sécuriser les imprimantes réseau en entreprise (1 occurrence)