Team Fortress 2 : protéger un serveur TF2 des attaques DDoS

Un serveur communautaire Team Fortress 2 qui perd tous ses joueurs en même temps au milieu d'une manche, le soir, puis disparaît du navigateur de serveurs pendant plusieurs minutes, a rarement un problème de matériel. Dans la plupart des cas, une attaque est en cours sur 27015/UDP. Cet article montre comment protéger un serveur TF2 des attaques DDoS : d'abord ce que vous pouvez faire vous-même dans les dix prochaines minutes sans frais supplémentaires, ensuite l'endroit où ces mesures s'arrêtent physiquement, et pour finir ce qui doit se passer en amont, dans le réseau.

Toutes les indications se rapportent à un serveur dédié Source installé avec SteamCMD (srcds_run -game tf) 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 changez d'abord rien et ne redémarrez pas le serveur, sauvegardez plutôt les mesures de la section 9. Après l'attaque, elles auront disparu.

Pourquoi les serveurs Team Fortress 2 ont besoin d'une protection DDoS

Team Fortress 2 est gratuit depuis 2011, et c'est précisément ce qui déplace l'économie d'une attaque. Un attaquant dispose d'un nombre illimité de comptes jetables, ne paie pour aucun d'entre eux et ne risque rien en cas de bannissement. Ce qui coûte de l'argent sur un jeu payant coûte ici une minute.

S'y ajoute une particularité qui distingue TF2 de la plupart des autres jeux : depuis la mise à jour « Meet Your Match » de juillet 2016, il n'existe plus de Quickplay pour répartir automatiquement les nouveaux joueurs sur les serveurs communautaires. Les nouveaux joueurs arrivent en mode Casual sur des serveurs de Valve. Les serveurs communautaires ne se trouvent plus que par le navigateur de serveurs. Celui qui sort de cette liste n'existe pratiquement plus pour les nouveaux joueurs, même si le processus serveur tourne parfaitement. Une attaque qui se contente de chasser votre serveur de la liste a donc déjà atteint son but.

Les cibles habituelles suivent cette logique : les serveurs communautaires qui tournent en continu avec des joueurs réguliers (2Fort en continu, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), les serveurs de ligue avec un horaire de match fixe dans les compétitions ETF2L, RGL et ozfortress, ainsi que les serveurs dont l'exploitant vient de bannir quelqu'un. Le déclencheur n'est presque jamais technique. Ce qu'est une attaque DDoS, l'article Qu'est-ce qu'une attaque DDoS ? l'explique.

Les ports dont il est réellement question sur un serveur TF2

Un serveur TF2 a besoin d'exactement un port vers l'extérieur : 27015/UDP. Tout le reste est soit désactivable, soit à restreindre, soit sortant de toute façon. Ce tableau est la base de chaque règle de pare-feu qui suit :

Avec plusieurs instances sur une même machine, les numéros s'incrémentent : 27016, 27017 et ainsi de suite pour le jeu, 27021 et 27022 pour SourceTV. Le fichier de configuration se trouve sous tf/cfg/server.cfg et est relu à chaque changement de carte.

Pourquoi le port partagé 27015 est le point le plus sensible

Sur TF2, le trafic de jeu et la requête serveur partagent le même port UDP, il n'existe pas de port de requête séparé. Une requête A2S_INFO fait exactement 25 octets : quatre octets FF FF FF FF, un octet 0x54 et la chaîne de 20 octets « Source Engine Query » terminée par un zéro. La réponse, avec le nom du serveur, la carte, le nombre de joueurs et les tags, pèse plusieurs fois plus. L'agence américaine CISA chiffre à 5,5 le facteur d'amplification du protocole Steam dans son alerte TA14-017A.

Comme UDP ne connaît pas d'établissement de connexion et que les adresses source se falsifient, cela a constitué pendant des années une faille d'amplification ouverte : un attaquant interrogeait des serveurs Source tiers en indiquant l'adresse de sa victime comme expéditeur, et ces serveurs envoyaient leurs réponses à la victime. A2S_PLAYER et A2S_RULES ont toujours exigé un challenge récupéré au préalable, A2S_INFO non. Ce n'est qu'en décembre 2020 que Valve a ajouté un challenge pour A2S_INFO également : au lieu de la réponse, le serveur peut renvoyer un S2C_CHALLENGE que le demandeur doit répéter, prouvant ainsi qu'il n'a pas falsifié son adresse source.

Cela désamorce la réflexion, mais ne met pas fin au problème. Chaque paquet de requête continue d'arriver chez vous et coûte du temps de calcul avant d'être traité ou rejeté. Et un attaquant qui inonde directement votre serveur n'a de toute façon pas besoin d'amplification.

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 TF2 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, et avec quelle ligne de démarrage

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

ss -lntup

Tout ce qui est lié à 127.0.0.1 ou à ::1 n'a besoin d'aucune ouverture. Tout ce qui écoute sur 0.0.0.0 ou sur [::] est joignable depuis Internet, y compris la base de données MySQL installée au passage par un plugin de statistiques et le serveur web sur lequel se trouvent vos fichiers FastDL. Comparez le résultat avec votre ligne de démarrage :

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount VOTRE_TOKEN_GSLT

Chaque port de cette ligne est une décision consciente. La façon d'installer la base est décrite dans Installer un serveur de jeu avec SteamCMD.

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

Un serveur TF2 public a besoin d'exactement une ouverture vers l'extérieur, plus RCON pour votre propre adresse. Avec UFW, et exactement dans cet ordre, pour ne pas vous bloquer vous-même :

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 jeu et A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment 'RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Remplacez 203.0.113.10 par votre propre adresse. SourceTV ne figure pas ici, et c'est volontaire : qui ne diffuse pas démarre avec -nohltv et n'occupe même pas 27020/UDP. Cela divise par deux la surface UDP d'un serveur TF2 joignable depuis l'extérieur. Si vous diffusez des matchs de ligue, ufw allow 27020/udp vient s'y ajouter, et il faut alors définir un tv_password.

Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH. Si cela arrive quand même : les serveurs root KVM et les serveurs dédiés de KernelHost s'atteignent par la console VNC de l'espace client, qui fonctionne indépendamment du réseau du système invité.

3. Limiter les requêtes A2S sans disparaître du navigateur de serveurs

C'est ici que se trouve l'erreur la plus coûteuse du domaine : bloquer purement et simplement 27015/UDP ou lui appliquer une limitation de débit grossière éjecte vos propres joueurs et termine l'attaque dans l'intérêt de l'attaquant. Comme le trafic de jeu et les requêtes occupent le même port, la limite doit passer entre les types de paquets, pas sur le port.

Le moteur apporte pour cela trois variables de console, qui ont leur place dans tf/cfg/server.cfg :

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

La première limite le nombre de requêtes auxquelles le serveur répond par adresse source, la deuxième le total sur l'ensemble des adresses, la troisième fixe la fenêtre de moyennage en secondes. Elles évitent au CPU de produire des réponses inutiles. Les valeurs par défaut varient selon le jeu et le build, find sv_max_queries dans la console serveur montre quelles valeurs votre serveur connaît.

Sur TF2, la deuxième valeur est la délicate : elle plafonne les réponses sur l'ensemble des adresses. Réglée trop bas, elle fait que votre serveur cesse aussi de répondre aux services de listing pendant une inondation de requêtes et disparaît du navigateur de serveurs, donc du seul chemin par lequel de nouveaux joueurs vous trouvent. Commencez large et ne resserrez qu'une fois que vous pouvez mesurer que les requêtes légitimes passent.

Un cran plus bas, ce même trafic se sépare proprement. Tous les paquets sans connexion du moteur Source commencent par quatre octets à un (0xffffffff), alors que le trafic des joueurs déjà connectés n'a pas cet en-tête. On peut poser là-dessus une limitation de débit sans toucher au trafic de jeu :

table inet tf2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

Vous chargez le fichier avec nft -f. La priorité -10 fait que la règle s'applique avant la chaîne de filtrage d'UFW, et @th,64,32 lit les quatre premiers octets situés après l'en-tête UDP.

4. Intercepter les floods de paquets fragmentés qui apparaissent dans le journal sous NET_GetLong

Cette attaque est une particularité du moteur Source et touche TF2 tout particulièrement, parce que TF2 tourne aujourd'hui encore sur l'ancienne branche du moteur. À côté des paquets sans connexion habituels, le moteur connaît des paquets fragmentés : ils commencent par FE FF FF FF au lieu de FF FF FF FF et annoncent qu'un message plus grand suit en plusieurs parties. Le serveur doit conserver les parties en mémoire et attendre le reste.

C'est exactement ce dont on peut abuser. Un attaquant envoie en masse des fragments annoncés mais jamais complets, avec des adresses source falsifiées. La charge CPU monte, le jeu saccade, et les lignes contenant NET_GetLong s'accumulent dans le journal du serveur. Une seule machine y suffit, la bande passante n'est presque pas sollicitée. Les exploitants signalent cela régulièrement comme une attaque DDoS, alors que la liaison est presque vide.

Comme un client TF2 normal n'a guère de raison d'envoyer des paquets fragmentés au serveur, une limite étroite est ici défendable :

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

Cette ligne a sa place dans la même chaîne que la règle de la section 3. Vous retirez du jeu l'une des rares raisons légitimes d'envois depuis le client avec sv_allowupload 0 (voir la section 7).

5. Sortir RCON du réseau ouvert

Le protocole RCON du moteur Source transmet le mot de passe en clair par TCP. Qui peut lire le chemin entre vous et le serveur dispose ensuite de votre mot de passe RCON, et qui dispose de RCON peut changer de carte, bannir tous les joueurs et arrêter le serveur. Ce n'est pas un problème de DDoS, c'est une prise de contrôle, mais elle est régulièrement signalée comme une attaque.

Ne laissez jamais rcon_password vide et ne le composez jamais de tête, une valeur issue de openssl rand -base64 32 suffit. S'y ajoute un frein contre les tentatives de connexion :

rcon_password "VOTRE_VALEUR_ALEATOIRE"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Le serveur bannit ainsi une adresse pendant 24 heures après trois échecs en 30 secondes ; find sv_rcon montre quelles variables votre build connaît. La règle de pare-feu de la section 2 reste malgré tout plus efficace, car elle empêche la tentative d'atteindre l'application. Pour un accès depuis des raccordements changeants, mettez en place une redirection locale par SSH et adressez ensuite RCON sur 127.0.0.1 :

ssh -N -L 27015:127.0.0.1:27015 root@ADRESSE.IP.DE.VOTRE.SERVEUR

6. Plafonner les débits et laisser l'hibernation activée

Team Fortress 2 tourne à 66,67 ticks par seconde, valeur fixe. Le volume de trafic qui en résulte ne dépend pas du tick, mais de ce qu'un client a le droit de demander. Sans plafond, chaque joueur prend autant que son client réclame, et cela se paie sur votre bande passante sortante :

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

Faites le calcul une fois : avec sv_maxrate 100000, chaque joueur peut recevoir 100 kilooctets par seconde, ce qui fait 2,4 mégaoctets par seconde sur 24 places, soit environ 19 Mbit/s en sortie. Avec sv_maxrate 0, il n'y a plus de plafond. Les serveurs de ligue le font sciemment, un serveur public avec beaucoup de places ne devrait pas le faire. Les plugins qui déverrouillent le tickrate multiplient le taux de paquets par joueur, et avec lui le même calcul.

Le deuxième point est souvent mal réglé. TF2 s'endort dès que personne n'est connecté et ne consomme presque pas de CPU dans cet état. Beaucoup d'exploitants désactivent cela pour que le serveur paraisse « réveillé ». Sur une machine qui porte plusieurs instances, cela signifie que le CPU est déjà chargé au repos et qu'une attaque frappe un système déjà plein. Laissez le réglage par défaut en place :

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. Séparer le FastDL et désactiver les envois depuis les clients

Les serveurs communautaires vivent de leurs propres cartes, et c'est précisément de là que naît une deuxième surface d'attaque. Sans sv_downloadurl, chaque joueur télécharge les contenus par le canal réseau du jeu, donc par le même port et le même processus qui calcule le match en même temps. Cela représente quelques kilooctets par seconde, un fichier après l'autre, et avec une collection de cartes de 200 mégaoctets, cela bloque votre serveur pendant des minutes pour chaque joueur :

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

net_maxfilesize vaut 15 par défaut et peut être porté à 64 mégaoctets au maximum. sv_allowupload 0 empêche les clients d'envoyer leurs propres fichiers (les sprays, par exemple) au serveur et supprime ainsi l'une des rares raisons légitimes d'avoir des paquets fragmentés, celle de la section 4.

Ce qui est décisif, c'est l'emplacement de l'hôte FastDL. S'il se trouve sur la même adresse IP que le serveur de jeu, un flood HTTP contre 443/TCP suffit à remplir la liaison et à étouffer du même coup 27015/UDP. Placez le téléchargement rapide sur un autre hôte ou derrière un réseau de diffusion de contenu : une attaque contre les fichiers ne touche alors pas le jeu.

8. Limiter le système de vote, les floods de connexions et les plugins

Toute panne n'est pas une affaire de bande passante. Comme TF2 est gratuit, une attaque contre la logique de jeu ne coûte que des comptes : des floods de connexions qui occupent chaque place, du spam vocal et textuel, et des votes détournés qui éjectent les joueurs réguliers. Les réglages par défaut de TF2 sont déjà raisonnables ici, mais ils sont souvent assouplis :

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

Ce sont les valeurs par défaut : les votes sont autorisés, les votes d'exclusion non, les spectateurs ne votent pas, 150 secondes séparent deux votes, 300 après un vote rejeté, et un vote a besoin de 60 pour cent d'approbation. Qui règle sv_vote_issue_kick_allowed 1 doit savoir qu'il ouvre ainsi un outil dont on abuse à coup sûr sur un serveur public.

Tout ce qui va au-delà passe sur TF2 par SourceMod et Metamod:Source. Les deux se trouvent sous tf/addons/ et se signalent dans la console avec meta version et sm version. Contrairement à Counter-Strike 2, la base est ici mature, et les plugins pour les listes de bannissement, le contrôle à la connexion et la limitation du chat sont la voie habituelle. Deux règles à ce sujet : chaque plugin est du code dans le même processus, et un plugin qui plante emporte le serveur avec lui. Et les plugins qui apportent leurs propres services web ouvrent d'autres ports et publient parfois exactement l'adresse que vous cherchez à protéger. sm plugins list montre ce qui tourne réellement.

Le mois d'avril 2020 montre à quel point le côté moteur est à prendre au sérieux : après la fuite d'anciens états du code source de TF2 et de CS:GO, de grands exploitants communautaires comme Creators.TF et Red Sun ont temporairement arrêté leurs serveurs par crainte d'une exploitation. Gardez le binaire du serveur à jour et les extensions en phase avec la version du moteur.

9. Mesurer et journaliser avant que cela ne brûle

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 vendredi soir. Pendant un incident, quatre commandes suffisent :

ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xfffffffe"

La première commande affiche les paquets, les erreurs et les rejets par interface ; lancez-la deux fois à dix secondes d'intervalle et vous obtenez un débit au lieu d'une valeur absolue. Les deux captures séparent l'inondation de requêtes du flood de paquets fragmentés et répondent ainsi à la question de savoir laquelle des deux règles des sections 3 et 4 doit réellement agir. Limitez-les toujours avec -c, une capture à pleine charge coûte elle-même du temps de calcul.

À l'intérieur du serveur, la commande de console stats fournit en une ligne la charge CPU, la charge réseau entrante et sortante en kilooctets par seconde, les FPS du serveur et le nombre de joueurs. Si les FPS du serveur tombent nettement sous la valeur du tick alors que le nombre de joueurs est normal, le serveur travaille à autre chose qu'au jeu. La façon d'interpréter ces valeurs est expliquée dans Détecter une attaque DDoS sur son serveur.

Où ces mesures s'arrêtent : bande passante et taux de paquets

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 de la liaison. 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é.

Mettez le fonctionnement normal d'un serveur TF2 plein à côté d'une attaque réelle, et le rapport devient clair :

Un serveur de jeu classique est raccordé à 1 Gbit/s, soit 125 mégaoctets par seconde, et la liaison est pleine dès que quelqu'un envoie davantage. La deuxième grandeur est le taux de paquets, et il frappe le plus souvent plus tôt que la bande passante : chaque paquet coûte un passage dans la pile réseau, même s'il est rejeté ensuite. Une attaque qui ne remplit même pas un tiers de votre liaison paralyse donc quand même votre serveur. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout avait disparu ».

Pour situer les ordres de grandeur qui se produisent réellement : sur des serveurs KernelHost ont notamment été filtrés en temps réel un flood UDP contre un serveur de jeu avec plus de 112,2 Gbit/s à plus de 8,7 millions de paquets par seconde, ainsi qu'une attaque multivecteur contre un serveur vocal avec plus de 473,4 Gbit/s à plus de 41,5 millions de paquets par seconde. 473,4 Gbit/s représentent environ 470 fois un raccordement à 1 Gbit/s. Il n'existe aucun réglage local pour cela.

Les deux freins d'urgence les plus répandus n'aident pas. Le null-routing retire du réseau l'adresse IP attaquée et met fin à l'attaque, mais aussi à votre serveur. Une redirection réactive coûte, pendant son temps de bascule, exactement les minutes durant lesquelles le match se décide. Seul un filtrage permanent, effectué dans le réseau en amont du serveur, est efficace.

Ce que KernelHost oppose aux attaques contre les serveurs TF2

La protection permanente comprise dans chaque pack serveur

La protection DDoS de KernelHost repose sur deux niveaux et reste active en permanence dès la mise en service, sans que vous ayez quoi que ce soit à commander, à activer 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 pour un serveur TF2. Le filtrage fonctionne en permanence et n'a pas besoin de réagir d'abord à une attaque : il n'y a donc pas de temps de bascule pendant lequel vos joueurs seraient éjectés et votre serveur sortirait du navigateur de serveurs. Et aucun null-routing n'est utilisé : votre adresse IP reste dans le réseau, seuls les paquets malveillants sont rejetés. Les jeux et protocoles couverts sont listés dans Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les serveurs attaqués en continu

Certains projets ne sont pas attaqués de temps à autre, mais de façon ciblée et pendant des semaines, avec des schémas changeants et toujours pile à l'heure du match. 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 27015/UDP, sur 27020/UDP et sur 27015/TCP, 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 au lieu d'attendre la fin du match.
• Un profil de protection adapté au jeu, pour Team Fortress 2 et les autres titres Source, tout comme des profils TCP et UDP libres pour vos propres applications.

L'offre s'adresse aux serveurs hébergés chez KernelHost. Si votre serveur TF2 se trouve actuellement ailleurs et qu'il est régulièrement attaqué, le déménagement est le chemin vers cette protection.

Les deux niveaux comparés

Pour la plupart des serveurs communautaires TF2, 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

« Le serveur tourne, mais il n'apparaît plus dans le navigateur de serveurs » : vérifiez d'abord le Game Server Login Token. Les serveurs TF2 ont besoin d'un token pour l'inscription publique, défini via sv_setsteamaccount et généré pour l'App ID 440. Steam retire les tokens qui n'ont pas été utilisés pendant 30 jours. Un serveur qui disparaît après une longue pause n'a donc souvent besoin que d'un nouveau token et n'est pas attaqué du tout. Ce n'est qu'ensuite que viennent un sv_max_queries_sec_global trop bas ou une règle de pare-feu trop grossière sur 27015/UDP.

« Le CPU est à 100 pour cent, la liaison est presque vide » : c'est l'image typique d'une inondation de requêtes ou d'un flood de paquets fragmentés. Cherchez dans le journal du serveur les lignes contenant NET_GetLong et mesurez avec les deux lignes tcpdump de la section 9 quel type de paquets arrive.

« Mes règles nftables ou iptables ne s'appliquent pas » : trois causes sont fréquentes. La règle se trouve derrière les chaînes UFW et n'est jamais atteinte (d'où la priorité -10), elle a disparu au dernier redémarrage, ou bien l'attaque est volumétrique et la règle travaille correctement sur une liaison déjà pleine. Vérifiez avec nft list ruleset si les compteurs augmentent. S'ils restent à zéro, la règle n'est jamais atteinte.

« J'ai changé d'adresse IP et j'étais de nouveau hors ligne le lendemain » : l'attaquant trouve la nouvelle adresse à la même source que l'ancienne. Votre serveur la publie lui-même dès qu'il figure de nouveau dans le navigateur de serveurs, et les anciens enregistrements DNS ainsi que les bots de statut Discord font le reste. Un changement d'adresse fait gagner des heures, ce n'est pas une solution.

« Le serveur plante de façon reproductible sans que la bande passante sorte de l'ordinaire » : le plus souvent, ce n'est pas une attaque DDoS, mais un plugin qui ne correspond pas à la version du moteur, ou un binaire de serveur obsolète. sm plugins list et une comparaison des versions vont ici plus vite que n'importe quelle règle de filtrage.

« Le serveur répond avec du retard après une période d'inactivité » : c'est l'hibernation, ce n'est pas un défaut. Elle abaisse la charge CPU à presque zéro tant que personne n'est connecté, et c'est exactement l'état dans lequel vous voulez avoir des réserves.

« Des commandes d'administration étrangères s'exécutent sur le serveur » : ce n'est pas une attaque DDoS, mais un accès RCON compromis. Changez immédiatement le mot de passe, restreignez le port à votre propre adresse, et n'oubliez pas que le mot de passe circule en clair sur la liaison.

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

En résumé

• Un serveur TF2 a besoin vers l'extérieur d'exactement 27015/UDP. RCON sur 27015/TCP doit être restreint à votre propre adresse, SourceTV sur 27020/UDP se désactive avec -nohltv si vous ne diffusez pas.
• Le trafic de jeu et la requête A2S partagent le même port. Qui bloque ou limite globalement 27015/UDP éjecte ses propres joueurs. La limite doit passer entre les types de paquets, reconnaissables aux quatre premiers octets situés après l'en-tête UDP.
• Les floods de paquets fragmentés portant l'en-tête FE FF FF FF produisent de la charge CPU au lieu de la bande passante et apparaissent dans le journal sous NET_GetLong. Une limite étroite sur ce type de paquets est défendable sur TF2.
• Depuis « Meet Your Match », les nouveaux joueurs ne trouvent les serveurs communautaires que par le navigateur de serveurs. Toute mesure qui vous chasse de la liste agit comme l'attaque elle-même.
• Un serveur plein de 24 places traite environ 1 600 paquets entrants par seconde. Les attaques contre les serveurs de jeu communautaires se situent d'ordinaire entre 5 et 50 Gbit/s et plusieurs millions de paquets par seconde.
• Avec des paquets de taille minimale, 1 Gbit/s transporte environ 1,49 million de paquets par seconde. Au-delà de cette limite, seul le réseau en amont du serveur est déterminant, aucune règle sur le serveur.
• Chez KernelHost, la protection permanente à deux niveaux est comprise sans supplément dans chaque pack serveur et active dès la mise en service, sans null-routing. L'Advanced DDoS Protection s'y ajoute à partir de 50,00 € par mois si vous voulez piloter vous-même les règles par port.

Si votre serveur tourne déjà 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. Indiquez d'emblée quatre informations : adresse IP, port, période dans votre fuseau horaire et ce que vous observez. Cela évite un aller-retour de questions, et cet aller-retour compte quand un match est en cours.