Un honeypot (« pot de miel ») est un leurre : un système, un service ou une donnée volontairement attirants, sans aucune valeur réelle, dont le seul rôle est d’être attaqué ou consulté pour que vous le sachiez. Puisqu’aucun utilisateur légitime n’a de raison d’y toucher, toute interaction est suspecte. C’est l’un des rares outils de détection qui produit très peu de faux positifs. Cet article explique à quoi servent les honeypots, présente les différents types, détaille comment les mettre en place au niveau applicatif et serveur, comment les surveiller, et quels pièges éviter.
Cadre d’usage : déployez des honeypots uniquement sur votre propre infrastructure ou avec l’accord écrit de son propriétaire, et isolez-les du reste du réseau. Un pot de miel mal isolé peut devenir un point d’entrée ou un relais d’attaque contre des tiers, et vous en seriez responsable. Les journaux collectés contiennent des adresses IP, qui sont des données personnelles : conservez-les avec parcimonie et sur une durée définie.
À quoi sert un honeypot ? #
| Objectif | Ce que le honeypot apporte |
|---|---|
| Détection précoce | Alerte dès qu’un attaquant explore le réseau ou tente une connexion |
| Peu de faux positifs | Aucun usage légitime : une alerte vaut enquête |
| Renseignement sur la menace | Adresses IP, identifiants testés, outils, commandes, malwares déposés |
| Détection de mouvement latéral | Un leurre interne révèle un attaquant déjà présent |
| Ralentir l’attaquant | Il perd du temps sur un système sans valeur |
| Étude et formation | Observer des comportements réels, former les analystes |
| Mesure de l’exposition | Voir combien de scans et d’attaques arrivent sur Internet |
Deux grandes familles d’usage :
- les honeypots de production, placés dans votre réseau pour détecter des intrusions et alerter le SOC ;
- les honeypots de recherche, exposés sur Internet pour collecter des données sur les attaquants et les campagnes en cours.
Les types de honeypot #
Selon le niveau d’interaction #
| Niveau | Principe | Avantages | Limites |
|---|---|---|---|
| Faible interaction | Émule quelques services (bannière, port ouvert) | Simple, léger, peu risqué | Facile à repérer, peu d’informations |
| Interaction moyenne | Émule un service de façon crédible (faux shell SSH, faux serveur web) | Bon compromis, capte identifiants et commandes | Un attaquant averti peut le détecter |
| Forte interaction | Vrai système, réellement exploitable, surveillé de près | Données riches, comportement réel | Risque élevé, lourd à isoler et à maintenir |
Selon la cible #
- Honeypots de service ou serveur : simulent SSH, Telnet, RDP, SMB, FTP, bases de données, et parfois des protocoles industriels.
- Honeypots applicatifs : fausses pages d’administration, faux WordPress, fausses API.
- Honeytokens (jetons leurres) : ce ne sont pas des machines mais des données piégées (clé d’API factice, document, ligne de base de données, compte) qui alertent quand on les utilise.
- Honeynets : réseau entier de leurres, avec plusieurs machines simulées.
Les outils de référence #
| Outil | Rôle | Interaction | Remarques |
|---|---|---|---|
| Cowrie | Faux serveur SSH et Telnet | Moyenne | Enregistre les identifiants testés et les commandes tapées, conserve les fichiers téléchargés. Successeur de Kippo |
| T-Pot | Plateforme tout-en-un qui regroupe de nombreux honeypots | Variable | Fournie avec des tableaux de bord de visualisation, conçue pour la recherche |
| OpenCanary | Leurre de services réseau (SSH, HTTP, SMB, FTP, etc.) | Faible | Léger, adapté aux honeypots internes avec alertes |
| Canarytokens | Jetons piégés (URL, document, clé, DNS) | Aucune (leurre de donnée) | Gratuit en ligne, alerte par e-mail ou webhook |
| Conpot | Leurre de systèmes industriels (ICS/SCADA) | Faible à moyenne | Pour la recherche sur les protocoles industriels |
| Dionaea | Capture de malwares qui se propagent par le réseau | Faible à moyenne | Ancien, projet moins actif |
Les projets évoluent : vérifiez l’état de maintenance de chaque dépôt avant de l’adopter.
Mise en place côté serveur #
Principe de placement #
- Honeypot exposé sur Internet : dans une zone dédiée, séparée de la production (DMZ ou réseau isolé, voire hébergement distinct). Vous collectez des données, vous ne protégez pas quelque chose.
- Honeypot interne : dans les réseaux d’utilisateurs et de serveurs, avec des noms crédibles (par exemple
srv-sauvegarde,nas-compta). Il détecte l’attaquant déjà à l’intérieur, qui cherche des cibles en scannant le réseau.
Exemple : un leurre SSH avec Cowrie #
Cowrie écoute par défaut sur le port 2222 et présente un faux shell. Une installation rapide avec Docker (voir notre article sur la sécurisation de Docker) :
docker run -d --name cowrie -p 2222:2222 cowrie/cowrie
Pour l’exposer sur le port SSH habituel sans y placer votre vrai service, déplacez d’abord votre administration SSH réelle sur un autre port (et restreignez-la par pare-feu ou VPN), puis redirigez le port 22 vers 2222 avec votre pare-feu. Ne redirigez jamais un port si vous risquez de vous couper l’accès à votre propre machine : testez depuis une seconde session avant de fermer la première.
Bonnes pratiques d’isolation :
- Conteneur ou machine virtuelle dédiée, sans accès au réseau de production ;
- Aucun secret réel : pas de clés, pas de mots de passe, pas de données existantes ;
- Filtrage du trafic sortant : le leurre ne doit pas pouvoir attaquer d’autres machines ; n’autorisez que ce dont il a besoin pour envoyer ses journaux ;
- Utilisateur sans privilèges et système à jour ;
- Instantanés ou reconstruction régulière pour repartir d’un état sain.
Exemple : un honeypot interne avec OpenCanary #
OpenCanary s’installe avec Python (pip install opencanary), génère un fichier de configuration à éditer (opencanaryd --copyconfig), où vous activez les modules voulus (SSH, HTTP, SMB, FTP…) et le canal d’alerte, puis se lance avec opencanaryd --start. Vérifiez la procédure dans la documentation du projet avant de l’appliquer, car les options évoluent. Un usage courant : une machine virtuelle discrète dans le réseau des serveurs qui alerte par e-mail ou dans votre SIEM à chaque tentative de connexion.
Mise en place côté applicatif #
Sur le plan applicatif, l’idée est de placer des pièges dans vos propres applications et vos données, à des endroits où seul un attaquant irait.
| Leurre | Où le placer | Ce qui déclenche l’alerte |
|---|---|---|
| Fausse page d’administration | /admin-old, /wp-login-backup |
Toute requête vers cette URL (elle n’est liée à rien) |
Entrée dans robots.txt |
Chemin « interdit » factice | Un visiteur qui suit le chemin est un explorateur, pas un moteur légitime |
| Fausse clé d’API ou de cloud | Dépôt de code, fichier de configuration, wiki | Utilisation de la clé (Canarytokens ou service équivalent) |
| Enregistrement leurre en base | Table clients (faux client, fausse adresse e-mail) | Apparition de cet e-mail dans une fuite ou un envoi de courriel |
| Faux document | Partage réseau, nom attractif (mots_de_passe.xlsx) |
Ouverture du fichier (document piégé) |
| Compte leurre | Annuaire (faux compte administrateur) | Toute tentative d’authentification ou demande de ticket Kerberos |
| Enregistrement DNS leurre | Nom interne fictif | Résolution de ce nom |
Précautions applicatives :
- Ne mettez pas de piège sur une URL utilisée par vos utilisateurs. Vérifiez d’abord dans vos journaux que personne, y compris vos outils de supervision et vos scanners internes, n’y accède déjà.
- Ne rendez pas un piège dangereux : une fausse page d’administration ne doit rien exécuter, ni traiter de vraies données.
- Faites valider ces pièges par les équipes concernées, pour éviter de déclencher vous-même de fausses alertes lors d’un audit, ou de troubler les tests de vos prestataires. Voir notre article sur la préparation d’un pentest : les leurres doivent figurer dans le périmètre de coordination.
Comment surveiller un honeypot #
Un honeypot sans surveillance ne sert à rien. La chaîne minimale :
- Journaliser : activer les journaux (Cowrie produit des journaux structurés au format JSON), incluant la date, l’adresse source, les identifiants testés, les commandes et les fichiers récupérés.
- Centraliser : envoyer les journaux hors du honeypot, vers un SIEM ou une pile de supervision (Elastic, Wazuh, Splunk, Graylog). Un attaquant qui prend la main peut effacer les journaux locaux : l’exportation immédiate protège la preuve.
- Alerter : créer des règles adaptées à chaque type de honeypot.
- Enrichir : réputation de l’adresse IP, géolocalisation, correspondance avec des indicateurs connus.
- Traiter : chaque alerte suit le processus d’incident habituel, avec une fiche dans le ticket.
- Exploiter : transformer les indicateurs collectés en règles de blocage ou de détection.
Règles d’alerte selon le contexte #
| Contexte | Règle recommandée | Priorité |
|---|---|---|
| Honeypot interne (réseau utilisateur ou serveur) | Toute connexion entrante est une alerte | Haute : un attaquant est probablement à l’intérieur |
| Compte leurre dans l’annuaire | Toute authentification ou demande de ticket | Haute |
| Clé ou jeton piégé | Toute utilisation | Haute : fuite ou vol de secret |
| Honeypot exposé sur Internet | Résumé quotidien, alerte sur comportement inhabituel (téléchargement d’un binaire, nouvelle technique) | Faible à moyenne : le bruit d’Internet est permanent |
La différence est essentielle : un honeypot sur Internet reçoit des scans en continu, ce qui n’est pas en soi un incident. En revanche, une connexion vers un honeypot interne ne devrait jamais se produire.
Que faire d’une alerte interne ? #
- Identifier la source : quelle machine, quel compte, quelle heure.
- Vérifier s’il s’agit d’un scan autorisé (outil d’inventaire, audit programmé).
- Sinon, traiter comme un incident : isoler la machine source si nécessaire, conserver les preuves, investiguer (voir notre article sur la réponse à incident selon l’ISO 27035).
- Rechercher d’autres traces : les mêmes identifiants ou la même adresse ailleurs dans le réseau.
- Documenter avec vos mémos de clôture d’alerte.
Pour l’analyse du trafic capturé, un outil comme Wireshark reste utile.
Limites et risques #
- Détection par l’attaquant : les attaquants expérimentés savent reconnaître les leurres classiques (bannières par défaut, comportements peu réalistes, absence de vie sur la machine). Personnalisez et rendez-les crédibles.
- Risque de compromission : surtout pour les systèmes à forte interaction, un honeypot peut devenir un tremplin. Isolez et filtrez le trafic sortant.
- Maintenance : un leurre non entretenu se démarque, et les composants obsolètes peuvent contenir de vraies failles.
- Faux sentiment de sécurité : un honeypot est un complément à la détection (EDR, SIEM, journalisation), pas un remplacement. Aucun pot de miel ne remplace les mises à jour ou l’authentification forte.
- Bruit : sur Internet, il faut savoir distinguer le bruit de fond des vrais signaux.
- Cadre juridique et vie privée : les journaux contiennent des adresses IP (données personnelles). Définissez une finalité, une durée de conservation et un accès restreint. Ne tentez pas de « riposter » : la contre-attaque est illégale. Pour le cadre général, voir notre article sur le RGPD en investigation.
Par où commencer #
- Commencez par les honeytokens : quelques clés et documents piégés sont gratuits, rapides et à faible risque.
- Ajoutez un honeypot interne léger (OpenCanary, par exemple) dans le réseau des serveurs, avec des alertes reliées à votre SIEM.
- Créez un compte leurre dans l’annuaire et surveillez son utilisation.
- Testez ensuite un honeypot exposé (Cowrie ou T-Pot) sur une machine isolée, pour comprendre le bruit d’Internet.
- Définissez le processus : qui reçoit l’alerte, qui décide, dans quel délai.
- Revoyez régulièrement : ajustez les leurres, retirez ceux qui ne servent pas, corrélez avec le reste de la détection.
Checklist #
- Objectif défini : détecter en interne ou collecter du renseignement
- Honeypot isolé, sans données ni secrets réels
- Trafic sortant filtré
- Journaux exportés vers un SIEM ou un stockage externe
- Alertes différenciées interne et Internet
- Responsable et processus de traitement de l’alerte définis
- Équipes et prestataires informés pour éviter les fausses alertes
- Durée de conservation des adresses IP et accès aux journaux cadrés
- Mise à jour et revue régulières
Points clés #
Un honeypot est un leurre dont la seule fonction est de révéler qu’on s’intéresse à lui. Placé à l’intérieur du réseau, il détecte des attaquants qui cherchent des cibles ; exposé sur Internet, il renseigne sur les méthodes en circulation. Les honeytokens, comme les clés ou les comptes piégés, sont le moyen le plus simple de démarrer. L’essentiel tient en trois règles : isoler le leurre, exporter les journaux, traiter chaque alerte interne comme un incident. Bien intégrés à un dispositif de détection, ces pièges apportent des signaux fiables que peu d’outils offrent.