Site devenu très lent sans trafic : minage ou attaque en cours

Lent soudainement, analytics plats : le signal

Un site très lent soudainement, sans campagne, sans soldes, sans botnet visible dans Matomo / Analytics, ce n’est pas un thème « trop lourd » apparu dans la nuit. Le thème était le même hier. Ce qui a changé, c’est un process qui mange le CPU ou les I/O : mineur (cryptomining), générateur de pages spam, spam mail, ou une injection qui refetch un kit à chaque hit.

Distinguez lenteur front (TTFB à 8 s pour tout le monde) et lenteur serveur (panel qui rame, SSH qui traîne, voisins qui se plaignent). La seconde est le motif `resource abuse`. La première peut être un CDN, une base, un DNS. Mesurez : page d’accueil vs un `hello.php` minimal déposé à la racine. Si hello est déjà lent, ce n’est pas WooCommerce.

Regardez l’heure. Un CPU à 100 % entre 2 h et 5 h, calme à 10 h : cron. Un CPU collé H24 : process persistant ou prepend. Notez-le pour l’hébergeur. Ça change la première commande qu’ils lanceront (`ps`, `crontab`, Imunify).

• Analytics stables + CPU haut = suspicion process.
• Test d’un PHP minimal vs le CMS.
• Fenêtre horaire (nuit vs continu).
• Ticket avant que le compte bascule en suspendu.

Ce que l’hébergeur voit (et va couper)

Les mutualisés mesurent CPU, RAM, processus simultanés, parfois les hits vers des domaines de mining pools. Au-delà du quota, email puis suspension. Le délai entre les deux peut être de quelques heures. D’où le ticket factuel immédiat : « CPU anormal sans trafic, intervention, merci de ne pas wipe, besoin de `ps` / cron / logs ». Voir prévenir l’hébergeur.

Ils voient aussi le voisin. Votre site propre peut être lent parce qu’un addon domain du même compte mine. Inspectez tout le home, pas seulement `www/monsite`. C’est le cas plusieurs sites, même compte.

Si le mail d’abus dit déjà `resource abuse`, ne répondez pas « on a mis WP Super Cache ». Répondez avec le cron retiré et le chemin. Sinon la remise en ligne n’arrive pas.

Mineur, générateur, ou simple boucle

Mineur : binaire ou JS/WASM, connexion sortante vers un pool, CPU saturé même sans hit web. Parfois un `cron.php` anodin. Parfois un process `xmrig` visible en SSH. Sur mutualisé sans SSH, vous ne verrez que le quota et un PHP qui ne se termine pas.

Générateur : chaque requête (ou le bot Google) fabrique des milliers d’URL, écrit des fichiers, gonfle l’I/O. `site:` explose. Le front peut être « normal » chez vous. CPU en dents de scie à chaque crawl. C’est une attaque SEO, pas un mineur, le traitement (désindexation) diffère.

Boucle honnête : objet cache cassé, cron WP toutes les minutes qui relance un import, plugin de stats synchrone, DNS externe mort avec un timeout long. Le log PHP et le slow query aident. Pas de fichier inconnu, pas de `site:` bizarre : restez sur la piste panne, mais copiez quand même.

Trouver le cron avant le fichier

Panel : Tâches cron / Cron Jobs. Une ligne `*/5 * * * * php /home/…/wp-content/uploads/cache.php` n’est pas WordPress. Une ligne `wget http://127.0.0.1/wp-cron.php` toutes les minutes empilée dix fois, si. Notez, désactivez (ne videz pas tout : les crons légitimes de backup aussi).

WordPress : événements dans la base (`wp_options` `cron`) ou un plugin comme WP Crontrol. Un hook inconnu toutes les deux minutes. wp-cli `cron event list` si vous l’avez. Un `DISABLE_WP_CRON` true avec un cron système sale : les deux existent, voir wp-cron vs cron système.

Crontab utilisateur SSH (`crontab -l`) et crons root dont vous n’êtes pas responsable : demandez à l’hébergeur. Un mineur posé via une faille CGI aime le crontab. Retirer le PHP sans le cron : il se retélécharge à H+5.

Processus PHP et `auto_prepend`

SSH : `ps aux | grep php`, temps CPU. Un script dans `tmp/` ou `uploads/` qui tourne depuis deux heures. Tuez le PID après copie du chemin. Sans SSH : l’hébergeur peut lister. Demandez-le dans le ticket, c’est plus utile que « le site est lent ».

`.user.ini` / `.htaccess` `auto_prepend_file` : chaque hit web charge le mineur ou le loader. TTFB pourri pour tout le monde, analytics « normaux » (les gens attendent puis partent). Retirer le prepend calme le front en une minute ; cherchez ensuite qui l’a écrit.

Les workers PHP-FPM qui ne meurent pas, un objet Redis qui ressert un JS pirate : plus rare, réel sur les stacks un peu plus riches. Voir object cache si vous avez Redis/Memcached.

Couper la charge sans casser le CMS

Ordre : copier, désactiver le cron pirate, isoler le PHP cité (renommer), retirer le prepend, tuer le process. Puis panel mot de passe. Ne stoppez pas tout PHP du compte (les autres sites meurent, l’hébergeur n’aime pas). Ne videz pas la crontab légitime de sauvegarde sans noter.

Mettre le site en maintenance globale ne stoppe pas un cron ni un binaire. Ça stoppe les hits web. Utile pour un générateur déclenché par les visiteurs, inutile pour un mineur autonome. Choisissez l’interrupteur qui correspond au process.

Si le quota est déjà dépassé, l’hébergeur a parfois déjà tué vos process : le site est lent ou 503, vous arrivez après. Travaillez sur l’archive et le cron, pas sur « optimiser les images ».

Après le calme : l’entrée et le voisin

Un mineur ne s’installe pas tout seul. Extension, mot de passe, voisin, panel. Si vous retirez le binaire sans ça, H+24 il est de retour et le second abus est plus sec. Checklist backdoor + tous les vhosts du compte.

Prévenez l’hébergeur du retrait (chemin, cron) pour éviter la suspension ou pour lever celle déjà là. CPU calme + fichier encore présent = leur scan peut quand même flagger.

Surveillez 48 h le CPU et `site:`. Un générateur laisse des URL ; un mineur, moins. Les deux peuvent cohabiter sur le même compte.

Vérifier que la lenteur n’était pas du cache pourri

Après une attaque, un cache page peut resservir une home lourde ou un HTML injecté. Vider le cache (plugin, Redis, Cloudflare) est un geste de fin, pas de début. Au début, le cache peut être votre seule preuve de ce que voyaient les visiteurs : copiez une page servie avant de tout flush.

Un plugin de perf mal configuré (JS combinés qui tirent un script tiers mort) donne du TTFB long sans CPU serveur. Le `hello.php` rapide tranche. Ne formatez pas le serveur pour un script `src` 404 à 20 secondes de timeout.

Si tout est calme, fichiers propres, hello rapide, CMS lent : base (slow query), objet trop gros dans `wp_options` autoload — parfois une option injectée de 4 Mo. C’est encore une piste incident, pas « il faut un VPS ». Déléguer si la lecture SQL n’est pas votre métier.