Comment de vieilles sauvegardes ont failli coûter à une agence sa récupération

La plupart des propriétaires de sites WordPress ont des sauvegardes. Presque aucun n’a de sauvegardes qu’il a réellement testées. La différence devient brutalement visible au pire moment possible : le jour où il en a besoin. Cet article décrit un cas réel issu d’un incident récent dans une agence de Sydney, où l’histoire des sauvegardes a failli transformer une récupération difficile en quasi-catastrophe, et ce que nous avons changé pour que cela ne se reproduise pas.

L’incident

L’agence gère un portefeuille de sites de petites entreprises clientes sur un seul hébergement mutualisé. L’un d’eux, le site de l’agence elle-même, a été compromis. Une attaque de dissimulation (cloaking) SEO avait discrètement déposé des fichiers malveillants à la racine du document, imitant les vrais noms de pages WordPress avec du contenu contrôlé par l’attaquant. Le nettoyage en soi a été simple une fois le point d’entrée identifié. Le plus difficile a été de décider jusqu’où revenir en arrière.

L’analyse forensique suggérait que l’attaquant était présent sur le site depuis au moins quelques semaines avant la découverte. Par prudence, le plan de récupération prévoyait une restauration à partir d’une sauvegarde antérieure à la date d’intrusion suspectée. Plus la base de référence antérieure à l’incident était propre, moins il y avait de risque qu’une porte dérobée subtile survive au nettoyage.

La première surprise

L’extension de sauvegarde avait été installée et configurée au lancement du site, deux ans plus tôt. Le plan prévoyait des sauvegardes quotidiennes de la base de données et des sauvegardes complètes hebdomadaires, toutes deux envoyées vers un compte de stockage cloud externe. Lorsque le propriétaire de l’agence a voulu récupérer une sauvegarde datant de six semaines avant l’incident, la réponse a été gênante : la sauvegarde la plus récente dans le stockage cloud datait de douze mois.

L’extension de sauvegarde échouait silencieusement depuis au moins un an. L’agence n’en avait aucune idée. Les notifications d’échec étaient envoyées à une adresse e-mail qui n’était plus surveillée. Personne n’avait pensé à vérifier le stockage de destination pour confirmer que les fichiers arrivaient réellement. Le système était cassé en silence depuis bien plus longtemps que l’incident de sécurité lui-même.

La deuxième surprise

L’agence s’est tournée vers l’hébergeur comme solution de repli. De nombreux hébergeurs infogérés conservent leurs propres sauvegardes, indépendantes de toute extension. Dans ce cas, la rétention des sauvegardes de l’hébergeur était de 30 jours. On soupçonnait que la compromission avait commencé environ 45 jours avant la découverte. Les sauvegardes de l’hébergeur se situaient à l’intérieur de la fenêtre de compromission, et non avant.

Toute sauvegarde que l’hébergeur pouvait fournir avait de fortes chances de contenir les fichiers de l’attaquant. Restaurer à partir de celles-ci n’aurait fait que remettre le compteur à zéro. Il n’existait aucun point propre antérieur à l’incident vers lequel restaurer.

La voie de récupération qui a fonctionné

Sans aucune sauvegarde propre, la récupération a dû se faire fichier par fichier. L’instantané forensique du site actuel a été comparé à un téléchargement neuf du cœur de WordPress, les fichiers du thème ont été vérifiés par rapport au contrôle de version là où il existait, les extensions ont été réinstallées depuis leurs sources officielles plutôt que réutilisées depuis le code compromis, et la base de données a été nettoyée des motifs malveillants connus sans être restaurée en arrière.

Cela a pris plusieurs fois plus de temps qu’une simple restauration. Chaque étape a dû être vérifiée. Le coût total a été substantiel, et plusieurs améliorations du site ont été perdues parce que le code de thème vérifiable le plus récent provenait d’un export vieux de plusieurs mois plutôt que de l’état en ligne. Le nettoyage a fonctionné, mais le coût a été nettement plus élevé qu’il n’aurait dû l’être.

Le nouveau dispositif de sauvegarde

Après l’incident, l’agence est passée à un dispositif de sauvegarde que nous utilisons sur les sites WordPress que nous gérons. Les caractéristiques comptent, il vaut donc la peine d’être précis.

Des sauvegardes incrémentielles quotidiennes des fichiers et de la base de données. Des sauvegardes complètes hebdomadaires. Toutes les sauvegardes stockées hors site, dans un compte de stockage inaccessible depuis le site WordPress lui-même, afin qu’une compromission ne puisse pas effacer les sauvegardes en même temps que le site en ligne.

La rétention est réglée pour que les sauvegardes restent disponibles pendant au moins 90 jours. Cela offre une fenêtre propre antérieure à l’incident, même pour les compromissions à combustion lente.

Les notifications d’alerte en cas d’échec des sauvegardes vont vers une boîte de réception professionnelle surveillée, et non vers un e-mail personnel. Deux personnes reçoivent les alertes, afin que les congés d’une seule personne ne puissent masquer un échec.

Un test de restauration trimestriel est exécuté sur un environnement de staging. La sauvegarde est téléchargée, restaurée et vérifiée par rapport au site en ligne. Si quelque chose est cassé, c’est corrigé avant le trimestre suivant.

Ce que vous pouvez faire aujourd’hui

Si ce cas vous semble inconfortablement familier, voici une courte liste d’étapes à parcourir cette semaine. Chacune ne prend que quelques minutes.

Connectez-vous à la destination vers laquelle vont vos sauvegardes, quelle qu’elle soit. Confirmez que le fichier le plus récent date d’aujourd’hui ou d’hier. Confirmez que les fichiers arrivent de manière régulière depuis 90 jours. Ouvrez l’adresse e-mail censée recevoir les notifications d’échec de sauvegarde et confirmez qu’elle est toujours surveillée.

Choisissez la sauvegarde la plus récente. Téléchargez-la. Essayez de la restaurer sur un site de staging ou un environnement local. Assurez-vous qu’elle fonctionne réellement comme une sauvegarde, et pas seulement comme un fichier.

Vérifiez la rétention des sauvegardes de votre hébergeur. La fenêtre de rétention est-elle assez longue pour couvrir une compromission lente ? Si non, complétez-la par une solution externe à rétention plus longue.

Le principe

Une sauvegarde n’est réelle qu’une fois que vous l’avez restaurée. Jusque-là, c’est une supposition. Le coût du test est faible. Le coût de la découverte à la dure est assez élevé pour menacer la récupération elle-même. Traitez la vérification des sauvegardes comme une partie de votre routine, pas comme une chose que vous feriez un jour.

Besoin d’un coup de main ?

Si votre dispositif de sauvegarde WordPress présente des lacunes, Defyn peut l’auditer, mettre en place des sauvegardes externalisées fiables avec une rétention appropriée, exécuter un test de restauration pour vérifier qu’il fonctionne, et s’assurer que les alertes parviennent à des personnes qui les verront. Contactez-nous et nous vous fournirons un dispositif de sauvegarde sur lequel vous pourrez réellement compter.