Protection anti-DDoS

Tous les services CloudFive sont derrière une protection anti-DDoS développée en interne, annoncée à 17 Tb/s de capacité de filtrage. Cette page explique ce qu’elle fait sans que vous ayez à y toucher, ce qu’elle ne fait pas, et la marche à suivre quand votre serveur est visé. Elle s’adresse aux clients VPS et dédiés ; pour une vue plus générale, lisez Comprendre l’anti-DDoS CloudFive.

Ce que la protection filtre automatiquement

Le filtrage est réalisé par un moteur maison en XDP/eBPF, c’est-à-dire au plus près de la carte réseau, avant que les paquets n’atteignent votre serveur. Concrètement, il écarte en continu :

les inondations volumétriques destinées à saturer le lien (UDP massif, ICMP, trafic sans destinataire valide) ;
les attaques par amplification et réflexion, où des services tiers mal configurés sont utilisés pour vous envoyer un volume multiplié ;
les inondations de connexions sur TCP, du type flot de SYN qui ne va jamais au bout ;
les sources manifestement usurpées, dont l’adresse d’origine ne peut pas exister sur Internet ;
les adresses déjà repérées en train d’arroser plusieurs serveurs de l’infrastructure.

Ce travail est invisible : vous ne voyez ni le trafic écarté, ni les compteurs. Côté serveur, une attaque correctement absorbée ne laisse souvent aucune trace dans vos propres journaux — c’est le résultat attendu.

Les modes de mitigation et leur impact

Le filtrage fonctionne à deux niveaux.

En permanence, un filtrage de fond écarte le trafic clairement illégitime. Il est neutre pour vos visiteurs et vos joueurs : c’est l’état normal de votre IP.

Pendant une attaque, le filtrage se renforce automatiquement sur l’IP visée. Les critères deviennent plus stricts, et c’est là qu’il faut comprendre le compromis : plus un filtrage est agressif, plus il risque d’écarter du trafic légitime qui ressemble à l’attaque. Un renforcement peut donc se traduire, le temps de l’attaque, par :

des connexions plus lentes à s’établir, ou une ou deux tentatives nécessaires ;
des micro-coupures sur des protocoles atypiques (tunnels, VoIP, flux UDP maison) ;
des requêtes refusées pour une source qui envoie beaucoup de paquets en très peu de temps.

Le réglage appliqué à votre IP n’est pas figé : il tient compte du type de service hébergé. Si votre usage est particulier — tunnel, serveur de voix, base de données exposée, protocole peu courant — ouvrez un ticket de support en décrivant précisément les ports et protocoles concernés. C’est le seul moyen d’obtenir un profil adapté plutôt que de subir un réglage générique.

Éviter les faux positifs sur un service légitime

Un faux positif, c’est du trafic normal pris pour une attaque. Les causes les plus fréquentes, et ce qui les évite :

Un service qui envoie beaucoup de paquets très courts. Déclarez-le au support avec son port et son protocole plutôt que d’attendre qu’il soit filtré.
Un port d’écoute inhabituel. Restez sur les ports standards quand c’est possible : ils sont reconnus comme tels. Voir Ports et protocoles par service.
Un outil de test de charge lancé depuis l’extérieur. Un test de montée en charge ressemble trait pour trait à une attaque. Prévenez le support avant, en donnant la plage horaire et l’IP source.
Un scanner ou un robot de surveillance qui interroge trop de ports à la fois depuis la même adresse. Espacez les sondes de vos outils de monitoring.
Un tunnel, un VPN ou un lien entre deux serveurs. Ces flux encapsulés sont les premiers touchés par un renforcement. Ils doivent être déclarés une fois pour toutes.

Cas particulier des serveurs de jeu

Le trafic de jeu est le pire cas pour un filtrage : beaucoup de petits paquets UDP, en continu, depuis des centaines d’adresses différentes. C’est exactement la signature d’une attaque volumétrique.

Deux situations à distinguer :

Votre serveur est hébergé sur le panel de jeu (panel.cloudfive.xyz). Le réglage adapté au jeu est déjà en place pour les offres de serveurs de jeu, et vous n’avez rien à faire. Si vous constatez des déconnexions, commencez par la console et les logs : un script en erreur ou un manque de RAM expliquent la grande majorité des cas.
Vous installez vous-même un serveur de jeu sur un VPS. Là, précisez-le au support : indiquez le jeu, le port et le protocole. Sans cette information, votre IP est traitée comme une IP de serveur générique, et un flux de jeu intense peut être vu comme suspect.

Si vous arbitrez encore entre les deux, Serveur de jeu ou VPS : lequel choisir ? compare les deux approches, et Latence, ping et tickrate explique ce qui se ressent vraiment en jeu.

Que faire pendant une attaque

Vérifiez d’abord status.cloudfive.xyz. Si un incident général est publié, vous n’êtes pas seul concerné et un ticket n’accélérera rien.
Ne redémarrez pas en boucle. Un redémarrage ne fait pas cesser une attaque, et il vous prive des informations utiles au diagnostic.
Regardez ce que voit votre serveur avant d’accuser le réseau :
Fenêtre de terminal
```
ss -s                      # nombre de connexions en cours
uptime                     # charge moyenne de la machine
journalctl -n 100 --no-pager
```
Une charge CPU à 100 % avec un réseau calme, c’est un problème applicatif, pas une attaque. Voir Surveiller les ressources.
Ouvrez un ticket avec l’adresse IP concernée, l’heure de début (avec le fuseau), les ports et protocoles touchés, et le symptôme exact côté utilisateur.
Attendez la réponse sans modifier votre configuration. Changer de port, basculer un DNS ou réinstaller pendant un épisode brouille les pistes et retarde la résolution.

Ce que la protection ne couvre pas

C’est la partie que l’on oublie. Le filtrage réseau ne vous protège pas contre :

un mot de passe faible ou une connexion SSH par mot de passe — réglez cela avec une clé SSH ;
une application vulnérable (extension obsolète, panneau d’administration exposé) ;
une saturation de vos propres ressources par un trafic légitime mais trop important ;
une erreur de configuration qui rend votre service injoignable ;
la perte de données. Seule une sauvegarde répare cela : Snapshots et sauvegardes.

En cas de problème

Mon service est injoignable et je soupçonne le filtrage. Testez dans l’ordre : le ping de l’IP, puis le port concerné, puis la même chose depuis une autre connexion Internet. Si le ping passe mais pas le port, le problème est presque toujours local : pare-feu ou service arrêté.

Mes utilisateurs sont déconnectés par vagues. Notez l’heure précise de deux ou trois vagues, demandez à un utilisateur son opérateur et son pays, puis ouvrez un ticket avec ces éléments. Un filtrage trop strict et une saturation applicative donnent le même symptôme ; seules les heures exactes permettent de trancher.

Tout remarche, mais je veux éviter la prochaine fois. Faites déclarer votre usage réel (ports, protocoles, type de service) par ticket une fois pour toutes. C’est la mesure la plus efficace, et elle se prend à froid, pas pendant une attaque.

Mon VPS ne répond plus du tout. Suivez Dépannage : mon VPS est inaccessible, qui déroule un diagnostic complet, console de secours comprise.