DoS

01 — DéfinitionQu'est-ce qu'une attaque DoS ?

Une attaque DoS (Denial of Service), ou attaque par déni de service, vise à rendre un service indisponible pour ses utilisateurs légitimes. Elle s'attaque à la disponibilité, troisième pilier de la triade CIA (Confidentialité, Intégrité, Disponibilité) de la sécurité de l'information.

Dans sa forme classique, le DoS est conduit depuis une seule source : un ordinateur, un serveur, une connexion. Deux grandes approches :

• Saturation : envoyer plus de trafic ou de requêtes que la cible ne peut en traiter, jusqu'à l'épuisement de ses ressources (bande passante, CPU, mémoire, connexions).
• Exploitation : déclencher une vulnérabilité spécifique qui provoque le blocage ou le crash du service avec très peu de trafic (parfois une seule requête malveillante).

Objectifs des attaquants

• Sabotage : rendre un concurrent ou une cible inaccessible.
• Extorsion : menacer d'une attaque prolongée si la rançon n'est pas payée (ransom DoS, RDoS).
• Hacktivisme : manifester un désaccord politique ou idéologique (Anonymous, NoName057, Killnet).
• Couverture : masquer une autre intrusion en noyant les logs sous le bruit d'une attaque visible.
• Guerre économique : attaque d'État contre des infrastructures critiques (cas Estonie 2007, Ukraine).
• Revanche personnelle : conflit entre particuliers, employé mécontent.

Le DoS dans le paysage cyber moderne

Le DoS mono-source a largement perdu en efficacité face aux infrastructures modernes qui absorbent facilement une seule connexion saturée. Son évolution naturelle est le DDoS (Distributed Denial of Service), qui multiplie les sources via un botnet.

Cependant, le DoS reste pertinent pour :

• Les cibles peu dimensionnées : PME, petits serveurs, APIs sans protection.
• Les DoS applicatifs qui exploitent une vulnérabilité : quelques requêtes suffisent.
• Les attaques internes : un employé malveillant ou un malware déjà installé.
• Les cibles dans des environnements fermés : réseaux industriels, IoT, intranets.

Le DoS est la plus vieille forme d'attaque cyber encore en service. Son principe est brutal — rendre indisponible plutôt que voler ou modifier — mais sa simplicité fait toujours des dégâts, particulièrement quand il exploite une faille spécifique plutôt que la force brute.

02 — DoS vs DDoSComprendre la distinction

La différence fondamentale

La différence tient à la source de l'attaque :

• DoS : une seule source attaquante (un attaquant, une machine, un script).
• DDoS : attaque distribuée, coordonnée depuis des milliers à des millions de sources, typiquement via un botnet.

Conséquences pratiques

Puissance d'attaque

Un DoS mono-source plafonne à la bande passante et aux ressources d'une seule machine — quelques Mbps à éventuellement quelques Gbps avec une machine haut de gamme. Un DDoS accumule les ressources de milliers de bots et peut atteindre plusieurs térabits par seconde : record actuel ~5,6 Tbps en 2024 (Cloudflare contre un botnet Mirai variant), 3,8 Tbps (Cloudflare octobre 2024).

Facilité de blocage

Un DoS mono-source est relativement simple à neutraliser : bannir l'IP source au niveau du pare-feu ou du FAI suffit dans la plupart des cas. Un DDoS est bien plus difficile à filtrer : distinguer les millions de bots du trafic légitime demande des infrastructures et algorithmes spécialisés.

Attribution

Un DoS mono-source expose directement l'attaquant — son IP est visible. Les amateurs se font souvent attraper par cette voie. Un DDoS via botnet masque l'attaquant derrière des milliers de machines compromises innocentes.

Cas où DoS et DDoS se confondent

Certaines situations floutent la distinction :

• DoS amplifié (voir section types) : une seule source déclenche une amplification via des serveurs intermédiaires, ressemble à un DDoS.
• DoS sur ressources asymétriques : le coût de la requête pour l'attaquant est très faible, le coût de traitement pour la cible est très élevé.
• Low and Slow : attaque lente depuis une source qui épuise les connexions (Slowloris).

Usage du terme dans le langage courant

Dans les médias et même dans certaines communications techniques, « DoS » est souvent utilisé de manière générique pour désigner toute attaque de disponibilité, y compris les DDoS. Cette confusion est tolérée en langage courant mais il reste important de distinguer techniquement les deux. Les rapports sérieux (ANSSI, ENISA, CERT-FR) maintiennent toujours la distinction.

03 — TypesLes grandes familles d'attaques DoS

1. DoS volumétrique

Saturation de la bande passante ou des ressources réseau de la cible. Depuis une source unique, efficace uniquement contre des cibles mal dimensionnées.

• Flood UDP : envoi massif de paquets UDP vers des ports aléatoires, forçant la cible à traiter chacun.
• Flood ICMP (ping flood) : envoi massif de paquets ICMP Echo Request.
• Flood TCP : envoi massif de paquets TCP (SYN, ACK, PSH+ACK, RST).

2. DoS par exhaustion de protocole

Exploitation de la manière dont les protocoles réseau gèrent les connexions :

• SYN flood : envoi massif de paquets SYN sans finaliser la poignée de main TCP. Le serveur maintient des connexions semi-ouvertes jusqu'à épuisement des ressources. Historiquement très efficace, maintenant mitigé par SYN cookies.
• TCP connect flood : ouverture complète de nombreuses connexions puis maintien.
• Ping of Death : envoi de paquets IP malformés de taille supérieure au maximum autorisé (65 535 octets), causait un crash sur les systèmes vulnérables avant le patch généralisé.
• Teardrop : paquets IP fragmentés avec des offsets qui se chevauchent, provoquant une erreur au réassemblage.
• Land attack : paquet SYN avec adresse source = adresse destination, le serveur se parle à lui-même en boucle.
• Smurf attack : ping ICMP à une adresse broadcast avec l'adresse source usurpée de la cible, toutes les machines du réseau répondent à la cible.

3. DoS applicatif (L7)

Cible la couche applicative — serveur web, API, base de données. Nécessite moins de volumétrie mais plus de connaissance de la cible.

• HTTP flood : envoi massif de requêtes GET ou POST légitimes en apparence.
• Slowloris : ouverture de nombreuses connexions HTTP avec envoi très lent des en-têtes, épuisement des slots de connexion du serveur. Remarquablement efficace depuis une seule machine contre Apache non patché.
• Slow POST / RUDY : envoi d'un POST avec un Content-Length important mais envoi très lent du corps, similaire à Slowloris mais sur POST.
• R-U-Dead-Yet : outil utilisant Slow POST.
• Range attack : en-tête Range HTTP avec de multiples intervalles forçant le serveur à assembler une réponse complexe.
• XML bomb / Billion Laughs : document XML avec entités récursives qui se décompressent exponentiellement à l'analyse.
• ZIP bomb : archive ZIP qui se décompresse en une taille massive (ex. 42.zip : 42 Ko → 4,5 Po).

4. DoS par exploitation de vulnérabilité

Une ou quelques requêtes spécifiques provoquent un crash ou une consommation excessive de ressources.

• ReDoS (Regular Expression DoS) : requête construite pour provoquer un backtracking catastrophique dans une regex mal conçue. Temps d'exécution en O(2^n) au lieu de O(n). Fréquent.
• GraphQL query complexity DoS : requêtes imbriquées profondes qui explosent en traitement.
• Deserialization DoS : objet sérialisé malformé qui épuise les ressources au désérialisage.
• Algorithmic complexity attacks : exploitation de structures de données avec un pire cas connu (hash collision, etc.).
• CVE spécifiques : régulièrement publiées sur Apache, nginx, parsers XML/JSON, bases de données.

5. DoS par amplification

Technique hybride entre DoS et DDoS : une source unique exploite des serveurs intermédiaires mal configurés (serveurs DNS, NTP, Memcached, SNMP) pour multiplier sa puissance d'attaque vers la cible, via usurpation d'adresse source.

• DNS amplification : requête ANY à un résolveur DNS ouvert, réponse 50x plus grande envoyée à la cible usurpée.
• NTP amplification : commande monlist sur serveurs NTP mal configurés, amplification jusqu'à 556x.
• Memcached amplification : cas extrême, amplification jusqu'à 51 000x, à l'origine de l'attaque record GitHub 1,35 Tbps en 2018.
• SNMP, SSDP, CLDAP, WS-Discovery amplifications : autres vecteurs.

6. DoS physique

Moins technique mais réel : couper l'alimentation, les réseaux, les refroidissements. Sabotage d'une fibre optique. Brouillage radio. Attaques EMP. Tous inhabituels dans le cyber courant mais envisageables dans les contextes étatiques ou de sabotage industriel.

04 — HistoriqueAttaques DoS marquantes

Ping of Death (1996-1997)

Premier DoS largement médiatisé. L'envoi d'un paquet ICMP de taille supérieure à 65 535 octets causait un crash système sur Windows 95, NT, Solaris, Linux anciens. Exploité depuis n'importe quelle machine connectée. Patch généralisé fin 1997.

SYN flood contre eBay, Amazon, Yahoo (février 2000)

Attaques historiques de Mafiaboy (Michael Calce, 15 ans à l'époque). Bien que techniquement distribuées, ces attaques ont massivement médiatisé la problématique DoS. Plusieurs heures d'indisponibilité, pertes économiques estimées à 1,2 milliard de dollars. Calce condamné à 8 mois en centre de détention pour mineurs.

Slowloris (2009)

Publié par Robert "RSnake" Hansen, c'est l'un des DoS mono-source les plus efficaces jamais conçus. Ouvre des centaines de connexions HTTP et les maintient ouvertes en envoyant très lentement les en-têtes (un caractère toutes les quelques secondes). Apache ne pouvait plus accepter de nouvelles connexions. Contre-mesure principale : mod_reqtimeout d'Apache, limitant la durée maximale d'envoi des en-têtes.

R-U-Dead-Yet (RUDY, 2010)

Variante de Slowloris sur les requêtes POST. Publie un formulaire avec un Content-Length important, envoie le corps un octet à la fois. Le serveur maintient les connexions en attente, s'épuise. Effet similaire à Slowloris, affecte différents serveurs.

Estonie (avril-mai 2007)

Vague d'attaques DoS et DDoS massives contre le gouvernement, les banques, les médias estoniens, dans le contexte d'une polémique sur un monument soviétique. Premier cas reconnu de cyber-guerre d'envergure contre un État. Attribution informelle à des acteurs russes. L'Estonie a accueilli par la suite le Centre d'excellence OTAN de cyberdéfense à Tallinn.

Attaques contre la Géorgie (août 2008)

Pendant la guerre russo-géorgienne, nombreux sites gouvernementaux et médias géorgiens victimes d'attaques DoS/DDoS coordonnées. Déni de service comme outil de guerre informationnelle en parallèle d'opérations militaires.

LOIC et Anonymous (2008-2012)

LOIC (Low Orbit Ion Cannon) était un outil DoS open source popularisé par Anonymous. Des milliers de sympathisants pouvaient lancer simultanément l'outil contre des cibles annoncées (PayPal, MasterCard, Visa après le blocage de WikiLeaks en 2010). Beaucoup ont été identifiés et condamnés car LOIC ne masquait pas leur IP. Évolution vers HOIC (High Orbit Ion Cannon) puis autres outils plus sophistiqués.

Attaques contre les sites français (depuis 2022-2024)

Dans le contexte de la guerre en Ukraine, les groupes pro-russes NoName057(16) et Killnet ont mené de nombreuses attaques DoS/DDoS contre des sites gouvernementaux français, d'entreprises et d'infrastructures (aéroports, ports, services publics, banques). La plupart ont été mitigées sans impact durable grâce aux protections cloud.

CVE DoS applicatives récentes (2023-2025)

Régulièrement, de nouvelles CVE DoS applicatives sont publiées :

• CVE-2023-44487 — HTTP/2 Rapid Reset (octobre 2023) : attaque exploitant le mécanisme d'annulation de flux HTTP/2, record DDoS à 398 millions de requêtes/seconde chez Google. Patch massif de tous les serveurs HTTP/2.
• CVE régulières sur parsers XML, JSON, regex Node.js, ReDoS dans diverses bibliothèques.
• Attaques GraphQL : requêtes imbriquées qui font exploser les traitements.

05 — DoS applicatifLa menace la plus actuelle

Alors que le DoS volumétrique mono-source est largement neutralisé par les infrastructures modernes, le DoS applicatif reste une menace très actuelle, y compris depuis une seule source. Il exploite une caractéristique fondamentale : l'asymétrie entre le coût d'une requête pour l'attaquant et son coût de traitement pour la cible.

Les vecteurs les plus courants en 2026

ReDoS (Regular Expression DoS)

Une regex mal conçue peut avoir un temps d'exécution exponentiel sur certaines entrées. Exemple classique : ^(a+)+$ avec l'entrée aaaaaaaaaaaaaaaaaaab prend plusieurs secondes à échouer. Les attaquants craftent des entrées ciblant ces regex. Problème très répandu dans les bibliothèques JavaScript (validators), en PHP, Python, Java. Détection via outils comme redos-detector, Semgrep, Snyk.

GraphQL query complexity

GraphQL permet aux clients de spécifier la structure des réponses. Sans limites, une requête peut demander des milliers d'objets imbriqués à plusieurs niveaux de profondeur. Ces attaques contournent le rate limiting classique (une seule requête) mais épuisent le backend. Mitigation : query depth limiting, complexity analysis, cost-based limiting. Bibliothèques : GraphQL Armor, graphql-query-complexity.

Bombes de décompression

• ZIP bomb : fichier 42.zip de 42 Ko qui se décompresse en 4,5 Po en 9 niveaux imbriqués.
• XML billion laughs : 10 lignes de XML qui consomment des gigaoctets de mémoire au parsing via entités récursives.
• PDF bombs : documents PDF avec structures qui épuisent les parsers.
• Images bombes : PNG avec tableaux de palette malformés.

Hash collision attacks

Exploitation de structures de données hashées (dictionnaires, HashMap) en soumettant des entrées calibrées pour provoquer un maximum de collisions, transformant un algorithme O(1) en O(n²). Attaque classique contre les langages qui n'utilisent pas de hash randomization (problème largement mitigé depuis 2012 mais persiste sur des anciens systèmes).

Algorithmic complexity attacks

Soumission d'entrées qui déclenchent le pire cas algorithmique d'un traitement. Exemples : tri avec quicksort sur données adverses, expressions mathématiques qui provoquent des calculs exponentiels, parsers récursifs face à des profondeurs extrêmes.

Open redirects et SSRF avec boucles

Forcer un serveur à requêter des URL qui se redirigent en boucle ou chargent des ressources gigantesques. Moins directement du DoS mais peut saturer les ressources.

Pourquoi les DoS applicatifs sont si efficaces

• Très peu de requêtes nécessaires : parfois une seule.
• Trafic légitime en apparence : pas de signature volumétrique.
• Difficiles à détecter en amont : un WAF classique ne voit qu'une requête standard.
• Souvent non corrigés : les équipes dev ne testent pas systématiquement le pire cas.
• Amplification potentielle : cascade d'effets (CPU → timeouts → cascades d'erreurs sur tout le SI).

Détection et réponse

• Monitoring fin des métriques applicatives : pics CPU isolés, latence sur endpoints spécifiques, timeouts.
• APM (Application Performance Monitoring) : Datadog, New Relic, Dynatrace détectent les anomalies.
• Profiling sur endpoints coûteux : identifier ceux qui peuvent devenir des cibles.
• Tests de charge adverses : fuzz testing avec entrées malformées.
• Pentest spécifique DoS applicatif : tester les limites et les pires cas.

06 — ProtectionSe défendre contre les DoS

07 — LégalCadre juridique en France

Code pénal — articles 323-1 à 323-8

Les attaques DoS et DDoS sont qualifiées d'entrave au fonctionnement d'un système de traitement automatisé de données (STAD) :

• Article 323-2 : « Le fait d'entraver ou de fausser le fonctionnement d'un système de traitement automatisé de données est puni de cinq ans d'emprisonnement et de 150 000 € d'amende. »
• Article 323-3 : modification, suppression ou introduction frauduleuse — jusqu'à 7 ans et 300 000 €.
• Article 323-3-1 : détention ou offre d'outils conçus pour commettre ces infractions, peines équivalentes.
• Article 323-4-1 : aggravation si la cible est un STAD de l'État ou d'un OIV — jusqu'à 10 ans et 300 000 €.
• La tentative est punie au même titre que l'acte consommé.

Responsabilité individuelle dans un DDoS

Point souvent mal compris : participer à un DDoS coordonné (outil LOIC historiquement, campagnes NoName057, Killnet actuellement) engage la responsabilité pénale individuelle même sans compétences techniques. Chaque participant peut être poursuivi sur la base de l'article 323-2, même s'il n'est qu'un "clic" parmi des milliers d'autres. Plusieurs condamnations illustratives :

• PayPal 14 (USA, 2014) : 14 participants au DDoS Anonymous contre PayPal condamnés à amendes et probation.
• Condamnations en Europe de participants LOIC (Royaume-Uni, Pays-Bas, Espagne, Allemagne).
• En France, plusieurs dizaines de condamnations pour participation à DDoS depuis 2010.

Cadre international

• Convention de Budapest sur la cybercriminalité (2001, signée par ~70 pays) : oblige les signataires à criminaliser les attaques contre les systèmes informatiques, incluant les DoS.
• Computer Fraud and Abuse Act (USA) : base des poursuites aux États-Unis.
• Computer Misuse Act (Royaume-Uni) : équivalent britannique.
• Directive NIS2 : renforce les obligations de notification et protection pour les entités essentielles et importantes.

Stress testing légitime

Les services de stress testing légitimes existent (tests de charge sur vos propres infrastructures avec autorisation) mais la limite est mince avec les booters / stressers illégaux qui offrent un service DDoS contre paiement. Utiliser ces services contre un tiers, même sans intention malveillante déclarée, constitue un délit. La police française a participé à plusieurs opérations internationales de démantèlement de booters (opérations Power Off 2018, 2022, 2024).

Recours de la victime

• Plainte : auprès de la police ou gendarmerie, service spécialisé (OCLCTIC, SDLC en régions).
• Signalement : sur cybermalveillance.gouv.fr.
• Notification : ANSSI / CERT-FR pour entités essentielles, NIS2 impose 24h + 72h.
• Notification CNIL : sous 72h si violation de données personnelles associée.
• Cyber-assurance : la LOPMI 2023 exige plainte sous 72h pour l'indemnisation.

08 — FAQQuestions fréquentes

Combien de temps dure typiquement un DoS ?

Extrêmement variable. Les DoS applicatifs par exploitation peuvent durer jusqu'à ce que la vulnérabilité soit corrigée — quelques minutes à plusieurs heures selon la réactivité. Les DoS volumétriques mono-source sont généralement bloqués en minutes à heures par bannissement de l'IP source. Les DDoS organisés peuvent durer de quelques minutes (test de capacité) à plusieurs jours ou semaines (campagnes hacktivistes soutenues). Les attaques pro-russes contre des sites français depuis 2022 reviennent par vagues. Certaines attaques sont courtes mais répétées — plusieurs centaines d'épisodes par jour dans les cas extrêmes.

Peut-on détecter un DoS mono-source avant qu'il ne fasse tomber le service ?

Oui, avec du monitoring approprié. Les signaux précurseurs : augmentation du taux d'erreur sur des endpoints spécifiques, pics CPU ou mémoire sur le serveur, latence qui monte progressivement, nombre de connexions simultanées anormal, logs avec patterns de requêtes malformées. Un APM moderne (Datadog, New Relic) alerte typiquement dans les secondes qui suivent l'apparition d'une anomalie. Encore faut-il avoir configuré les alertes et avoir quelqu'un pour y répondre. Un SOC 24/7 permet une réaction rapide, mais les petites structures sans surveillance nocturne peuvent découvrir l'incident le lendemain matin.

Un DoS peut-il voler des données ?

Pas directement : le DoS attaque la disponibilité, pas la confidentialité. Mais il est souvent utilisé en diversion : pendant que les équipes de sécurité se concentrent sur la gestion du DoS, un attaquant peut mener discrètement une intrusion classique sur d'autres systèmes. Plusieurs incidents majeurs ont suivi ce scénario. Il faut donc maintenir la vigilance sur l'ensemble du SI pendant un DoS, pas uniquement sur la cible apparente. Certains attaquants ont aussi utilisé un DoS pour provoquer des redémarrages qui exposent temporairement des systèmes normalement sécurisés.

Mon hébergeur va-t-il me protéger automatiquement ?

Partiellement. Les grands hébergeurs (OVH, Scaleway, AWS, Azure, GCP) incluent une protection DDoS de base gratuite qui absorbe les attaques volumétriques. Mais cette protection ne couvre pas les DoS applicatifs qui exploitent des vulnérabilités de votre code. Pour les attaques sophistiquées ou très volumineuses, des offres payantes avancées existent (AWS Shield Advanced, Cloudflare Business/Enterprise, OVH Game). Pour une PME, l'ajout de Cloudflare gratuit devant son site apporte déjà une protection très significative. Vérifier les clauses du contrat d'hébergement : certains hébergeurs peuvent suspendre temporairement un client sous attaque massive si cela pénalise leur infrastructure.

Que faire immédiatement en cas de DoS ?

Actions dans l'ordre de priorité :

• Identifier : vrai DoS vs panne, source apparente, type (volumétrique, applicatif, protocole).
• Bloquer à la source si mono-source : règle pare-feu ou niveau CDN/WAF.
• Activer la protection DDoS si disponible (mode "sous attaque" Cloudflare par exemple).
• Contacter l'hébergeur et/ou FAI : ils peuvent aider au niveau supérieur.
• Scale out si possible : auto-scaling, renforts de capacité temporaires.
• Déployer des contre-mesures applicatives : limites, patchs temporaires.
• Communiquer : utilisateurs via status page, direction, éventuellement publiquement.
• Documenter en continu : preuves pour plainte, post-mortem.
• Déposer plainte : police ou gendarmerie, dans les 72h pour cyber-assurance.
• Notifier CERT-FR et autorités si entité régulée NIS2.