Comment nous avons stoppé une DDoS attaque sur le site web d’une PME (1,4 milliard de requêtes)

En tant que chef de projet au sein de l’agence Incrona, mon quotidien consiste à veiller à ce que les sites internet de nos clients soient rapides, performants et surtout disponibles. Mais il y a des jours où la routine laisse place à une véritable cyberguerre.

Récemment, nous avons accompagné un client opérant dans un secteur d’artisans ultra-concurrentiel en région parisienne et Île-de-France. Dans ce milieu, chaque appel manqué est un chantier qui part à la concurrence. Autant vous dire que lorsque leur site internet a soudainement suffoqué sous le coup d’une ddos attaque sur leur site web, la situation est devenue critique en l’espace de quelques secondes.

Voici le récit de cette crise numérique, des enjeux financiers qui en découlent, et de la méthode pas à pas que j’ai déployée avec l’équipe d’Incrona pour terrasser une attaque massive de 1,43 milliard de requêtes.

Le déclencheur : Un algorithme concurrentiel d’une violence inouïe

Le scénario de cette attaque présente une particularité terrifiante qui démontre la sophistication de la malveillance économique en ligne aujourd’hui. Ce n’était pas un acte de vandalisme gratuit, et nous l’avons découvert de manière très concrète.

Alors que mon équipe et moi-même étions en train d’effectuer des modifications techniques axées sur le SEO pour améliorer le positionnement du site, nous avons soudainement vu le site s’effondrer. À l’écran, un message d’erreur s’affichait en boucle : « 508 Resource Limit Is Reached ».

En croisant nos outils de monitoring, nous avons fait un constat technique flagrant : dès que notre client activait sa campagne publicitaire Google Ads, son site internet était immédiatement bombardé par des vagues de connexions simultanées. L’algorithme mis en place par les attaquants (très probablement des concurrents peu scrupuleux utilisant des services de robots automatisés) était d’une réactivité chirurgicale. Dès que les annonces publicitaires apparaissaient sur les moteurs de recherche, les robots se jetaient sur le site pour l’asphyxier.

Dans ces moments-là, la situation devient intenable : chaque clic publicitaire coûte de l’argent, mais au lieu d’accueillir un vrai client d’Île-de-France en quête d’un dépannage urgent, le site internet se retrouvait totalement hors service (HS).

L’objectif des hackers : Étrangler le serveur, pas voler des données

Il est crucial de comprendre la nature de cette cyberattaque. Ici, l’objectif des hackers n’était pas d’injecter un virus, de voler des mots de passe ou de pirater la base de données. Ils visaient uniquement la page d’accueil avec une seule idée en tête : étrangler la pipe d’entrée du serveur pour rendre le business invisible sur le web.

Pour comprendre l’origine du blocage, mon premier réflexe a été d’analyser les statistiques de performance de l’hébergeur. Ce que j’ai vu sur les graphiques était surréaliste : le CPU du serveur tournait en permanence à plus de 240 % de sa capacité, alors qu’en temps normal, pour un site de cette envergure, il cruise tranquillement entre 2 % et 5 %.

Comprendre le point de rupture : L’histoire des « Entry Processes » (EP)

Pour ce client, l’agence Incrona avait mis en place un hébergement mutualisé premium extrêmement solide, taillé pour encaisser de grosses vagues de trafic. Cependant, ce n’est pas un serveur dédié. Sur un hébergement de ce type, le serveur est protégé par des limites de sécurité strictes pour éviter qu’un seul site internet ne monopolise toutes les ressources et ne fasse planter les autres clients de la machine. La limite la plus importante et la plus sensible s’appelle l’EP (Entry Processes – Processus d’entrée).

Qu’est-ce qu’un Entry Process (EP) ? Pour faire simple, c’est le nombre de connexions, de scripts ou de requêtes simultanés que votre serveur a le droit de traiter à la même micro-seconde (par exemple, charger une image, exécuter un script WordPress ou générer le code HTML de la page d’accueil pour un visiteur).

Notre hébergement possédait une limite de base fixée à 60 EP simultanés. C’est une excellente marge, amplement suffisante pour un comportement humain normal, même lors des pics de fin de journée. Mais face à l’algorithme des attaquants, ce plafond de 60 connexions a été pulvérisé.

La preuve par les logs : Des milliers de dépassements par minute

Pour comprendre précisément la violence de l’assaut, j’ai analysé le rapport d’erreurs détaillé fourni par le support technique (la commande système lveinfo). C’est en ouvrant ce fichier que j’ai pris conscience de la réalité de la situation : nous ne faisions pas face à une petite surcharge, mais à un pilonnage systématique.

La colonne EPf (Entry Process Faults) liste le nombre de fois où le serveur a dû refuser une connexion parce que la limite des 60 était déjà atteinte. Les chiffres extraits par notre support technique donnent le vertige : le site subissait littéralement des milliers de dépassements par minute.

Regardez attentivement les lignes de rapports ci-dessous :

• Entre 07h49 et 07h50, le serveur enregistre 1 600 refus en seulement 60 secondes (1.6K).
• Quelques minutes plus tard, à 08h07, le compteur grimpe à 1 700 connexions avortées (1.7K).
• Le pic absolu sur cette heure affiche 1 800 erreurs en à peine une minute (1.8K).

Pourquoi une attaque DDoS est un danger mortel pour un business local

Une ddos attaque sur un site web (Distributed Denial of Service) cherche à saturer les ressources d’un serveur pour le rendre indisponible. Pour une PME ou un artisan, les enjeux sont bien plus graves qu’une simple panne technique :

• La perte immédiate de chiffre d’affaires : Si un internaute fait face à une page blanche ou à une erreur de connexion, il ne patiente pas. Il retourne sur Google et clique sur le site suivant.
• Le gaspillage des budgets publicitaires : Les robots forcent le passage via les liens publicitaires, épuisant le budget quotidien en quelques minutes.
• La destruction du score SEO : Si les robots de Google tentent de visiter votre site alors qu’il est en panne, votre positionnement dans les résultats de recherche va s’effondrer.

Sur les hébergements mutualisés classiques, les serveurs intègrent des barrières de sécurité pour protéger les autres utilisateurs. Lorsque votre site consomme trop d’énergie à cause des robots, l’hébergeur coupe l’accès. C’est la fameuse erreur « 508 Resource Limit Is Reached ».

Si vous êtes vous-même confronté à des ralentissements inexpliqués ou à des plantages à répétition dès que vous lancez vos campagnes, sachez que vous subissez peut-être une attaque invisible. Dans ce genre de situation, vous pouvez passer par nous : l’agence Incrona dispose d’une cellule de crise capable de sécuriser des sites WordPress ou tout autre site web en un temps record.

Résolution étape par étape : Comment nous avons construit une forteresse avec Cloudflare

Face à une lance à incendie d’un milliard de requêtes, votre serveur d’hébergement ne peut rien faire seul. Il faut déplacer le champ de bataille en amont, grâce à un réseau de diffusion de contenu (CDN) comme Cloudflare. Bien que Cloudflare gère cela assez bien nativement, les réglages par défaut ne suffisaient pas face à la puissance de l’algorithme adverse. Voici la méthode exacte que j’ai appliquée.

Étape 1 : Le bannissement massif des adresses IP d’attaque (WAF)

En analysant l’historique des connexions de sécurité, j’ai repéré que l’attaque ne provenait pas d’humains derrière leurs écrans, mais de puissants serveurs virtuels loués en centres de données (datacenters) à l’étranger. Quelques dizaines d’adresses IP envoyaient des millions de requêtes à la minute.

Pour éviter de saturer l’interface visuelle de Cloudflare avec des listes interminables, je suis passé par l’éditeur d’expressions (Edit expression) du pare-feu pour bloquer ces machines d’un seul coup grâce à la syntaxe brute :

ip.src in {62.133.62.187 62.133.62.12 62.133.62.231 ...}

Étape 2 : L’activation du mode d’urgence « Sous attaque ! » (I’m Under Attack)

Les pirates ont rapidement tenté de contourner notre premier blocage géographique. En utilisant des proxys et des serveurs VPN basés en France, ils ont essayé de fondre leurs robots dans la masse pour se faire passer pour des clients locaux légitimes.

Face à cette tentative d’infiltration massive, il n’était plus question de faire de la dentelle. Je me suis immédiatement rendu dans l’onglet Security > Settings de Cloudflare pour activer l’option de crise ultime dans le menu Security Level : le mode « I’m Under Attack! » (Sous attaque !).

Qu’est-ce que le mode « Sous attaque » ? C’est le bouton rouge de Cloudflare. Lorsqu’il est activé, Cloudflare considère par défaut que le site subit un assaut critique. Il applique instantanément une vérification stricte du navigateur (un défi JavaScript invisible) à chaque visiteur qui tente d’entrer.

Pour les robots informatiques de la concurrence, ce mode est un mur infranchissable. Leurs scripts automatisés sont incapables de résoudre ce défi en arrière-plan et ils se font éjecter avant même d’avoir pu toucher le serveur. Pour un vrai client d’Île-de-France, l’expérience reste totalement sécurisée : Cloudflare analyse son navigateur en une fraction de seconde, valide qu’il s’agit bien d’un humain, lui attribue un jeton d’accès sécurisé et le laisse naviguer normalement.

Étape 3 : Le déploiement du gilet pare-balles ultime : Le « Cache Everything »

C’est l’étape maîtresse de notre intervention. Par défaut, Cloudflare ne met pas en cache les pages de texte (le code HTML) de votre site WordPress, car il considère que ce contenu est dynamique. Résultat : chaque visite de robot forçait le serveur de l’artisan à travailler.

Pour y remédier, j’ai créé une règle de mise en cache totale via les Cache Rules en utilisant le modèle Cache everything [Template].

J’ai appliqué la règle à l’ensemble des requêtes entrantes (All incoming requests) et j’ai configuré l’option Edge TTL sur Ignore cache-control header and use this TTL avec une durée de 5 heures.

Grâce à cela, Cloudflare a reçu l’ordre de garder en mémoire une copie parfaite de toutes les pages du site. Lorsqu’un robot tente de visiter une page pour saturer le serveur, Cloudflare lui fournit la copie stockée dans ses propres banques de données. La requête ne parvient jamais à l’hébergeur de notre client. La charge sur son serveur est instantanément retombée à zéro.

La victoire en chiffres : 1,43 milliard d’attaques stoppées net

Le lendemain de la mise en place de ces mesures, j’ai ouvert les outils d’analyse de Cloudflare pour vérifier l’état de santé du site web. Le spectacle était saisissant.

Le site avait essuyé un volume incroyable de 1,43 milliard de requêtes malveillantes. Mais regardez la beauté de la sécurité bien configurée : sur ce volume astronomique, un peu moins de 1,43 milliard de requêtes ont été bloquées en amont avec un code d’erreur 403 Forbidden.

Le serveur d’origine, quant à lui, n’a eu à traiter que quelques dizaines de milliers de requêtes légitimes et fichiers légers mis en cache. L’attaque continuait de faire rage à l’extérieur, mais à l’intérieur, le site web de notre client fonctionnait à merveille, les pages se chargeaient en moins d’une seconde, et les demandes de devis de vrais clients franciliens arrivaient à nouveau sur les téléphones.

Conclusion : Ne restez pas démuni face aux attaques de vos concurrents

Cette expérience montre qu’aujourd’hui, la réussite d’un business local dépend grandement de sa sécurité numérique. Les attaques DDoS ne sont plus l’apanage des géants du web ; elles sont utilisées comme des armes de destruction commerciale à l’échelle locale pour couler le site internet d’un confrère trop bien positionné.

Faire face à une telle crise demande de la réactivité et une expertise pointue des infrastructures serveurs et des réseaux de distribution. Si votre site internet donne des signes de faiblesse, si vous suspectez des comportements malveillants ou si vous souhaitez simplement auditer votre installation actuelle pour éviter le pire, n’attendez pas qu’il soit trop tard. Vous pouvez passer par nous : l’agence Incrona est à votre disposition pour auditer, nettoyer et sécuriser vos plateformes afin que vous puissiez vous concentrer sur ce que vous faites de mieux : votre métier.