Protéger un serveur RedM des attaques DDoS

Un serveur RedM qui disparaît en pleine session le soir et réapparaît dix minutes plus tard a rarement un problème de matériel. La plupart du temps, une attaque est en cours sur le port 30120, et elle se produit précisément au moment où le plus grand nombre de joueurs sont connectés. Cet article montre comment protéger un serveur RedM des attaques DDoS : d'abord ce que vous pouvez sécuriser vous-même sans frais supplémentaires, ensuite la limite physique de ces mesures, et pour finir ce qui doit se passer dans le réseau, en amont du serveur, lorsque l'attaque est plus grande que votre raccordement.

Toutes les indications se rapportent à un FXServer avec gamename rdr3 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. RedM est la modification de Red Dead Redemption 2 signée Cfx.re et le projet frère de FiveM. Les deux tournent sur le même programme serveur, ce qui rend une partie de la technique réseau réellement identique. Là où c'est le cas, cela tient ici en une phrase, et la partie détaillée se trouve dans l'article Protéger un serveur FiveM des attaques DDoS. Tout le reste de ce texte est propre à RedM.

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

Pourquoi les serveurs RedM sont si souvent la cible d'attaques DDoS

Un serveur RedM est une cible plus intéressante que son nombre de joueurs ne le laisse supposer. La raison tient à la taille de la scène, pas à sa petitesse. En septembre 2026, les trackers publics de listes de serveurs comptaient environ 2 000 serveurs RedM actifs pour quelque 12 400 joueurs simultanés, contre environ 39 000 serveurs FiveM pour quelque 325 000 joueurs. Celui qui met hors service un serveur sur 2 000 retire du réseau une part bien plus importante de la scène entière que celui qui frappe un serveur sur 39 000. Pour un attaquant qui veut nuire à un projet concurrent, le levier est donc incomparablement plus grand.

S'y ajoute la structure des communautés. Le roleplay RedM vit de sessions fixes à des horaires fixes, souvent avec inscription et validation du personnage. Une panne à 20 heures ne touche pas des joueurs quelconques, mais exactement ceux qui se sont inscrits pour cette soirée. Beaucoup de projets fonctionnent en outre comme un loisir au budget serré, reposent sur un unique serveur bon marché et n'ont pas de seconde instance vers laquelle basculer. Des cas publiquement documentés dans la scène RedM décrivent des séries d'attaques étalées sur des mois, à un rythme quasi quotidien, qui frappaient en même temps le serveur de jeu et le serveur vocal séparé.

Techniquement, s'y ajoute le fait que le trafic de jeu passe par UDP. UDP est un protocole de transport sans connexion : il n'existe aucun établissement de connexion que le serveur pourrait exiger, et les adresses source se falsifient. Un attaquant n'a donc besoin ni de rejoindre votre serveur RedM ni de s'adresser correctement à lui pour produire de la charge. Ce qu'est précisément une attaque DDoS et comment elle est construite, 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 serveur RedM s'attache à un seul port, et sur les deux protocoles. Dans le fichier server.cfg, cela s'écrit ainsi :

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

La ligne set gamename rdr3 est la seule qui distingue un serveur RedM d'un serveur FiveM. Si elle manque, le même FXServer s'annonce comme un serveur GTA V et un client RedM ne s'y connecte pas. RedM n'a ni port de requête dédié ni port RCON dédié : la requête serveur, l'établissement de connexion, le trafic de jeu et RCON passent tous par les deux mêmes entrées sur 30120. Voici les chiffres bruts :

Sur les quatre ports cités, deux exactement ont leur place sur le réseau ouvert : 30120 TCP et 30120 UDP. Le port 40120 et le port 3306 n'y ont rien à faire, et SSH sur le port 22 devrait être restreint à vos propres adresses. C'est l'erreur évitable la plus fréquente sur les serveurs RedM, parce que beaucoup de projets démarrent avec une recette txAdmin toute prête et ne vérifient jamais ensuite ce que le serveur propose vers l'extérieur.

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 RedM proprement configuré encaisse par ses propres moyens les attaques petites et moyennes, quel que soit l'hébergeur chez qui il se trouve. L'ordre est choisi à dessein : vous mesurez d'abord, vous fermez ensuite, et vous ne limitez qu'après.

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 FXServer, on trouve régulièrement sur un serveur RedM txAdmin sur 40120, MariaDB sur 3306, un serveur web pour la page du projet et parfois un service vocal. 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 ouverts que 30120 TCP et UDP

Pour RedM, 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 'RedM'
ufw allow 30120/udp comment 'RedM'
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 dans la section suivante consacrée à txAdmin. 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. VORP, RSGCore et RedEM:RP ont tous besoin d'une MariaDB ou d'une MySQL, le plus souvent via oxmysql avec une chaîne de connexion dans server.cfg. Cette connexion est locale, le port n'a donc pas à être joignable depuis l'extérieur. 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 les points d'accès HTTP du FXServer

Sur la partie TCP du port 30120, le FXServer répond à des requêtes HTTP sans que personne ait besoin de lancer Red Dead Redemption 2. Regardez ce que votre serveur RedM 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
curl -s http://127.0.0.1:30120/dynamic.json

/players.json énumère les joueurs connectés avec leurs identifiants, /info.json la configuration du serveur et les ressources chargées, /dynamic.json le taux d'occupation actuel. Ces trois points d'accès sont précisément la voie d'attaque de couche 7 documentée contre les serveurs FiveM et RedM : ils sont joignables sans authentification, ils peuvent être interrogés autant de fois que l'on veut, chaque requête coûte du travail à votre serveur, et leur contenu indique à un attaquant le moment où une attaque est rentable. Deux contre-mesures ne coûtent rien. Premièrement, les points de connexion des joueurs n'ont rien à faire dans la réponse, et une seule ligne dans server.cfg y suffit :

sv_endpointPrivacy true

Ce réglage masque les adresses IP de vos joueurs dans les sorties publiques du serveur. Deuxièmement : si votre bot Discord ou la page de votre projet affiche le nombre de joueurs, n'interrogez pas le point d'accès depuis le 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. Dans une scène aussi réduite que RedM, cela pèse doublement, parce qu'un seul bot d'état de serveur peut être intégré simultanément dans plusieurs serveurs Discord.

4. Retirer txAdmin sur le port 40120 du réseau ouvert

txAdmin est l'interface d'administration incluse dans la build du FXServer pour FiveM et RedM, et elle écoute par défaut sur 40120 TCP. Derrière se trouve l'accès complet à votre serveur : redémarrages, liste de bannissement, base de données des joueurs, gestion des ressources. Sans adresse IP fixe pour une règle d'autorisation, laissez ce port fermé vers l'extérieur et atteignez-le par une redirection de port locale avec SSH, puis ouvrez dans le navigateur http://127.0.0.1:40120 :

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

Qui laisse txAdmin exposé publiquement récolte deux problèmes à la fois : un formulaire de connexion contre lequel on peut lancer des floods d'authentification, et un service qui fournit du travail à chaque requête alors qu'il n'a rien à voir avec le jeu. Dans le doute, attachez txAdmin directement en local, en ne le faisant écouter que sur 127.0.0.1.

5. Limiter le nombre de connexions et le taux de paquets par adresse source

Contre les petites attaques et les bots mal écrits, un plafond par adresse source fait le travail. Les deux règles valent pour 30120, donc pour les deux protocoles du jeu :

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

La première règle rejette les nouvelles connexions TCP dès qu'une adresse en a plus de huit ouvertes en même temps, la seconde rejette les paquets UDP à partir de 500 paquets par seconde en continu depuis la même source. Les valeurs de départ sont ici un peu plus basses que sur un serveur FiveM, parce qu'un serveur RedM à 32 slots produit tout simplement moins de connexions légitimes par adresse. Mais des valeurs de départ ne sont pas des vérités : une soirée RP bien remplie 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. Protéger les 32 slots contre les floods de connexions

Sans OneSync, un serveur RedM a exactement 32 slots. Avec OneSync, ils sont 48, et au-delà il faut un abonnement Element Club pour aller jusqu'à 1 024 places. Ce chiffre relève de la sécurité, car il constitue la limite qu'un attaquant doit remplir : celui qui maintient 32 tentatives de connexion ouvertes en même temps occupe entièrement un serveur standard, sans qu'un seul joueur arrive effectivement en jeu. Sur un projet FiveM à 128 places, le même seuil est quatre fois plus haut.

Un avantage propre à RedM compense en partie : RedM exige une copie authentique de Red Dead Redemption 2, qu'elle ait été achetée sur Steam, Epic Games ou chez Rockstar, ainsi que le launcher Rockstar. Un flood de connexions avec des milliers de comptes jetables, comme il est courant sur les jeux gratuits, coûte donc ici de l'argent réel. Les attaques se déplacent de ce fait vers la couche réseau et vers les points d'accès HTTP, où aucune copie du jeu n'est nécessaire.

Contre tout ce qui emprunte le chemin de connexion normal, une liste blanche (whitelist) agit malgré tout. 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 et une limite de joueurs réaliste :

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance est une valeur de 1 à 5 qui indique à quel point l'identifiant d'un joueur peut varier chez un fournisseur ; 1 est le réglage le plus strict. sv_authMinTrust va également de 1 à 5 et décrit à quel point une identité falsifiée doit être improbable ; 5 est ici la valeur la plus stricte. Ne définissez un mot de passe RCON que si vous avez réellement besoin de RCON, car cet accès se trouve sur le même port ouvert 30120. 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.

7. Évaluer correctement l'entrée dans la liste des serveurs RedM

Ici, mieux vaut l'honnêteté que la pensée magique : votre adresse IP ne peut pas rester secrète. RedM utilise la même infrastructure de serveurs maîtres Cfx.re que FiveM, et l'entrée de la liste contient dans le champ connectEndPoints le point de connexion en clair. Via l'interface publique accessible sous servers-frontend.fivem.net, on peut retrouver l'adresse associée à n'importe quel code cfx.re, pour RedM comme pour FiveM. Si vous n'avez pas du tout besoin de cette entrée publique, parce que le projet fonctionne uniquement par Discord et par connexion directe, vous pouvez déclarer le serveur comme privé avec sv_master1 "" : on ne peut alors plus le rejoindre par la liste des serveurs. Cela vous coûte toutefois toute visibilité auprès des nouveaux joueurs, et dans une scène de 2 000 serveurs, la visibilité est le véritable moteur de croissance.

Deux habitudes sont plus efficaces. Ne publiez jamais l'adresse IP brute vous-même, donc ni dans le canal Discord ni sur la page 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.

8. Vérifier côté serveur les événements VORP, RSGCore et RedEM

Beaucoup de pannes signalées comme des attaques DDoS remontent à un seul script. Les ressources RedM 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 des dollars, faire apparaître des chevaux ou déclencher des requêtes en base de données en boucle jusqu'à ce que le serveur s'arrête. Cela vaut de la même manière pour les trois frameworks répandus : VORP Core, qui dispose depuis 2020 de la plus grande base de scripts, RSGCore et le plus ancien RedEM:RP.

Les ressources d'inventaire et de personnage sont particulièrement exposées, parce qu'elles écrivent en base de données à chaque appel. Une boucle d'événements qui enregistre dix fois par seconde l'état d'un inventaire pèse davantage sur un serveur RedM que bien des floods de paquets, et elle vient de l'intérieur, là où aucun pare-feu n'agit.

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. Collecter des mesures avant d'en avoir besoin

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 bien fréquenté. 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é. Regardez en outre si la charge porte sur la partie UDP ou sur la partie TCP de 30120. Une charge UDP indique un flood de paquets contre le trafic de jeu, une charge TCP un flood contre les points d'accès HTTP, et les deux appellent des contre-mesures différentes. La façon d'interpréter ces valeurs est expliquée dans Détecter une attaque DDoS.

Là où ces mesures s'arrêtent

Vient maintenant la partie qu'aucune server.cfg 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 roleplay 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 RedM, 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 ». Ce sont exactement ces pics de lag sans charge serveur visible qui forment le tableau typique d'une attaque par taux de paquets.

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 qui diffère entre RedM et FiveM

La réponse courte : la technique réseau est identique, le contexte ne l'est pas. Les deux tournent sur le même FXServer, les deux utilisent 30120 TCP et UDP, les deux se gèrent par txAdmin sur 40120. Tout ce que vous lisez plus haut sur les ports, les débits et les points d'accès vaut pour les deux. Ce sont les conditions générales qui diffèrent, et ce sont précisément elles qui déterminent la vitesse à laquelle une attaque produit son effet :

Trois points de ce tableau sont déterminants pour la défense. Premièrement, la scène plus réduite rend chaque serveur RedM plus précieux comme cible, parce qu'une panne touche une part plus grande des joueurs. Deuxièmement, la limite standard de 32 slots abaisse le seuil à partir duquel un flood de connexions ferme le serveur. Et troisièmement, on trouve sur le réseau moins de recettes de protection toutes faites pour RedM que pour FiveM, raison pour laquelle beaucoup de projets tournent avec une configuration standard inchangée. La défense est la même, l'état de départ est moins bon.

Ce que KernelHost oppose à cela

La protection permanente incluse sur 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 RedM 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'attaquant. Le site du filtrage est Francfort-sur-le-Main. 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 séparément ce qui est autorisé sur 30120 UDP et ce qui l'est sur 30120 TCP, sans avoir à ouvrir de ticket. Chez RedM, cette séparation est particulièrement utile, parce que le trafic de jeu et les points d'accès HTTP partagent le même numéro de port tout en ayant des schémas totalement différents.
• 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é à l'application. Pour les serveurs Cfx.re sur 30120, un profil adapté existe, tout comme pour les applications modifiées ou maison sur n'importe quel port TCP ou UDP.

Les deux valent pour des serveurs hébergés chez KernelHost. Si votre projet RedM tourne actuellement ailleurs et se fait régulièrement sortir du réseau, la recommandation est le déménagement, pas un produit supplémentaire.

Les deux niveaux comparés

Pour la plupart des projets RedM, 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

« Mon serveur n'apparaît pas dans la liste des serveurs RedM, je soupçonne une attaque » : vérifiez d'abord la configuration. Si set gamename rdr3 manque, le FXServer s'annonce comme serveur GTA V et n'apparaît pas dans la liste RedM. Si la clé de licence issue de portal.cfx.re manque ou ne correspond pas, l'entrée ne se crée pas non plus. Une attaque a une autre allure : l'entrée reste en place, c'est la connexion qui échoue.

« Des centaines de joueurs reçoivent une erreur en rejoignant, cela ressemble à un flood » : le plus souvent, c'est un problème de build du jeu. Si sv_enforceGameBuild ne correspond pas à ce qu'attendent vos ressources, le client signale « server specified an invalid game enforcement ». Définissez la valeur exigée par votre framework, habituellement 1436 ou 1491, et redémarrez complètement le serveur.

« 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, et examinez les ressources d'inventaire et de personnage de votre framework. 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 par sv_authMinTrust 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é

• Un serveur RedM a besoin d'exactement deux ports ouverts : 30120 TCP et 30120 UDP, définis par endpoint_add_tcp et endpoint_add_udp. Il n'existe ni port de requête dédié ni port RCON dédié.
• txAdmin sur 40120 TCP et la base de données sur 3306 TCP n'ont pas leur place sur le réseau ouvert, mais respectivement sur votre propre adresse et sur 127.0.0.1.
• sv_endpointPrivacy true retire les adresses IP des joueurs des sorties publiques, et un état de serveur mis en cache soulage /players.json, la voie d'attaque de couche 7 documentée contre les serveurs Cfx.re.
• Un serveur RedM a 32 slots sans OneSync, 48 avec OneSync et jusqu'à 1 024 avec Element Club. Plus le nombre de slots est faible, moins un flood de connexions coûte cher, et plus la liste blanche et le contrôle de compte comptent.
• RedM et FiveM tournent sur le même FXServer, distingués par la seule ligne set gamename rdr3. La défense réseau est donc identique, le contexte ne l'est pas : environ 2 000 serveurs RedM face à environ 39 000 serveurs FiveM font de chaque projet RedM une cible de plus grande valeur.
• Les règles de pare-feu locales s'arrêtent là où le raccordement est saturé : 1 Gbit/s représente 125 mégaoctets par seconde, et avec des paquets de 64 octets, environ 1,49 million de paquets par seconde y tiennent. Tout ce qui dépasse doit s'arrêter dans le réseau, en amont du serveur.
• Chez KernelHost, la protection permanente à deux niveaux est comprise dans chaque pack serveur, active dès la mise en service et sans null-routing. Qui veut piloter le filtrage lui-même obtient avec l'Advanced DDoS Protection, à partir de 50,00 € par mois, une IP protégée dédiée et ses propres règles par port et par protocole.

Si votre projet RedM 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.