Attaques de couche 3, couche 4 et couche 7
Les attaques de couche 3 ciblent la couche réseau (IP, ICMP) — exemples : flood ICMP et attaques par fragmentation IP. Les attaques de couche 4 ciblent la couche transport (TCP, UDP) — exemples : SYN flood, amplification UDP et amplification DNS. Les attaques de couche 7 ciblent la couche applicative (HTTP, HTTPS) — exemples : floods GET/POST HTTP et Slowloris. Chaque couche nécessite une atténuation différente.
Les attaques volumétriques aux couches 3 et 4 cherchent à saturer le tuyau réseau lui-même. Les plus grandes attaques publiquement divulguées ont franchi le seuil de plusieurs térabits par seconde — Cloudflare a indiqué avoir atténué une attaque de 7,3 Tbps en mai 2025, et AWS Shield a signalé une attaque de 2,3 Tbps dès février 2020. Ces attaques fonctionnent parce que les protocoles d'amplification (DNS, NTP, memcached, CLDAP) permettent à une petite requête falsifiée de déclencher une réponse beaucoup plus grande envoyée à la victime — des facteurs d'amplification de 50x pour DNS, 200x pour NTP et 50 000x pour memcached ont été documentés. Les attaques protocolaires de couche 4 — SYN floods, ACK floods, attaques par paquets fragmentés — épuisent l'état de suivi de connexion sur les pare-feu et les répartiteurs de charge plutôt que la bande passante. Les attaques de couche 7 sont les plus petites en octets mais les plus difficiles à filtrer : un flood HTTP issu d'un botnet de 100 000 nœuds ressemble bit pour bit à de vrais utilisateurs, et seule une logique applicative peut faire la différence.
Blackhole BGP et remote-triggered black hole (RTBH)
Le blackholing BGP est l'atténuation brutale mais efficace de dernier recours : l'opérateur réseau annonce une route /32 pour l'IP attaquée dans une communauté BGP « blackhole » spéciale, demandant à tous les pairs en amont de jeter entièrement le trafic vers cette IP. La cible reste hors ligne, mais le reste du réseau reste en service. Le RTBH est standardisé dans la RFC 5635 et pris en charge par tous les opérateurs Tier 1.
Le RTBH est documenté dans la RFC 5635 (août 2009) et fonctionne en marquant une route avec un attribut de communauté que les pairs en amont interprètent comme « jeter tout le trafic destiné à ce préfixe ». L'atténuation est totale — l'IP protégée devient inaccessible depuis tout l'internet, y compris pour les utilisateurs légitimes — mais elle protège le reste de la flotte client des dommages collatéraux. En raison de son caractère brut, le RTBH est approprié quand une seule IP est saturée par une attaque de plusieurs centaines de gigabits et que le coût d'une panne plus large l'emporte sur le maintien en ligne de cette IP. Beaucoup de forfaits VPS « protégés DDoS » bas de gamme signifient exactement cela : le fournisseur null-routera votre IP sous attaque pour préserver le reste de sa flotte. C'est de la mitigation par définition, mais la ressource protégée est le réseau du fournisseur, pas le vôtre.
Centres de scrubbing et déviation de trafic
Un centre de scrubbing est un site réseau durci où le trafic d'attaque est filtré et le trafic propre est transféré vers l'origine. Le trafic y est dévié via une annonce BGP (always-on ou à la demande) ou un pointage DNS. La capacité de scrubbing par Tbps est l'indicateur phare — les plus grands fournisseurs exploitent plus de 200 Tbps cumulés, tandis que les hébergeurs spécialisés annoncent typiquement 1 à 10 Tbps.
Les centres de scrubbing utilisent des appliances spécialisées — Arbor TMS, Radware DefensePro, A10 Thunder, NSFOCUS ADS ou de gros pipelines Linux/DPDK sur mesure — qui inspectent chaque paquet, classent les motifs bénins et malveillants et ne transfèrent que la fraction propre vers l'origine. La déviation se fait généralement par BGP : le préfixe du client est annoncé depuis le réseau anycast du fournisseur de scrubbing pendant l'attaque, aspirant tout le trafic vers le site de scrubbing le plus proche. Après nettoyage, le trafic est tunnelisé (GRE, IPSec, cross-connect dédié ou peering direct) jusqu'au serveur d'origine. La latence ajoutée par le scrubbing est typiquement de 1 à 3 ms en région, plus le supplément lié à la déviation. Le scrubbing always-on rend la déviation permanente, supprimant le délai de démarrage de la mitigation au prix d'une légère taxe de latence constante. Le scrubbing à la demande ne dévie qu'en cas d'attaque détectée, ce qui coûte moins cher mais introduit une fenêtre d'activation de 30 à 180 secondes pendant laquelle l'attaque atterrit.
Atténuation always-on vs à la demande
L'atténuation always-on route tout le trafic à travers la couche de scrubbing 24h/24 et 7j/7 — aucun délai d'activation, mais chaque paquet paie une petite taxe de latence (1 à 5 ms typiques). L'atténuation à la demande ne s'active que lorsqu'une attaque est détectée, supprimant la latence en régime permanent mais exposant l'origine pendant la fenêtre d'activation (typiquement 30 à 180 secondes). Les configurations hybrides combinent les deux : always-on pour HTTP/HTTPS, à la demande pour le trafic IP brut.
Choisir entre always-on et à la demande est un compromis entre la latence en régime permanent et la vulnérabilité dans la fenêtre d'attaque. Les services sensibles à la latence — serveurs de jeu multijoueurs, trading à faible latence, voix/vidéo — choisissent généralement la mise à la demande et acceptent l'écart d'activation parce que chaque milliseconde de RTT en régime permanent leur coûte. Les services web grand public, les API et les SaaS choisissent généralement le always-on ou une topologie entièrement proxifiée de type CDN où l'IP d'origine n'est même pas publique, supprimant entièrement la fenêtre d'attaque. Les fournisseurs de bordure cloud modernes (Cloudflare, Fastly, AWS Shield Advanced, Google Cloud Armor) penchent par défaut vers le always-on parce que leur réseau termine déjà le trafic dans des centaines de PoP de bordure et le « détour » est essentiellement nul.
Limitation de débit, WAF et défense applicative
La limitation de débit plafonne le nombre de requêtes par IP source, par session ou par URL, atténuant les floods de couche 7 sans affecter le trafic légitime. Un Web Application Firewall (WAF) inspecte les requêtes HTTP par rapport à des règles — protections OWASP Top 10, règles de débit personnalisées, géoblocage, défis JS et CAPTCHA. Ensemble, ils traitent les attaques de couche 7 que le scrubbing volumétrique seul ne peut pas gérer.
Le scrubbing volumétrique s'arrête à la frontière IP-port. Pour stopper un flood HTTP qui ressemble à du vrai trafic Chrome, il faut des règles qui opèrent sur les URL, les en-têtes, les cookies et le comportement. La limitation de débit est le contrôle de couche 7 le plus simple et le plus efficace : plafonnez une seule IP à, par exemple, 60 requêtes par minute sur /login et jetez le reste. Un WAF va plus loin avec des règles sensibles au contenu : blocage des requêtes avec motifs d'injection SQL, user agents anormaux, referrers manquants, origines géographiques en dehors de votre zone de service ou tailles de payload bien hors plage. Les WAF modernes (AWS WAF, Cloudflare WAF, Fastly Next-Gen WAF, ModSecurity avec l'OWASP Core Rule Set) exécutent aussi des défis JavaScript, hCaptcha et des heuristiques d'empreinte de bot qui font chuter de plus de 99 % le taux de succès d'un botnet sans gêner les vrais navigateurs.
Ce que les hébergeurs incluent généralement vs facturent en supplément
Les paliers gratuits ou inclus couvrent généralement les attaques volumétriques de couches 3-4 jusqu'à un plafond fixe en gigabits par seconde (souvent 10 à 100 Gbps) avec une limitation de débit basique et le blackhole BGP. Les options payantes incluent typiquement le scrubbing always-on, le WAF, l'atténuation de couche 7, l'écriture de règles personnalisées et des garanties de mitigation soutenues par un SLA. Lisez le contrat — « protection DDoS illimitée » signifie souvent « nous vous null-routerons au-delà de X Gbps ».
Le marketing DDoS des hébergeurs varie énormément. Une protection vraiment utile inclut trois éléments : (1) une capacité clairement annoncée en Gbps ou Tbps, (2) une couverture des couches 3 à 7, dont l'atténuation des floods HTTP, et (3) un SLA écrit avec un délai de démarrage de la mitigation et des engagements sur la perte de trafic. Une protection moins utile est un simple badge « DDoS protected » sans chiffre de capacité, ce qui veut dire généralement « blackhole BGP uniquement » — votre IP est null-routée sous attaque et vous êtes hors ligne pendant toute la durée. Lors de l'évaluation, demandez : quelle est la capacité annoncée par IP ? Always-on ou à la demande ? La couche 7 est-elle couverte ? Quel est le SLA sur le délai d'activation ? Que se passe-t-il si l'attaque dépasse le plafond du palier ? Les réponses indiquent si vous achetez une vraie protection ou un simple label marketing.