Déni de service distribué : de la saturation à la mitigation

Un déni de service distribué (DDoS) rend un service indisponible en le saturant depuis un grand nombre de machines réparties sur Internet, généralement un botnet ou des serveurs tiers détournés pour amplifier le trafic. Sa particularité tient à cette dispersion : bloquer une adresse source ne sert à rien quand les paquets arrivent de 50 000 adresses différentes, ce qui déplace toute la défense en amont du serveur attaqué.

DoS et DDoS : la différence tient au nombre de sources

Un déni de service simple part d'une seule machine. Un script qui ouvre 10 000 connexions simultanées vers votre serveur web entre dans cette catégorie, et il se traite en une règle de pare-feu sur l'adresse source. L'incident dure le temps de lire les logs.

Le distribué casse ce réflexe. Le trafic vient de milliers d'hôtes qui n'ont rien en commun : objets connectés compromis, serveurs mal configurés servant de réflecteurs, machines de bureau infectées. Le botnet Mirai, dont le code source a été publié en octobre 2016, recrutait ses hôtes en testant une soixantaine de couples identifiant/mot de passe par défaut sur des caméras IP et des enregistreurs vidéo en Telnet. Aucune de ces adresses ne dépasse individuellement un débit suspect. C'est la somme qui tue.

Le terme anglais DDoS (Distributed Denial of Service) désigne exactement la même chose. Vous rencontrerez les deux dans la documentation technique et dans les contrats d'infogérance, sans nuance de sens.

Autre confusion fréquente : un DDoS n'est pas une intrusion. Il n'y a ni vol de données ni prise de contrôle du serveur visé. En revanche il sert parfois de rideau de fumée pendant qu'une autre opération se déroule sur un système voisin, ce qui justifie de continuer à surveiller les journaux d'authentification pendant l'attaque plutôt qu'après.

Trois familles d’attaques, trois points de rupture

Classer une attaque par la couche réseau qu'elle vise détermine où la traiter. Un SYN flood ne se règle pas au même endroit qu'un flood de requêtes HTTP, et confondre les deux fait perdre les premières minutes.

La famille applicative est la plus pénible parce que chaque requête est parfaitement valide. Quelques milliers de requêtes par seconde sur une URL de recherche avec des termes aléatoires contournent le cache et vont taper directement la base de données : le lien réseau reste à 3 % d'occupation pendant que le site répond en 504. La vulnérabilité HTTP/2 Rapid Reset (CVE-2023-44487) illustre le rapport de force : ouvrir un flux puis envoyer immédiatement un RST_STREAM coûte presque rien au client et beaucoup au serveur. Google a mesuré un pic à 398 millions de requêtes par seconde en août 2023, avec un botnet d'environ 20 000 machines seulement.

Famille	Exemples	Ce qui sature en premier	Unité de mesure
Volumétrique (L3/L4)	Amplification DNS, NTP, memcached	Le lien vers l'opérateur, en amont du serveur	Gbit/s
Protocolaire (L4)	SYN flood, ACK flood, fragments IP	La table d'états du pare-feu ou du répartiteur de charge	Mpps (millions de paquets/s)
Applicative (L7)	Slowloris, flood GET/POST, HTTP/2 Rapid Reset	Les processus du serveur web et la base de données	rps (requêtes/s)

L’amplification : pourquoi 1 Gbit/s émis en devient 50 reçus

La technique repose sur deux propriétés d'UDP : pas de poignée de main, donc pas de vérification de l'expéditeur, et des réponses beaucoup plus grosses que les requêtes. L'attaquant envoie une petite requête à un serveur public en inscrivant l'adresse IP de sa victime comme source. Le serveur, qui ne fait que son travail, envoie sa réponse volumineuse à la victime. Multipliez par quelques dizaines de milliers de réflecteurs.

Les facteurs ci-dessous proviennent de l'alerte TA14-013A de l'US-CERT (CISA), régulièrement mise à jour. Ils mesurent le rapport entre la taille de la réponse et celle de la requête.

Protocole	Port abusé	Facteur d'amplification
DNS (requête ANY sur résolveur ouvert)	53/udp	28 à 54
NTP (commande monlist)	123/udp	jusqu'à 557
CharGen	19/udp	environ 359
SSDP	1900/udp	environ 31
LDAP / CLDAP	389/udp	46 à 55
memcached	11211/udp	10 000 à 51 000

Un cas réel : GitHub, 1,35 Tbit/s, aucun botnet

Le 28 février 2018, GitHub a encaissé 1,35 Tbit/s et 126,9 millions de paquets par seconde. Le site est resté inaccessible cinq minutes, puis instable quelques minutes de plus. Aucune machine infectée n'a été nécessaire : les attaquants ont simplement réutilisé des serveurs memcached exposés sur le port 11211 en UDP, un service de cache que personne n'aurait dû laisser joignable depuis Internet.

Le correctif tenait en une ligne de configuration. Lier memcached à 127.0.0.1 et désactiver l'écoute UDP avec l'option `-U 0`. Le projet a fini par la mettre par défaut dans la version 1.5.6, publiée fin février 2018. La leçon vaut au-delà de memcached : chaque service UDP que vous laissez répondre à l'Internet entier devient une arme pointée vers quelqu'un d'autre, et vous ne le verrez jamais dans vos propres alertes.

Reconnaître une attaque plutôt qu’un pic de trafic

Un article qui remonte en tête d'agrégateur produit la même courbe qu'un flood L7 : le trafic décuple en quelques secondes et le site tombe. La différence se lit dans la forme, pas dans le volume. Sur un pic légitime, la répartition géographique et le mix d'ASN ressemblent à votre audience habituelle, les visiteurs chargent les images et les feuilles de style, le taux d'erreur monte progressivement. Sur une attaque, les requêtes ne demandent que le HTML, l'agent utilisateur se répète à l'identique ou varie de façon absurde, et la distribution des adresses est plate.

Quelques commandes qui donnent une réponse en moins d'une minute sur un serveur Linux :

• `ss -tn state syn-recv | wc -l` : compte les connexions figées en SYN_RECV. Quelques dizaines en régime normal, plusieurs milliers pendant un SYN flood.
• `dmesg -T | grep -i 'syn flooding'` : le noyau journalise explicitement « Possible SYN flooding on port 443. Sending cookies. » quand la file d'attente déborde.
• `tcpdump -nni eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn' -c 200` : capture 200 SYN et montre immédiatement la diversité des sources.
• `awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20` : sur un DDoS bien réparti, aucune adresse ne dépasse quelques dizaines de hits, et c'est précisément ce résultat plat qui signe l'attaque.
• Comparer le débit de l'interface au débit souscrit : si vous êtes collé au plafond du lien, le filtrage local ne servira à rien.

Ce qui protège réellement, et ce qui donne une fausse sécurité

Règle de base : le filtrage doit se faire là où la capacité existe. Un lien 1 Gbit/s ne survit pas à 10 Gbit/s, quelle que soit la finesse de vos règles iptables, puisque les paquets sont déjà perdus avant d'atteindre la carte réseau. Contre le volumétrique, seules trois options tiennent : la capacité de votre opérateur, un centre de nettoyage vers lequel votre trafic est dérouté, ou un réseau anycast qui dilue l'attaque sur des dizaines de points de présence.

Le blackhole BGP (RTBH, décrit par la RFC 5635) mérite un avertissement. Votre opérateur annonce votre /32 avec une communauté de mise au rebut, et tout le trafic vers cette adresse est jeté dès l'entrée du réseau. Cela sauve l'infrastructure de l'opérateur et vos voisins de rack. Votre service, lui, devient injoignable : l'attaquant obtient exactement ce qu'il voulait. C'est une mesure de dernier recours, pas une protection. Le BGP Flowspec (RFC 8955) permet des règles bien plus fines quand votre opérateur le propose.

Côté serveur, quelques réglages absorbent les attaques de faible intensité et coûtent une ligne de configuration.

• SYN cookies : `sysctl net.ipv4.tcp_syncookies=1`, activé par défaut sur la plupart des distributions. Les contre-mesures aux SYN floods sont documentées dans la RFC 4987.
• Contre Slowloris et RUDY : `client_header_timeout` et `client_body_timeout` sous nginx, `mod_reqtimeout` sous Apache (livré actif depuis la 2.2.15).
• Limitation de débit applicative : `limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;` puis `limit_req zone=api burst=20 nodelay;` sur les URL coûteuses.
• Ne pas exposer de service UDP sans raison, et fermer toute récursion DNS ouverte : le résolveur ouvert reste le premier fournisseur d'amplification.
• Côté opérateur, le filtrage d'entrée BCP 38 (RFC 2827) et l'uRPF (RFC 3704) empêchent l'usurpation d'adresse source. Tant que ces bonnes pratiques ne sont pas déployées partout, l'amplification restera possible.

Questions fréquentes

Déni de service distribué et DDoS, est-ce la même chose ?

Oui. DDoS est le sigle de Distributed Denial of Service, dont « déni de service distribué » est la traduction littérale. Les deux formes coexistent dans la documentation française, les contrats d'hébergement et les rapports d'incident, sans différence de sens.

Un CDN suffit-il à me protéger ?

Seulement si l'adresse IP de votre serveur d'origine reste inconnue. Un attaquant qui la retrouve (ancien enregistrement DNS, en-tête de mail sortant, certificat, sous-domaine oublié) contourne le CDN et tape directement. La contre-mesure est de n'autoriser en entrée que les plages d'adresses du fournisseur sur le pare-feu de l'origine, et de changer d'IP après une fuite.

Combien de temps dure une attaque type ?

Cloudflare indique de façon constante dans ses rapports trimestriels que la majorité des attaques réseau se terminent en moins de dix minutes. La conséquence est opérationnelle : une protection activée manuellement, ou dont le déroutage prend un quart d'heure, arrive après la fin de l'attaque. Les attaques longues existent aussi, mais elles sont minoritaires.

Peut-on identifier l’auteur d’un DDoS ?

Rarement par l'analyse du trafic seul. Les adresses sources sont soit celles de machines infectées, soit celles de réflecteurs innocents, soit usurpées. Les affaires judiciaires aboutissent généralement par un autre biais : traçage des paiements vers les services de location d'attaques, saisie des serveurs de commande, erreurs d'opérateur. Il faut néanmoins conserver les captures et les logs, ils servent au dépôt de plainte.

Que risque-t-on en France à lancer ou commander une attaque ?

L'article 323-2 du code pénal punit l'entrave au fonctionnement d'un système de traitement automatisé de données de cinq ans d'emprisonnement et 150 000 euros d'amende. L'article 323-3-1 étend ces peines à la mise à disposition d'outils conçus pour cela, ce qui vise les services de « stresser » en ligne. Tester la résistance d'un site sans autorisation écrite du propriétaire tombe sous le même texte, y compris pour un test de charge présenté comme technique.

Testez vos connaissances

À lire aussi

attaque ddos · botnet · anycast · cdn