So gut wie jeder im Internet oder auch in einem LAN stehender Linux-Server bietet die Möglichkeit sich via SSH einzuloggen, um administrative Konfigurationen und Aufgaben auch von der Ferne aus durchführen zu können. SSH ist ein Protokoll welches ein Terminal auf dem Server an einem entfernten PC über eine verschlüsselte Verbindung bereitstellt. Entsprechend sollte dieses mächtige Tool auch abgesichert werden. Meist wird SSH zur Fernwartung genutzt und stellt bei fehlerhafter Konfiguration eine große Sicherheitslücke dar. In diesem Artikel möchte ich die einfachsten und gängigsten Möglichkeiten zur Absicherung eines SSH-Servers näher erläutern...Zu Beginn möchte ich aber noch erwähnen, dass die Systemsicherheit eines Linux-Servers von weit mehr als einem sicheren SSH-Server abhängt. Beispielsweise müssen auch andere installierte Pakete entsprechend sicher konfiguriert und auf einem aktuellem Stand sein. Es nützt nichts einen gesicherten SSH-Server bereitzustellen aber im Hintergrund einen veralteten ungepatchten Apache-Service, über den in das System eingedrungen werden kann. Auch sind die folgend beschriebenen Tipps lediglich ein Vorschlag zur Absicherung - es gibt sicherlich noch mehr Möglichkeiten, aber diese Anleitung soll zumindest die Grundsicherung des SSH-Servers deutlich untermauern.
Port
SSH kommuniziert standardmäßig auf Port 22. Dies ist weitgehend bekannt - aber nicht nur bei Menschen. Es gibt mittlerweile genügend Bots oder Skripts, die automatisiert Server nach offenem Port 22 durchsuchen und gängige Benutzer/Passwort-Kombinationen testen, um in das System einzudringen. Wenn also der Port auf einen anderen als 22 verändert wird (wie z.B. 1333), so wird sich die Zahl der "fehlgeschlagenen Logins" durch Bots oder Skripts deutlich verringern. Natürlich besteht auch weiterhin die Möglichkeit, dass automatisiert Login-Anfragen am SSH-Server aufschlagen, aber ein Portscan (welcher dann zuvor nötig ist) dauert entsprechend Zeit und nur wenige dieser Bots oder Skripte machen sich diese Mühe, solange es genügend andere Server im Internet mit der Standardkonfiguration gibt. Um den Port des SSH-Servers zu ändern gibt es in der Datei "/etc/ssh/sshd_config" einen Eintrag:
Port 22
ändern in
Port 1333
Nachdem dieser Eintrag entsprechend dem neuen Port angepasst wurde nicht vergessen den SSH-Dienst neu zu starten:
/etc/init.d/ssh restart
PermitRootLogin
In der Standardeinstellung erlaubt SSH den Login unter anderem für den "root"-Benutzer. Somit kann sich ein Angreifer, der das "root"-Kennwort kennt direkt auf dem Linux-Server via SSH als Systemadministrator einloggen. Sinnvoller ist es den SSH-Server so zu beschränken, dass sich nur "normale" Benutzer am SSH-Server authentifizieren können und später dann per "su"-Befehl zum Systemadministrator "root" gewechselt wird. Somit müsste der Angreifer zwei Passwörter (das von "root" und das von einem Benutzer) und den Benutzernamen des "normalen" Benutzers kennen, um administrative Berechtigungen auf dem Linux-Server zu erhalten. Eine deutliche Hürde, aber nur im Zusammenhang mit dem nächsten Tipp. Um den Login für den Benutzer "root" zu deaktivieren gibt es auch hier in der SSHd-Konfigurationdatei ("/etc/ssh/sshd_config")
PermitRootLogin yes
ändern in
PermitRootLogin no
Vor dem SSH-Server Neustart aber unbedingt beachten, dass sich danach nicht mehr als "root" eingeloggt werden kann. Sollte diese Änderung also per Fernwartung (SSH) geschehen unbedingt sicherstellen, dass es bereits mindestens einen "normalen" Benutzer gibt, der sich per SSH einloggen kann - um sich nicht aus zu sperren.
Benutzernamen und Passwörter
Ein leidiges Thema! Jeder der sich mit Sicherheit beschäftigt, dem sollte klar sein, dass an der Wahl des Benutzernamens und des Passwortes viel liegt. Beim Benutzernamen ist der Administrator meist in seiner Auswahl beschränkt. Somit ist hier kaum ein kryptischer Benutzername zu nutzen. Schön wäre es natürlich Benutzer wie "d4ER63bg" zu verwenden, aber in der Praxis kaum umsetzbar. Umso wichtiger ist es ein starkes und sicheres Passwort für die Benutzer zu vergeben - vor allem für den Systemadministrator "root". Ein sicheres Passwort sollte aus einer Kombination von Zahlen, Kleinbuchstaben, Großbuchstaben und Sonderzeichen bestehen. Auch die Anzahl an Zeichen sollte mindestens um 10-stelligen Bereich liegen. Ein Beispiel für ein sicheres Passwort:
D4sH!erIst€in$ich3|2esP4s$wort
Tipp: Passwörter für Benutzer unter Linux können mit Hilfe des Befehls "passwd" gesetzt werden.
Login nur für bestimmte Benutzer
Es kann nicht nur der Benutzer "root" ausgeschlossen werden, sondern es kann auch eine Liste von Benutzern spezifiziert werden, denen ein Login via SSH explizit erlaubt ist. Empfohlen ist hier eine überschaubare Liste von "normalen" Benutzern, die sich per SSH einloggen können. Diese Liste wird ebenso in der Datei "/etc/ssh/sshd_config" gepflegt:
AllowUsers user1 user2 user3
Der Eintrag "AllowUsers" existiert in der "Standard"-Konfigurationsdatei zunächst nicht. Dieser Eintrag kann einfach eingefügt werden. Anstelle von "user1", "user2" und "user3" werden die entsprechenden Benutzer festgelegt, die sich dann einloggen können. Es können unlimitiert Benutzer angegeben werden, die jeweils mit einem Leerzeichen getrennt sind. Sollen ganze Gruppen berechtigt werden gibt es die Einstellungsmöglichkeit "AllowGroups", die ähnlich zu konfigurieren ist.
Login via Zertifikat (Public-Key/Private-Key)
In der Standardkonfiguration genügt es den Benutzernamen einzugeben und dann das dazugehörige Password. Sollte dieses richtig sein ist man eingeloggt. Es gibt auch die Möglichkeit sich mit einem Zertifikat einzuloggen. Dazu muss auf dem Computer, der eine Verbindung herstellen möchte ein Zertifikat vorhanden sein und auf dem Linux-Server (der den SSH-Service bereitstellt) das Gegenstück dazu. Nur wenn beide Zertifikate zusammenpassen und (je nach Konfiguration) das richtige Passwort vom Zertifikat eingegeben wurde, ist der Login erfolgreich. Um den Login mit Zertifikaten zu ermöglichen sind ein paar weitere Schritte erforderlich. Ich beschreibe hier jetzt den Fall, dass sich ein Client mit Windows XP (und der Software puTTy) auf einem Linux SSH-Server mit Zertifikat einloggen möchte.
Zunächst muss das Zertifikat-Paar erzeugt werden. Hierzu gibt es für Windows ein simples Tool Namens "puTTYgen", welches es auf der PuTTY-Webseite zum Download bereit steht. Nach dem Start muss zunächst die Stärke der Verschlüsselung ganz unten rechts eingetragen werden. Empfehlen würde ich hier den Wert "2048" bit. Mit "Generate" kann nur das Zertifikat-Paar erzeugt werden. Dazu muss für ein paar Augenblicke die Maus innerhalb des puTTYgen-Fensters bewegt werden, um Zufallsdaten zu generieren. Wenn dies abgeschlossen ist erscheint der sogenannte Public-Key im Feld oben und es gibt die Möglichkeit einen Kommentar einzutragen und ein Passwort festzulegen. Ich empfehle zusätzlich ein starkes Passwort zu vergeben. Stark heißt so lange wie möglich und einer Kombination aus Zahlen, Kleinbuchstaben, Großbuchstaben und Sonderzeichen. Wenn ein Passwort vergeben wird, muss ein Angreifer für den erfolgreichen Login auf dem Linux-Server sowohl einen Teil des Zertifikates (Private-Key) und das Passwort haben. Wenn kein Passwort vergeben wird, genügt das Zertifikat. Sollten die Felder wie gewünscht gefüllt sein, müssen die Zertifikate gespeichert werden. Mit "Save public key" zunächst der öffentliche Schlüssel und mit "Save private key" der private Schlüssel. Wie der Name schon sagt ist dieser Teil des Zertifikats privat und das muss dieser Teil auch zwingend bleiben. Im Besitz dieses privaten Schlüssels (und ggf. dem Passwort - falls eingerichtet) kann später ein Login auf dem Linux-Server mittels SSH erfolgen. Diese Datei also keinesfalls weitergeben und unbedingt sichern! Zuletzt markiert man den Inhalt im Feld ganz oben über dem "Public key for pasting into OpenSSH authorized_keys file" steht und kopiert ihn in die Zwischenablage (STRG+A + STRG+C oder per Rechtsklick).
Jetzt muss man sich überlegen für welchen User das Zertifikat künftig für den Login verwendet werden soll. Empfohlen ist auch hier nicht den User "root" zu nutzen, sondern einen "normalen" Benutzer - erst recht, wenn "PermitRootLogin" bereits auf "no" gesetzt wurde. Dieser User muss aber (falls verwendet) in der "AllowUsers"-Liste stehen. Mit genau diesem Benutzer loggt man sich nun per SSH auf dem Linux-Server ein - das letzte Mal über Benutzername/Passwort - wie bisher auch. Im Homeverzeichnis des entsprechenden Benutzers wird ein Verzeichnis Namens ".ssh" (Punkt beachten!) angelegt und passende Rechte vergeben:
mkdir ~/.ssh
chmod 700 ~/.ssh
Nun wird innerhalb dieses neu erstellten Verzeichnisses eine Datei Namens "authorized_keys2" erzeugt und Berechtigungen gesetzt:
touch ~/.ssh/authorized_keys2
chmod 600 ~/.ssh/authorized_keys2
In diese Datei muss nun der zuvor in die Zwischenablage kopierte Text eingefügt werden. Dazu wird die Datei mit einem Editor nach Wahl geöffnet und der Text eingefügt bzw. eingetippt. Tipp: Wenn man gerade mit PuTTy auf dem entfernten Server verbunden ist kann der Inhalt der Zwischenablage mit der rechten Maustaste einfach eingefügt werden.
vim ~/.ssh/authorized_keys2
Wichtig ist, dass kein Zeilenumbruch innerhalb des Zertifikats-Schlüssels vorhanden ist, da es sonst nicht korrekt funktioniert.
Um den Login mit dem neu erstellten Zertifikat-Paar zu testen, muss der PuTTy-Client noch ein wenig angepasst werden. Hier den Menüpunkt "Connection -> SSH -> Auth" aufrufen und die gespeicherte Datei des privaten Zertifikates unter "Private key file for authentication" angeben. Nach dem Klick auf "Open" wird die Verbindung wie gewohnt zum SSH-Server hergestellt. Benutzername eingeben und dann sollte entweder automatisch eine Anmeldung erfolgen, oder nach dem Zertifikat-Passwort gefragt werden - je nach dem, ob ein Passwort für das Zertifikat definiert wurde oder nicht. Die Eingabe des Benutzernamens kann man sich sparen, wenn in den puTTy-Einstellungen unter "Connection -> Data" unter "Auto-login username" der entsprechende Benutzername bereits eingetragen wurde.
Login auf Zertifikate beschränken
Vielleicht schon bemerkt... Es ist trotz der Zertifikat-Erstellung nach wie vor möglich sich auch per Benutzername/Passwort am SSH-Server zu authentifizieren. Wenn der Login mit dem erstellten Zertifikat-Paar erfolgreich war, kann darüber nachgedacht werden den "normalen" Login mit Benutzer/Passwort zu deaktivieren. Danach ist nur noch ein Login mit entsprechend gültigem Zertifikat-Paar möglich. Deswegen sollte diese Funktionalität auch erst aktiviert werden, wenn ein Login per Zertifikat wirklich erfolgreich war. Um diese Funktionalität zu aktivieren muss die "/etc/ssh/sshd_config" Konfigurationsdatei folgendermaßen bearbeitet werden:
#PasswordAuthentication yes
UsePAM yes
ändern in
PasswordAuthentication no
UsePAM no
Bitte die eventuell führende Raute auch entfernen, da sonst diese Zeile auskommentiert und damit vom SSH-Server ignoriert wird.
Jetzt kann nochmals der Zugriff via Zertifikate und via Benutzername/Password getestet werden. Der Zugriff via Benutzername/Passwort sollte nun nicht mehr möglich sein.
Damit sollte der SSH-Server zumindest den gängigen Bots und "Script-Kiddies" problemlos widerstehen können und sich die "failed login attempt"-Meldungen in den Logfiles minimieren. Über Feedback, Log und Tadel in den Kommentaren würde ich mich selbstverständlich sehr freuen.