Verantwortlich für Initiierung: Leiter IT, IT-Sicherheitsmanagement
Verantwortlich für Umsetzung: Administrator, Benutzer
Ohne spezielle Erweiterungen bieten die Protokolle telnet und ftp nur rudimentäre Mechanismen zur Authentifizierung. In der Regel wird eine einfache Abfrage von Benutzerkennung und Paßwort durchgeführt, die dann - ebenso wie die Nutzdaten - im Klartext gesendet werden. Die Vertraulichkeit der Authentifizierungs- und Nutzdaten ist also nicht gesichert. Die verwandten Protokolle rsh, rlogin und rcp, die oft unter der Bezeichnung r-Dienste zusammengefaßt werden, weisen ähnliche Sicherheitsmängel auf.
Secure Shell (ssh) kann als Ersatz für die r-Dienste genutzt werden, wobei umfangreiche Funktionen zur sicheren Authentifizierung und zur Wahrung von Vertraulichkeit und Integrität zum Einsatz kommen. Hierzu wird ein hybrides Verschlüsselungsverfahren, also eine Kombination aus asymmetrischer und symmetrischer Verschlüsselung, verwendet. Angesiedelt ist die Secure Shell auf Schicht 7 (Anwendungsschicht) des ISO/OSI-Referenzmodells, allerdings können auch andere Protokolle wie das X11-Protokoll, das von der graphischen Oberfläche X-Windows verwendet wird, über ssh transportiert werden.
Derzeit basiert Secure Shell auf drei Protokollen, die aufeinander aufbauen und für die jeweils ein Internet-Draft existiert.
Für alle gängigen Unix-Betriebssysteme existieren Implementierungen sowohl von ssh -Clients als auch von ssh -Servern. Darüber hinaus gibt es ssh -Clients unter anderem für 32 Bit Windows, OS/2, Macintosh und als Java-Applet.
Grundsätzlich ist der Einsatz von Secure Shell zu empfehlen, wenn die Funktionalitäten der r- Dienste über Kommunikationskanäle genutzt werden, die nicht ausreichend gegen Kompromittierung und/oder Manipulation gesichert sind (z. B. über das Internet). Im folgenden werden einige Hinweise für den sicheren Einsatz von ssh gegeben.
Von besonderer Bedeutung ist die Gefährdung durch sogenannte man-in-the-middle - Attacken. Hierbei filtert der Angreifer den gesamten Verkehr zwischen den Kommunikationspartnern und reicht gefälschte öffentliche Schlüssel weiter. Ist es den Kommunikationspartnern nicht möglich, die öffentlichen Schlüssel zu prüfen, kann der Angreifer den gesamten Verkehr lesen und manipulieren, indem er die Daten jeweils selbst entschlüsselt, dann liest bzw. modifiziert und schließlich mit einem anderen Schlüssel verschlüsselt und weiterleitet. Dies kann mit Hilfe eines geeigneten Schlüssel-/Zertifikatmanagements verhindert werden. Beim praktischen Einsatz von Secure Shell wird jedoch oft eine Kompromißlösung angewandt, die den Einsatz von ssh ohne jede zusätzliche Infrastruktur erlaubt. Dabei wird bei einem Verbindungsaufbau zu einem Host, dessen öffentlicher Schlüssel noch nicht bekannt ist, dieser über das unsichere Netz gesendet und in einer lokalen Datenbank abgelegt. Bei allen nachfolgenden Verbindungen mit diesem Host kann dessen öffentlicher Schlüssel dann anhand der lokalen Datenbank überprüft werden. Im Rahmen des Sicherheitskonzeptes muß geklärt werden, ob dieses Verfahren, das eine reduzierte Sicherheit gegenüber man-in-the-middle -Angriffen bietet, für die vorliegende Anwendung ausreichend ist.
In den Internet-Drafts sind kryptographische Verfahren festgelegt, die von den Secure Shell- Implementierungen zur Verfügung gestellt werden müssen. Optional können jedoch zusätzliche kryptographische Algorithmen implementiert werden. Die tatsächlich benutzten Verfahren werden beim Verbindungsaufbau ausgehandelt. Durch Wahl geeigneter Client- und Server-Programme und durch entsprechende Konfiguration ist sicherzustellen, daß sich ssh -Client und ssh - Server auf qualifizierte kryptographische Algorithmen einigen, die den Sicherheitsanforderungen genügen.
Wenn ssh zum Einsatz kommt, sollten nach Möglichkeit alle anderen Protokolle, deren Funktionalität durch Secure Shell abgedeckt wird, also z. B. die r-Dienste und telnet, vollständig abgeschaltet werden, damit die Sicherheitsmaßnahmen nicht umgangen werden können. Dies setzt allerdings voraus, daß alle Kommunikationspartner über geeignete Implementierungen verfügen.
Von älteren Implementierungen von ssh sind sicherheitsrelevante Programmfehler bekannt. Es sollte daher eine Version verwendet werden, bei der solche Mängel beseitigt sind. Die Kompatibilität zwischen Implementierungen, deren Programmversionen sich stark unterscheiden, ist u. U. problematisch. Ein Mischbetrieb sollte deshalb möglichst vermieden werden.
Zu beachten ist, daß beim Einsatz von ssh über Firewalls eine inhaltssensitive Kontrolle des Datenstroms nicht mehr möglich ist.
Ergänzende Kontrollfragen:© Copyright by Bundesamt für Sicherheit in der Informationstechnik 2000.