Honeypot sur VPS
T-Pot & Threat Intelligence
Déploiement d'une plateforme multi-honeypot T-Pot sur un VPS Debian exposé à internet — pour observer, collecter et analyser les tentatives d'intrusion réelles en temps réel.
C'est quoi un honeypot ?
Un piège numérique délibérément vulnérable, conçu pour attirer et étudier les attaquants.
Principe
Un honeypot est un système informatique délibérément exposé et configuré pour imiter des services vulnérables (SSH, FTP, HTTP…). Son seul rôle est d'attirer les attaquants et d'enregistrer leur comportement — aucun utilisateur légitime ne doit s'y connecter.
Utilité
Il permet de comprendre les méthodes d'attaque réelles : quels ports sont scannés en premier, quels identifiants sont testés par brute-force, quels exploits sont utilisés. C'est une source précieuse de threat intelligence.
Ce que ce n'est pas
Un honeypot n'est pas un outil offensif. Il agit en défenseur passif : il observe sans contre-attaquer. Toute l'infrastructure de production est séparée et le honeypot ne contient aucune donnée réelle.
T-Pot : la plateforme choisie
T-Pot est une plateforme open source développée par Deutsche Telekom Security, qui orchestre plus de 20 honeypots différents via Docker.
Ce que c'est
T-Pot est une image ISO / script d'installation qui déploie automatiquement un ensemble de honeypots spécialisés, chacun dans son propre conteneur Docker. Il inclut également une stack ELK (Elasticsearch, Logstash, Kibana) pour centraliser et visualiser tous les événements capturés.
Pourquoi T-Pot
Plutôt que de configurer un seul honeypot manuellement, T-Pot couvre simultanément de nombreux protocoles et vecteurs d'attaque. La centralisation des logs dans Kibana offre une interface de visualisation puissante et les données sont automatiquement enrichies (géolocalisation, ASN, CVE).
Architecture
Chaque honeypot tourne dans un conteneur Docker isolé. Le trafic entrant est redirigé vers le bon conteneur selon le port de destination. Nginx gère l'accès à l'interface d'administration. Elasticsearch stocke l'ensemble des événements capturés.
Infrastructure — Le VPS
Un serveur cloud exposé directement sur internet, sans filtrage en amont, pour recevoir le trafic malveillant mondial.
Internet — Attaquants
Scanners automatisés, bots, scripts de brute-force et acteurs malveillants du monde entier tentent de se connecter en permanence aux adresses IP exposées.
VPS Debian 12 — 8 Go RAM / 4 vCPU
VPS hébergé chez un fournisseur cloud exposé directement sur internet. Règles iptables minimales — seul le port SSH d'administration (port non standard) est réservé à l'opérateur. Tous les autres ports sont redirigés vers T-Pot.
Docker Compose — T-Pot
Docker Compose démarre tous les conteneurs honeypot et la stack ELK. Chaque conteneur écoute sur ses ports spécifiques et journalise les événements dans Elasticsearch via Logstash.
Kibana — Tableau de bord
Interface de visualisation avec dashboards préconfigurés : cartes mondiales des attaques, top des identifiants testés, fréquence par protocole, enrichissement CVE et géolocalisation par ASN.
Prérequis T-Pot
Architecture Threat Intelligence — CrowdSec
Le VPS honeypot ne se contente pas de collecter des données : il alimente en temps réel le serveur de production via l'API CrowdSec pour bannir automatiquement les IP malveillantes détectées.
Installation pas à pas
T-Pot s'installe en quelques commandes sur un Debian 12 fraîchement installé.
Mise à jour du système
Mettre à jour les paquets avant toute installation :
apt update && apt upgrade -y
apt install git curl -yClonage du dépôt T-Pot
Récupérer le code source officiel depuis le dépôt GitHub de Deutsche Telekom :
git clone https://github.com/telekom-security/tpotce
cd tpotceLancement du script d'installation
Le script installe Docker, Docker Compose, configure le système et démarre tous les conteneurs. L'installateur propose plusieurs profils : Standard, Hive (multi-nœuds), ou Sensor (capteur distant). J'ai choisi le profil Standard pour une installation autonome.
./install.shL'installateur demande de créer un utilisateur dédié et un mot de passe pour l'interface web T-Pot. Il reconfigure également les règles iptables automatiquement pour rediriger le trafic.
Sécurisation de l'accès administrateur
Avant de redémarrer, je configure l'accès SSH sur un port non standard pour réserver le port 22 à Cowrie (honeypot SSH). L'accès à Kibana et à l'interface T-Pot se fait via le port 64297 en HTTPS.
# Changer le port SSH administrateur
Port 64295
# Désactiver l'auth par mot de passe — clé SSH uniquement
PasswordAuthentication no
PubkeyAuthentication yesRedémarrage et vérification
Après redémarrage, vérifier que tous les conteneurs T-Pot sont actifs :
reboot
# Après redémarrage :
cd ~/tpotce
docker compose ps
Une vingtaine de conteneurs doivent apparaître à l'état Up.
L'interface Kibana est accessible sur https://<IP>:64297.
Les premières tentatives de connexion apparaissent généralement dans
les minutes qui suivent l'exposition.
Les honeypots inclus
Chaque honeypot simule un service réseau différent pour attirer des attaques ciblant des protocoles spécifiques.
Cowrie
Simule un serveur SSH/Telnet vulnérable. Enregistre chaque tentative de connexion : identifiants testés, commandes exécutées après authentification, téléchargements de fichiers et sessions complètes.
Intérêt : Observer les campagnes de brute-force SSH et les payloads déposés après compromission (miners, backdoors, scripts de propagation).
Dionaea
Simule plusieurs services Windows et web. Capture les exploits qui tentent de propager des malwares via SMB (type EternalBlue), FTP ou HTTP. Il récupère et stocke les binaires malveillants téléchargés.
Intérêt : Collecter des samples de malwares pour analyse ultérieure, observer les tentatives d'exploitation SMB.
Honeytrap
Honeypot généraliste qui écoute sur n'importe quel port non utilisé. Il capture le premier paquet reçu sur des ports inconnus et enregistre les tentatives de connexion brutes sans simuler de service spécifique.
Intérêt : Découvrir quels ports non standards sont activement scannés et tentés par les attaquants.
ADBHoney
Simule un appareil Android avec le débogage USB activé et exposé en réseau (port 5555). Capture les tentatives d'exploitation ADB qui cherchent à installer des APK malveillants sur des appareils exposés.
Intérêt : Mesurer l'ampleur des scans ADB automatisés, vecteur souvent négligé dans les IoT et appareils Android.
Heralding
Simule des services de messagerie et d'accès distant. Enregistre les tentatives d'authentification sur les protocoles de mail professionnels souvent ciblés pour compromettre des comptes d'entreprise.
Intérêt : Observer les campagnes de credential stuffing ciblant les serveurs de mail.
CiscoASA
Simule un équipement Cisco ASA (pare-feu/VPN). Capture les tentatives d'exploitation de CVE connus sur les équipements Cisco, souvent ciblés en entreprise pour pivot réseau.
Intérêt : Observer l'exploitation automatisée de vulnérabilités connues sur des équipements réseau critiques.
Ce que j'ai observé
Après quelques jours d'exposition, les chiffres parlent d'eux-mêmes.
Brute-force SSH industrialisé
Dès la mise en ligne du VPS, des bots automatisés ont commencé à tester des combinaisons identifiant/mot de passe sur le port 22. Les dictionnaires utilisés contiennent des milliers d'entrées : identifiants par défaut d'équipements IoT, listes de mots de passe communs et credentials fuités.
Dépôt de miners
Cowrie a capturé plusieurs sessions où l'attaquant, après s'être connecté au faux SSH, exécutait des commandes pour télécharger et lancer un cryptominer XMRig (Monero). L'objectif : utiliser les ressources CPU du serveur compromis pour miner de la cryptomonnaie.
Scans massifs automatisés
Honeytrap a intercepté des connexions sur des centaines de ports différents, caractéristiques de scanners automatisés comme Masscan ou Shodan. Ces scans cherchent des services exposés, des interfaces d'administration ou des applications web vulnérables (Struts, Log4Shell…).
Exploitation ADB Android
ADBHoney a reçu des connexions tentant d'installer des APK malveillants sur le faux appareil Android. Ce vecteur cible les Smart TV, boîtiers Android et téléphones avec le débogage réseau activé — souvent par négligence ou mauvaise configuration.
Ce que j'ai appris
Ce projet m'a apporté une compréhension concrète des menaces réelles — loin des environnements de lab simulés.
Linux & administration système
Gestion d'un VPS Debian from scratch : configuration SSH sécurisée, règles iptables, gestion des services systemd, droits utilisateurs et monitoring des ressources système.
Docker & orchestration de conteneurs
Compréhension de Docker Compose pour orchestrer plus de 20 conteneurs. Gestion des volumes, des réseaux Docker isolés et du cycle de vie des conteneurs.
Threat Intelligence réelle
Observer de vraies campagnes d'attaque : comprendre les TTPs (Tactiques, Techniques et Procédures) des attaquants, les outils qu'ils utilisent (XMRig, Mirai, scripts bash…) et les cibles privilégiées.
Kibana & analyse de données
Exploitation de la stack ELK pour analyser des volumes importants de logs : création de requêtes KQL, lecture de dashboards préconfigurés et corrélation d'événements entre plusieurs sources.
Sécurité by design
Importance de changer les ports par défaut, désactiver l'authentification par mot de passe SSH, et isoler les services exposés. Ce que l'on voit dans les logs change radicalement la perception du risque.
Surface d'attaque & exposition
Toute IP exposée sur internet est scannée en quelques minutes. Ce projet illustre de manière frappante pourquoi réduire la surface d'attaque, patcher rapidement et surveiller ses logs est non négociable.