Anti-DDoS FiveM gratuit : ce qui existe vraiment et où ça s'arrête

Disons le prix tout de suite

Cet article est honnête sur un point dès le départ : fiveshield n'a pas d'offre gratuite. La facturation est calculée sur votre pic quotidien de joueurs simultanés, avec un plancher de 2,25 $ CA par jour tant qu'un serveur est actif — ce plancher couvre n'importe quel pic jusqu'à 50 joueurs. Au-delà de 50, chaque tranche de joueurs est facturée au tarif de son palier, entre 0,030 $ et 0,047 $ par joueur et par jour. Pas d'abonnement, pas de contrat, pas de supplément de bande passante. Le détail est sur la page tarification.

Cela dit, si vous cherchez « anti-DDoS FiveM gratuit », la question est légitime. Une partie du travail de protection est gratuite, se fait ce soir, et beaucoup de propriétaires ne l'ont jamais faite. Une autre partie ne peut structurellement pas l'être. Cet article trace la ligne entre les deux.

Ce que vous pouvez faire gratuitement, ce soir

Trois lignes dans server.cfg. Elles ne coûtent rien, elles sont documentées par FiveM, et elles ferment le vecteur d'attaque le plus utilisé contre les serveurs FiveM.

set sv_requestParanoia 3
set sv_forceIndirectListing true
set sv_listingHostOverride "votre-domaine-proxy.example.com"

sv_requestParanoia est un entier de 0 à 3, à 0 par défaut, prévu pour contrer les floods HTTP passant par des proxies. Au niveau 1, il bloque les IP dont les requêtes contiennent un en-tête Via ; au niveau 2, il ajoute Upgrade-Insecure-Requests ; au niveau 3, il ferme en plus la socket sur laquelle les requêtes ont été soumises. Sur /info.json, /dynamic.json et /players.json, une requête rejetée reçoit un 403 dont le corps est littéralement Nope..

Pourquoi ça compte : ces trois endpoints répondent sans authentification, et chaque requête coûte plus cher à votre serveur qu'à l'appelant. C'est l'attaque la moins chère à monter contre un serveur FiveM, et elle est gratuite à fermer. Le détail complet est dans notre article sur les attaques Layer 7 sur FiveM.

sv_forceIndirectListing est un booléen (false par défaut) qui empêche votre serveur d'être annoncé dans la liste avec sa vraie adresse IP. Il n'a de sens que si vos joueurs se connectent par autre chose que l'IP d'origine — un proxy, un nom d'hôte. Sans ça, votre adresse est publiée à qui la demande.

Un mot sur sv_endpointPrivacy, qu'on retrouve dans tous les blocs partagés : il concernait les adresses IP des joueurs dans les rapports HTTP publics du serveur, jamais celle du serveur. Sur les builds FXServer actuels, il a été retiré parce que la protection est devenue inconditionnelle, et le serveur affiche un message au démarrage demandant de l'enlever de la configuration. Même remarque pour sv_useDirectListing, absent de la documentation officielle : ne construisez rien dessus.

Une fois ces lignes en place, redémarrez et vérifiez le résultat plutôt que la config : le CFX Finder montre l'adresse de connexion que Cfx.re publie réellement pour votre serveur.

Le pare-feu de votre hébergeur

Deuxième niveau gratuit, celui-là dépend de chez qui vous êtes.

Si votre machine est un serveur dédié Bare Metal Game chez OVHcloud, vous avez accès à la protection anti-DDoS Game : un moteur applicatif avec un profil par famille de jeu — et FiveM fait partie des profils disponibles, aux côtés de Rust, Minecraft, Counter-Strike 2, Ark et Valheim. Il s'active dans l'espace client, sous Network → Adresses IP Publiques, via le menu ⁝ de l'IP puis « Configurer le Game firewall » ; vous y ajoutez des règles par protocole et plage de ports, avec une politique « Default Deny » possible. Les règles deviennent actives en quelques minutes.

Les limites à connaître : c'est réservé à la gamme Game (OVHcloud indique qu'il peut être indisponible ou limité sur la gamme Eco), et le profil FiveM n'existe que sur les générations GAME-1 et GAME-2 récentes (2024 et postérieures). Chaque IP se configure séparément, et le nombre de règles est plafonné par IP. Sur un VPS, un hébergement FiveM mutualisé ou chez un autre fournisseur, ce levier ne vous est pas ouvert — et c'est le cas de la majorité des serveurs communautaires.

Séparément, l'Edge Network Firewall d'OVH verrouille l'accès à la machine par IP source. Notre guide d'installation en donne la table de règles exacte, avec le piège classique : une règle « Autoriser » dont le champ IP source est vide autorise tout le trafic IPv4 et annule le pare-feu.

Verrouiller l'origine avec nftables

Troisième niveau gratuit, disponible partout où vous avez un accès root Linux. L'idée : n'accepter le trafic de jeu que depuis les plages du proxy, et rien d'autre.

# Table dédiée : ne touche pas à vos règles existantes
nft add table inet fivem
nft add chain inet fivem input '{ type filter hook input priority 0; policy accept; }'

# Remplacez 203.0.113.0/24 par les CIDR exacts de votre proxy
nft add rule inet fivem input udp dport 30120 ip saddr != { 203.0.113.0/24 } drop
nft add rule inet fivem input tcp dport 30120 ip saddr != { 203.0.113.0/24 } drop

# Rendre les règles persistantes au redémarrage
nft list ruleset > /etc/nftables.conf
systemctl enable --now nftables

Adaptez 30120 si votre serveur écoute sur un autre port, et n'oubliez pas le port de txAdmin si vous voulez le fermer aussi.

La limite honnête de cette approche : le noyau ne peut jeter un paquet qu'après l'avoir reçu. Vos règles protègent le processus FXServer, pas votre lien réseau. Face à un flood volumétrique qui sature la bande passante montante de la machine, le pare-feu fait exactement son travail et le serveur tombe quand même, parce que les paquets légitimes n'arrivent plus à passer. C'est la raison structurelle pour laquelle la mitigation doit se faire en amont, sur un lien dimensionné pour l'absorber.

Récapitulatif de ce que chaque mesure gratuite couvre réellement :

Les offres gratuites du marché, et leur plafond

Il existe de vraies offres gratuites d'anti-DDoS pour FiveM. Elles suivent trois modèles, et chacun a une limite qu'il vaut mieux connaître avant de bâtir dessus. On décrit les modèles, pas les fournisseurs.

Le palier gratuit plafonné. Un service complet, mais borné : un seul serveur, un nombre de joueurs simultanés bas, parfois une seule localisation de proxy. C'est honnête et souvent suffisant pour un serveur de test ou un lancement à quelques joueurs. Le plafond arrive au moment précis où votre serveur commence à marcher — c'est-à-dire au moment où quelqu'un a une raison de l'attaquer.

L'inclus chez l'hébergeur. Une protection livrée avec l'offre d'hébergement, sans supplément. Le point à vérifier : c'est presque toujours du filtrage réseau générique au niveau de l'infrastructure, pas un filtrage qui comprend le protocole FiveM. Il absorbe du volume, il ne distingue pas un vrai joueur d'une fausse connexion — et il vous lie à cet hébergeur.

L'essai limité dans le temps. Trois jours, sept jours, un mois. Utile pour mesurer si le service tient, inutile comme plan de protection : les attaques n'attendent pas la fenêtre d'essai.

À cela s'ajoutent les ressources Lua gratuites qui promettent une protection anti-DDoS. Elles ne peuvent pas fonctionner, et pas pour des raisons de qualité de code : une ressource s'exécute dans FXServer, donc la connexion a été acceptée, la requête lue et le runtime invoqué avant qu'elle ne puisse réagir. Tout le coût que l'attaque cherchait à imposer a déjà été payé. Ce qu'elles peuvent faire d'utile — journaliser, appliquer une politique de connexion — n'est pas de la mitigation.

Le seuil où le gratuit s'arrête

Il y a une frontière nette, et elle n'est pas au niveau du volume. Elle est au flood de connexions cfx.re.

Un joueur qui rejoint votre serveur déroule une poignée de main : demande d'entrée, vérification d'identité via Cfx.re, phase de deferral, puis passage au flux de jeu. Une attaque de connexion lance cette séquence en boucle sans jamais la terminer. Les paquets sont bien formés, ils viennent d'adresses distinctes, et ils ressemblent octet pour octet à de vrais joueurs — parce que c'est ce qu'ils sont, à l'intention près.

Aucune des mesures gratuites plus haut n'est documentée comme ayant prise dessus. sv_requestParanoia inspecte des en-têtes HTTP sur trois endpoints, et le flood de connexions ne passe pas par là. nftables décide sur des adresses, des ports et des débits, et il n'y a rien d'anormal à voir. Le pare-feu Game a bien un profil FiveM, mais la documentation d'OVHcloud ne précise pas quelles étapes de la séquence d'entrée cfx.re ce profil valide. Trancher demande un anti-DDoS FiveM qui filtre en L7, qui implémente réellement la poignée de main cfx.re et suit l'état de chaque session.

Le deuxième mur, c'est le volumétrique pur : quand le flood sature le lien montant de votre machine, il n'existe aucune règle locale qui puisse aider. Il faut de la capacité en amont, et la capacité n'est jamais gratuite pour celui qui la fournit.

Ce que coûte une protection qui tient

Reprenons les chiffres du début, maintenant qu'ils ont un contexte. La facturation suit votre pic quotidien, avec un plancher de 2,25 $ CA par jour tant que le serveur est actif — ce plancher couvre tout pic jusqu'à 50 joueurs, et les paliers par joueur ne commencent qu'au-delà. Un serveur à 30 joueurs de pic reste donc au plancher, et désactiver le serveur depuis le tableau de bord arrête la facturation.

Le tableau de bord démarre avec 10 $ CA de solde : crédités gratuitement sur votre premier serveur pendant la promotion d'essai, sinon déposés par vous et directement disponibles pour payer votre usage. Ce n'est pas une offre gratuite — c'est du solde de départ qui couvre les premiers jours, et il faut le dire comme ça.

Ce que couvre ce prix et que le gratuit ne couvre pas : l'absorption du volume en amont sur une infrastructure dimensionnée pour, le filtrage L4 en XDP, la validation de la poignée de main cfx.re en L7, le cache CDN devant les téléchargements, la protection du panel txAdmin et le masquage permanent de l'origine. C'est ce que doit couvrir une protection anti-DDoS FiveM complète, et le guide complet pour stopper les attaques DDoS explique pourquoi ces couches ne sont pas interchangeables.

Faites d'abord les mesures gratuites. Elles sont bonnes, elles sont documentées, et elles restent utiles derrière un proxy. Payez quand votre serveur vaut la peine d'être attaqué — vous le saurez, ça arrive toujours au même moment. Le moment venu, commencez par comment choisir un anti-DDoS FiveM.

Questions fréquentes

Existe-t-il un anti-DDoS FiveM vraiment gratuit et illimité ?

Non, et c'est une question de coût réel : absorber un flood demande de la bande passante et du matériel que quelqu'un paie. Les offres gratuites existantes sont plafonnées en joueurs, limitées dans le temps, ou livrées comme filtrage générique chez un hébergeur.

Quelle est la mesure gratuite la plus rentable ?

set sv_requestParanoia 3. Une ligne, aucun effet de bord notable sauf que vous ne pourrez plus ouvrir /players.json depuis un navigateur, et elle ferme le vecteur d'attaque le moins cher à monter contre un serveur FiveM.

Le pare-feu de mon VPS suffit-il ?

Il protège le processus, pas le lien. Des règles nftables empêchent FXServer de traiter le trafic indésirable, mais les paquets arrivent quand même sur la carte réseau et consomment la bande passante. Contre un flood volumétrique, le serveur tombe malgré des règles parfaites.

Les 10 $ CA de solde sont-ils une offre gratuite ?

Non. C'est du solde de départ : crédité pendant la promotion d'essai sur un premier serveur, sinon déposé par vous. Il couvre les premiers jours au plancher de 2,25 $ CA par jour, puis la facturation quotidienne normale prend le relais.

Puis-je combiner les mesures gratuites et un service payant ?

Oui, et c'est la bonne configuration. sv_requestParanoia, le listing indirect et le verrouillage nftables travaillent derrière le proxy et ferment les chemins qu'il ne voit pas — en particulier un accès direct à l'IP d'origine par quelqu'un qui l'aurait retrouvée.