Réseaux et infrastructures
Particuliers et entreprisesDéni de service, simple ou distribué
DoS / DDoS
Un service est saturé ou rendu incapable de répondre aux utilisateurs légitimes.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Un site ne répond plus pendant une affluence anormale. Des demandes ou paquets occupent ses ressources jusqu’à empêcher les visiteurs habituels d’y accéder. Une panne peut produire le même symptôme : l’origine malveillante doit être vérifiée.
Comment cela fonctionne
Un déni de service vise à rendre une ressource indisponible. Lorsqu’il provient de nombreuses sources, on parle de DDoS. L’attaque peut saturer une connexion, épuiser les capacités d’un serveur ou déclencher un traitement particulièrement coûteux. Le nombre de demandes n’est donc pas le seul facteur. Une attaque n’a pas besoin de voler des données pour causer un préjudice important.
- Une ressource est surchargée
Connexion, serveur ou fonction.
- Les demandes normales attendent
La capacité disponible est épuisée.
- Le service devient indisponible
Sans vol de données nécessaire.
Les signes qui doivent attirer l’attention
- La latence et les erreurs augmentent brutalement.
- La bande passante, les connexions ou les ressources atteignent leurs limites.
- Les demandes se concentrent sur une fonction coûteuse ou proviennent d’un ensemble inhabituel de sources.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Consultez les informations de l’exploitant par un autre canal si un service est indisponible. Si votre propre connexion ou site est visé, contactez l’opérateur avec les horaires observés.
Si vous êtes responsable du service ou de l’organisation
Préparez avec l’hébergeur le filtrage d’urgence et un canal d’information indépendant. Surveillez le réseau autant que les fonctions coûteuses de l’application.
Ajouter des serveurs ne règle pas nécessairement une saturation du lien réseau ou d’une dépendance unique.
À vous de décider
Un site ne répond plus. Cela prouve-t-il qu’il subit une attaque et que ses données ont été volées ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Non. Une panne ou une affluence légitime peut aussi rendre le site indisponible. Consultez les informations de l’exploitant par un autre canal. Même si un déni de service est confirmé, l’indisponibilité ne prouve pas un vol de données.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Identifier la ressource saturée avant de choisir la protection
Trois services deviennent indisponibles, mais pour des raisons différentes. Le premier reçoit 9,8 Gbit/s avec un processeur peu sollicité : le lien réseau peut être saturé avant que le serveur ne manque de ressources. Le deuxième accumule les connexions. Le troisième consacre son processeur et sa base de données à des recherches coûteuses, malgré un débit plus faible.
La protection doit intervenir là où se situe la saturation. Un filtrage dans l’application arrive trop tard si le lien amont est plein. À l’inverse, absorber davantage de trafic réseau ne corrige pas une recherche qui déclenche des dizaines de requêtes en base. Il faut mesurer les files d’attente, connexions, temps de réponse, accès au cache et dépendances, en plus du débit.
Une hausse de fréquentation légitime ou une panne d’un service tiers peut produire des symptômes similaires. Comparer le trafic à l’activité attendue et examiner les requêtes dominantes. Le rétablissement du service est prioritaire ; l’attribution de l’attaque peut rester incertaine. Les protections doivent aussi laisser passer les clients légitimes, y compris ceux qui partagent une adresse IP.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Trafic et connexions
Clients distribués vers Edge / opérateur
Trace Gbps, req/s, état
- Action
Requêtes admises
Edge / opérateur vers Application
Trace cache et route
- Action
Travail amplifié
Application vers Base de données
Trace 84 appels / recherche
- Réponse
Attente du pool
Base de données vers Application
Trace 850 ms
- Réponse
Réponse lente ou erreur
Application vers Edge / opérateur
Trace SLO métier
- Action
Limitation ciblée
Edge / opérateur vers Clients distribués
Trace effet sur utilisateurs
- Action
Annulation propagée
Application vers Base de données
Trace ressources libérées
Comment repérer cette attaque
Indices à rechercher
Repérer la première ressource qui atteint sa limite et les requêtes qui la sollicitent, ainsi que les hausses de latence, erreurs et refus d’accès.
Éléments à croiser
Identifier la première ressource qui sature : lien, connexions ou travail applicatif. Comparer les mesures sur la même période et confronter la hausse au trafic habituel et aux changements déployés.
Limites de l’interprétation
Une panne, une campagne commerciale ou une requête légitime coûteuse peuvent produire des symptômes voisins. Le nombre de requêtes ne mesure ni le débit en bits ni le coût de leur traitement.
Comment réagir
Intervenir sur la ressource saturée : protection opérateur pour le lien, filtrage amont pour les connexions, limitation et cache pour les traitements coûteux. Vérifier que le serveur d’origine n’est pas directement exposé en contournement de la protection prévue. Conserver des mesures utiles sans remplir les disques avec tout le trafic hostile.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Rejouer une charge bornée sur un environnement de capacité connue et mesurer le service métier.
- Vérifier qu’une requête annulée libère réellement ses ressources applicatives et SQL.
- Tester le parcours légitime derrière un NAT partagé après activation des limites.
À vous de raisonner
Le lien amont est saturé, mais le processeur reste peu utilisé. Pourquoi ajouter un filtre dans l’application risque-t-il de ne pas rétablir le service ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Le trafic sature le lien avant d’atteindre le filtre. La protection doit intervenir en amont avec l’acteur capable de traiter ce volume. Continuez à mesurer le service rendu et les accès légitimes ; si le goulet se situe dans une requête coûteuse, la réponse sera différente.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
db_pool_wait_ms- Mesure de supervision synthétique, pas champ d’un journal HTTP.
p99- Latence dépassée par environ 1 % des observations du périmètre mesuré ; préciser route, période et unité.
Trois profils de saturation
JournalLes valeurs illustrent des mécanismes distincts, pas des seuils universels.
fenetre ingress_Gbps req_s conn_actives app_cpu db_pool_wait_ms cache_hit
A 9.8 800 1200 22% 2 94%
B 0.3 900 98000 25% 3 94%
C 0.4 1800 3400 98% 850 12%
C route=/search p99_ms=6200 db_queries_per_request=84
C route=/health p99_ms=18 upstream_errors=0Préparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
nginx — journal d’accès HTTP
- Où les trouver
- Sur le frontal, dans le fichier désigné par access_log ; son contenu dépend de log_format. L’hébergeur peut devoir fournir cet export.
- Quoi relever
- Comparer les routes, statuts, débits de requêtes et temps de réponse lorsque le format les conserve. Séparer les erreurs du frontal et celles de l’application ; une route coûteuse peut saturer avec peu de requêtes.
- Accès et prérequis
- Lecture des journaux serveur. Vérifier que la route est journalisée : les temps de réponse et identifiants de requête ne figurent pas forcément dans le format configuré.
Prometheus — séries de mesures
- Où les trouver
- Dans l’interface de requêtes Prometheus ou les tableaux Grafana qui l’interrogent : choisir la période, les métriques exposées et les étiquettes de l’instance, route ou pod concerné.
- Quoi relever
- Aligner trafic entrant, connexions actives, CPU, attente en base et latence par route. Vérifier unité, intervalle d’échantillonnage et étiquettes de chaque série avant de comparer deux courbes.
- Accès et prérequis
- Un exportateur et une collecte doivent avoir existé. Les noms des métriques dépendent de l’instrumentation ; une série de mesures n’est pas un journal de requêtes individuelles.
Sonde réseau Zeek — conn.log
- Où les trouver
- Sur une sonde déjà placée sur le trajet du trafic, ou dans le collecteur de ses journaux conn.log. Identifier le point d’observation, notamment avant ou après traduction d’adresses.
- Quoi relever
- Comparer adresses, ports, durées et volumes au point d’observation. Si le lien amont est saturé, demander aussi les mesures de l’opérateur : la sonde locale peut ne pas voir tout le trafic rejeté en amont.
- Accès et prérequis
- La sonde doit avoir vu le trafic. uid, adresses, ports, orig_bytes et resp_bytes décrivent les échanges observés ; les octets réseau ne sont pas le contenu d’un document ni son destinataire humain.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- RéseauOpérateurs de Mirai
Des objets connectés transformés en armée de machines
Des caméras, routeurs et enregistreurs compromis composent le botnet Mirai. Ses opérateurs l’utilisent pour submerger des services de trafic. La diffusion de son code entraîne ensuite l’apparition de variantes exploitées par d’autres acteurs.
Ce qu’établit la source. Trois créateurs et opérateurs de la variante initiale ont plaidé coupable en 2017. Mirai désigne un logiciel et ses réseaux de machines, pas un groupe unique derrière toutes les variantes.
Consulter le rapport Charges and Guilty Pleas in Three Computer Crime Cases Involving Significant DDoS AttacksU.S. Department of Justice · Publié le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
- Contactez l’hébergeur ou l’opérateur avec les heures et symptômes observés.
- Activez les mesures prévues et protégez les fonctions indispensables.
- Informez les utilisateurs par un canal indépendant du service touché.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Network Denial of Service — attack.mitre.org
- MITRE ATT&CK — Endpoint Denial of Service — attack.mitre.org
- Cybermalveillance.gouv.fr — attaque en déni de service — www.cybermalveillance.gouv.fr
- OWASP — Denial of Service Cheat Sheet — cheatsheetseries.owasp.org
