SSH · trafic d'attaque

1234 tentatives de connexion en 41 heures : qui cogne vraiment sur un port SSH exposé

2026-07-19 · HardStacked · 7 min de lecture

Voici une box que personne n'est censé connaître. Une IP fraîche d'un fournisseur cloud, pas d'enregistrement DNS, aucun lien qui pointe dessus, rien de publié nulle part. Une de nos machines de test ordinaires, en ligne depuis quelques jours. On a tiré ses logs SSH le 20 juillet 2026, couvrant environ 41 heures, et on a compté ce qui cognait.

1234 tentatives de connexion, toutes sur des comptes qui n'existent pas. 93 adresses IP distinctes. 132 noms d'usagers différents. De l'activité à chaque heure de la journée. Ce n'est pas une étude de honeypot avec un appât : la box s'authentifie par clé seulement, et nos propres connexions sont exclues de chaque compte ci-dessous. C'est juste le bruit ambiant d'internet, mesuré.

1. Personne ne connaissait ce serveur. Ils l'ont trouvé pareil

Les 93 adresses s'étalent sur 61 réseaux /16 distincts, environ 1,5 adresse par réseau. Cette dispersion est une signature : ce n'est pas un attaquant qui réessaie de chez lui, c'est un botnet réparti à travers le monde, chaque membre sondant une tranche de l'espace d'adresses.

La géolocalisation place les adresses derrière les tentatives de connexion dans dix pays sur quatre continents. La plus insistante, enregistrée en Iran, a cogné 373 fois à elle seule ; la Chine, la Roumanie, les États-Unis et la Bulgarie complètent le top 5. Et cette carte montre où sont les machines infectées, pas où se trouve leur opérateur.

Rien n'a « fuité » le serveur. Il n'y avait rien à fuiter. L'espace IPv4 est assez petit pour être balayé industriellement, et ces gangs le balaient au complet, tout le temps. Ton adresse est dans l'espace, donc ton adresse est sur la liste. C'est toute la logique de ciblage.

2. Le bestiaire des usernames : 132 noms, quatre familles de proies

L'artéfact le plus intéressant des logs, c'est la liste des noms d'usagers essayés. 132 noms distincts en 41 heures, et ça se lit comme un inventaire de tout ce qui se branche sur internet :

Trie la liste complète en familles et la liste d'épicerie du botnet apparaît :

• Serveurs et services : postgres, mysql, oracle, apache, ftpuser. Des comptes de service qui ne devraient jamais accepter une connexion en premier lieu.
• La chaîne DevOps : ansible, deploy, dev, developer. Celle-là mérite une pause : un compte ansible ou deploy est rarement une curiosité, c'est le compte qui tient les clés de toutes les autres machines. Douze tentatives sur ansible, dix sur deploy, sur une box qui n'a ni l'un ni l'autre.
• L'équipement d'usine : ubnt (Ubiquiti), AdminGPON et telecomadmin (boîtiers fibre), cusadmin (modems câble), huawei. Ce ne sont pas des comptes de serveur du tout : ce sont les logins intégrés des routeurs, des terminaux optiques et des caméras.
• Les ordinateurs mono-carte : pi, orangepi. On y revient plus bas.

3. Oui, ils chassent aussi les Raspberry Pi

Sept tentatives sur pi, cinq sur orangepi, six sur ubnt, cinq sur AdminGPON. Le même gang qui sonde pour des serveurs PostgreSQL sonde aussi pour ton modem fibre et ton Raspberry Pi, dans la même passe, avec le même outillage. Ils ne cherchent pas « un serveur Linux » : ils ratissent tout ce qui a une adresse, avec les noms de comptes par défaut que les appareils ont en sortant de la boîte.

Pendant des années, le défaut sur un Raspberry Pi, c'était le compte pi avec un mot de passe bien connu, et chaque dictionnaire de botnet s'en souvient encore. Si un Pi à la maison est port-forwardé pour que tu le rejoignes à distance, il reçoit exactement ce trafic, avec une marge de sécurité plus mince qu'un serveur : personne ne surveille les logs d'un Pi.

4. Ça n'arrête jamais. Jamais

819 tentatives sur des comptes inexistants le premier jour complet, 402 le suivant. Et étalées, pas en rafales : chaque heure de la journée a vu de l'activité, l'heure la plus tranquille loggant encore autour de sept tentatives. Il n'y a pas de fenêtre calme, pas de fuseau horaire où le botnet dort, pas de motif autour duquel tu pourrais t'organiser.

Par-dessus les tentatives de connexion, plus d'un millier de connexions se sont ouvertes et refermées sans jamais essayer un compte. C'est la partie plus silencieuse de la machinerie : des lectures de bannière et des scans de version, la passe d'inventaire qui décide quelles portes vaudront la peine d'être poussées plus tard.

Mille lignes Invalid user, c'est un mardi ordinaire. Un seul Accepted que tu ne reconnais pas, c'est un incident.

5. Le plus beau zéro du log

Un compteur est resté à zéro à travers tout ça :

La box roule PasswordAuthentication no. Avec l'auth par clé seulement, sshd rejette ces clients avant qu'un mot de passe soit même échangé : l'engin de devinette, les dictionnaires, les réessais, tout ça frappe une porte sans trou de serrure. Les mêmes 41 heures contre une box avec mot de passe activé auraient produit plus de mille lignes Failed password, chacune une vraie devinette contre ta vraie politique de mots de passe.

Une limite honnête de ces données : sshd ne loggue jamais quels mots de passe ont été essayés, peu importe la configuration. Capturer ça demande un vrai honeypot comme Cowrie, ce qui est une autre expérience, pour un autre article.

Ce que ce bruit te dit

Tout ce qui précède est un décompte tiré du journal d'une seule machine, du 18 au 20 juillet 2026. Tes logs vont différer en volume, jamais en nature : le trafic est automatique, indiscriminé et permanent, parce qu'il ne coûte rien aux opérateurs et qu'il paie de temps en temps. La question qu'un propriétaire de serveur doit se poser, ce n'est pas « est-ce que je vais me faire sonder ». Tu te fais sonder en ce moment même. La question, c'est si la configuration tient la nuit où personne ne regarde les logs.