La sauvegarde oubliée sur votre serveur, que n'importe qui peut télécharger
Des fichiers comme backup.zip, des dumps .sql ou des dossiers old/ dans le répertoire du site sont des proies faciles pour les robots. Comment vérifier, quoi demander et où ranger les sauvegardes.
Avoir une sauvegarde, c'est bien. Le problème commence quand elle est au mauvais endroit.
Le scénario classique ressemble à ceci. Un développeur migre votre site chez un nouvel hébergeur, ou fait des modifications importantes. Par précaution, il compresse tout le site dans backup.zip, exporte la base de données dans database.sql et laisse les deux fichiers dans le dossier du site pour les avoir sous la main. Le travail est terminé, le site fonctionne, les fichiers restent. Un an plus tard, plus personne ne se souvient qu'ils existent.
Or le dossier du site est public. Tout ce qu'il contient peut être téléchargé avec un navigateur ordinaire par quiconque connaît l'adresse, ou la devine.
Ce qu'on retrouve le plus souvent
Les découvertes les plus fréquentes ressemblent à ceci :
- des archives du site entier, comme
backup.zip,site.tar.gzouwww-2023.zip, - des exports de base de données :
dump.sql,database.sql,db_backup.sql, - des copies du fichier de configuration :
wp-config.php.bak,wp-config.php.old,config.php~, - d'anciennes versions complètes du site dans des dossiers nommés
old/,test/oubackup/, - des archives et des fichiers d'installation laissés par les extensions de migration de site.
Le plus dangereux est souvent le plus petit : une copie du fichier de configuration. Le serveur exécute le wp-config.php d'origine comme un programme, si bien que personne de l'extérieur ne peut lire son contenu. Mais pour le serveur, wp-config.php.bak n'est qu'un fichier texte. Il le livre en entier, avec le nom de la base de données, l'identifiant et le mot de passe.
Un export de base de données, lui, contient tout ce que votre boutique ou vos formulaires ont collecté : noms, adresses, numéros de téléphone, historique des commandes, comptes utilisateurs. Et un dossier old/ contient souvent une copie complète et fonctionnelle du site d'il y a plusieurs années, avec des extensions que plus personne ne met à jour. Votre site principal peut être bien entretenu et se faire pirater quand même par la version oubliée posée à côté.
Pourquoi les robots les cherchent
Personne n'a besoin de savoir que vous, en particulier, avez une sauvegarde sur votre serveur. Des scanners automatiques parcourent Internet et, sur chaque site qu'ils atteignent, essaient une liste de noms courants : /backup.zip, /site.zip, /dump.sql, /wp-config.php.bak, /.env. C'est rapide et ne coûte rien, alors ils le font en permanence.
Si vous demandez à votre hébergeur les journaux d'accès du site, vous verrez presque certainement ces tentatives. Sur un site bien rangé, chacune se termine par une erreur 404 : le fichier n'existe pas. Sur un site avec une sauvegarde oubliée, l'une d'elles se termine par un code 200 et un téléchargement.
La deuxième voie, c'est Google. Si l'affichage du contenu des répertoires est activé, l'adresse votredomaine.fr/backup/ affiche une simple liste de fichiers intitulée « Index of /backup ». Ce genre de page finit parfois dans les résultats de recherche, et n'importe qui peut alors la trouver sans rien deviner.
Ce que vous pouvez vérifier vous-même, sans accès au serveur
Quelques vérifications prennent cinq minutes :
- Cherchez sur Google
site:votredomaine.fr intitle:"index of". Aucun résultat, c'est bon signe. - Tapez quelques adresses dans votre navigateur, par exemple
votredomaine.fr/backup.zip,votredomaine.fr/database.sqlouvotredomaine.fr/old/. Si un téléchargement démarre ou si vous voyez une liste de fichiers au lieu d'une page d'erreur, vous avez votre réponse. - Passez le site dans un scanner comme ShieldWave, qui essaie depuis l'extérieur les mêmes noms courants que les robots. La différence : les résultats arrivent chez vous.
Deviner a cependant ses limites. Il existe des centaines de noms possibles, et un développeur a pu appeler le fichier n'importe comment. Seule une personne qui regarde les fichiers sur le serveur peut donner une réponse fiable.
Comment demander une vérification à votre développeur ou à votre hébergeur
Vous n'avez pas besoin des détails techniques. Un court message qui demande quatre choses suffit :
- vérifier que le dossier public du site (souvent appelé
public_html,wwwouhttpdocs) ne contient aucun fichier.zip,.tar.gz,.sql,.bakou.old, ni de dossier commeold,backupoutest, - déplacer hors du dossier public, ou supprimer, tout ce qui est trouvé,
- désactiver l'affichage du contenu des répertoires s'il est activé,
- regarder dans les journaux du serveur si quelqu'un a téléchargé ces fichiers.
Ce dernier point compte. Si quelqu'un a téléchargé une copie du fichier de configuration, la supprimer ne suffit pas. Il faut changer le mot de passe de la base de données, parce que quelqu'un l'a peut-être déjà noté.
Si le fichier téléchargé contenait des données de clients, il s'agit d'une violation de données personnelles. Selon l'article 33 du RGPD, vous avez alors 72 heures à partir du moment où vous en avez connaissance pour la notifier à l'autorité de protection des données, sauf si la violation n'est pas susceptible d'engendrer un risque pour les personnes concernées. Même sans notification, vous devez la consigner dans un registre.
Où doivent se trouver les sauvegardes
Une bonne sauvegarde remplit quelques conditions simples :
- elle se trouve hors du dossier public du site, et idéalement sur un autre serveur ou dans un service de stockage séparé,
- elle se fait toute seule, selon un calendrier, et pas quand quelqu'un y pense,
- plusieurs versions plus anciennes sont conservées, car une infection n'est souvent découverte que des semaines plus tard,
- quelqu'un a déjà essayé au moins une fois de restaurer le site à partir d'elle.
Méfiez-vous des extensions de sauvegarde pour WordPress. Certaines enregistrent par défaut leurs archives dans le dossier du site, par exemple quelque part dans wp-content, et les protègent avec un fichier .htaccess. Cette protection fonctionne sur les serveurs Apache et LiteSpeed, mais un serveur nginx ne lit pas du tout ce fichier. Le plus simple est de régler l'extension pour qu'elle envoie les sauvegardes ailleurs et ne garde pas de copie locale.
Les administrateurs système parlent de la règle 3-2-1 : trois copies des données, sur deux types de support différents, dont une conservée hors site. Le site d'une petite entreprise peut se contenter d'une version allégée : une sauvegarde faite par l'hébergeur plus une copie envoyée automatiquement ailleurs. Mais jamais dans un dossier que n'importe qui peut ouvrir dans un navigateur.
Si vous ne posez qu'une question à la personne qui s'occupe de votre site, posez celle-ci : où sont nos sauvegardes, et qui d'autre que nous peut les télécharger ?