SSH Zugriff ist eine gängige Methode, mit der man auf einen Linux-Server zugreift. Doch wie schütze ich mein Linux-Server nach außen hin, damit man nicht immer erst eine VPN-Verbindung aufbauen muss? Mit folgender Anleitung möchte ich die Grundlagen zur Absicherung eines Debian-Servers erklären. Dazu gehört das Schließen von unbenutzen Ports, das Einrichten des SSH-Logins mit RSA-Schlüsselpaar, Deaktivieren von IPv6, die Login-Versuche zu begrenzen, damit Bruteforce-Attacken keine Chance haben und weitere Tipps.
Basis dieses Tutorials für einen sicheren SSH-Zugriff mittels RSA-Schlüsselpaar ist eine neue Debian 8 – 64bit Net-Install↗ ohne grafische Oberfläche.
Der SSH-Server auf Debian ist standardmäßig so eingestellt, dass sich root nicht über SSH einloggen kann. Dies ist schon das erste Sicherheitsmaßnahme, die wir auch nicht abändern sollten. So muss ein Angreifer nicht nur das Passwort erraten, sondern auch den Benutzernamen. Dies sind somit schon zwei Unbekannte.
1. Portfreigabe
Um überhaupt von außerhalb mittels SSH auf unseren Debian-Server zugreifen zu können, müssen wir einen Port im Router freigeben.
Hier bietet es sich an, einen x-beliebigen Port (zB.:12345) zu verwenden und diesen an unseren Server Port weiterzuleiten. Dies ist unser 1. Sicherheitsfeature, da Bots auf der Suche nach Schwachstellen oftmals zufällige IP-Adressen und die gängigsten Ports testet, ob etwas antwortet. Alle 65535 Ports abfragen dauert relativ lange und ist daher nicht sehr geläufig.
Nun erfolgt der erste Zugriff mittels SSH auf unseren Debian-Server.
Beim Klick auf Open sollte folgende Warnung erscheinen. Die ist beim ersten Verbindungsversuch mittels SSH normal. Sollte diese Meldung bei unveränderter Konfiguration erneut erscheinen, dann könnte das System kompromittiert sein. In unserem Fall können wir beruhigt auf „Ja“ klicken.
Nun können wir uns mit unserem Benutzer einloggen.
Nach erfolgtem Login holen wir uns Superuser-Rechte mittels des Befehls su.
Nun möchten wir auch noch den SSH-Port auf unserem Server in einen beliebigen Port ändern. Dafür öffnen wir mit folgendem Befehl mit nano die Konfigurationsdatei von SSHD.
nano /etc/ssh/sshd_config
Da Port 22 der gängige SSH-Port ist, werden wir diesen auch auf einen schwer zu erratenen ändern.
Nun muss die geänderte Konfigurationsdatei gespeichert werden. Danach müssen wir den SSH-Dienst neustarten.
/etc/init.d/ssh restart
Die aktive Verbindung wird dadurch nicht getrennt, da bestehende SSH-Verbindungen von der Änderung nicht betroffen sind. Wir sollten den SSH-Zugriff über den neuen Port erst mit einer neuen Terminal-Session ausprobieren, bevor wir unser aktuellen Terminal schließen.
Bevor wir uns jedoch wieder verbinden, müssen wir unsere Portfreigabe im Router noch auf den neuen Port abändern, da die Portfreigabe ja nun nicht mehr an den Standardport 22 sondern in meinem Beispiel an 41235 weitergeleitet muss.
2. Mailversand bei erfolgten SSH-Login
Eine weitere Sicherheitsmaßnahme ist, dass man sich bei einem erfolgtem SSH-Login per Email informieren lässt. Dafür benutzen wir das Programm sendEmail, was uns ermöglicht, Mails mittels Shell-Script zu versenden. SendEmail (nicht zu verwechseln mit sendmail) ist ein in Perl geschriebener SMTP-Client und kann mit folgendem Befehl installiert werden.
apt-get install sendemail
Um Emails versenden zu können, brauchen wir noch einen SMTP-Server. In der Regel bietet das jeder Freemail-Anbieter an. Da ich meine Webseiten auf all-inkl.com↗ hoste, habe ich dort die Möglichkeit mir dafür extra ein Mailpostfach einzurichten.
Damit bei erfolgreichem Login eine Mail verschickt wird, bearbeiten wir mit dem Editor nano die /etc/ssh/sshrc.
nano /etc/ssh/sshrc
Dort fügen wir unten folgende Zeilen ein:
ip=`echo $SSH_CONNECTION | cut -d “ “ -f 1`
logger -t ssh-wrapper $USER login von $ip
echo „Benutzer $USER hat sich von IP $ip eingeloggt.“ | sendEmail -q -f Absender@server.com -s Servername:Port -xu Benutzername -xp Passwort -t Empfänger@server.com -o tls=yes -u „SSH-Login auf Debian Testmaschine“
Folgende Angabe müssen für den Mailversand angepasst werden:
-q = quiet (Es erfolgt keine Textausgabe im Terminal, wenn die Mail versandt wurde)
-f = from (hier die Absendemailadresse eingeben)
-s = Server (Die Adresse der SMTP-Servers mit nachstehender Portangabe)
-xu = User (Loginname für SMTP-Server)
-xp = Passwort (Passwort für SMTP-Server)
-t = to (Empfängeradresse)
tls sollte auf yes stehen, damit eine verschlüsselte Verbindung mit dem SMTP Server aufgebaut wird.
– u = Subject (Betreff der Email)
Nach dem Speichern der /etc/ssh/sshrc können wir durch das Öffnen einen neuen Terminals den Mailversand testen.
3. Login-Versuche begrenzen mit Fail2Ban
Damit BruteForce-Attacken nicht unendlich viele Loginversuche vornehmen können, begrenzen wir die Anzahl der möglichen Versuche mittels des Programms Fail2Ban↗. Dieses installieren wir mit folgendem Befehl:
apt-get install fail2ban
4. Unbenutze Ports schließen
Da jeder geöffnete Port ein potenziellen Sicherheitsrisiko darstellt, sollten wir alle Ports schließen, die wir nicht benötigen. Dafür müssen wir erstmal wissen, welche Ports durch welche Programme geöffnet sind. Port sind nicht einfach offen, sondern werden von Programmen geöffnet, welche dann an diesem Port lauschen. Mit folgendem Befehl kontrollieren wir die geöffneten Ports:
netstat -tulpen | grep -v ‚127.0.0.1‘ | grep -v ‚::1:‘
Das Resultat:
Wir sehen direkt unseren Port 41235 mit der Info sshd. Jedoch können wir auch die Dienste rpc.statd, rpcbind und dhclient erkennen. Dhclient ist für den reibungslosen Betrieb mit einem DHCP-Server im Netzwerk zuständig und akzeptiert auch nur entsprechende Pakete. Alle anderen Pakete werden verworfen. Rpc.statd und rpcbind sind jedoch für NFS-Freigaben notwendig. Da ich diese nicht benötige, werde ich diese schließen.
Um die Dienste zu stoppen verwenden wir folgenden Befehle:
service rpcbind stop
service nfs-common stop
Natürlich könnten wir NFS mit folgendem Befehl auch komplett deinstallieren, was ich jedoch nicht getan habe:
apt-get –purge remove nfs-kernel-server nfs-common portmap
Nun sollte die Liste unserer offenen Ports in etwa so aussehen:
5. IPv6 deaktivieren
Solange IPv6 noch nicht produktiv genutzt wird, sollte bzw kann man es ruhigen Gewissens abschalten.
Mit
ip addr show | grep inet6
können wir gucken, ob wir eine IPv6 adresse erhalten haben:
Mit folgendem Befehl können wir IPv6 deaktivieren:
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
Nach einem Neustart mit dem Befehl reboot sollten wir keine IPv6-Adresse mehr erhalten:
6. SSH-Login mit RSA-Schlüsselpaar
Ein RSA-Schlüsselpaar ist ein sicherer Weg, sich an seinem SSH-Server zu authentifizieren. Während ein Passwort erraten oder mittels BruteForce-Attacke durchprobiert werden kann, ist es nahezu unmöglich einen RSA-Schlüssel zu entschlüsseln. Beim Generieren des RSA-Schlüsselpaares werden zwei Schlüssel erstellt: Ein öffentlicher und ein privater. Der öffentliche wird auf dem Server abgelegt und ab dann kann man sich nur noch eingeloggen, wenn man über den privaten Schlüssel verfügt. Vereinfacht vorstellen kann man sich das so, als ob der öffentliche Schlüssel ein Türschloss ist und der private Schlüssel der dazugehörige Schlüssel. Wenn jemand den privaten Schlüssel in die Hände bekommt, muss er auch erstmal wissen, zu welchem Türschloss dieser gehört. Noch dazu kann man seinen geheimen Schlüssel auch noch mit einem Passwort sichern. In der PuTTY-Standardkonfiguration muss man beim Verbindungsaufbau auch den Benutzernamen angeben, mit dem man sich einloggen möchte. Dieser lässt sich aber auch vordefinieren. Dazu später mehr.
Zuerst erstellen wir uns ein Schlüsselpaar. Dies erledigen wir nicht auf dem Server. Ich werde die Erstellung des Schlüsselpaares auf einem Linux-Client als auch auf einem Windows Client erklären.
6.1 RSA Schlüsselpaar unter Linux einrichten
Wir öffnen in unserem Linux ein Terminal und geben folgenden Befehl ein:
ssh-keygen -t rsa
Beim bestätigen mit Enter werden wir „Enter file in which to save the key (/home/demo/.ssh/id_rsa):“ gefragt. Diese Frage können wir einfach mit Enter bestätigen. Wenn wir unseren Schlüssel mit einem Passwort verschlüsseln wollen, müssen wir bei der Frage „Enter passphrase (empty for no passphrase):“ unser Passwort eingeben und nach dem Drücken von Enter dieses noch einmal bestätigen. Nun wird das Schlüsselpaar erzeugt. Dies sollte in etwa so ausehen:
Zu finden ist unser Schlüsselpaar unter dem angegebenen Ordner ~/.ssh:
Nach dem Erstellen des RSA Schlüsselpaares wollen wir die Schlüssel mit folgendem Befehl auf unseren Server kopieren:
ssh-copy-id benutzer@server -p Port
(Falls der Port wie oben beschrieben geändert wurde müssen wir ein „-p“ und nach einem Leerzeichen gefolgt die Portnummer angeben)
Nach der Eingabe von Yes und Bestätigen mit Enter sollten wir unseren Schlüssel auf unserem Server mit
nano ~/.ssh/authorized_keys
aufrufen können.
Machen wir nun ein neues Terminal auf und verbinden uns mit unserem Server, dann wird automatisch der Login mittels des RSA-schlüsselpaares durchgeführt. Jedoch können wir uns immernoch von einem anderen Computer, der den privaten Schlüssel nicht besitzt, immer noch mit Benutzername und Passwort anmelden. Um dies zu verhindern müssen wir auf dem Server in der SSH-Config die Passwortauthentifizierung auf „no“ setzen:
nano /etc/ssh/sshd_config
PasswordAuthentication no
Nun ist ein Login nur noch möglich, wenn man über den privaten RSA-Schlüssel verfügt. Ist für diesen ein Passwort gesetzt, dann benötigt man dieses natürlich auch, um den privaten Schlüssel zu entsperren. Der Login sieht dann in etwa so aus:
Nachdem man den Schlüssel entsperrt hat, ist man sofort eingeloggt:
6.1.1 RSA-Schlüsselpaar in PuTTY-ppk-Schlüssel umwandeln
Wenn wir uns jetzt jedoch zB auch von einer Windows Maschine mittels PuTTY einloggen wollen, brauchen wir dort natürlich auch noch den privaten Schlüssel. PuTTY benötigt den Private Key jedoch im .ppk-Format. Mittels des Programms PuTTYgen lässt sich diese jedoch aus unserem vorhandenen Schlüssel erzeugen:
Nachdem wir nun auf „Save private key“ geklickt haben, können wir den gespeicherten Schlüssel in PuTTY unter Connection >> SSH >> Auth >> Browse einfügen.
