Pyssly

Les robotsLa fiche du voleur

La liste du voleur

Chaque jour, des programmes demandent à Pyssly des fichiers qu’il n’a jamais eus : mots de passe, code source et sauvegardes. Voici la liste, combien de fois ils ont été demandés, pourquoi le voleur les veut et comment protéger ton propre site.

Un robot en papier avec un sac vide s’approche à pas de loup d’un classeur.

Qui est le voleur ?

Le voleur n’est presque jamais une personne qui cherche à la main. C’est un programme qui passe de site en site avec la même liste et réclame chaque fichier.

Si un site répond avec le fichier, le voleur a la clé, sans rien forcer du tout. Pyssly n’a aucun de ces fichiers, alors le voleur reçoit une fausse page et nous comptons la demande.

Tu as une page web, un site ou un serveur ? Fais en sorte que ces fichiers ne puissent pas être téléchargés. Tout en bas, tu vois comment vérifier.

Les plus recherchés

Voilà combien de fois des robots ont demandé ces fichiers à Pyssly.

On compte …

Mots de passe et clés

Le plus gros trésor : un seul fichier avec tout ce qui ouvre le site.

Comment te protéger

  • Ne mets jamais de secrets dans le dossier que le serveur web montre au public. Lis-les plutôt depuis des variables d’environnement ou un service de secrets (secrets Kubernetes, GitHub Actions ou le cloud).
  • Bloque dans le serveur web tous les fichiers et dossiers dont le nom commence par un point, sauf /.well-known/. Plus bas, tu vois comment faire.
  • Ne mets jamais de clé privée dans le dossier web, et garde tes propres clés de connexion pour toi, protégées par une phrase secrète.

Le code source

Tout le code du site, avec chaque modification faite un jour.

Comment te protéger

  • Ne mets jamais en ligne le dossier .git. Construis le site et envoie seulement le résultat, ou garde le dossier dehors avec un .dockerignore.
  • Bloque les dossiers à point dans le serveur web, comme sécurité en plus.
  • Si un mot de passe a un jour été dans le code : change-le. Le retirer dans une nouvelle modification ne suffit pas, il reste dans l’historique.

Bases de données et sauvegardes

Des copies que quelqu’un a posées sur le serveur pour un moment, puis oubliées.

Comment te protéger

  • Garde les sauvegardes hors du dossier web, de préférence sur une autre machine.
  • Bloque .sql, .bak, .zip et les fichiers du même genre dans le serveur web.
  • Ne modifie pas les fichiers directement sur le serveur : les éditeurs laissent des copies comme .swp et ~ derrière eux.

WordPress

WordPress fait tourner une grande partie du web, alors le voleur essaie toujours ses portes, même sur les sites qui n’ont pas WordPress, comme Pyssly.

Comment te protéger

  • Mets à jour WordPress, les thèmes et les extensions, et supprime les extensions que tu n’utilises pas.
  • Active la connexion en deux étapes, et désactive xmlrpc.php si tu n’en as pas besoin.
  • WordPress cherche aussi wp-config.php un dossier au-dessus de son installation. Déplace-le là seulement si ce dossier n’est pas lui-même servi sur le web, et n’en laisse jamais de copies.

Outils de base de données

Des programmes qui permettent de gérer la base de données depuis une page web.

Comment te protéger

  • Ne mets pas d’outils de base de données sur le site public. Utilise-les sur ton propre ordinateur et joins la base par un tunnel SSH ou un VPN.
  • S’ils doivent être là : verrouille-les derrière une connexion en plus ou une liste d’adresses autorisées.

Pages de débogage

Des pages que les développeurs utilisent pour regarder à l’intérieur d’un site pendant qu’il tourne. Super sur ton ordinateur, dangereuses sur le web.

Comment te protéger

  • Ne fais jamais tourner un site en mode débogage sur le web : APP_DEBUG=false, et aucun environnement de développement en production.
  • Supprime les fichiers phpinfo et les outils de test avant la mise en ligne (composer install --no-dev).
  • Verrouille les pages d’exploitation comme Actuator et server-status à ta propre adresse ou à un réseau interne.

Vieilles portes

Des programmes et des pages que le serveur exécute quand quelqu’un les demande.

Comment te protéger

  • Supprime tout ce que le serveur n’a pas besoin d’exécuter : vieux scripts, pages de test et dossiers comme cgi-bin.
  • Change le mot de passe d’usine des routeurs et des caméras, mets-les à jour, et n’expose jamais leurs pages de réglages sur internet.
  • Ne laisse s’exécuter que ce qui doit s’exécuter : un fichier envoyé par un visiteur ne doit jamais pouvoir tourner comme du code.

Boutiques et sites d’hameçonnage

Deux sortes de recherches qui ne sont pas une effraction tout de suite, mais presque.

Comment te protéger

  • Ce qu’une boutique montre à tout le monde, tout le monde peut le lire. Ne mets rien de secret dans les articles ou les champs de produits.
  • Si tu vois sur ton serveur un dossier ou un fichier que tu ne connais pas, comme lander/ : quelqu’un est peut-être entré. Supprime-le, change tous les mots de passe et mets tout à jour.

Bloquer dans le serveur web

La meilleure protection, c’est que ces fichiers ne soient jamais sur le serveur. Les blocages d’ici sont une sécurité en plus si quelque chose y arrive quand même.

Tous laissent /.well-known/ ouvert, parce qu’on en a besoin, par exemple pour les certificats. Essaie d’abord sur un site de test.

nginx En tête du bloc server du site. nginx prend la première règle regex qui correspond, et une location ^~ (par exemple pour /static/) les saute complètement, alors mets aussi les mêmes règles dedans.
# First in the server block: nginx takes the first regex location that matches,
# and a location ^~ (such as /static/) skips them, so repeat these inside it.
# Dotfiles (.env, .git, .htaccess) at any depth, but not /.well-known/
location ~ /\.(?!well-known/) {
    return 404;
}
# Databases, backups and old copies
location ~* \.(sql|bak|old|orig|swp|zip|tar|gz|7z)$ {
    return 404;
}
Apache Dans les réglages du site ou dans .htaccess (Apache 2.4).
# Dotfiles (.env, .git, .htaccess) at any depth, but not /.well-known/
RedirectMatch 404 "/\.(?!well-known/)"
# Databases, backups and old copies
<FilesMatch "\.(sql|bak|old|orig|swp|zip|tar|gz|7z)$">
    Require all denied
</FilesMatch>
Caddy Dans le bloc du site, dans le Caddyfile.
# Dotfiles (.env, .git, .htaccess) at any depth, but not /.well-known/
@hidden {
    path_regexp /\.
    not path_regexp ^/\.well-known/([^./][^/]*/?)*$
}
respond @hidden 404
# Databases, backups and old copies, /.well-known/ included
@copies path_regexp \.(sql|bak|old|orig|swp|zip|tar|gz|7z)$
respond @copies 404
.dockerignore Décide de ce qui entre dans l’image quand elle est construite, dans tous les dossiers. Cela ne couvre pas les fichiers montés pendant que le conteneur tourne, et ce n’est pas un blocage dans Traefik : le blocage se fait dans l’appli ou le serveur web.
**/.git
**/.env*
**/*.sql
**/*.bak
**/*.zip
**/id_*
**/*.tfvars

Comment vérifier

Cinq minutes dans un terminal. Remplace example.com par ta propre adresse.

Vérifie seulement ton propre site. Chercher les fichiers des autres, c’est exactement ce que fait le voleur.

  1. Demande .env

    curl -sS -i https://example.com/.env

    Regarde la réponse et le contenu. 404 ou 403, c’est bien. Si tes réglages arrivent avec, le fichier est public. (Si le site répond 200 à tout, comme beaucoup d’applis, le contenu doit être ta page normale.)

  2. Demande .git

    curl -sS -i https://example.com/.git/HEAD

    Si tu vois une ligne comme ref: refs/heads/main, tout le code source est exposé. Une page d’erreur ou ta page normale, c’est bien.

  3. Essaie sous d’autres dossiers

    curl -sS -i https://example.com/static/.env

    Un blocage peut manquer dans les dossiers servis directement, comme /static/ ou /assets/. Essaie là, et essaie d’autres fichiers de la liste, comme un .sql ou une vieille copie d’un fichier de réglages. Ce qui compte, c’est si le contenu s’affiche.

  4. Regarde le journal

    grep -E '\.env|\.git/|wp-login|phpinfo|\.sql' /var/log/nginx/access.log

    Les demandes arrivent chaque jour, alors qu’on les voie n’a rien d’étrange. Un 200 dans le journal ne prouve pas une fuite, car beaucoup d’applis répondent 200 avec leur page normale. Si tu vois un 200 pour .env ou .git/HEAD, récupère l’adresse comme plus haut et regarde le contenu.

Si un fichier est sorti

  • Supprime le fichier et bloque l’adresse.
  • Change chaque mot de passe et chaque clé qui s’y trouvait : la base de données, l’e-mail, les services de paiement et le compte cloud. Pars du principe que le voleur les a déjà.
  • Regarde dans le journal qui a téléchargé le fichier, et si quelque chose est arrivé aux comptes depuis.

Plus sur les voleurs et les autres sortes de robots dans Comment marchent les robots.