SSH absichern

Brute-Force-Angriffe gegen SSH-Server abwehren

Lukas Grunwald - 11.09.06

Internetserver sind heute in der Regel so gut abgeschottet, dass sie außer den gewünschten Ports für Anwendungen wie E-Mail oder Web meistens lediglich einen SSH-Zugang für die Fernverwaltung offen halten. Doch gerade darauf konzentriert sich deshalb das Interesse unwillkommener Anwender

Telnet, Rlogin, RSH und Finger gehören der Vergangenheit an, und der SSH-Daemon gilt inzwischen unter anderem dank Privilegienseparation als sicher genug. Dennoch besteht auch hier Anlass zur Sorge: Die Angreifer, meist "Skriptkiddies", versuchen mit Brute-Force-Angriffen in Internethosts einzubrechen. Sie probieren einfach eine Liste beliebter Kombinationen von Passwörtern und Benutzernamen aus, und sobald sie zufällig ein unsicheres Passwort finden, ist der Einbruch geglückt.

Passwörter nicht immer sicher genug

Wenn der Benutzer oder Administrator sicherere Passwörter vergibt, bleiben sie verborgen. Aber schnell ist ein Benutzerkonto "test" mit dem Passwort "test" ausgestellt, auch wenn es nur fünf Minuten dauern soll, "um mal eben schnell etwas zu testen".

Außerdem benötigen solche Angriffe Übertragungskapazität und Rechenleistung: Der Server startet zusätzliche SSH-Daemon-Prozesse. Ein Testserver mit einem Honeypot-System dokumentierte im Laufe von vier Monaten fast 64 000 illegale Login-Versuche (siehe Listing 1). Allein der damit verbundene Ressourcenmissbrauch ist Grund genug, dagegen vorzugehen.

Ein SSH-Zugang lässt sich mit verschiedenen Methoden schützen – im Folgenden anhand von OpenSSH in der Version 3.8.1 und 4.2 demonstriert, das für alle Unix- und Linux- Varianten zur Verfügung steht. Andere SSH-Daemons verwenden eine andere Syntax, lassen sich aber prinzipiell ebenso sichern.

Als probate Gegenmaßnahme kommt es in Betracht, den SSH-Zugang auf die Verwendung asymmetrischer Schlüssel zu beschränken. Damit man sich damit einloggen kann, ist zunächst ein Schlüsselpaar zu erstellen (Listing 2). Der Nachteil: Einen Private Key kann man sich nicht wie ein Passwort merken, sondern muss ihn auf einem Datenträger mit sich führen.

Es ist daher ratsam, den Schlüssel ebenfalls mit einem Passwort zu schützen. Das hat nichts mit dem Login-Passwort zu tun, sondern verhindert, dass sich ein Angreifer, der Zugriff auf den Private Key bekommen sollte, damit sofort und ohne weitere Autorisierung einloggen kann. Dadurch erhält der legitime Benutzer etwas mehr Zeit, ein neues Schlüsselpaar zu erzeugen und den Public Key auf dem Host durch einen neuen zu ersetzen.

alenka/password from ::ffff:211.22.8.3: 1 Time(s)
alex/password from ::ffff:211.22.8.3: 1 Time(s)
alexander/password from ::ffff:211.22.8.3: 1 Time(s)
alexis/password from ::ffff:211.22.8.3: 1 Time(s)
alice/password from ::ffff:211.22.8.3: 1 Time(s)
alicia/password from ::ffff:211.22.8.3: 1 Time(s)
alison/password from ::ffff:211.22.8.3: 1 Time(s)
allan/password from ::ffff:211.22.8.3: 1 Time(s)
allen/password from ::ffff:211.22.8.3: 1 Time(s)
allison/password from ::ffff:211.22.8.3: 1 Time(s)
almost/password from ::ffff:211.22.8.3: 1 Time(s)
alpha/password from ::ffff:211.22.8.3: 1 Time(s)
altaenbuscadores/password from ::ffff:211.22.8.3: 1 Time(s)w

Listing 2: Schlüsselerzeugung für SSH

user123@lxserv1:~$ ssh-keygen -d
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user123/.ssh/id_dsa):
Created directory '/home/user123/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user123/.ssh/id_dsa.
Your public key has been saved in /home/user123/.ssh/id_dsa.pub.
The key fingerprint is:
14:0a:aa:85:5f:77:b6:07:48:ef:fe:6e:b5:96:b0:8b user123@lxserv1