info.json, players.json, dynamic.json : verrouiller les endpoints de votre serveur FiveM

Quand on parle d'attaque L7 sur FiveM, tout tourne autour de trois petits fichiers : info.json, players.json et dynamic.json. Ils sont pratiques, ils sont publics… et ils sont le premier levier d'un attaquant. Beaucoup d'admins pensent « c'est géré de base » : en partie seulement. Voici ce que ces endpoints exposent et comment les verrouiller pour de bon.

Que révèlent ces endpoints ?

FiveM sert, sur le port du jeu, un mini serveur HTTP interrogeable par n'importe qui :

• info.json : version du serveur, ressources chargées, variables publiques (sv_projectName, etc.). Une carte d'identité complète de votre plateforme.
• players.json : la liste des joueurs connectés (noms, identifiants, ping). Un régal pour le scraping et le ciblage.
• dynamic.json : nombre de joueurs, slots, nom, mapname. Léger, donc parfait à marteler en boucle.

Deux problèmes se cumulent : la fuite d'informations (on cartographie votre serveur et vos joueurs) et surtout le vecteur de flood (on répète l'appel jusqu'à faire ramer le thread principal, et le serveur décroche).

« Mais je le fais déjà de base » : pourquoi ça ne suffit pas

FiveM applique quelques garde-fous par défaut, et un serveur sain répond normalement à ces endpoints : c'est voulu, la liste des serveurs en a besoin pour vous afficher. Le défaut, c'est justement que l'accès reste ouvert et bon marché pour l'attaquant :

• Par défaut, sv_requestParanoia vaut 0 : aucune restriction sur les requêtes HTTP.
• Par défaut, sv_endpointPrivacy est désactivé : les IP des joueurs sont récupérables.
• La liste publique peut exposer votre IP d'origine si vous ne forcez pas le listing indirect.

Autrement dit : « de base », votre serveur répond poliment à tout le monde, y compris à celui qui l'attaque. Le durcissement n'est pas automatique : c'est à vous de l'activer.

Verrouillage 1 : Masquer les IP joueurs

sv_endpointPrivacy true

À activer systématiquement. Cela empêche les ressources (et donc les scripts malveillants) de lire l'IP réelle des joueurs. Aucune contrepartie pour un serveur RP normal.

Verrouillage 2 : Fermer les endpoints JSON

C'est le rôle de sv_requestParanoia. À partir du niveau 2, les appels à info.json, dynamic.json et players.json renvoient « Nope » ; au niveau 3, la connexion HTTP est en plus fermée, ce qui rend le flood bien plus coûteux pour l'attaquant.

sv_requestParanoia 3

Effet de bord à connaître : au niveau 2 et plus, l'accès navigateur à ces endpoints est bloqué. Si un site de statut ou un outil externe lit players.json, ne baissez pas la paranoïa : ouvrez une exception ciblée au niveau du proxy pour cet outil précis.

Verrouillage 3 : Ne pas exposer l'origine

sv_forceIndirectListing true
sv_disableInactiveListing true

Ces deux réglages évitent que votre IP réelle apparaisse sur la liste des serveurs. Sans ça, verrouiller les endpoints ne sert à rien : l'attaquant vise l'IP directement et contourne toute protection placée devant.

Verrouillage 4 : Le filtrage en amont (chez HG, c'est déjà fait)

Fermer les endpoints dans server.cfg aide, mais votre machine reçoit et traite quand même chaque requête avant de répondre « Nope ». Sous une attaque soutenue, c'est encore du CPU consommé. La vraie robustesse vient d'un tri en amont : un proxy applicatif qui absorbe le flood, applique un rate-limiting par IP et ne laisse passer que le trafic légitime.

Sur nos hébergements, les attaques qui visent ces endpoints sont déjà filtrées par défaut. Notre couche HG-Proxy complète le scrubbing réseau volumétrique (L3/L4) et masque totalement votre origine : vous n'avez rien à configurer pour cette partie. Les réglages server.cfg ci-dessus restent utiles en défense en profondeur, mais vous n'êtes pas seul en première ligne.

Checklist endpoints FiveM

• sv_endpointPrivacy true : IP joueurs masquées.
• sv_requestParanoia 3 : info/players/dynamic.json fermés, connexions coupées.
• sv_forceIndirectListing true + sv_disableInactiveListing true : origine hors liste publique.
• Exception monitoring gérée au proxy, pas en baissant la paranoïa.
• Filtrage en amont pour ne pas traiter le flood sur le serveur lui-même.

Ces endpoints resteront toujours un point sensible de FiveM : ce n'est pas un bug, c'est le protocole. La bonne nouvelle, c'est que chez nous la couche de filtrage devant vos endpoints est déjà en place : le durcissement server.cfg vient l'épauler, mais vous êtes protégé dès le départ. Vous montez votre RP, on tient la porte.