Protéger un serveur FiveM des attaques DDoS

Un serveur roleplay FiveM qui disparaît chaque soir pendant quelques minutes a rarement un problème de matériel. La plupart du temps, une attaque est en cours, et précisément au moment où les joueurs sont les plus nombreux. Cet article montre d'abord ce que vous pouvez sécuriser vous-même sans frais supplémentaires, ensuite où ces mesures s'arrêtent techniquement, et pour finir ce qui doit alors se passer dans le réseau, en amont du serveur.

Toutes les indications se rapportent à un FXServer sous Debian 12, Debian 13, Ubuntu 22.04 LTS ou Ubuntu 24.04 LTS. Les commandes sont écrites pour root ; en tant qu'utilisateur normal, faites-les précéder de sudo.

Si l'attaque est en cours : ne modifiez rien à la configuration maintenant et ne redémarrez pas le serveur. Sauvegardez d'abord vos mesures (voir la section « Journaliser »), après l'attaque elles auront disparu.

Pourquoi les serveurs FiveM sont si souvent attaqués

Les projets FiveM réunissent plusieurs caractéristiques qui en font une cible commode. D'abord, un serveur RP publie son adresse de lui-même : l'entrée dans la liste des serveurs Cfx.re contient l'adresse IP et le port en clair, sans quoi les joueurs ne trouveraient jamais le serveur. Ensuite, les joueurs se connectent à des horaires fixes, et une panne à 20 heures est donc visible au maximum. Enfin, il existe une concurrence entre projets, des joueurs bannis et des conflits internes, et une attaque ne coûte à celui qui la lance ni compétence particulière ni argent notable.

S'y ajoute un point technique : le trafic de jeu passe par UDP. UDP ne prévoit aucun établissement de connexion que l'on pourrait exiger, et les adresses source se falsifient sans peine. Un attaquant n'a donc besoin ni de rejoindre votre serveur ni de s'adresser correctement à lui pour produire de la charge. Ce qu'est précisément une attaque DDoS, l'article Qu'est-ce qu'une attaque DDoS ? l'explique en détail.

Les ports dont il est réellement question

Par défaut, un FXServer s'attache à un seul port, et sur les deux protocoles. Dans le fichier server.cfg :

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

Ces deux lignes constituent toute la surface d'attaque du jeu lui-même :

• 30120 UDP porte le trafic de jeu en cours : données de position, synchronisation, transmission de la voix.
• 30120 TCP porte l'établissement des connexions et les points d'accès HTTP intégrés au FXServer : /info.json, /players.json et /dynamic.json.
• 40120 TCP est le réglage par défaut de l'interface web de txAdmin.
• 3306 TCP appartient à la base de données dont tout framework ESX ou QBCore a besoin.
• 22 TCP est votre accès SSH.

Sur ces cinq ports, deux exactement ont leur place sur le réseau ouvert. Les trois autres constituent l'erreur évitable la plus fréquente sur les serveurs FiveM.

Ce que vous pouvez faire vous-même avant de dépenser de l'argent

Cette section est la plus longue, et c'est volontaire. Un serveur proprement configuré encaisse par ses propres moyens les attaques petites et moyennes, quel que soit l'hébergeur chez qui il se trouve.

1. État des lieux : qu'est-ce qui écoute au juste ?

Avant d'écrire la moindre règle, regardez ce que votre serveur propose vers l'extérieur. Ne devinez pas, vérifiez :

ss -lntup

La colonne qui compte est celle de l'adresse locale. 0.0.0.0:30120 et [::]:30120 signifient « joignable depuis tout Internet », 127.0.0.1:3306 signifie « en local uniquement » et ne demande aucune règle de pare-feu. À côté du jeu, on y trouve souvent txAdmin, MariaDB, un serveur web et un service vocal oublié depuis longtemps. Le point de vue de l'attaquant, lui, s'obtient par un scan de ports depuis l'extérieur :

nmap -Pn -p- --min-rate 1000 ADRESSE.IP.DE.VOTRE.SERVEUR

2. Ne laisser ouvert que ce dont le jeu a réellement besoin

Pour FiveM, deux autorisations vers l'extérieur suffisent, tout le reste est restreint ou n'est tout simplement jamais publié. Avec UFW, cela donne ceci, et exactement dans cet ordre, pour ne pas vous bloquer vous-même :

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'FiveM'
ufw allow 30120/udp comment 'FiveM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Remplacez 203.0.113.10 par votre propre adresse. Sur un raccordement à adresse variable, c'est peu pratique, et la meilleure approche figure plus bas. Le guide complet, voie de secours comprise, se trouve dans Configurer le pare-feu UFW sans se bloquer l'accès SSH.

La base de données n'a en aucun cas sa place sur le réseau ouvert. Vérifiez dans /etc/mysql/mariadb.conf.d/50-server.cnf que la ligne suivante est bien présente :

bind-address = 127.0.0.1

3. Sécuriser le port de requête et les points d'accès HTTP

Sur la partie TCP du port 30120, le FXServer répond à des requêtes HTTP sans que personne ait besoin de lancer le jeu. Regardez ce qu'il y livre :

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600

/players.json énumère les joueurs connectés avec leurs identifiants. C'est pratique pour les pages de statut et les bots Discord, mais c'est aussi une invitation : ce point d'accès peut être interrogé autant de fois que l'on veut, chaque requête coûte du travail à votre serveur, et son contenu indique à un attaquant le moment où une attaque est rentable. Deux contre-mesures ne coûtent rien. Premièrement, les adresses de connexion des joueurs n'ont rien à faire dans la réponse, et une seule ligne dans server.cfg y suffit :

sv_endpointPrivacy true

Deuxièmement : si votre bot Discord ou votre site affiche le nombre de joueurs, n'interrogez pas le point d'accès depuis le navigateur du visiteur, mais mettez le résultat en cache à intervalle fixe. Une page de statut très fréquentée produit alors une requête par intervalle au lieu d'une par visiteur.

4. Ne pas exposer txAdmin sur le réseau ouvert

Le port 40120 est une interface web avec un accès complet à votre serveur. Sans adresse IP fixe pour une règle d'autorisation, laissez ce port fermé vers l'extérieur et atteignez-le par un tunnel SSH, puis ouvrez localement http://127.0.0.1:40120 :

ssh -N -L 40120:127.0.0.1:40120 root@ADRESSE.IP.DE.VOTRE.SERVEUR

5. Limiter le nombre de connexions et le taux de paquets

Contre les petites attaques et les bots mal écrits, un plafond par adresse source fait le travail :

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 12 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name fivem_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

La première règle rejette les nouvelles connexions TCP dès qu'une adresse en a plus de douze ouvertes en même temps ; la seconde rejette les paquets UDP à partir de 600 paquets par seconde en continu depuis la même source. Ces deux chiffres sont des valeurs de départ, pas des vérités : un serveur RP plein produit nettement plus de paquets qu'un serveur vide, et un réglage trop serré éjecte vos propres joueurs. Mesurez d'abord pendant une semaine en fonctionnement normal.

Deux remarques à ce sujet. Les règles iptables seules disparaissent après un redémarrage ; sous Debian et Ubuntu, on les enregistre ainsi :

apt-get install -y iptables-persistent
netfilter-persistent save

Et sous UFW, de telles règles ont leur place dans /etc/ufw/before.rules, faute de quoi elles disparaissent au prochain ufw reload. Un goulot d'étranglement souvent négligé est par ailleurs le suivi de connexions du noyau : lorsqu'il est saturé, le serveur rejette aussi les paquets légitimes, et le journal indique « nf_conntrack: table full ». La valeur actuelle et la limite s'affichent avec :

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. L'entrée dans la liste des serveurs

Ici, mieux vaut l'honnêteté que la pensée magique : votre adresse IP ne peut pas rester secrète. Tout joueur qui s'est connecté une fois la connaît, et l'entrée dans la liste la publie de toute façon. Si vous n'avez pas besoin de cette entrée publique, parce que le projet fonctionne uniquement par Discord et par connexion directe, vous pouvez la désactiver avec sv_master1 "". Cela vous coûte toutefois toute visibilité auprès des nouveaux joueurs et ne protège que contre l'attaquant le plus paresseux.

Deux habitudes sont plus efficaces. Ne publiez jamais l'adresse IP brute vous-même, donc ni dans le canal Discord ni sur le site du projet. Et faites passer vos joueurs par un nom d'hôte, afin de pouvoir changer d'adresse le jour venu sans casser toutes les références. Le grand classique reste ici les anciens enregistrements DNS : un enregistrement A oublié qui pointe encore vers l'adresse précédente rend tout changement inopérant.

7. Liste blanche et contrôle à la connexion

Une liste blanche (whitelist) agit contre tout ce qui emprunte le chemin de connexion normal : trolls, clients de triche, botnets faits de comptes jetables. Elle se met en place côté serveur dans l'événement playerConnecting, où vous suspendez la connexion avec les fonctions de deferral, vérifiez l'identifiant et n'autorisez l'entrée qu'ensuite. S'y ajoutent un contrôle de compte strict, une limite de joueurs réaliste et un ScriptHook désactivé :

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 48
sv_scriptHookAllowed 0

Ne définissez un mot de passe RCON que si vous avez besoin de RCON, car cet accès se trouve sur le même port ouvert. Et une chose doit être claire : une liste blanche protège la logique de votre jeu, pas votre raccordement. Un attaquant qui inonde votre serveur ne cherche pas du tout à s'y connecter. Ses paquets sont refusés, mais ils sont malgré tout arrivés, et c'est précisément là que se situe le problème.

8. Vérifier les événements réseau côté serveur

Beaucoup de pannes signalées comme des attaques DDoS remontent à un seul script. Les ressources FiveM communiquent par des événements réseau, et un événement que le serveur exécute sans le vérifier est une porte ouverte : celui qui envoie depuis le client un TriggerServerEvent avec des valeurs arbitraires peut créer de l'argent, faire apparaître des véhicules ou déclencher des requêtes en base de données en boucle jusqu'à ce que le serveur s'arrête.

Trois règles interceptent l'essentiel de ces abus. N'enregistrez avec RegisterNetEvent que les événements censés venir réellement du client. Ne vous fiez jamais aux valeurs transmises par le client, mais déterminez le joueur côté serveur à partir de source. Et limitez le nombre de fois qu'un joueur peut déclencher le même événement, en particulier pour tout ce qui interroge la base de données. Si le serveur saccade alors que le raccordement est calme, resmon 1 dans la console client affiche le temps de calcul par ressource, et le coupable se trouve la plupart du temps tout en haut.

9. Journaliser, pour disposer de données le jour venu

L'étape la plus importante est celle que presque personne ne franchit à l'avance : constituer une base de comparaison pendant que tout fonctionne normalement. Sans valeur de référence, vous ne pourrez pas dire après un incident si 40 000 paquets par seconde représentaient beaucoup, ou simplement un mardi soir. Avec apt-get install -y vnstat sysstat, la mesure tourne en permanence. Pendant un incident, quatre commandes suffisent : le taux de paquets par seconde, le taux de rejet de l'interface, les messages du noyau et un court échantillon du trafic.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -c 200 -q

Pour tcpdump, une règle : limitez toujours avec -c, car une capture à pleine charge alourdit encore un serveur déjà surchargé. La façon d'interpréter ces valeurs est expliquée dans Détecter une attaque DDoS.

Où ces mesures s'arrêtent

Vient maintenant la partie qu'aucun fichier de configuration ne peut résoudre. Toutes les mesures précédentes s'exécutent sur votre serveur, donc au bout du raccordement. Une règle de pare-feu décide du sort d'un paquet qui a déjà parcouru le câble. Vous pouvez le rejeter, mais vous ne pouvez pas faire qu'il n'ait jamais été envoyé.

Faites le calcul une fois. Un serveur de jeu classique est raccordé à 1 Gbit/s, soit 125 mégaoctets par seconde, et le raccordement est saturé dès que quelqu'un envoie davantage. Les attaques contre les projets FiveM se situent d'ordinaire entre 5 et 50 Gbit/s, soit cinq à cinquante fois votre raccordement. La qualité de votre règle iptables placée derrière n'a alors plus aucune importance, car les paquets de vos joueurs ne passent déjà plus en amont.

La deuxième grandeur est le taux de paquets, et il frappe souvent plus tôt que la bande passante. Avec de petits paquets de 64 octets, environ 1,49 million de paquets par seconde tiennent dans un raccordement à 1 Gbit/s. Selon le CPU et la carte réseau, un noyau de serveur normal en traite quelques centaines de milliers avant de commencer à rejeter. Une attaque qui ne remplit même pas un tiers de votre raccordement peut donc quand même paralyser votre serveur, parce que le temps de calcul part dans le rejet des paquets. Les exploitants vivent cela comme ceci : « la charge n'était même pas élevée, et pourtant tout avait disparu ».

Pour situer les ordres de grandeur qui se produisent réellement : sur des serveurs KernelHost, nous avons notamment filtré une attaque de plus de 473,4 Gbit/s à plus de 41,5 millions de paquets par seconde contre un serveur vocal, ainsi qu'un UDP flood de plus de 112,2 Gbit/s contre un serveur de jeu. Il n'existe aucun réglage local pour cela. Les attaques volumétriques doivent s'arrêter dans le réseau, en amont du serveur.

Ce que KernelHost oppose à cela

La protection permanente incluse avec chaque serveur

La protection DDoS de KernelHost repose sur deux niveaux et reste active en permanence, sans que vous ayez quoi que ce soit à activer, à commander ou à configurer :

• Niveau 1 : 17 Tbps de capacité de mitigation dans le réseau de scrubbing mondial. Les attaques volumétriques sont nettoyées au plus près de leur source, avant d'atteindre le centre de données.
• Niveau 2 : filtrage Arbor en temps réel à 3,2 Tbps à Francfort-sur-le-Main. Juste devant le serveur, les schémas propres à chaque protocole sont identifiés et rejetés, paquet par paquet.

Deux caractéristiques sont décisives. La protection fonctionne en permanence et n'a pas besoin de réagir d'abord à une attaque : il n'y a donc pas de premières minutes pendant lesquelles le serveur est injoignable. Et aucun null-routing n'est utilisé : votre adresse IP reste dans le réseau, seuls les paquets malveillants sont rejetés. Retirer l'adresse IP du réseau aboutit, de votre point de vue, exactement au même résultat que l'attaque elle-même. Le centre de données est maincubes à Francfort-sur-le-Main, en Allemagne. Les jeux et protocoles couverts sont listés dans Protection DDoS des serveurs de jeu en temps réel.

Advanced DDoS Protection pour les projets attaqués en continu

Certains projets ne sont pas attaqués de temps à autre, mais de façon ciblée et pendant des semaines. Pour ces cas, il existe l'Advanced DDoS Protection à partir de 50,00 € par mois, en PrePaid et sans durée minimale. La différence ne tient pas à une capacité supérieure, mais au contrôle :

• Une IP protégée dédiée issue du cœur de réseau de Francfort, vers laquelle votre serveur est basculé au sein de notre propre réseau. Aucune modification n'est nécessaire de votre côté.
• Des règles de protection par port et par protocole, que vous gérez vous-même dans l'espace client : vous définissez ce qui est autorisé sur 30120 UDP et ce qui l'est sur 30120 TCP, sans avoir à ouvrir de ticket.
• Les changements s'appliquent en temps réel, vous pouvez donc affiner les réglages pendant une attaque en cours.
• Un profil de protection adapté au jeu concerné. Pour FiveM, un profil prêt à l'emploi existe, tout comme pour les applications modifiées ou maison sur n'importe quel port TCP ou UDP.

Les deux niveaux comparés

Pour la plupart des projets FiveM, la protection permanente incluse suffit, à condition que la configuration du serveur soit propre. L'Advanced DDoS Protection est la réponse au cas où quelqu'un en fait une affaire personnelle.

Erreurs fréquentes et solutions

« J'ai changé d'adresse IP et deux heures plus tard j'étais de nouveau hors ligne » : l'attaquant a obtenu la nouvelle adresse par la même source que l'ancienne, le plus souvent l'entrée dans la liste des serveurs, un bot Discord ou un ancien enregistrement DNS. Un changement d'adresse fait gagner du temps, ce n'est pas une solution.

« Mes règles iptables ne s'appliquent pas » : trois causes sont fréquentes. Les règles se trouvent derrière les chaînes UFW et ne sont jamais atteintes ; elles ont disparu au dernier redémarrage (netfilter-persistent save ou une entrée dans /etc/ufw/before.rules y remédient) ; ou bien l'attaque est volumétrique et la règle travaille correctement sur un raccordement déjà saturé. Vérifiez avec iptables -L INPUT -n -v si les compteurs de correspondances augmentent. S'ils restent à zéro, c'est que la règle n'est jamais atteinte.

« Le serveur tourne, mais tous les joueurs subissent des effets d'élastique » : c'est plus souvent un script qu'une attaque. Regardez d'abord avec resmon 1 si une ressource dévore le temps de calcul. Si sar -n DEV 1 10 ne montre rien d'anormal, ce n'était pas une attaque DDoS.

« txAdmin affiche des centaines de tentatives de connexion échouées » : il s'agit d'un flood de connexions, qui touche la logique du jeu et non le raccordement. La liste blanche, le contrôle de compte et le plafond de connexions par adresse source y répondent.

« Mon hébergeur précédent a bloqué mon adresse IP » : c'est du null-routing. L'hébergeur protège ainsi son propre réseau ; pour vous, le résultat est identique à une attaque réussie, et le plus souvent pendant encore des heures. En cas de doute, demandez si le trafic est filtré ou si l'adresse est simplement retirée du réseau. La réponse pèse davantage sur votre disponibilité que n'importe quelle fiche technique.

« Dans tcpdump, je ne vois rien d'anormal » : si le trafic est déjà filtré dans le réseau en amont, rien n'arrive sur le serveur, et c'est bien ce à quoi il faut s'attendre. C'est le cas normal quand le filtrage fonctionne. À l'inverse : si le raccordement est saturé, il se peut que même la session SSH avec laquelle vous vouliez mesurer ne vous parvienne plus. Utilisez alors la console VNC dans l'espace client, qui fonctionne indépendamment du réseau du système invité.

En résumé

Fermez tout sauf 30120 TCP et UDP, tenez txAdmin et la base de données à l'écart du réseau ouvert, limitez les connexions et le taux de paquets par adresse source, tenez une liste blanche et vérifiez les événements réseau côté serveur. Vous êtes ainsi armé contre tout ce qui n'exige pas de bande passante notable. Au-delà, seul le réseau en amont du serveur est déterminant.

Si votre projet est déjà hébergé chez KernelHost, le filtrage est actif sans que vous ayez quoi que ce soit à faire. Si vous constatez malgré tout des anomalies, ouvrez un ticket de support afin que les règles de filtrage soient ajustées pour votre adresse IP. Pendant une attaque en cours, vous pouvez également nous joindre via le chat d'urgence WhatsApp au +43 650 8209883.