Installer Wordfence ou Sucuri pendant l'attaque : utile ou non
Un plugin de sécurité signale parfois l’infection, rarement il la retire, jamais il ne referme une faille tierce. Wordfence ou Sucuri pendant l’attaque ajoutent du bruit — scans, mails, parfois une 500 après « Repair ». On les pose à la fin, comme filet, pas comme nettoyage.
Un plugin de sécurité signale parfois l'infection, rarement il la retire, jamais il ne referme une faille tierce. On l'ajoute à la fin, comme filet, pas comme nettoyage.
Ce qu’on vous vend dans l’urgence
Installer Wordfence pendant un piratage, ou Sucuri, iThemes, WordPress « malware scanner » du premier résultat : le narratif est « le plugin va trouver et enlever le virus ». C’est le narratif de l’antivirus grand public. Un CMS n’est pas un disque Windows. Le malware est souvent une ligne dans un fichier légitime, ou une option SQL, ou un `.htaccess`. Le plugin cherche des signatures. Votre porte n’en a pas forcément.
Les landing pages disent « removes malware ». Entendez : retire ce qu’elles reconnaissent, dans les fichiers qu’elles lisent, si les droits PHP le permettent. Elles ne disent pas : referme Contact Form 7 obsolète, tue le compte `wpsupport`, lit le voisin de compte, invalide les Application Passwords.
Donc : utile comme détecteur de familles connues, parfois. Suffisant comme traitement, non. L’installer en premier geste, c’est ajouter un gros plugin sur un site instable, parfois déjà à genoux (CPU, 500). Mauvais moment.
- Pendant : plutôt logs, dates, diff, copie.
- Scan : pour trier des chemins, pas pour clore.
- Après : filet + alertes de nouveaux fichiers.
Ce qu’un scan voit réellement
Signatures (base64 trop gros, noms de familles, domaines de C2 connus), parfois comparaison de checksums du cœur si le plugin a la liste. Il voit un `eval` évident. Il rate un one-liner écrit pour vous, un JS de skimmer dans un option, un cloaking en `user-agent`, un cron système, un PHP hors du document root du site « principal ».
Il voit aussi des faux positifs : un thème premium minifié, une bibliothèque, votre propre snippet. D’où des listes de 80 fichiers « critiques » dont 75 sont le thème. Traiter la liste comme vérité, c’est supprimer au hasard.
Lancez un scan, si vous voulez, après la copie, pour obtenir des pistes. Ne le lancez pas comme étape 1 à la place de `site:` et de la liste des utilisateurs.
Ce qu’il ne retire pas (et ce qu’il casse)
Il ne retire pas une faille dans une extension tierce. Il ne met pas à jour pour vous de façon sûre au milieu du chaos (une maj peut fatal). Il ne voit pas le compte FTP. Il ne change pas le mot de passe panel. Il ne parle pas à l’hébergeur.
Il peut casser : « repair » d’un fichier de thème enfant, quarantine d’un must-use légitime, WAF en mode parano qui 403 wp-admin, règles qui 500 le front. On hérite alors d’un site inaccessible après nettoyage en plus de l’infection.
Les versions premium cloud scannent de l’extérieur : utiles pour voir ce qu’un visiteur voit (redirection). Encore un signal, pas un retrait du prepend.
« Réparer tout » : le bouton le plus cher
Wordfence et d’autres proposent de restaurer les fichiers cœur / d’effacer les « infectés ». Sur le cœur officiel, parfois juste. Sur tout le reste, c’est un restore aveugle. On a vu des `functions.php` d’enfant vidés, des mu-plugins légitimes tués, des permissions absurdes.
Si vous cliquez : une copie avant, un fichier à la fois, lecture du diff proposé. Jamais « tout réparer » à 1 h du matin sur un site sans backup hors serveur.
Réinstaller le cœur depuis le panel WordPress, ciblé, est souvent plus lisible que le repair du plugin. Encore une fois : après copie, et ça ne suffit pas.
Bruit : mails, CPU, faux positifs
Un scan full + les hits de l’attaquant + un mineur éventuel : le CPU explose, l’hébergeur suspend pour resource abuse. Le plugin de sécu devient le motif du ticket. Ironie fréquente.
Les mails « critical issue » toutes les cinq minutes noient le vrai chemin. Créez un filtre, ou désinstallez jusqu’à la fin, ou passez en alerte quotidienne. Pendant l’incident, votre attention est une ressource rare.
Deux plugins de sécu en parallèle : pire. Doublons, conflits, 500. Un seul, plus tard. Pas une collection.
Quand l’installer, concrètement
Après : site propre vérifié (mobile, privée, inspection), entrée traitée, secrets tournés. Alors un plugin (ou un WAF hébergeur, ou les deux) comme filet : alerte nouveau admin, nouveau fichier PHP dans uploads, brute force. C’est son métier.
Choisissez-en un, configurez les alertes vers une boîte que vous lisez, limitez le scan au quotidien pas toutes les heures. 2FA, restreindre xmlrpc, c’est souvent plus utile que le pack « firewall » par défaut qui casse les API.
Si vous l’aviez déjà : ne le réinstallez pas par-dessus une attaque en cours pour « rafraîchir ». Lisez ses journaux (parfois un premier hit utile), puis travaillez hors de lui.
Pendant l’attaque : quoi utiliser à la place
Gestionnaire de fichiers + dates. Zip officiel + diff. error.log. `site:` + Search Console. Liste utilisateurs. Cron. `.user.ini`. Copie. Panel. C’est la stack de l’heure 1. Elle est gratuite et plus précise.
Un grep (`eval`, `base64_decode`, `gzinflate`, domaines bizarres) sur le vhost, si vous l’avez. Mieux qu’un scan opaque. Vous voyez le contexte.
Les outils en ligne « scan my site » : un de plus, éventuellement, pour un signal externe. Dix outils : vous vous faites crawler comme un botnet et vous n’apprenez rien. Comment savoir suffit comme protocole.
Après : filet, pas totem
Le plugin vert n’est pas un certificat. Il n’empêche pas une faille 0-day dans un builder. Les maj, les comptes, l’isolation du compte d’hébergement, les backups hors site : le fond. Le plugin : l’alarme.
Si vous déléguez, un prestataire qui « installe Wordfence et part » vous a vendu l’alarme. Demandez le constat trouvé / retiré / corrigé. Soi-même ou déléguer.
WordPress n’est pas le seul CMS. Sur PrestaShop, le réflexe « plugin sécu » est le même piège. Même règle : fin, pas début. Page WordPress piraté pour l’ordre de fermeture des portes.