Chemins leurres comme honeypot WordPress : repérer les scanners dès la première requête
Un honeypot WordPress à chemins leurres repère les scanners dès la première requête : ReportedIP Hive surveille des adresses vers lesquelles aucune page ne renvoie et qu’aucun vrai visiteur ne demande jamais, si bien que le premier accès est déjà le signal d’attaque. La fonction est gratuite, activée par défaut et ne demande aucun entretien.
Ce guide explique comment fonctionnent les chemins leurres, ce qui se passe lors d’un accès, comment protéger les vrais fichiers de sauvegarde au niveau du serveur et comment ajouter vos propres pièges. L’interface de Hive est en anglais, les libellés sont donc cités tels qu’ils s’affichent.
Qu’est-ce qu’un chemin leurre dans WordPress ?
Les scanners automatiques ne naviguent pas, ils devinent. Ils demandent des sauvegardes de configuration oubliées, des fichiers d’environnement, des dumps de base de données et des fichiers d’identifiants, en espérant qu’un déploiement négligé en ait laissé un lisible à la racine du site. Le OWASP Web Security Testing Guide classe justement les anciennes sauvegardes et les fichiers non référencés parmi les points d’attaque classiques.
Un chemin leurre transforme ces tentatives en signal. Hive embarque une liste de ces adresses. Aucune n’est liée nulle part sur un site WordPress normal : une requête vers l’une d’elles vient donc d’un outil qui sonde le site, pas d’une personne qui le lit. Nous ne publions pas la liste, car un scanner qui la connaîtrait pourrait simplement éviter ces adresses.
Pourquoi une seule requête suffit
La plupart des capteurs d’attaque ont besoin d’un schéma avant de réagir : plusieurs échecs de connexion, une rafale d’erreurs 404, un flot de requêtes REST. Cela protège les vrais visiteurs qui se trompent de mot de passe ou suivent un ancien lien. Un chemin leurre n’a pas besoin de cette patience. Il n’existe aucune raison légitime de le demander : Hive considère donc la toute première requête comme l’indicateur d’attaque, sans attendre qu’un compteur augmente.
Parce que le signal est si net, les accès aux leurres comptent parmi les signalements les plus précieux du réseau communautaire. Une adresse qui cherche des fichiers d’identifiants sur un site fait très probablement la même chose sur des milliers d’autres.
Comment activer les chemins leurres
Les chemins leurres sont activés par défaut dans toutes les formules. Pour le vérifier ou le modifier, activez le mode expert dans l’en-tête de la page, ouvrez Protection, carte Firewall & Bots, et cherchez Decoy path blocking. La vue normale affiche le réglage avec un lien Open in expert mode.
Le Detection Score du tableau de bord compte les chemins leurres comme un capteur à part, Decoy-path block. S’il affiche Enable, l’interrupteur est désactivé.
Ce qui se passe quand un scanner mord à l’hameçon
- La requête est refusée : le scanner ne reçoit jamais de fichier.
- L’Event Log enregistre un Decoy Path Hit avec l’adresse et l’heure.
- En mode Community Network, Hive signale l’adresse au réseau de façon anonymisée, et tous les autres sites en sont informés.
Les adresses de votre liste blanche sont entièrement ignorées. Avec le Report-only mode activé sous Blocking & Escalation, l’accès est enregistré et signalé mais la requête n’est pas refusée, ce qui est utile le temps de vérifier qu’aucun de vos propres outils ne sollicite un piège par erreur.
Protéger les vrais fichiers de sauvegarde au niveau du serveur
Un chemin leurre ne fonctionne que si la requête atteint WordPress. Si un vrai fichier de sauvegarde portant un nom correspondant se trouve sur le disque, Apache ou nginx pourraient le servir directement avant même que PHP ne s’exécute. Hive ajoute donc des règles de réécriture au niveau du serveur web, qui font passer ces requêtes par WordPress, où le capteur les voit, au lieu de servir le fichier.
- Apache et LiteSpeed : Hive écrit lui-même les règles dans le
.htaccess, dans un bloc marqué# BEGIN ReportedIP Hive Decoy. Aucune intervention n’est nécessaire. - nginx : copiez l’extrait depuis Tools, onglet Server, carte Decoy Path Block (rewrite rules) dans votre configuration serveur. Il existe une forme regex pour nginx pur et une forme exact-match pour ISPConfig et les autres environnements gérés.
Les règles redirigent volontairement vers WordPress au lieu de répondre par un simple 403 au niveau du serveur, car un refus brut contournerait la détection et le signalement. La meilleure protection reste de ne pas laisser de sauvegardes à la racine du site : déplacez-les hors de la racine documentaire et supprimez les anciennes copies après un déploiement.
Vérifier la racine du site à la recherche de sauvegardes oubliées
Les chemins leurres attrapent le scanner, mais une sauvegarde lisible resterait une fuite si elle passait ailleurs. Après chaque déploiement, examinez une fois la racine du site et les répertoires voisins de wp-config.php par SSH, SFTP ou le gestionnaire de fichiers de votre hébergeur. Supprimez tout ce qui ne fait pas partie du site : les copies aux extensions .bak, .old ou .orig, tout fichier .env, les exports de base de données en .sql et les archives du site entier. Conservez ces fichiers dans un répertoire hors de la racine documentaire, où aucun serveur web ne peut les servir.
De nombreuses extensions de sauvegarde stockent leurs archives dans wp-content par défaut. Vérifiez leurs réglages et placez la destination hors de la racine du site ou sur un stockage externe.
Ajouter vos propres chemins leurres
Les développeurs complètent la liste intégrée avec le filtre reportedip_hive_decoy_paths. Les bons candidats sont les adresses d’un ancien système que les scanners essaient encore, comme l’administration d’une ancienne boutique. N’ajoutez jamais une adresse vers laquelle une vraie page renvoie ou qu’un service que vous utilisez appelle, car chaque requête vers elle compterait comme une attaque.
Où voir les accès aux leurres
Ouvrez Activity, onglet Event Log, et filtrez sur le type d’événement Decoy Path Hit. Chaque ligne affiche l’adresse, l’heure et le chemin demandé, et propose de consulter l’adresse ou de la bloquer à la main. Un filet régulier d’accès est normal pour tout site public ; une vague soudaine venant de nombreuses adresses signale généralement une nouvelle campagne de scan.
Chemins leurres, honeypot de formulaire et serveur honeypot
| Piège | Ce qu’il attrape | Où il fonctionne |
|---|---|---|
| Chemins leurres | Les scanners qui cherchent des fichiers | Sur chaque site Hive |
| Honeypot de formulaire | Les bots qui remplissent les formulaires de commentaire et de contact | Sur chaque site Hive |
| Serveur honeypot | Les attaques contre un serveur piège dédié | Sur un serveur que vous exploitez pour le réseau |
Les trois alimentent le même réseau communautaire. Le guide du honeypot de formulaire traite du spam, et la documentation du serveur honeypot montre comment exploiter un piège dédié.
Questions sur les chemins leurres comme honeypot WordPress
Les chemins leurres peuvent-ils bloquer de vrais visiteurs ?
Aucune page d’un site WordPress normal ne renvoie vers un chemin leurre : les visiteurs ordinaires n’en demandent donc jamais. Le risque vient de vos propres outils : une extension de sauvegarde, un service de surveillance ou un script de déploiement qui cherche un tel fichier. Placez leurs adresses sur la liste blanche, et elles seront entièrement ignorées.
Pourquoi la liste des chemins leurres n’est-elle pas publiée ?
Un piège ne fonctionne que tant que l’attaquant ignore où il se trouve. Un scanner muni de la liste pourrait éviter ces adresses et sonder tout le reste sans être dérangé. La liste fait partie de l’extension sur votre serveur, et le filtre vous permet d’ajouter vos propres chemins sans que personne d’autre ne les connaisse.
Les chemins leurres fonctionnent-ils avec Cloudflare ou un CDN ?
Ils fonctionnent tant que la requête atteint WordPress, ce qui est le cas normal pour des adresses qui n’existent pas en tant que fichiers statiques. Renseignez dans la carte Detection & Thresholds l’en-tête de l’IP client et les plages de proxy de confiance, pour que Hive enregistre la vraie adresse du scanner et non celle du CDN.
Ai-je besoin de chemins leurres sans sauvegardes à la racine du site ?
Oui. La valeur d’un chemin leurre tient à la détection du scanner, pas à la protection d’un fichier. Chaque accès désigne une adresse qui sonde activement des sites, et en mode Community Network cette information protège d’autres sites avant que le même scanner ne les atteigne.
Pour aller plus loin
La documentation de Hive détaille les capteurs d’attaque et les réglages du pare-feu.