Protéger un serveur Debian / Apache contre les robots d'attaque
En bref : la plupart des attaques ne visent pas votre site, mais des fichiers qu'il ne devrait pas montrer.
Sur nos serveurs, les robots ont fait plus de 6 600 tentatives en une semaine. Plus de la moitié cherchaient un seul fichier : .env, celui qui contient les mots de passe d'un site. Voici ce qu'ils cherchent, et les 7 points à régler pour leur fermer la porte.
1. Ce que les robots cherchent vraiment sur un serveur web
Ces chiffres ne viennent pas d'une étude générale : ce sont les tentatives réellement reçues par les serveurs de notre réseau de protection, qui hébergent 16 sites de la Marne et de la Haute-Marne. Aucun de ces sites n'utilise ces fichiers : chaque demande vient donc forcément d'un robot malveillant.
| Ce que le robot cherche | Pour quoi faire | Tentatives |
|---|---|---|
Le fichier .env | Lire les mots de passe de la base de données, les clés d'API, les accès e-mail | 3 331 |
| La connexion WordPress | Deviner le mot de passe administrateur | 1 263 |
Le code source (dossier .git) | Télécharger tout le code du site, mots de passe compris | 376 |
| Une vieille faille d'outil de test (PHPUnit) | Exécuter ses propres programmes sur le serveur | 352 |
| Des clés d'accès (cloud, SSH, FTP) | Prendre la main sur le serveur ou sur un compte en ligne | 248 |
| Des informations sur le serveur | Connaître les versions installées pour choisir la bonne faille | 231 |
| L'accès à la base de données (phpMyAdmin) | Entrer directement dans les données | 169 |
| Des sauvegardes oubliées | Récupérer toute la base, fichier clients compris | 66 |
Relevé du 15/10/2026 sur 3 serveurs Debian / Apache du réseau Reims Digital. Chiffres en direct, mis à jour toutes les 5 minutes : cyberattaques en Marne et Haute-Marne.
À côté de ces adresses piège, les serveurs ont aussi reçu 175 tentatives de connexion au serveur lui-même (deviner son mot de passe d'administration) et 154 adresses piégées contenant du code d'attaque. Et les robots ne dorment pas : les heures les plus chargées sont souvent la nuit.
2. Les 7 points à régler sur un serveur Debian / Apache
Ces points concernent un serveur Linux dont vous avez l'accès administrateur (VPS ou serveur dédié). Ils sont dans l'ordre où je les vérifie moi-même. Volontairement, cette page n'est pas un tutoriel : sur un serveur en production, une seule erreur de pare-feu ou d'accès suffit à vous enfermer dehors ou à couper vos sites. Si vous n'êtes pas sûr de vous, faites-vous accompagner.
1. Les fichiers cachés et les sauvegardes ne doivent jamais être visibles
- Ce que les robots tentent
- 3 331 demandes du fichier
.env, 376 du dossier.git, 66 de sauvegardes. - Ce qu'il faut obtenir
- Les fichiers de mots de passe et les sauvegardes sont rangés en dehors du dossier public du site. En plus, le serveur refuse de montrer tout fichier caché, pour tous les sites qu'il héberge.
- Le piège à éviter
- Bloquer trop large : certains dossiers cachés sont indispensables (celui qui sert au renouvellement des certificats HTTPS, par exemple). Une règle mal écrite peut faire expirer votre cadenas HTTPS trois mois plus tard.
2. L'accès d'administration (SSH) : une clé, pas un mot de passe
- Ce que les robots tentent
- 175 tentatives de connexion en une semaine, avec des listes de mots de passe courants.
- Ce qu'il faut obtenir
- La connexion au serveur se fait uniquement par clé SSH : sans mot de passe accepté, deviner ne sert à rien. Le compte administrateur principal n'est pas accessible directement.
- Le piège à éviter
- Couper les mots de passe avant d'avoir vérifié que la clé fonctionne, depuis une deuxième connexion. C'est la façon la plus courante de perdre l'accès à son propre serveur.
3. Un pare-feu qui refuse tout ce qui n'est pas prévu
- Ce que les robots tentent
- Ils balaient tous les ports à la recherche d'un service oublié : base de données, partage de fichiers, bureau à distance.
- Ce qu'il faut obtenir
- Seul le site (ports web) est ouvert à tout Internet. L'accès d'administration n'est ouvert qu'à vos propres adresses.
- Le piège à éviter
- Activer le pare-feu avant d'avoir autorisé sa propre adresse, ou oublier qu'une adresse de box internet peut changer. Il faut toujours garder un second chemin d'accès (console de l'hébergeur).
4. Un garde automatique qui bannit ceux qui insistent
- Ce que les robots tentent
- Essayer encore et encore, depuis la même adresse, jusqu'à trouver une ouverture.
- Ce qu'il faut obtenir
- Un outil comme Fail2ban lit les journaux du serveur et bannit automatiquement les adresses qui accumulent les erreurs : mots de passe faux, pages piège, demandes anormales. Vos propres adresses ne doivent jamais pouvoir être bannies.
- Le piège à éviter
- Un garde qui surveille la mauvaise porte. Nous l'avons rencontré : si l'accès d'administration a été déplacé, Fail2ban doit le savoir, sinon il bannit sur l'ancienne porte et laisse la vraie ouverte. Un serveur peut afficher « protégé » sans l'être.
5. Les mises à jour de sécurité, automatiques
- Ce que les robots tentent
- 352 tentatives sur une faille corrigée depuis des années : elle ne marche que sur les serveurs jamais mis à jour.
- Ce qu'il faut obtenir
- Les correctifs de sécurité de Debian s'installent seuls chaque jour, et quelqu'un vérifie régulièrement si un redémarrage est nécessaire.
- Le piège à éviter
- Croire que les mises à jour du système suffisent : le site lui-même (WordPress, extensions, bibliothèques) a ses propres mises à jour, que Debian ne fait pas.
6. Un serveur qui ne dit rien de lui
- Ce que les robots tentent
- 231 demandes pour connaître les versions installées et choisir la faille adaptée.
- Ce qu'il faut obtenir
- Apache n'annonce ni sa version ni celle de PHP, n'affiche jamais la liste des fichiers d'un dossier, et les messages d'erreur ne montrent aucun détail technique.
- Le piège à éviter
- Laisser traîner une page de test (
phpinfo, page d'installation) après une mise en ligne : elle dit tout du serveur.
7. Les outils d'administration hors de portée
- Ce que les robots tentent
- 169 tentatives sur phpMyAdmin et les outils du même genre.
- Ce qu'il faut obtenir
- phpMyAdmin et les interfaces d'administration ne répondent qu'à vos adresses. La base de données n'écoute que le serveur lui-même, jamais Internet.
- Le piège à éviter
- Se contenter d'un mot de passe solide sur phpMyAdmin : la moindre faille de l'outil donne alors accès à toutes les données.
3. Un test simple, dans votre navigateur
Sans rien installer et sans risque, ouvrez ces adresses en remplaçant votre-site.fr par le vôtre :
- votre-site.fr/.env : vous devez voir une page d'erreur (introuvable ou interdit). Si une liste de mots de passe s'affiche, c'est urgent.
- votre-site.fr/.git/config : même chose, une page d'erreur.
- votre-site.fr/phpmyadmin : depuis votre téléphone en 4G, vous ne devez pas voir de page de connexion.
Ces trois tests ne disent pas que votre serveur est sûr. Mais si l'un d'eux échoue, il ne l'est pas.
Pour aller plus loin, l'audit gratuit de votre site contrôle aussi plusieurs points de sécurité visibles de l'extérieur.
4. La limite d'un serveur qui se défend seul
Même avec ces 7 points réglés, votre serveur bloque un robot après qu'il a essayé plusieurs fois. Chaque serveur apprend seul : le robot qui a frappé un autre site ce matin arrive chez vous comme un inconnu.
Sur nos serveurs, 189 adresses ont attaqué plusieurs serveurs différents en quelques jours. C'est pour elles que j'ai construit un réseau de protection partagé : dès qu'une adresse attaque l'un des sites piégés du réseau, elle est bannie sur tous les serveurs protégés en moins de 5 minutes, avant d'arriver chez vous.
Vous préférez que ce soit fait, vérifié et surveillé ?
Je contrôle ces 7 points et les autres sur votre serveur, je vous remets un rapport clair de ce qui va et de ce qui manque, j'installe la protection partagée et vous recevez chaque matin le relevé des attaques bloquées chez vous. 390 € par serveur, puis 29 € par mois. Serveurs Linux avec accès administrateur ; hébergements mutualisés non compatibles.
Voir la protection de serveur
Me poser une question sur votre serveur →
5. Questions fréquentes
Mon site n'a pas de fichier .env : suis-je concerné ?
Oui. Les robots ne savent pas ce que contient votre site : ils essaient la même liste partout. Le premier point protège aussi le dossier .git, les sauvegardes et les fichiers oubliés par un ancien prestataire.
Changer le port SSH suffit-il ?
Non : cela réduit le bruit dans les journaux, mais un robot finit par trouver le port. Ce qui protège vraiment, c'est la connexion par clé uniquement et le filtrage par adresse (points 2 et 3).
Pourquoi ne donnez-vous pas les commandes exactes ?
Parce que chaque serveur est différent et qu'une commande copiée sans être comprise peut couper vos sites ou vous enfermer dehors. Cette page vous dit quoi vérifier et pourquoi ; si vous administrez vous-même votre serveur, la documentation officielle de Debian et de chaque outil reste la référence.
Fail2ban risque-t-il de bloquer Google ou mes clients ?
Fail2ban ne bannit que les adresses qui accumulent les erreurs. Il faut cependant y déclarer vos propres adresses. Le réseau de protection partagé, lui, garde en liste blanche les robots de Google, Bing, Apple et des IA, d'après les listes officielles de leurs éditeurs.
Et sur un hébergement mutualisé (OVH, o2switch, Ionos…) ?
La plupart de ces points dépendent alors de l'hébergeur, pas de vous. Ce qui reste entre vos mains : ne rien laisser traîner dans le dossier du site (point 1) et tenir à jour le site et ses extensions.
Ces 7 points remplacent-ils un audit de sécurité ?
Non. Ils ferment les portes que les robots essaient chaque jour. Un audit ou un test d'intrusion cherche en plus les failles propres à votre site (code, formulaires, extensions).
Page rédigée par Alexandre Léger, développeur web freelance à Reims depuis 2005, qui administre lui-même les serveurs Debian / Apache de ses clients.