SSH-Zugang absichern

Für Profis geeignet
 

Vorraussetzungen

Dauer

ca. 45 Min.

Verwandte Beiträge

  • Passwörter
  • Firewall

1. Allgemeine Problematik

Sofern man einen Server im Internet betreibt wird man nur in den seltesten Fällen ohne SSH-Zugang auskommen um dem Server zu administrien. Das wissen auch Angreifer und nutzen dieses gerne aus, um Zugriff auf dem Server zu erhalten. In den folgenden Punkten geben wir einige Tipps, wie man es Angreifern erschweren kann, Zugriff auf dem Server zu erlangen.
Man wird es wohl nie schaffen einen Server 100 % abzusichern, aber man kann es den Angreifern so schwer machen, dass sich kein Angriff mehr lohnt. Diesen kann man durch verschiedene Vorgehensweisen erreichen.

2. Grundlagen

Es sollte immer die aktuellste Version des SSH-Deamons installiert sein. Um die Tipps zur SSH-Absicherung umzusetzen benötigt man einige Dateien.

Folgende Dateien / Verzeichnise werden benötigt.

  • /var/log/messages dieses kann abweichen
  • der Konfigurations Pfad: /etc/ssh/sshd_config bzw. /etc/ssh/ssh_config abhänig von der Distribution

3. Server administrieren ohne SSH

Der beste / sicherste Weg ist SSH nicht nach außen zu öffnen - aber wie?

Möglichkeiten:

  1. Wenn der Server in einem Datencenter / Rechenzentrum steht, in das man Zutritt hat, kann man direkt mit Tastatur und Monitor den Server administrieren. Nachteil: Wenn der Zugang benötigt wird, muss man immer direkt vor dem Server sitzen.
  2. Zweite Netzwerkkarte mit seperater IP über z. B. einen VPN-Zugang.
  3. Oder eine eRIC Remote-Karte
  4. Webadministration mit z. B. Webmin oder Plesk - wobei man hier eingeschränkt ist und auch diese Anwendung haben Sicherheitslücken.

4. Der Angriff

Einer der heufigsten Angriffe auf Linux-Server ist es über SSH root-Rechte zu erlangen. Man weiß, dass der Benuzer root auf dem Server existent ist, nun braucht man nur noch das richtige Passwort und man hätte uneingeschränken Zugriff.

Und da fangen die Probleme an. Jeder sollte sich im Klaren sein,  der einen Server am Internet betreibt auch für dessen Sicherheit verantwortlich ist und auch die Haftung dafür übernimmt. Ein Beispiel, sollte der Server kompromittert worden sein und es werden darüber SPAM-Mails oder DDoS-Attacken ausgeführt, kann man dafür in Haftung genommen werden.

Wichtig ist immer ein „sicheres“ Passwort zu wählen. -> Passwörter

5 .ssh-Daemon

Schon mit ein paar Handgriffen kann man den SSH-Daemon relativ sicher konfigurieren.

Die Konfiguraationsdatei ist unter /etc/ssh/sshd_config zu finden. Und kann mit folgenden möglichen Optionen erweitert oder geändert werden.

ListenAddress 192.168.0.1
Protocol 2
PermitRootLogin No
PermitEmptyPasswords no
PasswordAuthentication yes
LoginGraceTime 600
MaxAuthTries 3
AllowUsers root@*.domain user
DenyGroups root
DenyUsers root
TCPKeepAlive yes
MaxStartups 32

Was bedeuten die einzelnen Optionen

ListenAddress 192.168.0.1
Durch die Option kann man dem SSH-Daemon sagen, auf welche IP-Adressen er überhaupt reagieren soll. Dieses wird eingesetzt, wenn man mehrere IP-Adressen auf dem Server verwendet und angeben möchte, über die der SSH-Zugriff möglich sein soll.
Protocol 2
Mit „Protocol 2“ wird der SSH-Daemon mit dem Protokol 2 betrieben. Dieses bieten mehr Sicherhet als das alte Protokol 1.
PermitRootLogin no
Zum Beispiel sollte man den root-Login verhindern, in dem man es ausschließt sich mit root anzumelden. In der Konfiguration sieht das so aus. PermitRootLogin = no. Aber wie jetzt noch einloggen? Man sollte einen neuen Benutzer anlegen und diesem auch ein „sicheres“ Passwort vergeben. Der User sollte nicht admin, administrator, god, gott etc. heißen. Wenn man es für notwendig erachtet, kann man auch zufällig einen Benutzernamen erstellen, so wie „J3ndsp&a“. Dannach sollte man den SSH-Daemon so konfigurieren, dass nur noch der Benutzer „J3ndsp&a“ sich anmelden kann. An dieser Stelle wird es für den Angreifen schon schwieriger einen Zugriff zu erlangen. Nach erfolgreichen Login kann man den Benutzer wechseln mit „su“ oder „sudo root“. Nach dem Wechsel, hat man volle root-Rechte.
PermitEmptyPasswords no
Um das Einloggen unter gewissen Richtlinien zusetzen, kann man mit „PermitEmpy Passwords no“ definieren, dass ein Login ohne Passwort nicht möglich ist.
PasswordAuthentication yes
Weiter kann die Sicherheit mit „PasswordAuthentication yes“ erhöht werden, wenn eine Authentifizierung mit Passwörter notwendig ist. Sofern man sich für die Authentifizierung per Schüssel (Empfehlung!) entscheidt, muss hier die Einstellung „no“ verwendet werden.
LoginGraceTime 600
LoginGraceTime gibt an, nach wie vielen Sekunden die Verbindung vom Server getrennt wird, falls sich der Benutzer nicht korrekt einloggen konnte.
MaxAuthTries 3
Zusätzlich sind die möglichen Loginversuche auf 3 begrenzt.
AllowUsers
In diesem Fall könnten sich nur aufgelistete Benutzer via SSH einloggen können, allen anderen Benutzern würde der Zugang verwehrt. Einzig die Benutzer „root“ und „user“ können sich noch einloggen. Wobei der Benutzer „user“ von überall aus eine Anmeldung vornehmen kann, der Benuter „root“ hingegen nur noch aus der Domain „domain“.
DenyGroups
Auch DenyGroups und DenyUsers erschweren den Zugang. Hier kann man Gruppen bzw. Benutzer eintragen, die keinen Zugriff erhalten sollen.
DenyUsers
Welche Benutzer dürfen sich nicht einloggen.
TCPKeepAlive yes
(früher: KeepAlive) Das System verschickt TCP-Keepalive-Nachrichten, um zu prüfen, ob die Netzwerkverbindungen noch bestehen. Nach Netzwerkausfällen oder Abstürzen von Clienten-Rechnern bleiben so keine offenen Verbindungen zurück, die Ressourcen verbrauchen.
MaxStartups 32
Beschränkt die maximalen gleichzeitigen Verbindungen. Dieses beugt DDos-Angriffen vor.

Durch Firewallregeln kann man denn SSH noch sicherer betreiben, in dem man einstellt, dass nur die IP 80.81.82.83 auf den Port des SSH-Daemon zugreifen darf. Man sollte aber immer mehre IPs angeben, um im Notfall auch von anderen PCs auf SSH zugreifen zu können. Bei DSL verbindet man sich mit dynamischen IP-Adressen. Hierbei ist es sinnvoll seinw IP einmal zu protokollieren, um dann den IP-Adressbereich individuell freizuschalten. Meist sieht das so aus 80.81.x.x. Das ganze kann natürlich durch IP-Sppofing auch gefälscht werden. Aber die Wahrscheinlichkeit ist realtiv gering, dazu müsste jemand schon genauere Kenntnisse über das persönliche Netzwerk haben und die Komponenten/IT-Dienstleister dazwischen müssten für diese Art des Angriffs anfällig sein.

6. Port

Standardmäßig lautet der SSH-Port 22. Wenn ein Angreifer ein Portscan durchführt und sieht das der Port 22 offen ist, werden Sie schnell in den Logs sehen, dass man versucht in den Server einzudringen. Da Standardwerte gerne ausgenutzt werden, sollte man diese ändern. Die Änderung des Port erschwert dem Angreifer z. B. automatisierte Attacken zu starten.
Wenn Sie einen anderen Port wählen z. B. 54732, dann dauert es bei einen Portscan länger bis man zum Port kommt und man muss nun noch ermitteln, was auf diesem Port läuft. Dies dient nur zum Erschweren des Eindringens.
Man ändert daher den Port 22 einfach auf einen individuellen Wert zwischen 1 - 65535. Beachten Sie das Sie keine Standart-Ports verwenden (Portliste). Anschließend müssen Sie den SSH-Dienst nur noch neustarten mit:

Denken Sie an die Firewallkonfiguration, sonst sperren Sie sich selbst aus!
/etc/init.d/ssh reload

7. Sperren statt blocken

Ein wichter Schritt in die richtige Richtung ist es potenzieller Angreifer zu blockieren. Aber sinnvoller ist es auch den potenzielen Angreifen direkt zu sperren! Wenn jemand 15 mal das SSH-Passwort falsch eingegeben hat und immer noch Zugriff auf den Server hat, hat der Angreifer alle Zeit der Welt. Hierzu gibt es Tools wie „fail2ban“, die dieses überprüfen und dann die IP des Angreifers in die „iptables“ (Firewall) des Servers eintragen, um diesen z. B. für 24 Stunden zu sperren. So ist kein Zugriff von der IP mehr möglich.

8. Logs

Wichtig ist es auch ständig die Log-Dateien im Auge zu behalten, um auch mögliche Angriffe zu erkennen und gegensteuern zu können.

Jun 17 20:10:25 server sshd [5421] : Failed Password for root 
form 123.456.789.123 port 22 ssh2

9. Abschließendes

Sicherlich gibt es noch viele weiter Möglichkeiten mehr Sicherheit zu erzielen. Dies ist daher nur eine kleine Auswahl.


Weiterführende / Verwandte Artikel