Déployer un honeypot en entreprise : le guide complet

Un honeypot mal déployé ne détecte rien : posé dans un segment que personne ne visite, avec une bannière générique et des alertes qui partent dans une boîte mail morte, il donne surtout un faux sentiment de sécurité. À l'inverse, un déploiement réfléchi transforme quelques VM légères en système de détection d'intrusion à très faible bruit. Voici la méthode que nous appliquons, étape par étape.

Étape 1 : cartographier les chemins d'attaque

Avant de poser le moindre leurre, posez-vous la question d'un attaquant : une fois un premier poste compromis, où irait-il ? Les zones à couvrir en priorité :

• Le VLAN serveurs : c'est la destination finale de la plupart des intrusions.
• Les VLAN utilisateurs : c'est là que commence le mouvement latéral.
• La DMZ : pour repérer un rebond depuis un service exposé.
• Les environnements cloud (VPC, VNet) : les mouvements est-ouest y sont souvent moins surveillés.
• Les segments d'administration : bastions, hyperviseurs, sauvegardes ; les cibles les plus critiques.

La règle pratique : au moins un leurre par segment où un attaquant pourrait transiter. La couverture prime sur la sophistication d'un leurre unique.

Étape 2 : choisir des personas crédibles

Un honeypot doit ressembler à ce qu'un attaquant s'attend à trouver dans ce segment :

• Dans le VLAN bureautique : un faux serveur de fichiers (SMB) ou une imprimante réseau.
• Près des applications métier : une fausse base de données MySQL ou MSSQL.
• Dans le segment IT : un faux équipement d'administration (interface web type firewall ou NAS).
• En DMZ : un service web ou SSH cohérent avec vos usages.

Le réalisme se joue dans les détails : nom de machine conforme à votre convention interne (SRV-FICH-04 plutôt que honeypot-01), versions de services plausibles, bannières cohérentes, comptes et partages nommés comme les vôtres. Nous avons détaillé les techniques de fingerprinting utilisées par les attaquants dans un article dédié ; retenez qu'un leurre générique est repéré en quelques minutes par un opérateur expérimenté.

Étape 3 : semer des breadcrumbs

Un honeypot doit être trouvé. Plutôt que d'attendre qu'un scan tombe dessus, guidez la découverte avec des breadcrumbs : de faux indices déposés sur les vrais systèmes.

• Identifiants enregistrés dans les gestionnaires de connexions (RDP, PuTTY).
• Entrées d'historique shell pointant vers le leurre.
• Partages réseau référencés dans des scripts ou des GPO.
• Honeytokens : fausses clés API, faux fichiers de mots de passe, documents piégés.

Un attaquant qui vole des identifiants sur un poste compromis et les rejoue sur le leurre déclenche une alerte qui vous dit quelle machine a été compromise et quels identifiants ont fuité.

Étape 4 : router les alertes là où on les lit

Une alerte honeypot est presque toujours actionnable : il n'y a pas de trafic légitime sur un leurre. Elle mérite donc un traitement prioritaire :

1. SIEM en premier choix (Syslog, CEF ou JSON selon votre stack : Splunk, Sentinel, QRadar, Elastic...), avec une règle de corrélation dédiée à sévérité haute.
2. Webhook vers votre outil d'astreinte ou un canal Slack/Teams surveillé.
3. E-mail en filet de sécurité, jamais comme canal unique.

Prévoyez un runbook court : qui investigue, quelles sources croiser (EDR du poste source, journaux AD), quand isoler la machine à l'origine de l'interaction.

Étape 5 : filtrer le bruit légitime

Les seules interactions légitimes avec un honeypot proviennent de vos propres outils : scanners de vulnérabilité, solutions d'inventaire, sondes de supervision. Mettez leurs adresses en liste blanche dès le premier jour ; c'est le seul « faux positif » structurel de la déception, et il se traite en cinq minutes.

Étape 6 : tester la chaîne complète

Un système de détection qui n'a jamais été testé n'existe pas. Validez la chaîne de bout en bout :

• Lancez un scan nmap depuis un poste interne : l'alerte doit arriver dans le SIEM en quelques secondes.
• Tentez une connexion SSH ou SMB sur le leurre avec de faux identifiants.
• Utilisez un honeytoken (ouvrez le document piégé, rejouez la fausse clé API).
• Profitez de votre prochain pentest ou exercice red team : si les auditeurs traversent le réseau sans toucher un seul leurre, votre placement est à revoir.

Étape 7 : maintenir dans la durée

La déception est un processus, pas une installation :

• Revoyez le placement à chaque évolution du réseau (nouveau segment, nouvelle application, migration cloud).
• Mettez à jour bannières et versions simulées pour suivre votre parc réel.
• Renouvelez périodiquement les honeytokens et vérifiez que les breadcrumbs sont toujours en place.
• Mesurez : nombre d'alertes, temps de réaction, couverture des segments. Le dwell time que vous évitez est votre vrai indicateur de succès.

Combien de temps pour déployer ?

Avec une plateforme dédiée, la mise en place du premier leurre prend quelques minutes : Trapster fournit des VM prêtes à l'emploi, des personas préconfigurés et les intégrations SIEM natives, et centralise honeypots et honeytokens dans un tableau de bord unique. En partant d'outils open source, comptez plutôt quelques jours pour atteindre le même niveau d'intégration ; notre comparatif des honeypots open source vous aidera à choisir votre point de départ.

Envie de voir un déploiement complet en conditions réelles ? Réservez une démo de 30 minutes avec notre équipe.