C’est bien connu: Bien mal acquis …blabla … Il m’est arrivé une mésaventure très récemment qui m’a bien ennuyée.
J’ai fait très récemment l’expérience de l’installation d’un thème vérolé sur mon blog. Dans ce qui suit, je vous expose mon erreur ainsi que les différentes mesures prises, non seulement pour les corriger mais également pour me prémunir d’un nouvel incident.
L’erreur conduisant au problème
Ainsi donc, je récupère sur un site de torrents bien connu le thème Divi. Un thème WordPress très puissant qui me semble pouvoir faire tout ce que je désire pour mon blog et plus encore. Divi est un thème payant (89$ par an). Le récupérer pour pas un rond est effectivement une aubaine semble-t-il. J’installe le thème par la procédure classique sur le blog que vous lisez en ce moment (upload du .zip), Divi apparaît bien dans la liste des thèmes. Je demande à prévisualiser avant d’activer le thème de façon à me rendre compte du rendu par défaut du thème “out of the box”… Et là, patatras … Page blanche, le site ne se charge plus … pas de message d’erreur, juste un blocage infini du chargement… Je flaire aussitôt une “arnaque”, et je n’ai pas tort.
La seule solution que j’ai est de me connecter sur l’interface de mon hébergeur web, d’accéder par ftp à mon arborescence et de supprimer le répertoire du thème Divi. J’essaie également une restauration de ma base de données WordPress à l’aide des snapshots quotidiens réalisés automatiquement par l’hébergeur: Cela ne fonctionne pas, la restauration se bloque et met la base dans un statut foireux. Je constate que mon site est de nouveau accessible mais complètement vierge: Tout a disparu et l’installation de WordPress m’est proposée, Snif.
La résolution
En essayant de me connecter à ma base de données avec PhpMyAdminn je constate que l’accès m’est refusé: Le thème vérolé a modifié le mot de passe d’accès à la base. Heureusement, quelqu’un qui connait bien WordPress m’indique que ce mot de passe en clair est dans le fichier wp-config du site. je me connecte donc avec ce nouveau mot de passe à ma base de données vierge et j’essaie de modifier le, mot de passe afin d’éviter une nouvelle intrusion. Peine perdue, la base étant en “Invalid status: restoring”, le changement de mot de passe n’est pas accepté.
Je décide donc quand même de faire repartir le blog (en créant quand même un ticket auprès de mon fournisseur pour remédier au problème de changement de mot de passe). J’exporte en local le snapshot de sauvegarde qui m’intéresse (drôlement confortable d’avoir une Save journalière), je supprime toutes les tables de ma base de données et je ré-importe: Tout fonctionne, je récupère tout mon site en quelques secondes.
Mesures prises
- C’est la dernière fois que j’installe un truc piraté sur un blog de production…et même sûrement sur n’importe quoi d’ailleurs. En effet, ce n’est pas parce que je vais tester un truc vérolé pendant 15 jours avec un comportement exemplaire qu’il ne va pas déclencher un cataclysme au bout d’un temps défini. Si, par exemple, mon blog avait été effacé 35 jours après l’installation du thème vérolé, toutes les sauvegardes journalières auraient été corrompues (il y a un mois de Save quotidiennes) et j’aurais été bien plus embêté !
- Création d’un Blog de test sur mon Synology de façon à tester avant de mettre en production. Je pourrais le faire en multisite chez mon hébergeur mais cela m’obligerait à partager ma base de données entre la production et le test. Je préfère deux bases séparées. De plus, sur mon Syno, c’est gratuit. je me demande même si je ne vais pas en faire une plateforme de secours avec recopie de la production tous les jours.
- Installation du plugin WordFence permettant, dans sa version gratuite, le Scan de détection de malwares dans l’installation.
- Installation d’un accès “authentification multifacteurs” (2FA) pour accéder à l’interface d’administration du blog (wp-admin) et également pour accéder à l’interface de mon compte chez l’hébergeur
