Votre site subit une attaque DDoS ? Que faire maintenant

Si votre site devient soudain lent ou inaccessible et que votre serveur reçoit bien plus de requêtes que d’habitude, vous subissez peut-être une attaque DDoS. La mesure la plus efficace à prendre tout de suite est de placer un filtrage devant votre serveur, car un serveur déjà submergé ne peut pas se défendre lui-même. Ce guide vous aide à reconnaître une attaque, à réagir pendant la première heure et à mettre en place la configuration qui rendra la prochaine attaque beaucoup moins pénible.

Comment reconnaître une attaque DDoS

Une attaque par déni de service distribué (DDoS) inonde votre site de trafic provenant de nombreuses sources à la fois, si bien que les vrais visiteurs ne passent plus. Tous les pics de trafic ne sont pas des attaques pour autant. Une newsletter, un passage à la télévision ou des soldes peuvent y ressembler au premier coup d’œil. Cherchez plutôt ces signes :

• Le pic n’a aucune raison commerciale. Pas de campagne, pas de presse, pas de lancement, et pourtant les requêtes s’envolent.
• Les requêtes visent toujours les mêmes URL. Souvent la page d’accueil, une page de recherche, une page de connexion ou une URL avec des paramètres aléatoires (/?x=83729) conçus pour contourner les caches.
• Des sources de trafic inhabituelles. Beaucoup de requêtes venant de pays où vous n’avez aucun client, de plages d’IP d’hébergeurs, ou avec des user agents identiques ou vides.
• Aucune conversion. Le trafic augmente alors que les ventes, les inscriptions et le temps passé sur la page ne bougent pas.
• Votre serveur est à saturation. Le CPU, les workers PHP ou les connexions à la base de données atteignent leur limite, et le journal d’erreurs se remplit de timeouts et d’erreurs 502/503/504.

Examinez votre journal d’accès

Si vous avez un accès shell, un coup d’œil au journal d’accès en dit long. Ces commandes affichent les IP les plus actives et les chemins les plus demandés (adaptez le chemin du journal à votre serveur) :

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Une poignée d’IP envoyant des milliers de requêtes indique une petite attaque que vous pouvez bloquer directement. Des milliers d’IP envoyant chacune un volume modéré indiquent un botnet, bien plus difficile à arrêter au niveau du serveur.

Les types d’attaques possibles

Connaître le type approximatif d’attaque aide à choisir la bonne réponse.

La plupart des attaques visant les sites de petites et moyennes entreprises sont des floods HTTP de couche 7. Elles n’ont pas besoin d’une énorme bande passante, car chaque requête impose à votre serveur un travail coûteux : générer une page, lancer une recherche, interroger la base de données. Quelques centaines de requêtes non mises en cache par seconde peuvent suffire à faire tomber une boutique ou un CMS classique.

Que faire dans la première heure

Gardez votre calme et procédez dans cet ordre. Notez ce que vous faites et à quel moment, car vous en aurez besoin plus tard.

1. Confirmer et informer

Assurez-vous qu’il ne s’agit pas d’un déploiement raté, d’une extension défaillante ou d’un pic légitime. Prévenez ensuite les personnes concernées : votre équipe, votre agence et votre hébergeur. Les hébergeurs voient souvent l’attaque dans leur supervision réseau et filtrent parfois déjà le trafic ou, dans certains cas, mettent votre IP en null-route pour protéger leurs autres clients.

2. Contacter votre hébergeur

Demandez directement à votre hébergeur ce qu’il observe, quelle protection il propose et s’il peut filtrer au niveau réseau. Certains hébergeurs incluent une protection DDoS de base, d’autres non. Si votre serveur est mis en null-route, il vous faut une couche de filtrage devant lui avant qu’il ne revienne en ligne.

3. Bloquer ce que vous pouvez identifier

Si l’attaque vient d’un petit nombre d’IP ou de plages d’adresses, bloquez-les dans votre pare-feu ou dans la configuration de votre serveur web. Si elle vise une URL coûteuse, comme un point d’accès de recherche, limitez temporairement son débit ou désactivez-la. Si elle vient surtout de pays que vous ne desservez pas, un blocage géographique ou un challenge temporaire peut vous faire gagner du temps. Ce sont des solutions d’appoint, pas une stratégie.

4. Placer une couche de filtrage devant votre serveur

La vraie solution consiste à arrêter le trafic malveillant avant qu’il n’atteigne votre origine. Un reverse proxy ou un CDN avec protection DDoS absorbe et filtre les requêtes en edge, et votre serveur ne voit que ce qui passe le filtre. La mise en place passe généralement par un changement des serveurs de noms de votre domaine, qui prend effet à mesure que les caches DNS expirent. Si vous le faites en pleine attaque, suivez une checklist pour ne perdre ni vos e-mails ni vos autres enregistrements. Notre guide pour changer de serveurs de noms sans interruption traite précisément ce point.

5. Réduire le travail causé par chaque requête

Pendant l’attaque, rendez chaque requête moins coûteuse. Servez des pages en cache partout où c’est possible, désactivez les fonctions lourdes dont vous pouvez vous passer une journée (recherche instantanée, widgets de produits associés, appels à des API externes) et vérifiez que votre cache n’est pas contourné par des paramètres d’URL aléatoires.

Les erreurs à éviter pendant une attaque

• Ne vous contentez pas d’augmenter la puissance du serveur. Plus de CPU aide brièvement, mais les attaquants montent généralement en charge plus vite que votre budget d’hébergement. Et cela n’arrête pas les attaques qui saturent la bande passante.
• Ne payez pas de rançon. Certaines attaques s’accompagnent d’une demande de paiement. Payer ne garantit rien et vous désigne comme une cible docile. Signalez l’extorsion à la police.
• Ne bloquez pas trop largement. Bloquer des pays entiers ou tous les bots peut exclure des clients et les robots des moteurs de recherche. En cas de doute, préférez les challenges aux blocages stricts, et supprimez les règles temporaires une fois l’attaque terminée.
• N’oubliez pas les autres surfaces d’attaque. Un DDoS sert parfois de diversion. Vérifiez ensuite les connexions, les comptes administrateurs et les modifications récentes. La présentation des attaques par déni de service de la CISA (en anglais) le mentionne aussi.

Après l’attaque : renforcer votre configuration

Une fois le calme revenu, tirez parti de ce que vous avez appris. L’objectif est que la prochaine attaque se heurte à un filtre, pas à votre serveur.

Garder un proxy en place en permanence

Le filtrage en edge fonctionne le mieux quand il est déjà en place. L’ajouter en pleine attaque vous fait perdre du temps pendant la propagation des changements DNS. Si vous ne savez pas exactement ce qu’un CDN vous apporte au-delà de la vitesse, lisez ce qu’est un CDN et si votre site en a besoin.

Mettre en cache tout ce qui peut l’être sans risque

Chaque page servie depuis un cache est une requête que votre serveur ne voit jamais. Les pages publiques comme la page d’accueil, les catégories, les fiches produit et les articles de blog doivent être mises en cache. Les pages personnelles comme le panier, la commande et le compte client doivent rester dynamiques. Un taux de cache hit élevé laisse aussi plus de marge à votre serveur pour les vrais visiteurs, et une origine rapide aide également : consultez le guide pour réduire le TTFB.

Verrouiller l’origine

N’autorisez le trafic HTTP et HTTPS vers votre serveur que depuis les plages d’IP de votre proxy. Tenez l’IP de l’origine à l’écart des enregistrements DNS publics, des en-têtes d’e-mails et des anciens sous-domaines, car ce sont les moyens habituels par lesquels les attaquants la trouvent.

Définir des limites de débit et des alertes

Des limites de débit sur les connexions, la recherche et les API arrêtent à la fois les floods et les tentatives de force brute. Des alertes sur les pics de trafic et les taux d’erreurs vous permettent d’apprendre la prochaine attaque par une notification, et non par un client.

Rédiger une courte procédure d’urgence

Une page suffit : qui appeler chez votre hébergeur, qui a accès au DNS et au tableau de bord du proxy, quelles règles activer et comment informer les clients. En pleine attaque, personne n’a envie de chercher des mots de passe.

Comment fast.site vous aide

fast.site se place devant votre hébergement existant. Vous gardez votre hébergeur et faites pointer les serveurs de noms de votre domaine vers fast.site. Dès lors, le trafic atteint d’abord le réseau edge et y est filtré avant que quoi que ce soit ne soit transmis à votre origine.

La détection des attaques DDoS de couche 7 fonctionne automatiquement sur tous les domaines, sans aucune configuration. Vous pouvez en plus bloquer des IP et des plages CIDR, bloquer des pays entiers ou leur imposer un challenge CAPTCHA, créer vos propres règles de challenge et définir des limites de débit par IP. Des ensembles de règles gérés protègent contre l’injection SQL, le XSS et les bots malveillants. Consultez la documentation sur la sécurité pour les détails.

La mise en cache réduit encore la charge. Les pages publiques servies depuis l’edge affichent fs-cache: HIT et ne sollicitent jamais votre serveur, tandis que les paniers, la commande et les sessions connectées affichent BYPASS et atteignent votre origine comme d’habitude. Les statistiques affichent les requêtes, les taux d’erreurs et la bande passante de l’origine, et des alertes d’anomalie vous préviennent en cas de pic de trafic.

Si vous êtes attaqué en ce moment même, rendez-vous sur la page d’urgence en cas d’attaque pour la solution la plus rapide. Sinon, vous pouvez mettre en place la protection sereinement et vérifier le résultat sur votre propre site. Vous pouvez commencer par un essai gratuit de 7 jours, sans carte bancaire. Les offres et le trafic inclus figurent sur la page des tarifs.

Questions fréquentes

Combien de temps dure une attaque DDoS ?

Cela varie énormément. Certaines attaques durent quelques minutes, d’autres arrivent par vagues pendant plusieurs jours. Les salves courtes sont fréquentes, souvent comme test avant une attaque plus importante ou accompagnées d’une demande de rançon. C’est pourquoi une protection active en permanence est plus utile qu’une solution que l’on active pendant l’attaque.

Une attaque DDoS peut-elle nuire à mon référencement ?

Une courte interruption n’a généralement pas d’effet durable. Si votre site reste inaccessible ou renvoie des erreurs pendant une période prolongée, les moteurs de recherche peuvent l’explorer moins souvent et retirer temporairement des pages. Remettre rapidement le site en ligne et renvoyer des codes de statut corrects limite les dégâts.

Une attaque DDoS est-elle illégale ?

Oui, dans la plupart des pays, lancer une attaque DDoS est une infraction pénale. Conservez les journaux, les horodatages et les éventuels messages de rançon, et signalez l’attaque à la police ou au service national de lutte contre la cybercriminalité. C’est particulièrement important quand une somme d’argent est exigée.

Une extension de sécurité WordPress peut-elle arrêter une attaque DDoS ?

Pas vraiment. Une extension s’exécute à l’intérieur de WordPress : chaque requête atteint donc toujours votre serveur, démarre PHP et interroge souvent la base de données avant que l’extension ne puisse la bloquer. C’est exactement la charge sur laquelle repose un DDoS. Les extensions sont utiles contre les attaques sur la connexion et les logiciels malveillants, mais le filtrage DDoS doit se faire devant le serveur.

Pourquoi mon site est-il lent alors que le trafic semble normal ?

Dans ce cas, il ne s’agit probablement pas d’un DDoS. Les causes fréquentes sont un hébergement lent, des extensions lourdes, des pages non mises en cache ou des images volumineuses. L’article d’assistance sur un site lent est un bon point de départ.