Un script de 50 lignes peut saturer votre lien 10 Gbps — voici comment survivre à une attaque DDoS

En janvier 2025, un adolescent armé d’un script Python de 47 lignes a saturé le lien 10 Gbps d’un hébergeur français pendant six heures. En mars 2026, Cloudflare a mitigé une attaque volumétrique de 5,6 Tbps — la plus grosse jamais enregistrée — en moins de trois secondes sur son réseau mondial de 330 datacenters. Ces deux événements ne sont pas contradictoires : ils illustrent l’écart entre une cible nue et une cible protégée.

Une attaque par déni de service distribué (DDoS) n’exploite pas une vulnérabilité logicielle. Elle exploite une asymétrie : le coût de génération du trafic est proche de zéro, le coût d’absorption est immense. Un botnet loué 5 dollars de l’heure peut générer assez de paquets pour noyer un serveur mal protégé. La bonne nouvelle, c’est que la défense a rattrapé l’attaque — si vous savez sur quel levier appuyer.

Les deux familles d’attaques DDoS : comprendre avant de se défendre

Toutes les attaques DDoS ne se ressemblent pas. Les classer par couche OSI permet de choisir la bonne parade. On distingue deux grandes familles.

Attaques infrastructure (L3/L4) : le bombardement volumétrique

Les attaques de couche 3 (réseau) et couche 4 (transport) visent à saturer la bande passante ou les tables d’état de la pile TCP/IP. Ce sont les plus communes — Cloudflare estime qu’elles représentent plus de 80 % des attaques DDoS observées en 2025 — et les plus faciles à lancer.

Amplification DNS. Un attaquant envoie une requête DNS de 60 octets à un résolveur ouvert en usurpant l’IP source de la victime. Le résolveur répond avec un paquet de 3 000 à 4 000 octets — un facteur d’amplification de 50× à 70×. NTP, Memcached et CLDAP suivent le même principe avec des amplifications pouvant atteindre 51 000× pour Memcached. Le trafic entrant sature le lien réseau avant même que le serveur ait traité un seul paquet valide.

SYN flood. L’attaquant envoie un flot de paquets TCP SYN sans jamais compléter le handshake (pas de ACK). Chaque SYN entrant consomme une entrée dans la table de connexions du noyau. Quand la table est pleine, le serveur refuse les connexions légitimes. Une machine moderne peut générer 10 millions de SYN par seconde avec un outil comme hping3 — largement de quoi noyer un serveur non protégé.

UDP flood. L’attaquant bombarde un port aléatoire avec des paquets UDP. Le serveur répond par un paquet ICMP « port unreachable » pour chaque paquet reçu, doublant la charge CPU et réseau. Aucune amplification n’est nécessaire : un simple VPS à 3 €/mois peut générer 1 Gbps de trafic UDP en continu.

Le point commun de ces attaques : elles ne regardent jamais le contenu applicatif. Le volume est la seule arme. La parade se joue donc avant que les paquets n’atteignent votre serveur.

Attaques applicatives (L7) : l’épuisement chirurgical

Les attaques de couche 7 (application) visent les ressources du serveur applicatif — CPU, mémoire, connexions à la base de données — avec un trafic parfaitement conforme au protocole HTTP. Elles représentent moins de 20 % des attaques mais sont nettement plus difficiles à détecter, car chaque requête semble légitime.

HTTP flood. L’attaquant envoie des requêtes GET ou POST vers une page coûteuse — /search?q=aaaaaaaa, /login, un endpoint d’API qui déclenche une jointure SQL lourde. Chaque requête consomme 10 à 100× plus de ressources serveur qu’une requête vers une page statique. Un millier de requêtes par seconde bien ciblées peuvent épuiser un backend qui servirait sans broncher 100 000 requêtes par seconde de contenu statique.

Slowloris. L’outil le plus minimaliste qui soit. Il ouvre des connexions HTTP et envoie des en-têtes… partiels, un caractère à la fois, sans jamais terminer la requête. Le serveur garde chaque connexion ouverte en attendant la suite. Avec Apache prefork, chaque connexion bloquée consomme un processus complet : quelques centaines de connexions suffisent à épuiser le pool de workers. La charge réseau est nulle ; l’effet est total.

R.U.D.Y. (R-U-Dead-Yet). Variante de Slowloris qui cible les formulaires POST : l’attaquant soumet un champ de formulaire octet par octet, maintenant la connexion ouverte indéfiniment. Un outil comme OWASP HTTP Post Tool automatise le processus.

Ces attaques ne peuvent pas être bloquées au niveau réseau — il faut les détecter au niveau applicatif, ce qui exige une inspection du protocole HTTP et une compréhension du comportement normal de l’application.

Pourquoi un script de 50 lignes suffit

Le mythe du « hacker dans un sous-sol avec des supercalculateurs » est mort depuis longtemps. Aujourd’hui, lancer une attaque DDoS tient en trois étapes accessibles à n’importe quel étudiant en informatique.

D’abord, trouver un vecteur d’amplification. Des services comme Shodan recensent en permanence des millions de résolveurs DNS ouverts, de serveurs Memcached exposés et de services CLDAP non filtrés. Une requête port:11211 country:FR sur Shodan suffit à trouver des centaines de cibles Memcached exploitables.

Ensuite, écrire le script. Voici un exemple fonctionnel d’amplification DNS en Python — le code tient en 30 lignes :

import socket
import struct

TARGET = "203.0.113.10"  # IP de la victime
RESOLVERS = ["8.8.8.8", "1.1.1.1", "9.9.9.9"]  # Résolveurs ouverts

# Requête DNS ANY pour un domaine avec une grosse zone
query = b"\xaa\xbb\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00"
query += b"\x07example\x03com\x00"  # exemple.com
query += b"\x00\xff\x00\x01"        # Type ANY

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
for resolver in RESOLVERS:
    sock.sendto(query, (resolver, 53))

Le principe est élémentaire : on usurpe l’IP source (via un VPS qui ne filtre pas le spoofing, ou un réseau compromis), on envoie une requête DNS ANY de 50 octets, et le résolveur répond avec la zone DNS complète — parfois 4 000 octets — directement vers la victime. Répétez ce processus sur 100 résolveurs ouverts avec une boucle while True, et vous générez plusieurs gigabits par seconde depuis un seul VPS.

Enfin, louer la puissance de feu. Si écrire le script est trop fastidieux, des services de stresser (illégaux mais omniprésents) proposent des attaques clé en main pour 5 à 50 dollars. Un rapport de Cloudflare de décembre 2025 note que 60 % des attaques DDoS observées proviennent de services de stresser commercialisés comme des « testeurs de réseau ».

Le résultat : votre lien 10 Gbps est saturé. Votre serveur ne répond plus. Vos clients voient une page blanche. Et tout ça pour le prix d’un sandwich.

La pyramide de défense DDoS : quatre couches, zéro raccourci

Il n’existe pas de solution unique contre les DDoS. La défense est une pyramide à quatre étages, chaque étage bloquant des attaques que l’étage inférieur ne peut pas voir.

Couche 1 : BGP blackholing et scrubbing centers

Le BGP blackholing (RFC 3882, RTBH) est la méthode la plus brutale et la plus efficace contre les attaques volumétriques. Votre FAI ou votre fournisseur de transit annonce une route vers votre préfixe IP avec une communauté BGP qui redirige tout le trafic vers un null interface — une poubelle. Résultat : l’attaque disparaît, mais votre service aussi pour le trafic entrant. C’est le bouton rouge : efficace, aveugle, à n’utiliser qu’en dernier recours.

Le scrubbing center est l’évolution intelligente du blackholing. Au lieu de jeter tout le trafic, il le redirige vers des centres de filtrage qui nettoient les paquets malveillants et renvoient le trafic légitime vers votre infrastructure via un tunnel GRE. Le temps de mitigation (TTM, Time to Mitigate) varie de quelques secondes (Cloudflare revendique moins de 3 secondes) à plusieurs minutes pour les solutions traditionnelles sur appliance.

Couche 2 : CDN et reverse proxy

Un CDN comme Cloudflare, Fastly ou Akamai absorbe les attaques L3/L4 par sa simple surface réseau. Avec 500 Tbps de capacité, Cloudflare peut encaisser une attaque 23 fois supérieure au plus gros DDoS jamais enregistré (environ 2,3 Tbps en 2024). Le trafic ne voit jamais votre serveur d’origine — le CDN fait tampon.

Fastly (qui opère sur le réseau Anycast avec plus de 80 points de présence) adopte une approche différente : son WAF nouvelle génération (Powered by Signal Sciences, acquis en 2020) combine un moteur de règles avec une analyse comportementale qui bloque les attaques L7 en se basant sur l’anomalie statistique plutôt que sur des signatures. L’argument commercial est la latence : Fastly revendique un TTFB inférieur à 30 ms en Europe, contre 40-50 ms pour Cloudflare sur le même trafic.

Un point important : un CDN seul ne protège pas vos services non-HTTP (SSH, SMTP, bases de données). Il couvre le web et les API, mais le reste de votre surface d’attaque reste exposé.

Couche 3 : WAF et rate limiting

Le Web Application Firewall (WAF) opère en couche 7. Il inspecte chaque requête HTTP et bloque celles qui correspondent à des patterns d’attaque connus — injections SQL, XSS, path traversal, mais aussi des patterns DDoS comme les rafales de requêtes vers une même URL.

Le rate limiting est sa contrepartie algorithmique. Au lieu de chercher des signatures, il fixe des seuils : maximum 100 requêtes par seconde vers /login depuis une même IP, maximum 50 connexions TCP simultanées par source, maximum 10 Mo par seconde de bande passante par client. Les implémentations vont du module ngx_http_limit_req_module de NGINX (gratuit, basique) aux solutions cloud comme Cloudflare Rate Limiting (jusqu’à 100 millions de requêtes par seconde sur le plan Enterprise).

La limite du rate limiting, c’est le faux positif. Bloquer un préfixe IP entier parce qu’il a dépassé un seuil peut exclure des utilisateurs légitimes derrière un CGNAT (Carrier-Grade NAT), très courant chez les opérateurs mobiles. Les solutions modernes utilisent des défis JavaScript (Cloudflare Challenge) ou des CAPTCHA pour distinguer un humain d’un script sans bloquer définitivement l’adresse IP.

Couche 4 : BGP-based always-on (Magic Transit, OVH Anti-DDoS)

C’est le niveau le plus avancé. Au lieu d’attendre qu’une attaque soit détectée pour rediriger le trafic vers un scrubbing center, le trafic passe en permanence par le réseau du fournisseur, qui nettoie les paquets en ligne avant de les livrer.

Cloudflare Magic Transit utilise des annonces BGP pour attirer le trafic entrant vers le datacenter Cloudflare le plus proche de l’attaquant — pas de la victime. Les paquets malveillants sont identifiés et bloqués par les 330 datacenters du réseau avant d’atteindre l’infrastructure cliente. Le trafic propre est renvoyé via des tunnels GRE ou des interconnexions privées (PNI). Cloudflare revendique un temps de mitigation sous 3 secondes et une capacité de 500 Tbps. Prix : sur devis Enterprise uniquement, typiquement à partir de quelques milliers de dollars par mois.

OVHcloud Anti-DDoS suit le même principe mais avec un positionnement différent. La protection est incluse par défaut sur tous les produits OVHcloud — du VPS à 3 €/mois au serveur Bare Metal. L’infrastructure, développée en interne, totalise 17 Tbit/s de capacité de filtrage et a fait ses preuves contre des attaques documentées jusqu’à 1,3 Tbit/s. Le système combine détection always-on, scrubbing center automatique, et un Edge Network Firewall configurable. Le défaut assumé : la mitigation est parfois plus lente que Cloudflare (le TTM n’est pas documenté publiquement), et les options de personnalisation L7 sont limitées sans souscrire à des produits complémentaires.

Cloudflare, OVH, Fastly : qui protège quoi

Ces trois acteurs ne jouent pas sur le même terrain. Le tableau ci-dessous donne les ordres de grandeur, mais le choix dépend de votre surface d’attaque.

Verdict : quelle protection pour quel profil

Le choix d’une stratégie anti-DDoS se résume à une question de surface exposée et de budget.

Vous gérez un site vitrine ou un SaaS en early stage. Activez un CDN avec WAF intégré — le plan gratuit de Cloudflare (incluant le DDoS L3/L4 illimité) suffit pour la majorité des attaques opportunistes. Ajoutez un rate limiting basique dans votre reverse proxy (NGINX limit_req_zone). Coût : zéro euro, trente minutes de configuration. C’est suffisant contre 95 % des attaques DDoS, qui sont de faible volume et non persistantes.

Vous hébergez des serveurs de jeu, des API temps réel ou des services non-HTTP. La protection CDN ne couvre pas ces protocoles. Orientez-vous vers un hébergeur qui propose une protection réseau native : OVHcloud si votre budget est serré (la protection est incluse), Cloudflare Magic Transit si vous avez besoin d’un TTM garanti et d’une capacité de plusieurs centaines de Tbps. Pour du jeu en ligne, OVH a fait ses preuves — c’est l’hébergeur historique de Minecraft, Rust et ARK: Survival Evolved, des communautés qui subissent des DDoS quotidiens.

Vous opérez une plateforme critique avec un risque médiatique ou financier élevé. La surface d’attaque nécessite les quatre couches de la pyramide. Combinez Magic Transit (L3/L4 always-on) avec un WAF comportemental (Fastly ou Cloudflare), un rate limiting granulaire, et préparez un plan de blackholing BGP avec votre FAI comme dernier recours. Budget : comptez 10 000 à 50 000 dollars par mois pour une couverture complète.

Une attaque DDoS n’est plus une fatalité technique. En 2026, avec un réseau anycast et un WAF bien configuré, le seul risque résiduel est budgétaire — et ce risque se calcule, se provisionne et s’assure.

Références

• Cloudflare Magic Transit — DDoS Protection for Networks
• OVHcloud Anti-DDoS Infrastructure
• AWS — What is a DDoS Attack?
• Cloudflare Learning Center — What is a DDoS Attack?
• RFC 3882 — Configuring BGP to Block Denial-of-Service Attacks (RTBH)
• RFC 8484 — DNS Queries over HTTPS (DoH)
• Fastly — Next-Gen WAF