Top 10 des règles nftables essentielles pour un serveur de jeu en prod

Les règles nftables serveur jeu constituent la colonne vertébrale de la sécurité réseau en production : mal configurées, elles exposent vos ports critiques aux floods TCP SYN, aux scans UDP ou aux attaques par amplification. Cet article dresse la checklist opérationnelle des dix règles essentielles pour 2026, en couvrant la gestion du conntrack, les limites de débit, la protection TCP flags et l'intégration avec XDP pour une défense en profondeur.

Pourquoi nftables reste incontournable pour les serveurs de jeu en 2026

Depuis la déprécation d'iptables dans les distributions récentes (Debian 11+, Ubuntu 22.04+), nftables s'impose comme le framework de filtrage kernel standard. Contrairement à son prédécesseur, nftables exploite une API unique (netlink) et une syntaxe cohérente : une table inet agrège IPv4 et IPv6 dans les mêmes règles, simplifiant radicalement l'administration.

Pour un serveur de jeu — Minecraft 25565/TCP, Rust 28015-28016/UDP, CS2 27015/UDP — la priorité est double : protéger les ports publics des floods volumétriques et maintenir une latence sub-milliseconde pour les joueurs légitimes. Les règles nftables assurent :

• Le filtrage stateful via ct state (conntrack) : seules les nouvelles connexions ou paquets établis traversent les règles coûteuses.
• Le rate-limiting par connexion (ct count) ou par IP source (meter + burst).
• La validation des flags TCP (SYN, ACK, FIN, RST) pour bloquer les paquets malformés ou les attaques XMAS/NULL.
• Le marquage (meta mark) et le routage différencié (DSCP) des flux prioritaires.

Contrairement aux solutions cloud de scrubbing (OVH Game DDoS, Cloudflare Spectrum), nftables opère directement sur le serveur, en coordination avec un programme XDP chargé en amont du stack réseau. Ce tandem XDP + nftables est au cœur de l'architecture PAKKT.io, qui orchestre les deux couches depuis un panel centralisé.

Top 10 règles nftables à déployer en production

1. Table et chaînes isolées

Créez une table inet pakkt dédiée, distincte de la table filter par défaut. Cela évite tout conflit avec Docker (table nat), fail2ban (table filter) ou iptables-persistent. Définissez trois chaînes avec priorités explicites :

nft add table inet pakkt
nft add chain inet pakkt input { type filter hook input priority 0 \; policy accept \; }
nft add chain inet pakkt forward { type filter hook forward priority 0 \; policy accept \; }
nft add chain inet pakkt output { type filter hook output priority 0 \; policy drop \; }

La priorité 0 place ces chaînes avant la table filter standard (priorité 100), permettant un filtrage précoce. La policy accept en input garantit qu'aucun trafic légitime n'est bloqué par défaut, vous ajouterez ensuite des règles drop ciblées.

2. Accepter le loopback et l'ICMP indispensable

nft add rule inet pakkt input iif lo accept
nft add rule inet pakkt input icmp type { echo-request, echo-reply } limit rate 10/second accept
nft add rule inet pakkt input icmpv6 type { echo-request, echo-reply, nd-neighbor-solicit, nd-neighbor-advert } limit rate 10/second accept

L'interface lo (loopback) doit toujours être autorisée : elle véhicule le trafic inter-processus local (bases de données, métriques Prometheus, heartbeat agent PAKKT). L'ICMP est indispensable pour le diagnostic réseau (ping, path MTU discovery) mais vulnérable aux floods : le rate-limit à 10 pps est un compromis sécurité/usabilité.

3. Filtrer les connexions établies et apparentées en premier

nft add rule inet pakkt input ct state established,related accept

Cette règle exploite le module conntrack du noyau pour court-circuiter l'évaluation des paquets appartenant à une session déjà validée. Placée en tête de chaîne, elle réduit drastiquement la charge CPU : un serveur de jeu avec 200 joueurs simultanés génère 50 000 à 100 000 pps en régime nominal, dont 98 % de paquets établis.

⚠️ Prérequis : vérifiez que les modules nf_conntrack, nf_conntrack_ipv4 et nf_conntrack_ipv6 sont chargés (lsmod | grep nf_conntrack). Ajustez net.netfilter.nf_conntrack_max dans /etc/sysctl.conf (minimum 262144 pour 100+ joueurs) pour éviter la saturation du tableau de suivi.

4. Bloquer les paquets TCP malformés (flags invalides)

nft add rule inet pakkt input tcp flags \& \(fin\|syn\|rst\|ack\) == 0x0 drop
nft add rule inet pakkt input tcp flags \& \(fin\|syn\) == \(fin\|syn\) drop
nft add rule inet pakkt input tcp flags \& \(syn\|rst\) == \(syn\|rst\) drop
nft add rule inet pakkt input tcp flags fin,syn,rst,psh,ack,urg / fin,syn,rst,psh,ack,urg drop

Ces règles détectent les scans furtifs (NULL scan, XMAS scan) et les segments TCP forgés. Un paquet avec tous les flags à zéro (NULL) ou tous à un (XMAS) ne correspond à aucun handshake légitime. Le dernier cas (urg isolé) est exploité par certains bots pour contourner les firewalls naïfs.

5. Rate-limit global sur les nouvelles connexions TCP

nft add rule inet pakkt input tcp flags syn ct state new limit rate 100/second burst 200 accept

Un flood TCP SYN épuise la file de demi-connexions du noyau (net.ipv4.tcp_max_syn_backlog). Cette règle limite les SYN à 100 pps avec un burst de 200 paquets, permettant un pic temporaire (batch de connexions légitimes) tout en bloquant les floods soutenus. Ajustez le seuil selon la concurrence attendue : 50 pps pour un serveur de 50 joueurs, 200 pps pour 300+ joueurs.

6. Rate-limit par port applicatif

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

Segmentez les limites par service : Minecraft (25565/TCP) tolère 50 nouvelles connexions/s, tandis que Bedrock (19132/UDP, stateless) requiert 200 pps pour absorber les connexions mobiles en Wi-Fi instable. Pour un serveur multi-jeu, créez une règle par port critique.

7. Rate-limit par IP source avec meter

nft add rule inet pakkt input tcp dport 25565 ct state new meter ratelimit-tcp-25565 { ip saddr limit rate 10/second burst 20 } accept

Le compteur meter crée une table de hachage dynamique indexée par IP source. Chaque adresse est limitée indépendamment : un joueur légitime peut ouvrir jusqu'à 20 connexions d'un coup (burst), puis est bridé à 10/s. Cela bloque les bots distribués (botnets) sans pénaliser les joueurs derrière NAT (un second joueur sur la même IP aura son propre compteur si vous indexez par ip saddr . tcp sport).

8. Listes noires dynamiques (set ipv4_addr)

nft add set inet pakkt blacklist { type ipv4_addr \; flags dynamic,timeout \; timeout 1h \; }
nft add rule inet pakkt input ip saddr @blacklist drop

Un set nftables supporte l'ajout/suppression en temps réel via l'API netlink, sans recharger les règles. L'agent PAKKT synchronise automatiquement la blacklist IP du panel vers ce set, avec expiration automatique (1 heure par défaut). Pour ajouter manuellement une IP :

nft add element inet pakkt blacklist { 203.0.113.42 timeout 30m }

9. Whiteliste explicite pour le trafic admin

nft add set inet pakkt whitelist { type ipv4_addr \; }
nft add element inet pakkt whitelist { 192.0.2.10, 192.0.2.11 }
nft add rule inet pakkt input tcp dport 22 ip saddr @whitelist accept
nft add rule inet pakkt input tcp dport 22 drop

SSH (22/TCP) doit être réservé à vos IPs d'administration. La whitelist bypasse toutes les règles de rate-limit : même sous DDoS, vous conservez l'accès. Pour une gestion centralisée, PAKKT synchronise les whitelists depuis le panel vers tous les agents via mTLS.

10. Log et drop final

nft add rule inet pakkt input limit rate 10/minute log prefix \"[nft-drop] \" level info
nft add rule inet pakkt input drop

Tout paquet n'ayant matché aucune règle précédente est logué (max 10/min pour éviter le spam syslog) puis rejeté. Analysez journalctl -k | grep nft-drop pour identifier les scans ou ajuster les règles.

Intégration XDP + nftables : défense en profondeur

Les dix règles ci-dessus opèrent au niveau du stack réseau Linux (post-allocation skb). Sous attaque volumétrique (> 1 Mpps), le noyau passe 80 % du temps à allouer et détruire des sk_buff avant même d'évaluer les règles nftables. C'est là qu'intervient XDP (eXpress Data Path) : un hook eBPF attaché au driver réseau, qui inspecte les paquets avant allocation skb.

Le PAKKT Engine, programme XDP unique par interface, filtre en sub-microseconde selon des critères grossiers (port range, protocole, max PPS global). Seuls les paquets survivants remontent vers nftables pour l'analyse stateful. Cette répartition garantit :

• XDP : filtrage stateless, très rapide, efficace contre les floods unicast (reflection DNS, NTP, Memcached).
• nftables : filtrage stateful, conntrack, validation TCP flags, rate-limit par connexion — trop coûteux pour du Mpps.

Exemple : une attaque UDP 100 000 pps sur le port 19132 (Bedrock). Votre règle XDP bloque 95 % (port non autorisé ou max_port_pps dépassé), les 5 000 pps restants traversent nftables qui applique le meter par IP source. Résultat : CPU < 20 %, latence joueur inchangée.

Charger le programme XDP sans écraser les règles nftables

ip link set dev eth0 xdp obj pakkt_engine.bpf.o sec xdp

Un seul programme XDP par interface : si vous en chargez un second, il remplace le premier (sauf mode xdpgeneric avec chaînage manuel). L'agent PAKKT gère cette exclusivité et synchronise les BPF maps (pakkt_rules, pakkt_blacklist) avec les sets nftables pour éviter toute divergence.

Debugger les interactions XDP/nftables

bpftool map dump name pakkt_rules
nft list ruleset inet pakkt

Comparez les compteurs eBPF (bpftool prog show, champ run_cnt) aux compteurs nftables (nft list chain inet pakkt input, colonnes packets / bytes). Un écart important signale une règle XDP trop permissive ou un hook nftables manquant.

Checklist de mise en production 2026

Avant de passer en live, validez ces neuf points critiques :

1. Noyau ≥ 5.10 : support XDP natif (drivers i40e, ixgbe, mlx5). Vérifiez uname -r et ethtool -i eth0 | grep driver.
2. Modules conntrack chargés : modprobe nf_conntrack nf_conntrack_ipv4 nf_conntrack_ipv6.
3. Table inet pakkt isolée : aucune règle dans filter ou nat ne doit matcher les ports de jeu.
4. Policy accept en input : les règles drop sont explicites, pas la policy par défaut (sinon risque de lockout SSH).
5. Règle established en tête : ct state established,related accept doit être la première règle après loopback.
6. Rate-limits calibrés : testez avec hping3 -S -p 25565 --flood et vérifiez que les compteurs nft plafonnent au seuil configuré.
7. Whiteliste admin remplie : ne déployez jamais en prod sans votre IP dans @whitelist pour SSH.
8. Logs activés temporairement : log prefix sur les règles drop pendant 24 h, puis désactivez (charge I/O disque).
9. Intégration monitoring : exportez les métriques nftables vers Prometheus via nft_exporter ou le dashboard PAKKT (TimescaleDB, GeoIP, top IPs).

Éviter les conflits avec Docker et fail2ban

Docker injecte ses règles dans nat PREROUTING et filter FORWARD (table filter, priorité 100). Fail2ban ajoute dynamiquement des règles dans filter INPUT. En isolant vos règles dans inet pakkt (priorité 0), vous évaluez avant ces deux systèmes : un paquet bloqué par PAKKT ne traversera jamais les chaînes Docker/fail2ban, éliminant tout conflit.

Pour vérifier l'ordre d'évaluation :

nft -a list chains

Recherchez les hooks input et comparez les priorités : inet pakkt input priority 0 doit apparaître avant ip filter INPUT priority 100.

Au-delà de nftables : orchestration centralisée et templates communautaires

Maintenir dix règles nftables + un programme XDP sur un seul serveur est faisable manuellement. Au-delà de cinq serveurs (infrastructure multi-région, flotte de nœuds Pterodactyl), l'administration décentralisée devient ingérable : divergences de configuration, oublis de mise à jour, absence d'audit centralisé.

PAKKT.io résout ce problème en orchestrant XDP et nftables depuis un panel unique :

• Templates de règles : « Minecraft Production », « Rust Anti-Flood », « CS2 Compétitif » — un clic pour déployer les dix règles ci-dessus + configuration XDP adaptée.
• Synchronisation temps réel : modification d'une règle dans le panel → propagation via mTLS vers tous les agents en < 30 s (heartbeat), rechargement atomique sans coupure.
• Marketplace communautaire : partagez vos templates XDP/nft, importez ceux testés par d'autres hébergeurs (ex. « Protection Palworld », « DayZ UDP Hardening »).
• Audit log : historique complet des modifications (qui, quand, quelle règle), export JSON pour conformité RGPD/ISO 27001.

L'API publique PAKKT (clé API générée depuis le panel) permet l'intégration CI/CD : déployez automatiquement un template nftables lors du provisionning d'un nouveau serveur de jeu via Terraform ou Ansible.

Conclusion

Les dix règles nftables serveur jeu présentées — table isolée, conntrack, TCP flags, rate-limit global/par-port/par-IP, whiteliste SSH, logging — forment le socle de toute infrastructure résiliente en 2026. Couplées à un programme XDP en amont, elles absorbent les floods volumétriques tout en préservant la latence sub-milliseconde exigée par les joueurs. L'orchestration centralisée via PAKKT.io élimine les erreurs humaines et accélère la réponse aux nouvelles menaces, transformant votre firewall kernel en rempart vivant et auditable.

FAQ

Puis-je charger plusieurs programmes XDP sur la même interface pour segmenter les règles par port ?

Non, une interface réseau ne supporte qu'un seul programme XDP en mode natif. Si vous chargez un second programme, il remplace le premier. La solution consiste à utiliser un programme XDP unique (comme le PAKKT Engine) piloté par des BPF maps contenant jusqu'à 256 règles simultanées, chacune ciblant un port range ou protocole spécifique. Cela garantit l'atomicité du filtrage et évite les race conditions.

Comment calibrer les seuils de rate-limit (50, 100, 200 pps) pour mon serveur ?

Mesurez d'abord le trafic légitime en production : nft list chain inet pakkt input après 24 h vous donne les compteurs par règle. Divisez le nombre de paquets par 86 400 pour obtenir le pps moyen, multipliez par 2-3 pour absorber les pics. Testez ensuite avec hping3 --flood ou mz depuis une IP externe : le seuil est correct si 99 % du trafic légitime passe et 95 % du flood est bloqué. Ajustez itérativement.

Les règles nftables entrent-elles en conflit avec un scrubbing cloud (OVH Game DDoS, Cloudflare) ?

Non, les deux couches sont complémentaires. Le scrubbing cloud filtre en amont (dans le datacenter du fournisseur) les attaques volumétriques > 10 Gbps avant qu'elles n'atteignent votre serveur. Nftables + XDP protègent ensuite contre les attaques résiduelles (< 10 Gbps) et les menaces applicatives (scans de port, exploitation de bugs du moteur de jeu). Déployez toujours les deux : le scrubbing absorbe la volumétrie brute, PAKKT affine le filtrage au plus près du kernel.