SSH vor Brute-Force-Angriffen schützen
Mit Open-Source-Tools und wenigen Handgriffen erkennt ein System verdächtige Anmeldeversuche und blockiert sie.
- Daniel Bachfeld
Viele Betreiber eines Servers mit SSH-Zugang und Authentifizierung per Passwort haben ein ungutes Gefühl, was die Sicherheit angeht. Spätestens wenn ein Blick in die Server-Logs zahllose Login-Versuche von automatischen Skripten offenbart, fragt man sich, ob das gut gewählte Passwort weiteren Brute-Force-Angriffe standhalten wird. Zuletzt zeigte sich bei Angriffen auf diverse Sicherheits-Sites, dass die Betreiber die eigenen Ratschläge nicht immer befolgen.
Doch mit einfachen Mitteln kann man die wiederholten Versuche der Cracker ganz einfach ausbremsen. Spezielle Tools zählen die Fehlversuche von einer bestimmten IP-Adresse aus und blockieren ab einer vorgegebenen Schwelle weitere Zugriffe. Bei der Blockade verfolgen die Tools unterschiedliche Ansätze.
Grundsätzliches
Mit sogenannten TCP-Wrappern lassen sich unter Unix-und BSD-Systemen Zugriffskontrollen für TCP-Verbindungen implementieren. Sie schalten sich zwischen den TCP/IP-Stack und den eigentlichen Dienst. Klassisch geschieht dies im Zusammenspiel mit dem Superserver (x)inetd, der ankommende Verbindungen zunächst dem TCP-Wrapper übergibt. Der kann dann beispielsweise Verbindungen protokollieren oder Verbindungsversuche von einzelnen IP-Adresse blockieren. Welche Adressen erlaubt sind und welche nicht, steht in den Dateien /etc/hosts.allow und /etc/hosts.deny. Erst wenn alles passt, startet der Wrapper das Dienstprogramm und übergibt ihm die offene Verbindung. Manche Dienste wie OpenSSH sind bereits gegen die Wrapper-Bibliothek libwrap gelinkt, die dieselbe Funktion übernimmt, und kommen somit ohne explizit zwischengeschalteten Vermittler aus. Ob der eigene OpenSSH-Daemon bereits gegen libwrap gelinkt ist und somit hosts.deny auswertet, kann man mit ldd /usr/sbin/sshd überprüfen.
Ein anderer Ansatz zum Blockieren ungewünschter Zugriffe unter Linux ist die Firewall netfilter, deren Regeln respektive Tabellen der Anwender über das Userland-Tool iptables konfiguriert. Auch Anwendungen können Regeln hinzufügen und somit Angreifer draußen halten. Darüber hinaus unterscheiden sich die Tools in der Art, wie sie Informationen über verdächtigte Anmeldeversuche sammeln. Einige durchforsten die Log-Dateien in regelmäßigen Abständen nach Meldungen über fehlgeschlagene Authentifizierungsversuche, andere Tools zählen einfach die Verbindungsversuche von einer IP-Adresse mit.
Alle Blockade-Tools, die in regelmäßigen Intervallen Log-Dateien auswerten, haben das Problem, nicht in Echtzeit auf Angriffe reagieren zu können. Solange ein Angreifer Name und Passwort manuell durchprobiert, können sie mithalten. Bei schnellen Attacken mit automatischen Skripten geraten sie unter Umständen ins Hintertreffen und schlagen zu spät zu. In Tests beobachteten wir Angriffe, bei denen im Log innerhalb weniger Sekunden Dutzende von Fehlversuchen auftauchten, die Tools aber erst nach etwa 40 Sekunden anschlugen. Zwar kann man die Intervalle verkürzen, allerdings nimmt das Tool dann unter Umständen zu viel Ressourcen in Anspruch.
Zudem sind sie grundsätzlich für manipulierte Logeinträge anfällig. Ein Angreifer könnte aus der Ferne etwa mit speziellen Nutzernamen oder anderen Aufrufen gezielt Einträge ins Log schleusen, die die Tools dazu bewegen, legitime IP-Adresse zu blockieren (Details dazu in Attacking Log analysis tools).
