Protéger un serveur Call of Duty des attaques DDoS

Protéger un serveur Call of Duty des attaques DDoS est, sur les titres classiques, une tâche agréablement concrète : il s'agit d'un seul port UDP, d'une poignée de dvars dans server.cfg et d'un vecteur d'amplification que le moteur traîne depuis 2003. Un serveur qui perd tous ses joueurs d'un coup le soir, en pleine partie, a en revanche rarement un problème de matériel. La plupart du temps, une attaque est en cours, et elle survient précisément au moment où le serveur est plein.

Cet article montre d'abord pour quels titres il vaut, ensuite ce que vous pouvez sécuriser vous-même sans frais supplémentaires, puis où ces mesures s'arrêtent techniquement, et pour finir ce qui doit alors se passer dans le réseau, en amont du serveur. Les commandes sont écrites pour Debian 12, Debian 13, Ubuntu 22.04 LTS et Ubuntu 24.04 LTS et supposent root ; en tant qu'utilisateur normal, faites-les précéder de sudo.

Si l'attaque est en cours : ne modifiez rien dans server.cfg maintenant et ne redémarrez pas le serveur. Sauvegardez d'abord les mesures (voir la section « Journaliser »), après l'attaque elles auront disparu.

Pour quels titres Call of Duty pouvez-vous protéger un serveur contre le DDoS

Vous ne pouvez protéger un serveur Call of Duty du DDoS que sur les titres qui autorisent des serveurs dédiés propres. Ce sont les versions originales de Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare et Call of Duty World at War, auxquelles s'ajoutent les plateformes communautaires Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) et CoD4X (Call of Duty 4). Tous ces titres suivent le même schéma : un fichier server.cfg, un port UDP ouvert et une entrée dans une liste de serveurs publique.

Cet article ne vaut expressément pas pour les épisodes modernes. Warzone, Modern Warfare (2019), Black Ops Cold War, Vanguard, Modern Warfare II, Modern Warfare III et Black Ops 6 ne connaissent aucun serveur dédié louable : les parties se déroulent sur l'infrastructure de matchmaking d'Activision, il n'existe ni server.cfg, ni navigateur de serveurs, ni port que vous pourriez ouvrir ou sécuriser. Les listes de ports qu'Activision publie pour ces titres (entre autres TCP 3074 et 27014 à 27050 ainsi que UDP 3074, 3478 et 27000 à 27031) décrivent des ports de client et de plateforme, pas des ports de serveur. Qui subit des coupures de connexion dans Warzone a un problème sur son propre raccordement ou un problème chez Activision, mais aucun qu'un serveur loué résoudrait.

Pourquoi ce sont précisément les serveurs Call of Duty qui sont attaqués

Les serveurs Call of Duty réunissent quatre caractéristiques qui en font une cible commode. Premièrement, chaque serveur listé publie son adresse de lui-même : l'entrée dans la liste des serveurs contient l'adresse IP et le port en clair, sans quoi personne ne pourrait le rejoindre. Deuxièmement, tout le trafic passe par UDP, et UDP ne prévoit aucun établissement de connexion que l'on pourrait exiger, les adresses d'expéditeur se falsifient. Troisièmement, le moteur répond aux requêtes de statut de n'importe qui, sans que personne ait besoin de lancer le jeu. Quatrièmement, la télécommande RCON se trouve sur le même port que le jeu lui-même.

S'y ajoute la part sociale : joueurs bannis, concurrence entre clans, querelles dans une communauté qui se connaît depuis des années. Une attaque ne coûte à celui qui la lance ni compétence particulière ni argent notable, les booters et stressers se vendent sous forme d'abonnement pour quelques euros par mois, et les attaques par amplification via des serveurs de jeu y font partie de l'offre standard. Ce qu'est précisément une attaque DDoS, l'article Qu'est-ce qu'une attaque DDoS ? l'explique en détail.

Les ports dont il est réellement question

Un serveur Call of Duty classique occupe exactement un port UDP, à savoir 28960. Trois choses passent en même temps par ce port unique : le trafic de jeu, les requêtes de statut de la liste des serveurs et la télécommande RCON. Il n'existe ni port de requête propre ni port RCON propre. La ligne de démarrage d'un serveur dédié est la même pour tous les titres, seul le nom du fichier exécutable diffère :

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

Les ports des serveurs maîtres n'ont pas leur place dans vos autorisations de pare-feu. 20810 et 20800 sont des ports de destination en face, pas des ports d'écoute sur votre machine : votre serveur s'adresse à la liste de sa propre initiative. Beaucoup de guides d'ouverture de ports recommandent malgré tout de les ouvrir en entrée. Cela agrandit la surface d'attaque sans la moindre contrepartie.

Ordres de grandeur habituels chez Call of Duty

Le second tableau est le plus important si vous voulez évaluer si vous pouvez encore vous en sortir seul. Il met la charge normale d'un serveur plein en regard des chiffres dont il est question lors d'une attaque.

Pourquoi le jeu, la requête et RCON se trouvent sur le même port

C'est la particularité décisive de Call of Duty. Le moteur id Tech 3, sur lequel reposent tous les titres classiques de Call of Duty, ne connaît pas de ports séparés pour le jeu, la requête et la télécommande. Tout passe par des paquets dits sans connexion sur le port UDP unique. Un paquet sans connexion est un paquet UDP qui commence par quatre octets 0xFF et porte ensuite le nom de la commande en clair : getstatus, getinfo, getchallenge, connect ou rcon.

La conséquence pratique est gênante : vous ne pouvez pas séparer RCON du jeu par le pare-feu sans bloquer le jeu avec lui. Une règle sur le port 28960 touche toujours tout. Qui veut trier précisément les floods de requêtes et les attaques RCON doit regarder le contenu du paquet et pas seulement le numéro de port. C'est exactement pour cela que les règles de pare-feu fondées sur les ports atteignent leur limite plus tôt chez Call of Duty que chez les jeux disposant d'un port de requête distinct.

Qu'est-ce que la réflexion getstatus chez Call of Duty ?

La réflexion getstatus est une attaque par amplification dans laquelle un attaquant envoie de petites requêtes de statut avec une adresse d'expéditeur falsifiée à de nombreux serveurs de jeu, afin que leurs réponses nettement plus volumineuses atterrissent chez la véritable victime. Les serveurs de jeu ne sont pas la cible, mais l'amplificateur. Ce vecteur est documenté pour le moteur id Tech 3 depuis plus d'une décennie et concerne Call of Duty tout autant que Quake 3 et ses autres dérivés.

Vous êtes touché deux fois, et depuis deux directions. En tant que victime, vous recevez un flot de requêtes getstatus qui consomment du temps de calcul et de la bande passante sortante, et vos joueurs le ressentent comme des pics de lag. En tant qu'amplificateur involontaire, vous expédiez des réponses vers une victime étrangère, et la plainte pour abus vous revient. Les deux se produisent sur le même port, avec les mêmes paquets, et les deux paraissent d'abord anodins sur le graphique de charge.

À quoi ressemble un paquet getstatus

La requête se compose de quatre octets 0xFF et du mot getstatus, soit 13 octets de charge utile. Avec l'en-tête IP et l'en-tête UDP, cela fait 41 octets sur le raccordement. C'est précisément ce que vise le contrôle de longueur dans les règles de pare-feu qui circulent depuis des années sur les forums Call of Duty :

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

La réponse est incomparablement plus grande. Un statusResponse contient toute la configuration du serveur sous forme de chaîne de caractères, plus une ligne par joueur connecté, donc plusieurs kilooctets sur un serveur plein. La CISA attribue au protocole réseau Quake, dans son panorama des attaques par amplification UDP (TA14-017A), un facteur d'amplification de 63,9 et désigne expressément comme commande détournée l'échange d'informations sur le serveur. Ainsi, 1 Mbit/s de requêtes falsifiées devient environ 64 Mbit/s chez la victime. À titre de comparaison : dans le même panorama, le DNS se situe entre 28 et 54, le NTP à 556,9.

Le frein intégré : sv_queryIgnoreTime et sv_queryIgnoreMegs

Depuis la version de serveur 1.7, Call of Duty 4 dispose d'un frein de requête intégré. Il retient chaque adresse ayant envoyé une requête de statut et ignore les requêtes suivantes de la même adresse pendant une durée réglable. Quatre dvars le pilotent, avec ces valeurs par défaut :

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs détermine la quantité de mémoire vive que la liste d'ignorance a le droit d'occuper. 1 mégaoctet contient environ 65 000 adresses, chaque mégaoctet supplémentaire environ 87 000 de plus. La valeur 0 désactive complètement le frein, et c'est exactement le cas sur de nombreux serveurs, parce que la configuration provient d'un ancien modèle. sv_queryIgnoreTime est la durée de blocage en millisecondes. sv_queryBounceIgnoreTime s'applique lorsqu'une réponse revient avec « ICMP Port Unreachable », donc précisément quand votre serveur est en train d'être détourné en amplificateur contre une victime étrangère. sv_queryIgnoreDebug 1 écrit les correspondances dans le journal, pour que vous puissiez au moins voir s'il se passe quelque chose.

Qui utilise CoD4X dispose en plus de plafonds fixes dans le code du serveur : au plus 20 réponses getstatus par tranche de 20 secondes, au plus 100 réponses getinfo par tranche de 100 secondes et au plus un message d'erreur RCON toutes les 100 millisecondes. Le commentaire dans le code source énonce clairement l'intention : le serveur peut bien se laisser inonder, mais il ne doit pas gaspiller de bande passante sortante ce faisant. C'est la bonne priorité, mais cela ne remplace pas un filtrage en amont du serveur.

Pourquoi RCON est historiquement un problème chez Call of Duty

RCON est la télécommande du serveur, et chez Call of Duty c'est un paquet UDP non chiffré sur le port de jeu. Sur le raccordement, une commande RCON se présente ainsi : quatre octets 0xFF, puis le mot rcon, puis le mot de passe en clair, puis la commande elle-même. Il n'y a ni chiffrement, ni session, ni compte utilisateur, ni second facteur. Trois problèmes en découlent, et tous sont réels :

• Interception. Qui voit le trafic à un endroit quelconque du trajet lit votre mot de passe RCON en clair. Cela vaut pour chaque réseau entre vous et le serveur, et pour chaque outil auquel vous confiez le mot de passe.
• Devinette. Il n'existe aucune connexion que l'on pourrait verrouiller, ni blocage de compte après dix échecs. Un attaquant essaie des mots de passe à la vitesse qu'il veut. Le serveur d'origine ne freine rien du tout, CoD4X freine seulement la réponse à un message d'erreur toutes les 100 millisecondes et journalise la tentative comme « Bad rcon ».
• Réflexion. Un message d'erreur RCON est lui aussi une réponse à un paquet falsifié. Qui bombarde votre serveur de paquets RCON falsifiés s'en sert comme d'un petit amplificateur, et votre serveur remplit au passage son propre journal.

La conséquence pratique : ne définissez rcon_password que si vous avez réellement besoin de RCON. Si oui, alors long et aléatoire. CoD4X exige au moins huit caractères, c'est un plancher et non une recommandation. Au quotidien, administrez par SSH et par la console du serveur plutôt que par RCON depuis le réseau ouvert. Et si vous exploitez un outil de gestion comme IW4MAdmin, qui communique lui-même par RCON, son interface web sur le port 1624 n'a pas sa place sur le réseau ouvert.

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 Call of Duty 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:28960 et [::]:28960 signifient « joignable depuis tout Internet », 127.0.0.1:3306 signifie « en local uniquement » et ne demande aucune règle de pare-feu. À côté du jeu, on y trouve souvent IW4MAdmin, un serveur web pour le Fast Download, une base de données pour les statistiques et une seconde instance de jeu oubliée. Le point de vue de l'attaquant, lui, s'obtient par un scan de ports depuis l'extérieur :

nmap -Pn -sU -p 28960-28970,4976,27016 ADRESSE.IP.DE.VOTRE.SERVEUR
nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

2. Ne laisser ouvert que ce dont le jeu a réellement besoin

Pour un serveur Call of Duty unique, une seule autorisation vers l'extérieur suffit, tout le reste est restreint ou n'est tout simplement jamais publié. 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 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Remplacez 203.0.113.10 par votre propre adresse. Sur Plutonium T6, 4976/udp prend la place de 28960/udp, sur Plutonium IW5 c'est 27016/udp. Si vous exploitez plusieurs instances, n'autorisez que la plage réellement utilisée, par exemple 28960:28962/udp et non 28960 à 28970 en bloc. Un port sur lequel rien n'écoute n'est certes pas une porte d'entrée, mais il coûte tout de même du travail au noyau en cas d'attaque. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

3. Activer le frein de requête dans server.cfg

Ces quatre lignes ont leur place dans chaque server.cfg d'un serveur Call of Duty 4 et ne coûtent rien d'autre que quelques mégaoctets de mémoire vive :

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

4 mégaoctets contiennent environ 326 000 adresses, ce qui suffit aussi pour un flood sérieux. N'augmentez sv_queryIgnoreTime qu'avec prudence au-delà des 2000 millisecondes par défaut : la liste des serveurs et chaque navigateur de serveurs interrogent votre serveur par le même mécanisme, et qui règle la durée de blocage trop haut disparaît de la liste. Mettez sv_queryIgnoreDebug temporairement à 1 si vous voulez savoir si le frein agit vraiment, puis remettez-le à 0 pour que le journal ne vous remplisse pas le disque.

4. Trier les floods de requêtes dans le pare-feu

Le frein du moteur n'agit qu'après que le paquet a atteint le processus de jeu. Une règle de pare-feu décide plus tôt et coûte moins. Ces deux lignes limitent getstatus par adresse source :

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

La première ligne retient chaque adresse source qui envoie un paquet de la longueur typique d'une requête de statut. La seconde rejette toute requête getstatus supplémentaire dès que la même adresse en a envoyé plus de quatre en deux secondes. Quatre requêtes par tranche de deux secondes suffisent à tout navigateur de serveurs. Sur les forums circulent aussi des variantes à 20 requêtes par seconde, nettement plus généreuses, qui agissent davantage contre des bots grossiers que contre une vague de réflexion bien construite.

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. Vérifiez ensuite 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.

5. Désactiver RCON ou le tenir serré

L'accès RCON le plus sûr est celui qui n'existe pas. Un rcon_password vide refuse tout paquet RCON :

set rcon_password ""

Notez une subtilité : le serveur répond malgré tout, à savoir par un message d'erreur, et reste ainsi un petit amplificateur. Qui veut exclure cela et n'a de toute façon besoin de RCON que depuis une adresse fixe rejette les paquets en amont :

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

Cette règle a un effet secondaire que vous devez connaître : la chaîne de caractères rcon peut théoriquement apparaître aussi dans un paquet de chat d'un joueur connecté, et ce paquet serait alors rejeté lui aussi. En pratique, c'est supportable. Qui ne veut pas de cet effet secondaire renonce à la règle et travaille uniquement avec un mot de passe vide ou très long.

6. Repousser le flood de connexions et l'épuisement des emplacements

Un flood de connexions ne vise pas le raccordement, mais la logique de jeu : l'attaquant envoie en succession rapide des paquets getchallenge et connect, jusqu'à ce que tous les emplacements soient occupés par des connexions à moitié établies. Les vrais joueurs reçoivent alors « Server is full », alors que personne n'est présent en jeu. Ces réglages agissent contre cela :

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

sv_reconnectLimit limite le nombre de reconnexions successives autorisées pour un même joueur. sv_floodProtect limite le nombre de commandes client que le serveur traite par joueur et empêche ainsi qu'un seul client ralentisse le serveur à coups de commandes. sv_connectTimeout et sv_timeout déterminent combien de temps une connexion à moitié établie, respectivement une connexion muette, bloque un emplacement : qui laisse ici des valeurs généreuses héritées d'un ancien modèle facilite l'épuisement des emplacements à l'attaquant.

Sur CoD4X s'ajoute sv_authorizemode. La valeur 1 ne laisse entrer que les joueurs disposant d'une copie valide, 0 uniquement ceux qui n'en ont pas, et -1 les deux. Qui met 1 exclut une grande partie des clients jetables, mais perd aussi de vrais joueurs sans copie originale. Le moyen le plus dur est un mot de passe de serveur défini par g_password, qui agit contre tout ce qui emprunte le chemin de connexion normal. Et une chose doit être claire : un mot de passe protège la logique de votre jeu, pas votre raccordement. Un attaquant qui inonde votre serveur ne cherche pas du tout à le rejoindre. Ses paquets sont refusés, mais ils sont malgré tout arrivés, et c'est précisément là que se situe le problème.

7. L'entrée dans la liste des serveurs et votre propre adresse

Ici, mieux vaut 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 l'entrée dans la liste la publie de toute façon, avec le port. Vous pouvez désactiver cette entrée en ne définissant aucun serveur maître dans server.cfg (les dvars s'appellent sv_master1, sv_master2 et ainsi de suite). Cela vous coûte toutefois toute visibilité auprès des nouveaux joueurs et ne protège que contre le plus paresseux des attaquants.

Une remarque sur l'état des listes : les serveurs maîtres d'origine d'Activision (codmaster.activision.com sur 20510, cod2master.activision.com sur 20710, cod4master.activision.com sur 20810) ne répondent plus à rien pour les anciens titres. Qui veut être listé aujourd'hui utilise les listes communautaires : CoD4X en exploite une et exige pour cela un token dans sv_authtoken, Plutonium apporte sa propre liste de serveurs. Cela ne change rien au fond, l'adresse y figure tout autant en clair.

Deux habitudes sont malgré tout efficaces. Ne publiez nulle part vous-même l'adresse IP brute, donc ni dans le canal Discord ni sur la page du clan. Et faites passer vos joueurs par un nom d'hôte, afin de pouvoir changer d'adresse le jour venu sans casser toutes les références. Le grand classique reste ici un enregistrement A oublié qui pointe vers l'ancienne adresse : il rend tout changement inopérant.

8. Retirer les interfaces web, la base de données et le Fast Download du réseau ouvert

À côté du jeu, la plupart des serveurs Call of Duty font tourner davantage : IW4MAdmin avec son interface web sur le port 1624, un serveur web pour le Fast Download des cartes, parfois une base de données pour les statistiques. Chacun de ces services constitue une surface d'attaque à part, et aucun d'eux n'a sa place sans restriction sur le réseau ouvert.

Restreignez 1624 à votre propre adresse ou atteignez l'interface par une redirection SSH, puis ouvrez localement http://127.0.0.1:1624 :

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

Attachez la base de données sur 127.0.0.1, elle n'a en aucun cas sa place sur le réseau ouvert. Et placez le Fast Download sur un serveur web distinct plutôt que dans le processus de jeu : sinon, un serveur web sous charge prend au jeu exactement le temps de calcul dont il a besoin pour la simulation.

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 vendredi soir. Avec apt-get install -y vnstat sysstat, la mesure tourne en permanence. Pendant un incident, quatre commandes suffisent :

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp port 28960 -c 200 -q

Pour Call of Duty, il en existe une cinquième, qui répond à la question décisive. Cette capture montre exclusivement les paquets sans connexion, donc précisément getstatus, getinfo, getchallenge, connect et rcon :

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

Si getstatus y apparaît cent fois depuis des adresses toujours nouvelles, vous avez un flood de requêtes. Si rcon y figure, quelqu'un essaie de deviner votre mot de passe. S'il n'y a que getchallenge et connect, c'est un flood de connexions. 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 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 plein de 32 emplacements produit en sortie environ 6,4 Mbit/s, soit moins d'un pour cent d'un raccordement gigabit. Ce même raccordement est saturé dès que quelqu'un envoie 125 mégaoctets par seconde, et c'est précisément sur cela que sont taillées les attaques que l'on peut commander pour dix euros par mois. La qualité de votre règle iptables placée derrière n'a alors plus aucune importance, car les paquets de vos joueurs ne passent déjà plus en amont.

La deuxième grandeur est le taux de paquets, et chez Call of Duty il frappe régulièrement 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. Une requête getstatus est encore plus petite avec ses 41 octets : une attaque qui ne remplit même pas un tiers de votre raccordement paralyse malgré tout votre serveur, parce que tout 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 Call of Duty s'ajoute une particularité qui aggrave le calcul. Comme le jeu, la requête et RCON se trouvent sur le même port, vous ne pouvez pas fermer 28960 en dernier recours : cela reviendrait à éteindre le serveur. Et comme le moteur répond à chaque requête de statut par un multiple de la taille de la requête, un attaquant consomme, pour le même effet, moins de sa propre bande passante que sur d'autres jeux.

Pour situer les ordres de grandeur qui se produisent réellement : sur des serveurs KernelHost ont été filtrés, entre autres, une attaque de plus de 473,4 Gbit/s à plus de 41,5 millions de paquets par seconde contre un serveur vocal et un flood UDP 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 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. 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 clans et certaines communautés 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 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 ce qui est autorisé sur 28960 UDP sans avoir à ouvrir de ticket, et séparément par port lorsque vous exploitez plusieurs instances.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages pendant une attaque en cours.
• Un profil de protection adapté au jeu concerné, y compris pour les applications modifiées ou maison sur n'importe quel port TCP ou UDP. C'est le point pertinent pour Plutonium et CoD4X, dont les ports peuvent s'écarter des valeurs par défaut.

L'Advanced DDoS Protection s'adresse aux serveurs hébergés chez KernelHost. Si votre serveur Call of Duty tourne actuellement ailleurs et y est régulièrement retiré du réseau, le déménagement vers KernelHost est la voie qui change quelque chose.

Les deux niveaux comparés

Pour la plupart des serveurs Call of Duty, la protection permanente incluse suffit, à condition que la server.cfg 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 changé d'adresse IP et deux heures plus tard j'étais 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 affichant le statut ou un ancien enregistrement DNS. Un changement d'adresse fait gagner du temps, ce n'est pas une solution.

« Mon hébergeur m'envoie un signalement d'abus alors que je suis la victime » : c'est que votre serveur n'est pas la cible, mais l'amplificateur. Quelqu'un envoie des requêtes getstatus falsifiées, et votre serveur répond docilement à une victime étrangère. Vérifiez d'abord si sv_queryIgnoreMegs est à 0, puis appliquez les quatre dvars de requête ainsi que la règle de pare-feu de la section 4.

« Le serveur apparaît comme plein dans la liste, mais il est vide » : il s'agit d'un flood de connexions, et il touche la logique de jeu, pas le raccordement. sv_reconnectLimit, des valeurs plus courtes pour sv_connectTimeout et sv_timeout et, en cas de doute, un mot de passe de serveur agissent contre cela.

« Le serveur disparaît de la liste des serveurs pendant l'attaque » : c'est la conséquence, pas la cause. La liste des serveurs vérifie par les mêmes requêtes de statut si votre serveur est vivant. Si les réponses ne passent pas ou si votre propre frein les a rejetées, le serveur est considéré comme hors ligne. Vérifiez si sv_queryIgnoreTime est réglé trop haut avant de soupçonner le pare-feu.

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

« Le serveur tourne, mais tous les joueurs ont des pics de lag » : regardez d'abord le taux de paquets de l'interface, pas la charge CPU. Si sar -n DEV 1 10 ne montre rien d'anormal et que cela saccade malgré tout, la cause tient le plus souvent à un mod, à une sv_maxRate exagérée ou simplement à trop de bots dans la partie.

« 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 Call of Duty classique a besoin d'exactement un port ouvert : 28960 UDP. Sur Plutonium T6, c'est 4976 UDP, sur Plutonium IW5 27016 UDP.
• Chez Call of Duty, le jeu, la requête de statut et RCON se trouvent sur le même port. Vous ne pouvez pas séparer RCON du jeu par une règle de port, il vous faut pour cela une règle qui regarde le contenu du paquet.
• La réflexion getstatus est le vecteur d'amplification propre à ce jeu : 41 octets de requête, un facteur de 63,9 pour le protocole réseau Quake selon l'alerte CISA TA14-017A, soit environ 2 600 octets de réponse.
• Activez le frein de requête : sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. Sur de nombreux serveurs, il est à 0 et donc désactivé.
• Ne définissez rcon_password que si vous avez réellement besoin de RCON : le mot de passe circule en clair sur UDP et peut être deviné autant de fois que l'on veut, sans blocage de compte.
• Les ports de serveur maître 20810 et 20800 sont des ports de destination sortants et n'ont pas leur place dans vos autorisations entrantes.
• À partir d'environ 1 Gbit/s ou de quelques centaines de milliers de paquets par seconde, seul le réseau en amont du serveur est déterminant, plus votre configuration.

Si votre serveur 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.