Absichern und härten von SSH unter Debian:

Unser Kollege „LordF“ aus dem securITy-dome.eu Forum hat eine Anleitung zum Absichern und Härten von SSH (Secure Shell) geschrieben. Für diese tolle und umfangreiche Arbeit – und natürlich die Erlaubniss zur Veröffentlichung - meinen herzlichsten Dank an „LordF“!



Themen dieses Berichts (was Sie erwartet):



Hier die Anleitung von „LordF“:



Allgemein:

Wenn man einen Server aufstellt, sollte man darauf achten, dass dieser möglichst wenig Schwachstellen hat. Der sich eingebürgerte Begriff dazu nennt sich "Härten" eines Systems, wenn man die Konfiguration so weit einengt, dass nur noch die gewünschte Funktionalität übrig bleibt.



Aufgabe:

Ziel meinerseits ist es irgendwann einen privaten Server zu Hause aufzusetzen und zu betreiben. Die Wahl meinerseits viel dabei auf die Linux Distribution Debian.

Die Schwierigkeit dabei: Dieser Server soll auch aus dem Internet administrierbar sein.

Um dieses zu gewährleistet wird SSH eingesetzt. Seit Jahren wohl bekannt und entsprechend sicher. Aber nicht gehärtet. Jedenfalls nicht in der Grundeinstellung.

Entsprechendes wollte ich dann machen und habe zu Übungszwecken eine virtuelle Maschine mit dem aktuellsten Debian aufgesetzt. Die eingebaute NAT Funktionalität von aktuellen virtuellen Maschinen erlauben einen realitätsnahen Test des Servers hinter einem Router.



SSH härten – Schritt 1:

Gibt man bei aktuellen Suchmaschinen diese Begriffe ein, erhält man eine Vielzahl von Webseiten, die im Grunde alle das Gleiche aussagen. Am besten hat mir die Seite von Debian gefallen, aus der ich zitieren möchte. Die Seite finden Sie in dem Abschnitt --> „Externe Links“.

Zitat:

Schließlich sollten Sie noch die Datei /etc/ssh/sshd_config für mehr Sicherheit modifizieren:



ListenAddress 192.168.0.1

Lassen Sie ssh nur auf eine bestimmte Schnittstelle hören, falls Sie mehrere haben (und ssh nicht auf allen verfügbar sein soll) oder Sie in Zukunft eine neue Netzwerkkarte einbauen werden (und keine ssh-Verbindungen auf ihr erlauben wollen).



PermitRootLogin no

Versuchen Sie so wenige Logins als Root wie möglich zu erlauben. Wenn nun jemand Root werden will, benötigt er zwei Logins. So kann das Root-Passwort nicht so leicht ausgetestet werden.



Port 666 oder ListenAddress 192.168.0.1:666

Verändern Sie den Listen-Port, so dass ein Eindringling nicht wirklich sicher sein kann, ob ein sshd-Daemon läuft (aber beachten Sie, dass dies lediglich "Sicherheit durch Verschleierung" ist).



PermitEmptyPasswords no

Nicht gesetzte Passwörter verspotten jegliche System-Sicherheit.



AllowUsers alex ref ich@irgendwo

Erlauben Sie nur bestimmten Nutzern sich via ssh auf der Maschine einzuloggen. user@host kann auch verwendet werden, um einen bestimmten Benutzer user dazu zu zwingen, nur von einem bestimmten Rechner host aus zuzugreifen.



AllowGroups wheel admin

Erlauben Sie nur bestimmten Gruppenmitgliedern sich via ssh auf der Maschine einzuloggen. AllowGroups und AllowUsers haben äquivalente Verfahrensweisen, um den Zugang zu der Maschine zu verwehren. Es wird nicht überraschen, dass es sich hierbei um "DenyUsers" und "DenyGroups" handelt.



PasswordAuthentication yes

Es ist allein Ihre Wahl, was Sie hier eintragen. Es ist sicherer, Zugriff nur Nutzern zu erlauben, die ssh-Schlüssel in der ~/.ssh/authorized_keys-Datei haben. Wenn Sie dies wollen, setzen Sie es auf "no".

Schalten Sie jedwede Art der Authentifizierung ab, die Sie nicht wirklich benötigen, zum Beispiel RhostsRSAAuthentication, HostbasedAuthentication, KerberosAuthentication oder RhostsAuthentication. Sie sollten sie abschalten, auch wenn sie es standardmäßig bereits sind (siehe dazu die Handbuch-Seite sshd_config(5)).



Protocol 2

Deaktivieren Sie die Protokollversion 1, da diese einige Designschwächen hat, die es einfacher zu machen, Passwörter zu knacken. Für weitere Informationen lesen Sie a paper regarding ssh protocol problems oder das Xforce advisory.



Banner /etc/eine_Datei

Fügen Sie einen Bannertext (er wird aus der Datei bezogen) für Benutzer, die sich mit dem ssh-Server verbinden, hinzu. In einigen Ländern sollte das Senden einer Warnung über unautorisierten Zugriff oder Benutzerüberwachung vor dem Zugriff zu einem bestimmten System erfolgen, um sich rechtlich abzusichern.



Viele von diesen Einstellungen sind in der Standardinstallation schon so vorhanden und müssen nicht noch extra angepasst werden.

Mit diesen Einstellungen erhält man schon eine umfangreiche Sicherheit. Und ist für die alltäglichen und privaten Dinge ausreichend.

Da man aber bei der IT-Security von einer grundlegenden Paranoia geplagt wird, hinterfragt man diese kleine Anleitung und fragt sich wozu all diese anderen Parameter in der Konfigurationsdatei wohl gut sind.



SSH härten – Schritt 2:

Ich nenne das einfach mal SSH härten 2.0:

Über die Manpage von sshd_config(5) (Siehe Abschnitt --> „Externe Links“) findet man eine ausführliche Beschreibung der Einstellungen.

Entsprechend kommen zu den obigen Empfehlungen diese noch hinzu:



RSAAuthentication no

Ist nur für Protokoll Version 1 von Bedeutung.



PasswordAuthentication no

Hiermit wird die Authentifizierung mit dem Passwort des Users ausgeschaltet.



MaxStartups 3

Es dürfen maximal 3 Anmeldefenster geöffnet werden. Nimmt Last vom System und wirkt ein wenig einem DOS entgegen.



AuthorizedKeysFile %h/.ssh/authorized_keys

Liste der Zertifikate, die sich mit den System verbinden dürfen. %h steht hier für das Verzeichnis des Users, welcher sich am System anmeldet.



MaxAuthTries 3

Nach drei Fehlversuchen sich zu verbinden, wird die Verbindung getrennt.



AllowUsers username

Eine Aufzählung der User, die eine SSH Verbindung aufbauen dürfen.



SSH härten – Schritt 3 (Optional):

Optional Einstellungen:



DenyUsers

Welche User sich nicht mit SSH verbinden dürfen.



AllowGroups

Welche Gruppen sich mit SSH verbinden dürfen.



DenyGroups

Welche Gruppen sich nicht mit SSH verbinden dürfen.



Ciphers aes256-cbc,aes256-ctr,blowfish-cbc,arcfour256

Konfiguration, welche Cipher-Suits verwendet dürfen.



Compression yes

Kompression für die Verbindung einstellen.



Anmeldung mit Zertifikaten:

Mit dieser Konfiguration ist es nun notwendig, sich mit einem Zertifikat am System anzumelden. Ansonsten wird die Verbindung sofort wieder getrennt. Und auf den ersten Blick kann man auch nicht erkennen, ob ein gültiger Benutzername angegeben worden ist. Als Fehlermeldung kommt üblicherweise, das ein falscher "public key" verwendet wurde.

Erstellen von Zertifikaten:

Um sich nun mit dem System verbinden zu können, ist es erforderlich ein Zertifikat zu erstellen. Da ich hauptsächlich Windows nutze, habe ich dafür den Schlüsselgenerator von Putty (Siehe Abschnitt --> „Externe Links“) genutzt (Puttygen), der seine Zufallswerte auf Mausbewegungen basiert. Auch kann man bequem die Schlüssellänge einstellen. Und nicht zu vergessen sehr einfach den Privaten Schlüssel in Putty einbinden, um zu dem Server die Verbindung aufzubauen.

Einbinden von Zertifikaten:

Wenn dann das Schlüsselpaar erzeugt wurde, muss der öffentliche Schlüssel noch in der Datei hinterlegt werden die unter AuthorizedKeysFile definiert wurde. Und das in der Form:

ssh-rsa %PUBLICKEY% %USERNAME%@%HOSTANME%

Die %X% sind als Variablen zu verstehen und mit entsprechendem Inhalt zu füllen. Z.B.: ssh-rsa AAAA...== username@xxx-test

Abschliessen der Konfiguration:

Sind alle diese Konfigurationen eingestellt, den sshd neustarten (/etc/init.d/ssh restart) und es kann losgehen. In Putty wird dann im Reiter "Connection->SSH->Auth" noch die "Private key file for authentication:" definiert und man kann sich mit dem System verbinden.

Das empfinde ich als Sicher und werde das auch irgendwann auf das Internet loslassen. Einziges Manko: FileZilla kann nicht mit Zertifikaten umgehen, wenn es SSH Verbindungen aufbaut. Man müsste dazu wahrscheinlich WinSCP nutzen (ungetestet).



SSH härten – Schritt 4:

Momentan ist die aktuellste Version von OpenSSH leider noch nicht als Debian Paket vorhanden. Denn dann könnte man für das interne LAN noch eigene Regeln aufbauen.

Ab der Version 4.3p2 ist das Match Attribut verfügbar, mit dem man Regeln erstellen kann. So könnte man Beispielsweise Verbindungen aus dem internen Netz erlauben sich auch mit einem Passwort anzumelden.

Was wäre das Leben ohne Zukunftsaussichten.



Ausschluss:

Ich habe mich nicht mit der Kerberos und GSSAPI Funktionalität auseinandergesetzt. Diese sind, so denke ich, aber mächtige Werkzeuge für entsprechende Netzwerke.

So. Ich hoffe das ist ausführlich und verständlich genug.



Externe Links:

Debian Absichern – Inhalt: http://www.debian.org/doc/manuals/securing-debian-howto/index.de.html

Debian Anleitung – Absichern von SSH: http://www.debian.org/doc/manuals/securing-debian-howto/ch-sec-services.de.html#s5.1

OpenBSD – Manual Page: http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5

Putty: http://www.chiark.greenend.org.uk/~sgtatham/putty/



Weitere Informationen bzw. zur Diskussion dieses Beitrags besuchen Sie unser Forum unter -->

http://www.security-dome.eu/forum/pA/index.php




Autor: Frank Richter

Co-Autor: LordF

Copyright: Frank Richter – securITy-dome.eu

Erstellungsdatum: 14.11.07

Letzte Aktualisierung: 14.11.07



<-- Zurück zu den News