Une attaque par déni de service distribué (DDoS) ne cherche ni à voler des données ni à prendre le contrôle d’un système. Son objectif est plus brutal : rendre un service indisponible en le saturant délibérément. Site web, API, serveur de messagerie, interface d’administration ou lien d’accès, toute ressource exposée peut devenir une cible. En 2026, la combinaison de botnets d’objets connectés, de services de location d’attaques et d’une furtivité croissante sur la couche applicative impose de traiter la résilience DDoS comme un volet à part entière de la stratégie de sécurité, et non comme une option technique secondaire. Ce guide détaille les familles d’attaques, les mécanismes de défense et le plan de réponse attendu d’un RSSI ou d’un DSI.
Qu’est-ce qu’une attaque DDoS ?
Le sigle DDoS signifie Distributed Denial of Service, déni de service distribué. Le principe est simple : épuiser une ressource finie jusqu’à ce qu’elle ne puisse plus servir les utilisateurs légitimes. Cette ressource peut être la bande passante du lien d’accès, la capacité de traitement d’un équipement, la table d’état d’un pare-feu, ou encore la logique d’une application incapable d’absorber un afflux de requêtes coûteuses.
Le caractère distribué est essentiel. Dans une attaque par déni de service classique (DoS), une source unique tente de saturer la cible. La défense est alors relativement simple : il suffit d’identifier puis de bloquer cette source. Dans une attaque distribuée, le trafic provient de milliers, parfois de centaines de milliers de sources réparties dans le monde, souvent des machines compromises agrégées en botnet. Il n’existe plus une adresse à bloquer, mais une masse de trafic dont chaque flux pris isolément peut sembler anodin.
Pourquoi les attaques DDoS persistent
Plusieurs facteurs structurels expliquent la permanence de la menace. D’abord, le coût pour l’attaquant reste faible : des services illégaux de location d’attaques, dits booters ou stressers, permettent de commander une vague de trafic contre une cible pour un prix dérisoire. Ensuite, la prolifération d’objets connectés mal sécurisés alimente en continu de nouveaux botnets capables de générer des volumétries considérables. Enfin, le DDoS est polyvalent : il sert tour à tour d’arme d’extorsion, de moyen de pression idéologique, d’outil de concurrence déloyale, ou de diversion destinée à masquer une intrusion menée en parallèle.
Les trois familles d’attaques DDoS
Comprendre la défense suppose d’abord de classer les attaques. La CISA, l’agence américaine de cybersécurité, distingue trois grandes catégories qui correspondent à trois cibles différentes au sein de l’infrastructure [1]. Cette taxonomie fait consensus et structure la conception des parades.
1. Les attaques volumétriques
Les attaques volumétriques visent à saturer la bande passante disponible entre la cible et le reste d’Internet. L’objectif est de remplir le tuyau : si le lien d’accès supporte un certain débit, l’attaquant cherche à le dépasser, de sorte que le trafic légitime ne trouve plus de place. On parle ici de débits exprimés en gigabits voire en térabits par seconde.
Ces attaques exploitent souvent l’amplification par réflexion. L’attaquant envoie une petite requête à un serveur tiers mal configuré (DNS, NTP, memcached, et autres protocoles UDP), en usurpant l’adresse source pour qu’elle pointe vers la victime. Le serveur tiers répond alors à la victime avec une réponse bien plus volumineuse que la requête initiale. Le facteur d’amplification peut atteindre plusieurs dizaines, voire centaines, ce qui permet à un attaquant disposant de ressources modestes de générer un volume massif. La parade à ce niveau ne peut pas se trouver dans l’infrastructure de la victime, dont le lien est par définition débordé : elle doit intervenir en amont, dans le réseau.
2. Les attaques protocolaires
Les attaques protocolaires, parfois dites attaques par épuisement d’état, ne cherchent pas à saturer la bande passante mais à épuiser les ressources des équipements intermédiaires : pare-feu, répartiteurs de charge, serveurs eux-mêmes. L’exemple historique est le SYN flood, qui exploite le mécanisme d’établissement de connexion TCP. L’attaquant envoie un grand nombre de demandes d’ouverture de connexion sans jamais les finaliser, ce qui laisse l’équipe cible avec une multitude de connexions à demi ouvertes qui occupent sa table d’état jusqu’à saturation.
Ces attaques sont redoutables car le volume de trafic peut rester modéré, en dessous du seuil de déclenchement des protections purement volumétriques. C’est une logique d’épuisement plutôt que de saturation brute. La défense repose sur des mécanismes spécifiques (SYN cookies, limitation du nombre de connexions par source, durcissement de la pile réseau) et sur le placement de la fonction de filtrage à un endroit suffisamment dimensionné.
3. Les attaques applicatives
Les attaques applicatives, dites de couche 7 en référence au modèle OSI, sont les plus furtives et souvent les plus difficiles à contrer. Plutôt que de saturer un tuyau ou une table d’état, elles ciblent la logique de l’application : elles envoient des requêtes parfaitement valides mais coûteuses à traiter. Une requête de recherche complexe, une page qui déclenche un calcul lourd ou une interrogation de base de données, répétée des milliers de fois par seconde, peut mettre à genoux un serveur applicatif sans générer un volume réseau spectaculaire.
La difficulté tient à ce que chaque requête prise isolément ressemble à une requête légitime. Distinguer un pic de trafic dû à une attaque d’un pic dû à un succès commercial soudain exige une analyse comportementale fine. C’est sur cette couche que les attaques ont le plus évolué en 2026, avec des campagnes qui imitent le comportement humain, font tourner les adresses sources et adaptent leur cadence pour rester sous les seuils de détection automatique.
Construire une architecture de défense multicouche
Aucune solution unique ne couvre les trois familles d’attaques. Une protection efficace combine plusieurs couches qui interviennent à des endroits différents du chemin réseau. Cette logique de défense en profondeur rejoint les principes que nous détaillons dans notre guide de l’architecture Zero Trust : aucune couche n’est jugée suffisante à elle seule.
Le surdimensionnement et l’absorption
La première ligne de défense reste la capacité. Disposer d’une marge de bande passante et de capacité de traitement permet d’absorber les attaques de faible et moyenne intensité sans bascule particulière. Le surdimensionnement n’est pas une protection en soi face aux grandes volumétries, mais il élève le seuil à partir duquel l’attaque devient gênante et donne du temps pour réagir. Les architectures distribuées, qui répartissent le service sur plusieurs points de présence, renforcent cette absorption naturelle.
Le filtrage en bordure
À l’entrée du réseau, des règles de filtrage éliminent le trafic manifestement illégitime : protocoles non utilisés, paquets malformés, sources géographiques sans rapport avec l’activité, trafic correspondant à des signatures d’attaque connues. Ce filtrage en bordure réduit la surface exposée et soulage les couches situées en aval. Il doit toutefois être conçu avec prudence, car un filtrage trop agressif risque de bloquer des utilisateurs légitimes, ce qui revient à réaliser pour l’attaquant l’indisponibilité recherchée.
Le scrubbing center
Pour les volumétries que le lien d’accès ne peut absorber, la mitigation passe par un scrubbing center, ou centre de nettoyage. Le principe consiste à rediriger le trafic destiné à la cible vers une infrastructure spécialisée disposant d’une capacité d’absorption massive. Cette infrastructure trie le flux, écarte le trafic malveillant, puis ne renvoie vers la cible que le trafic propre. La redirection s’opère soit en permanence (mode toujours actif), soit à la demande lorsqu’une attaque est détectée (mode à la demande), via des mécanismes de routage.
Le mode toujours actif offre une protection immédiate mais ajoute une latence permanente et un coût continu. Le mode à la demande limite ce surcoût mais introduit un délai de bascule, pendant lequel le service reste exposé. Le choix dépend du profil de risque et de la criticité du service. Pour un service générateur de revenus en continu, le mode toujours actif se justifie souvent.
La protection applicative
Contre les attaques de couche 7, les couches précédentes sont aveugles : le trafic est valide au niveau réseau. La défense repose alors sur des dispositifs applicatifs, notamment un pare-feu applicatif web (WAF) capable d’inspecter les requêtes, de limiter leur cadence par source, de poser des défis (challenges) pour distinguer un navigateur humain d’un automate, et d’appliquer une analyse comportementale. Cette couche se conçoit en cohérence avec l’ensemble des pratiques de sécurisation du cycle de développement, comme nous l’évoquons dans notre article sur le DevSecOps et la sécurité de la chaîne CI/CD.
Détection : voir l’attaque avant qu’elle ne fasse mal
La meilleure architecture de mitigation reste inutile si l’attaque n’est pas détectée à temps. La détection repose sur la surveillance continue de signaux clés : volume de trafic entrant, nombre de connexions par seconde, taux d’erreurs applicatives, temps de réponse, consommation de ressources sur les serveurs. Un écart soudain par rapport à la ligne de base normale constitue un indicateur d’alerte.
L’enjeu est de définir des seuils pertinents. Trop sensibles, ils déclenchent des fausses alertes lors de pics légitimes ; trop laxistes, ils laissent passer les attaques de faible volumétrie mais de forte précision. L’établissement d’une ligne de base solide, fondée sur l’observation du trafic réel sur une période représentative, est un prérequis. Cette discipline de mesure rejoint les pratiques d’observabilité que nous détaillons par ailleurs, où la connaissance fine du comportement normal d’un système est la condition de la détection de l’anormal.
La détection ne doit pas être uniquement automatique. Un canal d’alerte vers l’équipe ou le prestataire de sécurité, avec une procédure d’escalade claire, garantit qu’une attaque sortant des schémas connus déclenche bien une réaction humaine.
Le plan de réponse DDoS
Un dispositif technique sans plan de réponse documenté et testé reste fragile. La gestion d’une attaque DDoS s’inscrit dans la logique plus large de la gestion de crise cyber, que nous traitons dans notre dossier sur le plan de continuité et de reprise d’activité. Un plan de réponse DDoS comporte au minimum les éléments suivants.
Les contacts opérationnels. Qui appeler chez l’opérateur ou l’hébergeur, par quel canal, avec quels identifiants de contrat. En pleine attaque, l’indisponibilité éventuelle des canaux habituels (messagerie, portail) impose de disposer de contacts alternatifs documentés hors ligne.
Les seuils et les déclencheurs. À partir de quel niveau d’anomalie bascule-t-on en mode mitigation, qui prend la décision, et selon quelle procédure. L’ambiguïté sur la décision coûte des minutes précieuses.
Les actions de mitigation. La séquence concrète : activation du scrubbing, ajustement des règles de filtrage, mise en place de pages de maintenance, communication interne et externe. Chaque action doit avoir un responsable identifié.
La communication. Que dit-on aux clients, aux utilisateurs, à la presse le cas échéant. Une communication maîtrisée évite que l’indisponibilité technique ne se double d’une crise de réputation.
Le retour d’expérience. Une fois l’attaque traitée, l’analyse à froid des journaux, des seuils déclenchés et des délais de réaction nourrit l’amélioration continue du dispositif.
Comme tout plan, il ne vaut que testé. Un exercice de simulation, mené à intervalle régulier, révèle les angles morts bien plus efficacement qu’une lecture du document.
Le cas particulier de l’extorsion par DDoS
Une tendance lourde mérite une mention spécifique : le DDoS d’extorsion, parfois appelé Ransom DDoS. Le scénario type est le suivant. L’attaquant lance une courte démonstration de force, une vague d’attaque de quelques minutes, puis envoie un message de rançon menaçant de prolonger ou d’intensifier l’attaque si une somme n’est pas versée. La pression psychologique est forte, car la démonstration prouve la capacité de nuire.
La position recommandée par les autorités est constante : ne pas payer. Le paiement ne garantit rien, alimente le modèle économique des attaquants et désigne la victime comme une cible solvable pour de futures campagnes. La bonne réponse consiste à activer le plan de mitigation, à conserver les preuves et à signaler l’incident. Cette logique rejoint celle adoptée face aux rançongiciels, que nous analysons dans notre article sur les vecteurs d’attaque des ransomwares.
Anticiper contractuellement avec son hébergeur
Un point souvent négligé concerne le partage des responsabilités. Lorsque le service est hébergé chez un prestataire, la première question à poser est : que couvre le contrat en matière de protection DDoS, jusqu’à quel volume, avec quels engagements de délai et de disponibilité. Beaucoup d’offres incluent une protection volumétrique de base mais excluent les attaques applicatives ou plafonnent la capacité de mitigation. Lire ces clauses avant l’incident évite la mauvaise surprise au pire moment.
Pour les entités soumises à des exigences de résilience renforcées, l’analyse doit aussi porter sur la chaîne d’approvisionnement numérique. Une attaque visant un fournisseur critique (DNS, CDN, hébergeur) peut rendre un service indisponible sans que l’entité elle-même soit directement ciblée. La cartographie des dépendances externes fait partie intégrante de l’analyse de risque DDoS.
Que disent les autorités en 2026
Les agences nationales et européennes convergent sur un message simple : la protection DDoS n’est pas un produit mais un processus. La CISA insiste sur la préparation, la détection et l’existence d’un plan de réponse, plutôt que sur l’achat d’un boîtier unique [1]. L’ANSSI, via la plateforme cybermalveillance.gouv.fr, met à disposition des fiches réflexes destinées aux victimes et rappelle l’importance de la déclaration et de la conservation des preuves [4]. L’ENISA replace le DDoS dans le paysage global des menaces et souligne la montée des attaques applicatives sophistiquées [3].
Pour les entités relevant de la directive NIS2, une attaque DDoS ayant un impact opérationnel significatif entre dans le champ des incidents à notifier. La résilience face au déni de service n’est donc plus seulement une bonne pratique : elle s’inscrit désormais dans un cadre réglementaire explicite, ce qui élève la protection DDoS au rang d’obligation de fond pour les acteurs concernés.
Synthèse pour le décideur
La menace DDoS ne disparaîtra pas, parce qu’elle est peu coûteuse pour l’attaquant et polyvalente dans ses usages. La bonne posture ne consiste pas à chercher une protection absolue, illusoire, mais à bâtir une résilience proportionnée au risque. Cela passe par une architecture multicouche, une détection fondée sur une ligne de base solide, un plan de réponse testé, et une clarification contractuelle des responsabilités avec les prestataires. Une PME exposée sur Internet et une grande entité essentielle n’ont pas le même dimensionnement à viser, mais elles partagent la même logique : anticiper avant l’attaque, parce qu’au moment où le service tombe, il est déjà trop tard pour improviser.
Références
[1] CISA, Understanding and Responding to Distributed Denial-of-Service Attacks. [2] NIST, publications relatives à la disponibilité et à la résilience des systèmes d’information. [3] ENISA, Threat Landscape, chapitre relatif aux attaques par déni de service. [4] ANSSI et cybermalveillance.gouv.fr, fiche réflexe attaque en déni de service (DDoS). [5] Directive (UE) 2022/2555 (NIS2), articles relatifs à la notification des incidents importants.
Sources primaires : CISA, ANSSI, ENISA, NIST, Cybermalveillance.