SSH-Brute-Force 2007: Mit hashlimit gegen Skript-Angriffe

Zusammenfassung

Anfang 2007 probierten automatisierte Skripte bis zu 15.000 Kennwörter am Tag gegen meinen SSH-Zugang, und in einer Nacht kamen über 1.500 Anmeldeversuche gegen den POP3-Server dazu. Statt der üblichen Rezepte mit limit oder recent habe ich das iptables-Modul hashlimit verwendet, das neue Verbindungen je Quelladresse begrenzt, ohne mich selbst auszusperren. Dieser Beitrag aus meinem alten Blog zeigt die Regeln von damals und was nftables, fail2ban und OpenSSH heute von sich aus mitbringen.

15.000 Versuche am Tag

Lange habe ich den Skript-Kiddies einfach zugesehen, wie sie ihre Kennwortlisten gegen meinen Server ausprobierten, in der Spitze 15.000 Versuche am Tag. Ohne Erfolg: SSH ließ nur Anmeldungen mit öffentlichem Schlüssel zu. Die Fehlermeldung „publickey required“ war für die dummen Bash-Skripte aber offenbar nicht deutlich genug, sie machten einfach weiter. Die Logs liefen voll, und jede Verbindung kostete Rechenzeit.

Warum nicht limit oder recent

Im Netz fanden sich damals vor allem zwei Rezepte. Das Modul limit begrenzt die Rate für alle Absender zusammen: Ein Angreifer verbraucht das Kontingent, und der Admin kommt selbst nicht mehr herein. Das Modul recent merkt sich Adressen und sperrt sie nach zu vielen Versuchen, ist aber schnell so eingestellt, dass man sich mit ein paar schnellen scp-Aufrufen selbst aussperrt.

hashlimit verbindet beides: Es führt für jede Quelladresse einen eigenen Zähler mit eigener Rate und eigenem Spielraum. Ein Angreifer bremst nur sich selbst, alle anderen merken nichts.

Die Regeln

Diese Zeilen aus meinem Firewall-Skript erlaubten SSH aus dem Internet, aber je Adresse nur zwei neue Verbindungen am Stück und danach eine pro Stunde:

# ssh aus dem Internet erlauben, Brute Force aber verbieten (hashlimit)
$iptables -A INPUT -i eth0 -p tcp -d $ip_eth0 --dport 22 \
  -m hashlimit --hashlimit 1/hour --hashlimit-mode srcip \
  --hashlimit-name ssh --hashlimit-burst 2 \
  -m state --state NEW -j ACCEPT

Gezählt werden nur neue Verbindungen; bestehende laufen über eine eigene Regel für ESTABLISHED weiter. Eine Stunde pro Verbindung klingt streng, für einen Server mit Schlüsselanmeldung reichte es aber: Wer arbeitet, bleibt verbunden; wer rät, braucht eine neue Verbindung pro Versuch.

Dieselbe Nacht, ein anderer Dienst

Am selben Tag sah ich in den Logs des Mailservers den nächsten Angriff, diesmal gegen POP3. Ein einziger Rechner probierte in einer Nacht 106 verschiedene Benutzernamen, von admin, administrator und test mit je 32 Versuchen bis zu Vornamen wie alex oder andrea, insgesamt 1.532 Anmeldungen. Die Antwort war dieselbe Technik mit großzügigeren Werten, denn Mailprogramme holen öfter ab als ein Admin sich anmeldet:

# pop3 aus dem Internet erlauben, Brute Force aber verbieten (hashlimit)
$iptables -A INPUT -i eth0 -p tcp -d $ip_eth0 --dport 110 \
  -m hashlimit --hashlimit 2/minute --hashlimit-mode srcip \
  --hashlimit-name pop3 --hashlimit-burst 3 \
  -m state --state NEW -j ACCEPT

IMAP-Verbindungen bekamen eine ähnliche Regel.

Was sich seitdem geändert hat

Die Idee ist dieselbe geblieben, die Werkzeuge haben sich geändert. iptables ist auf den meisten Systemen durch nftables ersetzt; dort übernimmt ein Meter oder ein dynamisches Set mit Rate je Adresse die Rolle von hashlimit. Statt -m state schreibt man ct state. Eine Regel mit drei neuen Verbindungen pro Minute und Adresse sieht so aus:

tcp dport 22 ct state new \
  meter ssh-rate { ip saddr limit rate 3/minute } accept
tcp dport 22 ct state new drop

Wer nach Log-Einträgen statt nach Verbindungen sperren möchte, nimmt fail2ban. Und seit OpenSSH 9.8 von 2024 bremst sshd selbst: Die Einstellung PerSourcePenalties ist standardmäßig an und sperrt Adressen zeitweise, die wiederholt an der Anmeldung scheitern oder Verbindungen ohne Anmeldung offen lassen. Wer viele Nutzer hinter einer gemeinsamen NAT-Adresse hat, sollte die Werte prüfen.

Geblieben ist auch die wichtigste Maßnahme von damals: Anmeldung nur mit Schlüssel. Dann sind Brute-Force-Angriffe lästig, aber nicht gefährlich. Und wer streng drosselt, sollte die SSH-Multiplexing-Funktion ControlMaster kennen; sie bündelt mehrere Sitzungen in einer Verbindung, sodass man selbst nicht in die eigene Bremse läuft.

Zahlen im Überblick

• In der Spitze 15.000 SSH-Anmeldeversuche pro Tag, obwohl nur Schlüsselanmeldung erlaubt war.
• Der POP3-Angriff: ein Absender, 106 Benutzernamen, 1.532 Versuche in einer Nacht.
• SSH-Regel: zwei neue Verbindungen am Stück, danach eine pro Stunde je Quelladresse; POP3: drei am Stück, danach zwei pro Minute.
• OpenSSH 9.8 (Juli 2024) führte PerSourcePenalties ein, standardmäßig aktiv.

Referenzen

• bk99.de 2007: ssh bruteforce iptables (Webarchiv)
• bk99.de 2007: pop3 brute force (Webarchiv)
• iptables-extensions: hashlimit
• nftables-Wiki: Meters
• OpenSSH 9.8: Release Notes (PerSourcePenalties)
• Kuratierter Beitrag: SSH nur mit Public Key (HB, 2007)

Bemerkungen

• Dieser Beitrag fasst zwei Einträge vom 17. Februar 2007 aus meinem alten Plone-Blog zusammen. 2026 habe ich sie aus dem Webarchiv geholt, überarbeitet und um den heutigen Stand ergänzt. Die Adresse des Angreifers lasse ich weg.
• Die nftables-Regel ist ein Beispiel; sie gehört in eine Kette, deren übrige Regeln zum eigenen Regelwerk passen.

Originalbeitrag im Webarchiv →

Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.