Définition

Honeypot

Un honeypot est un système informatique délibérément exposé pour attirer, observer et enregistrer les actions d'un attaquant. Conçu pour ressembler à une ressource légitime (serveur, base de données, poste de travail, service applicatif), il n'a en réalité aucune fonction productive et n'est connu d'aucun utilisateur autorisé. Ce principe fondateur en fait sa force : puisque personne n'a de raison valable d'y accéder, toute interaction est par définition anormale et mérite une investigation. Le honeypot transforme ainsi le silence d'une ressource fictive en signal de détection à très haute fidélité, avec un taux de faux positifs proche de zéro.

Comment ça fonctionne

Un honeypot est instrumenté de bout en bout : chaque connexion, requête, tentative d'authentification ou commande exécutée est journalisée et déclenche une alerte. Contrairement à un IDS ou un antivirus qui doivent distinguer le trafic malveillant d'un flux légitime massif, le honeypot ne supporte aucun trafic normal. Le raisonnement de détection est donc binaire et robuste : présence d'interaction égale présence d'un acteur qui ne devrait pas être là, qu'il s'agisse d'un attaquant externe, d'un mouvement latéral interne ou d'un processus de reconnaissance automatisé.

Pour être atteint, un honeypot doit être découvert par l'adversaire. On l'expose donc dans les zones que les attaquants explorent naturellement, et on sème parfois des indices pour l'y conduire :

  • Des breadcrumbs (miettes) : identifiants stockés, entrées de configuration, partages réseau ou historiques de commande qui pointent discrètement vers le leurre.
  • Des honeytoken disséminés sur les vrais actifs, qui se comportent comme des appâts portables et déclenchent une alerte dès leur usage.
  • Une exposition de services réalistes (SSH, RDP, SMB, bases de données, API) avec des bannières et des comportements crédibles pour soutenir l'illusion.
  • Un placement aligné sur les chemins d'attaque probables, depuis la DMZ jusqu'au cœur du réseau interne et aux segments sensibles.

Types et placement dans le réseau

On classe traditionnellement les honeypots selon leur niveau d'interaction. Un honeypot basse interaction émule seulement la surface d'un service : il répond à une poignée de requêtes, capture les premières actions et présente peu de risque, mais offre une profondeur d'observation limitée. Un honeypot haute interaction met à disposition un système d'exploitation ou une application réels, ce qui permet de capturer le comportement complet de l'attaquant et ses outils, au prix d'un risque de compromission bien supérieur à maîtriser. Le choix relève d'un arbitrage entre richesse du renseignement et exposition.

Le placement détermine la valeur du signal. En périmètre ou en DMZ, le honeypot recense les scans et tentatives opportunistes venues d'Internet. À l'intérieur du réseau, parmi les actifs de production, il devient un détecteur de mouvement latéral : un attaquant déjà entré qui cartographie le domaine finira par sonder le leurre. Le honeypot s'inscrit dans une famille plus large de leurres de déception, aux côtés du decoy, du canary token et du honeytoken, qui couvrent ensemble fichiers, identifiants, services et hôtes entiers.

Valeur de détection, renseignement et risques

La principale valeur d'un honeypot est une détection précoce et fiable : il alerte souvent avant qu'un dommage réel ne survienne, là où les outils périmétriques sont aveugles. Il fournit aussi du renseignement de première main, ou intelligence : adresses sources, identifiants testés, outils déployés, tactiques et techniques observées, autant d'éléments qui alimentent la réponse à incident et le threat hunting. Le concept remonte aux travaux fondateurs des années 1990, popularisés par Lance Spitzner et le Honeynet Project, et reste aujourd'hui un pilier des stratégies de cyber-déception.

Le risque majeur tient à l'isolation. Un honeypot haute interaction mal cloisonné peut être détourné par l'attaquant pour rebondir vers les vrais systèmes ou servir de point de pivot. Une isolation réseau stricte, une surveillance permanente et des règles de confinement sortantes sont donc indispensables. Un leurre trop générique ou mal entretenu risque par ailleurs d'être identifié comme tel, perdant sa crédibilité face à un adversaire averti.

Honeypot, honeynet, honeytoken : quelles différences ?

Le vocabulaire de la cyber-déception regroupe plusieurs notions voisines qu'il est utile de distinguer. Le honeypot désigne un système leurre complet : un hôte ou un service qui accepte des connexions et enregistre tout ce qui s'y passe. Le honeynet est un réseau entier de honeypots interconnectés, généralement utilisé à des fins de recherche pour observer des campagnes d'attaque dans la durée. Le honeytoken est l'unité la plus fine : une donnée piégée (identifiant, clé API, document, entrée DNS) qui ne repose sur aucun système dédié mais déclenche une alerte dès qu'elle est utilisée.

Le canary token est une déclinaison popularisée du honeytoken, souvent distribuée sous forme de fichiers ou d'URL piégés. Le decoy (leurre) est le terme générique qui englobe l'ensemble de ces artifices. Une stratégie de deceptive security mature combine ces couches : des honeypots pour matérialiser des cibles crédibles, des breadcrumbs pour y guider les attaquants, et des honeytokens semés sur les vrais actifs pour couvrir ce que les leurres réseau ne voient pas.

Honeypot vs EDR, IDS et SIEM

Le honeypot ne remplace ni l'EDR, ni l'IDS, ni le SIEM : il comble leurs angles morts. Ces outils analysent des volumes massifs d'activité légitime pour y repérer des anomalies, ce qui les expose à deux écueils symétriques : les faux positifs qui saturent les analystes, et les faux négatifs lorsqu'un attaquant expérimenté imite un comportement normal, désactive l'agent ou exploite un poste non couvert.

  • L'EDR surveille les terminaux où il est installé ; le honeypot détecte l'activité sur des segments entiers, y compris depuis des machines sans agent (IoT, OT, imprimantes, équipements réseau).
  • L'IDS s'appuie sur des signatures et de l'analyse de trafic ; le honeypot n'a besoin d'aucune signature puisque toute interaction est suspecte par construction.
  • Le SIEM corrèle des journaux existants ; le honeypot produit un signal natif à très faible bruit qui enrichit précisément ces corrélations.
  • Face au mouvement latéral et à la reconnaissance interne, phases où les outils périmétriques sont aveugles, le honeypot est souvent le premier à alerter.

En pratique, les équipes SOC utilisent le honeypot comme un fil de détente à haute fidélité : une alerte honeypot justifie presque toujours une investigation immédiate, là où une alerte EDR moyenne doit d'abord être triée.

Cas d'usage : SOC, PME, MSSP et conformité

Les honeypots servent des profils très différents. Pour un SOC établi, ils fournissent un signal de compromission interne fiable et du renseignement exploitable (TTP, outils, identifiants testés) qui alimente le threat hunting. Pour une PME sans équipe sécurité dédiée, un honeypot managé constitue l'un des rares moyens d'obtenir une détection d'intrusion crédible sans recruter d'analystes. Pour un MSSP, la déception ajoute une couche de détection différenciante et peu coûteuse en supervision, chaque alerte étant actionnable par nature.

  • Détection du mouvement latéral et de la reconnaissance interne après une compromission initiale.
  • Détection des menaces internes : un employé ou un prestataire qui explore des ressources auxquelles il n'a pas de raison d'accéder.
  • Réduction du dwell time, le délai entre l'intrusion et sa découverte, qui se compte encore en semaines dans la plupart des incidents.
  • Appui aux exigences de détection d'incidents des référentiels NIS2, ISO 27001 (A.8.16, supervision) ou DORA, en démontrant une capacité de détection mesurable.
  • Validation des exercices red team et purple team : un honeypot bien placé mesure objectivement la discrétion des opérateurs.

Comment déployer un honeypot en entreprise

Un déploiement efficace suit une démarche simple mais rigoureuse, du choix des emplacements à l'intégration des alertes :

  • Cartographier les chemins d'attaque probables : segments serveurs, VLAN utilisateurs, DMZ, environnements cloud, liaisons site à site.
  • Choisir des personas crédibles : un faux serveur de fichiers dans le VLAN bureautique, une fausse base de données près des applications métier, un faux équipement d'administration dans le segment IT.
  • Soigner le réalisme : noms de machines conformes à la convention interne, bannières et versions cohérentes, comptes et partages plausibles.
  • Semer des breadcrumbs et honeytokens sur les vrais actifs pour guider la découverte des leurres.
  • Brancher les alertes sur les canaux existants : SIEM (Syslog, CEF, JSON), webhook, e-mail ou plateforme SOAR, avec un runbook de réponse dédié.
  • Tester la chaîne complète en conditions réelles, par exemple lors d'un pentest ou d'un exercice red team, puis réviser le placement périodiquement.

L'erreur la plus courante consiste à déployer un unique honeypot isolé dans un segment que personne ne visite, puis à conclure que la déception ne fonctionne pas. La couverture (plusieurs leurres, plusieurs segments) et la crédibilité comptent davantage que la sophistication d'un leurre unique.

Honeypots open source et solutions commerciales

L'écosystème open source est riche : Trapster Community (honeypot multi-services moderne en Python, avec clonage de sites web et réponses assistées par IA), Cowrie (SSH/Telnet), Dionaea (capture de malwares), OpenCanary (multi-protocoles léger) ou encore T-Pot (distribution agrégeant des dizaines de honeypots avec visualisation). Ces outils sont parfaits pour expérimenter, apprendre et couvrir des besoins ponctuels.

Les plateformes commerciales de deception ajoutent ce qui rend la déception exploitable à l'échelle d'une organisation : déploiement et mise à jour centralisés des leurres, génération et suivi des honeytokens, tableaux de bord, intégrations SIEM/SOAR natives et support. Le bon choix dépend de la maturité de l'équipe : commencer avec de l'open source pour valider le concept, puis industrialiser avec une plateforme quand le périmètre s'étend.

Questions fréquentes

Un honeypot est-il légal ? Oui. Déployer un leurre sur son propre réseau relève de la protection de son système d'information. Il ne s'agit pas d'incitation à la fraude : l'attaquant agit de sa propre initiative, et les journaux collectés peuvent appuyer un dépôt de plainte.

Un honeypot peut-il être détecté par un attaquant ? Un leurre générique mal configuré, oui. Un honeypot réaliste (bannières cohérentes, comportement crédible, placement plausible) résiste aux vérifications usuelles ; et même identifié, il a déjà rempli son rôle puisque l'alerte est partie au premier contact.

Combien de honeypots faut-il déployer ? La règle pratique est une couverture par segment réseau sensible plutôt qu'un nombre absolu : chaque zone où un attaquant pourrait se déplacer mérite au moins un leurre, complété par des honeytokens sur les actifs réels.

Un honeypot génère-t-il des faux positifs ? Très peu. Les seules interactions légitimes proviennent des scanners de vulnérabilité internes et des outils d'inventaire, qui se filtrent en liste blanche. Tout le reste est un signal d'investigation.

Avec Trapster

Trapster, plateforme de déception d'origine open source, déploie des honeypots et leurres sur l'ensemble du réseau, du périmètre aux segments internes, et les relie à des breadcrumbs et honeytoken sur les actifs réels afin d'orienter les attaquants vers les pièges. Chaque interaction avec un actif fictif est convertie en alerte qualifiée et à faible bruit, ce qui permet aux équipes SOC de détecter scans, accès non autorisés et mouvements latéraux sans noyer les analystes sous les faux positifs.

Termes liés

Passez de la théorie à la détection

Découvrez comment Trapster déploie honeypots, leurres et honeytokens sur votre réseau pour transformer chaque interaction suspecte en alerte fiable.

Démo de 30 min, sans engagement · Hébergé en France