Configurer un pare-feu avec nftables

nftables est le pare-feu du noyau Linux moderne : c'est lui qui filtre réellement les paquets, sous UFW comme sous Firewalld. L'outil nft remplace iptables avec une syntaxe unifiée, des sets natifs et de meilleures performances. Ce guide s'adresse à ceux qui veulent écrire leurs règles directement en nftables, sans frontend : serveurs minimalistes, conteneurs, appliances, ou rulesets versionnés en IaC. Vous partirez d'un ruleset serveur complet, puis verrez les sets, le NAT et la persistance.

Si vous cherchez d'abord une prise en main simple, un frontend comme UFW ou Firewalld reste plus rapide. nftables direct s'adresse à qui veut le contrôle total.

Ce que vous allez apprendre

• La différence entre nftables et iptables et quand écrire du nft direct.
• Les briques : tables, chaînes, hooks et politique par défaut.
• Un ruleset serveur complet avec filtrage stateful.
• Les sets pour gérer des listes d'adresses proprement.
• Le NAT, le masquerade et le port forwarding.
• Rendre le ruleset persistant au redémarrage.

Prérequis

• Un serveur Linux récent (RHEL 8+, Debian 10+, Ubuntu 20.04+) et un accès root.
• Les concepts de filtrage : politique par défaut, flux entrants/sortants, connexions à état. En cas de doute, voir Introduction aux pare-feux.
• Un accès console de secours avant d'appliquer une politique drop sur un serveur distant.

nftables ou iptables ?

iptables et nftables pilotent tous les deux Netfilter, le sous-système de filtrage du noyau. nftables est le successeur officiel : sur les distributions récentes, iptables n'est souvent qu'un wrapper (iptables-nft) qui traduit vers nftables en interne.

Critère	iptables	nftables
Statut	Legacy, maintenu par compatibilité	Standard depuis Linux 3.13 (2014)
Syntaxe	Une commande par table (iptables, ip6tables...)	Une commande nft, IPv4 et IPv6 unifiés
Listes d'IP	Nécessite ipset en plus	Sets natifs
Performance	Règles évaluées linéairement	Sets et maps en temps constant
Comptage	Compteurs par défaut	Compteurs à la demande (plus rapide)

Glissez pour voir

En clair : sur un système moderne, écrivez du nftables. iptables ne sert plus qu'à lire d'anciennes configurations ou à faire tourner des scripts legacy.

Quand écrire du nftables directement

La règle générale reste d'utiliser le frontend par défaut de votre distribution (UFW sur Debian/Ubuntu, Firewalld sur RHEL). Mais nft direct est justifié dans plusieurs cas :

• Serveur minimaliste ou conteneur où l'on ne veut aucun démon supplémentaire.
• Ruleset versionné en Git et déployé par Ansible ou un script (infrastructure as code).
• Règles avancées que les frontends exposent mal : maps, priorités de hooks, filtrage par intervalle.
• Appliance ou passerelle où vous maîtrisez tout le trafic.

Ne mélangez pas nft direct et un frontend

UFW et Firewalld écrivent leurs propres tables et chaînes dans Netfilter. Si vous ajoutez des règles nft à la main en plus d'un frontend actif, les deux se contredisent silencieusement. Choisissez : soit un frontend, soit nftables direct, pas les deux sur la même machine.

Installer nftables

nftables est présent sur tous les noyaux récents ; seul l'outil nft et le service peuvent manquer.

Debian/Ubuntu

sudo apt update && sudo apt install -y nftables
sudo systemctl enable --now nftables
nft --version
# nftables v1.0.6 (Lester Gooch #5)

RHEL/Fedora

sudo dnf install -y nftables
sudo systemctl enable --now nftables
nft --version

Tables, chaînes et hooks

Trois notions structurent nftables. Une table est un conteneur de règles pour une famille de protocoles (inet couvre IPv4 et IPv6 d'un coup). Une chaîne regroupe des règles ; une chaîne dite de base s'accroche à un hook du noyau, un point de passage du paquet.

Les hooks principaux pour le filtrage et le NAT :

Hook	Moment	Usage typique
input	Paquet destiné à la machine	Filtrer les flux entrants
output	Paquet émis par la machine	Filtrer les flux sortants
forward	Paquet routé à travers la machine	Passerelle, routeur
prerouting	Avant décision de routage	DNAT, port forwarding
postrouting	Après routage, avant émission	SNAT, masquerade

Glissez pour voir

Chaque chaîne de base porte une politique par défaut (policy drop ou policy accept) appliquée quand aucune règle n'a matché.

Un premier ruleset serveur

Voici un ruleset serveur complet en famille inet (IPv4 + IPv6). Il pose une politique drop par défaut, n'autorise que l'essentiel, et journalise le reste. Ce ruleset a été appliqué et vérifié sur nftables 1.0.6.

/etc/nftables.conf

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;

    iif "lo" accept
    ct state established,related accept
    ct state invalid drop
    ip protocol icmp accept
    tcp dport { 80, 443 } accept
    tcp dport 22 accept
    limit rate 5/minute log prefix "nft-drop: "
    drop
  }
  chain forward { type filter hook forward priority filter; policy drop; }
  chain output { type filter hook output priority filter; policy accept; }
}

Chaque ligne compte :

• ct state established,related accept autorise les réponses aux connexions déjà ouvertes : c'est le cœur du filtrage stateful. Sans elle, votre serveur ne recevrait aucune réponse.
• ct state invalid drop jette les paquets incohérents, souvent des scans.
• tcp dport { 80, 443 } utilise une liste anonyme : plus lisible qu'une règle par port.
• limit rate 5/minute log journalise les paquets bloqués sans inonder les logs.

Validez toujours avant d'appliquer, avec l'option -c (check) qui ne charge rien :

sudo nft -c -f /etc/nftables.conf   # validation seule
sudo nft -f /etc/nftables.conf      # application
sudo nft list ruleset               # vérification

Ne vous coupez pas l'accès SSH

La règle tcp dport 22 accept doit être présente avant d'appliquer une politique drop sur un serveur distant. Testez d'abord dans une session de secours, et gardez un accès console : une politique drop sans règle SSH vous verrouille dehors.

Sets : gérer des listes d'adresses

Un set est une liste nommée, évaluée en temps constant. C'est l'équivalent natif d'ipset, idéal pour une allowlist d'administration.

table inet filter {
  set ssh_autorises {
    type ipv4_addr
    elements = { 192.168.1.10, 10.0.0.5 }
  }
  chain input {
    type filter hook input priority filter; policy drop;
    # ... règles précédentes ...
    tcp dport 22 ip saddr @ssh_autorises accept
  }
}

La règle ip saddr @ssh_autorises n'accepte le SSH que depuis les adresses du set. Ajouter une IP ne demande pas de recharger tout le ruleset :

sudo nft add element inet filter ssh_autorises { 203.0.113.7 }

Les maps vont plus loin en associant une clé à une valeur (par exemple un port à une décision), utiles pour du routage de règles compact.

NAT et masquerade

Pour qu'une passerelle partage sa connexion, ajoutez une table nat avec une chaîne postrouting. Le masquerade réécrit l'adresse source des paquets sortants avec l'IP de l'interface, la forme de SNAT adaptée aux IP dynamiques.

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "eth0" masquerade
  }
}

N'oubliez pas d'activer le routage du noyau, sinon les paquets ne traversent pas la machine :

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-forward.conf
sudo sysctl --system

Port forwarding avec DNAT

Pour rediriger un port public vers un service interne, utilisez une chaîne prerouting avec dnat. Testé sur nftables 1.0.6 :

table ip nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    tcp dport 8080 dnat to 192.168.1.20:80
  }
}

Ici, tout le trafic arrivant sur le port 8080 est réécrit vers 192.168.1.20:80. Combinez prerouting (DNAT) et postrouting (masquerade) pour une passerelle complète.

Rendre le ruleset persistant

Un ruleset chargé avec nft disparaît au redémarrage. Deux réflexes le rendent permanent.

1. Écrire le ruleset dans /etc/nftables.conf (le fichier lu par le service), en le commençant par flush ruleset pour repartir propre.

2. Activer le service qui recharge ce fichier au démarrage :

   sudo systemctl enable --now nftables

3. Vérifier après un reboot que les règles sont bien là :

   sudo nft list ruleset

Comme le fichier est un script texte, versionnez-le dans Git et déployez-le par Ansible : c'est tout l'intérêt de nftables direct en infrastructure as code.

nftables et Docker

Docker écrit ses propres règles dans Netfilter pour publier les ports des conteneurs. Un flush ruleset manuel efface ces règles et casse le réseau des conteneurs jusqu'au prochain redémarrage du démon Docker.

La bonne pratique : laissez Docker gérer ses chaînes, et placez vos règles dans une table séparée plutôt que de vider le ruleset global. Sur une passerelle qui héberge aussi des conteneurs, cloisonnez avec soin et testez après chaque changement.

Aide-mémoire nftables

Les commandes du quotidien pour inspecter et modifier un ruleset actif.

sudo nft list ruleset              # tout le ruleset
sudo nft -a list ruleset           # avec les handles (pour supprimer)
sudo nft list table inet filter    # une table précise
sudo nft add rule inet filter input tcp dport 8443 accept
sudo nft delete rule inet filter input handle 12   # via le handle
sudo nft flush ruleset             # tout effacer (attention !)

Dépannage

Symptôme	Cause probable	Solution
Verrouillé hors du serveur	policy drop sans règle SSH	Accès console, ajouter la règle port 22
Aucune réponse aux requêtes	Pas de règle ct state established	Autoriser established,related
Règles perdues au reboot	Ruleset non persistant	Écrire /etc/nftables.conf + activer le service
Conteneurs Docker injoignables	flush ruleset a effacé les chaînes Docker	Redémarrer docker, isoler vos règles
Paquets bloqués invisibles	Pas de journalisation	Ajouter une règle log prefix avant drop

Glissez pour voir

À retenir

• nftables est le moteur de filtrage de tous les Linux modernes ; iptables n'est plus qu'un wrapper.
• Structure : tables (familles), chaînes accrochées à des hooks, politique par défaut.
• Un bon ruleset serveur est stateful (ct state established,related) et drop par défaut.
• Les sets remplacent ipset pour les listes d'adresses ; les maps vont plus loin.
• NAT en postrouting (masquerade), port forwarding en prerouting (dnat).
• Rendez le ruleset persistant via /etc/nftables.conf et le service nftables.

FAQ : Questions fréquentes

Quelle est la différence entre nftables et iptables ?

nftables est le successeur d'iptables : les deux pilotent Netfilter, mais nftables unifie IPv4/IPv6 dans une seule commande nft, intègre les sets nativement et évalue les règles plus efficacement. Sur les Linux récents, iptables n'est souvent qu'un wrapper vers nftables.

nftables remplace-t-il UFW et Firewalld ?

Non : UFW et Firewalld sont des frontends qui écrivent leurs règles dans nftables. nftables est le moteur. Vous pouvez écrire du nft directement pour un contrôle total, mais ne mélangez jamais nft manuel et un frontend actif sur la même machine.

Comment rendre les règles nftables persistantes après un redémarrage ?

Écrivez le ruleset dans /etc/nftables.conf (commençant par flush ruleset), puis activez le service avec systemctl enable --now nftables. Ce fichier est rechargé automatiquement au démarrage. Étant un script texte, il se versionne dans Git.

Comment configurer le NAT et le masquerade avec nftables ?

Créez une table nat avec une chaîne postrouting de type nat hook postrouting, et ajoutez la règle oifname eth0 masquerade. Activez aussi le routage du noyau avec net.ipv4.ip_forward = 1. Pour le port forwarding, utilisez une chaîne prerouting avec dnat.

nftables peut-il casser le réseau des conteneurs Docker ?

Oui : Docker écrit ses propres règles dans Netfilter pour publier les ports. Un nft flush ruleset efface ces règles et coupe le réseau des conteneurs jusqu'au redémarrage du démon Docker. Placez vos règles dans une table séparée plutôt que de vider le ruleset global.

Prochaines étapes

Introduction aux pare-feux Linux Les concepts avant de choisir un outil.

Configurer UFW Le frontend simple pour Debian/Ubuntu.

Configurer Firewalld Le frontend à zones pour RHEL/Fedora.

Pare-feu : qui peut parler à qui ? Le filtrage réseau expliqué, ingress et egress.

×

📖 Voir la documentation →