Attaques Layer 7 sur FiveM : players.json, info.json et sv_requestParanoia

Ce qu'un attaquant obtient en appelant /players.json

Quand on parle de DDoS sur FiveM, tout le monde pense au flood UDP sur le port 30120. C'est le vecteur le plus visible, mais ce n'est presque jamais le premier essayé — parce qu'il coûte de la bande passante à l'attaquant. Le premier essai, c'est le HTTP.

FXServer expose trois endpoints publics sur son port de jeu : /info.json, /dynamic.json et /players.json. Ils existent pour de bonnes raisons — la liste Cfx.re, les outils de monitoring, les sites de statistiques les consultent en permanence. Mais ils ont deux propriétés qui en font une cible parfaite :

• Ils répondent sans authentification. N'importe qui, depuis n'importe où, peut les appeler.
• Chaque requête coûte plus cher au serveur qu'à l'appelant. FXServer doit sérialiser l'état courant du serveur pour répondre. Une requête HTTP tient dans quelques centaines d'octets à l'aller.

C'est la définition d'une attaque applicative : le déséquilibre de coût, pas le volume. Quelques milliers de requêtes par seconde sur /players.json suffisent à faire monter le CPU de FXServer et à dégrader le tick pour tout le monde, sans jamais approcher la limite de bande passante. Sur les captures que les propriétaires nous envoient, c'est le scénario qui se termine le plus souvent par « le CPU était à 100 % mais le réseau était calme ».

Accessoirement, ces endpoints renseignent l'attaquant : nombre de joueurs, ressources chargées, numéro de build, variables sets publiées par votre config. C'est de la reconnaissance gratuite avant l'attaque suivante.

sv_requestParanoia : ce que fait vraiment chaque niveau

FiveM inclut une contre-mesure intégrée, et elle est nettement moins connue qu'elle ne le mérite. sv_requestParanoia est une variable entière de 0 à 3, à 0 par défaut, prévue pour contrer les floods HTTP passant par des proxies.

Deux choses valent la peine d'être comprises précisément.

Ce n'est pas un blocage de la socket, c'est une réponse. Quand la vérification échoue, FXServer répond un 403 dont le corps est littéralement Nope., sur /info.json, /dynamic.json et /players.json. La connexion TCP a donc déjà été acceptée, la requête déjà lue. Le coût économisé est celui de la sérialisation de l'état du serveur — réel, mais partiel.

Le déclencheur est un en-tête, pas un débit. Le niveau 1 vise l'en-tête Via, ajouté par les proxies HTTP ; le niveau 2 vise Upgrade-Insecure-Requests, envoyé par les navigateurs. C'est précisément pour ça que le niveau 2 casse la consultation de vos endpoints depuis un navigateur : c'est voulu, un humain n'a rien à y faire. Un outil de monitoring qui n'envoie ni l'un ni l'autre continue de fonctionner.

La ligne à mettre dans server.cfg :

set sv_requestParanoia 3

Le niveau 3 est le bon choix par défaut sur un serveur public : il ajoute la fermeture de socket, qui est ce qui coûte le plus cher à l'attaquant.

Le reste du bloc de durcissement, et ce qu'il vaut

sv_requestParanoia circule rarement seul. Voici les convars qui l'accompagnent dans les configs partagées, et ce qu'ils font réellement d'après la documentation officielle :

• sv_forceIndirectListing true — booléen (false par défaut) qui empêche le serveur d'être annoncé avec sa vraie IP. C'est le levier documenté du masquage d'origine, détaillé dans notre article sur comment cacher l'IP de son serveur FiveM.
• sv_authMinTrust — entier de 1 à 5 (1 par défaut) qui exprime à quel point il est improbable que l'identité d'un utilisateur soit usurpée par un client malveillant. Le monter resserre l'exigence de vérification d'identité à la connexion.
• sv_scriptHookAllowed — booléen à false par défaut ; le passer à true autorise les clients Script Hook V à se connecter, ce que la documentation déconseille explicitement.
• sv_endpointPrivacy — historiquement, il masquait les IP des joueurs dans les rapports publics du serveur. Sur les builds FXServer actuels il est retiré : le comportement est devenu inconditionnel et le serveur affiche au démarrage un message demandant de l'enlever de la configuration. Ce n'est pas une perte, c'est une protection devenue permanente.
• sv_useDirectListing — présent dans presque tous les blocs copiés-collés, absent de la référence des commandes serveur et du guide officiel de configuration derrière un proxy. Traitez-le comme du folklore.

Ce bloc complet, correctement appliqué, est gratuit et vaut la peine sur tout serveur public. Il ne couvre pas pour autant tout ce qu'on appelle « Layer 7 » sur FiveM.

Ce que sv_requestParanoia ne couvre pas : le flood de connexions cfx.re

Le deuxième vecteur applicatif est plus difficile, et c'est celui qui fait tomber les serveurs qui se croyaient durcis.

Un joueur qui rejoint votre serveur ne commence pas par envoyer du trafic de jeu. Il déroule la poignée de main de connexion FiveM : demande d'entrée, vérification d'identité via Cfx.re, phase de deferral pendant laquelle vos ressources peuvent afficher un message ou refuser, puis passage au flux de jeu. Cette séquence a un coût — elle occupe une place de connexion, déclenche des handlers dans vos ressources, et attend le réseau.

Une attaque de connexion consiste simplement à la lancer en boucle sans jamais la terminer. Les paquets sont bien formés. Ils viennent d'adresses distinctes. Ils ressemblent, octet pour octet, à des joueurs qui essaient de vous rejoindre — parce que c'est exactement ce qu'ils sont, à l'intention près.

sv_requestParanoia n'a aucune prise dessus : il inspecte des en-têtes HTTP sur trois endpoints, et le flood de connexions ne passe pas par là. Un pare-feu générique n'a pas plus de prise, parce qu'il n'y a rien d'anormal à filtrer au niveau du paquet. Distinguer un vrai joueur d'une fausse connexion demande un anti-DDoS FiveM qui implémente réellement la poignée de main cfx.re et suit l'état de chaque session — pas un tunnel L4 qui relaie ce qu'il reçoit.

Le troisième vecteur : le flood de téléchargement de ressources

Le dernier est le plus bête et le plus efficace. À la première connexion, un joueur télécharge toutes vos ressources. Sur un serveur RP correctement fourni, cela va de plusieurs centaines de mégaoctets à plusieurs gigaoctets.

Un attaquant n'a donc pas besoin d'un botnet : il lui suffit de déclencher ce téléchargement en boucle. Chaque itération vous coûte de la bande passante montante réelle, et sature le lien de la machine bien avant que le CPU ne bronche. C'est la raison pour laquelle un cache CDN devant les ressources n'est pas un confort mais une mesure de sécurité — le détail est dans notre article sur pourquoi un cache CDN pour serveur FiveM.

Récapitulatif des trois vecteurs applicatifs :

Filtrer le L7 en amont plutôt que dans FXServer

Le point commun aux trois lignes du tableau : au moment où FXServer décide quoi faire, le paquet est déjà arrivé. Le lien réseau a été consommé, le noyau a fait le travail, le processus a été réveillé. Le durcissement natif réduit le coût du traitement ; il ne réduit pas le coût de la réception.

C'est la différence structurelle avec un filtrage en amont. Un proxy qui parle le protocole peut refuser la connexion avant qu'elle n'atteigne votre machine, et absorber le volume sur un lien dimensionné pour ça. L'amont de votre serveur est la seule position d'où l'on peut à la fois valider la poignée de main et ne pas payer la bande passante de ce qu'on rejette — c'est là que se place une protection DDoS FiveM avec filtre Layer 7 cfx.re.

Concrètement, sur nos serveurs, le durcissement natif reste recommandé — il ne coûte rien et il ferme les endpoints HTTP — mais il travaille derrière le proxy, pas à sa place. Le guide complet pour stopper les attaques DDoS sur FiveM couvre l'architecture, et le guide d'installation le bloc server.cfg à coller. La tarification se fait au pic de joueurs quotidien.

Pourquoi une ressource Lua « anti-DDoS » ne peut pas y arriver

Il existe des dizaines de ressources qui promettent de bloquer les attaques L7. Le problème est de position, pas de qualité de code.

Une ressource Lua s'exécute dans FXServer. Pour qu'elle voie une requête, il faut que la connexion ait été acceptée, que la requête ait été lue, et que le runtime ait été invoqué. Autrement dit : tout le coût que l'attaque cherchait à vous imposer a déjà été payé au moment où votre code peut réagir. La ressource peut décider de ne pas répondre, ce qui économise la sérialisation — exactement ce que sv_requestParanoia fait déjà, en natif, sans runtime Lua dans la boucle.

Et sur le flood de connexions, c'est pire : la ressource ne peut agir qu'à partir de la phase de deferral, donc après que la poignée de main a été engagée. Sur le flood de téléchargement, elle ne voit rien du tout, parce que le fileserver ne passe pas par elle.

Une ressource peut faire des choses utiles — journaliser, appliquer une politique de connexion, bannir un joueur identifié. Elle ne peut pas faire de la mitigation, parce que la mitigation consiste par définition à ne pas recevoir le trafic.

Questions fréquentes

Quel niveau de sv_requestParanoia dois-je mettre ?

3 sur un serveur public. Il inclut les blocages des niveaux 1 et 2 et ferme en plus la socket. Le seul effet secondaire notable est que vous ne pourrez plus ouvrir /players.json depuis votre navigateur — c'est le comportement attendu.

Est-ce que ça va casser mes outils de monitoring ?

Ça dépend de leurs en-têtes. Le niveau 1 rejette les requêtes portant un en-tête Via, ajouté par les proxies HTTP ; le niveau 2 rejette Upgrade-Insecure-Requests, envoyé par les navigateurs. Un client qui n'envoie ni l'un ni l'autre — la plupart des outils en ligne de commande et des agents de monitoring — continue de fonctionner.

Pourquoi mon serveur lag alors que la bande passante est normale ?

C'est la signature d'une attaque applicative plutôt que volumétrique : le CPU monte, le tick s'allonge, les joueurs timeout ensemble, et le graphe de trafic ne montre rien de spectaculaire. Vérifiez d'abord sv_requestParanoia, puis regardez si les tentatives de connexion explosent. Si la cause reste floue, voyez comment savoir si c'est vraiment un DDoS.

sv_endpointPrivacy est-il encore utile ?

Sur un build récent, non : la protection est devenue inconditionnelle et le convar a été retiré. Le serveur vous demandera de l'enlever de votre configuration au démarrage. Sur un build ancien, laissez-le à true.

Un pare-feu suffit-il contre les attaques L7 ?

Non. Un pare-feu décide à partir d'adresses, de ports et de débits. Les trois vecteurs décrits ici utilisent des requêtes valides depuis des adresses variées vers des ports ouverts. Il faut comprendre le protocole pour trancher, et ça se fait en amont de la machine, pas dessus.