Comment protéger un site WordPress contre les attaques DDoS et rester en ligne ?

Une attaque DDoS peut transformer un site WordPress en machine à latence, coûteuse et démotivante pour vos visiteurs. Comprendre comment ces attaques se manifestent, quelles erreurs courantes les facilitent et quelles mesures pragmatiques vous pouvez appliquer aujourd’hui aide à limiter les dégâts et à récupérer plus vite si cela vous arrive.

Comment reconnaître une attaque DDoS sur WordPress

La première erreur est de confondre pic de trafic légitime et attaque. Des signes qui doivent éveiller vos soupçons incluent des erreurs 502 ou 503 répétées, des temps de réponse très longs malgré peu de visites visibles dans Google Analytics, et une augmentation massive des requêtes vers des points sensibles comme wp-login.php, xmlrpc.php ou des endpoints REST. Vérifiez vos logs serveur et les connexions actives. Si vous voyez des milliers de requêtes en provenance d’un grand nombre d’adresses IP différentes mais avec des patterns identiques d’user‑agent ou de chemin d’URL, il y a de fortes chances que ce soit une attaque.

Autre indicateur moins évident, l’écart entre métriques côté serveur et métriques côté analytics. Les bots malveillants n’exécutent pas toujours JavaScript, ils peuvent gonfler les connexions TCP sans apparaître dans vos outils de mesure client. Surveillez la consommation CPU, le nombre de connexions simultanées, et les files d’attente de la base de données.

Quelles sont les erreurs les plus fréquentes qui rendent WordPress vulnérable

Beaucoup de sites sont victimes non pas parce qu’ils sont ciblés spécifiquement, mais parce qu’ils présentent des cibles faciles. Parmi les erreurs récurrentes que j’observe :

• Laisser xmlrpc.php et les pingbacks activés sans besoin. Ces fonctions anciennes peuvent être utilisées comme amplificateurs.
• Exposer l’IP d’origine du serveur dans des enregistrements DNS ou des en-têtes de mail, ce qui permet de contourner une protection basée sur un CDN ou un WAF.
• Héberger sur des offres mutualisées à bas coût sans isolation des ressources, impossible à faire monter en charge pendant une attaque.
• Confondre plugin de sécurité et prévention DDoS. Un plugin agit sur le serveur déjà sollicité, il ne stoppe pas le trafic avant qu’il n’atteigne votre machine.
• TTL DNS trop long ou changement DNS mal préparé lorsque vous tentez d’activer une protection externe en urgence.

Quelles défenses déployer pour limiter l’impact d’une attaque DDoS

La stratégie la plus efficace combine filtrage en amont, réduction du travail côté serveur et règles spécifiques sur les endpoints sensibles. En pratique, cela donne :

• Mettre un WAF et un CDN devant votre site pour filtrer et absorber le trafic.
• Désactiver ou restreindre l’accès à xmlrpc.php si vous ne l’utilisez pas.
• Limiter les tentatives vers wp-login.php et admin-ajax.php avec des règles de rate limiting au niveau reverse proxy ou via fail2ban.
• Cacher l’IP d’origine et n’autoriser que les adresses IP de votre WAF à joindre le serveur.
• Mettre en cache autant que possible et proposer une page statique de secours si l’origine est saturée.

Ces mesures se complètent. Un CDN bien configuré réduit les requêtes vers l’origine, un WAF bloque les patterns malveillants avant qu’ils n’atteignent WordPress et les règles côté serveur protègent les zones critiques restantes.

Comment réagir immédiatement si votre site est attaqué

Quand ça se produit, la panique fait souvent commettre des erreurs. Voici une checklist d’actions rapides et efficaces que j’ai vue fonctionner en conditions réelles

• Confirmez l’attaque avec les logs et les métriques serveur plutôt qu’en vous fiant seulement à l’apparence du site.
• Activez ou redirigez le trafic vers un WAF/CDN capable d’intervention d’urgence.
• Appliquez un mode maintenance statique pour économiser les ressources backend.
• Bloquez les IPs et user agents manifestement malveillants et mettez en liste blanche les adresses de votre équipe et de votre hébergeur.
• Contactez l’hébergeur pour demander un filtrage au niveau réseau ou un blackhole si nécessaire.
• Sauvegardez immédiatement les logs et horodatages, envoyez-les sur un stockage externe pour conserver les preuves.

Quelle protection choisir selon votre budget et vos besoins

Il n’existe pas d’unique réponse adaptée à tous. Voici un tableau synthétique pour comparer les approches courantes et leurs limites.

Solution	Avantages	Limites
WAF cloud + CDN	Filtrage avant l’origine, amélioration des performances, mise à l’échelle	Coût, configuration DNS, nécessite cacher IP d’origine
Protection fournie par l’hébergeur	Filtrage réseau en amont, gestion par l’équipe d’infra	Qualité variable, attention aux offres mutualisées
Plugin de sécurité WordPress	Facile à déployer, utile pour hardening	Ne bloque pas le trafic avant qu’il n’atteigne votre serveur
Mesures serveur (nginx rate limit, fail2ban)	Contrôle fin, gratuit ou peu coûteux	Effet limité si l’origine est déjà saturée

Quels endpoints WordPress protéger en priorité et comment le faire

Certaines URL valent mieux qu’on les verrouille immédiatement. wp-login.php et xmlrpc.php sont les plus ciblés. Pour les protéger, vous pouvez appliquer une ou plusieurs de ces techniques selon votre environnement :

• Restreindre l’accès par adresse IP ou via une authentification HTTP basique.
• Implémenter un challenge JavaScript ou CAPTCHA au niveau du WAF pour filtrer les robots.
• Mettre en place du rate limiting strict et des règles bloquant les patterns répétitifs.
• Désactiver les fonctionnalités inutilisées comme les pingbacks depuis la configuration WordPress.

Ne négligez pas non plus le REST API. Des requêtes massives sur des endpoints REST peuvent épuiser votre base de données. Limitez les méthodes exposées et surveillez les volumes d’appels.

Pratiques de surveillance et post‑incident

La prévention ne s’arrête pas à la mise en place d’un WAF. Il faut surveiller activement et conserver des preuves pour l’analyse. Configurez l’export régulier des logs vers un stockage externe, activez des alertes basées sur le nombre de requêtes par seconde et la latence de la base. Après incident, analysez les patterns pour ajuster vos règles et coller des signatures dans votre WAF.

Indicateurs utiles à surveiller

RPS, taux d’erreurs 5xx, connexions TCP actives, provenance géographique, user agents et chemins ciblés. Ces métriques vous permettent de distinguer un afflux légitime d’un trafic malveillant et d’affiner vos règles de blocage.

FAQ

Mon site WordPress peut-il gérer une attaque DDoS sans services externes
Rarement. Sans filtrage en amont, même des centaines de requêtes par seconde peuvent saturer la base de données et le CPU.

Est‑ce qu’un plugin de sécurité suffit pour arrêter un DDoS
Non. Les plugins aident pour le hardening mais voient les requêtes après leur arrivée sur le serveur. Un WAF cloud est nécessaire pour filtrer en amont.

Que faire si mon fournisseur met du temps à répondre
Mettez en place des règles locales de mise en cache et une page statique, bloquez les patterns évidents et activez le mode maintenance pour préserver l’origine pendant que le fournisseur intervient.

Faut‑il désactiver xmlrpc.php et les pingbacks
Si vous n’en avez pas besoin, oui. Ce sont des vecteurs fréquemment exploités pour amplifier les attaques.

Combien de temps faut‑il pour activer une protection DDoS
En général quelques minutes à quelques heures selon le fournisseur et la propagation DNS. Préparez au préalable votre configuration pour gagner du temps en urgence.