Protection DDoS de serveur de jeu : stratégie en couches

Une attaque DDoS de serveur de jeu commence lorsqu'un trafic malveillant sature la bande passante ou la capacité de traitement de votre serveur, excluant les vrais joueurs. Que vous fassiez tourner Metin2, Minecraft ou votre propre serveur en C++, une solution durable ne repose jamais sur un seul outil — elle repose sur des couches qui se superposent. Dans ce guide, nous construisons une ligne de défense concrète, du fournisseur anti-DDoS jusqu'aux règles de pare-feu au niveau du noyau.

Comment les attaques DDoS ciblent les serveurs de jeu

Le trafic de jeu exige généralement une faible latence et circule via UDP, ce qui ouvre deux vecteurs classiques pour les attaquants :

• Attaques volumétriques : les floods UDP et l'amplification DNS/NTP saturent votre lien à l'échelle du Gbps. Vous ne pouvez pas les arrêter sur le serveur lui-même ; le trafic doit être nettoyé en amont.
• Attaques protocolaires : les floods SYN et ACK épuisent les tables de connexions et la capacité de votre conntrack.
• Attaques applicatives : des paquets de login falsifiés ou des requêtes visant les points faibles de votre protocole — elles peuvent étouffer le CPU même à faible bande passante.

Une défense correcte traite chaque vecteur à sa propre couche. Croire qu'une seule règle iptables résoudra tout est l'erreur la plus courante.

Couche une : un fournisseur anti-DDoS

Contre les attaques volumétriques, la seule défense réaliste est de se placer derrière un fournisseur disposant d'une capacité de nettoyage suffisante. OVH/So you Start, Path.net et les fournisseurs de tunnels GRE orientés jeu acheminent le trafic via leurs propres centres de nettoyage et ne transmettent que les paquets propres à votre serveur.

Pour choisir un fournisseur, examinez :

• Capacité de nettoyage (Tbps) : ce qui compte, c'est la protection allouée à une seule IP, pas le total affiché.
• Connaissance du protocole de jeu : les filtres HTTP/TCP génériques peuvent rejeter le trafic UDP de jeu comme faux positif. Des solutions orientées jeu comme Path.net offrent des règles sur mesure.
• Latence : comme le trafic passe par un centre de nettoyage, quelques ms de latence supplémentaire sont normales ; choisissez un PoP géographiquement proche de vos joueurs.

Cloudflare Spectrum est une bonne option pour les jeux basés sur TCP et les protocoles proxyables, mais les serveurs de jeu UDP bruts nécessitent généralement un arrangement personnalisé.

Couche deux : durcissement du noyau et du pare-feu

Même si le fournisseur nettoie le trafic volumétrique, le serveur lui-même doit être durci contre les attaques protocolaires. La première étape contre les floods SYN est d'activer les SYN cookies :

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=2048
sysctl -w net.core.somaxconn=1024

Pour éviter que la table de suivi des connexions (conntrack) ne déborde, augmentez sa capacité :

sysctl -w net.netfilter.nf_conntrack_max=262144

Pour rendre ces valeurs persistantes, inscrivez-les dans /etc/sysctl.d/99-ddos.conf et appliquez avec sysctl --system.

Couche trois : limites de débit et de connexions

Plafonner les connexions vers votre port de jeu par IP source filtre les attaques protocolaires de faible volume. Avec nftables, limiter les connexions simultanées et le taux de nouvelles connexions par IP est une approche propre :

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif "lo" accept
    # Rejeter plus de 30 connexions simultanees par IP
    tcp dport 30000 ct count over 30 drop
    # Limiter a 20 nouvelles connexions par seconde
    tcp dport 30000 ct state new limit rate over 20/second drop
    tcp dport 30000 accept
  }
}

Si vous préférez le iptables classique, la même logique se construit avec les modules connlimit et hashlimit :

iptables -A INPUT -p tcp --dport 30000 -m connlimit --connlimit-above 30 -j DROP
iptables -A INPUT -p tcp --dport 30000 -m hashlimit \
  --hashlimit-mode srcip --hashlimit-above 20/sec \
  --hashlimit-name game -j DROP

Pour les serveurs de jeu UDP, vous pouvez limiter le débit de paquets avec hashlimit, mais ajustez les seuils au comportement réel des joueurs ; des limites trop agressives coupent le trafic légitime.

Couche quatre : filtres applicatifs et comportementaux

Les attaques les plus sournoises sont des paquets qui paraissent valides mais sollicitent la logique de votre serveur. Ici la défense doit vivre dans l'application :

• Limitation des connexions (login throttling) : limitez les tentatives de connexion acceptées depuis la même IP par unité de temps.
• Liste d'autorisation : n'exposez les ports d'administration (SSH, MySQL, panneau) qu'aux IP connues, tout en gardant le port de jeu public.
• fail2ban : utilisez-le pour détecter les comportements anormaux dans les logs et bannir automatiquement les IP attaquantes. Avec un filtre et une jail personnalisés, vous pouvez le relier aux logs de votre serveur de jeu.
• Validation des paquets : dans votre protocole, rejetez tôt les paquets invalides ou incomplets pendant le handshake ; ne gaspillez pas le CPU à les traiter.

Surveillance : voir l'attaque tôt

La visibilité compte autant que la défense. Surveillez la bande passante avec vnstat et les connexions en direct avec iftop ; pour une installation plus permanente, déployez Prometheus + Grafana ou simplement Netdata. Détecter tôt un trafic anormal permet d'ajuster les règles pendant que l'attaque est en cours. Vous pouvez aussi vérifier instantanément le nombre de connexions actives avec conntrack -L | wc -l.

Questions fréquentes

Puis-je me protéger d'un DDoS avec iptables seul ?

Non. iptables est efficace contre les attaques protocolaires et de faible volume, mais il ne peut pas arrêter une attaque volumétrique qui sature votre lien sur le serveur lui-même — une fois que les paquets atteignent votre interface réseau, le mal est fait. La protection volumétrique doit se faire en amont, au niveau du fournisseur.

Cloudflare protégera-t-il mon serveur de jeu ?

Le proxy standard de Cloudflare est destiné au HTTP/HTTPS et ne fait pas passer le trafic de jeu brut. Les protocoles TCP/UDP de jeu nécessitent un produit distinct comme Cloudflare Spectrum, qui demande généralement un forfait payant ou un arrangement personnalisé.

Quelle doit être la limite de débit pour le port de jeu ?

Il n'y a pas de valeur fixe ; cela dépend de votre nombre de joueurs et de votre protocole. Mesurez d'abord le trafic normal avec iftop et conntrack, fixez un seuil nettement au-dessus du taux moyen de connexions, puis resserrez progressivement en confirmant l'absence de faux positifs.

Votre serveur est-il attaqué, ou souhaitez-vous mettre en place une protection durable ? Du choix d'un fournisseur anti-DDoS au durcissement du pare-feu, nous pouvons construire ensemble la ligne de défense de votre serveur de jeu. Contactez-moi.