Protection DDoS Metin2 : firewall, proxy et mitigation

L'une des causes les plus fréquentes de panne d'un serveur privé n'est pas un bug de code mais une attaque extérieure ; c'est pourquoi une bonne protection DDoS Metin2 est un sujet à planifier avant l'ouverture, pas après la première coupure. Une attaque DDoS (déni de service distribué) inonde votre ligne ou votre processeur de trafic factice provenant de multiples sources, si bien que les joueurs légitimes ne peuvent plus se connecter. Comme l'architecture Metin2 est composée de plusieurs services TCP (auth, cores de jeu/channel, db), la protection n'est jamais un outil unique mais une défense en couches : nettoyage au niveau réseau, firewall sur la machine, proxy qui masque l'IP réelle et contrôle des flux au niveau applicatif.

Connaître la menace : les types d'attaques visant Metin2

Pour bâtir la bonne défense, il faut savoir où l'attaque frappe. Les attaques contre les serveurs Metin2 se répartissent grosso modo en trois groupes :

• Attaques volumétriques : les UDP floods et l'amplification (réflexion DNS/NTP) saturent votre ligne à l'échelle du Gbps. La seule réponse réaliste est une couche de nettoyage (scrubbing) en amont devant le serveur ; l'iptables d'un seul VPS ne peut pas filtrer 50 Gbps, car la ligne est saturée avant même que le trafic n'atteigne la machine.
• Attaques protocolaires : les SYN floods et ACK floods ciblent la table de connexions (conntrack) et la poignée de main TCP. Une grande partie peut être atténuée par un firewall sur la machine.
• Attaques applicatives : ouverture et fermeture incessantes de connexions TCP sur le port de jeu ou d'auth, et spam de login/register. Elles peuvent occuper le core de jeu même à faible bande passante, et demandent donc un contrôle distinct.

La règle d'or : les attaques volumétriques se bloquent en amont, hors du serveur ; les attaques protocolaires et applicatives se filtrent sur la machine.

Séparer l'architecture : n'exposez jamais auth et db

La façon la moins coûteuse de réduire votre surface d'attaque est de n'ouvrir à l'internet que les ports réellement nécessaires. Sous Metin2, seuls les ports de jeu (channel) et le port d'auth doivent être joignables de l'extérieur pour qu'un joueur se connecte. Le service db (cache de base de données), MySQL et les panneaux GM/web doivent rester fermés au monde extérieur ; accédez-y uniquement via le réseau local ou un tunnel SSH.

En pratique, cela revient à fixer la politique par défaut sur « tout refuser » et à n'ouvrir que le nécessaire :

# Linux / iptables — approche liste blanche de base
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Ouvrir SSH uniquement depuis votre propre IP
iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT

# Ports ouverts aux joueurs (exemple : auth + deux channels)
iptables -A INPUT -p tcp --dport 11002 -j ACCEPT   # auth
iptables -A INPUT -p tcp --dport 13000 -j ACCEPT   # ch1
iptables -A INPUT -p tcp --dport 13001 -j ACCEPT   # ch2

Les numéros de port varient selon vos propres fichiers CONFIG ; ici l'essentiel n'est pas le port lui-même mais le principe : « ne pas l'ouvrir tant qu'on n'en a pas besoin ».

Atténuer les attaques protocolaires avec le firewall

Un firewall sur la machine ne peut pas stopper une attaque volumétrique, mais il réduit fortement les attaques protocolaires comme les SYN floods et les floods de connexions. Sous Linux, les principales mesures avec iptables sont :

# Jeter les paquets invalides
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

# Limite de débit contre le SYN flood
iptables -A INPUT -p tcp --syn -m limit --limit 60/s --limit-burst 100 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

# Limiter les connexions simultanées par IP (port de jeu)
iptables -A INPUT -p tcp --dport 13000 \
  -m connlimit --connlimit-above 30 --connlimit-mask 32 -j REJECT

En complément, activer les SYN cookies au niveau du noyau améliore la résistance aux floods de poignée de main : sysctl -w net.ipv4.tcp_syncookies=1. Sur les installations FreeBSD classiques, pf fait le même travail avec une syntaxe plus lisible :

# FreeBSD / pf — limite de débit et de connexions + liste noire automatique
table <abusers> persist
block in quick from <abusers>

pass in proto tcp to port 13000 keep state \
  (max-src-conn 30, max-src-conn-rate 10/5, \
   overload <abusers> flush global)

Ici max-src-conn-rate 10/5 place dans la table abusers toute IP qui ouvre plus de 10 nouvelles connexions en 5 secondes et coupe aussi ses connexions existantes. C'est très efficace contre les bots de flood simples qui se connectent et se déconnectent en rafale.

Masquer l'IP réelle : architecture proxy / tunnel

Les attaquants frappent généralement l'IP de votre serveur en direct ; si vous les empêchez de la découvrir, l'attaque volumétrique perd sa cible. L'approche consiste à séparer l'IP publique que voient les joueurs du vrai serveur (origin) où tourne le core de jeu :

• Un front-end protégé (proxy) : vous montez un proxy TCP ou un tunnel GRE chez un hébergeur qui nettoie le DDoS (par exemple des hôtes proposant de l'anti-DDoS comme OVH). Les joueurs se connectent uniquement à cette IP protégée, et le proxy transfère le trafic vers le vrai serveur backend.
• Verrouillez l'origin : le firewall du vrai serveur ne doit accepter le trafic vers les ports de jeu que depuis l'IP du proxy. Cette règle est cruciale, car dès que l'IP origin fuite, l'attaque peut la viser directement.

Pour un simple relais TCP, HAProxy est un choix courant :

# haproxy.cfg — relayer auth et un channel vers le backend
frontend ft_game
    mode tcp
    bind *:13000
    default_backend bk_game

backend bk_game
    mode tcp
    server core1 10.10.0.5:13000 check

Côté origin, ne faites confiance qu'au proxy :

# Firewall origin : seule l'IP du proxy peut atteindre le port de jeu
iptables -A INPUT -p tcp --dport 13000 -s 198.51.100.7 -j ACCEPT
iptables -A INPUT -p tcp --dport 13000 -j DROP

Une mise en garde importante : derrière un proxy TCP, l'IP réelle d'un joueur apparaît au backend comme l'IP du proxy. Si votre système de ban/log est basé sur l'IP, envisagez le support du PROXY protocol pour transporter l'IP réelle ; sinon, tous les joueurs sembleront venir d'une seule IP.

Couche applicative : limiter le rythme de login et de connexion

Le firewall et le proxy filtrent le trafic réseau, mais le core de jeu lui-même doit aussi être protégé contre des requêtes qui « paraissent valides » tout en étant malveillantes. Mesures pratiques :

• Connexions par seconde : si des dizaines de connexions auth arrivent de la même IP en quelques secondes, ralentissez-les avec le module connlimit/recent.
• Limite de login/register : plafonnez le nombre de tentatives par IP sur le formulaire d'inscription web et côté auth ; cela stoppe tôt un attaquant qui crée une marée de comptes.
• Surveillance : guettez les pics anormaux de connexions/bande passante avec des outils comme ss -s, netstat -an | grep SYN_RECV | wc -l et vnstat ; repérer une attaque tôt raccourcit votre temps de réaction.

Enfin, pensez à rendre vos règles persistantes avec iptables-save / pfctl et à garder prêt un plan d'urgence (fermer temporairement un port de channel pendant une attaque, changer l'IP du proxy).

Questions fréquentes

Puis-je stopper un gros DDoS avec iptables sur un seul VPS ?

Non. Les attaques volumétriques (à l'échelle du Gbps) saturent votre ligne avant d'atteindre le serveur, alors qu'iptables ne traite un paquet qu'une fois arrivé sur la machine. Pour de telles attaques, il faut un hébergeur effectuant un nettoyage en amont devant le serveur, ou un proxy anti-DDoS. iptables/pf sont précieux pour réduire les attaques protocolaires et de connexion.

Un proxy augmente-t-il le ping des joueurs ?

Comme vous routez le trafic par un saut intermédiaire, une petite latence ajoutée est normale. Pour la minimiser, placez le proxy géographiquement proche à la fois de vos joueurs et du serveur origin ; sur un tunnel bien conçu, la différence n'est généralement que de quelques millisecondes.

Que faire si mon IP réelle fuite ?

Si vous avez laissé le firewall origin ouvert uniquement à l'IP du proxy, une fuite seule ne facilite pas une attaque, mais le plus sûr reste de changer l'IP du serveur origin (obtenir une nouvelle IP chez l'hébergeur) et de rejeter tout le trafic arrivant par l'ancienne.

Vous voulez configurer votre serveur correctement contre les attaques dès le premier jour ? Planifions ensemble le firewall, l'architecture proxy et la configuration côté Metin2 — contactez-moi.