Attaques DDoS: types, symptômes et mitigation

17 février 2026 • 8 min read

Le DDoS n’est pas un phénomène nouveau, mais il est devenu beaucoup plus simple, moins cher et plus facile à faire évoluer. Autrefois, quelques serveurs mal configurés ou un petit botnet suffisaient à perturber un service. Aujourd’hui, on voit régulièrement des attaques capables de saturer des liens en une fraction de seconde, de submerger des pare-feux ou de mettre à genoux des applications avec des requêtes qui semblent “normales”.

Cet article n’a pas vocation à faire peur. Il vise à donner du contexte: ce qu’est vraiment un DDoS, quelles classes d’attaque comptent en pratique, comment les repérer en production, et quelles contre-mesures valent l’effort.

Qu’est-ce que le (D)DoS?

Dans une attaque de déni de service (DoS), un attaquant cherche à rendre un service inutilisable non pas en volant des données, mais en le surchargeant ou en épuisant ses ressources. La cible est la disponibilité: ton site ne charge plus, ton API time-out, ton gateway VPN n’accepte plus de sessions, ou tes resolvers DNS n’arrivent plus à suivre.

Le “D” de Distributed signifie que le trafic ne vient pas d’une seule source, mais de nombreuses. Cela peut être un botnet d’appareils compromis, une infrastructure légitime (reflection/amplification) ou un mélange des deux. Pour toi, opérateur, le résultat se ressemble: tu ne fais pas face à un seul attaquant, mais à une inondation distribuée.

Motivation: pourquoi lancer des attaques DDoS?

Les motivations sont souvent peu spectaculaires, mais efficaces:

Extorsion: “Paye, ou on vous remet à terre.”
Activisme/politique: visibilité, message, perturbation.
Distraction: un DDoS peut occuper l’équipe pendant qu’autre chose se passe en parallèle.
Concurrence/sabotage: lors de moments critiques (ticketing, releases, lancements), même une courte indisponibilité fait mal.
Pression sur les coûts: toutes les attaques ne visent pas une panne totale; parfois l’objectif est d’augmenter les coûts cloud, la charge support ou le stress opérationnel.

Les couches importantes (et pourquoi elles comptent)

On décrit souvent le DDoS par couches, car la couche t’indique quels signaux observer et quelles défenses sont possibles.

Couche 3 (IP): d’où ça vient et où ça va.
Couche 4 (TCP/UDP): ports, connexions, handshakes, état.
Couche 7 (Application): requêtes HTTP(S), APIs, endpoints métier.
“Couche 8” (logique métier): pas officiel, mais très réel: une logique coûteuse dans l’application, exploitable.

Point clé: une défense parfaite en couche 3/4 peut quand même échouer contre une attaque en couche 7, car les requêtes peuvent paraître légitimes et ne devenir coûteuses qu’une fois dans l’application.

Classe d’attaque 1: volume et amplification (souvent UDP)

Les attaques volumétriques visent à submerger la bande passante ou le traitement de paquets (pps). Un amplificateur classique est la reflection/amplification:

L’attaquant envoie de petites requêtes vers des serveurs accessibles publiquement (par exemple des resolvers DNS ouverts).
Il spoofe l’adresse source et met l’IP de la victime comme “source”.
Ces serveurs répondent avec des réponses bien plus grosses vers la victime.

Si une requête de 100 octets déclenche une réponse de 1 000 octets, tu as déjà un facteur 10. Selon le protocole et le payload, le facteur peut être bien plus élevé. Le problème: du point de vue de la victime, le trafic vient de services “normaux” qu’on n’a pas envie de bloquer.

Point important: l’amplification repose souvent sur le spoofing d’IP source. D’où l’importance du filtrage d’entrée (BCP 38). Si les fournisseurs bloquent systématiquement les adresses source forgées à la périphérie, ce vecteur devient beaucoup plus difficile.

Classe d’attaque 2: épuisement du protocole et de l’état (TCP/couche 4)

Tout DDoS ne cherche pas à maximiser la bande passante. Souvent, il est plus efficace de créer de l’état sur la cible jusqu’à remplir des tables ou épuiser des ressources.

Exemple classique: un SYN flood sur TCP:

Normalement, TCP établit une connexion via le three-way handshake (SYN -> SYN/ACK -> ACK).
Dans un SYN flood, l’attaquant envoie d’énormes quantités de SYN, mais l’ACK final n’arrive jamais.
Le serveur conserve de nombreuses connexions à moitié ouvertes (state) et réessaie jusqu’aux timeouts.

Cela consomme de la mémoire et du CPU, et peut aussi impacter le trafic sortant. Et même avec une bande passante confortable: une fois le suivi de sessions plein, la panne est proche.

Catégorie proche: les attaques low and slow. L’attaquant ouvre de vraies connexions et les garde ouvertes avec un trafic minimal, jusqu’à atteindre les limites du web server ou du load balancer. C’est parfois beaucoup moins visible qu’un gros pic de trafic.

Classe d’attaque 3: couche 7 et “couche 8” (HTTP, APIs, endpoints coûteux)

Les attaques couche 7 sont souvent les plus frustrantes, car elles se distinguent mal du trafic légitime. Exemples:

HTTP floods: beaucoup de requêtes vers des pages dynamiques, des endpoints de recherche ou des flux de login.
Slowloris/slow headers: connexions maintenues ouvertes en envoyant très lentement des headers ou des bodies.
Logique métier “coûteuse”: endpoints qui déclenchent des requêtes DB, des appels à des APIs externes, de la génération PDF, de la cryptographie ou même des workflows d’AI/agents.

Le truc n’est pas forcément “plus de trafic”, mais plus de travail par requête. Une petite quantité de trafic bien ciblé peut coûter plus cher qu’une grosse vague de GET statiques en cache.

Comment détecter un DDoS en production?

Si tu ne regardes que CPU et RAM, tu verras certains attaques trop tard. En pratique, une baseline plus quelques métriques robustes aident énormément:

Trafic: bps et pps au niveau edge (routeur, pare-feu, load balancer).
Métriques de connexion: nouvelles connexions/s, sessions ouvertes, SYN backlog, handshakes TLS/s.
Métriques HTTP: RPS, latence (p95/p99), ratios 4xx/5xx, timeouts.
Symptômes upstream: perte de paquets, RTT en hausse, liens saturés, événements BGP.
Signaux logs et WAF: chemins inhabituels, headers invalides, requêtes incomplètes, user agents/patterns suspects.

Le plus important est simple: il te faut une baseline. Sans baseline, tout est “beaucoup”. Avec une baseline, tu vois tout de suite que, par exemple, les “petits paquets” ou les “requêtes incomplètes” dévient fortement du normal.

Mitigation: ce qui marche vraiment en pratique

Il y a deux approches: make (construire soi-même) ou buy (utiliser un service). Pour la plupart des équipes, “buy” est plus réaliste, car la mitigation DDoS devient vite un sujet qu’on ne peut pas gérer “à côté”.

1) Mettre quelque chose devant l’app: CDN/WAF/anti-DDoS

Pour les sites et APIs, c’est souvent la mesure la plus efficace:

Les réseaux Anycast répartissent le trafic sur de nombreux sites.
Les règles WAF filtrent des patterns évidents en couche 7.
Bot management, rate limits et challenge/response réduisent les attaques “bon marché”.

Important: toutes les attaques ne passent pas par HTTP. Si tu exposes des services comme VPN, VoIP, serveurs de jeu ou d’autres protocoles UDP, il faudra d’autres couches de protection selon ton architecture.

2) Bien régler rate limiting et timeouts

Simple, mais efficace si c’est bien fait:

ICMP/“ping”: limiter, ne pas interdire totalement (utile pour le troubleshooting).
HTTP: limiter par IP/token/route, surtout sur les endpoints coûteux.
Requêtes lentes: timeouts stricts pour headers/bodies incomplets.

Exemple (Nginx, très simplifié) de limites par route:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

Ce n’est pas une solution miracle, mais ça change l’économie: les attaques “bon marché” deviennent plus difficiles.

3) Architecture: découpler le travail coûteux

Un DDoS couche 7 ne touche pas toujours la bande passante. Il touche les endroits où une seule requête coûte disproportionnellement cher. Et dans des setups “normaux”, il y en a beaucoup: login, recherche, exports PDF, rapports, uploads, requêtes DB complexes, appels à des APIs externes.

Exemple courant: un portail client a un bouton d’export (“facture en PDF”, “générer un rapport”, “tout télécharger en ZIP”). En temps normal, quelqu’un clique dessus toutes les quelques minutes. En attaque, l’endpoint est déclenché des centaines ou milliers de fois par minute. Le problème n’est pas le débit; ce sont le CPU (rendering), la base (queries) et les worker pools (threads/connexions). De l’extérieur, ça ressemble juste à “le site est lent”. En interne, on voit des timeouts, de la mise en file et une base qui ne suit plus.

Bonne nouvelle: pas besoin de tout reconstruire. Quelques choix d’architecture peuvent suffire à séparer la partie coûteuse du chemin de requête et à ajouter un frein:

Caching (y compris pages d’erreur), TTLs cohérents, edge caching.
Traitement asynchrone (queues) pour les tâches coûteuses: au lieu de “PDF maintenant”, lancer un job et livrer plus tard.
Validation stricte et arrêt précoce: limiter la complexité, limites strictes par requête.
Protection séparée pour login, recherche, upload, export: rate limits et timeouts dédiés, et éventuellement des worker pools dédiés.
“Mode dégradé” (feature flags): désactiver temporairement certaines fonctions sans stress de déploiement.

4) Options upstream: filtrage, scrubbing, plans d’urgence

Si ça devient très gros, il faut filtrer le trafic avant qu’il n’arrive sur ton lien:

Filtrage côté fournisseur / scrubbing center
Règles temporaires (ex: “pourquoi du UDP arrive sur mon web server?”)
Emergency routing (ex: basculer vers une IP “protégée”)

Cela ne fonctionne que si c’est préparé à l’avance avec le fournisseur. Démarrer “ad hoc” en plein incident est cher et lent.

Une checklist pragmatique (pour équipes sans spécialistes DDoS)

Inventaire: quels services sont publics? HTTP, DNS, VPN, mail, gaming, VoIP?
Points uniques de défaillance: provider DNS, reverse proxy, load balancer, une seule région?
Observabilité: bps/pps, RPS, latences, erreurs, connexions, alertes avec baseline.
Durcir les defaults: timeouts, limites, taille max des headers, limites de connexions, backpressure.
Plan fournisseur: qui scrube, qui peut filtrer, quels chemins d’escalade.
Runbook: “si X arrive, alors Y”, avec contacts, seuils et switches (feature flags).
S’entraîner: load tests contrôlés et drills d’incident (légaux et coordonnés).

Pour finir: tester, mais rester légal et utile

Tester le DDoS est un sujet sensible. Tout ce qui touche l’internet public, des systèmes tiers ou une infra sans autorisation explicite est interdit. Ce que tu peux et devrais faire:

Load tests sur ton environnement de staging (par exemple sur des endpoints coûteux).
Chaos tests sur les dépendances (cache down, DB lente, rate limits plus stricts).
Entraîner le process de réponse: alertes, communication, escalation fournisseur, mesures d’urgence.

Sources et lectures complémentaires

À la prochaine, Joe