Restauration après piratage
Le retour à un état sain après une intrusion, qui ne se confond pas avec la remise en ligne d'une sauvegarde.
Définition
La restauration après piratage est le retour à un état sain après une intrusion. Elle ne se confond pas avec la remise en ligne d’une sauvegarde : le choix se fait sur la date de compromission, pas sur celle de la dernière copie.
Faut-il restaurer ou nettoyer ?
Les deux réponses sont valables, et c’est la date d’intrusion qui départage.
La restauration remplace le site par une copie antérieure. Le nettoyage retire l’infection du site en place. La restauration est plus rapide et plus sûre quand une copie saine existe, parce qu’elle ne laisse aucune chance à un fichier oublié. Elle devient inapplicable dès que l’intrusion est plus ancienne que la plus vieille sauvegarde conservée, ce qui arrive souvent : une infection discrète dure des semaines, une rotation de sauvegardes en couvre parfois sept jours.
| Situation | Ce qui s’applique |
|---|---|
| Copie saine antérieure à l’intrusion, contenu peu changé depuis | restauration complète |
| Copie saine antérieure, mais commandes ou articles publiés depuis | restauration des fichiers, base conservée et examinée |
| Toutes les sauvegardes sont postérieures à l’intrusion | nettoyage du site en place |
| Date d’intrusion inconnue | rien, tant qu’elle n’est pas établie |
Dans quel ordre restaurer ?
Quatre opérations, et la remise en ligne n’est pas la dernière.
Dater l’intrusion
Les journaux du serveur et les dates de modification des fichiers donnent une fenêtre. Sans elle, aucune sauvegarde ne peut être déclarée saine.
Choisir la copie
La plus récente qui précède cette fenêtre. Ce qui a été publié entre-temps se réintègre ensuite, à la main et après examen.
Corriger la faille avant de republier
La copie restaurée contient la version vulnérable du jour de l’intrusion. Mises à jour et accès se traitent hors ligne, avant l’ouverture au public. C’est là que se joue une restauration d’un site WordPress piraté qui tient.
Vérifier ce qui a survécu
Comptes administrateurs, tâches planifiées et redirections se contrôlent après restauration : ils vivent en base, et la base n’est pas toujours celle qu’on a remplacée.
Le raccourci à éviter. Restaurer la sauvegarde de la veille parce que le site est tombé hier. La panne est le symptôme, pas la date d’entrée. Une porte dérobée posée trois semaines plus tôt figure dans cette copie, et le site est repris quelques jours après la remise en ligne, par le même chemin.
Pourquoi la base de données décide souvent
Parce que restaurer les fichiers ne restaure pas ce qui vit ailleurs.
Beaucoup de sauvegardes automatiques traitent les fichiers et la base séparément, et beaucoup de restaurations ne portent que sur les fichiers, pour ne pas perdre les commandes ou les commentaires récents. C’est un choix défendable, mais il laisse en place tout ce qu’une intrusion inscrit en base : un compte administrateur supplémentaire, une tâche planifiée qui réinstalle le code, une option chargée à chaque page, des liens insérés dans les articles.
Une restauration de fichiers seuls n’est donc pas une restauration : c’est un nettoyage partiel, qui doit être complété par l’examen de la base.
Questions fréquentes
Combien de sauvegardes faut-il conserver ?
Assez pour couvrir le délai entre une intrusion et sa découverte, qui se compte en semaines plus souvent qu’en jours. Une rotation de sept jours protège des pannes, pas des piratages.
La sauvegarde de l’hébergeur suffit-elle ?
Elle dépanne, mais sa profondeur et sa fréquence sont fixées par l’hébergeur, et elle vit sur le même compte que le site. Une sauvegarde qui n’a jamais été restaurée pour de bon reste une hypothèse.
Faut-il changer les mots de passe après une restauration ?
Oui, tous, y compris ceux de la base et du compte d’hébergement, ainsi que les clés de sécurité du fichier de configuration. La copie restaurée contient les identifiants du jour de l’intrusion.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.