Linux Techblog

SSH (Secure Shell) ist sowohl ein Protokoll als auch eine Reihe Von Anwendungen um dieses zu nutzen. Es wird genutzt um eine Verschlüsselte Verbindung zu entfernten Rechnern aufzubauen. Diese Verbindung kann dann quasi beliebige Daten transportieren, wird aber zumeist dafür benutzt eine Remotekonsole zu steuern oder Dateien zu übertragen (Secure Copy, SCP genannt). Das Protokoll ist auf OSI Schicht 7 angesiedelt und kommuniziert Standardmäßig (nach den Vorgaben der IANA) über Port 22.

Obwohl SSH an sich schon sehr Sicher ist, kommt es doch gelegentlich zu erfolgreichen Angriffen die es dem Angreifer dann natürlich unter Umständen ermöglichen Root-Rechte zu erlangen. Häufigste Ursache für den erfolgreichen Angriff sind in der Praxis meist schwache Passwörter und falsch konfigurierte SSH Daemons. Aus diesem Grund möchte ich hier darauf eingehen wie man den SSH Zugriff gegen diese beiden Faktoren härten kann.

Welcher Daemon ist der richtige?

Hier könnte man sich nun sicher schön streiten, jedoch ist OpenSSH nach angaben von openssh.org mit über 80% der meist Vertretene SSH-Daemon überhaupt, weshalb ich hier nur auf diesen eingehen Möchte. Zudem wird er von allen wichtigen Linux Distributionen schon in Paketform mitgeliefert und selbst unter Mac OS X läuft dieser Seit version 10.1. OpenSSH unterstützt beide Protokollversionen und liegt derzeit in Version 5.0 (vom 03. April 2008) vor. Die Sammlung von kleinen Tools umfasst neben dem eigentlichen Serverprogramm sshd auch die Clientprogramme ssh, scp und sftp zur verfügung. Dazu gesellen sich dann noch die Werkzeuge ssh-add, ssh-agent, ssh-keysign, ssh-keyscan, ssh-keygen und sftp-server. Die anderen Daemons sind aber sicher auch nicht schlecht.

1. Stufe: Protokollversion

Sicherheitshalber sollte heutzutage nur noch die SSH-Protokoll Version 2 genutzt werden. Die Version 1 ist durch die Verwendung des recht schwachen CRC-32 (Cyclic Redundancy Check mit 32 Bit) anfällig für einen Man in the Middle Angriff in dem gefälschte Pakete in die Verbindung eingeschleußt werden können. Der Patch der dies erkennen sollte (SSH CRC32 attack detection) lässt sich aber zu einem Speicherüberlauf überreden der es erlaub die Authentifizierung zu umgehen. Die Protokollversion 2 festzulegen ist ganz einfach in dem man zunächst in der SSH-Konfiguration (/etc/ssh/sshd_config) darauf achtet das hinter Protocol außschließlich eine 2 steht und anschließend den SSH-Daemon neu startet.

/etc/init.d/ssh restart

Dies kann Problemlos auch aus einer SSH-Session heraus geschehen - bestehende Verbindungen werden bei dem Neustart nicht abgebrochen.

2. Stufe: Publickey Authentifizierung

Unter bestimmten Umständern kann es unheimlich praktisch sein beim Administrieren verteilter Rechner Zeit zu sparen in dem man sich beim SSH oder SCP Login nicht mit einem Passwort authentifizieren bzw. sich nur ein Passwort für alle Systeme merken muss. Als Beispiel seien hier Verbindungen verschiedener Clusternodes untereinander, Virtueller Maschinen vom Virtualisierungsserver aus oder innerhalb des Heimnetzwerkes genannt.

Hierzu wird ganz einfach ein Schlüsselpaar erstellt welches welches aus einem Privaten und einem Öffentlichen Schlüssel besteht. Der Private Schlüssel wird dabei im Benutzerprofil gespeichert, der Öffentliche Schlüssel wird auf dem Zielsystem hinterlegt. Beim Verbindungsaufbau wird nun vom Server ein Zufälliger Text erstellt und mit dem Öffentlichen Schlüssel verschlüsselt. Dieser verschlüsselte Text wird dann an den Client gesendet welcher den Text mit seinem Privaten Schlüssel entschlüsseln kann. Diesen entschlüsselten Text sendet er an den Server zurück wodurch er bestätigt dass er im Besitz des Privaten Schlüssels ist. Wenn der empfangene Text mit dem Ursprungstext übereinstimmt ist sicher gestellt das der Client auch wirklich Vertrauenswürdig ist.

In der Praxis funktioniert das natürlich alles von selbst. Hierbei wird zunächst mit ssh-keygen ein Schlüsselpärchen erstellt. Dabei wird mit -t der Schlüsseltyp übergeben.

ssh-keygen  -t rsa

Dabei wird man zunächst nach dem identity file gefragt (standard mäßig ist das <homedir>/.ssh/id_dsa) in dem später der private schlüssel gespeichert wird. Dann bekommt man die Gelegenheit ein Passwort für den schüssel einzugeben. Je nach Anwendungsgebiet ist das schwer zu empfehlen. Man tauscht ja nur das Passwort gegen eine “Datei” - dabei würde die Sicherheit natürlich nur geringfügig erhöht. Deswegen wird hier ein passwort fetsgelegt welches dann zur benutzung des Schlüssels gebraucht wird. Nach der wiederhohlten Passworteingabe wird der Fingerprint des öffentlichen Schlüssels ausgegeben - dieser braucht hier aber nicht weiter zu interessieren.

Neben dem Identiy file legt ssh-keygen auch noch eine gleichnamige .pub Datei an in der sich der zugehörige Öffentliche Schlüssel befindet. Der inhalt dieser Datei muss nun auf dem Zielrechner als Autorisierter Schlüssel eingetragen werden. Dazu wird einfach der Inhalt der Datei auf dem Zielsystem in die <homedir>/.ssh/authorized_keys Datei eingefügt.  Der letzte Schritt ist nun in der SSH-Konfiguration (/etc/ssh/sshd_config) die entsprechenden Optionen zu aktiveren. Im wesentlichen sind das:


PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys


Selbsterklärend eigentlich wird zunächst diese Authentifizierungsmethode freigegeben und anschließend festgelegt in welcher Datei der Öffentliche Schlüssel zu suchen ist. Nach einem neustart des SSH-Daemons sollte das ganze funktionieren.

3. Stufe: Logfileauswertung

Ein wenig Paranoid mag dieser Weg erscheinen, doch auch wenn man bereits die Publicey Authentifizierung nutzt kann ein Bruteforceangriff natürlich nicht ausgeschlossen werden. Die Chancen hier tatsächlich noch einen Treffer zu landen tendieren stark gegen Null, doch ist dies eine sehr effektive Angriffsmethode um den Angreifer auch von anderen gefährdeten Diensten fern zu halten. Jeder Anmeldeversuch wird in eine Logdatei geschrieben und protokoliert. Hier ist es also eigentlich sehr leicht einen Bruteforceangriff zu erkennen. Natürlich schaut aber niemenad ständig in diese Logfiles und wenn man mal einen blick dafür findet ist es eventuell schon zu spät. Selbst wenn der Angreifer nach einer weile entnervt aufgeben sollte könnte er eventuell versuchen den FTP oder Webserver zu kompromitieren - hier kann man also geschickt vorgreifen.

Wichtig zu nennen sind hier zwei Programme: swatch, welches alle Möglichen Logfiles überwachen und mit Hilfe regulärer Ausdrücke auswerten kann und denyhosts (http://denyhosts.sourceforge.net/), welches speziell auf das auswerten fehlgeschlagener SSH Verbindungen ausgerichtet ist. Beide Dienste schreiben die IP-Adresse des Angreifers in die /etc/hosts.deny. Zweit genannter mag zwar “weniger können”, erfüllt seinen job dafür aber zuverlässiger, da die Verarbeitung der Logfiles hier ständig durch die Authoren gepflegt wird - aus diesem Grund entscheide ich mich für denyhosts.

Distributionsabhängig ist denyhosts bereits ab Werk als Paket verfügbar. In meinem Besipiel nutze ich Debian, es ist allerings auch nicht wirklich schwer es aus den Quellen zu installieren. Es ist lediglich von Python v2.3 oder höher abhängig.

aptitude install denyhosts

Unter Debian ist die Installation wie immer sehr leicht. Das Distributionseigene Paket ist im Prinzip bereits in einem Funktionsfähigen Zustand. Trotzdem sollte man sich bestimmte Parameter der /etc/denyhosts.conf anschauen. In den meisten Distributionspaketen ist die Standarkonfigurationsdatei sehr gut Dokumentiert. Unter /usr/share/denyhosts/denyhosts.cfg-dist sollte sich andernfalls aber ein gut Dokumentiertes Beispiel finden.

• SECURE_LOG: Aus dieser Datei liest denyhosts die Fehlgeschlagenen Loginversuche ab
• HOSTS_DENY: In diese Datei werden die Erkannten IP-Adressen geschrieben
• BLOCK_SERVICE: Dieser Dienst wird als zu blockierender Dienst angegeben. Standardmäßig steht hier sshd, dies sollte auf jedenfall durch “ALL” erstezt werden, damit auch andere Dienste wie der Webserver keine Verbindungen mehr von diesem Host annehmen
• DENY_THRESHOLD_INVALID: Die Anzahl an Fehlversuchen die ein Host starten darf bis er gesperrt wird
• SMTP_* und ADMIN_EMAIL: Diese Optionen erlauben es sich über gesperrte Host per E-Mail informieren zu lassen.

Zum Abschluss muss der Dienst nach den Anpassungen noch neu gestartet werden.



sh /etc/init.d/denyhosts restart

Um sicher zu stellen das auch wirklich alles Funktioniert sollte man sich von einem anderen Host einfach versuchen einige Male hintereinander “falsch” anzumelden. Nach einigen Versuchen sollte die IP-Adresse in der hosts.deny auftauchen (und es sollte keine Verbindung mehr möglich sein), wo man sie beim selbsttest natürlich einfach wieder entfernen kann. Falls man das nicht manuel tuen möchte kann denyhosts auch so konfiguriert werden dass die Adressen selbstständig freigegeben werden.