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.