Un honeypot SSH, c’est un faux serveur exposé sur Internet pour observer ce que font les attaquants une fois connectés. Pendant plusieurs mois en 2021–2022, j’en ai fait tourner un avec Cowrie : un faux serveur Debian qui laisse « entrer » les bots en root et enregistre chaque frappe de clavier dans des journaux TTY. Les premières tentatives de connexion arrivent en quelques minutes.
Voici huit sessions réelles tirées de ces journaux, rejouées à la frappe près, avec le décodage de ce que chaque attaquant cherchait à faire. Choisissez un spécimen, lancez la lecture.
Ouvrir le bestiaire en plein écran (plus confortable sur mobile).
Les 8 spécimens du honeypot SSH en un coup d’œil
| Spécimen | Famille | Ce qu’il fait | Durée |
|---|---|---|---|
| Le faux « systemd » | Mineur | Télécharge XMRig renommé « systemd », mine du Monero, installe zmap pour scanner la suite d’Internet | 57 s |
| Le voleur de clés | Backdoor | Vole /etc/shadow, plante une clé SSH déguisée en image JPEG, rend le compte daemon sudo sans mot de passe | 9 s |
| L’essaim multi-architecture | Ver / botnet | Lâche le même malware compilé pour 6 processeurs (x86, ARM, MIPS…) et les lance tous | 16 s |
| Le tueur de mineurs | Mineur | Change le mot de passe root, tue 7 mineurs concurrents, installe C3Pool puis efface l’historique | 22 s |
| Le planteur de clés | Backdoor | Remplace le dossier .ssh par sa clé RSA, cherche un dossier exécutable, lance un scanner SSH | 62 s |
| Le bruteforceur RDP | Humain | Fautes de frappe à l’appui, installe un outil de brute-force RDP contre une plage d’adresses | 120 s |
| Le mineur sans mineur | Mineur | Colle une commande xmrig… sans avoir installé xmrig. Échec total | 66 s |
| L’éclaireur | Reconnaissance | Mesure RAM et CPU, flaire l’émulation, échoue à lancer son binaire et abandonne | 56 s |
Ce que révèle le honeypot SSH
Quatre ans plus tard, les familles d’attaques restent les mêmes. La plupart des sessions durent moins d’une minute : ce sont des scripts, pas des humains. On retrouve :
- Le cryptominage (XMRig, C3Pool) : l’objectif le plus fréquent. Le mineur est souvent renommé (« systemd ») pour passer inaperçu, et certains bots commencent par tuer les mineurs concurrents.
- La persistance : clé SSH plantée dans
authorized_keys, compte système (daemon) promu sudo sans mot de passe, mot de passe root changé pour verrouiller la place. - La propagation : la machine compromise devient à son tour un scanner (zmap, scanners SSH ou RDP) qui cherche la prochaine victime — c’est ainsi que les botnets grossissent.
- Les ratés : une bonne partie des sessions échouent bêtement — mineur jamais installé, binaire pour la mauvaise architecture, humain qui se trompe de commande. C’est le bruit de fond d’Internet.
Comment fonctionne un honeypot SSH comme Cowrie
Cowrie est un honeypot SSH et Telnet open source dit « à interaction moyenne ». Il accepte certains couples identifiant / mot de passe, puis présente un shell Linux simulé avec un faux système de fichiers : les commandes courantes (uname, cat, wget, curl…) répondent de façon crédible, mais rien ne s’exécute réellement sur la machine hôte.
Chaque session est enregistrée : identifiants essayés, commandes tapées, fichiers téléchargés. C’est ce qui permet de rejouer ici les attaques à l’identique. Les attaquants les plus prudents détectent parfois l’émulation — c’est ce que fait « l’éclaireur » — mais l’immense majorité des bots ne vérifie rien.
Si vous voulez en déployer un : isolez-le complètement de votre production (VM ou VPS dédié, aucune donnée réelle, trafic sortant filtré) et déplacez votre vrai SSH sur un autre port avant de laisser Cowrie écouter sur le port 22.
Comment protéger son serveur SSH
Tous les spécimens de ce bestiaire sont entrés de la même façon : un mot de passe root deviné par brute-force. Les mesures qui les auraient arrêtés :
- Désactiver l’authentification par mot de passe (
PasswordAuthentication no,PermitRootLogin prohibit-passwordouno) et n’utiliser que des clés SSH. Attention aux fichiers desshd_config.d/(cloud-init notamment) qui peuvent écraser votre réglage : vérifiez avecsshd -T | grep -i passwordauth. - Bannir automatiquement les sources de brute-force avec fail2ban ou CrowdSec, derrière un pare-feu restrictif (voir la partie sécurisation de mon guide Pangolin sur Debian, qui couvre UFW et Fail2ban).
- Surveiller les fichiers sensibles :
~/.ssh/authorized_keys,/etc/sudoersetsudoers.d/, le shell des comptes système dans/etc/passwd. - Monter
/tmp,/var/tmpet/dev/shmennoexec: c’est là que presque tous ces bots déposent leurs binaires. - Alerter sur un CPU bloqué à 100 % et sur les connexions sortantes vers des pools de minage — le symptôme le plus visible d’une compromission.
- Filtrer le trafic sortant d’un serveur qui n’a pas besoin de télécharger depuis n’importe où : la plupart des attaques ci-dessus s’arrêtent au premier
wget.
Questions fréquentes
Combien de temps faut-il pour qu’un serveur SSH soit attaqué ?
Quelques minutes. Des scanners balaient en permanence tout l’espace IPv4 sur le port 22 ; un serveur fraîchement exposé reçoit ses premières tentatives de connexion presque immédiatement, puis des milliers par jour.
Que fait un bot après avoir piraté un serveur SSH ?
Dans l’ordre le plus fréquent : vérifier qu’il est root, installer un accès persistant (clé SSH, compte sudo), lancer un mineur de cryptomonnaie, puis transformer la machine en scanner pour infecter d’autres serveurs. Le tout en général en moins d’une minute.
Comment savoir si mon serveur mine du Monero à mon insu ?
Les signes typiques : un CPU proche de 100 % en permanence, un processus au nom anodin (« systemd », « kworker ») lancé depuis /tmp ou /dev/shm, des connexions sortantes vers des ports 443 ou 3333 de pools de minage, et des clés inconnues dans authorized_keys. En cas de doute, considérez la machine comme compromise et réinstallez-la.
Pour aller plus loin
- Installer et sécuriser Pangolin sur Debian — pare-feu UFW et Fail2ban pas à pas.
- Copy Fail (CVE-2026-31431) — quand un accès local suffit à devenir root.
- Nuclei, le scanner de vulnérabilités — auditer ses propres services exposés.
- Cowrie sur GitHub — le honeypot utilisé pour ces captures.
À propos des données
Contenu publié à des fins pédagogiques et défensives. Les commandes, adresses IP, URL et portefeuilles Monero sont reproduits tels quels depuis les journaux du honeypot (2021–2022). Les adresses IP correspondent le plus souvent à des machines elles-mêmes compromises ou à des VPS loués à la volée, très probablement réattribués depuis : elles ne désignent pas les auteurs et ne doivent pas servir à cibler qui que ce soit. Le nom d’un site légitime piraté pour héberger des charges a été masqué. N’exécutez aucune des commandes présentées.