Que faire lors d'une attaque DDoS sur un site Web ?

Manuel Schulz · 31.10.2025 · sécurité informatique · 7 min

Récemment, Zerlo.net à une attaque DDoS. Ce qui nous a intéressés : Comment gérons-nous cela, comment reconnaissons-nous ce genre de chose – et comment avons-nous pu le démontrer clairement ? Dans cet article, je montre nos étapes, ce qui se cache derrière le DDoS et comment Cloudflare sert de couche de protection. Si vous avez des problèmes similaires, vous trouverez des outils pratiques sur notre Zerlo-Toolseite et d'autres articles sur notre Zerlo-Blog .

Bannière de fonctionnalité : attaque DDoS – image symbolique

Source: Représentation personnelle

Explication : qu'est-ce qu'un DDoS ?

Un Distributed-Denial-of-Service-Angriff (DDoS) est la tentative de mettre hors service un service en ligne par des requêtes massivement distribuées. « Distributed » signifie : l'attaque vient simultanément de nombreuses sources ( CISA-Leitfaden). ). On distingue grossièrement entre les attaques au niveau réseau (par ex. UDP/ICMP-Floods) et au niveau applicatif (Layer7), par exemple HTTP-Floods. . Une bonne, pratique introduction fournit également OWASP ( (Denial of Service)).

Comment le reconnaître ?

Une seule valeur mesurée ne suffit presque jamais. Des motifs typiques sont : une charge d'origine en forte hausse, mais des sessions/conversions réelles inchangées ; soudainement beaucoup de requêtes sur des points de terminaison « coûteux » (Login, Recherche, /api, formulaires) ; agents utilisateur suspects ou vides ; pics inhabituels issus de nouveaux ASN ; forte CPU/IO sans modification du code. Des logs propres que vous pouvez analyser par exemple via Cloudflare Logpush/Log Explorer ou côté serveur pour l'évaluation. Une liste de contrôle compacte se trouve dans le Zerlo-Blog en cas d'incidents similaires.

Détection via Cloudflare

Dans Cloudflare, ces motifs peuvent être clairement décomposés :

Sécurité → Événements/Analyses : Segments de pics par chemin, pays, ASN, méthode, User-Agent ( Security Analytics)).
Trafic/Analytique : De nombreuses requêtes Edge avec un taux d'origine élevé → Indice pour les L7-Floods ( Traffic Analytics)).
WAF/Pare-feu : « Challenged/Blocked » compte les mitigations; ajustez finement les règles ( Cloudflare WAF)).
HTTP-DDoS / Limitation de débit : Identifier les hotspots IP/chemin ( Rate Limiting Rules, HTTP DDoS Managed Rules)).

Conclusion : Pour les sites Web avec beaucoup d'utilisateurs, une couche de protection en amont telle que Cloudflare Application Services pratiquement obligatoire – la télémétrie et les outils aident à distinguer la charge légitime et l'attaque et à réagir rapidement. En interne, nous renvoyons pour les articles de base vers le Zerlo-Blog et pour les outils sur le Zerlo-Tools.

Personnel

Nous, chez Zerlo nous avons constaté une charge inhabituellement élevée le 31/10/2025 – le site était hors-ligne à plusieurs reprises. Au départ, je pensais à un problème technique. Puis j'ai vérifié le trafic des visiteurs : presque identique à la veille, ce qui était étrange, car notre compteur ne mesure que les interactions humaines (JavaScript). Under-Attack-Mode (UAM) Le contre-test classique : tout lancer localement (localhost). Résultat : localement 0 % de charge – donc la charge externe devait être artificielle. Chez Cloudflare, l'augmentation était alors clairement visible. J'ai activé par test le

Statistiques Cloudflare : forte augmentation des requêtes entrantes

Source: Représentation personnelle

En bref : Nous avons été geddostés. Davantage d'éclaircissements nous les partageons régulièrement dans le Zerlo-Blog.

Cloudflare

Si l'hébergeur Web dispose déjà d'une bonne protection au niveau réseau, cela suffit souvent pour les attaques volumétriques, surtout si le fournisseur atténue. Nous opérons chez Zerlo cependant un réseau plus grand avec plusieurs services et avons besoin d'interfaces centrales en amont qui terminent et filtrent le trafic de manière intelligente avant d'atteindre nos origines. C'est exactement ici qu'un réseau Edge global comme Cloudflare aide : Anycast, caching, WAF, Bot Fight Mode, Rate-Limiting et une télémétrie détaillée.

Cloudflare est utilisable gratuitement dans sa version de base et peut être « monté en puissance » temporairement en cas d'attaques. Il ne reconnaît pas tous les scénarios automatiquement à la perfection – il faut observer les motifs –, mais ensuite avec les bonnes règles il est très efficace. Pour les configurations et les benchmarks, nous documentons également les meilleures pratiques sur zerlo.net/de/tools.

Explication du mécanisme de protection Cloudflare

Aussi simple que génial : Avant l'appel réel de la page, Cloudflare peut effectuer une vérification basée sur JavaScript ( Challenge) ) peut être mis en place et évaluer les signaux du navigateur. Pour les utilisateurs réels, cela se produit une fois et presque imperceptible ; les bots et scripts échouent ou doivent déployer énormément plus de ressources. Résultat : la charge du backend diminue immédiatement et vous gagnez du temps pour l'ajustement fin ( WAF, Rate-Limits, Caching)).

❝ On ne peut pas empêcher le DDoS – on le gère. L'art consiste à rendre les attaques invisibles pour les humains, mais coûteuses pour les bots. ❞

Manuel Schulz

Zerlo.net

Source: Aperçu rapide sur les botnets et le DDoS.

Que peut-on faire contre cela ?

Rien.Un DDoS n'est pas quelque chose que vous pouvez empêcher – chacun sur le réseau peut vous envoyer des paquets. Mais vous pouvez réduire l'effet de manière à ce que le site reste accessible aux utilisateurs réels. C'est ce dont il s'agit : atténuer intelligemment plutôt que d'attendre que ça passe.

À court terme : Under-Attack-Mode (UAM) activer pour atténuer immédiatement la charge Layer-7.

À long terme : WAF-Regeln pour POST/API/GET coûteux, Managed-Challenges pour les agents utilisateur suspects, Rate-Limiting par IP. Pour les pages publiques « Cache Everything“, », pour les connexions/administrateurs « By-pass on Cookie ». Formulaires avec Turnstile sécuriser.

Gestion : Security Analytics observer, mettre en place des alertes, Logs sécuriser. Un petit script peut déclencher UAM automatiquement lorsque les pings échouent – et vous avertir. Des exemples et extraits de code documentons sur zerlo.net/de/blog.

Cloudflare : règles WAF/limitation de débit judicieuses

(len(http.user_agent) = 0
 or lower(http.user_agent) contains "python"
 or lower(http.user_agent) contains "curl"
 or lower(http.user_agent) contains "bot"
 or lower(http.user_agent) contains "crawler")
=> Action: Managed Challenge

(http.request.method eq "POST"
 or starts_with(http.request.uri.path, "/api/")
 or http.request.uri.path contains "/sendMail.php")
=> Action: Managed Challenge

# Rate Limiting (Beispiel)
(http.request.method eq "POST" and starts_with(http.request.uri.path, "/api/"))
Threshold: 10 requests in 10 seconds per IP
Action: Challenge

# Doku:
# UAM: https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/
# WAF: https://developers.cloudflare.com/waf/
# Rate Limiting: https://developers.cloudflare.com/waf/rate-limiting-rules/
# Challenges: https://developers.cloudflare.com/cloudflare-challenges/

cloudflare_uam_toggle.sh

#!/usr/bin/env bash
# Under-Attack-Mode per API setzen (Beispiel)
# Voraussetzung: CF_API_TOKEN mit Berechtigung 'Zone Settings Edit'
ZONE_ID="<ZONE_ID>"

# UAM EIN
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"under_attack"}'

# UAM AUS (z.B. wieder auf 'high' oder 'medium')
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"high"}'

# Mehr: https://developers.cloudflare.com/api/operations/zone-settings-change-security-level

nginx_rate_limit_example.conf

# Nginx: simples per-IP-Limit (Beispiel)
limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/s;

server {
  location /api/ {
limit_req zone=perip burst=60 nodelay;
proxy_pass http://backend;
  }
}

# OWASP-DoS-Cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html

Ressources supplémentaires

Notions de base et approfondissement : NIST-DoS, NIST-DDoS, CISA-DDoS, OWASP-DoS, Cloudflare Learning Center. D'autres articles pratiques et outils se trouvent sur zerlo.net et plus particulièrement sur zerlo.net/de/tools.

Conclusion

Le DDoS n'est pas un état d'exception, mais un cas opérationnel. Ceux qui détectent rapidement les anomalies, atténuent à court terme et then renforcent de manière ciblée, restent en ligne. Pour les sites Web en croissance, il est Cloudflare fortement recommandé : comme couche de protection en amont : visibilité, mesures immédiates et briques pour une exploitation durable. Pour des configurations individuelles, des check-lists et des extraits de code, nous renvoyons vers le Zerlo-Blog et les Zerlo-Tools.