6 erreurs qui rendent un honeypot inutile

Installer un honeypot sur votre réseau est une solution très efficace pour détecter des attaques et y répondre rapidement. Mais encore faut-il le déployer et le configurer correctement. Un honeypot mal pensé n'attire personne, ou pire, devient une porte d'entrée vers votre vrai réseau.

Voici les 6 erreurs les plus fréquentes à éviter pour que votre honeypot remplisse réellement son rôle.

Erreur 1 : trop isoler votre honeypot du reste du réseau

C'est paradoxalement l'une des erreurs les plus fréquentes : trop isoler son honeypot. Une machine placée seule, sur un segment à part, sans aucun trafic autour d'elle, ne risque pas de générer beaucoup d'alertes.

Dans la plupart des cas, un attaquant ne verra même pas la machine. Et si jamais il tombe dessus, le fait qu'il s'agisse d'une machine isolée et sans trafic lui indiquera immédiatement qu'il s'agit d'un honeypot.

Il faut donc placer la machine dans le même réseau que vos vrais systèmes, l'intégrer à l'Active Directory avec un compte machine aux privilèges strictement limités, lui attribuer des adresses IP cohérentes avec le reste du parc, et la faire dialoguer avec d'autres machines. L'objectif est de rendre le honeypot légitime et complètement intégré à votre réseau, sans pour autant en faire un point d'appui pour l'attaquant.

Erreur 2 : un honeypot trop facilement identifiable

Un honeypot mal configuré peut être rapidement identifié par un attaquant : bannières factices incohérentes, nom de machine suspect, partage SMB vide, etc. Ce sont toutes ces petites configurations qui rendent votre honeypot réaliste et donc capable d'attirer les attaquants vers lui.

Voici un exemple d'honeypot mal configuré, et de fait facilement détectable :

On y remarque l'incohérence des services proposés, un mélange de composants Linux et Windows qui n'a aucun sens sur une même machine.

Voici maintenant un honeypot correctement configuré :

Ici, l'illusion est beaucoup plus aboutie et susceptible de tromper un attaquant.

Erreur 3 : une surveillance et des alertes mal configurées

Un honeypot n'a de valeur que si les interactions qu'il enregistre sont surveillées activement. Sans centralisation des logs (SIEM ou équivalent) et sans alertes correctement calibrées, les traces d'intrusion peuvent passer totalement inaperçues, ou au contraire noyer l'équipe sous des faux positifs.

Erreur 4 : pas de breadcrumbs

Un honeypot livré à lui-même reste passif. Pour le rendre efficace, il ne suffit pas de le déployer et d'attendre : il faut activement diriger les attaquants vers lui. C'est là qu'interviennent les breadcrumbs.

Il s'agit de petits artefacts disséminés sur votre réseau (scripts, historique de commandes, fichiers texte, etc.) dont le rôle est d'attirer une personne malveillante vers le honeypot, généralement à l'aide de faux identifiants associés à l'adresse IP de la machine leurre. Un attaquant qui a déjà compromis une machine du réseau et qui tombe sur ces indices sera naturellement tenté de les utiliser, ce qui le conduit droit vers le honeypot.

Sans breadcrumbs, le honeypot dépend uniquement de la chance qu'un attaquant le découvre par lui-même. Ces artefacts sont donc indispensables pour augmenter significativement son efficacité.

Erreur 5 : choisir le mauvais type de honeypot

Il existe différents types de honeypots, classés selon leur niveau d'interaction, et tous ne conviennent pas à chaque usage.

Les honeypots à forte interaction (high interaction), comme T-Pot, simulent un système beaucoup plus en profondeur, avec de vrais services et parfois un vrai système d'exploitation. Ils sont surtout utilisés dans un cadre de recherche, pour observer et analyser en détail le comportement d'un attaquant. Cette profondeur a un coût : ils demandent davantage de ressources, de temps de configuration et un confinement plus strict.

Les honeypots à faible ou moyenne interaction (low/medium interaction), comme Trapster ou Thinkst Canary, émulent seulement quelques services de façon plus légère. Ils sont largement suffisants, et même préférables, dans un cadre de protection d'un système d'information, où l'objectif principal est de détecter rapidement une intrusion et de déclencher une alerte, plutôt que d'étudier en profondeur les méthodes de l'attaquant.

Déployer un honeypot à forte interaction pour un simple besoin de détection revient à mobiliser des ressources et une complexité inutiles. À l'inverse, utiliser un honeypot à faible interaction dans un contexte de recherche poussée limitera fortement la qualité des données collectées. Le choix du type de honeypot doit donc toujours découler de l'objectif recherché.

Erreur 6 : l'absence de plan de réponse

Détecter une attaque ne sert à rien si personne ne sait quoi faire ensuite. Sans procédure claire (qui est alerté, quelles actions entreprendre, comment analyser les données collectées), le honeypot devient un simple outil de collecte sans valeur opérationnelle.

Pour la mise en œuvre pas à pas, voir notre guide de déploiement d'un honeypot en entreprise.

En résumé

Un honeypot efficace dépend de tous les aspects cités précédemment. Il ne suffit pas de le déployer sur un réseau puis d'attendre : il faut le rendre crédible, parfaire son intégration au reste du réseau, le rendre visible aux bons endroits, et l'accompagner d'une surveillance active, afin de pouvoir réellement piéger un attaquant.