Ich bin gelinde gesagt etwas schockiert über die SSH-Login-Versuche aus dem Internet!

[SierraX]

Nicht, weil sie überhaupt existieren oder wegen der schieren Menge; das beobachte ich mit meinem Splunk-Server ja mittlerweile schon seit einigen Jahren. Zuerst über die jeweiligen Security-Logs, wo ich die IPs und Namen mitgeschnitten habe, wenn ein Login-Versuch wie erwartet fehlschlug.

Ich sehe aber seit gestern, wie bodenlos schlecht wohl deren Passwortlisten sind!

Da ich gerade mehr als genug Zeit habe, dachte ich mir so: Mal gucken, ob das, was ich für meine beiden Server — einer in Karlsruhe und ein kleiner bei OpenBSD.ams — schon lange beobachte, auch für mein Heimnetzwerk gilt. Da ich dieses sowieso gerade umbaue — ISP-Router und Maschinen, die direkt daran hängen, werden zu einer Art DMZ und das Intranet wird durch einen OpenBSD-Router von diesem getrennt. Also habe ich mir eine VM mit FreeBSD 14 aufgesetzt, weil es noch keinen Splunk Forwarder für FreeBSD 15 gibt, und nach dem gescheiterten Versuch, mit Python einen SSH-Honeypot zu bauen, etwas mit sshesame herumgespielt.
Der Login-Versuch kommt jetzt ganz normal auf Port 22 an und wird auf Port 10022 durch die Firewalls an den Honeypot weitergeleitet. Weil mir die Datenmenge zu gering ist, habe ich kurzerhand meinen Server in Karlsruhe auch noch von den Security-Logs auf Honeypot umgezogen.
Der erfasst Uhrzeit, IP, Port, User und Passwort. Und die Passwörter sind FÜRCHTERLICH.

Man nimmt am besten root, r00t und admin* für eine Auswertung raus. Die machen ~70 % der Usernamen aus, ~60 % alleine root, und versauen einem sämtliche Statistiken. Auch weil überwiegend die gleichen Passwörter halt auch unter diesen Usern verwendet werden.
Dabei ist eins, was man als 1337-Haxxor lernen sollte, dass kein Admin mit nur ein wenig Sachverstand PermitRootLogin dauerhaft auf ja statt nein oder prohibit-password setzt.
Username gleich Passwort, bekannt vom Initialpasswort bei z. B. Ubuntu, wenn man es, glaube ich, von der Live-Umgebung installiert. Bei diesen Systemen muss man den SSH-Server aber eh selber nachinstallieren oder wissentlich in Betrieb nehmen. Also auch erstmal rausgeflogen, da sonst wahrscheinlich zehn bis zwanzig der Top 50 nur so Sachen wie debian:debian, zabbix:zabbix und so weiter wären.
Gut, es läuft jetzt gerade mal zwei Tage, aber pi:raspberry ist auf Platz 1, rly? Das gilt nur für RasPi-OS-Versionen, die älter als 4 Jahre sind. Dann dieser Zahlenreihen-Fetisch … wer macht denn sowas? Halten die Linux-/Unix-User allesamt für bescheuert?

Wenns hier Interesse an vollständigen Listen usernameassword als .csv gibt, gebt gerne Bescheid. ChatGPT mit etwa 1000 solcher Paare zu füttern und dazu fragen zu stellen war recht interessant… mit 20000 solcher Paare muss ich das auch noch ausprobieren ;-)

 

[marzl]

Danke für die Analyse, sehr interessant.
Seit ich auf meinen Servern den Port 22 auf etwas anderes zufälliges gesetzt habe, ist dieses Grundrauschen immerhin weg.

 

[medV2]

Gut, es läuft jetzt gerade mal zwei Tage, aber pi:raspberry ist auf Platz 1, rly? Das gilt nur für RasPi-OS-Versionen, die älter als 4 Jahre sind. Dann dieser Zahlenreihen-Fetisch … wer macht denn sowas? Halten die Linux-/Unix-User allesamt für bescheuert?

Ich befürchte die machen das, weil genug Menschen bescheuert sind. Immerhin kostet das Zeit und Geld, das würde nicht gemacht werden, hätte es keinen Erfolg. In meinem Bekanntenkreis sehe ich auch immer wieder Passwörter, wo ich die Händer vors Gesicht (der Person am besten) schlagen möchte.

Auch unabhängige Sicherheitsforscher, die immer mal wieder so Top-Passwortlisten raushauen, kommen ja immer wieder zu dem Schluss. Da steht dann password und 123456 an den ersten Stellen..

Und gerade ist die Situation ja gerade besonders heiß, mit dem User hat man vermutlich direkt den Rootzugriff (CVE-2026-31431).

 

[Azazyel]

Danke für die Analyse, sehr interessant.

Dem kann ich mich nur anschließen.

Seit ich auf meinen Servern den Port 22 auf etwas anderes zufälliges gesetzt habe, ist dieses Grundrauschen immerhin weg.

Dito; ich habe praktisch alles im Heimnetzwerk auf Non-Standard-Ports gelegt (nur Port 80 und 443 sind wegen Let's Encrypt erreichbar). Seitdem herrscht absolute Ruhe in den Logs.

Ich befürchte die machen das, weil genug Menschen bescheuert sind. Immerhin kostet das Zeit und Geld, das würde nicht gemacht werden, hätte es keinen Erfolg.

Ähnlich wie bei Spam-E-Mails ist der Aufwand gering genug, dass auch eine lächerliche geringe Erfolgsquote genug Geld einbringt. Wie viele Webserver dort draußen wohl gelangweilt Webseiten ausliefern, während im Hintergrund ein Bitcoin-Miner anderen Leuten Geld verdient...

Und gerade ist die Situation ja gerade besonders heiß, mit dem User hat man vermutlich direkt den Rootzugriff (CVE-2026-31431).

Die Vermutung liegt nahe, dass Leute mit Passwörtern wie 123456 auch an anderer Stelle schlampen.

Die Passwörter sind aber nur ein Problem in der Gleichung. Mit Ansätzen wie ich aktualisiere nur quartalsweise meine Systeme oder ich bin stolz auf 700 Tage Uptime oder anderen Patch-Strategien aus dem vergangenen Jahrtausend kann man aber auch abseits schlechter Passwörter sein System vorsätzlich gegen die Wand fahren.

 

[SierraX]

Seit ich auf meinen Servern den Port 22 auf etwas anderes zufälliges gesetzt habe, ist dieses Grundrauschen immerhin weg.

ist so ne Art Berufskrankheit unter den Splunkern. Wir wollen das Grundrauschen garnicht unbedingt loswerden, sondern gucken was da drin ist und was man daraus lesen und damit machen kann.
Das verlegen des Ports auf was zufälliges, dass nicht auf SSH schliessen lässt, was ich für meinen Karlsruher Server auch gemacht habe, ist eine effektive Methode.
Was aber auch zu Problemen führen kann. Ist man nicht der einzige der auf den Server zugreifen muss, muss der Port kommuniziert werden. Bei Firmen-Netzwerken kann eine Firewall für alle Ausgangs-Ports ausser 20,21,22, 80 und 443 erstmal geblockt sein. Oft ist selbst der Port 22 von Haus aus dicht… da kann man aber gegenüber dem Security Team leicht verargumentieren warum man den jetzt offen für eine bestimmte IP oder alle braucht.
Fail2Ban oder der Port 22 als "Opfer-Anode" während SSH (zusätzlich noch) auf einen anderen Port horcht, sind auch effektive Taktiken.

Ich befürchte die machen das, weil genug Menschen bescheuert sind. Immerhin kostet das Zeit und Geld, das würde nicht gemacht werden, hätte es keinen Erfolg. In meinem Bekanntenkreis sehe ich auch immer wieder Passwörter, wo ich die Händer vors Gesicht (der Person am besten) schlagen möchte.

Der Zeit und Geld Aufwand dürfte minimal sein. So ein Script ist relativ leicht geschrieben. Kann x1000 fach auf einem Rechner laufen (hat man da doch theoretisch so um die 63000 Ports für die Antworten frei). Auch ist das Internet nicht überall so teuer wie in Deutschland.
Über dass was da so teilweise aus Passwort Datenbanken für Online Accounts gezogen sieht braucht man eigentlich nicht zu sprechen. Wer das als Account Passwort verwendet und dadurch einen Security Issue bei seinem Arbeitgeber auslöst, gehört dann zurecht entlassen und verklagt.

Auch unabhängige Sicherheitsforscher, die immer mal wieder so Top-Passwortlisten raushauen, kommen ja immer wieder zu dem Schluss. Da steht dann password und 123456 an den ersten Stellen..

Ich bin da skeptisch, ob das nicht sehr stark von einem Zirkelschluss beeinflusst wird. Also dass Angreifer die Passwörter verwenden weil sie auf einer Top-Passwortliste von Sicherheitsforschern stehen, und Sicherheitsforscher die Passwörter in Top-Passwortlisten aufnehmen, weil Angreifer diese benutzen.
Ein wenig könnten auch Honeypots selbst daran Schuld sein, wenn ein solches Passwort in den Listen verbleibt:
Auch wenn ich nur die Passwörter mitschneide, bietet sshesame auch die Möglichkeit einen erfolgreichen Login zu simulieren um mitzuschneiden was für Befehle versucht werden. Und das bei der Verwendung egal welcher credentials. Ich kann mir schon vorstellen, dass man für einen professionellen Honeypot dann ein leichtes von so einer Liste nimmt um sicher zu stellen, dass der Angreifer auch rein kommt. Diese werden dann ebenfalls als funktionierend gekennzeichnet, obwohl sie mit der gelebten Realität recht wenig zu tun haben.

Versucht mal bei eurem nächsten erzwungenen Passwort-Change eurer Firma, eins von diesen Top 20 Passwörtern zu verwenden… Ich übernehme aber keine Haftung, wenn der Admin euch komische Fragen stellt oder gleich an die Geschäftsleitung meldet.
eine meiner letzten Kunden oder Arbeitgeber, verlangte bereits eine Mindestlänge von 16 Zeichen für login accounts von MFA um überhaupt erstmal auf eine Terminal das mit diesem Netzwerk verbunden ist zu kommen, ganz zu schweigen (CyberArk+Citrix ). Bei mir wurde auf einer Webseite schon mal ein Passwort abgelehnt, weil ich ein "eu" im Passwort hatte, und das auch Teil meines Logins war.

Und gerade ist die Situation ja gerade besonders heiß, mit dem User hat man vermutlich direkt den Rootzugriff (CVE-2026-31431).

Soll auch eine von KI gefundene Sicherheitslücke sein, also nichts on the wild. Es gibt ein Video von Hood Informatik wo das erklärt wird. Mit Admins die ihre Systeme im Internet nicht entsprechend sichern und Up-to-date halten, hab ich relativ wenig Mitleid.

 

[medV2]

Soll auch eine von KI gefundene Sicherheitslücke sein, also nichts on the wild. Es gibt ein Video von Hood Informatik wo das erklärt wird. Mit Admins die ihre Systeme im Internet nicht entsprechend sichern und Up-to-date halten, hab ich relativ wenig Mitleid.

Für sorgsame Admins kein Problem, und Mitleid hab ich auch nicht. Dennoch hat es gedauert (3 Tage Debian, 5 Tage RHEL um mal die größeren zu nennen) bis Updates alleine ausgereicht hätten. Um ab dem Tag, an dem der Exploit verfügbar war, geschützt zu sein, musste man schon selbst aktiv werden und die Mitigationsschritte der Distros beachten. Sofern man vom Bedrohungsszenario betroffen war. Ich würde wetten, das hat einige getroffen. Aber anderes Thema

 

[SierraX]

Ich weiss ja nicht wie IDS Systeme arbeiten, vielleicht machen die genau das was ich jetzt so jedem Admin mal empfehlen würde, wenn er mit der Wartung eines SSH System, das Passwort logins erlauben muss, betraut ist: Wenn noch keine Password-policy gibt sorge für eine Einführung. Filtere eine Passwortliste auf diese policy, und greife jeden Account für den du kein Passwort irgendwo gespeichert hast, mit diesem Passwort an.
Dass man die gespeicherten Passwörter und auch User mal mit dieser Liste überprüfen sollte versteht sich von selbst.

Hmm vielleicht mach ich da was mit gitlab

 

[SolarCatcher]

Ich setze auf Port 22 immer endlessh und die echten SSH-Server auf etwas anderes. Fail2ban schneidet dann diesen massenhaften Login-Traffic zumindest zu den FreeBSD-Jails ab. Der SSH-Server auf dem Host bleibt aber immer erreichbar, weil ich keine Lust habe, selbst einmal ausgesperrt zu werden.

 

[SierraX]

Ich setze auf Port 22 immer endlessh und die echten SSH-Server auf etwas anderes. Fail2ban schneidet dann diesen massenhaften Login-Traffic zumindest zu den FreeBSD-Jails ab. Der SSH-Server auf dem Host bleibt aber immer erreichbar, weil ich keine Lust habe, selbst einmal ausgesperrt zu werden.

Guter Punkt. Es gibt glaube draussen immer noch Hosting-Provider die keine anständige Möglichkeit zur Verwaltung bereitstellen … bei denen sollte man wissen worauf man sich ggf. einlässt… Damals bei Euserv war man Stunden lang mit irgendwelchen Live-Systemen beschäftigt wen man irgendwas abgeschossen hatte. Bei meinem jetzigen Anbieter hab ich wenigstens eine Virtuelle Konsole

 

[gadean]

Wobei ein alternativer Port auch nur zeitweise hilft*, bei mir tauchen seit Januar immer mehr Loginversuche auf.
Vorher waren es immer nur einfache Portscans, aber jetzt scheinen einige zu wissen, dass unter meiner IP der Port woanders ist

Muss den Port wohl mal wechseln und bei der Gelegenheit schau ich mir endlessh an
Gibt es auch in den Ports: net/endlessh

* "hilft" im Sinne von: unnötige Loginversuche unterbinden/Logs zu reduzieren

 

[SierraX]

Wobei ein alternativer Port auch nur zeitweise hilft*, bei mir tauchen seit Januar immer mehr Loginversuche auf.
Vorher waren es immer nur einfache Portscans, aber jetzt scheinen einige zu wissen, dass unter meiner IP der Port woanders ist

Ich kann mir vorstellen, dass eine reihe von Ports durch ihre "(psycho)logische Nähe" exponiert sind. Gerade wenn der Port 22 geschlossen ist (dass meinte ich mit offen halten als "Opfer Anode".
2222 sieht man immer wieder mal in irgendwelchen Anleitungen. 2022 leicht zu merken, 8022 leicht zu merken wenn man einen Webserver betreibt, eigentlich alles was irgendwie die 22 drin hat, . 1234 sieht man auch immer wieder mal als Port der einfach zu merken ist für alles mögliche. Dass was ich jetzt auf meinem Splunk-Server für SSH verwende würde logisch eher auf einen anderen Standard Dienst deutet.
Gemini meinte das gleiche und dass man wohl am besten einen Port über 40000 verwenden sollte.
endlessh ist eine nette Idee, würde ich wohl auch machen wenn ich die Infos nicht explizit abgreifen wollen würde. btw: https://gitlab.com/SierraX/honeypot-catch : muss es noch automatisieren, aber 30k Login versuche für Leute die selbst ein wenig analysieren wollen ohne selber einen Honeypot aufzusetzen und "OVER 9000" User Password Paare sind schon mal ein Anfang ;-)

 

[bsd4me]

Danke für die Analyse, sehr interessant.
Seit ich auf meinen Servern den Port 22 auf etwas anderes zufälliges gesetzt habe, ist dieses Grundrauschen immerhin weg.

das habe ich auch vor Jahren gemacht - den ssh port woanders hingelegt - und viele Versuche sind nicht mehr da :-)