SSH vor Brute-Force-Angriffen schützen
Seite 4: recent
recent
Mit dem iptables-Modul "recent" lassen sich auf Paketebene TCP-Verbindungsversuche auf Dienste in Echtzeit mitzählen und ab einem Schwellwert weitere Angriffe von einer IP-Adresse blockieren, ohne dass man Logs durchsuchen muss. Das Modul ist Bestandteil des Linux-Kernels und wird zur Laufzeit geladen.
Recent kann allerdings prinzipbedingt nicht zwischen erfolgreichen und fehlgeschlagenen Logins unterscheiden. Da sich aber kein Anwender ständig anmeldet und sofort wieder abmeldet, kann ein Fenster von drei SSH-Verbindungsaufbauversuchen innerhalb von 60 Sekunden als Grenze gelten, ab der man den Vorgang als Brute-Force-Angriff werten darf. Die individuellen Einstellungen hängen aber von Risiko für mögliche gezielte Angriffe auf den eigenen Server ab. Mit nur zwei Versuchen pro Minute kann ein Angreifer über den Tag verteilt aber immer noch 2880 Passwörter probieren. Hier hilft es gegebenenfalls, ein Tageslimit festsetzen, beispielsweise auf 30.
In unseren Tests hat folgende Konfiguration gut funktioniert. Man setzt man in /etc/ssh/sshd_config die Option MaxAuthTries 3 und definiert folgende iptables-Regeln (gelten für ein System ohne bereits vorhandene iptables-Regeln):
iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -i eth0 -m state --state ESTABLISHED -m recent --update --seconds 60 --hitcount 2 -j REJECT --reject-with tcp-reset
Die erste Regel schreibt mit der Option --set die IP-Adresse einer neuen Verbindung auf Port 22 nebst Zeitstempel in die Proc-Datei /proc/net/ipt_recent/DEFAULT. Die zweite Regel fügt mit --update einen weiteren Zeitstempel ein und prüft, ob zwei Zeitstempel innerhalb der letzten 60 Sekunden liegen. Ist dies der Fall, wird die Verbindung zurückgesetzt. Erst nach Ablauf einer Minute ist wieder eine Verbindung zum SSH-Server und drei weitere Login-Versuche möglich. Anders als bei der Wrapper-Methode blockieren diese Regeln nur den SSH-Zugang, alle anderen Dienste sind für den Angreifer weiter erreichbar.
Die Kombination von NEW und ESTABLISHED verringert die Gefahr von Spoofing-Angriffen, bei denen ein Spaßvogel mit gefälschten IP-Absender-Adresse die Recent-Liste füllt und somit unter Umständen legitime Adressen darin landen und die Firewall sie blockiert. Welche Adresse die Firewall wie oft gesehen hat, lässt sich mit cat /proc/net/ipt_recent/DEFAULT abfragen. Die gesamte Liste lässt sich mit echo clear > proc/net/ipt_recent/DEFAULT löschen. Einzelne Adressen kann man mit echo - > proc/net/ipt_recent/DEFAULT] entfernen. Grundsätzlich ließen sich diese Funktionen mit Log-Analyse verknüpfen.
Fazit
Auf einem über mehrere Monate mit DenyHosts geschützten System nahm die Zahl der Einbruchsversuche zwar nicht ab, deren Dauer verkürzte es aber auf unter eine Minute. Danach zog der Angreifer vermutlich zum nächsten System weiter. Stabilitätsprobleme zeigten sich nicht. Für den schnellen Schutz ist DenyHosts also durchaus geeignet. Grundsätzlich ist die Realisierung eines Blockers mit dem iptables-Modul recent aber deterministischer und zuverlässiger. Allerdings kann die Integration in bestehenden Firewall-Regelsätze mitunter etwas schwierig sein.
Angreifer versuchen jedoch immer häufiger, der Limitierung für Logins von einzelnen IP-Adressen zu entgehen, indem sie Botnetze für ihre Brute-Force-Angriffe verwenden. Dabei kann jeder Bot die maximale Anzahl der erlaubten Fehl-Logins durchprobieren, bevor das System ihn blockt. Die einzelnen Bots können sowohl parallel als auch hintereinander die Passwörter für ein Konto oder sogar mehrere testen. Bei einem beispielsweise aus 10.000 PCs bestehendem Botnetz könnte ein Angreifer bei drei erlaubten Versuchen 30.000 Passwörter ausprobieren. Daher bleibt es wichtig, ein schwer erratbares Passwort zu wählen.
Mit dem sshd-Parameter MaxStartups kann man die Zahl paralleler Verbindungen begrenzen, was zumindest zahlreiche gleichzeitige Logins verhindert. Sofern die Bots jedoch nacheinander ihr Glück versuchen, nutzt die Limitierung nicht mehr. Damit muss der Angreifer aber erheblich mehr Zeit aufwenden.
Alternativ oder auch auch zusätzlich kann man seinen SSH-Server aus der Schusslinie bringen, indem man ihn vom Standard-TCP-Port 22 auf einen ungewöhnlichen Port wie 54321 umzieht. Mit dem Wechsel auf die Authentifizierung per Public Key eliminiert man die Gefahr durch Brute-Force-Angriffe ganz; dies ist schlichtweg die sicherste Methode zur Authentifizierung. Allerdings ist es auch die unflexibelste, da man immer den Key dabei haben muss. Einen Mittelweg könnten Einmalpasswörter bieten. Der Artikel "Einmalpasswörter für den Heimgebrauch" beschreibt, wie man seinen Server dafür einrichtet. (dab)
