Wie ein SSH-Brute-Force-Angriff wirklich aussieht

Der Angriff, ohne Fachjargon

Ein SSH-Brute-Force-Angriff zielt nicht auf Sie. Er ist Massenware: Jemand mietet ein Botnetz, füttert es mit IP-Bereichen und lässt es sich überall anmelden, wo Port 22 antwortet. Die Namensliste ist kurz und langweilig — root, admin, ubuntu, test, git, oracle, postgres und die Dienstkonten, die dieses Jahr gerade verbreitet sind.

Am Laufen hält ihn die Ökonomie. Eine Shell auf einer Linux-Maschine ist Geld wert — zum Mining, als Proxy, als Fuß in der Tür zu allem, was die Maschine erreicht — und ein Versuch kostet praktisch nichts. Stellen Sie einen frischen Server auf eine öffentliche IP: Der erste Scan kommt meist binnen einer Stunde, nach einer Woche sind ein paar tausend Fehlschläge pro Tag unauffällig.

Das Volumen ist der Punkt. Ein Mensch, der Ihr Passwort errät, ist eine Anekdote. Hunderttausend Versuche im Monat von wechselnden Adressen sind eine Grundbedingung, und Maßnahmen für das Erste bewirken beim Zweiten nichts.

Was tatsächlich versucht wird

Drei verschiedene Verhaltensweisen tauchen im selben Protokoll auf, und sie verlangen unterschiedliche Antworten.

Root-Anmeldeversuche sind die lautesten und die ungefährlichsten, denn jeder korrekt konfigurierte Server hat PermitRootLogin auf no oder prohibit-password. Tausende davon am Tag heißen, dass die Bots noch nicht begriffen haben, dass root nicht verfügbar ist — sie begreifen es nie, weil Nachfragen sie nichts kostet.

Als Nächstes kommt die Namensaufzählung: ein Durchlauf durch übliche Kontonamen auf der Suche nach einem, der existiert. In modernem OpenSSH sind die Zeitunterschiede, die das früher zuverlässig machten, weitgehend beseitigt, aber die Bots probieren es trotzdem, und ein Treffer gibt ihnen ein Ziel.

Credential Stuffing ist das, was Erfolg hat. Benutzername-Passwort-Paare aus dem Leak eines anderen, gegen Ihren Server abgespielt. Es sieht nach wenigen Versuchen aus, nicht nach einer Flut, und es funktioniert, wenn ein Entwickler ein Passwort wiederverwendet hat. Kein Rate-Limit fängt es, weil es keine Rate zu begrenzen gibt.

Was SSH bietet, was andere Protokolle nicht haben

SSH hat einen Ausweg, den die meisten exponierten Dienste nicht kennen: Public-Key-Authentifizierung. Schalten Sie die Passwortauthentifizierung ganz ab, und die gesamte Kategorie der Rateangriffe wird nicht schwerer, sondern unmöglich. Es gibt kein Passwort zu erraten.

Das ist wirklich der stärkste verfügbare Einzelschritt, und wenn Sie ihn gehen können, ist alles Weitere in diesem Artikel zweitrangig. Ihm ist ein eigener Guide gewidmet.

Der Verkehr hört dadurch allerdings nicht auf. Die Bots kennen Ihre Konfiguration nicht; sie verbinden sich weiter, bieten weiter Passwörter an und werden weiter abgewiesen. Jeder Versuch kostet nach wie vor eine TCP-Verbindung, einen sshd-Fork, eine Protokollzeile und ein Stück CPU, und Ihr Authentifizierungsprotokoll rotiert weiter schnell genug, um die Ereignisse zu verlieren, die Sie gebraucht hätten. Keys-only entfernt das Risiko. Die Last entfernt es nicht.

Warum Rate-Limiting allein zu kurz greift

Die übliche erste Antwort ist fail2ban, und sie ist vernünftig — es liegt in den Repositories jeder Distribution und es funktioniert. Seine Grenzen sollte man kennen, bevor man sich als Ganzes darauf verlässt.

Es sperrt einzelne Adressen. Botnetze rotieren durch einen Bereich: Sperren Sie 203.0.113.47, startet eine Stunde später .48. Das /24 zu sperren beendet den Durchlauf in einem Zug, und das leistet fail2ban nicht ab Werk.

Seine Sperren laufen ab. Der Standard bemisst sich in Minuten, und dasselbe Botnetz kommt heute Abend wieder. Sie können sie länger setzen, aber der Zustand liegt im Speicher und in einer Datei, die einen Neuaufbau nicht übersteht.

Es lernt von niemandem sonst. Jeder Server entdeckt jeden Angreifer eigenständig, von null, zum Preis der ersten N Versuche jedes Mal.

Und es fällt lautlos aus. Eine Regex, die nach einem Distributionsupgrade nicht mehr passt, ein Jail, das ein Paketupdate deaktiviert hat, ein Dienst, der nach einem Neustart nicht zurückkam — nichts davon kündigt sich an, und der Ausfall sieht genau wie Ruhe aus.

Was den Verkehr tatsächlich senkt

Nur eines ändert das Volumen: sich zu weigern, mit der Quelle zu sprechen. Alles andere verhandelt mit ihr.

Das heißt, den Fehlschlagstrom zu beobachten und eine Quelle, sobald sie eine Schwelle überschreitet, in der Firewall zu verwerfen, bevor sshd irgendetwas für sie aufwendet. Drei Eigenschaften trennen eine Abwehr, die hält, von einer, die leckt:

• Das Subnetz sperren, nicht die Adresse. Angriffsverkehr kommt aus Hosting-Bereichen, in denen Nachbaradressen demselben Betreiber gehören; legitime Nutzer teilen sich fast nie ein /24 mit einem Scanner.
• Dauerhaft sperren und Neustarts überleben. Die Regel muss in nftables liegen und beim Booten wiederhergestellt werden, nicht im Speicher eines Daemons.
• Sich selbst auf die Whitelist setzen, bevor irgendetwas aktiv wird. Der häufigste Weg, das zu vermasseln, ist ein Administrator, der die eigene Adresse von einem Server aussperrt, den er nur über SSH erreicht.

Dasselbe, ohne die Mechanik zu pflegen

SSH Protector ist genau diese Logik als Agent verpackt. Er liest denselben journald- oder auth.log-Strom, den Sie lesen würden, entscheidet lokal — funktioniert also weiter, wenn das Netz ausfällt — und pflegt ein einziges zusammengefasstes nftables-Set mit allen gesperrten Bereichen.

Bei der Installation ermittelt er den echten SSH-Port aus der sshd-Konfiguration, statt 22 anzunehmen, und setzt die Adresse, von der Sie verbunden sind, auf die Whitelist, bevor er irgendetwas blockiert.

Was Sie allein nicht bauen können, ist die geteilte Reputation: Eine Adresse, die einen anderen Kunden angegriffen hat, ist bereits gesperrt, bevor sie Sie erreicht, Sie fangen also ihre ersten N Versuche nie ab. Ein Server ist dauerhaft kostenlos — genug, um einen echten Angriffsstrom auf der eigenen Maschine zu beobachten und nach Belegen zu entscheiden statt nach einem Artikel.