Mitigation DDoS : retour d’expérience sur 15 h 30 d’attaque applicative

Une attaque DDoS n’a pas besoin de battre un record mondial pour mettre une application hors service.

Nous l’avons constaté lors d’un incident réel sur une plateforme web en production. Pendant 15 heures et 30 minutes, Cloudflare a mitigé 22 482 683 requêtes. Le pic a atteint environ 2 000 requêtes par seconde et le trafic provenait de 290 000 adresses IP distinctes observées.

Ces chiffres restent modestes face aux attaques hypervolumétriques dont il est parfois question dans l’actualité. Ils étaient pourtant largement suffisants pour saturer l’application ciblée. L’attaque était distribuée, durable et orientée vers plusieurs pages dynamiques coûteuses à produire.

La réponse ne pouvait donc pas se limiter à activer un bouton chez Cloudflare. Il fallait comprendre simultanément ce qui se passait à l’edge, ce qui atteignait encore l’origine et pourquoi certaines requêtes produisaient un effet disproportionné sur Apache et MariaDB.

Ce retour d’expérience présente notre méthode. Le client, ses domaines, ses adresses et les détails exploitables de l’architecture ont volontairement été anonymisés.

Une attaque atypique par sa durée et sa distribution

Sur la fenêtre étudiée, l’activité malveillante ne s’est pratiquement jamais interrompue. La moyenne dépassait 24 000 requêtes mitigées par minute, avec une seconde vague plus intense en soirée. Pendant les périodes les plus chargées, le niveau observé atteignait plus de cent fois le bruit habituel de la plateforme.

La durée constitue ici un marqueur particulièrement atypique. Cloudflare indique que 75 % des attaques HTTP DDoS se terminent en moins de dix minutes. Dans ce cas, la pression s’est maintenue pendant 15 heures et 30 minutes, sans véritable période de répit sur la fenêtre analysée.

L’attaque présentait trois caractéristiques importantes :

• une durée très inhabituelle, avec une pression maintenue pendant plus d’une demi-journée ;
• une forte distribution des sources sur des réseaux résidentiels d’opérateurs légitimes, notamment Orange, Free et SFR, mais aussi d’autres fournisseurs habituellement utilisés par les visiteurs du site ;
• une rotation entre plusieurs routes dynamiques, plutôt qu’un simple martèlement de la page d’accueil.

Cette provenance rendait les blocages larges par opérateur ou par réseau inadaptés : ils auraient également écarté une partie du public légitime. Avec 289 402 adresses IP distinctes observées, un traitement manuel adresse par adresse était tout aussi impraticable. La mitigation devait donc s’appuyer sur le comportement des requêtes et la pression exercée sur l’application, pas seulement sur leur provenance.

La volumétrie brute ne racontait toutefois qu’une partie de l’histoire. Une requête HTTP servie depuis un cache n’a pas le même coût qu’une page déclenchant du PHP, plusieurs lectures SQL et des calculs applicatifs. À débit égal, l’impact sur l’origine peut varier dans des proportions considérables.

C’est pour cette raison que nous avons travaillé sur deux plans en parallèle : réduire le trafic transmis par Cloudflare et réduire le coût de chaque requête encore acceptée par l’origine.

Première étape : croiser les mesures Cloudflare et celles de l’hôte

L’analyse a commencé par une corrélation entre les événements Cloudflare et les signaux du serveur de production.

Côté Cloudflare, nous avons étudié :

• le volume de requêtes et son évolution dans le temps ;
• les actions de sécurité appliquées ;
• les routes et familles de routes visées ;
• la répartition apparente des sources ;
• la part respective des protections managées et des règles personnalisées.

Côté origine, nous avons suivi :

• la file de connexions HTTPS ;
• l’occupation des workers Apache ;
• la charge système et la pression CPU ;
• l’activité des conteneurs Docker ;
• les requêtes lentes et la concurrence dans MariaDB ;
• les lectures logiques et physiques de la base ;
• le temps de réponse de pages représentatives.

Cette double lecture évite une erreur fréquente : confondre le trafic vu par le fournisseur de protection avec le trafic réellement traité par l’application. Les données Cloudflare permettent de qualifier l’attaque. Les métriques locales montrent où l’infrastructure commence à céder.

Dans notre cas, le point de rupture visible se situait au niveau du frontal HTTPS, mais la cause principale était plus profonde. Certaines pages déclenchaient des requêtes SQL coûteuses en parallèle. Les traitements s’accumulaient, occupaient les workers applicatifs, puis remplissaient progressivement la file du serveur web.

Autrement dit, Apache matérialisait la saturation ; il n’en était pas l’unique origine.

Deuxième étape : adapter les règles Cloudflare au trafic réellement observé

Les protections automatiques de Cloudflare avaient déjà absorbé une grande partie de la pression. Sur la période analysée, 94,3 % des requêtes observées ont déclenché l’une des actions de mitigation retenues dans notre analyse, principalement des challenges managés.

Cela ne dispensait pas d’adapter les règles. Une attaque applicative peut changer de route, imiter une requête légitime ou répartir sa charge de manière à éviter un seuil trop global.

Nous avons donc affiné la politique de sécurité à partir du trafic réel :

• vérification du périmètre effectivement couvert par chaque règle ;
• identification des chemins les plus sollicités ;
• distinction entre trafic de navigation et appels automatisés ;
• combinaison des protections managées avec des règles personnalisées ;
• surveillance des faux positifs avant de conserver un réglage agressif ;
• ajustement progressif de la posture pendant l’incident.

Le choix entre blocage et challenge n’est pas anodin. Bloquer trop largement peut écarter des visiteurs légitimes. Challenger tout le trafic pendant trop longtemps dégrade également l’expérience. La bonne réponse dépend du comportement observé, du type de route et de la criticité du service.

Ce travail prolonge l’approche détaillée dans notre article sur la protection anti-DDoS avec Cloudflare et un WAF piloté : la plateforme fournit le bouclier, mais son efficacité repose sur l’exploitation des signaux et l’ajustement des règles.

Troisième étape : supprimer les facteurs d’amplification sur l’origine

Le filtrage en amont était indispensable, mais il ne fallait pas laisser l’origine dans un état où quelques dizaines de requêtes coûteuses suffisaient à provoquer une nouvelle saturation.

Nous avons donc analysé la chaîne complète : frontal Apache sur l’hôte, proxy vers l’application conteneurisée, exécution PHP, accès MariaDB et traitements en arrière-plan.

Redimensionner le cache mémoire de MariaDB

Le buffer pool InnoDB était trop petit par rapport au jeu de données actif et à la mémoire disponible. Des pages utiles étaient continuellement évincées du cache, obligeant MariaDB à répéter des lectures coûteuses.

Son redimensionnement contrôlé a permis de conserver beaucoup plus efficacement les données sollicitées. Malgré une charge SQL supérieure pendant la mesure après intervention, les lectures physiques par seconde ont diminué d’environ 40 % et les lectures physiques par requête d’environ 53 %.

Sur un traitement représentatif d’une page lourde, la médiane est passée de plusieurs secondes à environ un dixième de seconde une fois le cache chaud. Selon les mesures retenues, le temps de traitement associé a été divisé jusqu’à 51.

Ce gain n’a pas été présenté comme une solution DDoS à lui seul. Un cache plus grand ne bloque aucune attaque. Il réduit en revanche l’effet d’amplification de chaque requête et améliore durablement les performances du trafic légitime.

Construire les index à partir des requêtes réellement coûteuses

Les journaux de requêtes lentes ont ensuite permis d’identifier plusieurs parcours SQL inadaptés à la charge réelle.

Nous avons construit des index composites et couvrants ciblés, après contrôle des plans d’exécution et de l’espace disponible. L’un des traitements dominants pendant l’attaque a ainsi été accéléré de 14 à 31 fois. Sur une fenêtre comparable, le nombre de nouvelles requêtes lentes a diminué d’environ 92 %, alors même que MariaDB traitait davantage de requêtes par seconde.

L’objectif n’était pas d’ajouter des index au hasard. Chaque index supplémentaire a un coût en espace et en écriture. Nous avons donc mesuré avant, vérifié le plan choisi par l’optimiseur, construit en ligne lorsque c’était possible, puis contrôlé la charge et les temps après intervention.

Affiner Apache sans déplacer le problème

Augmenter aveuglément le nombre de workers Apache aurait simplement envoyé davantage de traitements simultanés vers PHP et MariaDB.

Nous avons préféré travailler sur la régulation de la chaîne : connexions, délais, comportement du proxy et pression maximale transmise au backend. Des réglages de protection ont été testés sous charge réelle. Lorsqu’un réglage trop agressif a commencé à pénaliser des visiteurs légitimes, il a été retiré conformément au plan de retour arrière.

Cette étape est importante. Une mitigation n’est pas réussie parce qu’elle maintient le serveur en vie tout en renvoyant des erreurs aux utilisateurs. Elle doit protéger le backend et préserver un niveau de service acceptable.

Le résultat des optimisations MariaDB, des index et de l’affinage de la chaîne web a dépassé le seul cadre de l’incident : certaines pages lourdes sont restées nettement plus rapides après le retour à un trafic normal.

Quatrième étape : automatiser une réponse progressive par l’API Cloudflare

Une attaque peut repartir en quelques secondes. Attendre qu’un humain reçoive une alerte, ouvre un tableau de bord et modifie manuellement la protection laisse parfois assez de temps pour saturer l’origine.

Nous avons donc développé un contrôleur spécifique capable de piloter plusieurs niveaux de mitigation par l’API Cloudflare selon des critères adaptés à cette application.

Le contrôleur ne se contente pas d’un seuil de trafic global. Il croise deux familles de signaux :

• la santé locale de l’origine, comme la pression Apache, la file HTTPS, la charge et l’activité de la base ;
• les tendances observées par Cloudflare, notamment le niveau des requêtes mitigées et son évolution.

Cette combinaison répond à un problème classique : lorsque la protection forte est active, le serveur redevient calme. Si l’on ne regarde que les métriques locales, le contrôleur peut croire trop tôt que l’attaque est terminée et désactiver la protection, provoquant immédiatement une nouvelle saturation.

Nous avons donc mis en place une véritable machine à états :

1. observation du fonctionnement normal ;
2. activation d’une mitigation lorsque les critères sont confirmés ;
3. maintien de la protection pendant une durée minimale ;
4. vérification durable du retour à la normale, localement et chez Cloudflare ;
5. désactivation contrôlée ;
6. période de probation avec réactivation immédiate si l’attaque reprend ;
7. clôture et notification seulement lorsque la situation est réellement stabilisée.

Le script mémorise également l’état précédent afin de restaurer la bonne configuration. Il distingue une protection activée automatiquement d’une décision manuelle, utilise un jeton limité au strict périmètre nécessaire et adopte une posture prudente lorsqu’une mesure distante devient indisponible.

Avant toute action réelle, le mécanisme a été exécuté en simulation. Les seuils ont été comparés aux métriques historiques, les transitions ont été testées et les comportements de reprise ont été validés. Cette progression évite qu’un automatisme de sécurité mal calibré ne devienne lui-même une source d’indisponibilité.

Le résultat : une attaque entièrement maîtrisée, sans masquer les limites

La combinaison des protections Cloudflare et du travail sur l’origine a permis de maîtriser complètement l’incident sur le plan opérationnel : l’essentiel du trafic hostile a été traité en amont, la chaîne de production a retrouvé de la marge et le service légitime a pu être maintenu.

Le résultat ne tient pas à une règle magique. Il vient de l’enchaînement des actions :

1. qualifier l’attaque avec les données Cloudflare ;
2. mesurer son effet réel sur l’hôte et les conteneurs ;
3. adapter les règles de filtrage au comportement observé ;
4. localiser les traitements qui amplifiaient chaque requête ;
5. optimiser MariaDB et les accès SQL ;
6. régler la chaîne Apache avec des limites mesurées et réversibles ;
7. automatiser l’activation, le suivi et la clôture des mitigations.

Les chiffres Cloudflare employés dans ce retour d’expérience proviennent de jeux de données adaptatifs. À fort volume, ils reposent sur un échantillonnage et des estimations. Le nombre d’adresses distinctes doit donc être compris comme un nombre d’adresses observées, pas comme le décompte garanti d’autant de machines compromises. Un challenge présenté ne signifie pas non plus que chaque requête a été définitivement rejetée.

Cette prudence ne diminue pas le constat : une attaque durable, répartie sur plusieurs routes et issue d’un très grand nombre de sources peut mettre à genoux une application réelle sans approcher les records mondiaux.

Ce que ce cas confirme sur la mitigation DDoS

Une protection DDoS sérieuse ne s’arrête ni au CDN ni au pare-feu.

Elle repose sur quatre capacités complémentaires :

• observer, avec une vue cohérente de l’edge jusqu’à la base de données ;
• filtrer, avec des règles adaptées au trafic légitime de l’application ;
• encaisser, en supprimant les goulots d’étranglement qui amplifient la charge ;
• réagir, avec une automatisation supervisée, progressive et réversible.

Ce cas illustre aussi la valeur d’une supervision pensée pour l’exploitation. Sans métriques locales et distantes, nous aurions pu voir la file Apache se remplir sans identifier la requête SQL responsable, ou constater une origine calme sans voir que l’attaque continuait d’être absorbée par Cloudflare.

C’est précisément notre rôle d’infogérant Linux : ne pas traiter chaque couche isolément, mais comprendre leurs interactions en situation réelle. Pare-feu, proxy, système, conteneurs, serveur web et base de données forment une seule chaîne de disponibilité.

Si votre application subit des attaques, des ralentissements inexpliqués ou des saturations récurrentes, nous pouvons intervenir en renfort technique pour diagnostiquer l’incident, mettre en place les protections et construire une réponse durable.

• Découvrir notre approche de l’infogérance
• Nous contacter
• Prendre rendez-vous

FAQ : mitigation d’une attaque DDoS

Une attaque DDoS doit-elle battre des records pour rendre un site indisponible ?

Non. Un débit modeste à l’échelle d’un grand réseau peut suffire à saturer une application lorsque chaque requête déclenche des traitements coûteux sur le serveur web ou la base de données.

Cloudflare suffit-il à protéger une application contre un DDoS ?

Cloudflare constitue une protection essentielle en amont, mais son efficacité dépend des règles appliquées, de leur suivi et de la capacité de l’origine à traiter le trafic qui lui parvient encore.

Pourquoi analyser le serveur si Cloudflare bloque déjà l’attaque ?

Les mesures Cloudflare décrivent la pression à l’edge, tandis que les métriques du serveur montrent l’impact réel sur Apache, les conteneurs et la base de données. Les deux vues sont nécessaires pour localiser le goulot d’étranglement.

Peut-on automatiser l’activation d’une mitigation Cloudflare ?

Oui. Un contrôleur peut appeler l’API Cloudflare selon des critères locaux et distants, à condition de prévoir des seuils validés, un état persistant, une période de maintien, une reprise prudente et un retour arrière.

L’optimisation de l’origine reste-t-elle utile après l’attaque ?

Oui. Les optimisations validées pendant l’incident réduisent aussi le coût du trafic légitime. Dans ce cas, certains traitements de base de données liés à des pages lourdes ont été accélérés jusqu’à 51 fois.

Forget About IT peut-il intervenir pendant une attaque DDoS ?

Oui. Nous pouvons analyser le trafic, piloter les protections Cloudflare, diagnostiquer l’origine Linux et mettre en place une réponse supervisée adaptée à l’application.

Sources

• Cloudflare Docs - fonctionnement de la protection DDoS
• Cloudflare Docs - fonctionnement des challenges
• Cloudflare Docs - échantillonnage des données Analytics
• Cloudflare - rapport sur les attaques DDoS du premier semestre 2026
• Cloudflare - rapport DDoS du premier trimestre 2025 et durée des attaques HTTP