Protéger son serveur FiveM des attaques L7 : le guide complet

Un serveur FiveM qui grossit devient vite une cible. Et contrairement aux idées reçues, la plupart des serveurs RP ne tombent pas sous un mur de trafic : ils tombent sous une attaque applicative (Layer 7), souvent quelques milliers de requêtes bien choisies qui suffisent à figer le thread principal. Bonne nouvelle : on peut se blinder, et une grande partie est gratuite, dans votre server.cfg. Voici la méthode complète.

L7, c'est quoi exactement sur FiveM ?

Une attaque DDoS se lit en couches. Le L3/L4 (volumétrique) cherche à saturer le lien réseau avec des paquets : UDP flood, amplification, SYN flood. C'est du volume, et ça se filtre en amont, sur le réseau. Le L7 (applicatif) est plus fin : l'attaquant parle le langage de votre serveur pour l'épuiser avec peu de bande passante.

Sur FiveM, le serveur ne fait pas que du jeu en UDP : il expose aussi un petit serveur HTTP sur le même port (30120 par défaut), qui sert des pages comme info.json, players.json et dynamic.json. Ces endpoints, plus les requêtes de découverte (getinfo, getstatus) et le flux de connexion, forment votre surface d'attaque L7.

La surface d'attaque d'un serveur FiveM

• Les endpoints JSON (info.json, players.json, dynamic.json) : on les martèle jusqu'à ce que le thread serveur ralentisse et lâche. C'est le vecteur L7 numéro 1 sur FiveM.
• getinfo / getstatus : le protocole de requête façon Source. Envoyé en boucle, il consomme du CPU pour rien.
• Le connect-flood : des milliers de tentatives de connexion à demi ouvertes pour saturer la file d'authentification.
• L'exposition de l'IP : si votre IP d'origine fuite (via la liste des serveurs ou les endpoints), l'attaquant peut viser directement la machine et court-circuiter toute protection placée devant.

Étape 1 : Durcir le server.cfg (le socle, gratuit)

La première ligne de défense est native. Ajoutez ce bloc à votre server.cfg et redémarrez :

sv_endpointPrivacy true
sv_requestParanoia 3
sv_forceIndirectListing true
sv_disableInactiveListing true
sv_authMinTrust 5

Ce que fait chaque ligne :

• sv_endpointPrivacy true : masque les adresses IP des joueurs. Fini les scripts « IP grabber » qui récupèrent l'IP des connectés.
• sv_requestParanoia 3 : durcit le traitement des requêtes HTTP. Au niveau 2 et plus, les appels à info.json, players.json et dynamic.json répondent « Nope » ; au niveau 3, la connexion est en plus fermée. C'est le cœur de la parade anti-flood applicatif (on y consacre un article dédié).
• sv_forceIndirectListing true : votre serveur est listé via le relais Cfx.re, pas avec son IP directe. On ne trouve plus votre machine sur la liste publique.
• sv_disableInactiveListing true : n'apparaît pas sur la liste tant que personne ne joue, réduisant la surface d'exposition.
• sv_authMinTrust 5 : exige le niveau de confiance d'entitlement le plus élevé. Cela bloque une bonne partie des clients non légitimes et des bots.

À savoir : sv_requestParanoia 3 ferme aussi l'accès navigateur à vos endpoints JSON. Si un outil de monitoring externe lit players.json, prévoyez une exception côté proxy plutôt que de baisser le niveau.

Étape 2 : Masquer l'IP d'origine

Le meilleur filtre du monde ne sert à rien si l'attaquant connaît l'IP réelle de votre serveur. L'objectif : que le monde ne voie qu'une adresse de façade (relais Cfx.re ou proxy), jamais la machine.

• Gardez sv_forceIndirectListing true pour ne pas publier l'IP sur la liste.
• Si vous passez par un proxy applicatif, annoncez son adresse avec sv_listingIpOverride / sv_listingHostOverride et laissez le proxy relayer vers l'origine.
• Ne diffusez jamais l'IP d'origine dans un lien de connexion direct, un screenshot de console ou un fichier de config partagé.

Étape 3 : Le filtrage en amont (déjà en place chez HG)

Le server.cfg durci protège le processus, mais il traite déjà chaque paquet arrivé jusqu'à lui. Pour tenir sous une vraie attaque, il faut trier avant : rate-limiting par IP, filtrage comportemental des requêtes getinfo/getstatus, blocage des floods de connexion, et absorption du volume L3/L4 en bordure de réseau.

Sur nos hébergements, cette couche tourne déjà par défaut. Les floods qui visent les endpoints du port de jeu sont filtrés en amont, en complément du scrubbing volumétrique réseau (L3/L4) : le trafic passe par une façade qui absorbe le volume, applique un rate-limiting applicatif et n'expose jamais votre origine. Concrètement, vous n'avez rien à installer pour cette partie : votre serveur ne voit que du trafic propre. Le durcissement du server.cfg décrit ci-dessus vient en plus, en défense en profondeur.

Ce que la protection réseau fait… et ne fait pas

Une protection L3/L4 comme notre protection réseau encaisse les gros volumes : c'est indispensable, mais elle voit du « trafic », pas de la « logique de jeu ». Un flood de players.json de 5 000 requêtes/s ressemble à du trafic HTTP légitime : seul un filtre conscient de l'application (paranoia, rate-limiting, filtrage des endpoints) le neutralise. Les deux couches sont complémentaires, pas interchangeables.

Checklist protection L7 FiveM

• sv_endpointPrivacy true : IP des joueurs masquées.
• sv_requestParanoia 3 : endpoints JSON verrouillés, floods HTTP fermés.
• sv_forceIndirectListing true + sv_disableInactiveListing true : IP d'origine hors de la liste.
• sv_authMinTrust 5 : clients non légitimes filtrés.
• IP d'origine jamais divulguée : façade uniquement.
• Filtrage applicatif en amont : rate-limiting et tri avant le serveur.

Ce socle gratuit couvre déjà l'essentiel des attaques L7 opportunistes côté serveur. Et pour tout ce qui vise le réseau et les endpoints, la protection est déjà active chez nous par défaut : filtrage applicatif en amont et scrubbing volumétrique réseau, sans que vous ayez à toucher à votre serveur. Hébergé en France, filtré en amont, sans exposition de votre origine : vous vous concentrez sur votre RP, on s'occupe du reste.