C’est le cauchemar de tout administrateur : un matin, un e-mail de la Google Search Console vous félicite pour l’indexation de milliers de « nouveaux produits ». Problème ? Votre site ne vend rien. Vous venez de découvrir une attaque de SEO Cloaking.
Voici mon retour d’expérience sur le nettoyage complet et la sécurisation d’un cœur WordPress infecté.
L’alerte : Le symptôme de la « page fantôme »
L’attaque était invisible pour un utilisateur classique. Pourtant, en tapant site:mon-domaine.fr dans Google, des milliers de pages de spam (luxe, pharmacie) apparaissaient. Un script malveillant injecté à la racine générait ces pages uniquement pour les robots d’indexation.
Diagnostic SSH : Autopsie du malware
Grâce à l’accès VPS, j’ai évité les outils graphiques lents pour passer directement par le terminal.
Vérification d’intégrité pour révélé que les fichiers natifs de WordPress avaient été modifiés. avec la commande
En SSH : wp core verify-checksumsIdentification du suspect : Un fichier archive .zip caché servait de « matrice » pour injecter du code PHP obfusqué dans le fichier index.php.
Nettoyage chirurgical via WP-CLI et Ninja Scanner
Pour éradiquer l’infection, j’ai appliqué un protocole de « terre brûlée » en deux étapes :
Restauration du coeur de wordpress, pour restaurer des fichiers sains sans toucher au contenu.
En SSH : wp core download --forceScan Anti-Malware en profondeur : Une fois le cœur propre, j’ai utilisé le Plugin NinjaScanner. Contrairement à un scan classique, il a analysé chaque fichier de mes thèmes et plugins en les comparant à ses bases de signatures de menaces. Il a permis de débusquer des « backdoors » (portes dérobées) cachées dans des fichiers légitimes que le scan système ne pouvait pas détecter.
SEO : Le pouvoir du code HTTP 410
Nettoyer le code ne suffit pas : il faut vider l’index de Google. Plutôt que d’attendre des mois avec des erreurs 404, j’ai configuré une règle Nginx pour renvoyer un code 410 Gone sur les répertoires infectés.
Pourquoi le 410 ? Contrairement à la 404, le code 410 indique explicitement à Google que la page a disparu définitivement. Résultat : une désindexation massive et accélérée des URLs de spam.
- 404 (Not Found) : Googlebot reviendra plus tard « pour voir ».
- 410 (Gone) : Googlebot retire l’URL de son index immédiatement.
Blindage final : Le mode « Full WAF »
Pour bloquer toute récidive, j’ai déployé NinjaFirewall en mode Full WAF.
Le principe, le pare-feu se charge via le fichier .user.ini avant que WordPress ne s’exécute.
Le résultat, les tentatives d’injection de code et les accès directs aux fichiers PHP dans les dossiers médias sont bloqués net, au niveau du serveur PHP.
Conclusion : Ce qu’il faut retenir
La sécurité d’un site WordPress ne repose pas sur la chance. La combinaison d’un accès SSH, de l’outil WP-CLI pour l’intégrité du code, et d’un véritable pare-feu applicatif (WAF) est la seule stratégie viable pour reprendre le contrôle après une attaque complexe.