Qu'est-ce qu'une attaque DDoS ?
Une attaque par déni de service distribué est exactement ce que son nom indique : un effort coordonné de nombreux points de terminaison pour submerger une cible unique avec du trafic, épuisant une ressource (bande passante réseau, état des connexions du noyau, threads d'application, connexions de base de données) et rendant le service indisponible. Les attaques DDoS modernes se répartissent en trois classes qui diffèrent par la manière dont elles exploitent la cible.
Les attaques volumétriques épuisent la bande passante réseau brute. La variante classique est la réflexion-amplification — l'attaquant envoie des paquets UDP usurpés à des serveurs publics (DNS, NTP, Memcached, CLDAP) qui répondent avec des réponses beaucoup plus grandes, multipliant la bande passante de l'attaquant par 50 à 50 000 selon le protocole. Les attaques volumétriques sont mesurées en bits par seconde et les plus grandes événements publiquement divulgués ont dépassé 3 Tbps. L'atténuation se produit à la périphérie du réseau, avant que le trafic n'atteigne votre serveur.
Les attaques de protocole épuisent l'état des connexions au niveau du noyau. Les SYN floods (connexions TCP semi-ouvertes), les ACK floods et diverses attaques par paquets malformés entrent dans cette catégorie. Elles sont mesurées en paquets par seconde. L'atténuation se produit à la fois à la périphérie (avec des filtres sans état) et sur le serveur (avec réglage du noyau, cookies SYN, blocage automatique de type fail2ban).
Les attaques au niveau de l'application (L7) épuisent les ressources au niveau de l'application. Les inondations HTTP qui ciblent des points de terminaison coûteux, les attaques slow-loris qui maintiennent les connexions ouvertes, les requêtes GraphQL qui explosent en motifs N+1. Mesurées en requêtes par seconde ; l'atténuation nécessite de comprendre la surface de votre application et est rarement réalisable purement à la périphérie du réseau — elle nécessite généralement une limitation de débit au niveau de l'application, des budgets de requêtes, une mise en cache CDN ou un WAF.
Chaque classe nécessite une atténuation différente ; les piles de protection modernes superposent les trois. Les chiffres en Gbps dans les textes marketing des hébergeurs offshore se réfèrent à la capacité volumétrique, mais les attaques volumétriques ne sont qu'une des trois menaces — les deux autres nécessitent un travail d'ingénierie de votre côté.
Comment fonctionne le nettoyage DDoS moderne
L'infrastructure qui absorbe les attaques volumétriques est appelée « centre de nettoyage » et l'architecture est cohérente chez tous les grands fournisseurs (Cloudflare, Akamai, Imperva, NTT) et chez la plupart des hébergeurs offshore qui exploitent leur propre périphérie.
Le trafic destiné à votre IP est annoncé via anycast depuis plusieurs points géographiques. L'anycast permet à la même IP d'être accessible depuis de nombreux endroits ; les protocoles de routage acheminent chaque paquet automatiquement vers la périphérie la plus proche. Lorsqu'une attaque est en cours, le trafic d'attaque est distribué sur de nombreux points de périphérie (car les attaquants sont eux-mêmes géographiquement distribués), et chaque point de périphérie ne voit qu'une fraction du volume total.
À chaque point de périphérie, les filtres de nettoyage classifient le trafic en temps réel. Le trafic légitime est transmis à votre origine ; le trafic d'attaque est abandonné à la périphérie. La classification utilise un mélange de règles sans état (abandonner les adresses IP source usurpées, abandonner les structures de paquets inhabituelles), d'heuristiques avec état (suivre l'état des connexions et abandonner les poignées de main incomplètes) et d'analyse comportementale (abandonner les sources correspondant à des modèles de botnets connus).
Toute l'architecture est préventive — pas de temps de réaction humain, pas besoin d'« activer » l'atténuation. Une fois votre IP sur l'annonce anycast protégée, la protection est toujours active. Les plans MurmurHost incluent cela par défaut ; la page de fonctionnalités DDoS protection documente la capacité par niveau.
Quelle capacité est suffisante ?
C'est la question que la plupart des clients posent, et la réponse est plus nuancée que ce que suggèrent les textes marketing.
Pour la plupart des projets personnels (un blog, un petit forum, une instance Mastodon de loisir), 10 Gbps de nettoyage est suffisant. Les attaques ciblant les projets personnels sont généralement opportunistes — niveau script-kiddie, sous 10 Gbps, durant de quelques minutes à quelques heures. Nos plans d'entrée de gamme VPS-1 et VPS-2 incluent 10 Gbps de nettoyage et cela a couvert toutes les attaques que nous avons vues contre les clients de projets personnels l'année dernière.
Pour les opérations commerciales modestes (une boutique e-commerce de niche, un petit SaaS, un forum actif), 50 à 100 Gbps est le bon niveau. Les attaques à ce niveau sont généralement motivées — harcèlement concurrentiel, tentatives de rançon, attaques idéologiquement motivées contre des commentaires spécifiques — et elles durent parfois des heures ou des jours. Les plans de milieu de gamme VPS-4 et VPS-8 incluent 100 Gbps de nettoyage.
Pour les charges de travail à haute bande passante ou à haute cible (streaming, adulte, serveurs de jeu, nœuds de sortie VPN), 200 à 400 Gbps est approprié. Les attaques contre ces charges de travail ont tendance à être à la fois plus importantes (les marchés commerciaux de DDoS-as-a-service ciblent explicitement le streaming et l'adulte) et plus longues (soutenues sur des jours, parfois des semaines). Notre niveau dédié — DS-Mid, DS-Pro — inclut 400 Gbps de nettoyage.
Pour les charges de travail d'entreprise avec une attention adverse soutenue (attaques observées de 1+ Tbps), la pratique standard est de superposer Cloudflare ou BunnyCDN devant l'origine offshore et de s'appuyer sur la capacité d'absorption beaucoup plus grande du CDN (multi-Tbps globalement) pour la protection L3/L4. Le niveau gratuit de Cloudflare inclut une protection utile ; les niveaux payants ajoutent des capacités WAF et de gestion des bots. Nous soutenons explicitement ce modèle — voir notre page de fonctionnalités DDoS protection.
Le tableau ci-dessous résume les niveaux de protection MurmurHost :
| Niveau de plan | Nettoyage volumétrique | Application de |
|---|---|---|
| Partagé, VPS-1, VPS-2 | 10 Gbps | Personnel, loisir |
| VPS-4, VPS-8, RDP-Pro | 100 Gbps | Commercial, trafic moyen |
| VPS-16, DS-Lite | 200 Gbps | Trafic élevé |
| DS-Mid, DS-Pro, DS-Beast, plans GPU | 400 Gbps | Streaming, adulte, soutenu |
| Entreprise personnalisée | 1+ Tbps | Niveau souverain, multi-CDN |
Tactiques de périphérie — règles au niveau de l'application, limitation de débit
Le niveau de nettoyage volumétrique gère les attaques L3/L4. Les attaques au niveau de l'application nécessitent un travail d'ingénierie à votre périphérie applicative. Trois modèles comptent le plus :
Limitation de débit. Limitez les requêtes par IP, par session ou par point de terminaison. L'implémentation la plus simple est via Nginx (limit_req_zone), HAProxy, ou le middleware de votre application. Des approches plus sophistiquées — token-bucket par identité, fenêtre glissante par point de terminaison — nécessitent plus de configuration mais absorbent les attaques en rafale plus gracieusement. Le bon ratio dépend de vos modèles de trafic normaux : si votre utilisateur légitime le plus actif fait 50 requêtes par minute, fixez la limite à 200/minute, pas à 30.
Règles WAF. Un pare-feu d'application web inspecte les charges utiles des requêtes et bloque les modèles correspondant à des signatures d'attaque connues (injection SQL, XSS, empreintes de bots courantes). Le WAF de Cloudflare, modsecurity (avec l'OWASP Core Rule Set) et le WAF de BunnyCDN fonctionnent tous pour les hébergeurs offshore. Le WAF vit à votre périphérie CDN si vous en avez un, ou devant votre serveur d'application si vous n'en avez pas.
Cloudflare ou BunnyCDN devant. Au-delà du WAF, un CDN absorbe l'attaque à une couche qui évolue beaucoup plus loin que n'importe quelle origine unique. Cloudflare en particulier a été la pratique standard dans l'hébergement offshore pendant une décennie — il fonctionne bien devant une origine aux Pays-Bas ou en Islande, et le niveau gratuit fournit une protection significative à lui seul. Nous documentons la configuration canonique Cloudflare-plus-origine-offshore sur notre page de fonctionnalités.
Tarpitting et mécanismes de défi
Pour les attaques L7 soutenues à faible volume (bots sophistiqués, scrapers, prises de contrôle de compte scriptées), les mécanismes de défi explicites deviennent utiles.
Défi JS. Le mode « I'm Under Attack » de Cloudflare et les fonctionnalités similaires injectent un petit défi JavaScript que les navigateurs légitimes passent automatiquement ; les bots qui n'exécutent pas JS sont filtrés. Bon marché, efficace, transparent pour les utilisateurs légitimes.
Portails CAPTCHA. Lorsque le défi JS est insuffisant, un véritable CAPTCHA sur les points de terminaison suspects filtre les humains des bots avancés. Le coût de friction est réel — les taux d'abandon augmentent — donc utilisez-le avec parcimonie et uniquement sur les points de terminaison sous attaque soutenue.
Défis de preuve de travail. mCaptcha, Anubis et des outils similaires exigent que le client calcule une petite preuve de travail avant que la requête ne soit traitée. Le coût économique pour l'attaquant évolue linéairement avec le taux d'attaque ; le coût pour un utilisateur légitime est invisible (quelques centaines de millisecondes au pire). Ce modèle a gagné du terrain en 2025-2026 spécifiquement contre le scraping IA et les campagnes de bourrage d'identifiants.
Tarpitting. Ralentir les réponses au trafic suspect sans les rejeter explicitement. Efficace contre les bots simples qui maintiennent les connexions ouvertes jusqu'à ce qu'ils obtiennent une réponse ; moins efficace contre les outils d'attaque modernes qui expirent et passent à autre chose.
Économie du DDoS : qui paie pour quoi
L'économie de la protection DDoS est généralement opaque pour les clients. En gros :
- La capacité de nettoyage volumétrique est la couche la plus chère pour l'hébergeur. Un niveau de nettoyage de 10 Gbps à l'échelle coûte au fournisseur environ 0,01 à 0,10 $ par Go protégé de trafic d'attaque, ce qui représente des frais généraux non négligeables pour les charges de travail à haute cible. La plupart des fournisseurs incluent un niveau de base dans le prix du plan et facturent la capacité « premium » au-delà.
- Le peering anycast est modérément cher — vous avez besoin d'espace dans plusieurs points d'échange Internet. C'est surtout un coût fixe.
- Les règles WAF et la protection L7 sont bon marché par rapport au nettoyage — la plupart du coût réside dans la maintenance de l'ensemble de règles, pas dans le CPU.
MurmurHost inclut le niveau de base complet sur chaque plan. Le nettoyage premium (au-dessus de la capacité du niveau de plan, pour les attaques soutenues de 1+ Tbps) est une conversation de mise à niveau au niveau entreprise, pas une facturation par attaque. Nous ne facturons pas par volume d'attaque ; les attaques soutenues au-dessus de la capacité du plan déclenchent une conversation côté client sur la mise à niveau du niveau de plan, pas une facture surprise.
Ce que vous pouvez faire au niveau de l'application
La protection DDoS la plus efficace est de ne pas être une cible, et la deuxième plus efficace est de garder votre application peu coûteuse à servir. Leviers spécifiques :
Mettez en cache agressivement. Le contenu statique servi depuis un CDN (ou même depuis Nginx local avec une directive de cache) ne coûte rien à l'origine. Le contenu dynamique mis en cache pour de courtes fenêtres (5 à 60 secondes pour la plupart des pages) absorbe les pics de trafic sans nécessiter un traitement complet de l'origine.
Rendez les points de terminaison dynamiques peu coûteux. Une requête qui accède à la base de données à chaque chargement de page est beaucoup plus vulnérable qu'une requête qui accède à Redis. Poussez les calculs coûteux vers des travailleurs en arrière-plan, renvoyez des données mises en cache ou éventuellement cohérentes sur le chemin de la requête.
Définissez des budgets de requêtes. Les API GraphQL sont particulièrement vulnérables aux attaques d'amplification — une seule requête d'attaquant peut déclencher des milliers de requêtes de base de données. Définissez des limites de profondeur de requête, des limites de complexité de requête et des budgets de requêtes par IP.
Séparez les chemins de lecture et d'écriture. Le trafic à forte lecture ne devrait jamais rivaliser avec le trafic à forte écriture pour le même pool de connexions de base de données. Les réplicas de lecture gèrent les attaques de lecture avec grâce ; les attaques d'écriture sont de plus petit volume et plus faciles à limiter en débit.
Surveillez et alertez. Une attaque de 10 minutes que vous ne remarquez pas est en grande partie un non-événement. Une attaque de 10 minutes que vous remarquez vous donne le temps d'activer les protections (basculer le mode I'm-Under-Attack de Cloudflare, déployer des règles WAF d'urgence, contacter le support). Même une surveillance de base (charge du serveur, taux de requêtes, taux d'erreurs 5xx) est suffisante pour la première réponse.
Plans avec protection DDoS intégrée
Plans MurmurHost sélectionnés, triés par cas d'usage typique :
- Projets personnels, loisir : VPS-1 (8 $/mois, 10 Gbps), Shared Pro (7,99 $/mois, 10 Gbps).
- Petite entreprise commerciale : VPS-2 (16 $/mois, 10 Gbps), VPS-4 (32 $/mois, 100 Gbps).
- Streaming, adulte, seedboxes : VPS-8 (64 $/mois, 100 Gbps), Stream-1 (niveau haute bande passante).
- Serveurs de jeu : Game-M (filtres UDP de qualité jeu), Game-L.
- Dédié soutenu à haute cible : DS-Mid (149 $/mois, 400 Gbps), DS-Pro, DS-Beast.
- Inférence GPU et ML : GPU-Pro, GPU-Beast — protégés par 400 Gbps de nettoyage comme le dédié.
Le menu complet se trouve à /pricing et la répartition par fonctionnalité à /features/ddos-protection.
Conclusion
La protection DDoS est un problème résolu au niveau volumétrique — chaque hébergeur offshore crédible en 2026 inclut une capacité de nettoyage substantielle par défaut. Le travail restant se situe au niveau de l'application, où la mise en cache bon marché, la limitation de débit, les budgets de requêtes et la surveillance de base ferment la plupart de la surface résiduelle. Le bon niveau de plan est déterminé par votre cas d'usage plus que par des prédictions de taille d'attaque : les projets personnels ont besoin de 10 Gbps, le commercial à trafic moyen a besoin de 100 Gbps, et les charges de travail à haute cible ont besoin de 400 Gbps avec Cloudflare devant. Choisissez le niveau qui correspond à votre charge de travail à partir de la page de tarification, et associez-le à une ingénierie au niveau de l'application sensée. Pour les modèles de menace qui le justifient, la page de fonctionnalités DDoS protection couvre la capacité par niveau en détail.