Attaque DDoS sur un site WooCommerce : boutique rétablie en 2 h 30

Des milliers de requêtes par minute, une boutique en ligne inaccessible et des commandes bloquées en pleine période de promotions. Voici comment nous avons reconnu l’attaque, filtré le trafic et protégé le site pour la suite.

Mardi, 9 h 50 : plus aucune commande

Ce mardi-là, la boutique était en pleine opération de promotions. À 9 h 50, les pages ont commencé à mettre plus de 20 secondes à s’afficher. À 10 h 05, une page d’erreur avait remplacé le site.

L’équipe du client a d’abord pensé à une panne chez l’hébergeur. Mais le serveur fonctionnait : il était simplement submergé. Pendant ce temps, le service client enchaînait les appels de clients qui n’arrivaient plus à accéder à la boutique.

Le responsable e-commerce nous a appelés à 10 h 40. Nous ne travaillions pas encore ensemble : il a d’abord fallu valider notre intervention d’urgence et récupérer les accès à l’hébergement.

Afflux de clients ou attaque ? Le diagnostic en 20 minutes

Un site qui tombe en pleine opération commerciale ne subit pas forcément une attaque. Un vrai afflux de clients peut aussi saturer un serveur trop juste : nous avons d’ailleurs géré un pic de trafic sur un autre site. Avant de bloquer quoi que ce soit, il fallait savoir à qui on avait affaire.

Trois indices ont suffi :

• Les vrais visiteurs n’avaient pas augmenté. Au moment où le site a commencé à ralentir, Google Analytics ne montrait aucune hausse de fréquentation. Le serveur, lui, recevait jusqu’à 12 000 requêtes par minute, contre environ 250 un jour de promotions classique.
• Ces requêtes ne ressemblaient pas à des clients. Elles visaient toujours les trois mêmes pages : la recherche interne, avec des mots tirés au hasard, l’ajout au panier et la page de connexion. Aucune de ces pages ne peut être mise en cache, donc chaque requête fait travailler le serveur.
• Elles venaient de plus de 1 500 adresses IP, presque toutes situées dans des pays où la boutique n’a jamais vendu un seul article.

C’était donc une attaque par déni de service distribué (DDoS) : des milliers de machines sollicitent le site en même temps pour l’épuiser. Ce type d’attaque ne vise pas les données, seulement la disponibilité du site. Nous avons tout de même vérifié qu’aucune intrusion ne l’accompagnait.

L’intervention, heure par heure

1. 10 h 40 Appel du responsable e-commerce. Nous lui proposons une intervention d’urgence, qu’il valide par e-mail dans la foulée.
2. 11 h 25 Nous recevons les accès à l’hébergement et au site, que le client a dû retrouver.
3. 11 h 45 Diagnostic posé : il s’agit d’une attaque DDoS sur la recherche, le panier et la page de connexion.
4. 12 h 00 Nous bloquons les 200 adresses IP les plus actives. Le serveur respire un peu, mais d’autres adresses prennent le relais.
5. 12 h 25 Nous plaçons un pare-feu devant le site. Toutes les requêtes sont filtrées avant d’atteindre le serveur.
6. 13 h 10 Le site est de nouveau accessible et les premières commandes arrivent dans la foulée.
7. 19 h 30 Une deuxième vague arrive, plus forte que la première. Le pare-feu la bloque et le site ne ralentit pas.
8. Le lendemain Contrôle complet, sans aucune intrusion ni fichier modifié. Nous affinons les règles du pare-feu.

Ce que fait le pare-feu, concrètement

Bloquer les adresses une par une ne servait à rien : chaque adresse bloquée était aussitôt remplacée par une autre. Il fallait trier le trafic avant qu’il n’arrive sur le serveur. Le pare-feu applique quatre règles :

1. Un filtre par pays. La boutique vend en France et dans les pays voisins, donc le trafic venant des pays où elle n’a aucun client est bloqué. Avant d’activer cette règle, nous avons autorisé les serveurs du prestataire de paiement et du transporteur. Sans cette exception, les confirmations de paiement n’auraient plus été reçues.
2. Le blocage des adresses IP malveillantes, à partir de listes mises à jour en continu et des adresses repérées pendant l’attaque.
3. Une limite de requêtes par visiteur. Un vrai client ne lance pas des dizaines de recherches par minute. Au-delà d’un certain seuil, les requêtes d’une même adresse sont refusées.
4. Des portes d’entrée mieux protégées. La page de connexion à l’administration n’accepte plus que des connexions depuis la France. Nous avons aussi fermé le fichier xmlrpc.php, une ancienne porte d’entrée de WordPress souvent visée par ces attaques et inutile pour ce site.

Ces quatre règles complètent les mesures que nous détaillons dans notre guide pour sécuriser un site WordPress.

Pour que ça ne se reproduise pas

Le pare-feu est resté en place, et le client a ensuite opté pour notre contrat de maintenance WordPress :

• une surveillance permanente, avec une alerte dès que le site ralentit ;
• des mises à jour de WordPress, WooCommerce et des extensions, testées avant d’être appliquées ;
• des sauvegardes quotidiennes ;
• et une équipe qui connaît déjà le site si un problème survient.

Études de cas similaires

Média en ligne

Pics de trafic WordPress : un média en ligne qui ne tombe plus

Résultat : plus aucune interruption lors des pics de trafic.

Presse professionnelle

Site WordPress piraté : un magazine remis en ligne en moins de 24 h

Résultat : site remis en ligne en moins de 24 h, sans redirection.