Protéger un serveur RAGE MP ou alt:V des attaques DDoS

Un serveur multijoueur GTA est une cible commode pour un attaquant : il tient à une seule adresse IP, son port figure dans une liste de serveurs publique, et la moindre interruption est visible par tous les joueurs en même temps. Cet article montre d'abord ce que vous pouvez réellement obtenir sur votre propre serveur, puis, tout aussi clairement, où ces possibilités s'arrêtent.

Si vous n'êtes pas encore certain qu'une attaque est bien en cours, commencez par le mesurer : Détecter une attaque DDoS décrit le diagnostic étape par étape. Les bases techniques sont expliquées dans Qu'est-ce qu'une attaque DDoS.

Pourquoi RAGE MP et alt:V sont si souvent touchés

La scène roleplay autour de GTA V est petite, publique et très disputée. Un serveur vit de ses joueurs réguliers, et ceux-ci basculent vite sur un autre Discord dès que les interruptions se prolongent. C'est ce qui rend les attaques attractives : il n'est pas nécessaire de tenir des heures, quelques minutes aux heures de pointe suffisent, le soir de l'ouverture ou pendant un wipe annoncé.

S'y ajoute que personne n'a besoin de chercher longtemps. Les deux plateformes déclarent votre serveur, si vous le souhaitez, à une liste de serveurs publique : RAGE MP par announce dans le fichier conf.json, alt:V par announce et token dans le fichier server.toml. Y figurer revient à publier votre adresse IP et votre port. Un serveur fraîchement inscrit reçoit donc souvent ses premières tentatives de connexion automatisées dès la première heure, bien avant l'arrivée du premier vrai joueur.

La troisième raison est d'ordre technique : le trafic de jeu passe par UDP. UDP ne prévoit aucun établissement de connexion qu'un expéditeur devrait attendre, l'adresse source se falsifie donc sans peine. Celui qui connaît votre port peut le bombarder sans jamais recevoir de réponse et sans montrer sa propre adresse.

Les ports dont il est question

Avant d'écrire la première règle, vous devez savoir à quoi sert chaque port. Les deux plateformes en utilisent plusieurs.

Deux particularités comptent ici. Chez RAGE MP, le port HTTP est solidement lié au port de jeu, il est toujours celui qui suit immédiatement : si vous déplacez le port de jeu sur 22015, le port des fichiers suit sur 22016. Chez alt:V, le trafic de jeu et la livraison des fichiers partagent le même numéro de port, une fois en UDP et une fois en TCP. Faire livrer les fichiers client par un réseau de diffusion de contenu (options useCdn et cdnUrl dans le fichier server.toml) retire la partie TCP de votre propre raccordement. Le trafic de jeu en UDP n'en est pas affecté.

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

Les étapes qui suivent n'arrêtent aucune attaque volumétrique, aucun logiciel sur le serveur n'en est capable. Elles éliminent en revanche tout ce qui se situe en dessous : scans de ports, floods de connexions issus de quelques sources, attaques visant la base de données plutôt que le jeu, et détournement de votre propre port de fichiers. C'est l'essentiel de ce qui perturbe un petit serveur au quotidien, et cela ne coûte qu'une demi-heure.

Étape 1 : état des lieux, ce qui écoute vers l'extérieur

ss -tulnp

La colonne intéressante est celle de l'adresse locale. Tout ce qui y figure sur 0.0.0.0 ou [::] est joignable depuis Internet, tout ce qui est sur 127.0.0.1 ne l'est qu'en local. Sur un serveur roleplay classique, on trouve vite, à côté du jeu, une base de données, un cache, un panneau web et parfois un serveur vocal. Chacun de ces services représente une surface d'attaque à part entière, et aucun ne doit être ouvert au seul motif qu'il tourne.

Étape 2 : restreindre le pare-feu aux ports réellement nécessaires

Pour un serveur RAGE MP, cela représente trois autorisations : SSH, le port de jeu et le port des fichiers. Autorisez dans tous les cas votre port SSH en premier, faute de quoi la dernière ligne vous bloquera vous-même l'accès :

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 22005/udp
ufw allow 22006/tcp
ufw enable

Pour alt:V, les deux règles de jeu deviennent :

ufw allow 7788/udp
ufw allow 7788/tcp

Vérifiez ensuite avec ufw status verbose que seuls ces ports sont réellement ouverts, puis relancez ss -tulnp. La configuration détaillée, IPv6 et pièges classiques du verrouillage compris, figure dans Configurer le pare-feu UFW.

Étape 3 : retirer la base de données et le cache du réseau

Sur la plupart des gamemodes, MariaDB et Redis tournent sur la même machine que le serveur de jeu et n'ont alors besoin d'aucune adresse sur Internet. La configuration de MariaDB (sous Debian et Ubuntu /etc/mysql/mariadb.conf.d/50-server.cnf) doit contenir cette ligne :

bind-address = 127.0.0.1

Et dans /etc/redis/redis.conf :

bind 127.0.0.1 ::1
protected-mode yes

Redémarrez ensuite les deux services et contrôlez le résultat avec ss -tulnp. Un cache ouvert et sans mot de passe n'est pas un problème de DDoS, c'est une porte d'entrée pour une intrusion, et elle est scannée jour et nuit.

Étape 4 : limiter les débits de connexion sur le port des fichiers

Le port TCP des fichiers client est l'endroit où une limitation de débit posée sur le serveur agit utilement, car il y a ici un véritable établissement de connexion, et donc une adresse source à laquelle on peut à peu près se fier. Deux règles suffisent, ici pour RAGE MP sur le port 22006 :

iptables -A INPUT -p tcp --dport 22006 --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP
iptables -A INPUT -p tcp --dport 22006 --syn -m hashlimit --hashlimit-name gtahttp --hashlimit-mode srcip --hashlimit-above 30/sec --hashlimit-burst 60 -j DROP

La première règle limite le nombre de connexions ouvertes simultanément par adresse source, la seconde les tentatives de connexion par seconde. Pour alt:V, indiquez 7788 aux deux endroits. Trois remarques à ce sujet : ufw limit est ici trop grossier et ne connaît que TCP, les valeurs numériques sont à adapter à la taille de vos fichiers client, et les règles ne survivent à un redémarrage qu'avec iptables-persistent ou sous forme d'entrée dans /etc/ufw/before.rules.

Sur le port de jeu UDP, en revanche, la même technique n'apporte pas grand-chose, car les expéditeurs y sont falsifiés : un blocage par adresse source ne touche alors personne, sinon par hasard un vrai joueur. Ce que vous devez surveiller à la place, c'est le suivi de connexions du noyau :

cat /proc/sys/net/netfilter/nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Lorsque la première valeur se rapproche de la seconde, le noyau rejette des paquets sans distinguer s'ils appartiennent à une attaque ou à un joueur. Le journal système affiche alors nf_conntrack: table full, dropping packet.

Étape 5 : utiliser les moyens intégrés aux deux plateformes

Les deux cœurs de serveur proposent des réglages pensés précisément contre les abus de connexion, et qui sortent d'usine sur la valeur la plus permissive. Chez RAGE MP, cela concerne trois clés dans le fichier conf.json :

{
    "bind": "0.0.0.0",
    "port": 22005,
    "announce": true,
    "maxplayers": 200,
    "disallow-multiple-connections-per-ip": true,
    "limit-time-of-connections-per-ip": 1000,
    "enable-http-security": true
}

Ceci n'est qu'un extrait, les autres clés restent inchangées. disallow-multiple-connections-per-ip empêche plusieurs connexions simultanées depuis la même adresse, limit-time-of-connections-per-ip impose un intervalle minimal entre deux tentatives de connexion (0 désactive la limitation), et enable-http-security active les contrôles supplémentaires du serveur HTTP intégré. Vérifiez l'unité de temps de la valeur du milieu dans la documentation de votre version de serveur avant de l'augmenter. Et attendez-vous à ce que la première option exclue les joueurs partageant un même raccordement, donc les colocations, les familles et les réseaux d'entreprise.

Chez alt:V, les options correspondantes se trouvent dans le fichier server.toml :

host = '0.0.0.0'
port = 7788
players = 200
announce = true
duplicatePlayers = 4
connectionQueue = true
useEarlyAuth = true

duplicatePlayers limite le nombre de joueurs autorisés à être connectés en même temps depuis la même adresse IP. La valeur par défaut est de 4096, ce qui ne constitue pratiquement aucune limite. connectionQueue place les tentatives de connexion dans une file d'attente au lieu de les traiter toutes d'un coup. useEarlyAuth place une authentification devant le serveur de jeu : le client doit se connecter avant d'entrer dans votre monde de jeu, ce qui écarte d'emblée les floods de connexions simples. L'adresse de la page d'authentification se définit dans earlyAuthUrl.

Étape 6 : la liste blanche, le temps de l'urgence

Lorsqu'une attaque passe par la mécanique du jeu, donc par des tentatives de connexion en masse plutôt que par la seule bande passante, une liste blanche est le moyen le plus efficace à court terme. Chez alt:V, un simple password dans le fichier server.toml suffit à passer en accès fermé. Sous forme de code, la version la plus simple ressemble à ceci, ici pour RAGE MP :

const whitelist = new Set(['JoueurUn', 'JoueurDeux']);

mp.events.add('playerJoin', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Le serveur est actuellement fermé.');
    }
});

Et la même logique pour alt:V :

import * as alt from 'alt-server';

const whitelist = new Set(['JoueurUn', 'JoueurDeux']);

alt.on('playerConnect', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Le serveur est actuellement fermé.');
    }
});

Les deux exemples sont volontairement simples et ont une limite claire : le nom affiché n'est pas un critère solide. Qui exploite une liste blanche sur la durée a intérêt à contrôler l'identifiant issu de l'authentification placée en amont, ou sa propre gestion de comptes. Surtout, retenez ceci : une expulsion n'a lieu qu'une fois la connexion arrivée sur le serveur. Contre des paquets qui saturent déjà le raccordement, elle ne sert à rien.

Étape 7 : l'entrée dans la liste des serveurs et l'hygiène de l'adresse IP

Désactiver l'entrée dans la liste des serveurs (announce sur false) a l'air d'une solution rapide, mais n'en est généralement pas une. Celui qui possède déjà votre adresse IP vous atteint toujours, tandis que vos joueurs ne vous trouvent plus. La démarche n'a de sens qu'accompagnée d'un changement d'adresse IP, car l'attaquant ne perd sa cible qu'à ce moment-là.

Sur la durée, il vaut mieux faire le ménage là où l'adresse se répand incidemment : héberger le site et le forum sur une autre machine, supprimer les anciens enregistrements DNS (y compris mail, ftp et les noms de test des débuts), ne pas faire tourner les bots Discord et les pages de statut depuis le serveur de jeu, séparer le serveur vocal. On ne peut cependant pas dissimuler complètement l'adresse d'un serveur de jeu : le trafic de jeu en UDP doit vous parvenir directement, et un réseau de diffusion de contenu placé devant les sites web n'y change rien. Ce qui aide ici n'est pas la dissimulation, mais une adresse derrière laquelle se trouve un filtrage.

Étape 8 : collecter des mesures avant que la situation ne devienne sérieuse

En cas de coup dur, seul compte ce que vous pouvez prouver. Préparez à l'avance les commandes qui vous donnent en quelques secondes le débit de paquets entrants et l'état des connexions :

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) paquets/s en entrée sur $IF"
ss -s

Relevez ces valeurs une fois en fonctionnement normal, aux heures de pointe, car sans point de comparaison, tout chiffre mesuré pendant une attaque est sans valeur. Si votre serveur de jeu tourne comme service systemd, ajoutez journalctl -u <nom-du-service> -n 200 : les floods de connexions y laissent en général une trace nette. Une limite doit être connue : sur le serveur, vous ne mesurez que ce qui est passé. Si un filtrage est placé en amont, le chiffre fiable se trouve dans le graphique de trafic de l'espace client, et non dans /proc.

Où ces mesures s'arrêtent

Toute règle posée sur le serveur n'agit qu'une fois le paquet arrivé. C'est la phrase décisive. Un pare-feu décide du sort de paquets qui ont déjà parcouru votre raccordement, et c'est précisément ce raccordement que vise une attaque volumétrique.

Voici les ordres de grandeur : un serveur isolé est en règle générale raccordé à 1 Gbit/s. Avec les plus petits paquets, cela correspond à environ 1,5 million de paquets par seconde, et physiquement rien de plus ne passe. Pour saturer ce raccordement, personne n'a besoin d'une attaque record, de 2 à 5 Gbit/s y suffisent. À titre de comparaison, une attaque réellement mesurée dans le réseau francfortois de KernelHost : plus de 473,4 Gbit/s et plus de 41,5 millions de paquets par seconde sur un seul service. Cela représente environ 470 fois un raccordement gigabit, et même un raccordement à 10 Gbit/s en reste éloigné d'un facteur 47.

Une fois le raccordement saturé, c'est déjà le routeur situé devant qui rejette, et sans considération pour le paquet individuel. Vos joueurs se retrouvent alors dans la même file d'attente que l'attaque. Ni iptables, ni un plugin, ni un CPU plus puissant n'y changent quoi que ce soit, parce que le goulot d'étranglement se situe en amont du serveur. S'y ajoute que les adresses source sont falsifiées lors des floods UDP : il n'y a tout simplement personne que vous puissiez bloquer utilement.

Seul un filtrage placé dans le réseau, en amont de votre raccordement, et disposant à cet endroit d'assez de capacité pour que l'attaque ne le sature pas, est donc efficace.

Ce que KernelHost oppose à cela

La protection permanente déjà active sur chaque serveur

Chez KernelHost (KernelHost GmbH, dont le siège se trouve à Vienne, en Autriche), une protection DDoS à deux niveaux est active en permanence sur chaque serveur, sans commande, sans configuration et sans supplément :

• Niveau 1 : réseau de scrubbing mondial doté de 17 Tbps de capacité de mitigation. Les attaques volumétriques sont interceptées au plus près de leur source, avant même d'atteindre le centre de données.
• Niveau 2 : filtrage Arbor en temps réel à 3,2 Tbps. Il est installé sur place, dans le datacenter maincubes de Francfort-sur-le-Main (Allemagne), et assure le travail de précision juste devant votre serveur, paquet par paquet.

Ce qui n'arrive pas compte tout autant : il n'y a pas de null-routing. Votre adresse IP reste dans le réseau pendant une attaque, seuls les paquets nuisibles disparaissent. Pour un serveur roleplay, cette différence est considérable, car une adresse mise en null-route est, pour vos joueurs, indiscernable d'une attaque réussie. Si vous ne passez plus en SSH pendant un incident, vous atteignez toujours le système par la console VNC de l'espace client, qui fonctionne indépendamment du raccordement réseau du serveur.

Advanced DDoS Protection pour les projets attaqués en continu

Certains projets ne sont pas touchés une seule fois, mais pendant des semaines. Pour ce cas de figure, il existe l'Advanced DDoS Protection à partir de 50,00 € par mois, en PrePaid et sans durée minimale, sans préavis de résiliation, sans contrat et sans frais de mise en service. Elle comprend :

• une IP protégée dédiée issue du cœur de réseau de Francfort, vers laquelle votre serveur est basculé, sans aucune modification de votre côté,
• des règles de protection que vous gérez vous-même, par port et par protocole, directement dans l'espace client,
• des changements qui s'appliquent en temps réel, sans ticket et sans attente,
• un profil de protection adapté au jeu concerné, choisi parmi plus de 40 profils pour jeux, services et protocoles, dont RageMP et alt:V, ainsi que des profils génériques pour vos propres applications TCP et UDP.

La différence pratique tient au contrôle : vous décidez vous-même quel profil tourne sur 22005 UDP et quelle règle s'applique à 22006 TCP, y compris en pleine attaque.

Les deux niveaux comparés

Erreurs fréquentes et solutions

Tous les ports ouverts, parce que sinon quelque chose ne fonctionne pas : il s'agit presque toujours d'un mauvais diagnostic. Notez avec ss -tulnp quel service a besoin de quel port, et n'ouvrez que ceux-là. S'il manque encore quelque chose ensuite, la cause vient le plus souvent d'un service qui n'est de toute façon attaché qu'en local.

Les adresses IP des attaquants sont bloquées : lors d'un flood UDP, les expéditeurs sont falsifiés. Vous bloquez ainsi des adresses non concernées et, dans le pire des cas, vos propres joueurs. Cela n'a de sens que pour les connexions TCP entièrement établies, donc sur le port des fichiers.

announce simplement mis sur false : le serveur disparaît de la liste, mais l'adresse IP reste la même. Une attaque en cours se poursuit sans changement, seuls vos joueurs ne trouvent plus le serveur. Sans changement d'adresse, la démarche n'apporte rien.

Limitation de débit sur le port de jeu UDP : les réseaux mobiles et les raccordements d'entreprise regroupent de nombreux joueurs derrière une seule adresse. Une limitation par adresse source y éjecte de vrais joueurs, tandis que les expéditeurs falsifiés du flood restent tranquilles.

Plus de CPU et plus de RAM comme réponse au DDoS : les deux aident contre un gamemode surchargé, pas contre un raccordement saturé. Le goulot d'étranglement se situe en amont du serveur, et un matériel plus puissant n'y change rien.

Redémarrage en pleine attaque : il efface tous les compteurs dont vous auriez eu besoin pour un signalement solide, et l'attaque se poursuit ensuite sans changement. Collectez d'abord les mesures, agissez ensuite.

Base de données ouverte sur Internet parce que le panneau web tourne sur une autre machine : faites passer la connexion par un tunnel SSH ou par un réseau privé. Si ce n'est pas possible, restreignez au moins l'accès à la seule adresse source qui en a réellement besoin.

Si cela se produit en ce moment

Collectez d'abord les mesures de l'étape 8, pour que votre signalement soit solide : l'horodatage avec le fuseau horaire, l'adresse IP et le port concernés, le débit de paquets mesuré avec le sens du trafic. Ouvrez ensuite un ticket de support. Pendant une attaque en cours, vous pouvez également nous joindre via le chat d'urgence WhatsApp au +43 650 8209883. Une vue d'ensemble indépendante de l'hébergeur sur les étapes suivantes est donnée dans Protéger son serveur des attaques DDoS.