Fichiers .env et .git sur le serveur : ce que cherchent les scanners

Dans les journaux de mon serveur, je vois régulièrement des requêtes vers des adresses qui n’existent pas sur le site : /.env, /.git/config, /backup.zip, /phpinfo.php. Ce ne sont ni des clients ni des moteurs de recherche, mais des scanners automatiques. Ils interrogent les uns après les autres des milliers de sites d’entreprise et vérifient si quelqu’un a laissé sur le serveur un fichier contenant des mots de passe ou une copie de tout le site.

Si un tel fichier est accessible, un seul téléchargement suffit : le mot de passe de la base de données, la clé de la messagerie ou une copie des données clients se retrouve entre les mains d’un inconnu. Dans ce guide, je montre ce que cherchent les scanners, comment vérifier votre propre site en 10 minutes et comment bloquer ces fichiers.

Ce que cherchent les scanners

Les mêmes adresses reviennent dans les journaux de nombreux serveurs. Chacune correspond à un fichier qui reste parfois dans le répertoire du site après une mise en ligne ou une mise à jour.

Différence importante : le serveur exécute le fichier wp-config.php comme un programme, son contenu n’est donc pas visible de l’extérieur. Une copie de ce fichier avec une autre extension (.bak, .old, .txt) devient en revanche un simple fichier texte, que le navigateur affichera ou téléchargera tout simplement.

Comment ces fichiers arrivent sur le serveur

Personne ne les laisse exprès. Je vois le plus souvent cinq scénarios :

1. Mise en ligne par copie de tout le dossier du projet. Avec les fichiers du site, le répertoire caché .git et le fichier .env arrivent sur le serveur.
2. Une copie « temporaire » avant une mise à jour. Quelqu’un compresse le site dans backup.zip dans le répertoire du site et oublie de supprimer l’archive.
3. Les copies de l’éditeur. L’éditeur laisse à côté du fichier modifié des fichiers se terminant par ~, .bak ou .swp.
4. Une ancienne version du site dans un sous-répertoire. Après un changement de site, la version précédente atterrit dans /old/ ou /test/ et continue de fonctionner, souvent sans mises à jour.
5. Des sauvegardes dans le répertoire public. Certains outils de sauvegarde enregistrent les archives à un endroit accessible depuis un navigateur.

Comment vérifier votre site en 10 minutes

Ne vérifiez que votre propre site ou un site dont vous vous occupez avec l’autorisation de son propriétaire.

Étape 1 : saisissez les adresses dans le navigateur. Remplacez votredomaine.pl par votre adresse et ouvrez-les une par une :

https://votredomaine.pl/.env
https://votredomaine.pl/.git/config
https://votredomaine.pl/.git/HEAD
https://votredomaine.pl/backup.zip
https://votredomaine.pl/phpinfo.php

Le bon résultat est une erreur 403 ou 404. Le mauvais résultat est l’affichage du contenu du fichier ou le début d’un téléchargement.

Étape 2 : passez en revue le répertoire du site. Connectez-vous au gestionnaire de fichiers du panneau d’hébergement (ou via FTP) et ouvrez le répertoire du site, généralement public_html ou www. Cherchez les fichiers se terminant par .zip, .sql, .tar.gz, .bak, .old et les répertoires old, test, kopia.

Étape 3 : vérifiez si la liste des fichiers des répertoires s’affiche. Ouvrez l’adresse d’un répertoire contenant des images, par ex. https://votredomaine.pl/wp-content/uploads/ sous WordPress. Si vous voyez une liste de fichiers au lieu d’une page vide ou d’une erreur, le serveur montre le contenu des répertoires à chaque visiteur.

Vous trouverez un examen plus large du site, au-delà de ces fichiers, dans le guide comment vérifier gratuitement le site d’une entreprise.

Que faire si un fichier est accessible

Si l’une des adresses a affiché un contenu, agissez dans cet ordre :

1. Supprimez le fichier ou déplacez-le hors du répertoire du site. Les sauvegardes ne doivent pas se trouver à un endroit accessible depuis Internet.
2. Considérez les mots de passe de ce fichier comme divulgués. Changez le mot de passe de la base de données, générez de nouvelles clés API et révoquez les anciennes, changez le mot de passe de la boîte e-mail utilisée par le site. Sous WordPress, générez aussi de nouvelles clés d’authentification et de nouveaux sels, ce qui déconnectera tous les utilisateurs connectés.
3. Demandez les journaux à l’hébergeur. Demandez si quelqu’un a téléchargé cette adresse (réponse du serveur 200). Vous saurez ainsi si le fichier a fuité ou s’il est simplement resté là.
4. Évaluez si des données personnelles ont fuité. Si la copie contenait une base avec des données clients, il peut s’agir d’une violation de données. L’article 33 du RGPD impose de notifier le président de l’UODO (Urząd Ochrony Danych Osobowych, l’autorité polonaise de protection des données) dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, à moins que la violation ne soit pas susceptible d’engendrer un risque pour les droits et libertés des personnes physiques. Les informations et le formulaire se trouvent sur uodo.gov.pl.

Je décris le plan complet des premières 24 heures après la découverte d’un problème dans le guide faille sur un site d’entreprise : que faire dans les 24 premières heures.

Blocage dans la configuration du serveur

Supprimer les fichiers est la base, mais il vaut aussi la peine de bloquer définitivement ces adresses. Ainsi, un fichier téléversé par erreur ne sera pas accessible.

Apache (de nombreux hébergements mutualisés), fichier .htaccess dans le répertoire du site :

# Pas de liste des fichiers dans les répertoires
Options -Indexes

# Fichiers et répertoires commençant par un point (.env, .git), sauf .well-known
RedirectMatch 404 /\.(?!well-known)

# Copies et dumps qui ne devraient pas se trouver dans le répertoire du site
<FilesMatch "(\.(sql|bak|old|swp)|~)$">
  Require all denied
</FilesMatch>

Trois remarques avant de coller ce code :

• Faites une copie de votre .htaccess actuel et ouvrez le site juste après la modification. Certains hébergeurs n’autorisent pas la ligne Options, et le site affiche alors une erreur 500. Supprimez cette ligne et demandez à l’hébergeur comment désactiver la liste des fichiers.
• Require all denied fonctionne avec Apache 2.4, c’est-à-dire sur la grande majorité des serveurs actuels.
• L’exception pour .well-known est nécessaire, car c’est notamment par là que passe le renouvellement du certificat SSL.

Nginx (serveurs VPS, la modification est faite par l’administrateur) :

location ~ /\.(?!well-known) {
    deny all;
}

location ~* \.(sql|bak|old|swp)$ {
    deny all;
}

Après la modification et la suppression des fichiers inutiles, refaites l’étape 1 de la vérification : toutes les adresses doivent renvoyer 403 ou 404.

Comment éviter cela à l’avenir

• Ne mettez sur le serveur que les fichiers du site, sans le répertoire .git, les fichiers du projet et les notes. Les outils de déploiement disposent pour cela d’une liste d’exclusions.
• Gardez .env hors du répertoire public. Les frameworks comme Laravel ont un répertoire public distinct, et lui seul doit être visible depuis Internet, tandis que le fichier .env se trouve un niveau au-dessus.
• Conservez les sauvegardes hors du répertoire du site et hors du serveur. Je décris comment l’organiser dans le guide sur la sauvegarde de site web et la règle 3-2-1.
• Faites le ménage après chaque mise à jour : supprimez les fichiers de test, les archives et les anciennes versions du site.
• Refaites la vérification de ce guide une fois par trimestre. Cela prend 10 minutes, et les scanners ne font pas de pause.

En résumé

Les scanners cherchent des fichiers restés sur le serveur par accident, et ils le font automatiquement, quelle que soit la taille de l’entreprise. Vérifiez les cinq adresses de ce guide, supprimez les copies inutiles et ajoutez un blocage dans la configuration du serveur. Si vous préférez que quelqu’un s’en charge à votre place, je vérifierai le site et le serveur dans le cadre d’un audit de sécurité, et la maintenance technique assure une protection permanente. Vous pouvez aussi tout simplement m’écrire.