Attaques DDoS Layer 7 : comment les d?tecter et s'en prot?ger

Layer 7 vs Layer 3/4 : la diff?rence fondamentale

Le mod?le OSI divise les communications r?seau en 7 couches. Les DDoS traditionnels ciblent les couches 3 (r?seau) et 4 (transport) : ils saturent la bande passante avec des torrents de paquets r?seau mal form?s ou massifs. Ces attaques sont massives et bruyantes, mais relativement simples ? filtrer en amont.

Les DDoS Layer 7 sont fondamentalement diff?rents. Ils ciblent la couche applicative ? HTTP, HTTPS, DNS, SMTP ? avec des requ?tes valides et syntaxiquement correctes. Un attaquant Layer 7 ne cherche pas ? saturer votre r?seau ; il cherche ? ?puiser vos ressources serveur : threads PHP, connexions ? la base de donn?es, processeurs de rendu, sessions d'authentification.

Types d'attaques Layer 7

HTTP Flood

La forme la plus simple : envoyer le maximum de requ?tes GET ou POST l?gitimes vers votre application. Si un endpoint g?n?re une requ?te SQL, chaque requ?te HTTP consomme une connexion ? la base de donn?es. Avec 500 requ?tes/seconde sur un endpoint non mis en cache, vous saturez rapidement votre pool de connexions.

Slowloris

Particuli?rement vicieux : Slowloris ouvre de nombreuses connexions HTTP et les maintient ouvertes le plus longtemps possible en envoyant des headers partiels ? intervalles r?guliers. Le serveur attend la fin de la requ?te qui ne vient jamais, consommant un thread pour chaque connexion maintenue.

# Exemple de ce que fait Slowloris (? titre ?ducatif)
# Ouvre une connexion et envoie des headers partiels ind?finiment
GET / HTTP/1.1\r\n
Host: example.com\r\n
X-a: b\r\n          ? header envoy? toutes les 15 secondes
X-a: b\r\n          ? la requ?te ne se termine jamais (\r\n\r\n manquant)

Cache Bypass Attack

L'attaquant g?n?re des requ?tes avec des param?tres URL al?atoires (v=rand, t=timestamp) pour contourner votre cache CDN et forcer chaque requ?te ? frapper votre serveur d'origine. Votre CDN voit du trafic parfaitement normal ; votre origine est submerg?e.

# Exemple de cache bypass
GET /api/productsv=7482917 HTTP/1.1   ? miss CDN, frappe l'origine
GET /api/productsv=8291047 HTTP/1.1   ? miss CDN, frappe l'origine
GET /api/productsv=3947261 HTTP/1.1   ? miss CDN, frappe l'origine

XML/JSON Bomb

L'attaquant envoie des requ?tes POST avec des payloads JSON ou XML con?us pour consommer un maximum de CPU lors du parsing ? des structures profond?ment imbriqu?es ou des tableaux massivement r?p?t?s.

D?tecter une attaque Layer 7

C'est le d?fi principal : comment distinguer une attaque Layer 7 d'un pic de trafic l?gitime (soldes, campagne marketing, publication virale)

Signaux d'alerte

• D?gradation des temps de r?ponse sans augmentation proportionnelle du trafic
• Concentration anormale sur un seul endpoint ? un endpoint repr?sente soudainement 80% des requ?tes
• User-Agents identiques ou suspects en masse
• Absence de comportement humain ? pas de requ?tes vers les CSS, images, fonts (un humain charge toutes les ressources d'une page)
• G?olocalisation concentr?e ? 90% du trafic depuis un seul pays inhabituel
• Taux de requ?tes identiques ? timing parfaitement r?gulier (exemple : exactement 10 req/s)

# Analyser les endpoints les plus sollicit?s en temps r?el
tail -f /var/log/nginx/access.log | \
  awk '{print $7}' | \
  sort | uniq -c | sort -rn | head -20

# D?tecter les User-Agents dominants (suspects si 1 UA = >10% du trafic)
awk -F'"' '{print $6}' /var/log/nginx/access.log | \
  sort | uniq -c | sort -rn | head -10

# Analyser la distribution des IPs
awk '{print $1}' /var/log/nginx/access.log | \
  sort | uniq -c | sort -rn | head -20

Contre-mesures efficaces

1. Rate limiting adaptatif

Contrairement au rate limiting statique, le rate limiting adaptatif ajuste les seuils en fonction du comportement observ?. En cas d'anomalie, les limites se resserrent automatiquement sur les patterns suspects.

# Nginx : rate limiting par zone avec burst
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req_zone $http_x_forwarded_for zone=api_xff:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req zone=api_xff burst=20 nodelay;
    limit_req_status 429;

    # Headers informatifs pour les clients l?gitimes
    add_header Retry-After 60;
    add_header X-RateLimit-Limit 10;
}

2. Protection contre Slowloris

# Nginx : limiter les connexions et les timeouts
http {
    client_header_timeout 10s;      # timeout si headers pas re?us en 10s
    client_body_timeout 10s;        # timeout si body pas re?u
    keepalive_timeout 65s;
    send_timeout 10s;

    # Limiter les connexions simultan?es par IP
    limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
    limit_conn conn_limit_per_ip 20;
}

3. CAPTCHA challenge adaptatif

Pour les endpoints non-API accessibles aux humains, un CAPTCHA challenge invisible (reCAPTCHA v3 ou Cloudflare Turnstile) peut ?tre d?clench? automatiquement quand le score de suspicion d'une IP d?passe un seuil.

4. Mise en cache agressive

Les requ?tes mises en cache ne frappent jamais votre serveur. Identifiez tous les endpoints qui peuvent ?tre mis en cache et configurez des TTL appropri?s ? y compris pour des donn?es "dynamiques" qui ne changent pas en temps r?el.

# Mettre en cache les r?ponses API immuables
location /api/products {
    proxy_cache products_cache;
    proxy_cache_valid 200 5m;         # cacher 5 minutes
    proxy_cache_use_stale error timeout updating;  # servir le cache si origine lente
    proxy_cache_bypass $http_pragma;
    add_header X-Cache-Status $upstream_cache_status;
}

5. Protection au niveau DNS

En passant votre trafic par un r?seau anycast (Cloudflare, AWS CloudFront), les attaques sont absorb?es en p?riph?rie du r?seau avant d'atteindre vos serveurs. C'est la protection la plus efficace contre les attaques volum?triques.

Plan de r?ponse ? incident

Quand une attaque Layer 7 est en cours, chaque minute compte. Avoir un plan pr?tabli fait la diff?rence entre 10 minutes et 4 heures de downtime.

• T+0 : Confirmer l'attaque ? v?rifier que ce n'est pas un pic l?gitime (soldes, campagne), analyser les logs
• T+2 min : Activer le mode d?fense ? rate limiting renforc?, blocage g?ographique si applicable, challenge CAPTCHA
• T+5 min : Identifier le pattern ? quel endpoint, quel User-Agent, quelles IPs dominantes
• T+10 min : Bloquer les IPs d'attaque ? blacklister les IPs identifi?es, contacter votre op?rateur si n?cessaire
• T+30 min : Post-mortem pr?liminaire ? documenter pour am?liorer la r?ponse future

Conclusion

Les DDoS Layer 7 sont la forme d'attaque la plus sophistiqu?e et la plus difficile ? contrer parce qu'ils exploitent la m?me infrastructure que vos utilisateurs l?gitimes. La cl? est la d?tection pr?coce par analyse comportementale, combin?e ? des contre-mesures en couches : rate limiting, mise en cache, WAF, et protection r?seau.

Le meilleur moment pour pr?parer sa r?ponse aux DDoS Layer 7, c'est avant qu'une attaque n'ait lieu. Configurez vos alertes, documentez votre plan de r?ponse, et testez-le.