WordPress sous attaque - CPU à 100%
Diagnostic et résolution en moins de 24h d'un serveur en surcharge critique causé par des attaques de bots AI.
Le défi
Un serveur cPanel/WHM hébergeant plusieurs sites WordPress était en surcharge critique (CPU 90-100%) depuis plus d'une semaine, rendant tous les sites hébergés pratiquement inutilisables.
L'hébergeur avait identifié qu'un site WordPress en particulier causait le problème, mais ne savait pas quelle en était la cause exacte. Le client risquait de perdre son hébergement si le problème n'était pas résolu rapidement.
Contexte
- Secteur
- Hébergement multi-sites
- Stack technique
- cPanel/WHM, CloudLinux, WordPress, MySQL
- Durée du problème
- 1+ semaine
- Temps de résolution
- Moins de 24 heures
Symptômes observés
CPU constant à 90-100 %
Le serveur était en surcharge permanente. CloudLinux LVE limits dépassées constamment, ralentissant tous les sites hébergés.
Temps de chargement 5-15 secondes
Le site WordPress problématique prenait entre 5 et 15 secondes à charger, quand il ne tombait pas en timeout (erreur 503/504).
Trafic anormal
Les logs montraient un trafic suspect avec des patterns de bots automatisés, particulièrement sur certaines pages spécifiques.
Diagnostic approfondi
1. Analyse des logs et du trafic
Première étape : identifier la source réelle du problème.
- Analyse des access logs Apache/LiteSpeed
- Identification de patterns d'attaque de bots AI (crawlers agressifs)
- Requêtes répétitives sur des URLs spécifiques non-cachées
- User-agents suspects et adresses IP récurrentes
2. Audit de la configuration WordPress
Analyse de l'installation WordPress elle-même.
- 50+ plugins installés, dont plusieurs désactivés mais non désinstallés
- Plusieurs plugins obsolètes ou mal configurés
- Pas de système de cache actif
- Thème avec code non optimisé
- Base de données WordPress jamais optimisée (transients expirés, révisions excessives)
3. Analyse de la configuration serveur
- PHP OpCache mal configuré (mémoire insuffisante, TTL trop court)
- Aucun système de cache objet (Redis/Memcached)
- Configuration MySQL sous-optimale pour la charge
- Pas de protection contre les bots au niveau serveur
Solution mise en place
1. Blocage immédiat de l'attaque
- Identification et blocage des IPs malveillantes via .htaccess et fail2ban
- Mise en place de règles pour bloquer les bots AI agressifs
- Configuration rate limiting au niveau serveur
- Ajout de Cloudflare avec mode "I'm Under Attack" temporaire
Résultat immédiat : CPU descendu de 100% à 60-70% en quelques minutes.
2. Nettoyage et optimisation WordPress
- Désinstallation (pas juste désactivation) des plugins inutilisés : 50+ → 25 plugins
- Mise à jour des plugins et thème vers versions stables récentes
- Optimisation base de données (nettoyage transients, révisions, spam)
- Installation et configuration d'un plugin de cache (WP Rocket / W3 Total Cache)
- Optimisation images (lazy loading, compression)
3. Optimisation PHP OpCache
- Augmentation de la mémoire OpCache (128M → 512M)
- Ajustement des paramètres de TTL et de revalidation
- Configuration du nombre de fichiers cachés
- Monitoring OpCache avec script de statistiques
4. Implémentation de Redis
- Installation et configuration de Redis sur le serveur
- Configuration WordPress pour utiliser Redis comme cache objet
- Mise en cache des requêtes de base de données fréquentes
- Configuration des TTL appropriés selon le type de contenu
Résultats spectaculaires en moins de 24h
Monitoring Zabbix - Utilisation CPU du serveur
Le graphique montre clairement la chute drastique de l'utilisation CPU après le blocage des bots et les optimisations. Le CPU user time (en vert) passe de ~57% en moyenne à un niveau minimal.
Réduction de 70%
Amélioration de 90%+
Tous les sites fonctionnent
Bots AI neutralisés
Impact business
- Hébergement sauvé (le client allait être suspendu)
- Tous les sites hébergés fonctionnent normalement
- Économies sur ressources serveur (peut héberger plus de sites)
- Expérience utilisateur transformée (site rapide et stable)
- Protection continue contre les futures attaques
Leçons techniques
Erreurs courantes identifiées
- Plugins désactivés mais non désinstallés (charge inutile)
- Aucun système de cache (ni page, ni objet)
- OpCache mal configuré ou désactivé
- Pas de protection contre les bots agressifs
- Base de données jamais nettoyée
Bonnes pratiques appliquées
- Diagnostic méthodique (logs → configuration → code)
- Action immédiate pour réduire la charge (blocage attaque)
- Optimisations multi-niveaux (serveur, PHP, WordPress, BD)
- Implémentation de monitoring pour prévenir récidive
- Documentation des changements pour le client
Technologies et outils utilisés
Infrastructure
Application
Cache & Sécurité
Votre WordPress est lent ou votre serveur surchargé ?
webO3 peut diagnostiquer rapidement la cause réelle du problème et le résoudre avec des optimisations mesurables et durables.
Votre site est lent ? Recevez un diagnostic gratuit en 24 h.
Triage gratuit sans engagement. Un expert vous répond en moins de 8 h ouvrables.