Protéger un serveur MTA:SA des attaques DDoS

Un serveur pour Multi Theft Auto: San Andreas se comporte sous une attaque DDoS autrement que n'importe quel autre projet multijoueur GTA, parce qu'il propose trois services réseau distincts en même temps : le trafic de jeu sur 22003 UDP, un serveur HTTP à part entière sur 22005 TCP et la requête ASE sur 22126 UDP. Chacun de ces trois services peut être attaqué séparément, et chacun tombe d'une autre manière. Cet article montre d'abord ce que vous pouvez sécuriser vous-même sans frais supplémentaires, ensuite où ces mesures butent sur la physique du raccordement, et pour finir ce qu'une protection DDoS efficace pour MTA:SA doit assurer dans le réseau, en amont du serveur.

Si l'attaque est en cours, la question la plus importante est de savoir lequel des trois services est touché. Si les joueurs restent connectés mais ne chargent plus de ressources à la connexion, c'est le serveur HTTP sur 22005 qui est visé. Si le serveur disparaît du navigateur alors que les joueurs connectés continuent de jouer normalement, c'est la requête ASE sur 22126. Si toutes les connexions se coupent en même temps, soit 22003 est la cible, soit le raccordement est saturé. Toutes les indications se rapportent à un serveur MTA sous Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS ; les commandes sont écrites pour root, en tant qu'utilisateur normal, faites-les précéder de sudo.

Pourquoi les serveurs MTA:SA deviennent si souvent la cible d'attaques DDoS

Les projets MTA:SA sont des cibles commodes parce qu'ils doivent publier leur adresse eux-mêmes. Un serveur n'apparaît dans le navigateur du jeu que s'il s'inscrit auprès de la liste des serveurs maîtres et répond ensuite aux requêtes venues de l'extérieur. Cette liste contient l'adresse IP et le port en clair : pour un attaquant, toute reconnaissance préalable est donc superflue.

S'y ajoute la scène elle-même. Les serveurs de jeu de rôle germanophones et brésiliens, les serveurs de drift et les adaptations DayZ se disputent le même public, et une panne aux heures de forte affluence est visible au maximum. Un joueur banni, une équipe en désaccord ou un projet concurrent n'a besoin ni de compétence ni d'argent notable pour rendre une soirée inutilisable. Les services d'attaque réservables, appelés booters ou stressers dans le milieu, vendent pour quelques euros par mois exactement deux résultats : mettre le serveur MTA hors ligne pendant des minutes ou le rendre injouable par des pics de lag. Ce qu'est techniquement une attaque DDoS et quels types d'attaques existent, l'article Qu'est-ce qu'une attaque DDoS ? l'explique.

Techniquement, MTA:SA facilite la tâche des attaquants sur deux points par rapport à d'autres modifications multijoueur. D'abord, la requête se trouve sur un port UDP propre qui renvoie, en réponse à un seul octet, une réponse de plusieurs kilooctets. Ensuite, chaque serveur MTA comporte un serveur HTTP qui livre les fichiers côté client de toutes les ressources, et ce sans authentification, à quiconque le demande.

Les ports dont il est réellement question

Un serveur MTA:SA a besoin d'exactement trois ports : 22003 UDP pour le jeu, 22005 TCP pour le serveur HTTP interne et 22126 UDP pour la requête ASE. Le troisième port n'est pas un réglage libre, il découle fixement du port de jeu plus 123. Qui met serverport sur 22010 obtient la requête sur 22133.

Deux subtilités figurent telles quelles dans la mtaserver.conf livrée d'origine et sont régulièrement ignorées. httpport peut porter la même valeur numérique que serverport, parce que l'un des ports est TCP et l'autre UDP. Et serverip est réglé sur auto et doit y rester : une valeur inscrite en dur attache le socket ASE exactement à cette adresse et casse l'entrée dans la liste dès que l'adresse change.

Le protocole de requête ASE et pourquoi il est un amplificateur

ASE (All-Seeing Eye) est un protocole de requête purement UDP : le premier octet du paquet détermine la réponse, il n'existe aucun établissement de connexion. Le serveur MTA connaît cinq requêtes et y répond sur 22126 :

• s est la requête ASE complète. La réponse commence par EYE1 et contient le nom du serveur, le type de jeu, le nom de la carte, la version, l'état du mot de passe, le nombre de joueurs, la liste complète de toutes les règles posées par setRuleValue, puis chaque joueur connecté avec son nom, son score et son ping. Cette réponse n'a aucune limite de taille.
• b et r sont les requêtes plus légères destinées au navigateur du jeu. La réponse commence par EYE2 et est tronquée dans le code source à 1 340 octets, afin d'éviter la fragmentation.
• x renvoie un message de statut abrégé, v uniquement l'identifiant de version ASE.

C'est de là que naît le problème. Une requête se compose d'un unique octet de charge utile, soit 29 octets sur le fil (20 octets d'en-tête IP, 8 octets d'en-tête UDP, 1 octet de charge utile). Une réponse de 1 400 octets de charge utile représente 1 428 octets sur le fil. Le rapport atteint environ 49 fois, et comme UDP ne connaît aucun établissement de connexion, l'adresse source se falsifie. Un attaquant peut donc utiliser votre serveur comme amplificateur contre une troisième cible, sans jamais entrer dans votre jeu. Avec la requête complète, le facteur croît avec le nombre de joueurs et avec chaque règle que pose votre gamemode.

MTA apporte en contrepartie deux freins intégrés qu'il faut connaître, parce qu'ils expliquent pourquoi certaines vagues font effet et d'autres non. Le serveur répond au plus à cinq requêtes en six secondes par adresse source et ignore ensuite cette adresse pendant sept secondes. Il garde en outre les réponses en cache pendant dix secondes au lieu de les reconstruire à chaque requête. Le comptage par adresse source est cependant entièrement ignoré dès que plus de 100 adresses sources différentes figurent en même temps dans la liste. C'est précisément le cas normal lors d'une vague distribuée issue d'un botnet ou avec des adresses sources falsifiées, et c'est pourquoi le frein intégré n'aide pas contre une attaque sérieuse.

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 MTA 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 ?

Regardez d'abord ce que votre serveur propose vers l'extérieur. Ne devinez pas, vérifiez :

ss -lntup

Trois lignes du processus MTA sont attendues : 0.0.0.0:22003 en UDP, 0.0.0.0:22005 en TCP et 0.0.0.0:22126 en UDP. Si une base de données sur 0.0.0.0:3306, un serveur web ou un service vocal oublié apparaît en plus, cela doit être arrêté. Le point de vue de l'attaquant s'obtient par un scan de ports depuis l'extérieur :

nmap -Pn -sU -p 22003,22126 ADRESSE.IP.DE.VOTRE.SERVEUR
nmap -Pn -p 22005 ADRESSE.IP.DE.VOTRE.SERVEUR

Le serveur apporte aussi sa propre commande de console pour cela. Dans la console du serveur, openports vérifie si les trois ports sont joignables depuis l'extérieur.

2. Ne laisser ouverts que les trois ports dont MTA a réellement besoin

Avec UFW, une configuration de départ viable se présente ainsi, et exactement dans cet ordre, pour ne pas vous bloquer vous-même :

ufw allow 22/tcp comment 'SSH'
ufw allow 22003/udp comment 'MTA jeu'
ufw allow 22005/tcp comment 'MTA HTTP'
ufw allow 22126/udp comment 'MTA ASE'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Le guide complet, voie de secours comprise, figure dans l'article Configurer le pare-feu UFW. Sur les serveurs root KVM et les serveurs dédiés de KernelHost, vous accédez en cas d'urgence au système par la console VNC de l'espace client, même quand le raccordement est saturé.

La base de données n'a pas sa place sur le réseau ouvert. Si ss -lntp | grep 3306 affiche un 0.0.0.0:3306, inscrivez dans /etc/mysql/mariadb.conf.d/50-server.cnf la ligne bind-address = 127.0.0.1 et redémarrez le service.

3. Limiter le port ASE sans disparaître de la liste des serveurs

Contrairement à SA-MP, la requête se trouve chez MTA:SA sur un port propre, vous pouvez donc la limiter indépendamment du jeu. C'est le plus grand avantage pratique de cette architecture : une règle sur 22126 n'éjecte pas un seul joueur.

Avec nftables dans une table propre, pour que le jeu de règles n'entre pas en conflit avec UFW :

nft add table inet mtaguard
nft add chain inet mtaguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet mtaguard input udp dport 22126 meter aseperip '{ ip saddr limit rate over 3/second burst 6 packets }' drop
nft add rule inet mtaguard input udp dport 22126 limit rate over 2000/second burst 500 packets drop
nft list table inet mtaguard

La première règle limite chaque adresse source prise isolément, la seconde le port dans son ensemble. Les deux ensemble sont importantes : une vague distribuée passe par l'interstice entre de nombreuses sources isolées si la limitation ne porte que sur chaque adresse. Les valeurs sont serrées, et c'est ici acceptable, parce qu'un vrai navigateur de serveurs n'interroge votre serveur que toutes les quelques secondes. Avec iptables, le module hashlimit obtient la même chose :

iptables -A INPUT -p udp --dport 22126 -m hashlimit --hashlimit-name mta_ase \
  --hashlimit-mode srcip --hashlimit-above 3/sec --hashlimit-burst 6 \
  --hashlimit-htable-expire 30000 -j DROP

Vouloir fermer complètement le port est un arbitrage et non une astuce de spécialiste : sans ASE, votre serveur disparaît du navigateur du jeu et donc de l'afflux naturel de joueurs. Si vous le voulez malgré tout, <ase>0</ase> ne suffit pas. Dans le code source, l'ouverture du port dépend de la combinaison OU du mode Internet et du mode LAN : avec <ase>0</ase>, le socket reste donc ouvert tant que <donotbroadcastlan>0</donotbroadcastlan> est en place. Qui veut réellement fermer le port règle les deux :

<ase>0</ase>
<donotbroadcastlan>1</donotbroadcastlan>

La voie la plus honnête pour un projet en croissance est la suivante : laisser le port ouvert, limiter le débit, et maintenir l'effet d'amplification à un niveau bas en veillant à ce que votre gamemode ne publie aucune règle inutile via setRuleValue. Chaque règle figure dans la requête complète et agrandit la réponse.

4. Soulager le serveur HTTP interne

Chez MTA:SA, le serveur HTTP sur 22005 constitue une surface d'attaque à part entière, parce que chaque joueur qui rejoint la partie y télécharge l'ensemble des fichiers côté client de toutes les ressources en cours. Sur un projet de jeu de rôle doté de modèles propres, cela représente vite plusieurs centaines de mégaoctets, répartis sur des centaines de fichiers. Le serveur intégré est volontairement resté simple : aucune compression, un contingent fixe de fils d'exécution. Quelques dizaines de requêtes simultanées suffisent pour que de vrais joueurs restent bloqués plusieurs minutes sur l'écran de chargement.

La mesure la plus efficace consiste à sortir complètement les téléchargements du serveur de jeu. MTA prépare lui-même les fichiers à livrer pour cela, sous mods/deathmatch/resource-cache/http-client-files. Vous publiez ce dossier via nginx ou lighttpd et inscrivez l'adresse dans la mtaserver.conf :

<httpdownloadurl>http://cdn.ihre-domain.tld/mta</httpdownloadurl>

Cela apporte deux choses à la fois. Les téléchargements passent par un serveur web conçu pour cela, et ils ne passent plus par l'adresse de votre serveur de jeu. Si le serveur web se trouve sur une autre machine ou derrière un Content Delivery Network, une vague dirigée contre les téléchargements ne touche plus le jeu. Point important : si l'adresse externe est fausse ou injoignable, MTA revient silencieusement au serveur interne.

Si le serveur interne reste en service, utilisez ses propres limites. Dans la mtaserver.conf :

<httpmaxconnectionsperclient>5</httpmaxconnectionsperclient>
<httpdosthreshold>20</httpdosthreshold>
<http_dos_exclude></http_dos_exclude>
<httpthreadcount>8</httpthreadcount>

httpmaxconnectionsperclient limite à 5 les connexions simultanées par client, dans la plage autorisée de 1 à 8. httpdosthreshold limite le nombre de connexions qu'une seule adresse IP peut établir en peu de temps, valeur par défaut 20. http_dos_exclude en exempte certaines adresses, par exemple votre propre page de statut. httpthreadcount détermine le nombre de fils d'exécution, valeur par défaut 8 dans la plage de 1 à 20. Une valeur plus élevée aide lorsqu'il y a beaucoup de petits fichiers, mais coûte du temps de calcul qui manque ensuite au jeu.

Pensez en outre à ce qui est également livré sur ce même port. Les ressources webadmin et resourcebrowser sont démarrées dans la configuration livrée d'origine et accessibles dans le navigateur via 22005. Une interface d'administration n'a pas sa place sans protection sur le réseau ouvert : attribuez des droits propres dans l'acl.xml, créez un compte dédié avec un long mot de passe aléatoire, et arrêtez la ressource lorsque vous n'en avez pas besoin.

5. Utiliser les limites intégrées de mtaserver.conf

MTA apporte plus de limites de protection que la plupart des projets n'en utilisent. Certaines sont figées dans le code source, d'autres se trouvent dans la mtaserver.conf. Ce tableau rassemble celles qui jouent un rôle lors d'une attaque :

Trois réglages méritent une décision réfléchie. maxplayers est sur 32 et devrait correspondre à la réalité : chaque slot supplémentaire agrandit la requête complète et augmente le nombre de connexions qu'un attaquant peut occuper. bandwidth_reduction est sur medium ; la valeur maximum réduit sensiblement la charge sortante, mais coûte en précision de synchronisation. Et <password></password> fait de votre serveur un cercle fermé sans le moindre effort, tandis que l'entrée dans la liste subsiste : c'est le frein d'urgence le plus rapide pendant une vague de connexions en cours.

6. Distinguer les vagues de connexions des vagues d'événements

Deux schémas d'attaque ne visent pas le raccordement mais la logique du jeu, et ils sont régulièrement confondus.

Une vague de connexions établit de vraies connexions en rafale, jusqu'à ce que tous les slots soient occupés ou que le serveur ne suive plus l'établissement. MTA limite cela de lui-même à quatre connexions par adresse source en 30 secondes et ignore ensuite cette adresse pendant 30 secondes. Ce que fait le frein à un instant donné, la commande de console debugjoinflood le montre. La limite agit par adresse, un botnet de mille adresses passe à côté. Contre cela, un mot de passe serveur, une liste blanche dans le gamemode et une limitation de débit sur 22003 aident.

Une vague d'événements vient en revanche de joueurs déjà connectés : un client manipulé émet triggerServerEvent en boucle jusqu'à ce que le serveur ne parvienne plus à fournir le temps de calcul. MTA autorise pour cela 100 événements par joueur et par seconde en sortie d'usine et signale au-delà un message sur les vagues d'événements. Si votre gamemode utilise beaucoup de petits événements, vérifiez la valeur avant de l'abaisser : réglée trop serrée, elle éjecte vos propres joueurs.

Indépendamment de cela, la même règle vaut côté serveur que partout ailleurs : ne vous fiez jamais aux valeurs transmises par le client, déterminez le joueur à partir de l'émetteur de l'événement, et limitez tout ce qui déclenche une requête en base de données. Un seul événement non vérifié qui lance une requête suffit à mettre un serveur à l'arrêt sans la moindre attaque réseau.

7. Liste des serveurs, adresse IP et ce qu'elle révèle par ailleurs

Votre adresse IP ne peut pas rester secrète. Chaque joueur qui s'est connecté une fois la connaît, et l'entrée dans la liste des serveurs maîtres la publie de toute façon. Placer un domaine devant n'aide pas : le client résout le nom une fois, puis dialogue directement avec l'adresse.

Vérifiez plutôt ce que votre adresse révèle par ailleurs. Les fuites typiques des projets MTA sont d'anciens enregistrements A et AAAA dans le DNS, la page du projet sur la même machine, un bot Discord affichant le statut qui lit publiquement la requête ASE, des certificats TLS portant d'anciens noms d'hôte et des messages de forum datant des débuts. Il en découle une règle que beaucoup de projets apprennent trop tard : si vous basculez vers une adresse protégée, changez en même temps l'ancienne adresse. Si elle subsiste, elle figure dans toutes les bases de données de scanners, et l'attaque passe à côté de la protection.

Deux entrées de la mtaserver.conf concernent directement la visibilité. <serverip>auto</serverip> reste sur auto, sauf si vous savez précisément pourquoi vous y dérogez. Et <owner_email_address> doit être rempli : si l'entrée manque ou est fausse, cela peut nuire à la visibilité dans la liste des serveurs maîtres.

8. 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 tant 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 vendredi soir. Avec apt-get install -y vnstat sysstat, la mesure tourne en permanence.

Pendant un incident, séparez d'abord les trois ports les uns des autres. Ces quatre commandes suffisent :

sar -n DEV 1 10
nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
tcpdump -ni eth0 -c 200 -q 'udp port 22126'
ss -tn state established '( dport = :22005 or sport = :22005 )' | wc -l

L'interprétation est plus simple qu'elle n'en a l'air. Si les erreurs de tampon augmentent alors que la charge CPU est basse, il vous arrive plus de trafic que le processus ne peut en traiter. Si un cœur tourne à fond alors que le trafic semble normal, le problème vient du gamemode et non du réseau. Si la capture sur 22126 montre beaucoup de paquets d'un seul octet de charge utile, c'est une vague ASE. Si le nombre de connexions ouvertes sur 22005 reste durablement à quatre chiffres, c'est le serveur HTTP qui est touché. Pour tcpdump, une règle vaut toujours : limitez avec -c, car une capture à pleine charge alourdit encore un serveur déjà surchargé. La façon d'interpréter les valeurs en détail est décrite dans l'article Détecter une attaque DDoS sur le serveur.

Le journal du serveur lui-même se trouve sous logs/server.log, le journal des scripts sous logs/scripts.log. Les deux chemins figurent dans la mtaserver.conf et peuvent être déplacés.

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, ce qui correspond à 125 mégaoctets par seconde et, avec des paquets de 64 octets, à environ 1,49 million de paquets par seconde. Les attaques contre des projets de serveurs de jeu de cet ordre de grandeur se situent d'ordinaire entre 5 et 50 Gbit/s, soit cinq à cinquante fois votre raccordement. La qualité de votre règle nftables placée derrière n'a alors plus aucune importance, car les paquets de vos joueurs ne passent déjà plus en amont.

Le taux de paquets frappe à cet égard souvent plus tôt que la bande passante. Selon le CPU et la carte réseau, un noyau de serveur normal traite quelques centaines de milliers de paquets par seconde avant de commencer à rejeter. Une attaque qui ne remplit même pas un tiers de votre raccordement peut donc paralyser votre serveur, parce que le temps de calcul part dans le rejet. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout avait disparu ».

Chez MTA:SA s'ajoute une troisième limite, et c'est elle qui s'applique le plus tôt. Le serveur lit les ports réseau dans un seul fil de traitement. Une vague de requêtes sur 22126 occupe ce traitement au point que les paquets de synchronisation des vrais joueurs expirent dans le tampon de réception, bien avant que le raccordement ne soit saturé. Le processus ne plante pas pour autant, il devient seulement lent, et les joueurs constatent des effets d'élastique. Il en va de même pour le serveur HTTP : il partage le temps de calcul avec le jeu.

Pour situer les ordres de grandeur qui se produisent réellement : sur des serveurs KernelHost, nous avons notamment filtré une attaque de plus de 473,4 Gbit/s à plus de 41,5 millions de paquets par seconde contre un serveur vocal, ainsi qu'un UDP flood de plus de 112,2 Gbit/s à plus de 8,7 millions de paquets par seconde contre un serveur de jeu. Le premier cas représente environ 473 fois la bande passante et à peu près 28 fois le taux de paquets qu'un raccordement à 1 Gbit/s peut absorber. 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 que KernelHost oppose à cela

La protection permanente, incluse sur chaque serveur

Chaque serveur chez KernelHost se trouve derrière un filtrage à deux niveaux actif en permanence :

• 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 même d'atteindre le centre de données de Francfort-sur-le-Main.
• Niveau 2 : filtrage Arbor en temps réel à 3,2 Tbps directement sur place, à Francfort-sur-le-Main. Immédiatement devant le serveur, les schémas propres à chaque protocole sont identifiés et rejetés paquet par paquet.

Trois caractéristiques sont décisives. La protection est active en permanence, il n'y a donc pas de phase de détection pendant laquelle votre serveur passe hors ligne. Aucun null-routing n'est utilisé : l'adresse attaquée reste dans le réseau, seuls les paquets malveillants sont rejetés, tandis que les connexions des vrais joueurs se poursuivent. Et elle ne coûte rien de plus : elle est comprise dès la mise en service dans chaque pack serveur, du serveur root KVM au serveur dédié en passant par le serveur de jeu. Le filtrage porte sur les couches 3, 4 et 7, sur chaque port TCP ou UDP, donc sur 22003 UDP, 22005 TCP et 22126 UDP en même temps. Tout cela est exploité dans le centre de données maincubes à Francfort-sur-le-Main, en Allemagne. Les jeux et protocoles qui disposent de profils propres sont indiqués dans l'article Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les projets visés en continu

Certains projets ne sont pas touchés de temps à autre, mais visés de façon ciblée pendant des semaines. Pour ce 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. Votre serveur y est basculé à l'intérieur du réseau KernelHost, vous ne modifiez rien 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. C'est précisément le point chez MTA:SA : vous réglez séparément 22003 UDP, 22005 TCP et 22126 UDP, au lieu de traiter trois services très différents de la même manière.
• Les changements s'appliquent en temps réel, sans ticket et sans attente. Vous pouvez donc affiner les réglages en plein milieu d'une attaque en cours.
• Un profil de protection adapté au jeu. Multi Theft Auto existe comme profil à part entière, de même que les serveurs web, les serveurs vocaux et vos propres applications TCP ou UDP qui tiennent derrière la même adresse protégée.

Les deux niveaux comparés

Pour la plupart des projets MTA:SA, 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.

Erreurs fréquentes et solutions

« J'ai bloqué 22126, le serveur ne figure malgré tout dans aucune liste, mais des requêtes continuent d'arriver » : alors le socket est encore ouvert. <ase>0</ase> seul ne ferme pas le port tant que <donotbroadcastlan>0</donotbroadcastlan> est en place. Vérifiez avec ss -lnup | grep 22126 que plus rien n'écoute réellement.

« Les joueurs restent bloqués sur l'écran de chargement, le jeu lui-même tourne normalement » : ce n'est pas une attaque sur 22003, c'est le serveur HTTP sur 22005 qui est à bout. Externalisez les téléchargements via httpdownloadurl et vérifiez httpmaxconnectionsperclient et httpthreadcount.

« Le serveur a disparu du navigateur, les joueurs présents ne remarquent rien » : alors seul 22126 est touché. Pour les joueurs connectés, c'est sans conséquence, pour l'arrivée de nouveaux joueurs, non. Une limitation de débit sur ce seul port est la bonne réponse, pas une limitation sur le port de jeu.

« Nous avons changé d'adresse IP et deux heures plus tard nous étions de nouveau hors ligne » : l'attaquant a obtenu la nouvelle adresse par la même source que l'ancienne, le plus souvent l'entrée dans la liste, un bot Discord interrogeant le statut ou un ancien enregistrement DNS. Un changement d'adresse fait gagner du temps, ce n'est pas une solution.

« Nous avons posé une limite de 20 paquets par seconde et par adresse sur 22003 » : c'est trop serré. Un seul joueur dépasse déjà cette valeur en synchronisation active, et plusieurs joueurs derrière la même adresse NAT se partagent le même contingent. Vous éjectez ainsi vos propres joueurs. Sur 22126, en revanche, des valeurs serrées ne posent pas de problème.

« Nous nous sommes bloqués nous-mêmes avec le pare-feu » : un redémarrage n'aide pas, parce qu'UFW rétablit ses règles au démarrage. Chez KernelHost, vous ouvrez la console VNC dans l'espace client et y exécutez ufw disable. La console VNC fonctionne indépendamment du réseau du système invité.

« 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.

« Nous attendons simplement que l'attaque passe » : les attaques qui font effet sont répétées. Documentez le moment avec le fuseau horaire, la durée, les valeurs de pointe et le port concerné. Ce sont exactement ces indications dont un ticket de support a besoin pour que le filtrage soit ajusté de façon ciblée.

En résumé

• Un serveur MTA:SA a besoin d'exactement trois ports : 22003 UDP pour le jeu, 22005 TCP pour le serveur HTTP interne et 22126 UDP pour la requête ASE. Le troisième découle fixement du port de jeu plus 123.
• La requête ASE se trouve sur un port propre et peut donc être limitée sans exclure un seul joueur. C'est la différence la plus importante avec SA-MP, où le jeu et la requête partagent le même port.
• Un unique octet de requête sur 22126 produit une réponse pouvant atteindre plusieurs kilooctets, et l'adresse source est falsifiable. Un port ASE sans frein est donc à la fois cible et amplificateur.
• Les freins intégrés de MTA agissent par adresse source : cinq requêtes en six secondes, quatre connexions en 30 secondes. Au-delà de 100 adresses sources simultanées, le comptage des requêtes est ignoré, une vague distribuée passe donc à travers.
• Le serveur HTTP interne sur 22005 est une surface d'attaque à part entière. Qui externalise les téléchargements via httpdownloadurl vers un serveur web externe les sort du jeu.
• Tout ce qui tourne sur le serveur ne décide que du sort des petites attaques. À 1 Gbit/s, la limite se situe vers 1,49 million de paquets par seconde, indépendamment de la qualité de vos règles.
• La protection permanente à deux niveaux de KernelHost est comprise sans supplément dans chaque pack serveur et travaille sans null-routing. Qui veut piloter lui-même les règles par port ajoute l'Advanced DDoS Protection à partir de 50,00 € par mois.

Si votre projet tourne déjà chez KernelHost, le filtrage est actif en permanence, vous n'avez rien à activer. Si vous constatez malgré tout des anomalies, ouvrez un ticket de support indiquant la période, le port et le comportement observé, afin que les règles soient ajustées pour votre adresse. Pendant une attaque en cours, vous pouvez également nous joindre via le chat d'urgence WhatsApp au +43 650 8209883. Si vous hébergez encore ailleurs et que vous êtes régulièrement touché, le passage à Francfort-sur-le-Main est la solution la plus courte : les étapes suivantes pour le cas aigu figurent dans l'article Attaque DDoS de forte intensité : que faire.