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
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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 cherche à rendre un service indisponible. Quand l’attaque vient de nombreuses sources, on parle de DDoS. Elle peut saturer la connexion, épuiser les capacités du serveur ou lui imposer des traitements très coûteux. Le nombre de demandes ne suffit donc pas à mesurer le risque. Même sans vol de données, l’interruption peut causer des dommages importants.
- 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.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver 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 ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Non. Une panne ou de nombreux visiteurs légitimes peuvent aussi rendre le site indisponible. Cherchez les informations de l’exploitant par un autre moyen. Même si l’attaque est confirmée, l’arrêt du service ne prouve pas que des données ont été volées.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Identifier la ressource saturée avant de choisir la protection
Les trois services sont indisponibles, mais les mesures orientent vers des causes différentes. Le premier reçoit 9,8 Gbit/s alors que son processeur travaille peu : le lien réseau peut être saturé. Le deuxième accumule les connexions. Sur le troisième, des recherches coûteuses occupent le processeur et la base de données 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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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 ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- RéseauOpérateurs de Mirai
Des objets connectés transformés en armée de machines
Les opérateurs de Mirai utilisent des caméras, des routeurs et des enregistreurs piratés pour envoyer un trafic massif vers des services et les submerger. Après la diffusion du code du logiciel, d’autres acteurs en créent et utilisent des variantes.
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
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’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 comprendre votre situation et trouver de l’aide : 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
