Mettre en place un honeypot SSH conteneurisé et exploiter ses logs d’attaques
Introduction
Un honeypot SSH est un faux serveur SSH exposé volontairement sur Internet pour attirer et enregistrer les tentatives d’intrusion automatisées (bots, scanners). Ce guide détaille le déploiement de gopot sur un Jetson Orin Nano via Docker.
Installation
Afin d’installer ce honeypot voici les pré-requis :
- Système Linux
- Docker
- Une IP publique IPv4
Séparer le vrai SSH du honeypot
Si vous utilisez deja le port 22 pour sshd, les deux services ne peuvent pas cohabiter sur le même port. On doit donc migrer sshd vers un autre port. Ici par exemple le port 2022.
# /etc/ssh/sshd_config
Port 2022
sudo systemctl restart ssh
Docker configuration
gopot est conteunerisé avec Docker, vous trouverez dans le dépôt Git un Dockerfile ainsi qu’un docker-compose.yml.
Vous pouvez modifier ces fichiers si vous souhaitez changer le port utilisé dans le container ou encore ajuster les ressources alloués au honeypot.
Points important :
"22:2223": le port 22 de l’hôte est redirigé vers le port interne du honeypotgopot.tomlet host_key montés en lecture seule- La base de données SQLite persiste dans un named volume
cap_drop: ALLet no-new-privileges limitent la surface d’attaque- Rotation des logs pour éviter de saturer le disque
Génerer la clé SSH
Il est nécessaire de générer une clé persistante entre les redémarrages.
ssh-keygen -t ed25519 -f ./host_key -N ""
chmod 644 ./host_key # lisible par l'utilisateur non-root du conteneur
Déployer
docker compose up -d --build
docker compose logs -f
Voilà ! Maintenant votre honeypot SSH est actif sur le port 22 et est prêt à logger chaque tentative de connexion et chaque session. Il faut attendre quelques heures avant de voir les premiers bots arriver.
Résultats
Le honeypot a tourné du 9 au 15 mai 2026, soit une semaine d’exposition directe. Sur cette fenêtre, gopot a enregistré 1 047 tentatives d’authentification réparties sur 135 sessions provenant de 80 adresses IP distinctes. Fait notable : seulement 3 commandes ont été exécutées au total une fois la session ouverte, toutes des whoami.
Tentatives d'authentification par jour
Données : 9 mai 16, 10 mai 78, 11 mai 220, 12 mai 115, 13 mai 205, 14 mai 341, 15 mai 72.
Identifiants les plus visés
Données : support 482, root 213, admin 148, user 41, test 12, orangepi 10, ubnt 6, config 6.
Répartition des clients SSH
Données : SSH-2.0-Go 109, libssh_0.7.4 22, russh_0.51.1 2, OpenSSH_for_Windows_9.5 1, OpenSSH_9.8 1.
Ce que disent ces chiffres
Les sessions durent une fraction de seconde et n’enchaînent presque jamais de commande après l’authentification (3 commandes pour 135 sessions). Les bannières clientes confirment l’automatisation : 109 sessions identifiées s’annoncent en SSH-2.0-Go, soit plus de 80 % des clients reconnus, le reste se partageant entre libssh et russh. À noter : gopot accepte volontairement la quasi-totalité des connexions, ce qui explique le taux de succès de 86 % affiché. Ce chiffre ne traduit donc aucune compromission, c’est le comportement attendu du honeypot qui cherche à enregistrer un maximum d’interactions.
Loin d’une foule d’attaquants variés, le volume est très concentré : 87.251.64.176 génère à elle seule 460 tentatives, soit 44 % du total, et les trois IP les plus actives cumulent 52 % du trafic. Cette signature, où une même source martèle le service avec un dictionnaire identique, est caractéristique d’un botnet coordonné plutôt que d’intrusions ciblées et indépendantes.
Le palmarès des identifiants tentés ne vise pas des serveurs classiques mais des équipements grand public et embarqués : support arrive largement en tête (482 tentatives), suivi de comptes par défaut typiques de box, caméras et cartes ARM comme orangepi, ubnt, config ou system. Ces dictionnaires sont taillés pour des firmwares laissés avec leurs identifiants d’usine, cible privilégiée pour grossir les rangs d’un botnet.