« Anti-DDoS inclus » figure sur à peu près toutes les pages d'hébergement. La formule est vague, et elle couvre des réalités très différentes. Voici ce qu'il faut comprendre pour savoir ce que vous achetez.
Ce qu'est une attaque par déni de service
Une attaque DDoS cherche à rendre un service indisponible en le saturant. Il en existe deux familles, qui n'ont presque rien en commun.
Les attaques volumétriques noient le lien réseau sous un flot de paquets. On les mesure en gigabits par seconde. Elles n'exploitent aucune faille : elles remplissent simplement le tuyau. Un serveur derrière un lien de 1 Gb/s tombe face à 10 Gb/s de trafic, quel que soit son logiciel.
Les attaques applicatives sont bien plus discrètes. Quelques milliers de requêtes HTTP parfaitement légitimes en apparence, visant la page la plus coûteuse du site, suffisent à saturer la base de données. Le volume est faible ; le service tombe quand même.
Ce que fait un filtrage réseau
Le filtrage Anti-DDoS agit en amont, dans le réseau du datacenter, avant que le trafic n'atteigne votre serveur. Les équipements analysent les flux et écartent ce qui ne ressemble pas à du trafic légitime : amplifications DNS ou NTP, inondations SYN, paquets malformés.
C'est très efficace sur le volumétrique, et c'est ce qui compte le plus pour un serveur de jeu : ces attaques-là visent à couper la partie, pas à voler des données.
Ce qu'aucun filtrage ne fera à votre place
Il est honnête de le dire clairement :
- Une attaque applicative ciblée ressemble à du trafic normal. Le filtrage réseau la laisse passer ; c'est à vous de mettre en place de la limitation de débit, du cache et des protections côté application.
- Un mot de passe faible n'est pas un problème de DDoS. La majorité des serveurs compromis le sont par un accès mal protégé, pas par une attaque de saturation.
- Un plugin vulnérable reste vulnérable, protégé ou non.
- Une attaque interne — un joueur qui abuse d'une commande coûteuse — ne se voit pas depuis le réseau.
Les bons réflexes en complément
- Ne publiez pas l'IP de votre machine. Pour un site web, passez par un service qui masque l'origine. Une IP connue est une cible plus facile.
- Limitez le débit côté application. Sur une API ou un formulaire, quelques requêtes par minute et par adresse suffisent presque toujours.
- Mettez en cache. Une page servie depuis le cache coûte mille fois moins qu'une page recalculée.
- Surveillez. Une attaque repérée en dix minutes se traite beaucoup mieux qu'une attaque découverte le lendemain.
Ce qu'il faut demander à un hébergeur
Trois questions simples :
- Le filtrage est-il actif en permanence, ou activé à la demande ?
- Y a-t-il une limite de capacité, et laquelle ?
- Que se passe-t-il si mon service est attaqué de façon répétée — suis-je protégé, ou suspendu ?
La dernière question est la plus révélatrice. Certains hébergeurs coupent le client attaqué pour protéger les autres. C'est une politique défendable, mais elle doit être annoncée avant la commande, pas découverte pendant l'incident.
Notre page d'état des services publie en continu la disponibilité de chaque brique de l'infrastructure.