Une attaque par déni de service distribué (DDoS, pour distributed denial of service) consiste à saturer un service en ligne sous un volume de requêtes qu’il ne peut pas absorber, jusqu’à le rendre inaccessible aux utilisateurs légitimes. Le caractère « distribué » tient à l’origine du trafic : les requêtes proviennent simultanément de milliers de machines compromises — postes de travail, serveurs ou objets connectés — regroupées au sein d’un botnet que l’attaquant pilote à distance.
L’attaque ne comporte en elle-même ni intrusion ni destruction de données ; elle vise la disponibilité du service. Pour les clients d’une banque en ligne, le constat est le même que lors d’une panne : pendant toute la durée de l’attaque, le site ne répond plus.
Des attaques volumétriques aux attaques applicatives
Les attaques volumétriques forment la famille la plus intuitive : engorger la bande passante de la cible sous un flot de données supérieur à ce que ses liens réseau peuvent écouler. Les attaquants recourent souvent à l’amplification, en adressant de petites requêtes à des services mal configurés — résolveurs DNS ouverts, serveurs de temps — tout en usurpant l’adresse de leur victime : celle-ci reçoit des réponses bien plus volumineuses que les questions.
Les attaques protocolaires visent un autre maillon. En exploitant le fonctionnement des protocoles réseau, par exemple en ouvrant des connexions jamais menées à leur terme, elles remplissent les tables d’état des pare-feu et des serveurs, qui finissent par refuser toute nouvelle session alors même que la bande passante reste disponible.
Au niveau applicatif, enfin, des requêtes d’apparence légitime — recherches ou appels d’API — déclenchent des traitements coûteux côté serveur ; un volume modeste suffit alors à épuiser la ressource, et la distinction entre trafic hostile et clients réels devient délicate. Les campagnes observées combinent fréquemment ces registres pour contourner les défenses.
Ce que cherchent les attaquants
Derrière la saturation, les mobiles varient. L’extorsion en est un : des groupes menacent une entreprise d’une attaque, parfois après une courte démonstration de force, et exigent un paiement pour y renoncer ou y mettre fin.
Le déni de service peut également accompagner une autre opération. Dans son guide « Comprendre et anticiper les attaques DDoS », l’ANSSI relève que ces attaques servent parfois à détourner l’attention des équipes de sécurité, mobilisées sur l’indisponibilité pendant qu’une exfiltration ou une fraude se déroule ailleurs dans le système d’information.
Le hacktivisme complète ce paysage : des campagnes revendiquées pour des motifs politiques visent régulièrement des sites institutionnels et financiers européens, en particulier dans les périodes de tension géopolitique. Le CERT-FR publie des alertes lorsque de telles vagues touchent des entités françaises.
L’enjeu pour un établissement financier
Pour une banque ou un assureur, l’indisponibilité se voit immédiatement : banque en ligne muette, API de paiement injoignables. L’interruption se commente en quelques minutes sur les réseaux sociaux et entame la confiance, alors même qu’aucune donnée n’a été compromise. À plus grande échelle, les conséquences d’une cyberattaque massive sur les infrastructures essentielles du secteur financier dépassent l’établissement touché et interrogent la stabilité de l’écosystème des paiements.
Le règlement (UE) 2022/2554, dit DORA, impose aux entités financières une politique de continuité des activités informatiques régulièrement testée, ainsi que la notification des incidents majeurs à leur autorité de supervision ; depuis son entrée en application, une indisponibilité prolongée peut donc constituer un incident à déclarer. Le Forum des Compétences a consacré une analyse à la manière dont ransomwares et attaques DDoS transforment les pratiques de sécurité dans les finances et assurances.
Des protections en couches successives
Face aux attaques volumétriques, la défense se joue en amont du système d’information, dont les liens réseau saturent avant que les équipements internes n’entrent en jeu. Les pratiques constatées reposent sur le filtrage assuré par les opérateurs de transit et sur des services de protection dédiés, qui déroutent le trafic vers des centres de nettoyage où les flux hostiles sont écartés.
La capacité d’absorption constitue une deuxième couche : répartition des services sur plusieurs sites et mise en cache des contenus au plus près des utilisateurs, complétées par l’élasticité des infrastructures cloud. Cette externalisation crée en retour une dépendance envers un petit nombre d’acteurs, comme l’ont montré les pannes massives des grands fournisseurs de cloud. L’agence américaine CISA recommande de son côté de convenir à l’avance, avec hébergeur et fournisseur d’accès, de la marche à suivre en cas d’attaque.
La détection complète le dispositif. La supervision du trafic par un SOC et la corrélation des journaux au sein d’un SIEM aident à distinguer une attaque naissante d’un pic de fréquentation et à déclencher les mesures préparées : page d’attente allégée, bascule des canaux critiques vers une infrastructure de repli si la saturation persiste. Le renseignement sur la menace intervient plus tôt encore, certaines campagnes hacktivistes étant annoncées avant leur lancement.
Quand l’attaque devient une crise
Un déni de service qui se prolonge sort du registre purement technique. Le plan de continuité d’activité organise le fonctionnement en mode dégradé — accueil des clients par d’autres canaux, priorité aux opérations sensibles — tandis que le plan de reprise d’activité couvre l’hypothèse d’une reconstruction ; particularité du DDoS, l’infrastructure n’est pas endommagée et la sortie de crise dépend surtout de l’arrêt de l’attaque ou de l’efficacité du filtrage. Ces dispositifs s’inscrivent dans la résilience opérationnelle de l’établissement, dont l’objet est précisément le maintien des fonctions critiques pendant la perturbation.
La conduite de crise proprement dite mobilise une cellule décisionnelle, une communication adaptée vers les clients, ainsi qu’une coordination avec les opérateurs et les autorités ; ces réflexes se préparent avant l’incident, comme le montrent les travaux consacrés à la gestion de crise face aux cybermenaces. En cas d’attaque avérée, cybermalveillance.gouv.fr conseille dans sa fiche réflexe dédiée de conserver les journaux techniques, utiles comme preuves, puis de solliciter son hébergeur et de déposer plainte. À l’échelon européen, les mécanismes de cyberdéfense se structurent également, avec une réserve de prestataires mobilisable pour épauler la réponse aux incidents de grande ampleur.
Questions fréquentes sur les attaques DDoS
Quelle différence entre un déni de service (DoS) et un déni de service distribué (DDoS) ?
Le déni de service simple émane d’une source unique, ce qui le rend plus aisé à bloquer : filtrer l’adresse émettrice suffit souvent. La forme distribuée s’appuie sur des milliers de machines réparties dans le monde, aux adresses sans cesse renouvelées ; le filtrage devient d’autant plus délicat que chaque source, prise isolément, se comporte presque comme un client ordinaire.
Une attaque DDoS peut-elle provoquer un vol de données ?
Pas par elle-même : la saturation d’un service n’ouvre aucun accès au système d’information et ne permet d’exfiltrer aucune donnée. Pendant l’incident, les équipes de sécurité évitent cependant de concentrer toute leur attention sur le service touché, car une campagne de déni de service peut coïncider avec une tentative d’intrusion menée au même moment.
Faut-il payer lorsqu’une demande de rançon accompagne l’attaque ?
Cybermalveillance.gouv.fr recommande de ne pas céder : rien ne garantit l’arrêt de l’attaque après paiement, et verser les fonds désigne l’organisation comme une cible disposée à payer de nouveau. Le dépôt de plainte est conseillé dans tous les cas, l’entrave au fonctionnement d’un système de traitement automatisé de données constituant une infraction pénale en droit français.
