Die Secure Shell nutzt ihr Protokoll nicht nur für eigene Dienste, sie leitet auch beliebige andere TCP-Verbindungen durch einen sicheren Tunnel. Damit SSH tatsächlich sicher ist, müssen die Schlüssellänge und die Softwareversion stimmen - im Zusammenspiel mit Firewalls ist auch einiges zu beachten.
Die Secure Shell SSH trägt das Attribut sicher schon im Namen, und zwar durchaus zu Recht. Viele ihrer Security-Dienste hat bereits der erste Teil dieses Beitrags [1] vorgestellt. Zu den interessanten Features zählt das Tunneln beliebiger TCP-Protokolle, das im Folgenden näher beschrieben wird.
Vorher sei aber die Warnung aus dem ersten Teil bekräftigt: Das SSH-Paket ist nur sicher, wenn eine aktuelle Softwareversion zum Einsatz kommt, in OpenSSH wurden wiederholt Sicherheitslücken entdeckt. Die Entwickler haben jede zwar sehr rasch behoben [http://www.openssh.com/security.html], veraltete SSH-Server sind aber weiterhin ein Sicherheitsrisiko.
Bei der Suche nach alten SSH-Servern hilft das Tool »scanssh« [2]. Es untersucht einzelne Hosts oder ganze Subnetze, ob dort SSH-Server laufen, und gibt jeweils an, um welche Version es sich handelt. Beim Aufruf ist einfach die IP-Adresse mit der Subnetzmaske als Argument zu übergeben, für einen einzelnen Host sieht das wie folgt aus:
scanssh 192.168.10.3/32
Ein Beispiel für ein ganzes Subnetz zeigt Abbildung 1, in der Ausgabe ist die Versionsnummer der installierten Server zu sehen. In Abbildung 2 untersucht Scanssh einzelne Rechner und zeigt, dass OpenSSH und Ssh.com die eigene Software auf ihren Webservern einsetzen. Scanssh setzt keine Root-Rechte voraus; negativ fällt lediglich auf, dass es nicht mit Host- oder Domain-Namen arbeiten kann und dass es bislang nur SSH-Server findet, die auf Port 22 lauschen.
Abbildung 1: Das Hilfsprogramm Scanssh durchsucht das Subnetz 129.168.10.0/24 nach SSH-Servern und gibt jeweils die exakte Version aus.
Abbildung 2: Scanssh untersucht in diesem Beispiel, welche SSH-Versionen das OpenSSH-Projekt und die Firma SSH Communications Security auf ihren eigenen Webservern einsetzen.
Beim Thema Sicherheit von SSH- und anderen Kryptographie-Programmen gab es Mitte März dieses Jahres einige Aufregung, die zur Abwechslung mal nicht von Software-Sicherheitslücken herrührt. Angeblich ist es inzwischen möglich, mit einem überschaubaren Zeit- und Geld-Bedarf RSA-Keys von 1024 Bit Länge zu entschlüsseln. Konkret ging es hier um PGP-Schlüssel, das Problem trifft aber auch auf SSH zu.
Dan Bernstein, Autor des Qmail-Mailservers, hatte im Herbst 2001 seine Forschungen über einen spezialisierten Parallelrechner veröffentlicht, der zum Faktorisieren von Ganzzahlen dient [3]. Daraufhin wurde auf der Bugtraq-Mailliste diskutiert, ob man nun alle 1024-Bit-PGP-Schlüssel zurückrufen müsse.
Krypto-Experte Bruce Schneier hat zu dieser Unruhe einige klärende Worte beigetragen ( [4], [5]). Bis zum Jahr 2005 sind seiner Meinung nach folgende Schlüssellängen ausreichend sicher:
Längere RSA-Keys sind laut Schneier nur Zeitverschwendung. Wer diesem Rat folgen möchte, bislang für SSH jedoch nur einen per Voreinstellung generierten RSA-Schlüssel mit 1024 Bit verwendet, sollte lieber auf einen neuen umsteigen. Folgendes Kommando erzeugt einen neuen RSA-Schlüssel für die Protokollversion 2:
ssh-keygen -b 1280 -t rsa -f ~/keyneu/id_rsa -C "1280-Bit-Key fuer Webmaster"
Das RSA-Schlüsselpaar (»id_rsa« und »id_rsa.pub«) mit der Schlüssellänge 1280 Bit landet dann im Verzeichnis »~/keyneu/«. Die explizite Angabe des Zielverzeichnisses mit der Option »-f« verhindert, dass das Kommando vorhandene Schlüssel in »~/.ssh/« überschreibt. Die Option »-C« ergänzt den Public Key noch mit einem Kommentar, Er dient nur der besseren Unterscheidbarkeit und hat keine Auswirkung auf die Funktion.
Neben ihrer ursprünglichen Aufgabe, einen sicheren Remote Login zu ermöglichen, kann die SSH auch fast beliebige andere Protokolle absichern: Durch Port Forwarding kann sie TCP-Ports durch die sichere SSH-Verbindung umleiten. Dabei tritt SSH ähnlich wie ein Proxy auf, der auf der einen Seite des SSH-Kanals die Verbindung entgegennimmt und sie auf der anderen Seite mit dem jeweiligen Server verbindet.
Dabei kennt SSH zwei unterschiedliche Varianten: Local Port Forwarding und Remote Port Forwarding. In den meisten Fällen ist Local Port Forwarding die passende Lösung. Es leitet eine Verbindung, die auf einem lokalen (Client-seitigen) Port eintrifft, durch den sicheren SSH-Kanal auf einen Port auf einem entfernten Server weiter. Man kann dieses Verfahren daher auch als ausgehenden Tunnel bezeichnen. Die Syntax dieses Kommandos ist recht einfach:
ssh login@remote_host -L local_port:remote_host:remote_port
Das Forwarding lässt sich beispielsweise dafür nutzen, eine POP3-Verbindung zur eigenen Mailbox abzusichern - der erste Teil zu OpenSSH [1] hatte POP3 ja bereits als potenzielle Gefahr ausgemacht. Der POP-Client überträgt das POP-Passwort schließlich im Klartext an den Server, auf dem Weg dahin ist es einfach abzuhören. Wer das verhindern will, auch wenn der Provider kein POP-SSL anbietet, kann die POP3-Verbindung durch SSH tunneln:
ssh kh@pop.remote.com -C -L 25025:pop.remote.com:110
Ein verwegenes »telnet localhost 25025« zeigt nun die Bannermeldung des entfernten POP3-Servers. Es funktioniert, ohne Root zu bemühen. Nun muss nur noch der POP-Client auf Localhost und Port 25025 eingestellt werden, um regulär seine Mail zu empfangen.
Den genauen Ablauf veranschaulicht Abbildung 4: Das SSH-Kommando baut eine normale SSH-Verbindung zum Server »pop.remote.com« auf und legt dabei zusätzlich den Tunnel an. So lange ein Login besteht, ist auch diese Weiterleitung aktiv. Verbindet sich nun ein POP3-Client (oder ein Telnet-Kommando) mit Port 25025 auf dem Client (Localhost), nimmt der SSH-Client diese Verbindung entgegen. Auf Server-Seite baut SSH die Verbindung zu Port 110 auf und leitet alle Daten weiter.
Mit einer ähnlichen Weiterleitung lässt sich die Verbindung zu Webmin absichern (siehe Kasten "Webmin konfiguriert SSH-Server"):
ssh kh@admin.remote.com -C -L 33337:admin.remote.com:10000
Daraufhin kann ein Browser den Webmin-Server durch den Tunnel kontaktieren: »https://localhost:33337/«.
Nach diesem Prinzip lassen sich viele TCP-basierte Dienste - zum Beispiel SMTP, IMAP, LDAP oder NNTP, nicht aber FTP - umleiten und tunneln. Das Problem bei FTP wird in [7] näher erläutert: Dieses Pro- tokoll nutzt neben der Kontrollverbin- dung noch zusätzlich eine Datenverbindung, deren Ports es innerhalb der Kontrollverbindung aushandelt. Damit ist es zwar leicht, den Kontrollkanal abzusichern, die Datenverbindung bleibt aber unverschlüsselt. SSH bietet dafür mit »scp« und »sftp« geeigneten Ersatz.
Abbildung 3: Das Web-basierte Administrationsprogramm Webmin bietet ein eigenes Modul an, um SSH-Server bequem zu konfigurieren. Es gibt aber einiges zu bedenken (siehe Kasten).
Abbildung 4: Beim lokalen Forwarding leitet SSH eine Verbindung, die beispielsweise auf Port 25025 des Client-Rechners ankommt, durch den Tunnel weiter zum Server. Dort endet sie auf Port 110.
Abbildung 5: SSH kann TCP-Verbindungen auch zu einem Server weiterleiten, der auf einem anderen Rechner als der SSH-Daemon läuft. Die Verbindung zwischen »ssh.remote.com« und »pop.remote.com« ist dabei nicht geschützt.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
