Tester une règle nftables avant de la pousser en prod : méthode sûre

Déployer une règle nftables en production peut sembler risqué : un simple oubli de syntaxe, un mauvais filtrage ou une directive trop stricte et c'est l'accès SSH qui saute, coupant le serveur jusqu'à une intervention manuelle au KVM. Heureusement, nftables offre des mécanismes de test et de rollback automatique qui permettent de valider chaque changement avant de le rendre permanent. Cet article explique comment tester méthodiquement vos règles, éviter les lock-out, et industrialiser ce processus dans une architecture XDP/eBPF + nftables comme celle proposée par PAKKT.io.

Pourquoi tester une règle nftables avant de la rendre permanente

Contrairement à un firewall matériel piloté par une interface web avec bouton « Annuler », nftables modifie directement le filtrage du noyau Linux. Une erreur peut couper toute connexion entrante, y compris SSH, et nécessiter un accès physique ou console série pour récupérer la main.

Les risques fréquents en production

• Verrouillage SSH : une politique par défaut drop activée avant d'avoir autorisé le port 22 coupe immédiatement la session.
• Conflit de priorité : une règle large placée avant une règle spécifique peut bloquer le trafic légitime.
• Mauvaise gestion du conntrack : oublier ct state established,related accept bloque les réponses aux connexions sortantes.
• Interférence avec Docker ou fail2ban : créer une table qui flush ou surcharge une chaîne partagée désactive d'autres services.

L'approche recommandée consiste à appliquer la règle de manière temporaire, valider qu'elle fonctionne dans le contexte réel du serveur, puis la rendre permanente seulement après confirmation.

Méthode 1 : le rollback automatique avec timeout

La technique la plus sûre pour éviter un lock-out consiste à appliquer un jeu de règles avec un délai d'auto-annulation. Si vous ne confirmez pas manuellement avant expiration, nftables restaure l'état précédent.

Étape 1 : sauvegarder la configuration actuelle

nft list ruleset > /root/nft-backup-$(date +%F-%H%M%S).conf

Cette archive servira de point de restauration en cas de problème.

Étape 2 : appliquer la nouvelle règle avec timeout

nft -f /etc/nftables.d/test-rule.conf && sleep 60 && nft -f /root/nft-backup-*.conf

Ce script charge le nouveau fichier, attend 60 secondes, puis restaure automatiquement la sauvegarde. Pendant ce délai, ouvrez une seconde session SSH sans fermer la première, et testez que le trafic souhaité (port de jeu, API, etc.) fonctionne correctement.

Étape 3 : confirmer ou laisser annuler

• Si tout fonctionne : interrompre le script (Ctrl+C) dans la session initiale, puis recharger le fichier en mode permanent.
• Si un problème apparaît : ne rien faire ; au bout de 60 secondes, la configuration précédente revient automatiquement.

Cette méthode est idéale pour tester une politique de filtrage complexe, un nouvel ensemble de rate-limits nftables, ou une intégration avec un moteur XDP comme celui de PAKKT.

Méthode 2 : tester dans une table isolée avant fusion

Pour éviter tout risque de conflit avec des tables existantes (Docker, fail2ban, iptables-persistent), nftables permet de créer une table dédiée, y insérer les nouvelles règles, puis fusionner seulement après validation.

Créer une table de test

nft add table inet test_firewall
nft add chain inet test_firewall input { type filter hook input priority filter \; policy accept \; }
nft add rule inet test_firewall input tcp dport 25565 ct state new limit rate 100/second accept
nft add rule inet test_firewall input tcp dport 25565 drop

Cette table inet test_firewall cohabite avec votre table de production (par exemple inet pakkt dans le cas de PAKKT.io). Les paquets traverseront les deux chaînes, et vous pouvez observer les compteurs pour vérifier que la règle correspond bien au trafic attendu.

Vérifier l'impact avec les compteurs

nft list ruleset | grep test_firewall -A 10

Examinez les valeurs packets et bytes pour chaque règle. Si le compteur de la règle drop augmente alors qu'il ne devrait pas, c'est qu'un trafic légitime est bloqué.

Fusionner ou supprimer

• Si validation OK : copiez les règles dans votre table de production et supprimez la table de test.
• Si anomalie : supprimez simplement la table inet test_firewall sans toucher à la production.

nft delete table inet test_firewall

Cette approche est particulièrement utile lorsque vous testez des règles de rate-limit par connexion, des meter avec burst ou des filtres TCP flags complexes.

Méthode 3 : valider la syntaxe et simuler l'application

Avant même de toucher au noyau, nftables propose une option de dry-run pour vérifier la syntaxe d'un fichier de configuration.

Vérification syntaxique

nft -c -f /etc/nftables.d/new-rules.conf

L'option -c (check) parse le fichier sans l'appliquer. Si une erreur de syntaxe existe (parenthèse manquante, mot-clé invalide, mauvais protocole), nftables renverra un message d'erreur précis.

Tester dans un namespace réseau dédié

Pour aller plus loin, créez un namespace Linux isolé, appliquez-y la règle, puis générez du trafic synthétique avec hping3 ou nc.

ip netns add test_nft
ip netns exec test_nft nft -f /etc/nftables.d/new-rules.conf
ip netns exec test_nft nft list ruleset

Cette technique convient aux environnements de développement ou de staging. En production, elle est moins pratique car le namespace ne voit pas le trafic réel.

Industrialiser le test avec un workflow CI/CD et agent automatisé

Dans une infrastructure hébergeant plusieurs serveurs de jeu ou applications critiques, répéter manuellement ces tests sur chaque nœud est chronophage et source d'erreurs. Un agent de configuration centralisé peut appliquer un workflow de test automatique avant chaque déploiement.

Le rôle d'un agent de gestion firewall

Un agent léger installé sur chaque serveur reçoit les nouvelles règles depuis un panel centralisé, les applique en mode test avec timeout, surveille les métriques (compteurs, GeoIP, taux de drop), puis confirme ou rollback automatiquement selon des seuils prédéfinis.

C'est exactement le fonctionnement de l'agent Go de PAKKT : à chaque modification de règle XDP ou nftables depuis le dashboard, l'agent applique le changement, attend 30 secondes de collecte de métriques (heartbeat), et si aucun lock-out ou pic anormal n'est détecté, persiste la configuration. En cas d'échec, il restaure la version précédente via le SHA256 de la configuration sauvegardée.

Exemple de workflow automatisé

Étape	Action	Validation
1. Préparation	Sauvegarde automatique du ruleset nftables actuel	SHA256 stocké en base (audit log)
2. Application	Chargement de la nouvelle règle dans la table inet pakkt	Syntaxe validée avec nft -c côté panel avant envoi
3. Test temps réel	Heartbeat 30s : envoi des compteurs par port, protocole, action (block/accept)	Comparaison avec seuils définis (ex. : drop rate < 5 % du trafic légitime)
4. Décision	Si métriques OK : persist, sinon rollback automatique	Notification dashboard + log centralisé (TimescaleDB)

Cette approche élimine le risque humain et garantit qu'aucune règle mal formée ne reste active plus de quelques secondes. Pour des environnements multi-serveurs, elle permet de déployer une règle sur un serveur pilote, valider l'impact, puis propager progressivement aux autres nœuds.

Bonnes pratiques pour éviter les erreurs de configuration nftables

Toujours autoriser le trafic établi et SSH en premier

nft add rule inet pakkt input ct state established,related accept
nft add rule inet pakkt input tcp dport 22 ct state new accept

Ces deux règles doivent apparaître avant toute politique de drop par défaut ou règle restrictive.

Utiliser des priorités explicites pour éviter les conflits

Lorsque plusieurs tables cohabitent (Docker, fail2ban, PAKKT), vérifiez que leurs chaînes ont des priorités différentes :

nft add chain inet pakkt input { type filter hook input priority filter + 10 \; policy accept \; }

Cela garantit que la chaîne PAKKT est évaluée après la priorité standard filter (0), évitant tout conflit avec les règles Docker ou iptables-legacy.

Tester d'abord en IPv4, puis étendre à IPv6

Si votre serveur accepte du trafic dual-stack, commencez par valider la règle en famille ip (IPv4 uniquement), puis dupliquez-la en ip6 ou migrez vers inet (les deux).

Documenter chaque règle avec un commentaire

nft add rule inet pakkt input udp dport 19132 limit rate 200/second accept comment \"Bedrock rate-limit\"

En cas d'audit ou de debug, ces commentaires accélèrent la compréhension du ruleset et facilitent le travail en équipe.

Complémentarité XDP/eBPF et nftables dans un test de règle

Dans une architecture hybride comme celle de PAKKT, le moteur XDP (stateless, couche 2-3, millions de pps) filtre les paquets avant même qu'ils n'atteignent la pile réseau. Nftables (stateful, couche 3-4, conntrack) intervient ensuite pour des règles plus fines.

Ordre de traversée d'un paquet

1. Carte réseau (NIC) : paquet reçu sur eth0.
2. Programme XDP : lookup dans une BPF map (ex. : port bloqué → XDP_DROP immédiat, sub-microseconde).
3. Pile réseau kernel : si XDP retourne XDP_PASS, le paquet monte.
4. Chaîne nftables input : évaluation des règles stateful (conntrack, rate-limit par connexion, meter/burst).
5. Application : si accept, le paquet arrive au daemon (serveur Minecraft, API, etc.).

Tester la cohérence entre les deux couches

Lorsque vous ajoutez une règle nftables de rate-limit sur un port déjà protégé en XDP, vérifiez que :

• La règle XDP laisse passer le trafic légitime (XDP_PASS).
• La règle nftables affine le filtrage (ex. : autoriser TCP SYN mais limiter le taux de nouvelles connexions).
• Les compteurs XDP (via bpftool map dump name pakkt_stats) et nftables (via nft list ruleset) sont cohérents.

Un agent comme celui de PAKKT synchronise automatiquement les deux couches : quand vous activez une règle de rate-limit sur le port 25565 depuis le dashboard, l'agent crée à la fois l'entrée dans la BPF map XDP (max_port_pps) et la règle nftables correspondante (limit rate + meter), garantissant qu'un test sur l'une reflète l'autre.

Exemple concret : déployer une règle de protection Minecraft sans risque

Imaginons que vous hébergez un serveur Minecraft Java (TCP 25565) et souhaitez limiter les nouvelles connexions à 50 par seconde pour bloquer les attaques par ouverture massive de sockets.

Étape 1 : vérifier la configuration actuelle

nft list ruleset | grep 25565

Si aucune règle n'existe, le trafic est actuellement accepté sans limite (ou géré uniquement en XDP).

Étape 2 : créer la règle avec timeout

nft add rule inet pakkt input tcp dport 25565 ct state new limit rate 50/second accept
nft add rule inet pakkt input tcp dport 25565 drop

Appliquez ces deux règles via le script de rollback automatique présenté plus haut, avec un délai de 60 secondes.

Étape 3 : tester depuis une machine externe

Utilisez hping3 pour simuler des connexions rapides :

hping3 -S -p 25565 --flood --rand-source VOTRE_IP_SERVEUR

Observez les compteurs nftables :

watch -n 1 'nft list ruleset | grep 25565'

Si le compteur de la première règle (accept) monte à environ 50 paquets/seconde et que celui de la seconde (drop) absorbe l'excédent, la règle fonctionne correctement.

Étape 4 : confirmer ou annuler

• Validation OK : interrompre le script, persister la règle dans /etc/nftables.conf ou via l'agent PAKKT.
• Problème détecté : ne rien faire, le rollback restaure l'état précédent après 60 secondes.

Cette méthode s'applique à tous types de jeux (Rust, FiveM, CS2, Bedrock sur UDP 19132) et à tous protocoles (HTTP/HTTPS sur 80/443, SSH sur 22, API custom).

Logs et audit : tracer chaque changement de règle

Pour des raisons de conformité (RGPD, audit sécurité) et de debug, il est essentiel de journaliser chaque modification de règle nftables.

Activer le logging nftables pour une règle spécifique

nft add rule inet pakkt input tcp dport 25565 log prefix \"[PAKKT-MINECRAFT] \" drop

Les paquets bloqués apparaîtront dans /var/log/kern.log ou via journalctl -k.

Centraliser les logs avec un agent de monitoring

L'agent PAKKT envoie toutes les modifications de règles (ajout, suppression, rollback) vers une base TimescaleDB centralisée. Chaque événement est horodaté, lié à l'agent source, et inclut le hash SHA256 de la configuration avant/après. Cela permet de :

• Retrouver quelle règle a causé un incident (audit log complet).
• Rejouer une configuration passée en un clic depuis le dashboard.
• Alerter par webhook si un rollback automatique se déclenche (signe d'une règle problématique).

Pour les infrastructures sans agent centralisé, vous pouvez scripter un envoi de log vers un SIEM (Graylog, ELK) ou un service Syslog distant.

Ressources officielles pour approfondir nftables

Pour maîtriser la syntaxe avancée, les familles de protocoles et les expressions de filtrage, consultez la documentation officielle :

• Wiki nftables : syntaxe, exemples, FAQ.
• Netfilter.org – nftables : documentation de référence.
• man nft : pages de manuel complètes sur votre système Linux.
• eBPF.io : guides sur l'intégration XDP/eBPF + nftables.

Pour des cas d'usage spécifiques (protection de serveurs de jeu, intégration Docker, rate-limit avancé), le blog PAKKT propose des tutoriels détaillés et des templates de règles prêts à l'emploi.

Tester chaque règle nftables avant de la rendre permanente n'est pas une contrainte mais une discipline indispensable en production. Grâce aux mécanismes de rollback automatique, aux tables isolées et à l'industrialisation via agent automatisé, vous pouvez itérer rapidement sans jamais risquer un lock-out. Dans une architecture XDP/eBPF + nftables, cette rigueur garantit une protection kernel performante, auditable et résiliente face aux attaques DDoS volumétriques et applicatives.

FAQ

Comment annuler automatiquement une règle nftables si elle coupe SSH ?

Utilisez un script qui applique la règle puis restaure la sauvegarde après un délai (ex. : nft -f new.conf && sleep 60 && nft -f backup.conf). Ouvrez une seconde session SSH pour tester. Si tout fonctionne, interrompez le script avec Ctrl+C ; sinon, la configuration précédente revient automatiquement après 60 secondes.

Peut-on tester une règle nftables sans impacter le trafic de production ?

Oui, créez une table dédiée (ex. : inet test_firewall) avec ses propres chaînes et priorités. Les paquets traverseront cette table en parallèle de votre table de production. Observez les compteurs pour valider le comportement, puis fusionnez ou supprimez la table de test sans toucher à la production.

Comment vérifier qu'une règle nftables ne bloque pas par erreur le trafic légitime ?

Consultez les compteurs de chaque règle avec nft list ruleset. Si une règle drop accumule des paquets alors qu'elle ne devrait pas, c'est qu'un filtre est trop strict. Comparez également les métriques XDP (via bpftool map dump) et nftables pour détecter toute incohérence entre les deux couches.