Serveur 7 Days to Die : comment absorber un SYN flood sans crasher ?

Le SYN flood sur 7 Days to Die fait partie des attaques DDoS par volume les plus fréquentes contre les serveurs de jeu multijoueur. En exploitant la phase de handshake TCP à trois voies, un attaquant envoie des milliers de requêtes SYN incomplètes pour saturer la table de connexions du noyau Linux et rendre le serveur injoignable. Dans ce guide 2026, nous décortiquons les mécanismes précis du SYN flood appliqué à 7 Days to Die, les symptômes observables et les contre-mesures kernel-level (XDP, eBPF, nftables) qui permettent de filtrer ces flux malveillants avant qu'ils n'atteignent la pile TCP. Vous apprendrez à diagnostiquer l'attaque via les métriques système, à durcir votre configuration réseau et à déployer une protection automatisée pour garantir la continuité de votre serveur.

Comprendre le SYN flood : mécanique de l'attaque sur 7 Days to Die

Le protocole TCP établit une connexion via un handshake à trois étapes : SYN (client), SYN-ACK (serveur), ACK (client). Lors d'un SYN flood, l'attaquant envoie un déluge de paquets SYN avec des adresses IP sources souvent usurpées, sans jamais compléter l'ACK final. Le serveur 7 Days to Die, qui écoute par défaut sur le port TCP 26900, alloue une entrée dans sa table de connexions semi-ouvertes (half-open connections) pour chaque SYN reçu. Cette table possède une taille finie définie par net.ipv4.tcp_max_syn_backlog dans /etc/sysctl.conf. Une fois saturée, le serveur rejette toute nouvelle connexion légitime.

Sur 7 Days to Die, les symptômes typiques sont les suivants :

• Impossible de se connecter au serveur via le client Steam (timeout après ~20 secondes).
• Console serveur affiche « Too many open files » ou « Cannot allocate memory ».
• Commande ss -tan | grep SYN_RECV | wc -l renvoie plusieurs milliers de lignes.
• CPU du processus 7DaysToDieServer.x86_64 reste bas, mais la latence réseau explose (>500 ms).
• Graphiques bande passante montrent un pic soudain en paquets entrants (plusieurs dizaines de milliers de pps) sans pic correspondant en bande passante sortante.

L'attaque peut provenir d'un botnet distribué ou d'un simple script Python utilisant Scapy pour forger des paquets SYN avec IP source aléatoire. La volumétrie varie de 10 000 pps (attaque artisanale) à plusieurs millions de pps (botnet professionnel). Le serveur de jeu, qui tourne en espace utilisateur, subit la saturation avant même que le noyau Linux ne puisse appliquer des règles de filtrage classiques (iptables, nftables hors XDP).

Diagnostic kernel-level : identifier le SYN flood en temps réel

Pour confirmer un SYN flood actif, connectez-vous en SSH sur votre serveur Linux et exécutez :

ss -tan | grep SYN_RECV | head -n 20
netstat -s | grep -i "SYNs to LISTEN"
cat /proc/net/sockstat

Si TCP: inuse dépasse plusieurs milliers alors que vous n'avez que quelques dizaines de joueurs connectés, l'attaque est confirmée. Vérifiez ensuite les métriques XDP si vous utilisez déjà un programme BPF :

bpftool prog show
bpftool map dump name pakkt_stats

Ces commandes affichent le nombre de paquets traités par le hook XDP et les compteurs par action (XDP_DROP, XDP_PASS). Un ratio XDP_DROP élevé indique que le filtrage kernel bloque effectivement le flood.

Durcir la configuration système : sysctl et nftables stateful

Avant de déployer XDP/eBPF, commencez par optimiser les paramètres kernel TCP pour limiter l'impact d'un SYN flood. Éditez /etc/sysctl.conf et ajoutez les directives suivantes :

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_timestamps = 0

Appliquez immédiatement via sysctl -p. Le paramètre tcp_syncookies active un mécanisme de défense qui encode les informations de connexion dans le SYN-ACK lui-même, évitant ainsi l'allocation d'une entrée dans la table tant que l'ACK final n'est pas reçu. Cela permet de survivre à des attaques modérées (jusqu'à ~50 000 pps) sans filtrage additionnel.

Règle nftables pour rate-limit TCP SYN par IP source

Complétez le durcissement avec une règle nftables stateful exploitant ct state et un meter dynamique. PAKKT déploie automatiquement une table isolée inet pakkt qui coexiste sans conflit avec Docker, fail2ban ou iptables-persistent. Voici un exemple de règle manuelle équivalente :

nft add table inet pakkt
nft add chain inet pakkt input { type filter hook input priority filter \; policy accept \; }
nft add rule inet pakkt input tcp dport 26900 ct state new meter syn_limit { ip saddr limit rate over 10/second } drop
nft add rule inet pakkt input tcp dport 26900 tcp flags syn ct state new limit rate 100/second accept

Cette règle autorise 10 nouvelles connexions SYN par seconde par adresse IP source, et limite le débit global à 100 SYN/s. Au-delà, les paquets sont droppés avant d'atteindre l'application 7 Days to Die. Le meter nftables conserve l'état en mémoire kernel et réinitialise automatiquement les compteurs après expiration du quota.

Pour vérifier la règle active :

nft list table inet pakkt

Vous devriez observer des compteurs de paquets et de bytes incrémentés à chaque requête SYN bloquée. Cette approche stateful est efficace jusqu'à ~500 000 pps ; au-delà, seul un hook XDP peut traiter le volume sans dégradation de latence.

Protection XDP/eBPF : filtrage stateless à plusieurs millions de pps

Pour survivre aux attaques de grande envergure (>1 Mpps), vous devez intervenir au plus tôt dans la pile réseau, avant même l'allocation du sk_buff. XDP (eXpress Data Path) exécute un programme eBPF directement dans le driver réseau, permettant de décider du sort d'un paquet en sub-microseconde. PAKKT.io fournit un moteur XDP pré-compilé (PAKKT Engine) qui charge un unique programme BPF par interface physique et gère jusqu'à 256 règles simultanées via des BPF maps.

Architecture du PAKKT Engine pour 7 Days to Die

Le PAKKT Engine expose une BPF map de type BPF_MAP_TYPE_ARRAY contenant les règles actives. Chaque règle définit :

• Port range : ex. 26900-26900 pour 7 Days to Die.
• Protocole : TCP, UDP, ICMP ou any.
• Rule type : block, rate_limit (pps global), allow_only.
• Max PPS global : plafond de paquets par seconde toutes sources confondues.
• Max port PPS : plafond par port destination.
• Min/max packet size : filtrer les paquets anormalement petits (<64 bytes) ou géants (>1500 bytes).

Pour bloquer un SYN flood ciblant le port 26900, configurez une règle de type rate_limit avec max_port_pps = 50000 et protocol = TCP. Le programme eBPF inspecte le header TCP, détecte le flag SYN et incrémente un compteur atomique partagé dans une BPF map de type BPF_MAP_TYPE_PERCPU_ARRAY. Si le quota est dépassé, l'action XDP_DROP est retournée immédiatement, sans traverser la pile réseau.

L'agent PAKKT, écrit en Go et obfusqué via Garble, synchronise les règles depuis le panel centralisé toutes les 30 secondes (heartbeat mTLS). Toute modification de règle dans le dashboard est propagée automatiquement et appliquée sans redémarrage du serveur de jeu. L'impact CPU de l'agent reste <1 %, la consommation mémoire <5 MB.

Commandes manuelles pour inspecter le programme XDP

Si vous souhaitez vérifier quel programme XDP est attaché à votre interface réseau :

ip link show dev eth0
bpftool net show dev eth0
bpftool prog show

Pour dumper les statistiques de la BPF map pakkt_stats :

bpftool map dump name pakkt_stats

Vous y trouverez le nombre total de paquets traités (XDP_PASS, XDP_DROP) et le compteur par règle. Ces métriques sont également remontées en temps réel dans le dashboard PAKKT, avec une granularité TimescaleDB (1 seconde) et des graphiques par port/règle.

Blacklist / Whitelist IP double couche

PAKKT expose une fonctionnalité de blacklist et whitelist IP synchronisée sur deux couches : une BPF map LPM_TRIE pour le lookup XDP, et une règle nftables ip saddr @blacklist drop pour le fallback stateful. Ajouter une IP à la blacklist dans le panel PAKKT met à jour instantanément les deux structures. Cela garantit que même si un paquet contourne la vérification XDP (cas rare sur certaines NICs anciennes), il sera bloqué par nftables.

Pour ajouter manuellement une IP à la blacklist XDP :

bpftool map update name pakkt_blacklist key hex 0a 00 00 01 value hex 01

(Exemple : 10.0.0.1 encodé en big-endian). Le panel PAKKT automatise cette opération via l'API publique, permettant par exemple d'intégrer des scripts de détection d'anomalie ou des feeds Threat Intelligence tiers.

Déploiement pratique : protéger 7 Days to Die en 5 minutes

Voici un workflow complet pour déployer PAKKT sur un serveur 7 Days to Die hébergé chez votre fournisseur préféré (OVH, Hetzner, Scaleway, etc.). Prérequis : Linux kernel 5.x ou supérieur, architecture x86_64, droits root.

Étape 1 : Inscription et récupération de la clé agent

Créez un compte sur PAKKT.io (essai gratuit 7 jours sur le premier agent). Dans l'onglet Agents, cliquez sur « Add Agent » et notez la clé API générée (format UUID). Cette clé permet l'authentification mTLS entre l'agent et le backend PAKKT.

Étape 2 : Installation de l'agent

Connectez-vous en SSH sur votre serveur et exécutez :

curl -sSL https://install.pakkt.io/agent.sh | sudo bash -s -- --key VOTRE_CLE_API

Le script télécharge le binaire Go obfusqué, vérifie le SHA256, l'installe dans /usr/local/bin/pakkt-agent et active le service systemd pakkt-agent.service. L'agent détecte automatiquement votre interface réseau principale (eth0, ens3, etc.) et attache le PAKKT Engine XDP en mode SKB (compatible toutes NICs) ou NATIVE (meilleure performance sur Mellanox, Intel i40e).

Étape 3 : Créer une règle anti-SYN flood

Dans le panel PAKKT, naviguez vers Rules > Add Rule. Configurez :

• Port range : 26900-26900
• Protocol : TCP
• Rule type : rate_limit
• Max port PPS : 50000 (ajustez selon votre trafic légitime)
• Min packet size : 40 (header TCP SYN minimal)
• Max packet size : 1500

Sauvegardez. La règle est propagée à l'agent en moins de 30 secondes et appliquée sans interruption de service. Vérifiez dans l'onglet Metrics que les compteurs packets_passed et packets_dropped évoluent correctement.

Étape 4 : Compléter avec une règle nftables stateful

Pour ajouter une couche de défense en profondeur, activez le firewall nftables dans PAKKT (onglet Firewall > Enable). Le panel génère automatiquement une table inet pakkt avec des règles conntrack :

nft add rule inet pakkt input tcp dport 26900 ct state established,related accept
nft add rule inet pakkt input tcp dport 26900 ct state new meter syn_limit { ip saddr limit rate over 10/second } drop
nft add rule inet pakkt input tcp dport 26900 ct state new tcp flags syn limit rate 100/second accept

Cette configuration coexiste avec Docker (table nat), fail2ban (table filter) et toute règle iptables-persistent existante. PAKKT utilise une priorité filter standard et ne modifie jamais les autres tables.

Étape 5 : Monitoring en temps réel

Retournez sur le dashboard PAKKT. Vous disposez de :

• Carte monde GeoIP montrant les pays sources des paquets droppés.
• Top 10 IPs sources bloquées (mise à jour toutes les 10 secondes).
• Graphique TimescaleDB par port/règle (résolution 1 seconde, rétention 30 jours).
• Logs internes de l'agent (niveau debug disponible via l'API).
• Audit log des modifications de règles (qui, quand, quelle règle).

En cas d'attaque, vous observerez un pic de packets_dropped dans le graphique XDP et une liste d'IPs sources géographiquement distribuées (botnet). Ajoutez les /24 ou /16 malveillants à la blacklist PAKKT pour un blocage permanent.

Intégration avec Pterodactyl

Si vous gérez 7 Days to Die via Pterodactyl v1.x, PAKKT propose une intégration native qui injecte un onglet « Protection » dans chaque instance de serveur. Vos utilisateurs peuvent activer/désactiver des règles XDP prédéfinies (templates marketplace) sans accès SSH. L'intégration fonctionne via webhook Pterodactyl et clé API PAKKT, avec un mappage automatique port → allocation Pterodactyl.

Stratégies avancées : combiner XDP, nftables et scrubbing cloud

PAKKT fournit une protection kernel-level sur le serveur lui-même, ce qui signifie que les paquets malveillants atteignent tout de même votre interface réseau physique. Pour les attaques dépassant la capacité de votre uplink (ex. 100 Gbps sur un serveur dédié 1 Gbps), vous devez combiner PAKKT avec un scrubbing cloud en amont.

Architecture hybride : scrubbing + PAKKT

Schéma recommandé :

1. Couche 1 : Scrubbing cloud (CloudFlare Spectrum, OVH VAC, Arbor Networks) filtre les attaques volumétriques (>10 Gbps) avant qu'elles n'atteignent votre datacenter. Le trafic légitime est routé via GRE/IPIP tunnel ou Anycast vers votre IP serveur.
2. Couche 2 : XDP PAKKT traite les flux qui passent le scrubbing (attaques sous le seuil de détection cloud, floods applicatifs spécifiques à 7 Days to Die). Rate-limit par port, par IP source, par taille de paquet.
3. Couche 3 : nftables stateful PAKKT applique des règles conntrack (ex. limit rate par connexion TCP établie) et gère les listes noires dynamiques.
4. Couche 4 : Application 7 Days to Die reçoit uniquement le trafic légitime, sans overhead de filtrage.

Cette approche garantit une résilience maximale. PAKKT ne remplace pas un scrubbing cloud (qui absorbe la volumétrie brute), mais empêche les attaques ciblées de type « low and slow » ou les floods exploitant des failles protocolaires (ex. malformed TCP options) qui passent souvent sous le radar des WAF génériques.

Métriques de performance PAKKT en production

D'après les retours terrain de nos utilisateurs hébergeant 7 Days to Die :

• Sans PAKKT : serveur injoignable sous 20 000 pps de SYN flood (tcp_max_syn_backlog saturé).
• Avec PAKKT (XDP + nftables) : tient jusqu'à ~2 Mpps de SYN flood sur une NIC Intel X710 10 Gbps, latence ajoutée <10 µs par paquet.
• Impact CPU de l'agent PAKKT : 0,3 % sur un Xeon E-2388G 8c/16t sous charge.
• Consommation RAM de l'agent : 4,2 MB (mesurée via ps aux).

Ces chiffres dépendent du hardware (CPU, NIC) et de la complexité des règles XDP. Pour des serveurs avec plusieurs dizaines de ports ouverts et des centaines de règles, privilégiez un kernel 6.x avec support eBPF CO-RE (Compile Once, Run Everywhere) pour optimiser les lookups BPF map.

Automatisation via API publique PAKKT

PAKKT expose une API REST (clé API, rate-limit 1000 req/h) permettant de créer/modifier/supprimer règles XDP, blacklist/whitelist IP, et récupérer les métriques temps réel. Exemple d'ajout automatique d'une IP à la blacklist depuis un script Python :

import requests

headers = {"Authorization": "Bearer VOTRE_CLE_API"}
payload = {"ip": "203.0.113.42", "reason": "SYN flood detected"}
r = requests.post("https://api.pakkt.io/v1/blacklist", json=payload, headers=headers)
print(r.json())

Vous pouvez intégrer cet endpoint dans vos outils de monitoring (Prometheus, Grafana Alerting, Zabbix) pour bannir automatiquement les IPs dépassant un seuil de paquets suspects. Le délai de propagation agent ↔ backend est <30 secondes (heartbeat mTLS).

Conclusion

Survivre à un SYN flood sur 7 Days to Die nécessite une défense multi-couches combinant durcissement kernel (sysctl, tcp_syncookies), filtrage stateful (nftables conntrack + meter) et traitement XDP/eBPF pour absorber les volumétries extrêmes. PAKKT.io centralise ces mécanismes dans une interface unifiée, automatise le déploiement des règles et fournit un monitoring temps réel des menaces. Avec un coût de 3€/agent/mois et un essai gratuit 7 jours, vous éliminez les interruptions de service sans migrer d'hébergeur ni investir dans du hardware dédié anti-DDoS.

FAQ

Quelle différence entre tcp_syncookies et une règle XDP pour bloquer un SYN flood sur 7 Days to Die ?

Les tcp_syncookies (kernel Linux) évitent l'allocation d'une entrée dans la table de connexions tant que le handshake TCP n'est pas complet, ce qui permet de survivre à des attaques modérées (~50k pps). Une règle XDP PAKKT intervient avant la pile TCP, au niveau du driver réseau, et peut filtrer plusieurs millions de pps avec une latence sub-microseconde. Les deux mécanismes sont complémentaires : tcp_syncookies protège contre les floods légers, XDP absorbe les volumétries extrêmes.

PAKKT peut-il bloquer un SYN flood si l'attaque sature mon uplink 1 Gbps ?

Non. PAKKT filtre les paquets sur le serveur, après qu'ils aient traversé votre uplink. Si l'attaque dépasse la capacité physique de votre lien (ex. 10 Gbps sur un uplink 1 Gbps), vous devez combiner PAKKT avec un scrubbing cloud en amont (CloudFlare, OVH VAC) qui absorbe la volumétrie brute avant routage vers votre IP. PAKKT traite ensuite les flux résiduels (low and slow, attaques applicatives spécifiques).

Combien de règles XDP puis-je activer simultanément sur un même port 7 Days to Die ?

Le PAKKT Engine supporte jusqu'à 256 règles simultanées par interface réseau, toutes ports confondus. Vous pouvez empiler plusieurs règles sur le port 26900 (ex. rate_limit global, rate_limit par IP via blacklist, min/max packet size). Chaque règle est évaluée séquentiellement dans le programme eBPF ; au-delà de 100 règles actives, privilégiez des regroupements par plages de ports ou des templates marketplace pour optimiser les performances.