Comprendre l'anti-DDoS CloudFive

Cette page explique ce qu’est une attaque par déni de service, ce que la protection CloudFive filtre à votre place, et surtout ce qu’elle ne peut pas faire. Elle s’adresse à tout client : serveur de jeu, VPS, dédié ou hébergement web. Vous n’avez rien à activer, le filtrage est permanent — mais savoir ce qu’il couvre évite beaucoup de faux diagnostics.

Ce qu’est concrètement une attaque DDoS

Une attaque par déni de service distribué envoie vers une adresse IP plus de trafic qu’elle ne peut en traiter. Le but n’est pas de voler des données, c’est de rendre le service injoignable. « Distribué » signifie que le trafic vient de milliers de machines à la fois — souvent piratées, parfois des adresses falsifiées qui n’existent pas.

Trois choses à comprendre d’emblée :

Une attaque sature un tuyau ou un processeur, pas un mot de passe. Rien n’est volé, vos fichiers ne sont pas concernés.
Le volume n’est pas tout. Une attaque de quelques mégabits bien ciblée sur le protocole du jeu fait plus de dégâts qu’un flot brut énorme.
Beaucoup de « DDoS » n’en sont pas. Un script en boucle, une base saturée, un plugin défaillant ou la connexion du joueur produisent les mêmes symptômes. D’où l’importance de vérifier avant de conclure.

Les types d’attaques les plus courants sur un serveur de jeu

Type	Comment ça marche	Ce que vous voyez
Flood UDP	un déluge de paquets vers le port du jeu	ping qui explose, joueurs éjectés en masse
Amplification / réflexion	des serveurs tiers mal configurés sont utilisés pour multiplier le volume envoyé vers vous	gros pic de trafic venu d’adresses crédibles
Flood SYN	des milliers de demandes de connexion jamais terminées	le serveur n’accepte plus de nouvelle connexion
Paquets fragmentés ou malformés	des paquets volontairement anormaux, coûteux à traiter	coupures brèves et répétées
Flood applicatif (requêtes de jeu)	des requêtes valides en apparence, envoyées en boucle	liste de serveurs qui décroche, faux joueurs
Flood HTTP (sites web)	des milliers de requêtes sur les pages les plus lourdes	site lent, erreurs de passerelle

Dans le monde du jeu, deux cas reviennent sans cesse :

L’attaque sur le joueur, pas sur le serveur. Quelqu’un obtient l’adresse IP d’un joueur et l’attaque chez lui. Le serveur va parfaitement bien ; une seule personne se déconnecte. Aucun hébergeur ne peut agir sur la connexion personnelle d’un joueur.
Les faux joueurs. Des connexions automatisées remplissent les slots pour empêcher les vrais joueurs d’entrer. C’est de l’abus applicatif, pas du volume.

Comment le trafic est filtré avant d’atteindre votre serveur

Le tri se fait en amont, sur le réseau, avant que les paquets arrivent à votre serveur. Si le nettoyage se faisait sur votre machine, il consommerait déjà vos ressources — ce qui est précisément l’objectif de l’attaquant.

Ce que cela implique concrètement :

Le trafic manifestement illégitime est jeté avant votre serveur. Il ne consomme ni votre CPU, ni votre RAM, ni votre bande passante.
Le filtrage est permanent. Pas de bouton à presser, pas de mode « sous attaque » à déclencher en urgence, pas de délai d’activation.
Le filtrage connaît les protocoles de jeu. C’est ce qui permet de distinguer un vrai joueur d’un paquet fabriqué, là où un filtre de volume ne verrait aucune différence.
Le trafic légitime continue de passer pendant l’attaque. C’est tout l’enjeu : une protection qui coupe tout le monde atteint le même résultat que l’attaque.

Ce que la protection ne peut pas faire

C’est la partie la plus utile de la page. Une protection réseau filtre le réseau — et seulement lui.

Elle ne protège pas votre connexion personnelle. Si votre box ou celle d’un joueur est visée, cela se règle avec le fournisseur d’accès concerné, pas avec l’hébergeur.
Elle ne corrige pas un serveur sous-dimensionné. Un serveur limité par son processeur laguera avec du trafic parfaitement légitime. Voir Combien de RAM pour un serveur FiveM et pour un serveur Minecraft.
Elle ne corrige pas une faille dans votre code. Une ressource vérolée, un plugin troué, un accès d’administration laissé ouvert : le trafic est légitime du point de vue du réseau, le problème est chez vous.
Elle ne remplace pas un mot de passe. Un compte piraté, une clé partagée, un identifiant qui traîne dans un dépôt public : rien de cela n’est du ressort du filtrage. Voir Profil, mot de passe et double authentification.
Elle ne distingue pas toujours un pic légitime d’une attaque. Une ouverture de serveur avec 500 connexions en dix secondes ressemble beaucoup à un flood. Prévenez le support si vous attendez un événement de ce genre.
Elle n’empêche pas les abus applicatifs. Faux joueurs, spam de requêtes, bruteforce de vos propres interfaces : cela se traite dans le jeu ou dans l’application.

Aucun filtrage n’est parfait, et le réglage est toujours un compromis : plus on filtre serré, plus on risque d’écarter du trafic honnête. C’est pour cette raison qu’il n’y a pas de promesse chiffrée de disponibilité sur cette page.

Ce que vous pouvez faire de votre côté

Les mesures qui réduisent vraiment la surface d’attaque, dans l’ordre d’efficacité.

Sur un serveur de jeu :

N’exposez que les ports nécessaires. Pas de base de données ouverte sur Internet, pas d’interface d’administration accessible à tous. Voir Ports et allocations et Ports et protocoles par service.
Donnez un nom de domaine à vos joueurs, pas une adresse IP brute : Utiliser un nom de domaine personnalisé.
Tenez à jour vos ressources, plugins et mods, et supprimez ceux dont vous ignorez l’origine.
Protégez vos accès : mot de passe unique, double authentification, et un sous-utilisateur aux droits limités pour chaque membre de l’équipe plutôt qu’un mot de passe partagé.
Sauvegardez. Une attaque ne détruit pas vos données, mais les manipulations faites dans la panique, si. Voir Sauvegardes du serveur de jeu.

Sur un VPS ou un dédié :

Fermez tout ce qui ne sert pas avec le pare-feu, et remplacez l’authentification par mot de passe en SSH par une clé.
Ne laissez tourner aucun service ouvert à tous susceptible de servir d’amplificateur — un résolveur DNS ouvert, par exemple, finira par être utilisé contre quelqu’un d’autre.
Surveillez la charge pour distinguer un pic d’attaque d’une dérive de votre application : Surveiller les ressources, puis Snapshots et sauvegardes.

Le détail propre aux VPS est sur Protection anti-DDoS.

Que faire pendant une attaque

Dans l’ordre. L’objectif des trois premières étapes est de savoir si c’est vraiment une attaque — c’est ce qui fera gagner le plus de temps.

Consultez l’état des services sur status.cloudfive.xyz. Si un incident global est en cours, vous avez votre réponse.
Vérifiez si le serveur lui-même répond : le panel est-il joignable, la console tourne-t-elle, les ressources sont-elles anormalement sollicitées ? Voir Console et logs. Un serveur injoignable dont la console tourne normalement oriente vers le réseau ; un serveur à 100 % de processeur oriente vers votre application.
Testez depuis une autre connexion, le partage de connexion d’un téléphone par exemple. Si vous entrez depuis la 4G mais pas de chez vous, le problème est votre propre accès.
Ne redémarrez pas en boucle. Un redémarrage ne fait pas cesser une attaque et interrompt les écritures en cours.
Ouvrez un ticket sur cloudfive.fr/manager/submitticket.php avec des éléments précis : l’adresse IP et le port concernés, l’heure de début avec le fuseau horaire, les symptômes exacts, un extrait de logs. Un ticket qui dit « ça marche pas » fait perdre un aller-retour.
Signalez-le aussi sur le Discord pour le temps réel — le support est disponible 7 j/7, voir Contacter le support — et transmettez à abuse@cloudfive.xyz toute preuve de la source de l’attaque.
Prévenez vos joueurs et conservez vos traces : elles serviront si vous déposez plainte.

Si l’attaque passe quand même

Les joueurs sont éjectés mais le serveur tourne normalement. Cherchez d’abord du côté applicatif : faux joueurs, requêtes en boucle, ressource défaillante. Si le phénomène est clairement réseau, donnez au support l’adresse, le port et l’horaire précis : un réglage de filtrage adapté à votre service peut être étudié.

Le serveur est injoignable alors que le panel répond. Notez-le tel quel dans votre ticket. Vérifiez au passage que votre nom de domaine pointe toujours vers la bonne adresse et le bon port.

Mon VPS ne répond plus du tout. Passez par la console VNC, qui ne dépend pas du réseau du système, puis par Dépannage : mon VPS est inaccessible. Une attaque et une mauvaise règle de pare-feu produisent le même silence.

Un seul joueur est touché, toujours le même. Ce n’est pas votre serveur qui est attaqué, c’est lui. Conseillez-lui de redémarrer sa box pour changer d’adresse, et d’en parler à son fournisseur d’accès.

Aucune attaque n’est confirmée, c’était juste plus lent. Reprenez par Latence, ping et tickrate : la plupart des « attaques » signalées sont des problèmes de latence ou de dimensionnement.

Pour aller plus loin

Protection anti-DDoS — le cas des VPS et des dédiés.
Glossaire — les termes réseau en une ligne chacun.
Questions fréquentes — les réponses rapides.