Protéger un serveur Lineage 2 des attaques DDoS

Un serveur Lineage 2 privé sur lequel personne ne passe plus l'écran de connexion le soir, alors que les joueurs déjà présents dans le monde continuent de jouer sans être dérangés, n'a pas de problème de matériel. C'est l'empreinte typique d'une attaque DDoS contre le serveur de login, et c'est exactement là qu'une protection DDoS pour Lineage 2 doit agir. Cet article montre d'abord ce que vous pouvez sécuriser vous-même sans frais supplémentaires, ensuite où ces mesures s'arrêtent techniquement, et pour finir ce qui doit alors se passer dans le réseau, en amont du serveur.

Toutes les indications se rapportent à L2J et à ses dérivés (L2J-Mobius, aCis) sous Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS, ainsi qu'aux paquets L2OFF avec AuthD, CacheD et L2Server. Les commandes sont écrites pour root ; en tant qu'utilisateur normal, faites-les précéder de sudo.

Si l'attaque est en cours : ne modifiez rien à la configuration maintenant et ne redémarrez ni le serveur de login ni le serveur de jeu. Sauvegardez d'abord vos mesures (voir la section « Journaliser »), après l'attaque elles auront disparu.

Protéger un serveur Lineage 2 du DDoS : pourquoi les serveurs L2 privés sont attaqués

Un serveur Lineage 2 privé réunit plusieurs caractéristiques qui en font une cible commode, et la protection DDoS pour Lineage 2 doit s'attaquer précisément à ces caractéristiques. D'abord, votre adresse est publique, et elle l'est dès le départ : les joueurs téléchargent un dossier System modifié, et dans son fichier l2.ini figure la ligne ServerAddr= avec l'adresse IP de votre serveur de login. Quiconque a installé votre projet une fois connaît cette adresse, qu'il ait créé un personnage ou non.

Ensuite, la communauté de joueurs est liée à des horaires fixes. Les sièges, les raid boss épiques et les événements figurent au calendrier, et une panne à cette heure précise est visible au maximum. Enfin, les projets sont en concurrence directe les uns avec les autres : celui qui ouvre un serveur courtise les mêmes quelques milliers de joueurs que trois autres projets le même week-end. Mettre un concurrent hors service est une stratégie courante dans ce milieu. Une attaque s'y commande comme un service (dans le milieu, cela s'appelle un booter ou un stresser) et ne coûte au donneur d'ordre ni compétence particulière ni argent notable. Ce qu'est précisément une attaque DDoS, l'article Qu'est-ce qu'une attaque DDoS ? l'explique en détail.

Pourquoi le serveur de login sur le port 2106 est la vraie cible

Lineage 2 est réparti sur deux processus distincts : un serveur de login et un ou plusieurs serveurs de jeu. Le client se connecte d'abord sur le 2106 TCP au serveur de login, s'authentifie, y récupère la liste des serveurs avec l'adresse externe et le port du serveur de jeu, puis établit une seconde connexion sur le 7777 TCP vers le serveur de jeu. Les deux processus ont leurs propres fichiers de configuration, leurs propres ports et leurs propres limites de charge.

Il en découle le schéma d'attaque que les exploitants de serveurs L2 décrivent sans cesse : un flood sur 2106 bloque uniquement les nouvelles connexions. Celui qui se trouve déjà dans le monde continue de jouer, jusqu'à ce qu'il perde lui-même la connexion. Le compteur de joueurs en ligne baisse donc lentement au lieu de s'effondrer d'un coup, et sur le forum on lit « le serveur tourne, mais je n'arrive pas à entrer ». C'est exactement cette image qui distingue une attaque contre le serveur de login d'une attaque contre le serveur de jeu, où tout le monde est éjecté en même temps.

Le serveur de login est de plus la cible la moins chère, parce que l'effort est réparti de façon inégale. Au démarrage, le serveur de login L2J génère une réserve de dix paires de clés RSA de 1024 bits et de vingt clés Blowfish. Chaque tentative de connexion coûte au client l'envoi d'un paquet, et au serveur un déchiffrement avec la clé RSA privée. Une session à moitié établie occupe pendant ce temps une place, jusqu'à ce que le minuteur intégré la rejette : dans le code source, LOGIN_TIMEOUT vaut 60 secondes. Le réglage par défaut MaxConnectionPerIP = 50 autorise cinquante connexions simultanées par adresse source. Mille adresses sources suffisent ainsi pour 50 000 sessions ouvertes en même temps, chacune subsistant jusqu'à une minute.

S'y ajoute une particularité du jeu qui le distingue de la plupart des serveurs de jeu : Lineage 2 fonctionne exclusivement en TCP. L'éditeur indique pour ce jeu les ports TCP 80, 2009, 2106 et 7777, et en UDP uniquement le port 53 pour la résolution de noms. Il n'existe donc aucun trafic de jeu UDP à filtrer, mais en contrepartie le SYN flood classique avec des adresses source falsifiées agit directement, et le suivi de connexions du noyau devient le premier goulot d'étranglement.

Pourquoi les attaques contre les serveurs Lineage 2 se concentrent sur les ouvertures de serveur

Les attaques contre les serveurs Lineage 2 privés se multiplient autour des ouvertures de serveur, parce que la date et l'heure de l'ouverture sont publiques des semaines à l'avance. Les calendriers d'ouverture pour les projets Lineage 2 répertorient les lancements à venir par chronique (Interlude, High Five, Classic, Essence), avec les taux et l'heure exacte de démarrage, et ils sont mis à jour quotidiennement. L'attaquant n'a rien à explorer : le moment qui lui est le plus favorable figure dans l'annonce de l'exploitant.

La deuxième raison est économique. Un serveur Lineage 2 privé gagne son argent au début : toute la base de joueurs se recrute dans les premiers jours, les dons tombent dans les premières semaines, et la population décroît ensuite régulièrement. Un joueur qui n'arrive pas à entrer pendant la première heure passe au projet qui démarre le même week-end, et ce projet existe toujours. Une heure d'indisponibilité le jour de l'ouverture ne coûte donc pas une heure de chiffre d'affaires, mais une partie de toute la durée de vie du serveur.

La troisième raison est technique. Lors du grand opening, des milliers de joueurs tentent de se connecter en même temps. Le serveur de login est de toute façon à la limite à cette minute précise, et un flood supplémentaire se distingue à peine du pic de charge. Une attaque qui resterait sans conséquence un mardi calme suffit à l'heure de l'ouverture. Il en va de même pour les rendez-vous annoncés en exploitation courante : les sièges de château et les raid boss épiques figurent au calendrier et sont, pour la même raison, des fenêtres d'attaque prisées. Après la ruée de l'ouverture, l'incitation retombe, ce qui fait que les exploitants vivent les attaques par vagues et non comme un état permanent.

Les ports dont il est réellement question

Le tableau suivant répertorie les ports d'un serveur Lineage 2 privé, le fichier de configuration correspondant et la directive qui fixe la valeur. Les réglages par défaut proviennent des fichiers de configuration livrés avec L2J, respectivement des guides d'installation des paquets L2OFF.

Ce tableau répond du même coup à deux questions : Lineage 2 n'a ni port de requête ni port RCON. Il n'existe aucun service séparé qui livrerait l'état des joueurs à une liste de serveurs, ni aucun port de télécommande comme dans les jeux basés sur Source. La liste des serveurs, le serveur de login la génère lui-même et l'envoie par la même connexion sur 2106 au client authentifié. La télécommande passe dans L2J par des commandes en jeu et par la base de données. Deux vecteurs d'attaque que d'autres jeux possèdent disparaissent donc, et tout repose d'autant plus sur le port 2106.

Les ordres de grandeur à connaître

Ce que vous pouvez faire vous-même avant de dépenser de l'argent

Cette section est la plus longue, et c'est volontaire. Un serveur Lineage 2 proprement configuré encaisse par ses propres moyens les attaques petites et moyennes, quel que soit l'hébergeur chez qui il se trouve.

1. État des lieux : qu'est-ce qui écoute au juste ?

Avant d'écrire la moindre règle, regardez ce que votre serveur propose vers l'extérieur. Ne devinez pas, vérifiez :

ss -lntp

La colonne qui compte est celle de l'adresse locale. 0.0.0.0:2106 et 0.0.0.0:7777 ont leur place ici. 0.0.0.0:9014 et 0.0.0.0:3306 sont des erreurs : ce sont les deux ports par lesquels un attaquant peut s'accrocher à votre liste de serveurs ou sonder votre base de données. 127.0.0.1:3306 signifie en revanche « en local uniquement » et ne demande aucune règle de pare-feu. Le point de vue de l'attaquant, lui, s'obtient par un scan de ports depuis l'extérieur :

nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

2. Tenir le port 9014 et la base de données à l'écart du réseau ouvert

Le port 9014 est le canal par lequel le serveur de jeu s'enregistre auprès du serveur de login, et il n'a en aucun cas sa place sur le réseau ouvert. L2J livre déjà le bon réglage par défaut pour cela : LoginHostname = 127.0.0.1 attache le port à l'interface de loopback, il n'est donc pas du tout joignable depuis l'extérieur. Si le serveur de login et le serveur de jeu tournent sur deux machines différentes, indiquez l'adresse interne concrète au lieu de * et n'ouvrez le port que pour la machine distante.

La même règle vaut pour la base de données. Vérifiez dans /etc/mysql/mariadb.conf.d/50-server.cnf que la ligne suivante est bien présente :

bind-address = 127.0.0.1

Et remplacez l'utilisateur de la base de données. Le fichier Server.properties livré par défaut porte Login = root, et le fichier lui-même commente cela par la remarque que ce n'est précisément pas recommandé. La façon de créer un utilisateur dédié avec des droits minimaux est décrite dans Sécuriser MariaDB et MySQL. Contrôlez ensuite le résultat :

ss -lntp | grep -E ':9014|:3306'

Le pare-feu par-dessus reste court. Pour un serveur Lineage 2, deux autorisations vers l'extérieur suffisent, et exactement dans cet ordre, pour ne pas vous bloquer vous-même :

ufw allow 22/tcp comment 'SSH'
ufw allow 2106/tcp comment 'L2 Login'
ufw allow 7777/tcp comment 'L2 Game'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

3. Désactiver AcceptNewGameServer dès que votre serveur est enregistré

Dans le fichier LoginServer.properties, la valeur d'usine est AcceptNewGameServer = True, et le commentaire au-dessus décrit exactement ce que cela signifie : n'importe quel serveur de jeu peut s'enregistrer sur une place libre de votre serveur de login. Tant que 9014 reste sur l'interface de loopback, cela reste sans conséquence. Dès que le port devient joignable pour une autre raison, c'est une porte ouverte. Mettez donc la valeur à False dès que votre propre serveur de jeu est enregistré et dispose de son identifiant :

AcceptNewGameServer = False

La contrepartie côté serveur de jeu porte AcceptAlternateID = True. C'est pratique pendant la mise en place, parce que le serveur de login attribue alors un autre identifiant si celui souhaité est occupé. Sur un système en production, vous voulez l'inverse : un identifiant fixe, et une erreur s'il est occupé.

4. Régler correctement la flood protection du serveur de login

L2J embarque son propre frein à connexions dans le serveur de login. Il se règle dans le fichier LoginServer.properties, et toutes les valeurs de temps sont en millisecondes :

EnableFloodProtection = True
FastConnectionLimit = 15
NormalConnectionTime = 700
FastConnectionTime = 350
MaxConnectionPerIP = 50

Les valeurs sont liées entre elles. Une connexion qui arrive depuis la même adresse source moins de FastConnectionTime après la précédente compte comme rapide. Après FastConnectionLimit connexions de ce type, l'adresse est refusée. NormalConnectionTime est l'intervalle à partir duquel le compteur redescend. MaxConnectionPerIP est le plafond de connexions ouvertes simultanément par adresse.

Cinquante connexions simultanées sont très généreuses pour un joueur isolé, et des valeurs plus basses aident sensiblement. La prudence reste pourtant de mise ici : plusieurs joueurs d'un même foyer, un cybercafé et surtout les raccordements derrière un NAT d'opérateur (dans le milieu L2, cela concerne beaucoup de joueurs de Turquie, du Brésil et de certaines régions d'Europe de l'Est) se partagent une adresse publique. Celui qui descend ici à 3 exclut de vrais joueurs. Mesurez d'abord pendant une semaine en fonctionnement normal, puis abaissez par étapes.

Et une limite que vous devez connaître : ce frein tourne dans le processus Java du serveur de login. Chaque paquet sur lequel il statue a déjà parcouru votre raccordement et a déjà coûté du temps de calcul. Il agit contre une poignée de sources, pas contre un botnet.

5. Limiter les tentatives échouées et utiliser banned_ip.cfg

Deux autres directives du fichier LoginServer.properties déterminent combien de temps quelqu'un peut deviner :

LoginTryBeforeBan = 5
LoginBlockAfterBan = 900

LoginTryBeforeBan est le nombre de combinaisons compte et mot de passe invalides après lequel l'adresse est bloquée, LoginBlockAfterBan est la durée du blocage en secondes (900 correspond à 15 minutes). Ensuite, le comptage repart de zéro.

Les blocages permanents s'inscrivent dans le fichier banned_ip.cfg du répertoire de configuration du serveur de login. Sont autorisées les adresses isolées, des réseaux entiers et une date d'expiration facultative sous forme d'horodatage Unix en millisecondes ; tout ce qui suit # est un commentaire :

198.51.100.7
203.0.113.0
198.51.100.44 1789689600000

Mettez par ailleurs AutoCreateAccounts = False. Le réglage par défaut True crée automatiquement un compte à chaque connexion avec un nom de compte inconnu. C'est commode pendant la mise en place et c'est un cadeau en exploitation : un attaquant se fabrique ainsi autant de comptes qu'il veut, et chacun d'eux a le droit de consulter la liste des serveurs contenant l'adresse de votre serveur de jeu. Faites plutôt naître les comptes via l'inscription sur votre site, vous contrôlez alors qui obtient un identifiant.

6. Limiter les taux de connexion sur 2106 et 7777 dans le noyau

Ce que le frein Java tranche trop tard, le noyau le tranche plus tôt et pour moins cher. Contre les petites attaques et les bots mal écrits, un plafond par adresse source fait le travail :

iptables -I INPUT -p tcp --dport 2106 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 2106 --syn -m hashlimit --hashlimit-name l2login --hashlimit-mode srcip --hashlimit-above 6/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 6 --connlimit-mask 32 -j DROP

La première règle rejette les nouvelles connexions vers le serveur de login dès qu'une adresse en a plus de huit ouvertes en même temps. Un client régulier en a besoin d'exactement une. La deuxième limite le taux de nouvelles connexions à six par seconde et par adresse avec un tampon de vingt, ce qui laisse encore passer une vague de reconnexions après un redémarrage du serveur. La troisième autorise six connexions simultanées par adresse sur le serveur de jeu, parce que la connexion multiple (dualbox et triplebox) est normale dans Lineage 2 et qu'une limite trop serrée touche vos joueurs payants.

Ces trois chiffres sont des valeurs de départ, pas des vérités. Un serveur avec 2000 joueurs simultanés se comporte autrement qu'un serveur avec 200. Mesurez d'abord, réglez ensuite. Les règles iptables seules disparaissent après un redémarrage ; sous Debian et Ubuntu, on les enregistre ainsi :

apt-get install -y iptables-persistent
netfilter-persistent save

Sous UFW, de telles règles ont leur place dans /etc/ufw/before.rules, faute de quoi elles disparaissent au prochain ufw reload.

7. Encaisser un SYN flood : SYN cookies, backlog et suivi de connexions

Parce que Lineage 2 fonctionne exclusivement en TCP, le SYN flood est le vecteur évident. Un SYN flood est une attaque qui envoie des demandes de connexion avec des adresses source falsifiées et ne répond jamais à la confirmation, de sorte que le serveur réserve pour chaque demande une mémoire qui ne sera jamais utilisée. Quatre réglages désamorcent cela :

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_synack_retries=2

Les SYN cookies sont ici la ligne la plus importante : le noyau répond à la demande sans rien mémoriser et ne crée l'état que lorsque la machine distante établit réellement la connexion. Les adresses source falsifiées tombent ainsi dans le vide. Pour rendre les valeurs permanentes, on les dépose dans un fichier sous /etc/sysctl.d/ et on les charge avec sysctl --system.

Un goulot d'étranglement souvent négligé est le suivi de connexions du noyau. Lorsqu'il est saturé, le serveur rejette aussi les paquets légitimes, et le journal indique « nf_conntrack: table full, dropping packet ». La valeur actuelle et la limite s'affichent avec :

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

8. Site web, serveur de login et serveur de jeu sur des adresses IP séparées

Le site du projet, avec son inscription, sa boutique de dons et ses pages de vote, reste toujours repérable via votre domaine. S'il se trouve sur la même adresse IP que le serveur de login, une attaque contre le site paralyse du même coup l'authentification, et réciproquement. Répartissez ces trois rôles sur des adresses différentes. Lors d'une attaque contre le site, le jeu reste alors joignable, et lors d'une attaque sur 2106, les joueurs déjà connectés continuent de jouer.

Tenez au passage vos enregistrements DNS au propre. L'erreur la plus fréquente est un enregistrement A oublié qui pointe vers une adresse précédente : il rend tout changement d'adresse inopérant, parce que l'attaquant trouve la nouvelle adresse par le même nom que vos joueurs.

Et c'est ici que l'honnêteté vaut mieux que la pensée magique : l'adresse de votre serveur de login ne peut pas rester secrète. Elle figure dans le fichier l2.ini du dossier System que chaque joueur télécharge. Quant à l'adresse du serveur de jeu, c'est le serveur de login lui-même qui la distribue : dans L2J, elle est inscrite comme adresse externe dans ipconfig.xml (dans les dérivés plus anciens comme ExternalHostname dans Server.properties), et elle est communiquée à chaque client qui s'est authentifié avec succès. Se cacher n'est pas une stratégie, filtrer en est une.

9. Journaliser, pour disposer de données le jour venu

L'étape la plus importante est celle que presque personne ne franchit à l'avance : constituer une base de comparaison pendant que tout fonctionne normalement. Sans valeur de référence, vous ne pourrez pas dire après un incident si 40 000 paquets par seconde représentaient beaucoup, ou simplement un samedi soir. Avec apt-get install -y vnstat sysstat, la mesure tourne en permanence. Pendant un incident, quatre commandes suffisent :

sar -n DEV 1 10
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 'tcp port 2106' -c 200 -q

La deuxième ligne est la plus parlante avec Lineage 2 : elle compte les connexions semi-ouvertes. Une valeur à cinq chiffres pour quelques centaines de joueurs est un SYN flood et rien d'autre. Pour tcpdump, une règle : limitez toujours avec -c, car une capture à pleine charge alourdit encore un serveur déjà surchargé. La façon d'interpréter ces valeurs est expliquée dans Détecter une attaque DDoS.

Où ces mesures s'arrêtent

Vient maintenant la partie qu'aucun fichier de configuration ne peut résoudre. Toutes les mesures précédentes s'exécutent sur votre serveur, donc au bout du raccordement. Une règle de pare-feu décide du sort d'un paquet qui a déjà parcouru le câble. Vous pouvez le rejeter, mais vous ne pouvez pas faire qu'il n'ait jamais été envoyé.

Faites le calcul une fois. Un serveur de jeu classique est raccordé à 1 Gbit/s, soit 125 mégaoctets par seconde, et le raccordement est saturé dès que quelqu'un envoie davantage. Contre un serveur Lineage 2, il ne faut même pas une grosse attaque pour cela, parce que la deuxième grandeur frappe plus tôt : le taux de paquets. Avec de petits paquets de 64 octets, environ 1,49 million de paquets par seconde tiennent dans un raccordement à 1 Gbit/s. Selon le CPU et la carte réseau, un noyau de serveur normal en traite quelques centaines de milliers avant de commencer à rejeter.

Avec un jeu purement TCP, une troisième limite s'ajoute. Chaque connexion semi-ouverte occupe une entrée dans le suivi de connexions et dans le backlog, et le serveur de login L2J conserve ses sessions jusqu'à 60 secondes. Une attaque de quelques centaines de milliers de paquets par seconde, qui ne remplit même pas un tiers de votre raccordement, peut donc bloquer complètement l'authentification. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant personne n'arrivait à entrer ».

Pour situer les ordres de grandeur qui se produisent réellement : sur des serveurs KernelHost, nous avons notamment filtré une attaque de plus de 112,2 Gbit/s à plus de 8,7 millions de paquets par seconde contre un serveur de jeu, ainsi qu'une attaque multivecteur de plus de 473,4 Gbit/s à plus de 41,5 millions de paquets par seconde contre un serveur vocal. Il n'existe aucun réglage local pour cela. Les attaques volumétriques doivent s'arrêter dans le réseau, en amont du serveur. Ce qu'il faut faire dans l'urgence est décrit dans Attaque DDoS sévère : que faire ?.

Ce que KernelHost oppose à cela

La protection permanente incluse avec chaque serveur

La protection DDoS de KernelHost repose sur deux niveaux et reste active en permanence, sans que vous ayez quoi que ce soit à activer, à commander ou à configurer :

• Niveau 1 : 17 Tbps de capacité de mitigation dans le réseau de scrubbing mondial. Les attaques volumétriques sont nettoyées au plus près de leur source, avant d'atteindre le centre de données.
• Niveau 2 : filtrage Arbor en temps réel à 3,2 Tbps à Francfort-sur-le-Main. Juste devant le serveur, les schémas propres à chaque protocole sont identifiés et rejetés, paquet par paquet.

Deux caractéristiques sont décisives. La protection fonctionne en permanence et n'a pas besoin de réagir d'abord à une attaque : il n'y a donc pas de premières minutes pendant lesquelles le serveur est injoignable. Lors d'un grand opening précisément, c'est la différence entre un lancement réussi et un lancement perdu. Et aucun null-routing n'est utilisé : votre adresse IP reste dans le réseau, seuls les paquets malveillants sont rejetés. Retirer l'adresse IP du réseau aboutit, de votre point de vue, exactement au même résultat que l'attaquant. Les jeux et protocoles couverts sont listés dans Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les projets attaqués en continu

Certains projets ne sont pas attaqués de temps à autre, mais de façon ciblée et pendant des semaines, et dans le milieu Lineage 2 c'est le cas normal pour tout serveur qui atteint les premiers rangs des listes de serveurs. Pour ces cas, il existe l'Advanced DDoS Protection à partir de 50,00 € par mois, en PrePaid et sans durée minimale. La différence ne tient pas à une capacité supérieure, mais au contrôle :

• Une IP protégée dédiée issue du cœur de réseau de Francfort, vers laquelle votre serveur est basculé au sein de notre propre réseau. Aucune modification n'est nécessaire de votre côté.
• Des règles de protection par port et par protocole, que vous gérez vous-même dans l'espace client : vous définissez séparément ce qui est autorisé sur 2106 TCP et ce qui l'est sur 7777 TCP. C'est le point décisif avec Lineage 2, parce que ces deux ports ont des profils de trafic totalement différents : beaucoup de connexions courtes d'un côté, peu de connexions très longues de l'autre.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages pendant une attaque en cours, durcir les règles avant l'heure de l'ouverture et les assouplir ensuite.
• Un profil de protection adapté à l'application, y compris pour des fichiers serveur modifiés ou maison sur n'importe quel port TCP ou UDP. Que vous exploitiez L2J, L2J-Mobius, aCis ou un paquet L2OFF ne change rien au jeu de règles, puisque celui-ci se fonde sur le port et le protocole.

Les deux niveaux comparés

Pour la plupart des projets Lineage 2, la protection permanente incluse suffit, à condition que la configuration du serveur soit propre. L'Advanced DDoS Protection est la réponse au cas où quelqu'un en fait une affaire personnelle, et l'expérience montre que cela arrive la semaine précédant le grand opening.

Erreurs fréquentes et solutions

« La connexion ne passe pas, mais le serveur de jeu tourne normalement » : ce n'est pas un hasard, c'est la forme habituelle d'une attaque contre un serveur Lineage 2. Le serveur de login et le serveur de jeu sont deux processus sur deux ports. Mesurez ss -tn state syn-recv | wc -l et sar -n DEV 1 10. Si les connexions semi-ouvertes montent alors que la bande passante reste normale, c'est un flood de connexions sur 2106.

« J'ai changé d'adresse IP et le lendemain j'étais de nouveau hors ligne » : l'attaquant obtient la nouvelle adresse par le même chemin que vos joueurs, à savoir le nouveau dossier System avec son fichier l2.ini modifié, votre annonce ou un enregistrement DNS oublié. Un changement d'adresse fait gagner du temps, ce n'est pas une solution.

« J'ai mis MaxConnectionPerIP à 3, maintenant les joueurs se plaignent » : le dualbox est courant dans Lineage 2, et les joueurs derrière un NAT d'opérateur partagent une adresse publique avec des centaines d'autres. Revenez à une valeur qui couvre vos mesures en fonctionnement normal et limitez plutôt le taux de nouvelles connexions dans le noyau.

« Mes règles iptables ne s'appliquent pas » : trois causes sont fréquentes. Les règles se trouvent derrière les chaînes UFW et ne sont jamais atteintes ; elles ont disparu au dernier redémarrage (netfilter-persistent save ou une entrée dans /etc/ufw/before.rules y remédient) ; ou bien l'attaque est volumétrique et la règle travaille correctement sur un raccordement déjà saturé. Vérifiez avec iptables -L INPUT -n -v si les compteurs de correspondances augmentent. S'ils restent à zéro, c'est que la règle n'est jamais atteinte.

« Tous les joueurs ont des pics de lag, mais le raccordement est calme » : alors ce n'est pas une attaque DDoS. Sur un serveur Java, les suspects habituels sont les pauses du ramasse-miettes, une base de données sans index adaptés et un script ou un événement personnalisé pris dans une boucle. Vérifiez d'abord sar -n DEV 1 10 : si les taux de paquets restent normaux, la cause est dans le serveur et non dans le réseau.

« Mon hébergeur précédent a bloqué mon adresse IP » : c'est du null-routing. L'hébergeur protège ainsi son propre réseau ; pour vous, le résultat est identique à une attaque réussie, et le plus souvent pendant encore des heures. En cas de doute, demandez si le trafic est filtré ou si l'adresse est simplement retirée du réseau. La réponse pèse davantage sur votre disponibilité que n'importe quelle fiche technique.

« Dans tcpdump, je ne vois rien d'anormal » : si le trafic est déjà filtré dans le réseau en amont, rien n'arrive sur le serveur, et c'est bien ce à quoi il faut s'attendre. C'est le cas normal quand le filtrage fonctionne. À l'inverse : si le raccordement est saturé, il se peut que même la session SSH avec laquelle vous vouliez mesurer ne vous parvienne plus. Utilisez alors la console VNC dans l'espace client, qui fonctionne indépendamment du réseau du système invité.

« Mon grand opening est dans deux semaines » : alors déménagez maintenant et pas pendant la semaine du lancement. Un déménagement coûte un nouveau dossier System pour les joueurs, une bascule DNS et un essai. Vous voulez avoir tout cela derrière vous avant d'annoncer la date, car dès l'annonce, chaque concurrent connaît votre moment le plus défavorable.

En résumé

• Un serveur Lineage 2 privé a besoin d'exactement deux ports sur le réseau ouvert : 2106 TCP pour le serveur de login et 7777 TCP pour le serveur de jeu. Le port 9014, la base de données (3306 avec L2J, 1433 avec L2OFF) et les ports internes L2OFF 2002, 2006, 2008, 2104 et 2108 n'en font pas partie.
• Lineage 2 fonctionne exclusivement en TCP et n'a ni port de requête ni port RCON. L'attaque typique est donc un SYN flood ou un flood de connexions sur le port 2106, et non un flood UDP.
• Une attaque contre le serveur de login ne bloque que les nouvelles connexions. Si personne n'entre alors que les joueurs présents dans le monde continuent de jouer, la cause est à chercher sur le port 2106 et non sur 7777.
• Réglez EnableFloodProtection, MaxConnectionPerIP, LoginTryBeforeBan et AutoCreateAccounts en connaissance de cause, mettez AcceptNewGameServer à False après l'enregistrement et limitez en plus les taux de connexion dans le noyau, parce que le frein Java n'agit qu'en bout de raccordement.
• Les attaques contre les serveurs Lineage 2 se concentrent sur les ouvertures de serveur, parce que la date et l'heure sont publiques des semaines à l'avance et que le dommage économique est le plus élevé le jour de l'ouverture. La protection doit être en place avant l'annonce, pas après.
• Au-delà de la capacité du raccordement et au-delà de quelques centaines de milliers de paquets par seconde, seul le filtrage dans le réseau en amont du serveur est déterminant. Chez KernelHost, il est à deux niveaux, actif en permanence, sans supplément et sans null-routing.

Si votre projet est déjà hébergé chez KernelHost, le filtrage est actif sans que vous ayez quoi que ce soit à faire. Si vous constatez malgré tout des anomalies, ouvrez un ticket de support afin que les règles de filtrage soient ajustées pour votre adresse IP. Pendant une attaque en cours, vous pouvez également nous joindre via le chat d'urgence WhatsApp au +43 650 8209883.