OpenSSH Security Hardening Guide für Linux
SSH ist eines der am weitesten verbreiteten Protokolle für die Systemverwaltung auf Linux-Plattformen. Es ist für viele Betriebssysteme verfügbar, die auf Unix, Linux und MacOS basieren. Es basiert auf dem Client-Server-Modell, bei dem ein Rechner die Serverkomponente ausführt und der andere ein Client-Tool für den Zugriff verwendet.
Wie funktioniert SSH?
Der Client (ssh) initiiert die Verbindung, indem er eine Anfrage an den Server sendet. Der Server wartet mit Hilfe des Server-Daemons (sshd) auf die eingehenden Anfragen. Er verwendet seinen öffentlichen Schlüssel, um sich gegenüber dem Client zu authentifizieren, der versucht, sich mit ihm zu verbinden:
Auf diese Weise kann der Client sicher sein, dass er sich mit dem richtigen SSH-Server verbindet. Wenn dies geschehen ist, kann der Client auf den Server zugreifen. Wenn du mit einem Windows-Client arbeitest, musst du Tools wie putty verwenden, um dich mit dem Server zu verbinden. Sowohl der Client als auch der Server können auf demselben System installiert werden, d.h. du kannst das Client-Tool verwenden, um auf andere Rechner zuzugreifen, oder dein System kann selbst der Server sein, auf den andere zugreifen können. In diesem Fall wird die Konfigurationsdatei im selben Verzeichnis abgelegt, allerdings mit einem etwas anderen Namen. Das Verzeichnis ist „/etc/ssh“ und der Name der Konfigurationsdatei des ssh-Clients ist „ssh_config“ und der der Konfigurationsdatei des Servers ist „sshd_config“:
Wenn du beide Dateien auf deinem System hast, solltest du klugerweise wählen, welche Datei du konfigurieren musst. In den meisten Fällen ist es der Server, den wir aus Sicherheitsgründen konfigurieren müssen, da er die Tür für potenzielle Zugriffe auf das System öffnet.
Wir beginnen damit, den Status des SSH-Daemons oder sshd auf unserem Server zu überprüfen. Auf diese Weise können wir feststellen, ob er läuft und so aktiviert ist, dass er beim Booten automatisch startet. Der folgende Befehl prüft den Status des sshd:
$ systemctl status ssh.service
Oder verwende den folgenden Befehl:
$ systemctl status sshd.service
Aus dem Screenshot können wir ersehen, dass der Dienst aktiv und aktiviert ist. Er läuft bereits seit 6 Stunden. Wenn du die Terminalansicht durch Drücken des Pfeils nach rechts erweiterst, wirst du feststellen, dass er auf dem Standardport 22 lauscht.
Manchmal nehmen wir Änderungen an der SSH-Konfigurationsdatei des entfernten Systems vor, während wir über SSH selbst mit ihm verbunden sind. In einem solchen Fall sollten wir den Befehl reload statt restart verwenden. Auf diese Weise ist die Wahrscheinlichkeit geringer, dass die Verbindung unterbrochen wird.
SSH mit den Best Practices konfigurieren
Ich denke, es ist jetzt an der Zeit, mit der Konfiguration des SSH-Servers zu beginnen. Bevor wir uns die Hände mit der SSH-Konfigurationsdatei schmutzig machen, sollten wir ein Backup der Datei mit den Standardeinstellungen erstellen:
$ sudo cp /etc/ssh/sshd_config ~/sshd_config.bkp
Wenn wir die Sicherung durchgeführt haben, können wir sicher sein, dass wir die Sicherungsdatei verwenden können, um wieder zur Normalität zurückzukehren, falls wir mit der Hauptdatei Fehler machen und unser SSH unterbrechen.
1. Ändern des Standardports
Der sshd-Daemon lauscht standardmäßig auf Port 22 des Servers. Es wird empfohlen, diesen Wert auf eine andere Nummer zu ändern, um die Möglichkeiten automatisierter Angriffe durch Skripte zu verringern. Dieser Ansatz wird als Sicherheit durch Unklarheit bezeichnet. Öffne dazu die unten stehende Datei und suche nach der Zeile mit dem Text „#Port 22“.
$ sudo nano /etc/ssh/sshd_config
Entferne das Kommentarzeichen in der Zeile „#Port 22“ und ändere „22“ in eine andere Portnummer, die auf deinem System nicht verwendet wird. Wir müssen sie in „222“ ändern und den Dienst neu starten. Verwende nun den ssh-Befehl mit der Option „p“, um den neuen Port anzugeben:
$ ssh user@system_ip -p 222
2. Deaktivieren der Anmeldung als Root-Benutzer
Root ist der ultimative Benutzer auf jedem Linux-System und hat Zugriff auf alle Ressourcen deines Systems. Wenn du keinen strikten Root-Zugang benötigst, solltest du die Root-Anmeldung auf deinem Server deaktivieren. Öffne dazu die oben genannte Datei:
$ sudo nano /etc/ssh/sshd_config
und setze den Parameter „PermitRootLogin“ auf „no“. Damit wird sichergestellt, dass der Server vor zufälligen Angriffen auf das Root-Konto geschützt wird. Die Standardoption ist „prohibit-password“, die eine Anmeldung mit Public-Key-Authentifizierung zulässt, aber die Anmeldung mit Passwort verweigert.
3. Einstellen der Protokollversion
Die ältere Protokollversion von SSH ist 1 und ist im Vergleich zu SSH2 weniger sicher. Außerdem haben beide unterschiedliche Netzwerkimplementierungen und sind nicht miteinander kompatibel. Um zu überprüfen, welche Protokollversion auf deinem Server aktiv ist, öffne die Datei sshd_config erneut und suche nach der Zeile „Protocol“:
$ cat /etc/ssh/sshd_config | grep ‚Protocol‘
Falls du eine leere Ausgabe erhältst, verwendet OpenSSH wahrscheinlich die Version 2, wie es in unserem Fall der Fall war. Eine andere Möglichkeit ist, das Dienstprogramm netcat zu verwenden:
$ nc localhost 22
Beispielhafte Ausgabe:
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4
Anhand der Ausgabe können wir sehen, dass SSH2 auf unserem System aktiv ist.
Um zu überprüfen, welche Protokollversion auf einem entfernten Server läuft, versuche, dich mit einem ssh-Client mit der Option -Q (query) mit ihm zu verbinden:
$ ssh -Q protocol-version user@server_name
Das obige Bild zeigt die SSH-Version 2 beim Zugriff auf einen Ubuntu ssh-Server von einem Kali Linux aus.
4. Passwortkomplexität
Schwache Passwörter sind immer anfällig für Angriffe, leere Passwörter sind also noch anfälliger für Angriffe. Die Option PermitEmptyPasswords sollte daher in der Datei sshd_config auf „no“ gesetzt werden. Genauso sollte die Anzahl der Anmeldeversuche mit falschem Passwort begrenzt werden, um die Wahrscheinlichkeit eines Brute-Force-Angriffs zu verringern. Dies kann mit der Option „MaxAuthTries“ erreicht werden, die auf einen kleineren Wert wie 3 gesetzt wird.
In der obigen Abbildung sehen wir, dass wir nach drei falschen Passwörtern keinen SSH-Zugang mehr haben, wenn wir den Wert „MaxAuthTries“ auf 3 setzen. Ein weiterer wichtiger Sicherheitsaspekt ist die Verwendung der Authentifizierung mit öffentlichen Schlüsseln für die Anmeldung. Die schlüsselbasierten Authentifizierungsmodelle sind weniger anfällig für Brute-Force-Angriffe. Außerdem können wir das PAM-Authentifizierungsmodul verwenden, um den SSH-Server noch mehr zu stärken.
Fazit
In diesem Leitfaden haben wir versucht, die wichtigsten Punkte zur Sicherung eines SSH-Servers abzudecken und sie in vier Hauptpunkten zusammenzufassen. Obwohl dieser Leitfaden nicht vollständig ist, kannst du noch weitere Bereiche finden, um deinen SSH-Server zu stärken. Du kannst z.B. versuchen, eine Bannermeldung einzufügen, um die Benutzer/innen über die Nutzung deines Systems über SSH zu informieren. Du kannst auch die Anmeldung mit einem Passwort verweigern und eine schlüsselbasierte Authentifizierung für die passwortlose Anmeldung verwenden. Ein weiterer interessanter Punkt ist, dass du die Anzahl der SSH-Benutzer und deren Verbindungszeit begrenzen kannst.