Protéger un serveur Terraria des attaques DDoS

Qui veut protéger son serveur Terraria des attaques DDoS a affaire à un cas particulier : Terraria ne parle que TCP. Le trafic de jeu passe par un seul port, 7777 TCP, et le jeu n'ouvre aucun port UDP. Presque tous les conseils qui circulent sur le réseau à propos de la protection des serveurs de jeu sont écrits pour des jeux UDP et tombent ici soit dans le vide, soit au mauvais endroit.

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 à un serveur dédié Terraria (vanilla, TShock ou tModLoader) 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. Si l'attaque est en cours, ne modifiez d'abord rien à la configuration et ne redémarrez pas le serveur : sauvegardez vos mesures (voir la section « Journaliser »), après l'attaque elles auront disparu.

Pourquoi ce sont justement les serveurs Terraria qui sont touchés par les attaques DDoS

Les serveurs Terraria sont une cible commode, parce que leur adresse est forcément publique. Terraria vanilla n'a pas de navigateur de serveurs intégré : les joueurs se connectent via « Multiplayer » puis « Join via IP », donc via une adresse que quelqu'un a dû faire connaître au préalable. Qui veut de nouveaux joueurs inscrit son serveur sur des sites de listes comme terraria-servers.com, tserverweb.com ou topg.org, ou bien diffuse l'adresse par Discord. Chacun de ces chemins livre à un attaquant exactement ce qu'il livre au joueur : l'adresse IP et le port en clair.

Lorsqu'un serveur Terraria passe sans cesse hors ligne alors que rien n'a changé au matériel, au monde ni à la liste de mods, une attaque est donc l'explication la plus probable. S'y ajoute la constellation typique d'un projet : horaires de jeu fixes, serveurs concurrents, joueurs bannis et conflits dans la communauté. Une attaque ne coûte à son commanditaire ni compétence particulière ni argent notable, un Terraria server booter se vend en abonnement pour quelques euros par mois. Ce qu'est techniquement une attaque DDoS et comment elle est construite, l'article Qu'est-ce qu'une attaque DDoS ? l'explique en détail.

Terraria passe par TCP, pas par UDP

C'est la différence la plus importante avec pratiquement tout autre serveur de jeu. Le serveur dédié Terraria accepte les connexions avec un écouteur TCP (dans le moteur du jeu, la classe Terraria.Net.Sockets.TcpSocket) et n'ouvre aucun socket UDP. Cela a quatre conséquences qui déterminent toute votre défense :

• Une connexion TCP entièrement établie ne peut pas être falsifiée. L'attaquant doit recevoir le SYN-ACK du serveur pour achever le handshake. Celui qui est réellement connecté vient donc d'une adresse réelle. Les blocages d'IP et les plafonds de connexions agissent de ce fait nettement mieux chez Terraria que sur un jeu UDP.
• Un SYN flood se falsifie en revanche très bien, parce qu'il n'achève jamais le handshake. Contre ce type d'attaque, aucun blocage d'IP n'agit, seuls les SYN cookies et le filtrage en amont.
• Chaque connexion TCP acceptée vers le port 7777 occupe des ressources dans le processus de jeu, pas seulement dans le noyau. Cela fait de l'épuisement des slots l'attaque la plus efficace avec la bande passante la plus faible.
• Un UDP flood frappe malgré tout votre serveur. Les paquets n'ont pas besoin d'être acceptés pour remplir votre raccordement. Que Terraria ne parle pas UDP ne protège pas le raccordement, cela empêche seulement que le processus de jeu traite lui-même les paquets.

Il existe une exception : si l'on démarre le serveur dédié avec -steam et -lobby friends ou -lobby private, la connexion passe par le réseau Steam et donc par des ports UDP dans la plage 27000 à 27100. C'est un autre mode de fonctionnement, et non le serveur classique joignable par son adresse IP.

Les ports dont il est réellement question

Un serveur Terraria a besoin d'exactement un port sur le réseau ouvert : 7777 TCP. Tout le reste dans ce tableau n'a soit rien à faire sur Internet, soit uniquement sur votre propre adresse.

Que Terraria ne connaisse ni port de requête ni RCON est une bonne nouvelle pour la sécurisation : les deux points d'accès qui, chez Counter-Strike, Rust ou ARK, sont régulièrement détournés pour des attaques par réflexion n'existent tout simplement pas ici. En contrepartie, la surface d'attaque est d'autant plus concentrée sur le port 7777, et qui utilise TShock s'ajoute une seconde surface avec le port 7878.

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 Terraria 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 -lntup

La colonne qui compte est celle de l'adresse locale. 0.0.0.0:7777 signifie « joignable depuis tout Internet », 127.0.0.1:7878 signifie « en local uniquement » et ne demande aucune règle de pare-feu. Si une entrée UDP apparaît dans cette liste pour votre processus Terraria, c'est que le serveur tourne en mode Steam. 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. Ne laisser ouvert que 7777 TCP et fermer tout le reste

Pour Terraria, une seule autorisation vers l'extérieur suffit. Vous n'avez besoin d'aucune règle UDP, et une règle UDP pour 7777 serait tout simplement fausse : elle laisserait passer du trafic vers un port sur lequel rien n'écoute. Avec UFW, cela donne ceci, et exactement dans cet ordre, pour ne pas vous bloquer vous-même :

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/tcp comment 'Terraria'
ufw allow from 203.0.113.10 to any port 7878 proto tcp comment 'TShock REST'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Remplacez 203.0.113.10 par votre propre adresse. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH. Qui exploite un panel restreint également 8080 et 2022 à sa propre adresse.

3. serverconfig.txt : bien régler le mot de passe, maxplayers et secure

Le fichier de configuration central du serveur Terraria s'appelle serverconfig.txt et se passe au démarrage avec -config serverconfig.txt. Quatre directives sont décisives pour la sécurisation :

port=7777
maxplayers=16
password=UnLongMotDePasseAleatoire
secure=1
upnp=0
banlist=banlist.txt

password= est la mesure gratuite la plus efficace contre les floods de connexions qui empruntent le chemin normal. La raison tient au protocole : un client envoie d'abord le message 1 avec son identifiant de version (par exemple Terraria279), le serveur répond par le message 37 si un mot de passe est défini, le client doit répondre correctement par le message 38, et ce n'est qu'ensuite que le serveur envoie par le message 3 l'autorisation avec le slot de joueur. Sans le bon mot de passe, un attaquant n'atteint donc jamais la transmission du monde, qui est la partie coûteuse d'une connexion.

maxplayers accepte des valeurs de 1 à 255, la valeur par défaut est 16 (avant la version 1.4.0.1, elle était de 8). La limite supérieure de 255 n'est pas un chiffre arbitraire : Terraria adresse les joueurs avec un seul octet. Ne réglez pas maxplayers plus haut que ce dont vous avez réellement besoin, car chaque slot est une ressource qu'un attaquant peut occuper. secure=1 active le contrôle anti-triche intégré (en ligne de commande -secure), upnp=0 empêche le serveur d'ouvrir de sa propre initiative des ports sur un routeur.

4. Sécuriser TShock : l'API REST sur 7878 et les floods de connexion

TShock est l'extension serveur la plus répandue pour Terraria et apporte avec son API REST une seconde surface d'attaque à part entière. Elle se trouve par défaut sur le port 7878 TCP et se configure dans tshock/config.json, donc pas dans serverconfig.txt. À la livraison, elle est désactivée ("RestApiEnabled": false), et c'est exactement ainsi qu'elle devrait rester tant que vous n'en avez pas besoin.

Si vous en avez besoin, ces valeurs sont pertinentes :

"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1

Deux points sont importants. Premièrement, le point d'accès /status livre sans jeton le nom du serveur, le port, le nombre de joueurs et les noms des joueurs, tant que EnableTokenEndpointAuthentication est sur false. C'est pratique pour les pages de statut et les bots Discord, et c'est en même temps un renseignement gratuit pour tout attaquant qui veut savoir quand une attaque est rentable. Deuxièmement, le point d'accès /v2/token/create produit un jeton d'accès à partir d'un nom d'utilisateur et d'un mot de passe, et il est joignable depuis l'extérieur dès que le port 7878 est ouvert : une attaque par essais de mots de passe contre votre compte d'administration, qui coûte au passage du temps de calcul. Le seau formé par RESTMaximumRequestsPerInterval et RESTRequestBucketDecreaseIntervalMinutes freine cela, mais ne remplace pas une règle de pare-feu.

Pour l'accès au jeu lui-même, d'autres valeurs de TShock entrent en jeu. MaximumLoginAttempts est à 3 et éjecte un joueur après trois tentatives infructueuses. RequireLogin (false par défaut) exige un compte pour chaque joueur. EnableIPBans (true par défaut) et KickProxyUsers (true par défaut) sont particulièrement efficaces sur un jeu TCP, parce que l'adresse source d'une connexion établie ne peut justement pas être falsifiée. Contre le griefing, souvent signalé comme une attaque, agissent les seuils TileKillThreshold (60), TilePlaceThreshold (20), TileLiquidThreshold (15) et ProjectileThreshold (50), chaque fois en actions par seconde.

5. Limiter les connexions par adresse source et vérifier les SYN cookies

Parce que Terraria fonctionne sur TCP, la règle locale la plus efficace est un plafond de connexions simultanées par adresse source. Un vrai joueur en a besoin d'exactement une :

iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m hashlimit --hashlimit-name terraria_syn --hashlimit-mode srcip --hashlimit-above 10/min --hashlimit-burst 20 -j DROP

La première règle rejette les nouvelles connexions dès qu'une adresse en a plus de trois ouvertes en même temps. La seconde limite à dix par minute le rythme des tentatives de connexion issues de la même source, avec une marge de 20. Ces deux chiffres sont des valeurs de départ, pas des vérités : un serveur situé derrière un raccordement partagé (colocation, réseau scolaire, opérateur mobile) voit plusieurs joueurs légitimes sous la même adresse. Mesurez d'abord pendant une semaine en fonctionnement normal.

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. Contre les paquets SYN falsifiés, qui n'achèvent jamais le handshake, aucune de ces règles n'agit : c'est le noyau lui-même qui s'en charge. Vérifiez les trois valeurs :

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

net.ipv4.tcp_syncookies doit être à 1, ce qui est en général déjà le cas sous Debian et Ubuntu. Les SYN cookies se passent de la file d'attente des connexions à demi ouvertes et reconstruisent l'état à partir de la réponse du client, un SYN flood tombe ainsi dans le vide tant que le raccordement n'est pas saturé. net.core.somaxconn est à 4096 depuis Linux 5.4 et était à 128 auparavant : si la valeur est faible, le noyau rejette des connexions entièrement établies avant même que le processus de jeu puisse les accepter.

6. Empêcher l'épuisement des slots : pourquoi un scan de ports remplit votre serveur

L'épuisement des slots est l'attaque efficace la moins chère contre un serveur Terraria : l'attaquant ouvre vers le port 7777 autant de connexions TCP que le serveur a de slots de joueurs, et il les maintient ouvertes. Cela ne lui coûte presque aucune bande passante, mais remplit le serveur. Les vrais joueurs voient « Server is full » et n'entrent plus, alors que rien d'anormal ne se passe sur votre raccordement. C'est précisément pour cela que les exploitants de serveurs Terraria ne remarquent souvent pas qu'ils sont attaqués.

La cause tient à la façon de compter : une connexion est acceptée avant même que le client ait envoyé son identifiant de version. Historiquement, ces connexions fantômes restaient occupées jusqu'à l'expiration de la session TCP. La série 1.4.5 a atténué cela : plus aucun slot n'y est réservé pour les clients qui se déconnectent aussitôt. Dans les premières versions de 1.4.5.7 et 1.4.5.8, le serveur dédié plantait toutefois avec une ObjectDisposedException non gérée dès qu'une connexion TCP était ouverte sans que le handshake soit achevé. Un nc -z ou un test d'accessibilité d'un système de monitoring y suffisait. Le défaut a été corrigé discrètement en quelques semaines, il subsiste en partie dans d'anciennes images de conteneurs. Maintenez donc la version de votre serveur à jour, ce n'est pas ici un lieu commun, mais une question concrète de disponibilité.

Deux réglages aident en plus. Qui utilise TShock met MaxSlots sur le nombre de joueurs souhaité et maxplayers dans serverconfig.txt deux places plus haut : TShock rejette alors les connexions excédentaires avec un message propre, au lieu que le processus de jeu les laisse entrer dans la dernière place libre. Et le plafond de connexions de la section précédente est exactement la règle qui empêche une adresse unique d'occuper tous les slots d'un coup.

7. Désactiver UPnP et ne pas publier l'adresse soi-même

Par défaut, le serveur Terraria tente d'ouvrir son port sur un routeur par UPnP. Sur un serveur loué, c'est sans effet ; dans un réseau domestique, cela ouvre des ports dont vous ne saurez plus rien par la suite. Désactivez-le avec upnp=0 dans serverconfig.txt ou avec -noupnp en ligne de commande.

Ici, mieux vaut en outre l'honnêteté que la pensée magique : votre adresse IP ne peut pas rester secrète. Tout joueur qui s'est connecté une fois la connaît, et une inscription sur un site de listes la publie de toute façon. Deux habitudes sont efficaces. Ne publiez jamais l'adresse IP brute vous-même, mais faites passer vos joueurs par un nom d'hôte : le client Terraria résout un nom d'hôte, vous pouvez donc changer d'adresse le jour venu sans casser toutes les références. Et faites le ménage dans les anciens enregistrements DNS, car un enregistrement A oublié qui pointe encore vers l'adresse précédente rend tout changement inopérant.

8. Mettre les requêtes de statut en cache au lieu de les répercuter

Comme Terraria n'a pas de protocole de requête, les pages de statut, les bots Discord et les sites de listes déterminent l'état de votre serveur par l'un de ces deux chemins : soit ils établissent une vraie connexion TCP vers 7777 et se font passer pour un client, soit ils interrogent l'API REST de TShock. Les deux coûtent du travail à votre serveur, et les deux évoluent avec le nombre de demandeurs.

La contre-mesure ne coûte rien : n'interrogez jamais depuis le visiteur. Laissez un seul service récupérer le statut à intervalle fixe (30 ou 60 secondes suffisent), mettez le résultat en cache et livrez à tous les visiteurs l'état mis en cache. Une page de statut très fréquentée produit ainsi une requête par intervalle au lieu d'une par visiteur. Qui utilise l'API REST pour cela restreint le port 7878 à l'adresse de ce seul service.

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, cinq commandes suffisent :

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

La troisième commande est celle qui est propre à Terraria : elle compte les connexions à demi ouvertes. Une valeur à deux chiffres est normale, une valeur à quatre ou cinq chiffres est un SYN flood. ss -s montre à côté le nombre total de connexions TCP, et si ce nombre correspond à peu près à votre maxplayers alors que personne n'est en jeu, vous voyez un épuisement des slots. 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.

Là 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. Les attaques contre des projets de serveur de jeu de cette taille se situent d'ordinaire entre 5 et 50 Gbit/s, soit cinq à cinquante fois votre raccordement. La qualité de votre règle connlimit placée derrière n'a alors plus aucune importance, car les paquets de vos joueurs ne passent déjà plus en amont. C'est exactement ainsi que naissent les pics de lag d'un serveur Terraria, ceux où la charge CPU paraît normale.

La deuxième grandeur est le taux de paquets, et il frappe souvent plus tôt que la bande passante. 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 SYN flood, la limite est encore plus basse, parce que chaque paquet SYN déclenche une décision d'état : quelques dizaines de milliers de paquets SYN par seconde suffisent déjà à paralyser l'acceptation des connexions d'un Linux standard, bien avant que le raccordement soit saturé. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout avait disparu ».

Et le troisième point est celui que l'on oublie le plus souvent chez Terraria : un attaquant ne se règle pas sur votre protocole. Il envoie des floods UDP et du trafic de réflexion vers votre adresse, bien qu'aucun port UDP n'écoute. Votre serveur rejette ces paquets correctement, mais ils ont déjà occupé votre raccordement, et votre serveur Terraria passe hors ligne sans qu'un seul paquet ait atteint le processus de 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 et un UDP flood de plus de 112,2 Gbit/s contre un serveur de jeu. 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

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. Pour Terraria, cela signifie concrètement que les floods SYN et les floods de connexions contre 7777 TCP s'arrêtent là, et non sur votre carte réseau.

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. 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. Le site est Francfort-sur-le-Main. 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. Pour ces cas, il existe l'Advanced DDoS Protection à partir de 50,00 € par mois, en PrePaid, sans durée minimale et sans frais de mise en service. 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 ce qui est autorisé sur 7777 TCP et vous pouvez fermer tout le reste, sans avoir à ouvrir de ticket.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages pendant une attaque en cours, par exemple resserrer le rythme de connexions autorisé par adresse source.
• Un profil de protection adapté à l'application. Des profils adaptés existent pour les jeux TCP comme Terraria et pour les applications maison ou modifiées sur n'importe quel port TCP ou UDP.

Les deux niveaux comparés

Pour la plupart des projets Terraria, 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. Qui exploite actuellement son serveur ailleurs n'obtient pas la protection en complément, mais par le déménagement chez KernelHost : le filtrage fait partie du réseau, ce n'est pas un ajout sur le serveur.

Erreurs fréquentes et solutions

« Le serveur est plein, mais il n'y a personne dedans » : c'est un épuisement des slots. Vérifiez avec ss -tn dst :7777 | wc -l combien de connexions sont réellement ouvertes et comparez avec la liste des joueurs (console du serveur : playing). Si les chiffres ne concordent pas, des connexions étrangères occupent les slots. Les remèdes sont le plafond de connexions par adresse source, un mot de passe de serveur et une version de serveur à jour.

« J'ai ouvert 7777 UDP et cela ne change rien » : c'est exact, car rien n'écoute sur 7777 UDP. Terraria n'utilise que TCP. L'ouverture UDP ne nuit pas directement, mais c'est une ouverture inutile et un signe certain qu'un tutoriel écrit pour un autre jeu a été recopié.

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

« Des joueurs se font éjecter alors qu'aucune attaque n'est en cours » : si vous resserrez trop votre limite connlimit, cela touche les joueurs derrière des raccordements partagés. En TCP, cela arrive plus vite que sur les jeux UDP, parce qu'une reconnexion après une coupure crée aussitôt une nouvelle connexion alors que l'ancienne est encore en TIME_WAIT. Augmentez la valeur par paliers et observez les compteurs de correspondances.

« Le serveur saccade, le raccordement est calme » : c'est plus souvent un mod ou un plugin qu'une attaque. Sous tModLoader, chaque mod supplémentaire coûte du temps de calcul dans le même processus, et un monde comptant beaucoup d'entités sature entièrement un cœur sans qu'un seul paquet de trop arrive. Si sar -n DEV 1 10 ne montre rien d'anormal, ce n'était pas une attaque DDoS.

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

En résumé

• Un serveur Terraria a besoin d'exactement un port ouvert : 7777 TCP. Le jeu n'ouvre aucun socket UDP, n'a pas de protocole de requête et pas de RCON.
• L'API REST de TShock sur le port 7878 TCP est la seconde surface d'attaque. Laissez RestApiEnabled sur false ou restreignez le port à votre propre adresse.
• Un mot de passe de serveur dans serverconfig.txt est la mesure gratuite la plus efficace, parce qu'un attaquant sans réponse correcte au message 37 n'atteint jamais la transmission du monde.
• L'épuisement des slots est chez Terraria l'attaque la moins chère : chaque connexion TCP acceptée vers 7777 occupe une place, sans bande passante notable. Y répondent un plafond par adresse source, un mot de passe et une version de serveur à jour.
• Parce que Terraria utilise TCP, l'adresse source d'une connexion établie ne peut pas être falsifiée : les blocages d'IP agissent ici mieux que sur les jeux UDP. Contre les floods SYN falsifiés, seuls les SYN cookies et le filtrage en amont aident.
• Un UDP flood paralyse votre serveur Terraria bien qu'il ne parle pas UDP, car il remplit le raccordement avant que le processus de jeu voie quoi que ce soit.
• À partir d'environ la taille de la bande passante de votre raccordement, seul le réseau en amont du serveur décide. Chez KernelHost, ce filtrage est à deux niveaux, actif en permanence et compris sans supplément dans chaque pack serveur.

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.