Un serveur FiveM encaisse deux types de menaces bien distincts : les tricheurs qui exploitent des failles côté script, et les attaques réseau qui visent à le faire tomber ou à le ralentir jusqu'à le rendre injouable. Notre guide anti-cheat couvre la première en détail. Celui-ci se concentre sur la seconde, la protection réseau, et referme la boucle avec une checklist de sécurité qui couvre les deux fronts sans répéter ce qui est déjà dit ailleurs.
Ce qu'est réellement une attaque DDoS sur un serveur FiveM
Une attaque DDoS (déni de service distribué) sature la bande passante et la connexion réseau du serveur avec un volume de trafic largement supérieur à ce que l'infrastructure réseau de l'hébergeur peut absorber, jusqu'à ce que les joueurs légitimes ne puissent plus s'y connecter ou subissent des latences extrêmes. Sur FiveM, ça vient rarement du hasard : c'est le plus souvent un joueur banni qui se venge, un serveur concurrent qui veut couper la communauté, ou un différend qui dégénère. L'adresse IP du serveur (ou celle du joueur qui se connecte, dans les attaques ciblant un individu plutôt qu'un serveur) est la cible : une fois obtenue, elle circule vite dans certains milieux, que le serveur tourne sur un VPS, un serveur dédié ou tout autre hébergement exposé publiquement.
Pourquoi la protection se joue avant le serveur, pas dessus
Un pare-feu (firewall) configuré sur le serveur lui-même (VPS ou dédié) ne sert à rien contre une attaque volumétrique : le trafic malveillant sature déjà la liaison réseau avant même d'atteindre le système d'exploitation qui pourrait le filtrer. La seule protection qui fonctionne réellement se situe en amont, au niveau de l'infrastructure réseau de l'hébergeur, sur l'ensemble de ses serveurs hébergés (qu'ils soient vendus comme VPS, une tranche virtuelle obtenue par virtualisation et parfois commercialisée sous le nom de serveur cloud ou d'hébergement cloud, ou comme hébergement dédié), qui détecte et absorbe le trafic anormal avant qu'il n'arrive jusqu'à votre machine.
C'est la raison pour laquelle la protection anti-DDoS est intégrée à toutes nos offres FiveM, avec un réseau à 10 Gbit/s de bande passante, plutôt que proposée en option payante à ajouter après coup. Si votre hébergement actuel facture cette protection à part, ou pire, ne la propose pas du tout, c'est un signal à prendre au sérieux : elle finit par manquer précisément le jour où vous en avez besoin.
Le type d'hébergement joue aussi sur l'ampleur des dégâts collatéraux. Sur un hébergement mutualisé, plusieurs clients se partagent la même bande passante : une attaque qui vous vise peut ralentir des serveurs qui n'ont rien à voir avec vous, et inversement. Un VPS (une tranche virtuelle obtenue par virtualisation sur du matériel partagé) ou un serveur dédié isole ce risque : le firewall réseau de l'hébergeur absorbe le trafic malveillant en amont, sans que votre voisin d'hébergement en subisse les conséquences.
Durcir l'accès à l'administration du serveur
Une fois la couche réseau couverte côté hébergeur, le reste de la sécurité dépend de la façon dont vous administrez le serveur au quotidien :
- Accès root en SSH par clé, jamais par mot de passe seul, sur le VPS ou le serveur dédié qui héberge le serveur. Un mot de passe, même complexe, reste exposé aux tentatives automatisées permanentes qui balaient le port 22 sur Internet.
- txAdmin accessible uniquement aux personnes de confiance, avec des comptes nominatifs plutôt qu'un mot de passe partagé : en cas de doute sur un membre du staff, on révoque un compte au lieu de changer un mot de passe que tout le monde utilise.
- Artefacts FXServer et scripts à jour : les versions obsolètes concentrent la majorité des failles connues et documentées publiquement, donc les plus faciles à exploiter par quelqu'un qui ne cherche pas longtemps.
- Sauvegarde régulière de la base de données : une attaque réseau ne touche pas vos données, mais une intrusion réussie sur l'accès admin peut le faire. Une sauvegarde récente, stockée sur un espace disque distinct du serveur (un backup externalisé), reste le dernier filet, quelle que soit la menace.
Ne publiez pas l'IP réelle du serveur inutilement. Si votre hébergeur propose une adresse de connexion dédiée masquant l'IP d'origine derrière sa protection réseau, préférez-la à l'IP brute en annonce publique (Discord, forums, réseaux sociaux) : moins elle circule, moins elle devient une cible facile.
Ce que FXServer protège nativement, avant l'anti-cheat applicatif
Entre la protection réseau de l'hébergeur et l'anti-cheat applicatif détaillé dans notre guide dédié, il existe une couche intermédiaire souvent oubliée : les protections natives de la plateforme Cfx.re elle-même, actives par défaut sur les versions récentes de FXServer (à partir du build 8450) :
| Protection native FXServer | Ce qu'elle vérifie |
|---|---|
| CNL (Client Network Lockdown) | Surveille les connexions entrantes et déconnecte les clients qui dépassent les seuils de tolérance réseau attendus d'un vrai client FiveM. |
sv_pure_verify_client_settings |
Valide que la configuration envoyée par le client correspond à ce qu'un jeu non modifié doit transmettre. |
sv_authMaxVariance / sv_authMinTrust |
Évaluent la fiabilité de l'identité du joueur avant même qu'il n'entre en jeu. |
sv_filterRequestControl |
Bloque les demandes de contrôle réseau non autorisées selon la politique définie sur le serveur. |
La documentation officielle Cfx.re est directe là-dessus : ces protections aident, mais « des choses passent parfois au travers ». Elles ne dispensent ni d'une bonne hygiène de script côté serveur (détaillée plus loin, avec RegisterNetEvent/AddEventHandler) ni d'un anti-cheat applicatif dédié pour un serveur RP avec une communauté active. Des solutions tierces spécialisées comme FiveGuard couvrent précisément cette couche-là, en complément des protections natives listées ci-dessus.
Le rôle du game build (sv_enforceGameBuild) dans la maintenance du serveur
sv_enforceGameBuild indique aux clients quelle base de contenu GTA V (véhicules, armes, maps ajoutés par une DLC Rockstar) le serveur attend : à l'origine, la documentation officielle Cfx.re le présente comme un sélecteur de compatibilité de contenu, pas comme un outil anti-triche à proprement parler. Son lien avec la sécurité reste indirect, mais réel : laisser ce paramètre non défini, ou figé sur un très ancien build, signifie que certains clients tournent sur un exécutable de jeu qui n'a plus reçu aucune mise à jour Rockstar depuis longtemps. La bonne pratique rejoint celle des artifacts FXServer eux-mêmes (voir plus haut) : fixer sv_enforceGameBuild à une valeur choisie et documentée, cohérente avec ce que vos scripts et vos MLO exigent réellement, plutôt que de la laisser par défaut ou de sauter sur la toute dernière version sans vérifier la compatibilité de vos resources.
Comment un tricheur contourne réellement un serveur FiveM
Comprendre le vecteur d'attaque aide à savoir où poser la défense. Sur FiveM, la quasi-totalité des triches ne passe pas par une faille du jeu lui-même, mais par un exécuteur Lua couplé à une injection dans le processus client : cet outil permet d'exécuter du code arbitraire côté client et, surtout, d'appeler directement les events réseau que votre script serveur écoute, avec n'importe quel argument. Concrètement, si un script métier déclenche TriggerServerEvent('boutique:acheterArticle', prix) en faisant confiance au prix envoyé par le client, un tricheur peut déclencher ce même event avec un prix de son choix, sans jamais passer par l'interface d'achat normale.
C'est ce qu'on appelle l'event spoofing : le client ne demande plus une action au serveur, il lui dicte directement un résultat. Un menu de triche injecté peut aussi lire l'état du jeu en mémoire (position, véhicule, contenu affiché de l'inventaire) pour cibler quel event falsifier, mais il ne peut jamais forcer le serveur à faire confiance à une valeur si le script serveur la revalide lui-même.
La règle qui prime sur toutes les autres : ne jamais faire confiance au client
La documentation officielle Cfx.re est explicite : le client demande une action, c'est au serveur de décider du résultat à partir de son propre état, jamais l'inverse. RegisterNetEvent ne fait qu'autoriser un event à traverser la frontière réseau : il n'authentifie personne et ne valide aucun contenu. Toute la validation reste à la charge du handler enregistré avec AddEventHandler côté serveur.
Sur un event qui touche à l'argent, à un item ou à un déplacement, trois réflexes évitent l'essentiel des exploits :
- Ne jamais accepter un montant, un prix ou une récompense envoyé par le client. Le serveur doit recalculer la valeur lui-même à partir de sa propre configuration ou de l'état stocké en base, jamais reprendre un chiffre transmis par
TriggerServerEvent. - Valider le type, la plage et les valeurs autorisées de chaque paramètre reçu avant toute écriture en base de données : un identifiant d'item qui n'existe pas, un grade supérieur à ceux définis pour le job, une position à des centaines de mètres de la dernière position connue, sont des signaux à rejeter plutôt qu'à traiter.
- Vérifier la cohérence temporelle et spatiale des actions : un gain d'argent ou un déplacement incompatible avec le temps écoulé depuis la dernière action légitime trahit presque toujours un event déclenché hors du jeu normal, à réinitialiser côté serveur plutôt qu'à accepter tel quel.
Cette hygiène de script ne remplace pas un anti-cheat applicatif dédié sur un serveur RP avec une communauté active (voir notre guide anti-cheat), mais aucun anti-cheat, aussi complet soit-il, ne compense un script serveur qui fait confiance par défaut à ce que le client lui envoie.
Vecteurs d'attaque FiveM et défense associée
| Vecteur | Ce qu'il exploite | Défense |
|---|---|---|
Event spoofing (TriggerServerEvent falsifié) |
Un handler serveur qui fait confiance à une valeur reçue du client (prix, montant, item) | Revalider chaque paramètre côté serveur, ne jamais accepter un montant transmis tel quel |
| Menu injecté (exécuteur Lua) | Accès direct au processus client pour lire l'état du jeu et déclencher des events à volonté | Protections natives CNL de FXServer, complétées par un anti-cheat applicatif dédié |
| UDP flood volumétrique (protocole ENet) | Sature la liaison réseau avant même d'atteindre le processus FXServer | Scrubbing réseau en amont chez l'hébergeur, jamais un pare-feu logiciel posé sur le serveur lui-même |
| Accès admin compromis (txAdmin ou ACE mal cloisonnés) | Compte partagé ou permission ACE accordée trop largement à un groupe | Comptes nominatifs, permissions ACE par identifiant individuel, jamais de compte admin partagé |
| Spam applicatif (event valide, mais déclenché en boucle) | Un handler serveur légitime, appelé des centaines de fois par seconde par un exécuteur Lua | Rate-limiting par joueur et par event, en plus de la revalidation des valeurs |
Limiter la fréquence des events : le rate-limiting applicatif
La validation des valeurs (section précédente) ne suffit pas si un event peut être déclenché sans limite de fréquence. Un exécuteur Lua peut appeler TriggerServerEvent des centaines de fois par seconde sur un event pourtant parfaitement validé côté serveur : chaque appel pris isolément reste légitime, mais leur accumulation sature le thread principal du serveur ou multiplie les écritures en base au point de provoquer des lags généralisés, voire de faire planter la resource visée. C'est un event spam, différent de l'event spoofing vu plus haut : le tricheur ne cherche pas à falsifier une valeur, il cherche à épuiser les ressources du serveur par la seule répétition.
La parade, documentée par plusieurs ressources de rate-limiting publiées sur le forum communautaire Cfx.re, consiste à limiter, event par event, le nombre d'appels acceptés par joueur sur une fenêtre de temps donnée : un compteur simple par identifiant de joueur, remis à zéro périodiquement, qui ignore ou déconnecte un joueur qui dépasse un seuil cohérent avec l'usage normal de cet event précis. Un achat en boutique n'a aucune raison légitime d'être déclenché cinquante fois par seconde ; un event de déplacement, en revanche, tolère une fréquence bien plus élevée. Le seuil se choisit donc event par event, jamais de façon uniforme sur l'ensemble du script.
Permissions ACE et gestion des comptes dans txAdmin
FXServer distingue les rôles via son système de permissions ACE (Access Control Entries) : un principal (un identifiant de joueur ou un groupe) reçoit des droits sur des commandes ou des ressources précises. La bonne pratique consiste à créer un groupe dédié plutôt que d'accorder des droits nominativement à chaque personne :
add_ace group.admin command allow
add_principal identifier.discord:123456789012345678 group.adminEn cas de doute sur un membre du staff, on retire simplement son add_principal du groupe : les autres comptes admin ne sont jamais impactés, contrairement à un mot de passe partagé qu'il faudrait changer pour tout le monde.
Côté txAdmin, le panel de gestion intégré à tout serveur FiveM va plus loin qu'un simple accès : chaque bannissement peut être rattaché simultanément à plusieurs identifiants du joueur (licence FiveM, Steam, Discord, adresse IP), ce qui évite qu'un tricheur banni ne revienne juste en changeant de pseudo. La liste blanche (whitelist) peut se limiter aux membres d'un rôle Discord précis, à une licence FiveM approuvée manuellement, ou aux seuls comptes déjà administrateurs, selon le niveau de fermeture souhaité pour la communauté. Ces réglages vivent dans le fichier de données local de txAdmin, pas dans une base MySQL séparée : à garder en tête si vous changez un jour d'hébergeur, notre guide de migration FiveM détaille ce que ça implique.
Steam, compte FiveM, licence : quel identifiant pour un bannissement qui tient
FXServer transmet plusieurs identifiants à chaque connexion, tous exploitables par txAdmin pour un bannissement, mais ils ne se valent pas pour empêcher un contournement :
- L'identifiant
fivem:(le compte Cfx.re du joueur) est le plus difficile à changer : il est lié au compte, pas à l'installation du jeu sur la machine. - L'identifiant
discord:n'est présent que si le joueur a Discord ouvert au moment de la connexion : signal fort quand il est disponible, absent sinon. - L'identifiant
steam:n'existe que pour un lancement via Steam : un joueur qui lance FiveM autrement n'en a pas. - L'identifiant
license:(un hash lié à Rockstar Online Services) peut changer après une réinstallation ou un changement de région : utile en complément, pas comme identifiant unique.
Depuis le 27 avril 2026, Cfx.re a définitivement retiré les identifiants xbl: et live: (Xbox/Microsoft) de la liste renvoyée par le serveur, pour des raisons de confidentialité des joueurs : un bannissement qui reposait encore sur ces identifiants ne matche plus personne, à vérifier si votre liste de bannis en dépendait. txAdmin combine automatiquement tous les identifiants disponibles au moment du bannissement, ce qui limite fortement le contournement sans jamais l'éliminer complètement : un joueur qui change à la fois de compte Cfx.re et de licence reste théoriquement possible à recroiser, mais devient nettement plus coûteux à faire qu'un simple changement de pseudo.
Que faire pendant une attaque en cours
Si le serveur devient injoignable ou anormalement lent sans raison apparente (pas de pic de joueurs, pas de mise à jour en cours), les réflexes utiles sont limités mais efficaces :
- Contactez le support de votre hébergeur immédiatement, plutôt que de redémarrer le serveur en boucle : un redémarrage ne fait rien contre un trafic qui sature déjà la bande passante et le réseau en amont, et masque le signal que l'équipe réseau doit voir pour agir.
- Ne tentez pas de « riposter » (contre-attaque, outils de traçage agressifs) : c'est inefficace contre du trafic distribué et anonymisé, et ça peut poser des problèmes légaux selon la juridiction.
- Conservez les horodatages de l'incident (heure de début, symptômes observés) : ça aide l'hébergeur à corréler l'attaque avec ses propres graphes réseau et à confirmer rapidement qu'il s'agit bien de ça plutôt que d'un souci côté serveur.
Lire les logs txAdmin après un incident
Une fois l'horodatage de l'incident noté, txAdmin conserve trois journaux distincts dans le même dossier de données local que celui qui contient déjà les bannissements et la whitelist (voir plus haut), avec une rotation quotidienne : admin.log pour les actions d'administration (bannissements, redémarrages, changements de réglages), server.log pour les événements en jeu (connexions, déconnexions, messages de chat, morts, commandes), et fxserver.log pour la sortie console brute du serveur.
Pour une attaque réseau, c'est server.log qui aide le plus : chaque source de joueur y est notée au format [mutex#id] nom, donc rechercher l'horodatage retenu permet de voir si un pic inhabituel de connexions ou de déconnexions coïncide avec le moment où le serveur est devenu injoignable. Ce constat reste à croiser avec ce que confirme le support réseau de l'hébergeur, seul capable de voir le trafic en amont (voir plus haut) ; fxserver.log complète en montrant si le processus lui-même a produit des erreurs ou redémarré pendant la même fenêtre.
Checklist sécurité réseau, complémentaire de la checklist anti-cheat
- Hébergement avec protection anti-DDoS incluse par défaut, pas en option.
- Réseau dimensionné (10 Gbit/s ou plus) pour absorber un pic sans que les joueurs légitimes le ressentent.
- Accès SSH par clé, jamais par mot de passe seul.
- txAdmin en comptes nominatifs, pas en mot de passe partagé, avec permissions ACE cloisonnées par identifiant.
- IP réelle du serveur non diffusée publiquement quand une alternative existe.
- Sauvegarde de la base de données récente et testée, indépendante de l'hébergeur.
- Aucun event serveur qui fait confiance à une valeur (montant, item, position) envoyée par le client sans la revalider.
- Rate-limiting appliqué sur les events sensibles (achat, inventaire, argent), pas seulement une revalidation des valeurs reçues.
- Liste des identifiants de bannissement à jour (les identifiants xbl:/live: sont retirés depuis avril 2026).
Pour la partie tricheurs et scripts malveillants, la checklist et les bonnes pratiques détaillées vivent dans notre guide anti-cheat. Si vous démarrez tout juste votre serveur, notre guide de mise en place applique ces réglages dès le premier jour plutôt qu'après un incident. Et si votre hébergeur actuel ne couvre ni l'un ni l'autre correctement, changer d'hébergeur FiveM explique comment migrer sans perdre votre configuration ni votre communauté.