Processeur serveur saturé : mineur, bot ou générateur de pages

Lire la charge avant de « optimiser »

Un plugin de cache n'explique pas un load à 40 sur un mutualisé. Avant de payer un « turbo », ouvrez les stats hébergeur : CPU, I/O, entrée HTTP. Un pic CPU sans trafic est un mineur ou un cron. Un pic CPU + access.log monstrueux est un bot. Un pic I/O + milliers de fichiers nouveaux est un générateur.

Notez l'heure du pic et l'heure du premier e-mail d'abus. Elles alignent le process. Une optimisation thème pendant que `xmrig` tourne vous fait perdre l'après-midi.

Si le panel est déjà en « resource limit », ne migrez pas. Vous emportez le process. Demandez un access temporaire ou une archive, comme pour une suspension.

Les process parlent plus que le thème

VPS : `top` / `htop`, puis `ps aux` sur le PID. La ligne de commande est le chemin. Un `php /tmp/.x` ou un binaire `kthreadd` dans votre home n'est pas Apache. Mutualisé : gestionnaire de processus du panel, ou ticket « quel uid consomme ».

Copiez la ligne complète avant de tuer. Tuer sans noter, le cron relance dans 60 secondes et vous n'avez plus le chemin. C'est le motif n°1 des « j'ai tué ça revient ».

PHP-FPM : trop de processus `php-fpm` peut être du trafic réel (soldes) ou un loop. Le `access.log` tranche : 200 000 hits `/xmlrpc.php` n'est pas la home.

• Ligne de commande complète, horodatée.
• UID : le vôtre ou un voisin.
• Relance : cron, systemd, `.bashrc`.
• Hits HTTP en parallèle ou non.

Cause 1 : mineur (CPU plat, peu de hits)

CPU saturé 24 h, peu de requêtes web, ventilateur du VPS à fond : mineur. Noms fréquents : `xmrig`, `kdevtmpfsi`, un process déguisé en `[php]` ou `apache2` dans votre home. Fichiers dans `/tmp`, `~/.cache`, un dossier `uploads` avec un binaire.

Retirer le binaire sans le cron / la backdoor, c'est J+1 à 100 % encore. Cherchez crontab, `~/.ssh`, les services utilisateur, un mu-plugin qui relance. Voir aussi cryptominage : le mineur navigateur, lui, sature le CPU du visiteur, pas le serveur — autre symptôme.

L'hébergeur classe ça en « resource abuse ». Il veut le binaire parti et la porte fermée, pas un thème plus léger. Le constat écrit (trouvé, retiré, cron vidé) accélère la réouverture.

Cause 2 : bot et bruteforce (access.log)

`wp-login.php`, `xmlrpc.php`, `xmlrpc.php?rsd`, un `POST` toutes les 20 ms : bruteforce ou amplification. Le CPU est du PHP légitime trop appelé. Coupez xmlrpc si vous ne vous en servez pas, limitez `wp-login`, WAF, fail2ban sur VPS. Ce n'est pas toujours un malware déjà posé — c'est souvent la porte d'entrée en cours.

Un bot qui frappe des milliers d'URL spam déjà générées sature aussi. Là le malware est en amont : le générateur. Limiter le bot sans tuer le générateur, le CPU redescend un peu, l'index Google continue de pourrir.

Cloudflare ou le WAF de l'hébergeur calme le hit. Posez-le comme un pare-feu temporaire, pas comme un nettoyage. Voir WAF après piratage.

Cause 3 : générateur de pages (I/O + index)

Des milliers de fichiers HTML/PHP créés, un sitemap qui grossit, `site:votre-domaine.fr` qui explose : le CPU écrit sur disque et répond aux robots. Les process sont souvent `php` sur un script à la racine ou un cron. Traitez comme un spam SEO, pas comme un thème lourd.

Coupez le script, le cron, le dossier aléatoire. Puis seulement, désindexez. Tant que le générateur tourne, chaque hit Googlebot recréé de la charge.

LiteSpeed / cache objet peut resservir du HTML sale et, parfois, relancer une tâche. Videz après avoir coupé, pas avant — sinon vous cachez le symptôme le temps d'un TTL.

Cron, voisins, et PHP-FPM

Listez les cron du compte, pas ceux du CMS seulement. Un voisin sur le même mutualisé peut saturer l'instance : l'hébergeur le voit à l'uid. Si ce n'est pas vous, le ticket le dit ; vous n'avez pas à réinstaller WordPress.

PHP-FPM : un pool mal borné transforme un petit bot en avalanche. Après incident, des `pm.max_children` raisonnables évitent de tuer MySQL. Ce n'est pas la cause pirate ; c'est l'amplificateur.

Un objet Redis / Memcached qui « réchauffe » une page malware à chaque hit : le CPU reste haut après suppression fichiers. Videz le cache applicatif. Voir object cache.

Gestes utiles en attendant le diagnostic

Mot de passe panel. Copie du site ailleurs. Ticket factuel avec l'heure du pic. Ne restaurez pas « la dernière sauvegarde » : elle contient souvent le cron. Ne payez pas un upgrade immédiat : vous offrez plus de CPU au mineur.

Si le site sert du phishing, coupez l'URL ou le vhost. Le CPU n'est plus le sujet. Sinon, gardez le site joignable : une 503 prolongée coûte le SEO, et Googlebot qui réessaie ajoute de la charge au retour.

Un mode maintenance léger (une page statique) réduit PHP. Utile le temps de tuer le process. Pas une semaine.

• Panel + copie + ticket.
• Noter le process avant kill.
• Maintenance courte si PHP s'emballe.
• Pas d'upgrade « pour absorber ».

Ce qui empire : cache miracle et migration sale

Installer cinq plugins de perf pendant l'attaque ajoute du PHP. Migrer chez un « plus costaud » avec le mineur dans le zip fait suspendre le nouveau compte. Réinstaller WordPress sans lire crontab laisse le binaire dans `/tmp`.

Un CDN ne réduit pas un mineur serveur. Il peut réduire un bot HTTP. Choisissez l'outil selon la cause, pas selon la pub du plugin.

La facture qui explose se conteste après nettoyage, avec les dates de pic. Contester pendant que le process tourne donne un refus.

Après le calme : facture et prévention

CPU normal 24 h, cron relu, pas de binaire dans `tmp`, `site:` stable. Puis vous parlez facture et, si besoin, réexamen Google — seulement s'il y a eu page dangereuse, pas pour du CPU. Safe Browsing 24 à 72 h est une autre file.

Prévention minimale : cron relu après chaque incident, pas de PHP dans uploads, moins d'admins, alertes ressources hébergeur activées. Une alerte à 70 % CPU le mardi évite l'e-mail de suspension le jeudi.

Vous pouvez déclarer le site si le process et le cron se recréent. Tuez, notez, changez le panel : ces trois-là tiennent avant toute délégation.