Bundesamt für Sicherheit in der Informationstechnik

M 5.64 Secure Shell

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Ohne spezielle Erweiterungen bieten die Protokolle telnet und ftp nur rudimentäre Mechanismen zur Authentisierung. In der Regel wird eine einfache Abfrage von Benutzer-Kennung und Passwort durchgeführt, die dann - ebenso wie die Nutzdaten - im Klartext gesendet werden. Die Vertraulichkeit der Authentisierungs- und Nutzdaten ist also nicht gesichert. Die verwandten Protokolle rsh, rlogin und rcp, die oft unter der Bezeichnung r-Dienste zusammengefasst werden, weisen ähnliche Sicherheitsmängel auf.

Secure Shell (ssh) kann als Ersatz für die r-Dienste genutzt werden, wobei umfangreiche Funktionen zur sicheren Authentisierung 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-Window 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.

  • Das unterste Protokoll ist das Transport Layer Protocol. Dieses Protokoll leistet den Großteil der Sicherungsfunktionen von ssh, nämlich Authentisierung auf Host-Ebene, Verschlüsselung und Schutz der Datenintegrität. Die kryptographischen Algorithmen sind zwischen den Kommunikationspartnern aushandelbar.
  • Das mittlere Protokoll ist das User Authentication Protocol. Dies erlaubt die Authentisierung auf Benutzer-Ebene, wobei auch hier das Verfahren ausgehandelt werden kann. Wenn zur Authentisierung eine einfache Übertragung von Benutzer-Kennung und Passwort verwendet wird, so ist die Vertraulichkeit dieser Informationen gegenüber dem Kommunikationsweg durch das darunterliegende Transport Layer Protocol gesichert. Empfohlen wird jedoch die Authentisierung durch ein Public-Key-Verfahren.
  • Das Connection Protocol baut auf den beiden vorhergehenden Protokollen auf und erlaubt den Aufbau von mehreren logischen Nutzkanälen. Die Daten auf diesen Nutzkanälen werden gemeinsam über eine einzelne abgesicherte Secure Shell-Verbindung übertragen.

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 Windows, Mac OS 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 so genannte 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 Kompromisslö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 muss 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, dass 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, dass 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 unter Umständen problematisch. Ein Mischbetrieb sollte deshalb möglichst vermieden werden.

Zu beachten ist, dass beim Einsatz von ssh über Firewalls eine inhaltssensitive Kontrolle des Datenstroms nicht mehr möglich ist.

Prüffragen:

  • Bei hohen Schutzbedarf vor man-in-the-middle-Angriffen: Wird ein geeignetes Schüsselmanagement und Zertifikatmanagement verwendet?

  • Wird nach Möglichkeit nur eine einzige aktuelle Version von ssh verwendet?

Stand: 13. EL Stand 2013