La plupart des propri\u00e9taires de sites WordPress ont des sauvegardes. Presque aucun n’a de sauvegardes qu’il a r\u00e9ellement test\u00e9es. La diff\u00e9rence devient brutalement visible au pire moment possible : le jour o\u00f9 il en a besoin. Cet article d\u00e9crit un cas r\u00e9el issu d’un incident r\u00e9cent dans une agence de Sydney, o\u00f9 l’histoire des sauvegardes a failli transformer une r\u00e9cup\u00e9ration difficile en quasi-catastrophe, et ce que nous avons chang\u00e9 pour que cela ne se reproduise pas.<\/p>\n\n\n\n
L’agence g\u00e8re un portefeuille de sites de petites entreprises clientes sur un seul h\u00e9bergement mutualis\u00e9. L’un d’eux, le site de l’agence elle-m\u00eame, a \u00e9t\u00e9 compromis. Une attaque de dissimulation (cloaking) SEO avait discr\u00e8tement d\u00e9pos\u00e9 des fichiers malveillants \u00e0 la racine du document, imitant les vrais noms de pages WordPress avec du contenu contr\u00f4l\u00e9 par l’attaquant. Le nettoyage en soi a \u00e9t\u00e9 simple une fois le point d’entr\u00e9e identifi\u00e9. Le plus difficile a \u00e9t\u00e9 de d\u00e9cider jusqu’o\u00f9 revenir en arri\u00e8re.<\/p>\n\n\n\n
L’analyse forensique sugg\u00e9rait que l’attaquant \u00e9tait pr\u00e9sent sur le site depuis au moins quelques semaines avant la d\u00e9couverte. Par prudence, le plan de r\u00e9cup\u00e9ration pr\u00e9voyait une restauration \u00e0 partir d’une sauvegarde ant\u00e9rieure \u00e0 la date d’intrusion suspect\u00e9e. Plus la base de r\u00e9f\u00e9rence ant\u00e9rieure \u00e0 l’incident \u00e9tait propre, moins il y avait de risque qu’une porte d\u00e9rob\u00e9e subtile survive au nettoyage.<\/p>\n\n\n\n
L’extension de sauvegarde avait \u00e9t\u00e9 install\u00e9e et configur\u00e9e au lancement du site, deux ans plus t\u00f4t. Le plan pr\u00e9voyait des sauvegardes quotidiennes de la base de donn\u00e9es et des sauvegardes compl\u00e8tes hebdomadaires, toutes deux envoy\u00e9es vers un compte de stockage cloud externe. Lorsque le propri\u00e9taire de l’agence a voulu r\u00e9cup\u00e9rer une sauvegarde datant de six semaines avant l’incident, la r\u00e9ponse a \u00e9t\u00e9 g\u00eanante : la sauvegarde la plus r\u00e9cente dans le stockage cloud datait de douze mois.<\/p>\n\n\n\n
L’extension de sauvegarde \u00e9chouait silencieusement depuis au moins un an. L’agence n’en avait aucune id\u00e9e. Les notifications d’\u00e9chec \u00e9taient envoy\u00e9es \u00e0 une adresse e-mail qui n’\u00e9tait plus surveill\u00e9e. Personne n’avait pens\u00e9 \u00e0 v\u00e9rifier le stockage de destination pour confirmer que les fichiers arrivaient r\u00e9ellement. Le syst\u00e8me \u00e9tait cass\u00e9 en silence depuis bien plus longtemps que l’incident de s\u00e9curit\u00e9 lui-m\u00eame.<\/p>\n\n\n\n
L’agence s’est tourn\u00e9e vers l’h\u00e9bergeur comme solution de repli. De nombreux h\u00e9bergeurs infog\u00e9r\u00e9s conservent leurs propres sauvegardes, ind\u00e9pendantes de toute extension. Dans ce cas, la r\u00e9tention des sauvegardes de l’h\u00e9bergeur \u00e9tait de 30 jours. On soup\u00e7onnait que la compromission avait commenc\u00e9 environ 45 jours avant la d\u00e9couverte. Les sauvegardes de l’h\u00e9bergeur se situaient \u00e0 l’int\u00e9rieur de la fen\u00eatre de compromission, et non avant.<\/p>\n\n\n\n
Toute sauvegarde que l’h\u00e9bergeur pouvait fournir avait de fortes chances de contenir les fichiers de l’attaquant. Restaurer \u00e0 partir de celles-ci n’aurait fait que remettre le compteur \u00e0 z\u00e9ro. Il n’existait aucun point propre ant\u00e9rieur \u00e0 l’incident vers lequel restaurer.<\/p>\n\n\n\n
Sans aucune sauvegarde propre, la r\u00e9cup\u00e9ration a d\u00fb se faire fichier par fichier. L’instantan\u00e9 forensique du site actuel a \u00e9t\u00e9 compar\u00e9 \u00e0 un t\u00e9l\u00e9chargement neuf du c\u0153ur de WordPress, les fichiers du th\u00e8me ont \u00e9t\u00e9 v\u00e9rifi\u00e9s par rapport au contr\u00f4le de version l\u00e0 o\u00f9 il existait, les extensions ont \u00e9t\u00e9 r\u00e9install\u00e9es depuis leurs sources officielles plut\u00f4t que r\u00e9utilis\u00e9es depuis le code compromis, et la base de donn\u00e9es a \u00e9t\u00e9 nettoy\u00e9e des motifs malveillants connus sans \u00eatre restaur\u00e9e en arri\u00e8re.<\/p>\n\n\n\n
Cela a pris plusieurs fois plus de temps qu’une simple restauration. Chaque \u00e9tape a d\u00fb \u00eatre v\u00e9rifi\u00e9e. Le co\u00fbt total a \u00e9t\u00e9 substantiel, et plusieurs am\u00e9liorations du site ont \u00e9t\u00e9 perdues parce que le code de th\u00e8me v\u00e9rifiable le plus r\u00e9cent provenait d’un export vieux de plusieurs mois plut\u00f4t que de l’\u00e9tat en ligne. Le nettoyage a fonctionn\u00e9, mais le co\u00fbt a \u00e9t\u00e9 nettement plus \u00e9lev\u00e9 qu’il n’aurait d\u00fb l’\u00eatre.<\/p>\n\n\n\n
Apr\u00e8s l’incident, l’agence est pass\u00e9e \u00e0 un dispositif de sauvegarde que nous utilisons sur les sites WordPress que nous g\u00e9rons. Les caract\u00e9ristiques comptent, il vaut donc la peine d’\u00eatre pr\u00e9cis.<\/p>\n\n\n\n
Des sauvegardes incr\u00e9mentielles quotidiennes des fichiers et de la base de donn\u00e9es. Des sauvegardes compl\u00e8tes hebdomadaires. Toutes les sauvegardes stock\u00e9es hors site, dans un compte de stockage inaccessible depuis le site WordPress lui-m\u00eame, afin qu’une compromission ne puisse pas effacer les sauvegardes en m\u00eame temps que le site en ligne.<\/p>\n\n\n\n
La r\u00e9tention est r\u00e9gl\u00e9e pour que les sauvegardes restent disponibles pendant au moins 90 jours. Cela offre une fen\u00eatre propre ant\u00e9rieure \u00e0 l’incident, m\u00eame pour les compromissions \u00e0 combustion lente.<\/p>\n\n\n\n
Les notifications d’alerte en cas d’\u00e9chec des sauvegardes vont vers une bo\u00eete de r\u00e9ception professionnelle surveill\u00e9e, et non vers un e-mail personnel. Deux personnes re\u00e7oivent les alertes, afin que les cong\u00e9s d’une seule personne ne puissent masquer un \u00e9chec.<\/p>\n\n\n\n
Un test de restauration trimestriel est ex\u00e9cut\u00e9 sur un environnement de staging. La sauvegarde est t\u00e9l\u00e9charg\u00e9e, restaur\u00e9e et v\u00e9rifi\u00e9e par rapport au site en ligne. Si quelque chose est cass\u00e9, c’est corrig\u00e9 avant le trimestre suivant.<\/p>\n\n\n\n
Si ce cas vous semble inconfortablement familier, voici une courte liste d’\u00e9tapes \u00e0 parcourir cette semaine. Chacune ne prend que quelques minutes.<\/p>\n\n\n\n
Connectez-vous \u00e0 la destination vers laquelle vont vos sauvegardes, quelle qu’elle soit. Confirmez que le fichier le plus r\u00e9cent date d’aujourd’hui ou d’hier. Confirmez que les fichiers arrivent de mani\u00e8re r\u00e9guli\u00e8re depuis 90 jours. Ouvrez l’adresse e-mail cens\u00e9e recevoir les notifications d’\u00e9chec de sauvegarde et confirmez qu’elle est toujours surveill\u00e9e.<\/p>\n\n\n\n
Choisissez la sauvegarde la plus r\u00e9cente. T\u00e9l\u00e9chargez-la. Essayez de la restaurer sur un site de staging ou un environnement local. Assurez-vous qu’elle fonctionne r\u00e9ellement comme une sauvegarde, et pas seulement comme un fichier.<\/p>\n\n\n\n
V\u00e9rifiez la r\u00e9tention des sauvegardes de votre h\u00e9bergeur. La fen\u00eatre de r\u00e9tention est-elle assez longue pour couvrir une compromission lente ? Si non, compl\u00e9tez-la par une solution externe \u00e0 r\u00e9tention plus longue.<\/p>\n\n\n\n
Une sauvegarde n’est r\u00e9elle qu’une fois que vous l’avez restaur\u00e9e. Jusque-l\u00e0, c’est une supposition. Le co\u00fbt du test est faible. Le co\u00fbt de la d\u00e9couverte \u00e0 la dure est assez \u00e9lev\u00e9 pour menacer la r\u00e9cup\u00e9ration elle-m\u00eame. Traitez la v\u00e9rification des sauvegardes comme une partie de votre routine, pas comme une chose que vous feriez un jour.<\/p>\n\n\n\n