Serveur FiveM attaqué par DDoS : que faire tout de suite

Aucun symptôme ne le prouve à lui seul : un script bloqué, une règle de pare-feu et une attaque par saturation peuvent tous finir par un timeout général. Ces trois vérifications reposent sur des preuves extérieures au jeu.

1. Le trafic entrant a-t-il grimpé ?

C’est la vérification qui compte, et elle vient de votre hébergeur ou de la machine, pas de FiveM. Le graphique de trafic entrant du panel de l’hébergeur est le plus rapide : comparez-le à une journée calme. Une vague de connexions après un redémarrage se voit plutôt en sortie (téléchargements), une attaque par saturation en entrée.

Sur la machine, dix secondes de compteurs suffisent. Regardez les paquets et les kilo-octets reçus par seconde sur l’interface publique.

sar -n DEV 1 10

Get-Counter -Counter '\Network Interface(*)\Packets Received/sec' -Continuous

2. Le processus est-il bloqué, ou répond-il encore ?

Lisez la console de FXServer. Les lignes server thread hitch warning indiquent qu’un thread a pris du retard. Les causes les plus signalées sont les scripts, les gros net events et un CPU faible ; ces alertes seules ne prouvent pas une attaque.

Un txAdmin « online » prouve moins qu’il n’y paraît. Son contrôle de santé est une requête que la machine adresse à son propre FXServer (vérifié sur txAdmin 8.1.1) : il peut rester vert alors que personne ne peut se connecter de l’extérieur.

3. Tout le monde, ou quelques joueurs ?

Tout le monde en même temps, avec une console calme, laisse penser à un problème hors de la machine. Quelques joueurs chez le même fournisseur d’accès laissent plutôt penser à un problème sur leur propre route. Demandez à deux ou trois joueurs touchés la ligne « Timeout info » de la fenêtre d’erreur : comparer ses valeurs game, recv et send aide à distinguer un jeu bloqué de paquets qui ont cessé d’arriver.

Voici les situations le plus souvent confondues avec une attaque. Chaque guide dit ce qui changerait son verdict.

• Console : « server thread hitch warning »

  Un thread a pris du retard : scripts, net events ou CPU d’abord.

  Server thread hitch warning

• Joueurs : « Failed to get info from server (tried 3 times) »

  La réponse UDP n’est jamais revenue. Vérifiez d’abord le transfert UDP et les pare-feux, avant de soupçonner une saturation.

  Failed to get info from server

• Beaucoup de joueurs d’un coup : « Client -> server connection timed out »

  Un blocage assez long pour déconnecter tout le monde, côté serveur ou sur le trajet réseau.

  Tout le monde en timeout en même temps

• Votre hébergeur écrit que le trafic a été redirigé vers son infrastructure anti-DDoS

  Une attaque que votre hébergeur a détectée.

  Pic de trafic ou notification de l’hébergeur

• Une menace, ou l’IP de votre serveur visible quelque part en public

  Pas encore une attaque. La question est de savoir si votre vraie IP est publiée.

  IP fuitée ou menace de DDoS

• Tous les problèmes de serveur FiveM, diagnostiqués

Face à une grosse attaque, un hébergeur choisit en général entre deux réponses, et savoir laquelle s’applique à vous change la suite. Le filtrage (scrubbing) redirige le trafic vers des équipements de nettoyage, et la partie saine vous parvient encore. Une null route coupe tout le trafic vers l’IP : la documentation de TransIP indique qu’une adresse en null route n’est plus joignable depuis l’extérieur. Les fournisseurs diffèrent. Le support de votre hébergeur peut vous dire dans quel cas vous êtes.

Chez OVHcloud, le Network Security Dashboard (Network, puis Network Security Dashboard, dans l’espace client) liste les attaques détectées dans son scrubbing centre log : heure de détection, heure de fin, IP de destination et vecteurs d’attaque. Les adresses sources n’y figurent pas, car elles sont le plus souvent usurpées : les bannir depuis votre panel ne sert à rien.

Le message à envoyer

Bonjour,

Depuis [heure de début et fuseau horaire], le serveur de jeu sur [IP], ports UDP et TCP [port], est inaccessible pour la plupart des joueurs. La machine est allumée et le processus tourne, mais les joueurs tombent en timeout.

Pouvez-vous m’indiquer :
1. Cette IP est-elle actuellement filtrée (trafic redirigé vers votre infrastructure anti-DDoS) ou en null route ?
2. Quels type et volume d’attaque voyez-vous, et depuis quand ?
3. Y a-t-il quelque chose à changer de mon côté, et comment saurai-je que le trafic est redevenu normal ?

Je joins une capture du graphique de trafic entrant. Merci de conserver les journaux de cette IP : j’en aurai peut-être besoin.

Cordialement,

À sauvegarder avant tout redémarrage

• Une capture des graphiques de trafic entrant et sortant de l’hébergeur, avec la plage horaire visible.
• Tout e-mail ou avis de l’hébergeur, avec son horodatage.
• La console FXServer et le journal txAdmin autour de l’heure de début.
• La ligne « Timeout info » de deux ou trois joueurs touchés.
• L’heure de début, dans votre fuseau horaire et en UTC.

Ce qu’il peut faire

• Filtrer le trafic avant qu’il n’atteigne votre serveur : les joueurs se connectent au proxy, et votre machine ne voit que ce que le proxy lui transmet.
• Remplacer l’adresse que vous publiez. La liste des serveurs affiche un nom d’hôte FiveShield au lieu de l’IP de la machine.
• Se mettre en place en cinq minutes environ, sans déplacer le serveur ni toucher au DNS.

Ce qu’il ne peut pas faire

• Arrêter une attaque dirigée vers une adresse que l’attaquant connaît déjà, tant que cette adresse accepte du trafic. C’est pourquoi la section suivante a une étape pour l’IP.
• Réparer un script bloqué, un net event en boucle ou un CPU trop faible. Si les vérifications ci-dessus n’ont montré aucun pic de trafic, un proxy n’est pas la solution.
• Garantir une protection contre tous les types d’attaque. Notre politique de remboursement le dit : aucun service ne le peut.

• Lire la politique de remboursement

Rien n’est à migrer, ce qui rend l’opération possible en pleine attaque. C’est l’ordre des étapes qui la fait réussir.

1. Installez le proxy. Créez votre serveur dans le tableau de bord, collez le bloc fourni tout en haut de server.cfg et redémarrez. C’est le seul redémarrage qui en vaille la peine.
2. Changez l’IP si l’attaquant la connaît. Un proxy ne peut pas protéger une adresse que les attaquants connaissent déjà : demandez à votre hébergeur une nouvelle IP pour la machine. Chez OVHcloud, le pare-feu Edge Network décrit dans le guide d’installation peut rendre une nouvelle IP inutile une fois ses règles correctes, mais une règle Allow dont l’IP source est vide annule tout le pare-feu : lisez l’avertissement du guide. Si l’attaque continue sur l’ancienne adresse, demandez une nouvelle IP à votre hébergeur.
3. Mettez l’adresse à jour dans les Paramètres. Saisissez la nouvelle IP dans les Paramètres de votre serveur, dans le tableau de bord, et ne la donnez à personne d’autre : ni sur Discord, ni en capture d’écran, ni dans un ticket que d’autres peuvent lire.
4. Fermez l’origine. Seuls le proxy et votre propre IP doivent pouvoir joindre la machine ; la section sur le pare-feu Edge d’OVH du guide d’installation donne les règles.
5. Vérifiez ce que vous publiez. Passez votre code de connexion dans le CFX Finder : il doit afficher un nom d’hôte FiveShield, pas une IP et un port.

• Le guide d’installation, pas à pas
• Vérifier votre code de connexion avec le CFX Finder

Dites ce que vous savez, sans jamais citer d’adresse.

Ne nommez personne : l’hébergeur doit d’abord confirmer une attaque, et même une fois celle-ci confirmée, les adresses sources sont le plus souvent usurpées.

L’attaquant a trouvé l’adresse quelque part. Tant que vous ne savez pas où, la prochaine attaque tombera au même endroit.

• Passez votre code de connexion dans le CFX Finder. Une IP et un port bruts dans la liste des serveurs signifient que l’adresse est publique.
• Vérifiez les enregistrements DNS de votre domaine, les anciens compris. Tout enregistrement qui pointe vers la machine de FXServer trahit l’adresse, tout comme un site web hébergé sur cette machine.
• Cherchez des adresses codées en dur dans vos ressources, et l’endpoint dans vos webhooks Discord et vos salons de logs.
• Placez txAdmin derrière la même protection, ou limitez son port (40120 par défaut) à vos propres IP.
• Verrouillez l’origine : seuls le proxy et votre IP doivent pouvoir la joindre.

Déjà protégé et toujours touché ?

Testez si l’origine répond encore. Depuis un autre réseau, une requête vers l’IP d’origine sur le port de jeu ne doit rien renvoyer. Si elle répond, le proxy est contourné et c’est du côté des fuites ci-dessus qu’il faut chercher. Sinon, dites-nous sur Discord à quelle heure cela a commencé.

• Toutes les façons dont l’IP d’un serveur FiveM fuit, en détail