sv_requestParanoia 3 : bien régler la « paranoïa » de votre serveur FiveM

Si vous ne deviez retenir qu'un seul réglage anti-flood dans le server.cfg de FiveM, ce serait sv_requestParanoia. C'est la parade native contre les attaques HTTP qui visent les endpoints de votre serveur. Encore faut-il comprendre ses quatre niveaux et leurs effets de bord. Décryptage.

À quoi sert sv_requestParanoia ?

FiveM expose un petit serveur HTTP sur le port du jeu (info.json, players.json, dynamic.json). sv_requestParanoia définit à quel point le serveur se méfie des requêtes HTTP qu'il reçoit. Plus le niveau est haut, plus il filtre agressivement les requêtes typiques des floods applicatifs et des proxies d'attaque. Par défaut, il vaut 0 : aucune restriction.

Les quatre niveaux, en détail

• Niveau 0 (défaut) : aucun filtrage. Toutes les requêtes HTTP sont traitées, y compris celles des attaquants.
• Niveau 1 : bloque les requêtes portant un en-tête Via. Cet en-tête trahit le passage par un proxy : c'est la signature classique d'un flood relayé.
• Niveau 2 : bloque en plus les IP qui envoient un en-tête Upgrade-Insecure-Requests (typique d'un navigateur). Surtout, à partir de ce niveau, les appels à info.json, dynamic.json et players.json renvoient « Nope » : vos endpoints ne servent plus de données à qui les martèle.
• Niveau 3 : tout ce que fait le niveau 2, plus la fermeture de la socket sur laquelle la requête est arrivée. L'attaquant ne reçoit même plus de réponse : sa connexion est coupée, ce qui rend le flood nettement plus coûteux à maintenir.

# Recommandé pour un serveur RP en production
sv_requestParanoia 3

Niveau 3 en prod : l'effet de bord à connaître

Le niveau 3 est le plus solide, mais il n'est pas gratuit : dès le niveau 2, l'accès navigateur à vos endpoints JSON est bloqué. Concrètement :

• Un site de statut externe ou un bot Discord qui lit players.json pour afficher « X joueurs en ligne » ne recevra plus rien.
• Certains outils de monitoring tiers reposent sur ces endpoints : ils tomberont en erreur.

La bonne pratique : ne baissez pas la paranoïa pour faire plaisir à un outil. Gardez sv_requestParanoia 3 et créez une exception ciblée au niveau du proxy pour l'IP de votre outil de statut. Vous gardez la protection maximale tout en laissant passer ce que vous maîtrisez.

La paranoïa ne travaille pas seule

sv_requestParanoia gère le HTTP ; associez-le aux réglages qui couvrent le reste de la surface d'attaque :

sv_endpointPrivacy true      # masque les IP des joueurs
sv_requestParanoia 3         # ferme les endpoints JSON au flood
sv_forceIndirectListing true # IP d'origine hors de la liste publique
sv_disableInactiveListing true
sv_authMinTrust 5            # bloque les clients non légitimes

Ensemble, ces cinq lignes constituent le socle de sécurité applicatif d'un serveur FiveM. Elles sont gratuites et prennent effet au prochain redémarrage.

Ce que la paranoïa ne protège PAS

Important : sv_requestParanoia ne traite que le HTTP. Il ne fait rien contre :

• les floods UDP sur le protocole de jeu (getinfo, getstatus, connect-flood) ;
• les attaques volumétriques L3/L4 qui saturent le lien réseau bien avant d'atteindre l'application.

Pour ces couches, il faut un filtrage réseau en amont. Sur nos hébergements, c'est déjà en place par défaut : filtrage comportemental des requêtes de jeu et blocage des connect-floods côté HG-Proxy, scrubbing volumétrique réseau (L3/L4) en bordure, et masquage de votre origine. Autrement dit : le durcissement server.cfg et sv_requestParanoia 3 sont votre défense en profondeur, pas votre unique rempart. Vous êtes déjà couvert en première ligne.

À retenir

• sv_requestParanoia 3 = protection HTTP maximale (endpoints fermés + socket coupée).
• Niveau 2+ : pensez à l'exception proxy pour vos outils de statut légitimes.
• À combiner avec endpointPrivacy, forceIndirectListing et authMinTrust.
• Ne remplace pas la protection réseau L3/L4 : déjà assurée chez HG.