Anti-DDoS FiveM : la protection DDoS de votre serveur GTA RP

Le mot que vous verrez passer dans les Discord GTA RP, c'est booter — parfois stresser, ou IP stresser. Ce sont trois noms pour la même chose : un service de DDoS à la demande, vendu à l'abonnement, avec une interface web, un champ pour l'adresse, un champ pour la durée, et un bouton. Rien à installer, rien à comprendre.

C'est ce qui explique le profil des attaquants sur FiveM : ce ne sont presque jamais des gens qui savent ce qu'est un paquet UDP. « Se faire ddos » sur un serveur GTA RP, dans l'immense majorité des cas, c'est se faire viser par quelqu'un qui a payé quelques euros et collé une adresse dans un formulaire. La conclusion pratique est rassurante et inquiétante à la fois : l'attaque est bête, mais elle est à la portée de n'importe quel joueur banni.

FiveM fait passer le trafic de jeu par ENet, au-dessus d'UDP. UDP n'établit pas de connexion : il n'y a pas de poignée de main à terminer avant que votre serveur ne commence à traiter un paquet. L'attaquant n'a donc rien à prouver, rien à compléter, et n'a même pas besoin de recevoir de réponse — il peut usurper son adresse source de bout en bout.

C'est la différence structurelle avec un site web. Une requête HTTP arrive au bout d'un handshake TCP, ce qui donne un point où l'on peut refuser quelqu'un avant de travailler pour lui. Sur le port 30120, ce point n'existe pas.

Un attaquant qui dispose de 100 Mbit/s n'envoie pas 100 Mbit/s vers vous. Il envoie de petites requêtes, avec votre IP en adresse source falsifiée, vers des services mal configurés qui répondent beaucoup plus gros que la question posée : résolveurs DNS ouverts, serveurs NTP, Memcached, SSDP. Les réponses partent toutes chez vous.

Le facteur d'amplification va de 30× à plus de 50 000× selon le protocole. C'est pour cela qu'un flood à plusieurs dizaines de gigabits coûte le prix d'un abonnement de streaming, et pourquoi « avoir une bonne machine » ne protège de rien : la machine n'est jamais le facteur limitant, le lien l'est.

Le cas de base : un très gros volume de paquets UDP vers votre IP, sans aucune prétention de ressembler à quoi que ce soit. C'est brutal et c'est efficace, parce qu'il suffit de dépasser la capacité de votre lien montant. Un serveur sur du 1 Gbit/s tombe sous 1 Gbit/s d'attaque, quelle que soit la qualité de sa configuration.

Cela se traite en amont, sur un réseau qui a la capacité de l'avaler — jamais sur la machine attaquée, qui par définition ne peut pas recevoir plus que ce que son lien accepte.

Le plus intéressant, et celui que presque personne ne filtre. Une fois le volume brut absorbé, un attaquant sérieux arrête d'envoyer du déchet et se met à envoyer du trafic techniquement valide : des milliers de tentatives de connexion FiveM bien formées par seconde.

Pour un tunnel L4 générique, chacune de ces tentatives ressemble à un joueur. Elle est donc transmise, et c'est votre FXServer qui fait le travail de la refuser : parsing du handshake, vérification du ticket cfx.re, file d'attente, allocation, puis rejet. Le lien n'est plus saturé — c'est le CPU du serveur qui l'est, et vos vrais joueurs n'arrivent plus à entrer. Le symptôme est différent (« le serveur est en ligne mais personne ne peut rejoindre »), la cause est la même.

Chaque joueur qui rejoint télécharge vos ressources. Sur un serveur RP fourni, cela va couramment de plusieurs centaines de mégaoctets à plusieurs gigaoctets. Un attaquant n'a qu'à demander vos fichiers les plus lourds en boucle, depuis quelques centaines d'adresses, pour saturer votre bande passante sortante avec des requêtes parfaitement légitimes.

Il n'y a rien de malformé à détecter ici : c'est exactement ce qu'un vrai joueur fait, en plus souvent. Cela ne se règle pas avec un filtre, mais avec un cache qui sert les fichiers depuis un autre endroit que votre machine.

FiveM répond, sur le même port 30120, à deux familles de requêtes qui n'ont rien à voir avec le jeu. En UDP, des requêtes hors-bande héritées de Quake — getinfo et getstatus — dont se servent le navigateur de serveurs et les sites de listing pour afficher votre nom, votre carte et votre nombre de joueurs. En HTTP, sur le même numéro de port, les endpoints /info.json, /players.json et /dynamic.json, qui exposent la même chose en JSON.

Chacune tient dans un paquet ou une requête minuscule, et oblige FXServer à composer une réponse complète. Un attaquant n'a donc qu'à la répéter quelques milliers de fois par seconde pour occuper le thread principal, sans jamais tenter de se connecter. Le lien n'est pas saturé, la bande passante bouge à peine, et pourtant le serveur cesse de répondre : il disparaît de la liste alors qu'il tourne encore, et les joueurs qui tentent de rejoindre restent bloqués sur « Failed to get info from server (tried 3 times) » — le client demande ces informations avant de terminer la connexion.

/players.json a un second effet, celui-là permanent : il liste vos joueurs connectés à qui veut bien le demander. C'est de cette façon qu'on sait quand votre serveur est plein, donc quand une attaque fera le plus de dégâts.

txAdmin écoute en TCP, par défaut sur le port 40120, sur la même machine que le jeu. C'est un serveur HTTP de plus, exposé, et il ne profite d'aucun des réglages que vous auriez pu mettre sur le port de jeu.

Un SYN flood y remplit la table des connexions semi-ouvertes sans jamais terminer une seule poignée de main : le panel devient injoignable bien avant que le port de jeu ne bouge. C'est l'attaque la moins spectaculaire et la plus efficace, parce qu'elle vous retire l'outil avec lequel vous auriez réagi. On ne la remarque en général qu'au moment où l'on ouvre le panel pour comprendre ce qui se passe.

Déplacer le port — txAdminPort, ou la variable d'environnement qui l'a remplacée — déplace la cible sans la faire disparaître : un scan de ports la retrouve en quelques secondes.

La référence le décrit toujours comme masquant les adresses IP des joueurs dans les rapports publics émis par le serveur — celles des joueurs, pas la vôtre. Sur les builds FXServer actuels, il ne fait même plus cela : le convar a été retiré, le comportement est devenu inconditionnel, et le laisser dans la configuration fait afficher au démarrage un message demandant de l’enlever.

Il ne masque pas l'IP de votre machine et il ne rejette pas un seul paquet. C'est la confusion la plus répandue sur le sujet : le nom fait penser à un masquage d'origine, le comportement n'a rien à voir.

sv_requestParanoia va de 0 à 3 et ne concerne que les requêtes HTTP reçues par le serveur. Au niveau 1, il bloque les adresses dont les requêtes portent un en-tête Via ; au niveau 2, celles qui portent Upgrade-Insecure-Requests ; au niveau 3, il ferme en plus la socket sur laquelle elles sont arrivées. C'est prévu contre les floods HTTP relayés par des proxies.

Deux limites à connaître. Il raisonne sur des en-têtes, donc un attaquant qui ne les envoie pas n'est pas concerné. Et il ne voit pas l'UDP : ni le trafic de jeu, ni les requêtes getinfo du port 30120 ne passent par ce chemin. Mettez-le à 3, et ne comptez pas dessus comme protection contre un flood volumétrique.

sv_forceIndirectListing true empêche le serveur d'être annoncé avec son adresse IP réelle : c'est le réglage qui compte dès que vous passez par un proxy. Il travaille avec sv_endpoints, qui déclare le point d'entrée réel ou les proxies, et au besoin avec sv_listingHostOverride / sv_listingIpOverride, qui remplacent le nom d'hôte et l'IP envoyés au master.

sv_proxyIPRanges déclare les réseaux, en notation CIDR, depuis lesquels l'en-tête X-Real-IP est accepté et le limiteur de débit contourné — autrement dit vos proxies. Par défaut, seuls les réseaux privés y figurent (10.0.0.0/8, 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) ; ne pas l'ajuster fait voir à FXServer l'adresse du proxy à la place de celle du joueur, ce qui casse vos bans par IP avant de casser autre chose.

Ensemble, ces variables évitent que votre IP soit publiée. Elles ne l'effacent pas d'un ancien enregistrement DNS, d'un site web hébergé sur la même machine, ni d'une ressource qui appelle une adresse codée en dur.

sv_authMinTrust va de 1 à 5 et exprime la difficulté d'usurper l'identité d'un client : monter le niveau écarte les identités les moins fiables. sv_maxClients plafonne le nombre de joueurs (1 à 2048), donc la taille de la file.

Les deux se décident à l'intérieur de FXServer, une fois la tentative reçue et traitée. C'est utile contre des bots qui rejoignent réellement ; c'est sans effet contre dix mille tentatives par seconde, parce que le coût que vous vouliez éviter — recevoir, décoder, vérifier — a déjà été payé au moment où la décision se prend.

Cloudflare protège du HTTP. Le trafic de jeu FiveM n'est pas du HTTP — c'est de l'UDP sur le port 30120, et le proxy Cloudflare classique ne le voit jamais passer. Mettre son domaine derrière Cloudflare protège le site web de la communauté et ne fait strictement rien pour le serveur de jeu.

Pire, cela donne un faux sentiment de sécurité, et cela laisse presque toujours l'IP réelle exposée quelque part : un sous-domaine oublié, un enregistrement DNS resté en clair, un ancien A record. L'attaquant n'a besoin que d'un.

Il existe une exception qu'il vaut mieux connaître que se faire opposer : Cloudflare Spectrum est un proxy de couche 4 qui, lui, relaie du TCP et de l'UDP et masque l'origine. Deux réserves. La documentation Cloudflare indique que les applications TCP/UDP personnalisées — ce qu'est le port 30120 — demandent un plan Enterprise avec Spectrum en option payante, ce qui n'est pas l'ordre de grandeur d'un serveur communautaire. Et Spectrum reste un tunnel générique : il ne vérifie pas la poignée de main cfx.re, donc il transmet une fausse connexion bien formée exactement comme le ferait n'importe quel autre tunnel L4. Il couvre le premier des trois métiers, pas le deuxième.

Il existe, il est réel, et il est générique. Il est réglé pour protéger un réseau entier contre des attaques massives, pas pour comprendre le protocole d'un jeu en particulier. Concrètement, il arrête bien le flood volumétrique, et il ne voit aucune différence entre un joueur qui rejoint et dix mille fausses connexions par seconde. L'exception est un hébergeur qui ajoute par-dessus une couche adaptée aux jeux, comme le pare-feu Game d'OVHcloud, qui affiche un profil FiveM sur ses serveurs Game récents (2024 et après) ; la documentation d'OVHcloud ne précise pas ce que ce profil vérifie.

Il a aussi un mode d'échec désagréable : quand la mitigation se déclenche, elle filtre souvent de façon assez grossière pour dégrader le jeu de ceux qui sont déjà connectés. Rester en ligne avec 400 ms de latence et du rubber-banding n'est pas très différent d'être hors ligne, du point de vue des joueurs.

Filtrer sur la machine attaquée arrive trop tard par construction : les paquets ont déjà traversé le lien saturé pour arriver jusqu'à la règle qui les rejette. Vous économisez du CPU applicatif, vous ne récupérez pas de bande passante.

Quant aux ressources Lua vendues comme « anti-DDoS » sur les marketplaces : elles s'exécutent à l'intérieur de FXServer, donc après que le paquet a été reçu, décodé et traité. Elles peuvent limiter des abus applicatifs. Elles ne peuvent pas, par définition, arrêter une attaque réseau.

Cela fonctionne, pendant environ une journée. Vos joueurs doivent connaître l'adresse pour se connecter, donc l'attaquant l'apprend par le même chemin qu'eux — la liste des serveurs, un ami, un compte jetable. Sans masquage permanent de l'origine, changer d'IP est un délai, pas une solution.

Le trafic volumétrique se traite là où la capacité existe, avant votre lien. Ce qui compte n'est pas seulement le chiffre affiché en Tbit/s, mais l'endroit où le paquet est rejeté. Filtrer en espace utilisateur signifie qu'un paquet d'attaque coûte un réveil du noyau, une copie mémoire et un changement de contexte — ce qui fait de la mitigation elle-même une cible.

fiveshield filtre en XDP, c'est-à-dire dans le pilote réseau du noyau Linux, avant l'allocation de la structure sk_buff. Un paquet rejeté à cet endroit ne coûte presque rien à rejeter, ce qui est la seule raison pour laquelle le débit de mitigation tient sous charge réelle.

C'est la partie qu'un proxy générique ne peut pas offrir, parce que l'offrir suppose d'implémenter le protocole FiveM. Distinguer un vrai joueur d'une fausse connexion demande de vérifier la poignée de main cfx.re elle-même — le ticket, la séquence, la cohérence entre ce qui est annoncé et ce qui suit.

C'est ce filtre de couche 7 qui fait la différence entre « le serveur est en ligne » et « les joueurs peuvent effectivement rejoindre » pendant une attaque.

Le filtrage est défensif ; le masquage de l'origine met fin au cycle. Si vos joueurs ne résolvent qu'une adresse de proxy et n'apprennent jamais l'IP réelle de votre machine, l'attaquant n'a plus rien à viser qu'une infrastructure faite pour être visée.

C'est aussi la pièce que les propriétaires défont le plus souvent sans s'en rendre compte : un site web non protégé sur la même machine, un vieil enregistrement DNS, une ressource qui appelle une adresse codée en dur. N'importe lequel des trois rend le reste inutile. Le premier réflexe est de regarder ce que la liste cfx.re publie déjà sur votre serveur — c'est ce qu'un attaquant lit en premier.

Tout proxy ajoute un saut, et c'est au niveau du saut que le chat vocal se dégrade. Mumble et PMA-Voice sont intransigeants sur la gigue d'une manière que le trafic de jeu ne l'est pas : un chemin de mitigation réglé uniquement pour le débit produit un serveur qui reste en ligne et qui sonne mal.

C'est un critère de choix, pas un détail. Un serveur protégé sur lequel la voix hache est un serveur que les joueurs quittent sans jamais dire pourquoi.

Six en Europe, trois en Amérique du Nord, un en Asie et un en Océanie. Vous en choisissez un dans le tableau de bord en ajoutant votre serveur — de préférence celui qui est le plus proche de la machine.

Amérique du Nord : Beauharnois (BHS5), Virginie (US-EAST-VA-1), Oregon (US-WEST-OR-1).

Europe : Francfort (DE1), Gravelines (GRA9), Roubaix (RBX-A), Strasbourg (SBG5), Londres (UK1), Varsovie (WAW1).

Asie : Singapour (SGP1). Océanie : Sydney (SYD1).

Nos proxies tournent chez OVHcloud, dont le réseau anti-DDoS de 17 Tbit/s absorbe le volume brut en amont. Sur les 11 emplacements de proxy eux-mêmes, le filtrage est fait en XDP, dans le noyau, avec des compteurs et des limiteurs par port : un client sous attaque ne consomme pas la capacité des autres.

Sur chaque instance de proxy, le programme XDP est attaché à l'interface réseau et s'exécute sur chaque paquet dès que le pilote le reçoit. La limitation de débit par source et la protection contre les SYN floods s'appliquent à ce stade, et seul le trafic des joueurs attribués à cette instance, sur les ports actifs de votre serveur, passe aux règles nftables placées derrière, qui assurent le suivi des connexions. Tout le reste est rejeté avant que le noyau n'ait engagé quoi que ce soit pour lui, et c'est de là que vient l'écart par cœur que montre la figure ci-dessous.

Chaque connexion est vérifiée selon le protocole FiveM avant d'être transmise à votre serveur. Une tentative qui ne complète pas correctement la poignée de main n'atteint jamais FXServer, ce qui est exactement ce qui manque à un tunnel générique.

Les joueurs ne sont pas tous routés par la même adresse. Chaque connexion se voit attribuer une instance de proxy, ce qui veut dire qu'une adresse compromise ou attaquée n'expose ni ne bloque l'ensemble de votre population — elle concerne les joueurs qui étaient dessus, et ils sont réattribués.

Vos fichiers de ressources sont servis depuis le cache, pas depuis votre machine. Cela retire le troisième vecteur d'attaque (le flood de téléchargement) et, accessoirement, réduit nettement le temps de chargement initial de vos joueurs — c'est la même mécanique qui règle les deux.

L'interface d'administration passe par la même protection que le jeu. Vous gardez la main pendant une attaque, ce qui est précisément le moment où vous en avez besoin.

fiveshield ne remplace pas votre hébergement, il se place devant. Le serveur reste sur la machine et chez le fournisseur que vous avez aujourd'hui, votre panel reste le vôtre, et votre contrat d'hébergement n'est pas concerné. La seule modification côté serveur est un bloc de configuration dans server.cfg.

Il n'y a donc rien à migrer, aucun enregistrement DNS à déplacer et aucune ressource à installer. C'est ce qui rend la mise en route possible pendant une attaque, là où une migration ne l'est pas.

Redémarrer FXServer ou la machine ne sert à rien : l'attaque est en amont, et vous ne perdez que la session en cours. Annoncer une nouvelle adresse dans votre Discord est pire — l'attaquant y est, et c'est souvent par là qu'il a eu la première.

CPU et RAM bas, processus FXServer vivant, tous les joueurs qui tombent en même temps : c'est le réseau, pas le serveur. Du lag ordinaire fait monter quelque chose — le CPU, le temps de tick, la mémoire ; une attaque réseau ne fait rien monter du tout.

Deux variantes utiles. Un serveur qui disparaît de la liste alors qu'il tourne encore, ou des joueurs bloqués sur « Failed to get info from server (tried 3 times) », pointe vers un flood de requêtes plutôt que vers un flood volumétrique. Un txAdmin injoignable pendant que le jeu répond encore pointe vers le port 40120.

C'est la seule action qui change quelque chose durablement, et il faut être lucide sur l'ordre. Mettre un proxy devant un serveur dont l'adresse est déjà connue ne vide pas votre lien : l'attaquant continue de taper là où il tapait. La séquence qui fonctionne est : mettre le proxy en place, demander une nouvelle IP à votre hébergeur, ne la publier nulle part, et ne laisser sortir que l'adresse du proxy.

La mise en place tient dans les cinq minutes — un bloc à coller dans server.cfg et un redémarrage — parce qu'il n'y a ni changement DNS ni migration à attendre. C'est précisément pour cela que c'est faisable pendant l'attaque.