La protection DDoS d'un site web se joue à deux niveaux distincts, rarement présentés ensemble avec précision : le trafic volumétrique qui sature un lien réseau avant même d'atteindre le serveur, et le trafic applicatif qui inonde une page précise avec des requêtes qui ressemblent, une par une, à un visiteur normal. La confusion entre ces deux familles explique l'essentiel des malentendus sur ce qu'une offre d'hébergement couvre réellement. Ce guide distingue les attaques L3/L4 (réseau/transport) des attaques L7 (applicatif), détaille ce qu'un hébergeur bloque en amont — avec la capacité de scrubbing et le retour terrain de l'infrastructure Tomco — et ce qui reste à la charge du site : rate limiting, pare-feu applicatif, CAPTCHA. Les solutions gratuites sont passées au crible sur leur couverture réelle, pas perçue.
À retenir
- Les attaques L3/L4 (volumétriques) saturent la bande passante ou les ressources réseau ; seul un hébergeur peut les absorber, via du scrubbing en amont.
- Les attaques L7 (applicatives) ciblent un endpoint précis (
wp-login.php, recherche, formulaire) avec un trafic indiscernable d'un visiteur légitime — leur mitigation fine reste à la charge du site.- Tomco filtre jusqu'à 3 Tbps de trafic volumétrique en amont, avant qu'il n'atteigne l'infrastructure d'hébergement.
- Les solutions anti-DDoS gratuites couvrent presque toujours le L3/L4 ; la protection L7 avancée (règles WAF fines, CAPTCHA géré, rate limiting par endpoint) reste une fonctionnalité payante ou absente.
- Une défense efficace empile quatre couches : hébergeur (réseau), WAF (applicatif générique), rate limiting (applicatif spécifique au site), monitoring (détection).
Sommaire
- Panorama des attaques DDoS en 2026
- Attaques volumétriques L3/L4
- Attaques applicatives L7
- Ce qu'un hébergeur fait réellement
- Ce qu'un hébergeur ne fait pas
- Solutions gratuites et leurs limites
- Construire une défense en couches
- Questions fréquentes
L'essentiel en un coup d'œil
| Question | Réponse courte |
|---|---|
| Différence L3/L4 vs L7 ? | L3/L4 sature le réseau (volumétrique) ; L7 cible une page précise avec un trafic qui ressemble à un visiteur réel |
| Que bloque l'hébergeur ? | Le trafic volumétrique L3/L4, en amont, par scrubbing réseau — jusqu'à 3 Tbps chez Tomco |
| Que reste-t-il à la charge du site ? | Le L7 fin : rate limiting par endpoint, règles WAF spécifiques, CAPTCHA |
| Une solution gratuite suffit-elle ? | Pour le L3/L4 dans la plupart des cas ; la protection L7 avancée y est rarement incluse |
| WordPress est-il une cible privilégiée ? | Oui sur des points précis : wp-login.php, recherche interne, formulaires sans limitation |
Panorama des attaques DDoS en 2026
Une attaque par déni de service distribué (DDoS) vise à rendre un service indisponible en épuisant l'une de ses ressources : bande passante réseau, table de connexions, ou capacité de calcul applicative. La classification par couche du modèle OSI reste la plus opérante pour choisir la bonne défense : couche 3 (réseau, IP), couche 4 (transport, TCP/UDP) et couche 7 (application, HTTP) — une segmentation que l'OWASP reprend en distinguant surface réseau, session et application. Les attaques L3/L4 sont volumétriques et brutes ; les attaques L7 sont ciblées et discrètes.
La tendance de fond depuis plusieurs années tient à l'accessibilité des outils d'attaque : des services de déni de service à la demande (« booters » ou « stressers ») se louent en ligne pour un coût modique, ce que confirme l'ANSSI dans ses publications sur la menace DDoS. La conséquence directe : la cible n'a plus besoin d'être stratégique pour être touchée, un concurrent mécontent ou un différend commercial suffisent à déclencher une attaque. Deuxième tendance, les attaques multi-vecteurs combinent désormais un bruit volumétrique L3/L4 en façade avec une tentative d'exploitation L7 plus discrète menée en parallèle, pariant sur le fait que les équipes de supervision concentrent leur attention sur le pic de trafic visible.
| Couche | Cible | Exemple de vecteur | Échelle typique |
|---|---|---|---|
| L3 — Réseau | Bande passante, routeurs | Flood ICMP, amplification | Gb/s à Tb/s |
| L4 — Transport | Table de connexions TCP/UDP | SYN flood, UDP flood | Gb/s à Tb/s |
| L7 — Application | Endpoint applicatif (PHP, DB) | HTTP flood ciblé (login, recherche) | Requêtes/s, volume faible |
Attaques volumétriques L3/L4
Une attaque volumétrique cherche à saturer la capacité brute d'un lien réseau ou d'un équipement, sans se préoccuper de l'application hébergée derrière. Trois familles dominent. Le UDP flood envoie un volume massif de paquets UDP vers des ports aléatoires ou fixes, forçant la cible à répondre par des messages d'erreur ICMP jusqu'à épuisement. Le SYN flood exploite la poignée de main TCP à trois temps : l'attaquant envoie des paquets SYN en masse sans jamais compléter la connexion, saturant la table des connexions semi-ouvertes du serveur ou du pare-feu.
Les attaques par amplification (DNS, NTP, memcached) sont les plus efficaces en rapport effort/impact. L'attaquant envoie une petite requête à un serveur ouvert (résolveur DNS public mal configuré, serveur NTP) en usurpant l'adresse IP de la victime : le serveur répond par un message bien plus volumineux, directement à la cible. Un facteur d'amplification de 50 à 100 n'est pas rare sur certains protocoles DNS, ce qui signifie qu'un attaquant disposant d'1 Gb/s de bande passante peut générer 50 à 100 Gb/s dirigés vers la victime.
L'usurpation d'adresse IP source (IP spoofing) est la brique technique commune à la majorité des attaques par amplification. La contre-mesure de référence côté opérateurs réseau est décrite depuis 2000 dans la RFC 2827 (BCP 38) : filtrer en sortie de réseau tout paquet dont l'adresse source ne correspond pas à une plage légitimement annoncée. Sa mise en œuvre reste inégale d'un opérateur à l'autre à l'échelle mondiale, ce qui explique la persistance des attaques par amplification près de vingt-cinq ans après sa publication.
Attaques applicatives L7
Une attaque L7 ne cherche pas à saturer un lien réseau : elle vise un point de l'application dont le traitement coûte cher en ressources serveur, avec un volume de requêtes qui peut rester modeste. Sur un site WordPress, trois cibles reviennent systématiquement. Le formulaire /wp-login.php déclenche à chaque tentative un calcul de hachage de mot de passe coûteux en CPU — quelques centaines de requêtes par seconde suffisent à saturer un pool PHP-FPM dimensionné pour un trafic normal, un vecteur déjà documenté comme le premier bloqué par le WAF Tomco dans le guide sécuriser WordPress en 2026. La recherche interne déclenche des requêtes SQL potentiellement non indexées sur de gros catalogues, coûteuses à répéter en masse. Les formulaires de contact ou de commentaire, enfin, peuvent déclencher des envois d'e-mail ou des écritures en base à chaque soumission.
La difficulté de détection tient à l'indiscernabilité : une requête HTTP vers /wp-login.php avec un user-agent de navigateur standard, un en-tête Referer cohérent et un cookie de session valide n'a, prise isolément, rien d'anormal. Ce n'est que la fréquence, la concentration géographique ou temporelle, ou l'absence des requêtes annexes qu'un vrai navigateur générerait (chargement du CSS, des images, des scripts) qui révèle le pattern d'attaque. Les botnets modernes s'appuient de plus en plus sur des adresses IP résidentielles compromises plutôt que sur des datacenters, ce qui complique encore le filtrage par réputation d'IP.
Ce qu'un hébergeur fait réellement
La défense contre le volumétrique L3/L4 se joue nécessairement en amont, au niveau du réseau, avant que le trafic n'atteigne le serveur d'origine. Le principe technique s'appelle le scrubbing : le trafic entrant est redirigé, via annonce BGP anycast, vers des centres de nettoyage répartis sur plusieurs points de présence. Ces centres inspectent le trafic en temps réel, éliminent les paquets illégitimes (signatures de flood connues, paquets malformés, sources usurpées) et ne laissent transiter vers l'origine que le trafic jugé légitime.
La capacité d'absorption de ce scrubbing est le chiffre qui distingue le plus nettement les offres entre elles : il conditionne directement la taille d'attaque qu'un hébergeur peut neutraliser sans dégradation de service. L'infrastructure Tomco filtre jusqu'à 3 Tbps de trafic volumétrique en amont — une capacité à vérifier au moment de la lecture sur la page technologies, ce chiffre évoluant avec les investissements réseau. Sur l'ensemble du parc, le support Tomco observe plusieurs dizaines de tentatives d'attaques volumétriques par mois, la grande majorité durant moins d'un quart d'heure et n'approchant pas la capacité de scrubbing disponible. Un cas représentatif : une attaque par amplification DNS mesurée à plus de 200 Gb/s en pointe a été absorbée intégralement par le scrubbing en périphérie, sans dégradation de latence perceptible côté client ni ouverture de ticket support pour rétablir l'accès. Sur des infrastructures dimensionnées pour de la haute performance, comme les serveurs dédiés Tomco, cette protection anti-DDoS multicouche est incluse par défaut, sans configuration additionnelle côté client.
Ce qu'un hébergeur ne fait pas
Aucun hébergeur ne peut filtrer, au niveau réseau, une attaque L7 fine dont chaque requête individuelle est légitime en apparence. Filtrer à ce niveau nécessiterait de comprendre la logique métier de chaque application hébergée — ce qui casserait le modèle même de la mutualisation d'infrastructure. Cette couche de mitigation applicative reste donc la responsabilité du site : configuration du pare-feu applicatif, rate limiting par endpoint, et déploiement d'un CAPTCHA sur les points d'entrée sensibles.
Un rate limiting appliqué au niveau du serveur web limite le nombre de requêtes qu'une même adresse IP peut envoyer vers un endpoint donné sur une fenêtre de temps :
# Limiter les requêtes vers un endpoint sensible (wp-login.php, recherche)
limit_req_zone $binary_remote_addr zone=sensitive_endpoint:10m rate=10r/m;
server {
location = /wp-login.php {
limit_req zone=sensitive_endpoint burst=5 nodelay;
limit_req_status 429;
}
}Au niveau du pare-feu applicatif (WAF), une règle de comptage par adresse IP détecte un rythme de requêtes anormal sur un endpoint coûteux et bloque au-delà d'un seuil :
# ModSecurity : limiter les requêtes répétées vers un endpoint coûteux
SecAction "id:1005030,phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},\
setvar:ip.request_count=+1,expirevar:ip.request_count=60"
SecRule IP:REQUEST_COUNT "@gt 60" \
"id:1005031,phase:1,deny,status:429,t:none,\
msg:'Rate limit exceeded on sensitive endpoint (possible L7 flood)'"Le guide de sécurisation WordPress détaille la limitation des tentatives de connexion et le durcissement complémentaire de la couche accès — deux mesures directement complémentaires du rate limiting réseau contre les attaques L7 ciblant le formulaire de login.
Solutions gratuites et leurs limites
Les offres gratuites de protection réseau (proxy inverse, CDN en niveau gratuit) couvrent efficacement le L3/L4, pour une raison structurelle : cette couche ne nécessite aucune connaissance de l'application hébergée. Un proxy anycast absorbe un flood UDP ou un SYN flood de la même manière, quel que soit le site derrière — la mutualisation à grande échelle rend cette protection économiquement viable à distribuer gratuitement.
La protection L7 avancée suit une logique inverse : elle nécessite un réglage fin par application (quels endpoints protéger, quels seuils, quelles règles de détection comportementale), un CAPTCHA géré avec des pages de challenge maintenues, et dans la plupart des cas une analyse de trafic en temps réel avec apprentissage. Ce travail de configuration et de maintenance a un coût que les offres gratuites ne couvrent, dans la plupart des cas, que partiellement ou pas du tout — la couverture réelle est nettement plus étroite que la couverture perçue par un site qui affiche simplement le badge du fournisseur.
Deux limites factuelles s'ajoutent, indépendamment du niveau de protection choisi. D'abord, l'exposition de l'adresse IP d'origine : si le serveur répond directement à certaines requêtes (mail, API tierce, ancien enregistrement DNS non nettoyé), l'adresse réelle peut fuiter et permettre à un attaquant de contourner totalement le proxy en frappant directement l'origine. Ensuite, une dépendance de configuration : la protection ne fonctionne que si l'intégralité du trafic transite par le proxy — tout sous-domaine ou service oublié dans la configuration DNS reste exposé sans aucune protection, gratuite ou payante.
Construire une défense en couches
Une protection DDoS efficace n'est jamais une couche unique : elle empile quatre niveaux complémentaires, chacun couvrant un angle que les autres ne couvrent pas.
La première couche, réseau, relève de l'hébergement web : scrubbing volumétrique en amont, absorption du L3/L4 avant que le trafic n'atteigne l'infrastructure. La deuxième couche, pare-feu applicatif générique (WAF), filtre les patterns d'attaque HTTP connus — injections, scans, signatures de bots identifiées — avant que la requête n'atteigne le code applicatif. La troisième couche, spécifique au site, ajuste le rate limiting et les règles CAPTCHA aux endpoints réellement sensibles de l'application : login, recherche, formulaires. La quatrième couche, le monitoring, détecte les anomalies de trafic en temps réel et déclenche l'alerte avant qu'un pic ne devienne un incident.
Cette répartition des responsabilités, entre l'infrastructure réseau Tomco en amont et la configuration applicative du site, reste le point le plus mal compris lors du choix d'un hébergeur : la capacité de scrubbing annoncée protège contre le volumétrique, mais ne dispense jamais de durcir la couche applicative propre au site.
Chaque couche neutralise une classe d'attaque différente, et aucune n'est suffisante seule — un pic volumétrique absorbé au réseau n'empêche pas une attaque L7 discrète menée en parallèle, exactement le scénario que la vigilance opérationnelle doit couvrir en continu.
