Guide nftables Linux Complet (2026)

Introduction : pourquoi nftables est devenu incontournable en 2026

Le pare-feu reste la première ligne de défense de tout serveur Linux. Bon, soyons honnêtes : combien d'entre nous continuent à utiliser iptables en 2026 ? Beaucoup trop. La réalité, c'est qu'iptables est en fin de vie. Son successeur, nftables, est le framework de filtrage par défaut sur Debian depuis Buster (10), sur RHEL/CentOS depuis la version 8, sur Ubuntu 20.04+ et sur Fedora depuis la version 18. Et avec le noyau Linux 6.18/6.19, les optimisations du backend pipapo pour les sets dynamiques apportent des gains de performance mesurables — surtout pour les cas d'utilisation avec Fail2Ban.

Les chiffres parlent d'eux-mêmes : en 2025, plus de 5 500 CVE ont été recensés pour le seul noyau Linux. Ça fait 8 à 9 nouvelles vulnérabilités par jour. Les attaques SSH par force brute représentent plus de 60 % des tentatives d'intrusion sur les serveurs exposés. Dans ce contexte, un pare-feu bien configuré n'est pas un luxe — c'est une nécessité absolue.

Ce guide vous accompagne de A à Z dans la maîtrise de nftables : des fondamentaux jusqu'aux fonctionnalités avancées (sets dynamiques, verdict maps, rate limiting, géo-blocage, flowtables), en passant par l'intégration native avec Fail2Ban, la sécurisation IPv6 et le déploiement dans des environnements Kubernetes. Chaque section contient des configurations prêtes à déployer en production. Allez, on attaque.

nftables vs iptables : comprendre les différences fondamentales

Pourquoi migrer est désormais obligatoire

iptables n'est plus activement développé. Point. Les distributions majeures l'ont remplacé par nftables, et même quand vous tapez iptables sur un système récent, c'est souvent le backend xtables-nft qui traduit vos commandes en bytecode nftables. Mais cette traduction ne débloque pas les avantages architecturaux fondamentaux de nftables — flowtables, mises à jour atomiques, offload matériel. Pour en profiter, il faut passer à la syntaxe native.

Voici un comparatif des deux frameworks :

Fonctionnalité	iptables	nftables
Performance de lookup	Linéaire O(n)	Optimisé O(log n) avec hash/sets
Syntaxe	Complexe, incohérente entre outils	Unifiée, déclarative
IPv4 / IPv6	Outils séparés (iptables, ip6tables)	Famille `inet` unifiée
Ensembles (sets)	Externe via ipset	Natif, intégré au noyau
Atomicité	Règle par règle	Transaction complète
Débogage	Limité	Traçage avancé intégré
Actions multiples par règle	Non	Oui
Tables/chaînes par défaut	Prédéfinies	Aucune — flexibilité totale

Migrer les règles existantes

Si vous avez un jeu de règles iptables existant, deux outils facilitent la transition :

# Traduire une règle iptables unique
iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
# Résultat : nft add rule ip filter INPUT tcp dport 22 counter accept

# Traduire un fichier de règles complet
iptables-restore-translate -f /etc/iptables/rules.v4 > /etc/nftables-migrated.conf

# Même chose pour IPv6
ip6tables-restore-translate -f /etc/iptables/rules.v6 >> /etc/nftables-migrated.conf

# Valider la configuration traduite sans l'appliquer
nft -c -f /etc/nftables-migrated.conf

Un conseil important : ne vous contentez pas de traduire mécaniquement. Honnêtement, j'ai vu trop de migrations qui se résumaient à un copier-coller de l'ancienne logique dans la nouvelle syntaxe. Profitez de la migration pour repenser votre architecture de règles en utilisant les sets, maps et la famille inet. C'est là que nftables brille vraiment.

Architecture et concepts fondamentaux de nftables

La hiérarchie : tables, chaînes, règles

nftables s'organise selon une hiérarchie claire :

Tables : conteneurs de premier niveau, associés à une famille d'adresses (ip, ip6, inet, arp, bridge, netdev). La famille inet est recommandée car elle gère IPv4 et IPv6 simultanément
Chaînes : conteneurs de règles. Les chaînes de base (base chains) sont rattachées à un hook Netfilter (input, forward, output, prerouting, postrouting) avec un type et une priorité
Règles : expressions de correspondance et actions. Contrairement à iptables, une seule règle peut contenir plusieurs actions
Sets : collections d'éléments (adresses IP, ports) avec lookup O(1) par table de hachage
Maps : associations clé-valeur pour le routage de décisions

Point crucial (et c'est un piège classique pour ceux qui viennent d'iptables) : nftables ne crée aucune table ni chaîne par défaut. Cela signifie que si vous n'avez pas configuré de chaîne avec un hook, les paquets traversent le système sans filtrage. C'est à vous de tout définir — et c'est exactement ce qui rend nftables si flexible.

La machine virtuelle nftables

Sous le capot, nftables exécute un bytecode compilé dans une machine virtuelle intégrée au noyau. Les règles sont compilées en espace utilisateur par l'outil nft, puis envoyées au noyau via Netlink.

Cette approche offre deux avantages majeurs :

Atomicité : un script entier est appliqué en une seule transaction Netlink. Si une erreur survient, aucune règle n'est appliquée — votre pare-feu reste dans un état cohérent. Avec iptables, les règles étaient appliquées une par une, créant des fenêtres de vulnérabilité pendant les mises à jour
Performance : le bytecode est optimisé pour minimiser le nombre d'opérations par paquet. Les sets et maps utilisent des structures de données du noyau (hash tables, arbres rouge-noir, pipapo) pour des lookups en temps constant ou logarithmique

Installation et configuration de base

Installation sur les distributions majeures

L'installation est vraiment simple, quelle que soit votre distribution :

# Debian / Ubuntu
sudo apt update && sudo apt install -y nftables
sudo systemctl enable --now nftables

# RHEL / CentOS / Fedora / AlmaLinux
sudo dnf install -y nftables
sudo systemctl enable --now nftables

# Arch Linux
sudo pacman -S nftables
sudo systemctl enable --now nftables

# Vérifier la version installée
nft --version
# nft 1.1.1 (Joe Btfsplk) — version typique début 2026

Sur RHEL et dérivés, assurez-vous de désactiver firewalld si vous souhaitez gérer nftables directement — les deux ne font vraiment pas bon ménage :

# Désactiver firewalld pour éviter les conflits
sudo systemctl stop firewalld
sudo systemctl disable firewalld
sudo systemctl mask firewalld

Configuration durcie pour un serveur de production

Voici un fichier /etc/nftables.conf complet et durci, adapté à un serveur web en production. C'est une base solide que j'utilise personnellement comme point de départ sur mes déploiements :

#!/usr/sbin/nft -f

# Nettoyer toutes les règles existantes
flush ruleset

# === Table principale : inet (IPv4 + IPv6) ===
table inet firewall {

    # --- Sets statiques ---
    set management_nets {
        type ipv4_addr
        flags interval
        elements = {
            10.0.1.0/24,        # Réseau d'administration
            192.168.100.0/24    # VPN administrateurs
        }
    }

    set blocked_ips {
        type ipv4_addr
        flags interval, timeout
        timeout 24h
    }

    # --- Chaîne INPUT ---
    chain input {
        type filter hook input priority filter; policy drop;

        # Connexions établies et associées
        ct state established,related accept

        # Paquets invalides → poubelle
        ct state invalid drop

        # Loopback autorisé
        iif "lo" accept

        # IPs bloquées
        ip saddr @blocked_ips drop

        # ICMP : ping rate-limité
        ip protocol icmp icmp type echo-request \
            limit rate 5/second burst 10 packets accept
        ip6 nexthdr icmpv6 icmpv6 type echo-request \
            limit rate 5/second burst 10 packets accept

        # ICMPv6 essentiels (NDP, etc.)
        ip6 nexthdr icmpv6 icmpv6 type {
            nd-neighbor-solicit,
            nd-neighbor-advert,
            nd-router-solicit,
            nd-router-advert
        } accept

        # SSH : uniquement depuis les réseaux d'administration
        tcp dport 22 ip saddr @management_nets \
            ct state new limit rate 10/minute accept

        # HTTP/HTTPS : ouvert
        tcp dport { 80, 443 } ct state new accept

        # Journaliser les paquets refusés (rate-limité)
        limit rate 10/minute burst 20 packets \
            log prefix "[nftables DROP INPUT] " level warn

        # Politique par défaut : drop (déjà défini)
    }

    # --- Chaîne FORWARD ---
    chain forward {
        type filter hook forward priority filter; policy drop;
        ct state established,related accept
        ct state invalid drop
    }

    # --- Chaîne OUTPUT ---
    chain output {
        type filter hook output priority filter; policy accept;
        ct state established,related accept
        ct state invalid drop
    }
}

Commandes essentielles pour le quotidien

Ce sont les commandes que vous allez taper le plus souvent. Gardez-les sous le coude :

# Valider une configuration SANS l'appliquer
sudo nft -c -f /etc/nftables.conf

# Appliquer la configuration
sudo nft -f /etc/nftables.conf

# Afficher toutes les règles actives
sudo nft list ruleset

# Afficher une table spécifique
sudo nft list table inet firewall

# Ajouter une IP au set de blocage à chaud
sudo nft add element inet firewall blocked_ips { 203.0.113.50 }

# Supprimer une IP du set
sudo nft delete element inet firewall blocked_ips { 203.0.113.50 }

# Sauvegarder les règles actives
sudo nft list ruleset > /root/nftables-backup-$(date +%Y%m%d).conf

# Activer le traçage pour déboguer
sudo nft add rule inet firewall input meta nftrace set 1
sudo nft monitor trace

Fonctionnalités avancées : sets, maps et verdict maps

Sets nommés et dynamiques

Les sets sont, à mon avis, la fonctionnalité la plus puissante de nftables. Là où iptables nécessitait 200 règles individuelles pour bloquer 200 adresses IP (oui, c'était aussi absurde que ça en a l'air), nftables effectue un lookup en O(1) dans une table de hachage :

# Set statique d'adresses autorisées
set trusted_admins {
    type ipv4_addr
    elements = {
        10.0.1.10,
        10.0.1.11,
        10.0.1.12
    }
}

# Set dynamique avec expiration automatique
set rate_limited {
    type ipv4_addr
    flags dynamic, timeout
    timeout 5m
    size 65536
}

# Set d'intervalles pour les plages réseau
set internal_nets {
    type ipv4_addr
    flags interval
    elements = {
        10.0.0.0/8,
        172.16.0.0/12,
        192.168.0.0/16
    }
}

# Set concaténé : IP + port
set allowed_services {
    type ipv4_addr . inet_service
    elements = {
        10.0.1.10 . 5432,    # PostgreSQL depuis l'app server
        10.0.1.11 . 6379,    # Redis depuis le cache
        10.0.1.12 . 3306     # MySQL depuis le backend
    }
}

Maps et verdict maps (vmaps)

Les maps permettent d'associer des clés à des valeurs, tandis que les verdict maps associent des clés à des verdicts (accept, drop, jump). Elles remplacent élégamment de longues séries de règles conditionnelles :

# Map nommée : rediriger le trafic selon le port de destination
map port_redirect {
    type inet_service : inet_service
    elements = {
        8080 : 80,
        8443 : 443,
        2222 : 22
    }
}

# Verdict map : action différente selon le réseau source
map network_policy {
    type ipv4_addr : verdict
    flags interval
    elements = {
        10.0.1.0/24  : accept,     # Administration → autorisé
        10.0.2.0/24  : jump dmz,   # DMZ → chaîne spécifique
        192.168.0.0/16 : drop      # Interne non autorisé → refusé
    }
}

# Utilisation dans une règle
chain input {
    type filter hook input priority filter; policy drop;
    ip saddr vmap @network_policy
}

Sans verdict map, ce routage nécessiterait trois règles distinctes. Avec la vmap, tout tient en une seule ligne — et le noyau effectue le lookup en temps constant grâce à la table de hachage. Franchement, une fois qu'on y a goûté, on ne revient pas en arrière.

Rate limiting par IP avec meters

Les meters (anciennement appelés « dynamic sets ») permettent d'appliquer des limites par adresse IP source — bien plus efficace que le hashlimit d'iptables :

# Limiter les connexions SSH à 3/minute par IP source
chain input {
    tcp dport 22 ct state new \
        meter ssh_limit { ip saddr limit rate 3/minute burst 5 packets } \
        accept

    # Journaliser les tentatives excessives
    tcp dport 22 ct state new \
        meter ssh_abuse { ip saddr limit rate over 3/minute } \
        log prefix "[nftables SSH BRUTE] " drop
}

# Protection anti-flood HTTP (par IP)
tcp dport { 80, 443 } ct state new \
    meter http_flood { ip saddr limit rate 50/second burst 100 packets } \
    accept

# Flood détecté → journaliser et bloquer
tcp dport { 80, 443 } ct state new \
    meter http_flood_log { ip saddr limit rate over 50/second } \
    log prefix "[nftables HTTP FLOOD] " drop

Géo-blocage avec nftables

Bloquer le trafic par pays

Le géo-blocage est une couche supplémentaire qui réduit significativement le bruit — tentatives de brute force, scans automatisés — en bloquant les plages IP de pays depuis lesquels aucun trafic légitime n'est attendu. Ce n'est pas une solution miracle (les attaquants utilisent des VPN), mais c'est un filtre efficace en complément de Fail2Ban et du rate limiting.

# Installer nft-geo-filter (outil de génération de sets géo-IP)
git clone https://github.com/rpthms/nft-geo-filter.git
cd nft-geo-filter

# Générer un set pour bloquer les IP de pays spécifiques
# Codes ISO 3166-1 alpha-2 : CN (Chine), RU (Russie), KP (Corée du Nord)
python3 nft_geo_filter.py -f inet -t firewall \
    --set-name geo_blocked \
    CN RU KP > /etc/nftables/geo-block.conf

# Inclure dans la configuration principale
# Dans /etc/nftables.conf, ajouter :
include "/etc/nftables/geo-block.conf"

# Puis dans la chaîne input :
ip saddr @geo_blocked drop
ip6 saddr @geo_blocked_v6 drop

Pour automatiser la mise à jour des listes (parce que bon, personne n'a envie de faire ça à la main chaque semaine) :

# Crontab : mise à jour hebdomadaire des listes géo-IP
# /etc/cron.weekly/update-geoip-nftables
#!/bin/bash
cd /opt/nft-geo-filter
python3 nft_geo_filter.py -f inet -t firewall \
    --set-name geo_blocked \
    CN RU KP > /etc/nftables/geo-block.conf
nft -c -f /etc/nftables.conf && nft -f /etc/nftables.conf
logger "nftables: listes géo-IP mises à jour"

Un mot d'avertissement quand même : le géo-blocage ne remplace pas une authentification robuste. Les attaquants utilisent des VPN et des proxys résidentiels. C'est un filtre volumétrique, pas une protection absolue. Mais sur mes serveurs, ça réduit facilement 70-80 % du bruit dans les logs.

Flowtables : accélérer le trafic réseau

Le fast path de Netfilter

Les flowtables offrent un chemin accéléré (fast path) pour les connexions TCP et UDP établies. Au lieu de traverser toute la pile Netfilter pour chaque paquet, les flux reconnus sont traités par un raccourci au niveau du noyau — voire déchargés sur le matériel réseau compatible.

Le principe est assez élégant : une fois qu'une connexion est établie et suivie par le conntrack, ses paquets peuvent être offloadés vers la flowtable. Le noyau effectue alors un lookup rapide et redirige directement le paquet vers l'interface de sortie, sans passer par les chaînes de filtrage.

# Configuration avec flowtable (routeur/passerelle)
table inet router {

    # Déclaration de la flowtable
    flowtable ft {
        hook ingress priority filter
        devices = { eth0, eth1 }
        # Ajouter "flags offload" pour l'offload matériel
        # (nécessite un NIC compatible : Mellanox mlx5, Intel i40e/ixgbe)
    }

    chain forward {
        type filter hook forward priority filter; policy drop;

        # Offloader les connexions établies vers la flowtable
        ct state established flow add @ft accept

        # Autoriser les nouvelles connexions légitimes
        ct state related accept
        ct state new tcp dport { 80, 443 } accept
        ct state invalid drop
    }
}

Les gains sont considérables. Sur un routeur Linux avec des cartes réseau compatibles, l'offload matériel transforme le pare-feu en appliance wire-speed pour les flux établis. Même en software-only, la flowtable réduit significativement la consommation CPU et la latence.

Quelques points à garder en tête :

Les paquets offloadés ne sont plus visibles par tcpdump ou les compteurs de règles (ça peut surprendre lors du débogage)
Le NAT doit être configuré avant l'offloading
L'offload matériel nécessite un driver compatible (Mellanox mlx5, Intel i40e/ixgbe principalement)
La flowtable software fonctionne sur tout matériel, y compris les Raspberry Pi

Intégration native avec Fail2Ban

Configurer Fail2Ban pour nftables natif

Par défaut, Fail2Ban utilise encore iptables comme backend. C'est dommage, mais heureusement la bascule vers nftables natif est assez simple. Voici comment procéder :

# Étape 1 : Créer la table nftables dédiée à Fail2Ban
sudo mkdir -p /etc/nftables
cat << 'EOF' | sudo tee /etc/nftables/fail2ban.conf
#!/usr/sbin/nft -f
table ip fail2ban {
    chain input {
        type filter hook input priority filter - 1; policy accept;
    }
}
EOF

# Inclure dans /etc/nftables.conf
# Ajouter après "flush ruleset" :
# include "/etc/nftables/fail2ban.conf"

La priorité filter - 1 garantit que la chaîne Fail2Ban est évaluée avant la chaîne principale. Les paquets provenant d'IP bannies sont donc rejetés avant même d'atteindre vos règles de filtrage. C'est un détail subtil mais important.

# Étape 2 : Configurer Fail2Ban
# /etc/fail2ban/jail.local
[DEFAULT]
banaction = nftables-multiport
chain = input
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd

[sshd]
enabled = true
port = ssh
maxretry = 3
bantime = 4h

[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = nftables-allports
bantime = 7d
findtime = 1d
maxretry = 3

Le jail recidive mérite une attention particulière — il bannit les récidivistes pendant 7 jours. Si une même IP se fait bannir 3 fois en 24h, elle prend un ban longue durée sur tous les ports. Très efficace contre les botnets persistants.

# Étape 3 : Configurer le backend nftables
# /etc/fail2ban/action.d/nftables-common.local
[Init]
nftables_family = ip
nftables_table = fail2ban
blocktype = drop
nftables_set_prefix =

Lier Fail2Ban à nftables via systemd

Point critique souvent négligé : si nftables redémarre (rechargement de configuration, par exemple), la table Fail2Ban est vidée et les bans sont perdus. J'ai appris ça à mes dépens sur un serveur de production. La solution est de lier les deux services via systemd :

# Créer l'override systemd
sudo mkdir -p /etc/systemd/system/fail2ban.service.d
cat << 'EOF' | sudo tee /etc/systemd/system/fail2ban.service.d/override.conf
[Unit]
Requires=nftables.service
PartOf=nftables.service

[Install]
WantedBy=multi-user.target nftables.service
EOF

sudo systemctl daemon-reload
sudo systemctl restart fail2ban

# Vérifier que les règles Fail2Ban sont bien dans nftables
sudo nft list table ip fail2ban

Sécuriser IPv6 : les pièges à éviter

IPv6 change la donne en matière de pare-feu

En IPv4, le NAT offrait une forme accidentelle de protection — les machines internes n'étaient pas directement joignables. Mais en IPv6, chaque machine possède une adresse publique routable. Résultat : vos serveurs internes sont directement exposés au trafic entrant, et le pare-feu devient un élément critique de sécurité.

La bonne nouvelle : avec la famille inet de nftables, vos règles s'appliquent simultanément à IPv4 et IPv6. Mais — et c'est un « mais » important — certains paquets ICMPv6 sont essentiels au fonctionnement du réseau et ne doivent jamais être bloqués :

# Règles ICMPv6 essentielles (NDP - Neighbor Discovery Protocol)
# OBLIGATOIRE pour le fonctionnement d'IPv6
chain input {
    # NDP : découverte des voisins (équivalent ARP en IPv4)
    ip6 nexthdr icmpv6 icmpv6 type {
        nd-neighbor-solicit,
        nd-neighbor-advert
    } accept

    # NDP : découverte des routeurs
    ip6 nexthdr icmpv6 icmpv6 type {
        nd-router-solicit,
        nd-router-advert
    } accept

    # Destination unreachable et packet too big
    # (nécessaire pour le Path MTU Discovery)
    ip6 nexthdr icmpv6 icmpv6 type {
        destination-unreachable,
        packet-too-big,
        time-exceeded,
        parameter-problem
    } accept

    # Echo request (ping6) rate-limité
    ip6 nexthdr icmpv6 icmpv6 type echo-request \
        limit rate 5/second accept
}

Bloquer le NDP revient à couper la résolution d'adresses IPv6 — votre serveur deviendrait injoignable sur le réseau local. Bloquer packet-too-big casserait le Path MTU Discovery et provoquerait des connexions suspendues mystérieuses. Ce sont des erreurs fréquentes et vraiment pénibles à diagnostiquer quand on ne sait pas où chercher.

nftables et Kubernetes : l'intégration moderne

kube-proxy en mode nftables

Depuis Kubernetes v1.33, kube-proxy supporte pleinement le mode nftables (statut stable). Ce mode remplace les milliers de règles iptables que kube-proxy générait traditionnellement pour le routage des Services par une architecture nftables native, plus performante et plus lisible.

Les CNI populaires comme Calico et Cilium s'appuient également sur nftables pour implémenter les Network Policies. Si vous gérez un pare-feu nftables sur les nœuds de votre cluster, voici le point essentiel à retenir : nftables n'a pas de tables réservées. Chaque composant (kube-proxy, Calico, votre pare-feu) travaille dans ses propres tables. Mais si votre pare-feu drop des paquets, il n'y a pas moyen de contourner vos règles — il faut configurer explicitement les exceptions.

# Exemple : autoriser le trafic Kubernetes sur un nœud
set k8s_pods {
    type ipv4_addr
    flags interval
    elements = {
        10.244.0.0/16    # CIDR des Pods (adapter selon votre config)
    }
}

set k8s_services {
    type ipv4_addr
    flags interval
    elements = {
        10.96.0.0/12     # CIDR des Services (adapter selon votre config)
    }
}

chain input {
    # API server
    tcp dport 6443 ip saddr @management_nets accept

    # Kubelet
    tcp dport 10250 ip saddr @k8s_pods accept

    # NodePort range
    tcp dport 30000-32767 accept

    # Communication inter-pods
    ip saddr @k8s_pods ip daddr @k8s_pods accept
}

Débogage et monitoring

Le traçage intégré

nftables dispose d'un système de traçage intégré bien plus puissant que le -j LOG d'iptables. Il permet de suivre le parcours exact d'un paquet à travers toutes les chaînes et règles — un vrai game changer pour le débogage :

# Activer le traçage sur une règle spécifique
# (ajout d'une règle de trace en début de chaîne)
sudo nft insert rule inet firewall input \
    tcp dport 22 meta nftrace set 1

# Lancer le moniteur de trace
sudo nft monitor trace

# Exemple de sortie :
# trace id 3f8a... inet firewall input
#   rule tcp dport 22 meta nftrace set 1 (verdict continue)
# trace id 3f8a... inet firewall input
#   rule tcp dport 22 ip saddr @management_nets ... accept
#   verdict accept

# Ne pas oublier de supprimer la règle de trace après débogage !
sudo nft delete rule inet firewall input handle XX

Monitoring des compteurs

# Ajouter des compteurs nommés pour le monitoring
counter http_accepted {
    packets 0 bytes 0
}
counter ssh_accepted {
    packets 0 bytes 0
}
counter dropped_total {
    packets 0 bytes 0
}

# Utilisation dans les règles
tcp dport { 80, 443 } counter name http_accepted accept
tcp dport 22 ip saddr @management_nets counter name ssh_accepted accept

# En fin de chaîne
counter name dropped_total drop

# Consulter les compteurs
sudo nft list counters table inet firewall

Ces compteurs nommés s'intègrent facilement dans des outils de monitoring comme Prometheus (via node_exporter ou un exporter nftables dédié), Grafana, ou même un simple script cron qui exporte les valeurs vers votre système de supervision. Personnellement, je pousse ces métriques dans Prometheus et j'ai un dashboard Grafana qui m'alerte quand le taux de drops dépasse un seuil.

Bonnes pratiques et checklist de déploiement

Les règles d'or de la configuration nftables

Politique deny-all par défaut : toujours policy drop sur les chaînes input et forward. N'autorisez que ce qui est explicitement nécessaire
Famille inet : utilisez inet au lieu de ip ou ip6 séparément, sauf besoin spécifique
Validez avant d'appliquer : toujours nft -c -f avant nft -f. Une mauvaise règle peut vous couper l'accès SSH (croyez-moi, ça arrive plus souvent qu'on ne le pense)
Connexion console : ayez toujours un accès console (IPMI, iLO, KVM, console cloud) disponible quand vous modifiez les règles de pare-feu à distance
Sauvegardez régulièrement : nft list ruleset > backup.conf avant chaque modification
Journalisez les drops : loguez les paquets rejetés avec un rate limit pour identifier les tentatives d'intrusion sans saturer les logs
Sets plutôt que règles multiples : préférez un set de 200 adresses à 200 règles individuelles
Un seul outil : ne mélangez pas nftables, firewalld et iptables sur le même système
Auditez régulièrement : intégrez une vérification des règles de pare-feu dans vos audits de sécurité mensuels avec Lynis ou OpenSCAP
Documentez : commentez votre fichier nftables.conf — dans six mois, vous remercierez votre vous du passé

Checklist de déploiement

# 1. Vérifier que nftables est le seul gestionnaire de pare-feu
sudo systemctl is-active firewalld  # doit retourner "inactive"
sudo systemctl is-active nftables   # doit retourner "active"

# 2. Valider la configuration
sudo nft -c -f /etc/nftables.conf

# 3. Vérifier les règles actives
sudo nft list ruleset | grep "policy drop"
# → les chaînes input et forward doivent avoir policy drop

# 4. Vérifier les connexions établies
sudo nft list ruleset | grep "ct state established"
# → doit être présent dans la chaîne input

# 5. Tester la connectivité SSH (depuis un autre terminal !)
ssh user@server

# 6. Vérifier le logging
sudo journalctl -k --since "5 minutes ago" | grep nftables

# 7. Scanner les ports ouverts depuis l'extérieur
nmap -sS -sV server.example.com

FAQ : questions fréquentes sur nftables

nftables remplace-t-il complètement iptables ?

Oui, nftables est le remplacement officiel d'iptables, ip6tables, arptables et ebtables. Il est le framework par défaut sur toutes les distributions majeures depuis plusieurs années. La commande iptables existe encore sur certains systèmes, mais elle utilise le backend xtables-nft qui traduit les commandes en bytecode nftables. Pour bénéficier pleinement des performances et fonctionnalités avancées (sets, maps, flowtables, atomicité), il est recommandé d'utiliser la syntaxe native nft.

Peut-on utiliser nftables et firewalld en même temps ?

C'est fortement déconseillé. firewalld peut utiliser nftables comme backend, mais les deux ne doivent pas être configurés indépendamment sur le même système. Les interactions entre règles de différents gestionnaires créent des comportements imprévisibles et des failles de sécurité. Choisissez l'un ou l'autre : nftables directement pour un contrôle fin, ou firewalld si vous préférez une interface de plus haut niveau.

Comment éviter de se verrouiller hors du serveur lors de la configuration ?

Trois précautions essentielles : premièrement, testez toujours avec nft -c -f /etc/nftables.conf avant d'appliquer. Deuxièmement, gardez une session SSH ouverte pendant que vous testez depuis une seconde session. Troisièmement, ayez un accès console de secours (IPMI, iLO, KVM virtuel, console cloud).

Et une astuce bonus que j'utilise systématiquement : configurez un cron temporaire qui restaure la configuration précédente après 5 minutes. Si tout fonctionne, vous supprimez le cron. Si vous êtes coupé, la configuration sera automatiquement restaurée. Ça m'a sauvé plus d'une fois.

nftables fonctionne-t-il avec Docker et Kubernetes ?

Oui. Docker utilise nftables comme backend de pare-feu sur les noyaux récents. Kubernetes v1.33 supporte nftables en mode stable via kube-proxy. Les CNI comme Calico et Cilium gèrent leurs propres tables nftables. Le point important est que chaque composant travaille dans ses propres tables — il n'y a pas de tables par défaut partagées comme avec iptables. Si votre pare-feu personnel drop le trafic des Pods, vous devez créer des exceptions explicites.

Quel est l'impact de nftables sur les performances du serveur ?

L'impact est minimal et généralement inférieur à celui d'iptables. Grâce aux lookups optimisés O(log n) via sets et maps (contre O(n) pour iptables), nftables est plus rapide avec de grands jeux de règles. Les flowtables réduisent encore davantage la charge en court-circuitant la pile Netfilter pour les connexions établies. Avec l'offload matériel sur des NIC compatibles (Mellanox, Intel), les performances peuvent atteindre le wire-speed. Même en mode software-only, les gains sont mesurables, surtout pour le routage et le NAT.