Protéger un serveur Left 4 Dead 2 des attaques DDoS

Un serveur Left 4 Dead 2 tombe rarement au moment qui vous arrange. Il tombe dans le dernier chapitre d'une campagne, au second tour d'un match Versus, ou précisément au moment où un joueur banni vient d'être refusé pour la troisième fois. Quand vous êtes déjà sous le feu, vous n'avez pas besoin d'un débat de fond sur les techniques réseau, mais d'un ordre de marche. Cet article montre d'abord comment protéger un serveur Left 4 Dead 2 des attaques DDoS tant que les moyens du bord y suffisent, ensuite où ces possibilités 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é (srcds), installé via SteamCMD sous l'App-ID 222860, sur 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. Un point d'emblée, parce qu'il détermine l'ordre de marche : pendant une attaque en cours, ne modifiez rien à l'aveugle et ne redémarrez pas le serveur avant d'avoir sauvegardé vos mesures. Après l'attaque, elles auront disparu.

Pourquoi les serveurs Left 4 Dead 2 sont une cible DDoS payante

La différence avec un jeu de tir à 64 places tient à la taille de la partie. Une campagne coopérative compte quatre places pour les survivants, un match Versus huit places pour les deux camps réunis. Une panne ne touche donc jamais des joueurs isolés, mais toujours la partie entière : interrompre une campagne au troisième de ses cinq chapitres, c'est mettre fin à la soirée de tous les participants. C'est exactement ce qui rend une attaque attrayante pour celui qui la déclenche, car elle ne lui coûte ni compétence particulière ni argent notable, alors qu'elle détruit une heure de jeu en face.

S'y ajoute la conception. Left 4 Dead 2 tourne sur le moteur Source, et un serveur Source se trouve publiquement, avec son adresse IP et son port. C'est une condition de fonctionnement, pas une négligence : un serveur qui ne répond à aucune requête n'apparaît dans aucune liste et n'est trouvé par aucun lobby. La question n'est donc jamais de savoir si un attaquant connaît votre adresse, mais uniquement ce qui se passe quand il tire dessus. Le trafic de jeu passe par UDP, et UDP ne prévoit aucun établissement de connexion que l'on pourrait exiger, tandis que les adresses source se falsifient sans peine. Ce qui se déroule techniquement dans ce cas, l'article Qu'est-ce qu'une attaque DDoS ? l'explique.

Un troisième point est propre à Left 4 Dead 2 et n'a pas d'équivalent chez Counter-Strike, Garry's Mod ou Team Fortress 2 : la plupart des joueurs n'arrivent pas par le navigateur de serveurs, mais par le système de lobby. Un lobby de quatre joueurs au maximum est orienté par le matchmaking de Steam vers un serveur dédié, qui reçoit pour cela une réservation. Ce mécanisme est à la fois votre filtre d'accès le plus efficace et une surface d'attaque supplémentaire. Les deux aspects sont détaillés plus bas.

Les ports dont il est réellement question

Un serveur Left 4 Dead 2 occupe exactement un port UDP pour tout ce qui constitue le jeu. La valeur par défaut est 27015, définie par -port ou +hostport dans la ligne de démarrage :

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

La première ligne de ce tableau est le cœur du problème. Le trafic de jeu et la requête d'état se partagent 27015/UDP, il n'existe pas de port de requête séparé chez Left 4 Dead 2. Celui qui bloque globalement ce port ou lui applique une limitation de débit grossière éjecte du même geste ses propres joueurs et termine l'attaque dans le sens voulu par l'attaquant.

Une requête A2S tient dans un paquet de quelques dizaines d'octets, la réponse pèse plusieurs fois plus. En UDP, l'adresse source se falsifie, et votre serveur devient alors non seulement une victime, mais un amplificateur : un attaquant interroge des serveurs de jeu tiers avec l'adresse de sa cible et dirige leurs réponses vers celle-ci. En décembre 2020, Valve a complété A2S_INFO par une demande préalable (S2C_CHALLENGE) que le demandeur doit renvoyer avant d'obtenir la réponse. Cela atténue la réflexion sans y mettre fin, car les anciens programmes de requête continuent d'être servis.

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

La partie qui suit ne coûte rien et vaut la peine quel que soit l'endroit où votre serveur est hébergé. Elle ne vous débarrassera pas d'une attaque volumétrique, mais elle fait tomber à plat les attaques petites et moyennes, et elle élimine les pannes signalées à tort comme des attaques DDoS.

1. État des lieux : qu'est-ce qui écoute vraiment

Avant d'écrire la moindre règle, établissez quels services sont joignables. Sur un serveur Left 4 Dead 2 qui a vécu, ils sont presque toujours plus nombreux que prévu, car à côté de srcds tournent aussi un serveur web pour les campagnes, une base de données de statistiques et parfois un second serveur pour le Versus :

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. Le point de vue de l'attaquant s'obtient par un scan de ports depuis l'extérieur, et l'expérience montre qu'il s'écarte de ce que l'on attendait :

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 ADRESSE.IP.DE.VOTRE.SERVEUR

Si la couche de base vient d'être installée ou si vous voulez en refaire le chemin, l'article Installer un serveur de jeu avec SteamCMD décrit le parcours de SteamCMD jusqu'à un srcds en fonctionnement.

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

Un port UDP vers l'extérieur, un port TCP pour votre propre adresse, rien de plus. RCON n'a rien à faire en accès libre sur Internet, car celui qui dispose de RCON change de carte, bannit tous les joueurs et arrête le serveur :

ufw allow 27015/udp comment "Port de jeu L4D2 et A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Remplacez 203.0.113.10 par votre propre adresse. Si celle-ci change régulièrement, passez par une redirection de port SSH plutôt que par une ouverture permanente. L'ordre des opérations au moment d'activer le pare-feu décide si vous vous bloquez vous-même l'accès ; il est décrit, chemin de retour compris, dans l'article 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 n'ont ni IPMI ni iDRAC, vous atteignez la machine par la console VNC de l'espace client, et celle-ci ne dépend pas de la pile réseau du système invité.

3. Freiner la requête A2S sans disparaître de la recherche de lobby

C'est ici que se trouve l'erreur la plus coûteuse du domaine. Comme le trafic de jeu et la requête d'état occupent le même port, le frein doit faire la différence entre les deux catégories de paquets, et non entre les ports.

Depuis les modifications de décembre 2020, la couche Steam des serveurs de jeu apporte pour cela sa propre limitation, définie comme variable d'environnement avant le démarrage. STEAM_GAMESERVER_RATE_LIMIT_200MS=N rejette les paquets sans connexion (A2S_INFO, A2S_RULES, A2S_PLAYERS) d'une adresse source dès qu'il en arrive plus de N dans une fenêtre de 200 millisecondes. Valve indique une plage utilisable de 25 à 75 ; par défaut, la limitation est désactivée :

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

Dans une unité systemd, la même valeur a sa place dans la section [Service] sous la forme Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50, sans quoi elle disparaît au prochain redémarrage. Ce frein ne s'applique que si votre build de serveur embarque la couche Steamworks actuelle, et il protège le temps de calcul de votre serveur, pas votre liaison : les paquets sont déjà arrivés.

Un cran plus bas, le même trafic se sépare dans le noyau. Tous les paquets sans connexion du moteur Source, c'est-à-dire les requêtes d'état et l'établissement de connexion, commencent par quatre octets à un (0xffffffff), alors que le trafic des joueurs déjà connectés n'a pas cet en-tête. C'est là-dessus que nftables permet de poser une limitation de débit par adresse source :

table inet l4d2 {
    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. Commencez large et ne resserrez la limite qu'une fois que vous avez la preuve que les requêtes légitimes passent : votre propre entrée dans la liste des serveurs en dépend.

4. Utiliser le système de lobby comme filtre d'accès

C'est le levier dont seuls Left 4 Dead 2 et son prédécesseur disposent. Le serveur décide lui-même s'il accepte ou non des connexions en dehors du matchmaking. Quatre directives de server.cfg le déterminent :

sv_allow_lobby_connect_only 1
sv_search_key "votre-propre-cle"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 n'autorise que les arrivées issues d'un lobby de matchmaking. Un connect 203.0.113.10:27015 depuis la console de développement et une invitation Steam sont refusés. La valeur 0 autorise les deux.
• sv_search_key est une clé de recherche librement choisie. Seul un lobby dans lequel la même clé est définie trouve le serveur via le matchmaking. Sans cette clé, il n'apparaît pas dans la recherche publique.
• sv_steamgroup rattache le serveur à un groupe Steam et le fait apparaître parmi les serveurs de ce groupe.
• sv_steamgroup_exclusive connaît trois niveaux : 0 laisse entrer tout le monde, 1 se comporte comme 0 mais exige l'arrivée par un lobby, et 2 ne laisse plus passer que les membres du groupe et l'accès direct par l'adresse IP.

Pour une communauté établie, la combinaison de la clé de recherche et de sv_steamgroup_exclusive 2 est le filtre d'accès gratuit le plus efficace que le jeu connaisse. Un serveur public ne peut pas l'utiliser, car un serveur que personne ne trouve est aussi vide qu'un serveur hors ligne.

Et maintenant la partie que les textes publicitaires passent volontiers sous silence : ces directives protègent votre logique de jeu, pas votre liaison. Un attaquant qui inonde 27015/UDP ne cherche pas du tout à rejoindre la partie. Ses paquets sont refusés, mais ils sont malgré tout arrivés, ils ont consommé de la bande passante et coûté un passage complet dans la pile réseau. Contre un flood d'arrivées issu de comptes jetables, sv_allow_lobby_connect_only 1 agit remarquablement bien ; contre un booter, il n'agit pas du tout.

5. La réservation de lobby et le moment où sv_force_unreserved est le meilleur choix

Une réservation de lobby est une occupation limitée dans le temps de votre serveur par un lobby de matchmaking. Tant qu'elle existe, le serveur est considéré comme pris par les autres lobbys, et elle n'expire d'elle-même qu'au bout d'un certain temps. Pour un serveur à quatre places, c'est une ressource rare : contrairement à un jeu de tir à 32 ou 64 places, il en faut très peu pour bloquer une partie.

Qui n'exploite pas son serveur via le matchmaking supprime entièrement cette surface :

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

sv_force_unreserved 1 fait que le serveur ne répond plus aux demandes de réservation venues du système de lobby et refuse les arrivées porteuses d'une marque de réservation. Vous avez de toute façon besoin de ce même réglage si vous exploitez plus de quatre places coopératives avec L4DToolZ, car sinon le lobby obtient une réservation dès que les quatre premières places sont occupées, et les places restantes demeurent inaccessibles. La contrepartie est claire : vos joueurs n'entrent alors plus que par le navigateur de serveurs ou par connect.

Choisissez délibérément l'un des deux modes d'exploitation. Le mélange d'un matchmaking à moitié ouvert et d'une arrivée directe à moitié ouverte est la variante qui cumule les deux inconvénients.

6. Sécuriser RCON

Un port RCON ouvert avec un mot de passe faible n'est pas un problème de DDoS, c'est une prise de contrôle. Ne laissez jamais rcon_password vide et ne le composez jamais de tête, une valeur issue de openssl rand -base64 32 suffit. Les titres Source apportent en plus un frein contre les tentatives de connexion :

rcon_password "UNE_VALEUR_ALEATOIRE"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Une adresse est ainsi bannie pour une journée après trois échecs en 30 secondes ; find sv_rcon dans la console du serveur montre lesquelles de ces variables votre build connaît. La restriction de pare-feu de l'étape 2 reste malgré tout plus efficace, car elle empêche la tentative d'atteindre l'application. Si vous n'avez pas besoin de RCON, laissez le mot de passe vide : la partie TCP de 27015 n'écoute alors pas.

7. Externaliser les campagnes personnalisées au lieu de les livrer par le port de jeu

Les campagnes personnalisées sont la raison pour laquelle Left 4 Dead 2 est encore joué quinze ans après, et en même temps une source de charge qui n'existe pas sous cette forme chez Counter-Strike. Une campagne est un paquet VPK contenant cartes, modèles, textures et sons, donc un multiple de ce que pèse une seule carte de compétition.

La voie confortable pour les joueurs est le Steam Workshop : le paquet vient alors de Steam et non de votre serveur, et ne vous coûte aucune bande passante. Si vous livrez vous-même des fichiers isolés, cette livraison a sa place sur un serveur web et non sur le port de jeu :

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

Les fichiers destinés à sv_downloadurl doivent être déposés sur le serveur web sous forme d'archive bzip2, macarte.bsp devient donc macarte.bsp.bz2. Sans sv_downloadurl, srcds envoie les fichiers lui-même par la connexion de jeu, et alors la règle est la suivante : chaque tentative de connexion d'un nouveau joueur vous coûte le téléchargement complet, chaque interruption en cours de téléchargement également. C'est une façon particulièrement bon marché de remplir une liaison, et elle ne ressemble à une attaque dans aucune statistique.

Trois points à ce sujet, qui font mal en pratique. sv_allowupload 0 doit être défini, car vous n'avez pas besoin d'envois du client vers le serveur. Si le serveur web de sv_downloadurl se trouve sur le même hôte que le jeu, le téléchargement et le trafic de jeu partagent la même liaison et la même adresse IP, et une attaque sur 443/TCP touche alors aussi votre partie en cours. Et sv_consistency 1 n'est pas une protection contre les attaques, mais contre les fichiers clients divergents ; ne le désactivez que si une campagne ne démarre manifestement pas autrement.

8. SourceMod, Metamod et les extensions

Une part importante des pannes signalées comme DDoS n'en sont pas. Ce sont des plantages et des pics de charge qu'un seul client déclenche, parce qu'une faille reste ouverte dans le binaire du serveur ou dans une extension. Aucune bande passante n'y change quoi que ce soit, seule la maintenance aide :

• Gardez Metamod:Source et SourceMod en phase avec la version du moteur. Left 4 Dead 2 continue de recevoir des mises à jour, et une extension mal assortie est la cause la plus fréquente de plantages juste après une mise à jour.
• Left4DHooks plutôt que des interventions maison. Les événements propres à L4D2 sont regroupés dans cette extension. Intervenir soi-même dans les mêmes fonctions est le chemin le plus rapide vers un binaire de serveur qui abandonne sur certaines suites de paquets.
• N'utilisez L4DToolZ qu'en connaissance de cause. L'extension relève les limites de places inscrites en dur. Chaque place supplémentaire est un joueur supplémentaire qui produit du temps de calcul, et en liaison avec le système de lobby, elle exige sv_force_unreserved 1.
• Moins d'extensions. Chaque plugin est du code dans le même processus. Les extensions dotées de leurs propres services web ouvrent des ports supplémentaires et publient souvent précisément l'adresse que vous cherchez à protéger.

Les bannissements doivent être enregistrés durablement, sinon ils disparaissent au redémarrage. Les titres Source disposent pour cela de banid avec writeid ainsi que de addip avec writeip, et les fichiers produits sont relus par exec banned_user.cfg et exec banned_ip.cfg.

9. Soulager le suivi de connexions et le tampon de réception

Ce point passe souvent inaperçu et explique des pannes qui ressemblent à une attaque volumétrique sans en être une. Le noyau crée pour le trafic UDP des entrées dans le suivi de connexions (conntrack), et avec des adresses source falsifiées, chaque adresse signifie une nouvelle entrée. Une fois la table pleine, le noyau jette les paquets sans faire de différence : l'attaque et vos joueurs sortent ensemble. Un coup d'œil suffit pour voir l'état et la limite :

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

L'action la plus efficace consiste à ne pas faire suivre du tout le trafic de jeu, puisque le moteur gère lui-même ses sessions :

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 27015 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 notrack
    }
}

Avec iptables, l'équivalent s'écrit iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK, plus la même ligne pour OUTPUT avec --sport. Le port a ensuite besoin d'une ouverture explicite, car sans suivi, plus aucune règle testant un état existant ne s'applique. Si les paquets arrivent plus vite que srcds ne les récupère, le tampon de réception déborde en plus, et pour les joueurs cela ressemble à de la perte de paquets sur une liaison libre :

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Vous déposez ce fichier sous /etc/sysctl.d/ et l'activez avec sysctl -p. Le noyau vous dit lui-même si ces valeurs sont seulement nécessaires : si UdpRcvbufErrors augmente dans nstat -az, elles servent à quelque chose. Si le compteur reste à zéro, le réglage ne change rien. C'est une réserve, pas une protection.

10. Mesurer, pour ne pas avoir à deviner pendant l'attaque

Pendant une attaque, la question la plus importante est la suivante : combien arrive, sur quel port, et s'agit-il de trafic de requêtes ou de trafic de jeu. Quatre commandes suffisent :

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

Lancez la première commande deux fois à dix secondes d'intervalle, vous obtenez alors un débit au lieu d'une valeur absolue. La dernière ligne ne montre que les paquets sans connexion, c'est-à-dire exactement la catégorie dont abuse une inondation de requêtes ; si le compteur se remplit en quelques secondes alors que presque personne n'est connecté, vous avez votre réponse. Gardez la capture courte, car elle consomme elle-même du temps de calcul sous charge. La façon d'interpréter ces valeurs est expliquée dans l'article Détecter une attaque DDoS sur son serveur.

L'étape la plus importante reste toutefois 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 un serveur Versus plein.

Où ces mesures s'arrêtent

Passons à la partie honnête. Tout ce qui précède n'agit qu'une fois les paquets arrivés sur votre carte réseau. 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. À la plus petite taille de paquet possible, cette liaison transporte environ 1,49 million de paquets par seconde, une liaison à 10 Gbit/s environ 14,88 millions. C'est la limite physique, indépendamment du CPU, du noyau et du pare-feu. Selon le processeur 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 liaison peut donc paralyser votre serveur, parce que le temps de calcul part dans le rejet des paquets. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout avait disparu ».

En face, il y a les attaques réelles. Deux exemples tirés de notre exploitation chez KernelHost, tous deux filtrés en temps réel : un flood UDP contre un serveur de jeu sur 7777/UDP avec plus de 112,2 Gbit/s et plus de 8,7 millions de paquets par seconde, ainsi qu'une attaque multivecteur contre un serveur vocal sur 9987/UDP avec plus de 473,4 Gbit/s et plus de 41,5 millions de paquets par seconde. Rapportez cela à votre liaison : 473,4 Gbit/s représentent environ 470 fois un raccordement à 1 Gbit/s, et encore environ 47 fois un raccordement à 10 Gbit/s.

C'est pourquoi les deux freins d'urgence les plus répandus ne satisfont personne. Le null-routing (blackholing) retire du réseau l'adresse IP attaquée et met bien fin à l'attaque, mais aussi à votre serveur : pour vos joueurs, le résultat est identique à celui d'une attaque réussie. Une redirection réactive coûte, pendant son temps de bascule, exactement les minutes durant lesquelles la campagne se décide. Seul un filtrage permanent, effectué dans le réseau en amont du serveur, est réellement efficace.

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, bien avant qu'elles n'atteignent 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 sur les couches 3 à 7, paquet par paquet.

Deux caractéristiques sont décisives. Premièrement, le filtrage tourne en permanence, il n'y a donc pas de temps de bascule pendant lequel vos joueurs seraient éjectés. Deuxièmement, aucun null-routing n'est employé : l'adresse IP attaquée reste dans le réseau, seuls les paquets malveillants sont rejetés. La protection est comprise dans chaque pack serveur sans supplément, sans pack de protection distinct et sans mise en service particulière, et elle est active dès la mise à disposition. Les serveurs se trouvent dans le maincubes Premium Datacenter à Francfort-sur-le-Main. Les jeux et protocoles couverts sont listé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 attaqués de temps à autre, mais de façon ciblée et pendant des semaines, avec des schémas changeants et toujours pile au soir de campagne convenu. 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. Votre serveur est basculé sur cette adresse au sein de notre 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. Vous définissez dans l'espace client quel port est filtré avec quel profil, donc 27015/UDP autrement que le serveur web qui livre vos campagnes.
• Les changements s'appliquent en temps réel, sans ticket et sans attente. Vous pouvez donc affiner les réglages pendant une attaque en cours.
• Un profil de protection adapté au jeu concerné. Pour Left 4 Dead 2 et les autres titres Source comme pour plus de 40 autres jeux et protocoles, avec en plus des profils TCP et UDP libres pour les serveurs modifiés.

Ici aussi, le modèle PrePaid s'applique : pas de durée minimale, pas de préavis de résiliation, pas de contrat et pas de frais de mise en service. Une fois la vague d'attaques passée, il vous suffit de ne pas renouveler.

Les deux niveaux comparés

Pour la plupart des projets Left 4 Dead 2, la protection permanente incluse suffit, à condition que la configuration du serveur soit propre. L'Advanced DDoS Protection est la réponse au cas où quelqu'un en fait une affaire personnelle.

Erreurs fréquentes et solutions

Le serveur a disparu de la recherche de lobby, mais il tourne toujours : le plus souvent, 27015/UDP a été bloqué globalement ou limité en débit de façon trop stricte, et comme le trafic de jeu et la requête partagent le même port, une règle grossière touche les deux. Travaillez plutôt avec une comparaison portant sur les paquets sans connexion. Si le port est joignable et que le serveur reste malgré tout invisible, vérifiez sv_search_key, sv_steamgroup_exclusive, sv_lan 0 et sv_region 255, ainsi que le fait que le démarrage n'ait pas eu lieu par mégarde avec -nomaster.

La console du serveur affiche sans arrêt « Invalid split packet length » : ce n'est pas une attaque volumétrique, mais un paquet réseau mal assemblé, envoyé en succession rapide. Le trafic reste minuscule, le serveur lague quand même. Vérifiez d'abord si la bande passante sort seulement de l'ordinaire, et mettez à jour le binaire du serveur ainsi que les extensions. La bande passante n'aide en rien ici.

Tous les joueurs ont un ping élevé, mais la liaison n'est pas saturée : cela oriente vers un débit de paquets plutôt que vers un volume. Regardez les paquets rejetés dans ip -s link show et les compteurs UDP dans nstat -az. Si le journal système contient nf_conntrack: table full, sortez le port de jeu du suivi avec notrack.

La règle de pare-feu est correcte et reste pourtant sans effet : vérifiez avec iptables -L INPUT -n -v si les compteurs de correspondances augmentent. S'ils restent à zéro, la règle n'est jamais atteinte, parce qu'elle se trouve derrière les chaînes UFW ou parce qu'elle a été perdue au dernier redémarrage. S'ils augmentent et que rien ne change, c'est que la liaison en amont du serveur est saturée, et à partir de là seul le filtrage dans le réseau aide.

Le serveur n'accepte plus de joueurs bien que des places soient libres : le plus souvent, une réservation de lobby est restée bloquée. Soit vous exploitez le serveur de façon conséquente via le matchmaking, soit vous définissez sv_force_unreserved 1 et laissez vos joueurs entrer par le navigateur de serveurs. Avec plus de quatre places coopératives sous L4DToolZ, ce réglage est de toute façon obligatoire.

Les nouveaux joueurs chargent indéfiniment et la liaison est saturée pendant ce temps : c'est que srcds livre lui-même les fichiers de campagne par le port de jeu. Définissez sv_downloadurl vers un serveur web et déposez-y les fichiers sous forme d'archive bzip2, ou orientez vos joueurs vers le Steam Workshop.

L'attaque s'interrompt après un changement d'IP et revient au bout d'un à deux jours : c'est le cas normal, car votre serveur publie lui-même la nouvelle adresse dès qu'il est de nouveau enregistré, et un enregistrement DNS oublié ou un bot Discord affichant le statut fait le reste. Un changement d'IP procure quelques heures, pas une solution.

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 et restreignez la partie TCP de 27015 à votre propre adresse.

En résumé

• Un serveur Left 4 Dead 2 a besoin d'exactement un port ouvert vers l'extérieur : 27015/UDP. Le trafic de jeu et la requête A2S se le partagent, il n'existe pas de port de requête séparé.
• 27015/TCP est RCON et doit rester réservé à votre propre adresse. Qui n'a pas besoin de RCON laisse rcon_password vide.
• Le système de lobby est le filtre d'accès gratuit le plus efficace que le jeu connaisse : sv_allow_lobby_connect_only 1, un sv_search_key qui vous est propre et sv_steamgroup_exclusive 2 excluent tout ce qui ne vient pas du matchmaking. Il filtre les arrivées, pas les paquets.
• Les campagnes personnalisées ont leur place dans le Steam Workshop ou derrière sv_downloadurl, jamais sur le port de jeu. Sinon, chaque tentative de connexion interrompue se paie avec votre bande passante.
• La limitation de débit doit faire la différence entre les paquets sans connexion (commençant par 0xffffffff) et le trafic de jeu. Une règle grossière sur 27015/UDP éjecte vos propres joueurs.
• Avec des paquets de 64 octets, une liaison à 1 Gbit/s transporte environ 1,49 million de paquets par seconde. Au-delà, seul le réseau en amont du serveur décide, aucun réglage sur le serveur lui-même.
• Chez KernelHost, 17 Tbps de scrubbing mondial et un filtrage Arbor en temps réel à 3,2 Tbps à Francfort-sur-le-Main filtrent en permanence et sans supplément, sans null-routing et sans temps de bascule.

Si votre projet 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 pour que notre équipe ajuste les règles de filtrage appliquées à votre adresse IP. Pendant une attaque en cours, vous pouvez également nous joindre par 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 (des joueurs sont éjectés, le serveur n'apparaît pas dans la recherche de lobby, ping élevé). Cela évite un aller-retour de questions, et cet aller-retour compte quand une campagne est en cours.

Si vous hébergez ailleurs et que vous êtes régulièrement visé, le transfert chez KernelHost est un chemin plus court que n'importe quelle règle supplémentaire sur un serveur dont la liaison s'arrête avant. La protection permanente fait partie de chaque pack serveur, ce n'est pas un supplément que l'on réserve seulement le jour venu.