Fonctionnement des attaques DDoS de la couche 1 à 7 et protections possibles

Résumé exécutif

Une attaque par déni de service distribué (DDoS) vise à rendre un service, un réseau ou une infrastructure indisponible en provoquant une surcharge (bande passante, capacité de traitement, tables d’état, ressources applicatives), en s’appuyant sur de nombreux hôtes sources (botnets, infrastructures louées/compromises, IoT). Les DDoS ne sont pas un « type unique » d’attaque : ils se déclinent en familles (volumétriques, protocolaires, applicatives), souvent combinées (multi‑vecteurs), et exploitent des propriétés structurelles d’Internet (difficulté de distinguer trafic malveillant et « flash crowd », possibilité d’usurper des adresses source, existence de services UDP amplificateurs) ainsi que des goulots d’étranglement opérationnels (limites de liens, équipements, middleboxes, architectures applicatives).

L’alignement exact sur les couches OSI est une grille d’analyse (modèle), pas une séparation étanche : de nombreuses attaques « traversent » plusieurs couches (ex. un HTTP flood impacte à la fois L7, mais aussi L4 via les connexions et L3 via le volume). Dans ce rapport, la cartographie L1→L7 sert à relier : (a) ce que l’attaquant surcharge, (b) ce qu’on peut observer, (c) où et comment on peut mitiger.

Les défenses efficaces reposent presque toujours sur une stratégie en profondeur, combinant :

• réduction de surface (services exposés, endpoints, ports/protocoles),
• capacités d’absorption (réseau, Anycast/CDN, autoscaling),
• filtrage/limitation (ACL, policers/rate‑limit, SYN cookies, limites de connexions),
• atténuation en amont (RTBH, FlowSpec, scrubbing centers, coordination ISP),
• détection et orchestration (télémétrie, baselines, IDPS/NBA, automatisation),
• et une discipline de réponse à incident (runbook, communications hors bande, collecte d’éléments, post‑mortem).

Ce document décrit les mécanismes à un niveau analytique défensif et opérationnel (observabilité/mitigation). Il n’inclut pas de procédures d’attaque « prêtes à l’emploi », scripts, ni paramètres destinés à faciliter la mise en œuvre malveillante.

Définitions, objectifs et modèle de menace

Définition et objectifs d’un DDoS

• DDoS : « technique de déni de service utilisant de nombreux hôtes pour exécuter l’attaque ». L’intérêt de la distribution est d’augmenter fortement l’échelle et de compliquer la défense/attribution.
• DoS/DDoS : attaque visant à empêcher une cible de « faire un travail utile », souvent sans compromettre la cible elle‑même (pas nécessairement une intrusion), mais en la surchargeant.

Objectifs fréquents (non exhaustifs, dépendants du contexte) :

• indisponibilité (site, API, DNS, VPN, VoIP, jeux),
• extorsion (« ransom DDoS »),
• diversion (couvrir une compromission/fraude),
• pression économique (coûts cloud, perte de revenus),
• sabotage de l’expérience (latence, timeouts) et atteinte à l’image.

Taxonomie pratique : volumétrique, protocolaire, applicatif

Une classification largement utilisée en opérations consiste à distinguer :

• Bit‑intensive / volumétrique (Tbps) : saturation de liens (« pipes ») et de la capacité d’acheminement.
• Packet‑intensive (pps) : surcharge des capacités de traitement paquet (CPU, ASIC limits, files, tables d’état), souvent L3/L4.
• Request‑intensive (rps) : surcharge des applications/APIs avec des requêtes « complètes », souvent L7.

Les campagnes modernes combinent souvent ces axes (multi‑vecteurs) pour épuiser à la fois les systèmes automatiques et l’équipe humaine (fatigue/erreurs, escalades).

Botnets, IoT, cloud et industrialisation

• Botnets IoT : Mirai (et dérivés) a montré la capacité d’agréger des centaines de milliers d’appareils compromis (souvent IoT/embarqués) pour des DDoS massifs, avec une dynamique rapide de propagation
• Infrastructure cloud abusée : les rapports récents soulignent le rôle accru des plateformes cloud/vm facilement provisionnables et, plus largement, de « sources » multiples (ASNs divers), ce qui complique les contre‑mesures basées sur des listes simples.

Exemples (illustratifs) :

• attaques hyper‑volumétriques et campagnes multi‑vecteurs (records Tbps et Mrps) observées à grande échelle sur des réseaux mondiaux.
• attaques multi‑protocole (SSDP/CLDAP/DNS/NTP) agrégées dans un même pic, observées chez des hyperscalers.

Mécanismes d’attaque par couche OSI

Repère OSI

Le modèle OSI comporte 7 couches (Application, Présentation, Session, Transport, Réseau, Liaison de données, Physique). Les DDoS « Internet » typiques se situent surtout à L3–L7, alors que L1–L2 sont souvent des attaques de proximité/locales (LAN, radio, accès physique) mais peuvent produire un déni de service tout aussi réel au niveau métier.

Couche physique

Cible typique : disponibilité du médium (fibre/cuivre/radio), énergie, climatisation, équipements physiques, capacité brute de lien suggérée par la couche.
Pourquoi c’est pertinent en DDoS : même si la « distribution » est moins directe, un effet DDoS peut se traduire par saturer des liens physiques (volumétrique) ou rendre un site injoignable par incident physique (panne, coupure, sabotage), et doit être traité dans les plans de continuité.

Techniques (niveau conceptuel)

• Saturation de liens (effet « volumétrique ») entraînant congestion/discards en amont (lien Internet, interco datacenter).
• Défaillance/panne/surcharge d’alimentation ou de refroidissement sur équipements critiques (effet indisponibilité).

Indicateurs observables (exemples)

• Utilisation lien ≈ 100%, erreurs interfaces, drops/queues saturées, perte de paquets généralisée, hausse latence, alarmes optiques/énergie (selon environnement).
• Symptômes de service « down » sans signaux applicatifs cohérents (ex. tout tombe car le site est isolé).

Impacts

• Indisponibilité complète (aucune requête utile n’atteint l’infra) ; effets en cascade (BGP sessions instables, timeouts).

Exemple réel (ordre d’idée)

• Attaques « records » Tbps visent précisément à saturer des capacités d’acheminement/liaisons ; elles sont mécaniquement visibles au niveau transport réseau (link saturation).

Couche liaison de données

Cible typique : commutation/bridging, tables MAC (CAM), broadcast/multicast, protocoles L2 de topologie (STP), ARP/ND (frontière L2/L3).
Particularité : souvent limité à un domaine de broadcast (LAN/datacenter). Mais l’impact sur un service critique peut être total.

Techniques

• MAC/CAM table overflow (MAC flooding) : saturation de la table MAC d’un switch peut provoquer un comportement de diffusion (flood) de trames, dégradant performance et confidentialité (trames visibles au mauvais endroit) et pouvant mener à DoS interne. (Description technique/formation, switch qui « flood » quand la table/structure est saturée.)
• Tempêtes ARP / sur‑sollicitation ARP : un taux élevé soutenu d’ARP peut dégrader fortement un équipement et provoquer un DoS (ex. traitement ARP saturé, file interne).
• Attaques STP/prise de rôle root (DoS topologique) : un équipement participant au STP peut influencer la topologie (changement de root), forçant recalculs et dégradant le chemin (ex. bascule sur lien plus faible), jusqu’à provoquer pertes et indisponibilité.[^34]

Workflow d’attaque (conceptuel)
1) L’attaquant (ou une machine infectée sur le LAN) génère un volume anormal de trames/contrôles L2 (MAC/ARP/STP).
2) Le switch/routeur/contrôleur L2 doit apprendre/traiter, remplit des tables ou déclenche recalculs.
3) La capacité de commutation/contrôle est dépassée : flood, errdisable, congestion, ou instabilité de topologie.

Ressources requises (profil attaquant)

• Accès au segment L2 (direct, via compromission interne, ou via équipement adjacent).
• Peu de bande passante « Internet » nécessaire : l’attaque est locale et vise les mécanismes L2.

Indicateurs

• Hausse brutale broadcast/multicast, logs STP/PortFast/BPDU, fluctuations topologiques, ARP drops et messages de queue drop/ARP process saturé (selon plateforme).

Impacts

• Indisponibilité locale (VLAN, rack, site) ; pertes intermittentes difficiles à diagnostiquer ; instabilité réseau.

Exemples

• Cisco documente qu’un équipement participant au STP avec priorité plus basse peut perturber la topologie (DoS) et que BPDU Guard vise à empêcher ces scénarios sur ports PortFast.
• Cisco publie aussi des cas où un taux élevé et soutenu d’ARP peut mener à un « broadcast storm » et un DoS sur certains équipements (congestion/queue drops, perte de management)

Couche réseau

Cible typique : IP (routage), capacité paquet (pps), reassembly/fragmentation, infrastructures partagées (routeurs, firewalls, NAT).
C’est souvent la zone des attaques « packet‑intensive » et une partie des volumétriques.

Techniques

• Flood IP/ICMP : saturation pps et files.
• Attaques de fragmentation / reassembly exhaustion : en bombardant la cible de fragments, l’attaquant force l’allocation mémoire/temporisation de réassemblage ; des fragments non réassemblables peuvent remplir des buffers temporaires et épuiser la mémoire.
• Attaques visant l’infrastructure : certains comportements peuvent induire surcharge sur middleboxes (firewalls stateful, systèmes de mitigation, etc.), ce qui se traduit « réseau » côté victime.[^3]

**Workflow (conceptuel) – fragmentatio 1) Production de trafic fragmenté à grande échelle.
2) La cible (ou un équipement en chemin) tente de réassembler ou de maintenir des fragments en attente.
3) Saturation mémoire/CPU → crash, lenteur, pertes de paquets.

Ressources requises

• Réseau distribué (botnet/infra) pour volume/pps, ou vecteur d’amplification (voir plus bas).
• Les attaques pps exigent souvent beaucoup de sources pour éviter d’être limitées par un seul lien.

Indicateurs

• Hausse des fragments IP, accroissement de la mémoire utilisée pour reassembly, montée des drops, CPU routeur, latence, jitter.
• Difficulté de filtrer « non‑initial fragments » sans dommage collatéral (risque faux positifs sur trafic légitime fragmenté).

Impacts

• Dégradation réseau globale, indisponibilité de services dépendants, instabilité d’équipements.

Exemple

• NETSCOUT décrit ces attaques comme volumétriques, combinant volume et consommation de ressources de réassembly, avec difficultés de tri lorsque les fragments ne portent pas toutes les informations de protocole/ports.

Couche transport

Cible typique : TCP/UDP, état de connexion, tables NAT/firewall/load balancer, files d’attente, ports.
C’est le cœur des attaques protocolaires classiques (SYN/ACK/UDP floods) et d’une part majeure des amplifications (souvent UDP).

TCP SYN flood et épuisement de tables d’état

Mécanisme : le SYN flood exploite la rétention d’état des TCP servers après réception d’un SYN (semi‑connexions). L’objectif est d’épuiser les ressources (backlog, mémoire, structures) pour empêcher l’établissement de connexions légitimes.

Workflow (conceptuel)
1) Envoi massif de segments SYN vers un service en écoute.
2) Le serveur crée/maintient de l’état pour des demi‑connexions.
3) Saturation du backlog/state → connexions légitimes rejetées/timeout.

Ressources requises

• Forte cadence pps (pas nécessairement Tbps), souvent distribuée.

Indicateurs

• Ratio SYN/ACK anormal, backlog saturé, augmentation des retransmissions, logs kernel/stack, hausse des timeouts.
• Pertes côté clients, mais service « up » (symptôme trompeur).

Impact typique

• Indisponibilité TCP (services web, API, VPN), surcharge CPU sur équipements stateful.

Exemples

• RFC 4987 décrit le principe et les mitigations courantes, dont des techniques comme SYN cookies (avec analyses de compromis).
• Les grands fournisseurs cloud évoquent SYN cookies, rate limiting et connection limits comme techniques standard de mitigation L3/L4.

UDP/ICMP floods

Mécanisme : mesures « brutes » pour saturer capacité de traitement ou bande passante ; UDP étant sans état, les floods peuvent être très « simples » côté trafic, mais très coûteux côté défense (filtrage/inspection).

Indicateurs

• Hausse massive d’UDP/ICMP pps, drops sur edge, saturation liens.

Exemples

• Microsoft décrit des pics multi‑Tbps et multi‑vecteurs, dont des attaques UDP (et UDP reflection) sur des ports utilisés par des services variés.

Couche session

Cible typique : gestion de sessions (au sens OSI) et, en pratique, état au‑dessus du transport maintenu par des middleboxes/proxys (reverse proxies, API gateways, load balancers), ou par des protocoles orientés session (ex. VoIP/SIP dans certains environnements).

Techniques (conceptuel)

• Épuisement de tables de sessions sur reverse proxy / LB : multiplication d’ouvertures/maintien de sessions, redirections, affinité (sticky sessions), quotas par client.
• Attaques de « churn » (ouverture/fermeture répétée) : stress sur allocateurs, garbage collection, caches de sessions.

Indicateurs

• Explosion du nombre de sessions actives et du taux de création/expiration ; hausse de latence, erreurs de backend.

Impacts

• Les reverse proxies et LBs deviennent le goulot d’étranglement : même si l’origine est dimensionnée, la « porte d’entrée » sature.

Exemples

• Les rapports cloud indiquent que la défense DDoS se fait « en pipeline distribué » au bord du réseau, précisément pour éviter que quelques points de contrôle (gateways) ne concentrent le risque.

Couche présentation

Cible typique : transformation/présentation des données, chiffrement (TLS), négociation cryptographique et coûts CPU associés.
En pratique moderne, TLS est le sujet dominant ici.

Techniques

• Exhaustion TLS/SSL : surcharge CPU/cryptographique (handshakes, négociations, parfois renégociations selon contextes), épuisement de terminators TLS, saturation de files/threads de chiffrement.
• Attaques sur paramètres de négociation / diversité des ciphers : complique la mise en cache et les optimisations, augmente le coût côté serveur (selon implémentations).

Workflow (conceptuel)
1) L’attaquant provoque un volume élevé d’établissements cryptographiques ou de négociations coûteuses.
2) Terminateur TLS (LB/WAF/reverse proxy) consomme CPU et devient le bottleneck.
3) L’application ou le frontal échoue (timeouts) malgré bande passante « suffisante ».
(Le détail dépend des stacks, ciphers, architectures, et est donc non spécifié ici.)

Indicateurs

• CPU sur terminateurs TLS, hausse du taux de handshakes, baisse du taux de sessions réutilisées, hausse latence handshake, erreurs 5xx/handshake failures.

Exemples

• Les guides cloud mentionnent explicitement des protections L3‑L4 fortes et des techniques de mitigation (SYN cookies, rate limiting, connection limits) et recommandent WAF en complément pour couverture L3‑L7, ce qui inclut la gestion des flux chiffrés au niveau plateforme.

Couche application

Cible typique : logique métier, endpoints coûteux (requêtes DB, recherche), caches, quotas, rate limits, ressources server (threads, pools), DNS (résolution), et « asymétrie » coût requête vs coût réponse.

HTTP(S) floods

Mécanisme : inonder un serveur d’un grand nombre de requêtes applicatives (souvent difficiles à distinguer du trafic réel), jusqu’à saturer capacité de traitement ou dépendances (DB, cache).

Workflow (conceptuel)
1) Génération distribuée de requêtes « valides » (syntaxe correcte).
2) Contournement partiel des contrôles simples (rotation d’IP/UA, diversité de chemins).
3) Surcharge CPU/app/DB, montée 5xx/timeouts, files saturées.

Ressources requises

• Soit botnet important (IoT, VMs), soit trafic loué/relayé.
• Souvent moins de bande passante totale qu’une attaque volumétrique, mais plus de sophistication. Indicateurs
• Augmentation rps, ratio endpoints « chers », taux de cache hit en baisse, hausse latence p95/p99, erreurs 429/5xx, saturation pools DB.

Exemples

• Cloudflare décrit les HTTP floods comme attaques L7 difficiles à distinguer, et mentionne challenges/WAF/réputation comme axes de mitigation

Low-and-slow (Slowloris / slow HTTP)

Mécanisme : épuiser les pools de connexions/threads en maintenant des connexions ouvertes « lentement », avec très peu de bande passante. Défendre est délicat car le trafic ressemble à des clients lents.

Indicateurs

• Forte concurrence de connexions en cours, faible débit par connexion, temps de réponse qui s’allongent, backlog applicatif.

Exemples

• Les docs de fournisseurs de protection DDoS expliquent la mitigation via reverse proxy (buffering, ne pas relayer tant que la requête n’est pas complète) et via empreintes/règles éphémères.

Attaques DNS côté application (DNS flood / DNS amplification)

Deux réalités distinctes :

• DNS flood : beaucoup de requêtes vers serveurs DNS (authoritatifs ou résolveurs) → saturation.
• DNS amplification/reflection : utilisation de résolveurs ouverts comme « amplificateurs » : l’attaquant usurpe l’adresse de la victime (spoofing), envoie une petite requête, et le résolveur renvoie une réponse plus grosse à la victime.

Mécanisme DNS amplification (résumé) : dépend à la fois (a) de résolveurs ouverts accessibles et (b) de la possibilité d’usurper l’adresse source ; les réponses étant « légitimes » et provenant de serveurs valides, le filtrage peut être difficile au niveau victime.

Indicateurs

• Réponses DNS sans requête correspondante (asymétrie request/response), hausse soudaine de traffic DNS entrant, saturation UDP, logs de résolveurs (si on est « amplificateur involontaire »).

Exemple

• US‑CERT décrit l’attaque DNS amplification et les mesures : éliminer les résolveurs ouverts, vérifier source IP, limiter récursion/RRL, etc.

Amplification / reflection multi‑protocoles (NTP, SSDP, CHARGEN, CLDAP, memcached…)

Principe commun :
1) un service (souvent UDP) répond beaucoup plus qu’il ne reçoit (amplification),
2) l’attaquant usurpe l’adresse source pour que la réponse soit envoyée à la victime (reflection),
3) distribution → volume total très élevé.

NTP amplification : CERT explique l’abus de serveurs NTP vulnérables/paramétrés par défaut, via messages de contrôle pouvant amplifier fortement ; mitigation via mise à jour et restrictions requêtes, et filtrage anti‑spoofing. SSDP amplification : exemples officiels de CERT nationaux décrivent SSDP/UPnP comme vecteur DrDoS ; défense via filtrage, durcissement, coordination ISP, etc. CHARGEN : services legacy ne devraient pas être exposés ; peuvent être abusés pour amplification ; mitigation : désactiver/restreindre. CLDAP reflection : AWS rapporte une attaque CLDAP reflection atteignant 2,3 Tbps (cas volumétrique record à l’époque), illustrant l’usage de vecteurs UDP reflection à très grande échelle. memcached (UDP) amplification : GitHub décrit une attaque d’amplification memcached culminant à 1,35 Tbps ; ils observent le rôle du spoofing et la difficulté de mitigation sans partenaires de transit plus larges.

Indicateurs génériques de reflection/amplification

• Beaucoup de trafic entrant depuis des serveurs tiers « innocents » (réflecteurs), diversité d’ASNs, paquets/flux qui ne correspondent pas aux requêtes sortantes ; logs de trafic anormal côté provider.
• Forte dépendance à l’anti‑spoofing : si le spoofing est réduit, l’efficacité de ces attaques diminue.

Détection, observabilité et signaux de monitoring

La détection efficace repose sur une combinaison de métriques « macro » (réseau) et « micro » (application), corrélées à une baseline (comportement normal).]

Métriques recommandées par famille de pression

• Pression bande passante (Tbps) :

  • Utilisation liens (edge/transit), drops, congestion, latence inter‑sites, saturation upstream.

• Pression capacité de traitement (pps) :

  • pps par interface, CPU routeurs/firewalls, drops de queues, saturation tables (conntrack, NAT), erreurs kernel/stack, ratio SYN/ACK (si TCP).

• Pression applicative (rps) :

  • rps global et par endpoint, latence (p95/p99), 4xx/5xx, saturation pools (threads, DB connections), cache hit ratio, taux de timeouts.

Exemple concret de détection « simple mais robuste » : GitHub indique avoir été alerté par une anomalie dans le ratio trafic entrant/sortant sur transit (symptôme typique d’un afflux non corrélé au trafic utile).

Télémétrie réseau et sécurit

• NetFlow/IPFIX : l’export de « flow telemetry » permet une visibilité agrégée (qui parle à qui, combien, quand), utile pour identifier sources, ports, asymétries, et guider des politiques de filtrage/RTBH/FlowSpec.
• IDPS/NBA : NIST distingue notamment les systèmes de détection réseau, sans fil, comportement réseau (NBA) et hôtes ; ces approches participent à l’identification d’anomalies et au déclenchement de réponses adaptées.

Signaux par couche

• L1 : saturation lien, erreurs physiques, alarmes infra.
• L2 : broadcast storms, logs STP/BPDU, taux ARP, anomalies MAC learning.
• L3 : fragments IP, hausse ICMP/UDP, CPU routeur, drops.
• L4 : SYN backlog, conntrack table, retransmissions, ratio SYN/ACK.
• L5–L7 : sessions actives, handshake TLS, rps, endpoints « chers », cache miss, DB saturation.

Protections et mitigations par couche

La mitigation DDoS est un problème d’architecture et d’opérations autant que de filtrage. RFC 4732 rappelle qu’il est en principe impossible de distinguer parfaitement un DoS subtil d’un « flash crowd » : l’objectif est de rendre l’attaque plus coûteuse et de préserver le service « suffisamment ».

Couche physique

Mécanismes

• Redondance liens/énergie, diversité opérateurs et chemins.
• Capacité de sur‑provisionnement et plans de contournement (failover).

Déploiement / considérations

• Contrats multi‑ISP, multi‑pop, capacité réservée, tests de bascule.
• Coût élevé (CAPEX/OPEX) mais réduit le risque de perte totale.

Limites / faux positifs

• Ne « filtre » pas l’attaque : absorbe ou contourne ; ne protège pas si l’attaque dépasse toute capacité.

Couche liaison de données

Mécanismes

• Port security / limitations L2 (contrôle du nombre d’adresses MAC apprises, etc.) pour limiter impacts de MAC flooding (selon plateformes).
• BPDU Guard / protections STP : désactive un port PortFast recevant des BPDUs, empêchant qu’un hôte prenne le contrôle STP et provoque un DoS topologique.
• Contrôle broadcast/multicast (« storm control ») et politiques ARP/ND (selon vendor).

Déploiement

• Très dépendant du matériel, nécessite prudence et tests (risque coupure d’accès légitime).

Limites / risques

• Faux positifs : un équipement légitime mal branché peut être coupé (errdisable).
• Les protections L2 ne traitent pas les DDoS Internet mais protègent des DoS internes destructeurs.

Couche réseau

Mécanismes

• Filtrage de fragments anormaux, policies de rate‑limit sur classes de trafic susceptibles.
• Détection + mitigation en amont (scrubbing, anycast) pour éviter saturation locale.

Limites

• Bloquer des fragments « non‑initiaux » peut casser du trafic légitime ; trade‑off à gérer, surtout en crise.

Couche transport

SYN cookies / protections TCP

• RFC 4987 décrit l’intérêt des mitigations TCP (dont SYN cookies) pour réduire l’efficacité du SYN flood ; certaines ont des effets de bord et doivent être comprises/paramétrées correctement.
• Les plateformes cloud mentionnent SYN cookies, rate limiting, connection limits dans leurs défenses standard.

Rate limiting / connection limiting

• Vise à plafonner l’impact d’un flux ou d’une classe (par IP, par préfixe, par port, par protocole), en acceptant un risque de chuter du trafic légitime (faux positifs) lors d’une crise

Limites

• Les attaques distribuées contournent facilement des limites « par IP ».
• Certaines limites peuvent amplifier l’impact sur des clients NATés (plusieurs clients derrière une IP).

Couche session et présentation

Reverse proxy, buffering, offload

• Interposer un reverse proxy / CDN / WAF permet de terminer les connexions côté edge, d’appliquer des règles et de ne relayer vers l’origine que des requêtes « propres », ce qui est une défense clé contre low‑and‑slow et certaines pressions TLS/HTTP.[^47]

TLS offload / capacité crypto

• Déplacer/accélérer la terminaison TLS sur des équipements dimensionnés, ou sur une couche réseau mondiale, réduit le risque que l’origine (ou un LB unique) soit le bottleneck.[^44]

Limites / faux positifs

• Challenges et protections « bots » peuvent impacter l’UX, casser des clients légitimes (APIs, IoT).
• Mauvaise configuration de TLS offload/routage peut créer des points uniques de défaillance.

Couche application

WAF et règles applicatives

• OWASP définit le WAF comme un pare‑feu applicatif HTTP appliquant un ensemble de règles à la conversation HTTP (souvent en reverse proxy).
• Les WAF peuvent aider à filtrer attaques L7 (floods, patterns, réputation), mais nécessitent tuning pour limiter faux positifs (trafic légitime bloqué) et faux négatifs.

Défense « par empreintes » (fingerprinting) et règles éphémères

• Certains systèmes automatisés génèrent des empreintes en temps réel et installent des règles temporaires (« ephemeral mitigation rules ») quand un pattern est détecté ; ils peuvent drop/rate‑limit/challenge selon la nature.[^47]

Réduction d’asymétrie

• Caching agressif, optimisation endpoints coûteux, quotas par token/API key, priorisation, dégradation contrôlée (« graceful degradation »), file d’attente.

Limites

• Les meilleurs flood L7 miment des utilisateurs réels ; distinguer peut exiger plus de contexte (auth, comportement) et du ML/télémétrie.

Mitigation en amont : ISP, BGP, RTBH, FlowSpec, scrubbing centers, Anycast

RTBH (blackholing)

• RFC 3882 décrit l’usage de communautés BGP pour déclencher un blackhole sur une destination (bloquer trafic vers une cible) et aussi des techniques de « sinkhole tunnels » pour attirer le trafic vers un routeur de sinkhole pour analyse.
• Trade‑off : RTBH peut « sauver le reste » d’un réseau en sacrifiant la cible (indisponible mais confiné). C’est une option de crise.

Source Address Validation / anti‑spoofing (BCP 38 / BCP 84)

• Les attaques de reflection/amplification reposent sur le spoofing ; RFC 2827 propose le filtrage d’entrée (ingress filtering) pour empêcher la propagation de paquets à source usurpée depuis un ISP.
• RFC 3704 (BCP 84) discute les mécanismes d’ingress filtering en contexte multihoming (difficultés et approches opérationnelles).
• RFC 8704 propose des techniques uRPF plus flexibles visant à réduire les faux positifs et faciliter le déploiement SAV.

BGP FlowSpec

• FlowSpec permet de diffuser des règles de filtrage/traitement de flux (match sur champs, actions : drop, rate‑limit, redirect) et est utilisé dans certaines architectures de mitigation

Scrubbing centers / providers externes

• Une approche courante : détourner (BGP diversion) le trafic vers des points de présence (PoPs) où il est « nettoyé » (scrubbed), puis renvoyé vers la cible via tunnel/liaison dédiée ; cela nécessite préparation (on‑demand vs always‑on)

Anycast

• Anycast répartit la charge sur plusieurs PoPs partageant une même IP ; combiné à l’ingénierie de trafic, cela aide à absorber/diluer un DDoS et à éviter qu’un PoP unique ne sature.

BGP hardening (résilience du contrôle‑plane)

• Les protections de sessions BGP (filtrage control‑plane, TTL, options d’authentification TCP) relèvent de la résilience ; RFC 7454 synthétise des mesures opérationnelles de sécurité BGP.

Risques / trade‑offs

• Coût (services scrubbing, capacité globale), complexité (BGP, tunnels, orchestration), risques d’erreur (blackhole trop large, FlowSpec mal diffusé).
• Faux positifs : filtrage agressif peut couper trafic légitime — surtout dangereux si appliqué en amont à grande échelle.

Gouvernance et réponse : communications, juridique, forensique

• NIST rappelle l’intégration de la réponse à incident dans la gestion du risque, avec un cycle (détection/réponse/récupération) soutenu par préparation et amélioration continue.
• GEANT souligne la nécessité de processus de communication définissant qui contacter, comment (y compris canaux hors bande), et les autorisations nécessaires lors d’une attaque.
• En cas d’incident significatif : conservation d’éléments (logs, captures, métriques), coordination ISP/anti‑DDoS, notification des autorités compétentes selon juridiction et obligations contractuelles/réglementaires. (Détails juridiques : non spécifiés, dépend du pays/secteur.)[^22][^37]

Tableau comparatif mitigations vs types d’attaque

Lecture : « efficacité » = typiquement utile (faible/moyenne/forte) si correctement déployé ; la réalité dépend de votre architecture, du volume, et des vecteurs multi‑couches.

Playbook de mitigation et runbook de réponse à incident

Préparation

• Définir « ce qui doit rester disponible » (SLO/SLA), l’ordre de priorité (DNS, auth, API, site).
• Mettre en place télémétrie (rps/pps/Tbps), alertes, dashboards, et baselines.
• Pré‑négocier les actions avec ISP/anti‑DDoS (contacts 24/7, procédures RTBH/FlowSpec/scrubbing).
• Préparer communications hors bande (messagerie/phone) et un protocole d’escalade.
• Tester les bascules (on‑demand → scrubbing, CDN failover, runbooks) en contexte contrôlé (exercices).

Détection et qualification (triage)

1) Confirmer incident (symptômes utilisateurs vs monitoring).
2) Classer la pression dominante : Tbps / pps / rps. 3) Identifier surfaces touchées : IP/port, service, POP/region, endpoints, DNS.
4) Vérifier s’il s’agit d’un faux positif (flash crowd) : RFC 4732 rappelle la difficulté fondamentale ; on cherche donc des signaux d’anomalie (asymétrie ingress/egress, patterns, sources improbables).

Mitigation immédiate

• Activer protections « sûres » à faible risque :

  • cache/CDN si possible,
  • rate‑limit modéré sur endpoints non critiques,
  • augmentations de capacité (autoscale) si la plateforme le permet.

• Si volumétrique/pps : escalader vers mitigation en amont (scrubbing/ISP).

• Si SYN flood : activer/ajuster SYN cookies et limites connexions si disponibles, en surveillant l’impact sur clients légitimes.

• Si reflection/amplification : coordonner filtrage amont, analyser vecteur (DNS/NTP/SSDP/CLDAP/memcached), vérifier exposition interne (ne pas être amplificateur).

Stabilisation et récupération

• Surveiller : baisse des erreurs (5xx), retour latence p95/p99, stabilité des liens, normalisation des tables.
• Ajuster finement : déplacer l’effort de « bloquer large » vers « filtrer précis » (empreintes, règles temporaires, WAF tuning).
• Maintenir un canal de communication continu (tech + management) ; GEANT insiste sur la difficulté de communiquer pendant un DDoS sans canaux hors bande.

Post‑incident

• Conserver preuves (métriques, logs, éventuelles captures, tickets ISP).
• Cartographier vecteurs et faiblesses : surface exposée, absence SAV/BCP38, manque d’automatisation, goulots LB/TLS/app.
• Mettre à jour runbook, baselines, seuils, contrats (capacité scrubbing), et plan de tests.