Contenez l’incident avant de nettoyer
Des redirections inattendues, des comptes administrateur inconnus ou des résultats de recherche contenant du spam peuvent signaler une compromission. Un scan propre par une extension ne l’exclut pas. De même, un symptôme isolé ne prouve pas l’existence d’une porte dérobée ou d’une technique d’attaque précise. Examinez ce que le serveur sert réellement à différentes sessions et à différents appareils.
Protégez d’abord les visiteurs. Restreignez l’accès ou désactivez temporairement les fonctions touchées si du contenu malveillant ou une interception des paiements est possible. Promettre zéro interruption n’a pas de sens lorsque maintenir en ligne un service compromis peut exposer davantage de personnes.
Préservez les preuves et délimitez l’étendue
- Conservez dans un emplacement restreint une copie datée des fichiers, de la base de données et des journaux d’accès, d’erreurs et d’authentification disponibles. Notez le fuseau horaire en vigueur et les modifications que vous effectuez.
- Inventoriez les domaines, les comptes d’hébergement, les installations WordPress, les administrateurs, les extensions et les identifiants de déploiement qui partagent un accès.
- Recherchez des modifications inattendues dans les fichiers du cœur, les extensions must-use, les téléversements, les tâches planifiées, la configuration du serveur et les options de la base de données.
- Établissez la première activité suspecte connue avant de choisir une sauvegarde. Une sauvegarde récente peut déjà contenir la compromission.
Vérifiez l’intégrité depuis un environnement de confiance
Les sommes de contrôle de WP-CLI peuvent révéler des différences par rapport aux paquets officiels. Utilisez des outils de confiance sur une copie ou dans un environnement contrôlé. Certaines commandes peuvent charger du code du site ; une installation compromise n’est pas un environnement d’exécution fiable.
wp core verify-checksums --include-root
wp plugin verify-checksums --all --strictCes vérifications ne prouvent pas que tout le site est sain. Les extensions sur mesure et commerciales n’ont pas toujours de sommes de contrôle publiques. Les charges malveillantes en base de données, la persistance au niveau du serveur et les identifiants volés nécessitent une enquête distincte. Un écart peut aussi être une modification légitime qu’il faut examiner.
Reconstruisez et fermez le point d’entrée
Remplacez les composants compromis par des versions de confiance et relisez le code sur mesure. Corrigez ou supprimez le point d’entrée vulnérable ; se contenter d’effacer un fichier injecté laisse la cause intacte. Examinez les tâches planifiées, les comptes administrateur, le contenu de la base de données, les téléversements et les sites voisins avant de reconnecter les services.
Après le confinement, renouvelez les identifiants d’hébergement, de déploiement, de base de données et d’application exposés, révoquez les sessions et régénérez les clés de salage WordPress selon les besoins. Appliquez le principe du moindre privilège et l’authentification multifacteur. Limitez le code exécutable dans les téléversements avec une configuration adaptée à votre serveur web.
Vérifiez la remise en état avant de rouvrir
- Testez les pages, les formulaires, la connexion et les parcours d’achat depuis des sessions propres.
- Recherchez des requêtes sortantes inattendues, des fichiers modifiés et des tâches planifiées qui réapparaissent.
- Confirmez que la sauvegarde peut réellement être restaurée dans un environnement isolé.
- Consultez les problèmes de sécurité dans la Search Console et ne demandez un réexamen qu’après avoir traité le problème signalé. Les délais de réexamen dépendent du fournisseur.
Continuez la surveillance après la réouverture. Tenez un bref registre de l’incident : étendue, point d’entrée probable, preuves, modifications, questions en suspens et responsables du suivi. Évitez de publier des données clients ou des journaux sensibles bruts dans un post-mortem public.
Questions fréquentes
Faut-il restaurer une sauvegarde immédiatement ?
Une sauvegarde saine connue peut faire partie de la remise en état, mais préservez d’abord les preuves, comparez sa date à la chronologie de l’incident et corrigez le point d’entrée. Prévoyez comment réintégrer les commandes ou contenus légitimes créés après cette sauvegarde.
Un scan de sécurité propre prouve-t-il que WordPress est sûr ?
Non. Un scanner peut passer à côté d’injections en base de données, d’une persistance au niveau du serveur ou d’identifiants compromis. Combinez les contrôles d’intégrité des fichiers avec l’examen des comptes, des journaux, de la base de données et des tâches planifiées. Vérifiez que le site sert le contenu attendu depuis des sessions propres et enquêtez sur le point d’entrée d’origine.
Un site piraté doit-il rester en ligne pendant le nettoyage ?
Cela dépend du préjudice qu’il peut causer. Si les visiteurs risquent de recevoir un logiciel malveillant, des redirections trompeuses ou de voir leurs paiements interceptés, restreignez le service concerné pendant l’enquête. Préserver la disponibilité n’est pas plus important que contenir une compromission active.
Que vérifier après la restauration du site ?
Vérifiez les formulaires, l’authentification et les parcours d’achat ; confirmez que le point d’entrée est corrigé ; examinez les fichiers, comptes et requêtes sortantes inattendus ; et testez la restauration d’une nouvelle sauvegarde. Si la Search Console signale un problème de sécurité, demandez le réexamen après l’avoir résolu. Continuez la surveillance, car la réouverture ne marque pas la fin de la remise en état.
Sources et lectures complémentaires
- WordPress : renforcer la sécurité de WordPress
- WP-CLI : vérification des sommes de contrôle du cœur
- Google : rapport sur les problèmes de sécurité
Pour aller plus loin
Pour une aide concrète, consultez la récupération de WordPress après un malware. Après la remise en état, vérifiez l’explorabilité et la présentation dans les moteurs de recherche.
Leave a Reply