Blog

Bis heute wurde eine Vielfalt von Protokollen entwickelt, welche für jede Übertragungsform von Daten geeignet ist: zum Beispiel das RTP (Real-Time Transport Protocol) ist ein Protokoll zum kontinuierlichen Streaming von Daten oder Telnet für die Fernverwaltung von Servern. Leider unterstützen viele von diesen Protokollen (z.B. Telnet) nicht eine verschlüsselte Verbindung zwischen dem Client und dem Server und sogar wird die Benutzerauthentifizierung unverschlüsselt übermittelt. Folglich sind die übertragenen Daten von einem Angreifer abhörbar. Um dieses Problem zu beheben, wurde ein Protokoll entwickelt, welches vollständig die Protokolle Telnet und RSH (Remote Shell) ersetzt und den Datenaustausch von anderen Protokolle durch die so genannte „Tunnels“ zu verschlüsseln ermöglicht: Die Datenpakete von einem anderen Protokoll werden in SSH-Pakete eingepackt. Dieses Protokoll heisst SSH (Secure Shell).

Diese Arbeit befasst sich mit dem „Secure Shell“ SSH-Protokoll Version 2. Am Anfang dieser Arbeit wird ein Überblick über seine Geschichte und über die Grundfunktionen des Protokolls erläutert. Danach in den Kapiteln 2.3, 2.4, 2.5 und 2.6 wird erklärt wie ein SSH-Paket aufgebaut ist und was es für Client- und Serverprogramme gibt, wo das SSH-Protokoll implementiert wird. Im letzten Teil der Arbeit werden die zwei wichtigsten Grundfunktionen des Protokolls anhand von praktischen Beispielen gezeigt.

Die Ziele dieser Arbeit sind:

➢       Geschichte von SSH kennenlernen

➢       Funktionsweise des SSH-Protokoll verstehen

➢       Installation von Client und Server

➢       Mit einem SSH-Server verbinden und diesen fernsteuern

➢       Einen „Tunnel“ erstellen

1 Einleitung

2 SSH

2.1 Geschichte

2.2 Grundfunktionen

2.3 Verbindungsaufbau

2.4 Protokollebene

2.5 Protokollanalyse mit Wireshark

2.6 Open Source Client und Server

3 Einsatz

3.1 Remote Fernsteuerung

3.2 Tunneling

2 SSH

2.1 Geschichte

In Wikipedia ist folgendes zu finden:

„Die erste Version des Protokolls (jetzt SSH-1 genannt) wurde 1995 von TatuYlönen als Reaktion auf die Nachfrage nach Drop-in-Replacements für Berkeley Services unter Unix einschließlich der Befehle rsh (remote shell), rcp (remote copy) und rlogin (remote login) entwickelt. Er veröffentlichte seine Implementation 1995 als Freeware, die daraufhin relativ schnell an Popularität gewann; Ende des Jahres 1995 zählte man bereits 20.000 Benutzer in fünfzig Ländern. Im Dezember gründete TatuYlönen die Firma SSH Communications Security, um SSH zu vermarkten und weiterzuentwickeln. Die Originalsoftware enthielt ursprünglich Open-Source-Quellcode, entwickelte sich aber im Laufe der Zeit immer mehr zu proprietärer Software. Nachdem einige Schwachstellen in der Integritätsprüfung von SSH-1 bekannt geworden waren, wurde 1996 mit SSH-2 eine überarbeitete Version des Protokolls entwickelt. Sie ist inkompatibel zu SSH-1. Dabei wurde unter anderem das Protokoll in verschiedene Einzelteile aufgegliedert und somit die Verwendung sicherer Verschlüsselungs- und Authentifikations-Algorithmen ermöglicht. Damit wurde die Schwachstelle beseitigt, und derzeit gilt das Protokoll als sicher. 1999 wurde der Wunsch nach einer freien Implementation von SSH laut, und aus der letzten freien Version der Originalimplementation entwickelte sich das separate OpenSSH-Projekt. Spätestens seit dieser Zeit existiert das SSH-Protokoll in zwei Implementationen: Als Open-Source-Software (OpenSSH) und als proprietäre Software (Produktname: SSH Tectia), entwickelt und vertrieben von der Firma SSH Communications Security, also den Original-Entwicklern rund um Ylönen. 2005, also zehn Jahre nach der Original-Entwicklung, ist die Firma SSH Communications Security mit der Generation 3 (SSH G3) an die Öffentlichkeit gegangen. Dieses Protokoll unterstützt die Verwendung des proprietären Snakeoil-Algorithmus „CryptiCore“ (Vorteile angeblich vor allem im Datendurchsatz), der jedoch als unsicher gilt (siehe „Verschlüsselung“). Die anderen, etablierten Verschlüsselungsalgorithmen werden weiterhin ebenfalls unterstützt. 2006 wurde dieses Protokoll (Version 2) von der IETF als Internetstandard vorgeschlagen.“[1]

2.2 Grundfunktionen

SSH bietet die folgenden Grundfunktionen:

• Vertraulichkeit, Authentifizierung, Autorisierung und Integrität
• Fernsteuerung von Servern
• Übertragung von Daten: SFTP, SCP (Secure Copy) sind Alternativen zu FTP und RCP
• SSHFS (entferntes Dateisystem auf dem lokalen Rechner mounten)
• Aufbau von Tunnels
• X11 über SSH transportieren (X11 ist ein Netzwerkprotokoll und eine Software, die Fenster auf Bitmap-Displays in den meisten unixoiden Betriebssystemen und OpenVMS ermöglicht.)

2.3 Verbindungsaufbau

Heutzutage wird nur die zweite und die dritte Version von SSH verwendet, da SSH-1 Schwachstellen enthält: Ein Angreifer könnte eine SSH-1 Sitzung wegen den Schwachstellen der verwendeten Integritätsprüfung (CRC-32) abnehmen.

Ab Version 2 werden die folgenden Sicherheitsanforderungen erfüllt:

Datenintegrität: Während der Übertragung von Daten auf einem Trägersignal passiert es oft, dass äussere Störungen den Bitstrom beeinflussten oder die Pakete wurden durch einen Angreifer manipuliert: Folglich ist das Datenpaket unbrauchbar. Das Sicherheitsmanagement muss die Integrität der Datenpakete gewährleisten und das wird durch eine Prüfsumme erreicht. Im SSH-2 werden die Algorithmen hmac-sha1 und hmac-md5 verwendet.

Vertraulichkeit: Sie wird durch die symmetrische Verschlüsselung realisiert. Hier kommen die folgenden Verschlüsselungen im Spiel: 3DES, Blowfish, Twofish, CAST, IDEA, Arcfour, SEED und AES. Standardmässig wird für SSH2 das AES mit einem 128 Bit Schlüssel gearbeitet. SSH-3 verfügt über einen neuen Verschlüsselungsalgorithmus und zwar der Snakeoil-Algorithmus „CryptiCore“. SSH unterstützt auch die asymmetrische Verschlüsselung (RSA, DSA), jedoch wird diese nur bei der Teilnehmerauthentifizierung eingesetzt.

Server-Authentifizierung und Client-Authentifizierung: Unter diesem Begriff versteht man, dass die Identität der Teilnehmer sichergestellt wird. Ist der Server oder Client wirklich derjenige, für den er sich ausgibt? SSH bietet dem Benutzer mehrere Möglichkeiten sich am Server zu identifizieren. Die einfache Variante ist, dass sich der Benutzer mit dem Login des Betriebssystems einloggt. Eine andere Variante, die heute am meistens verwendet wird, ist die Public-Key-Authentifizierung (RSA oder DSA): Der Client muss immer ein Schlüsselpaar (public und private key) generieren. Der öffentliche Schlüssel soll an den Server übereicht werden. [2]

Ablauf der Verbindungsaufbau (Kombiniertes Verfahren, rote Pfeile):

• Zuerst wird ein TCP-Verbindung (Port 22) aufgebaut
• Danach schickt der Server seine Protokollversion und die verfügbaren Protokolle
• Der Client antwortet ebenfalls mit dem Senden seiner unterstützten Version und das gewählte Protokoll. Er verlangt auch den öffentlichen Schlüssel des Servers
• Der Server schickt seinen öffentlichen Schlüssel
• Der Client generiert einen Session Key und verschlüsselt ihn mit dem öffentlichen Schlüssel des Servers
• Der Server entschlüsselt den Session Key mit seinem privaten Schlüssel und ab jetzt werden alle Daten, die zwischen Server und Client ausgetauscht werden, mit einem symmetrischen Verfahren (Session Key) verschlüsselt.

Ablauf einer Authentifizierung (RSA-Verfahren, grüne Pfeile):

1. Client sendet eine Verbindungsaufbauanfrage (Login-Anfrage) am Server
2. Der Server erhält diese Anfrage und antwortet mit einer „Challenge“: Ein Zufallswert wird generiert und mit dem öffentlichen Schlüssel des Benutzers (Client) verschlüsselt.
3. Der Client entschlüsselt diesen Zufallswert mit seinem privaten Schlüssel und bildet den dazugehörigen Hashwert. Dieser Hashwert wird mit dem privaten Schlüssel verschlüsselt und dem Server geschickt.
4. Der Server entschlüsselt den empfangenen Hashwert mit dem öffentlichen Schlüssel des Benutzers und konfrontiert seinen generierten Hashwert mit dem vom Client.
5. Wenn beide Hashwerte übereinstimmen, wird der Zugriff auf dem Server zugelassen.[3,4]

2.4 Protokollebenen

SSH arbeitet auf der Anwendungsschicht (5. bis 7. Schicht OSI-Modell). Die SSH-Pakete werden immer über eine zuverlässige Verbindung auf der Transportschicht (z.B. TCP, Port 22) übermittelt.

SSH-2 Protokoll besteht aus drei Teilen (SSH Architektur RFC 4251):

• SSH Transport Layer Protocol (SSH-TRANS, RFC 4253)
• SSH Authentication Protocol (SSH-AUTH, RFC 4252)
• SSH Connection Protocol (SSH-CONN, RFC 4254)

Transport Layer Protocol: Das Transport Protocol setzt als erste Protokollebene auf. Seine Aufgaben sind: die Regelung der Aushandlung von Algorithmen, Austausch von Sitzungs-Schlüsseln usw.

Authentication Protocol: Das Authentication Protocol setzt auf dem SSH-Transport Layer Protocol auf. Seine Aufgabe ist die Client-Authentifizierung und Passwortänderung.

Connection Protocol: Es setzt auch wie das Authentication Protocol auf dem Transport Layer Protocol auf und verwaltet die TCP-Port-Forwarding, die Verwaltung von virtuellen Terminals, die Datenkomprimierung usw.[3,4]

Aufbau eines SSH-Paketes

Nach dem Verbindungsaufbau auf der Transportschicht tauschen der Client und der Server SSH-Pakete. Diese werden als Nutzdaten an einem sogenannte Service Access Point (SAP) der unterstehenden Schicht (z.B. TCP) übergeben. Ein entsprechendes Paket hat die folgende Struktur:

• Gesamtlänge von Paketlänge inklusive Padding muss ein vielfaches der Blocklänge oder ein vielfaches von 8 ergeben
• Maximale Blocklänge: < 35‘000 Byte
• Paketlänge = Paddinglänge + Nutzdaten + Padding
• Nutzdaten: falls Kompression aktiviert, wird dieses Feld mit zlib komprimiert
• MAC: Checksumme (hmac-sha1 oder hmac-md5) des gesamten Paketes. Sie wird vor der Verschlüsselung berechnet.

2.5 Protokollanalyse mit Wireshark

In diesem Abschnitt werden grob die empfangenen Pakete untersucht. Die untenstehende Paketaufzeichnung entspricht einem Verbindungsaufbau mit Authentifizierung.

Wie aus der Abbildung 4 ersichtlich, wird der Client (192.168.1.109) eine Verbindung mit dem SSH-Server (192.168.1.200) erstellen. Die ersten drei Pakete sind die sogenannten TCP-Drei-Wege-Handshake (Verbindungsaufbau). Danach folgt der Austausch von Informationen (Version des Clients und des Server, Verschlüsselungsmethode) zwischen dem Client und dem Server und es wird ein Session Key (Diffie-Hellman-Schlüsselaustausch) vereinbart. Ab Paket Nummer 19 ist die Verbindung schon verschlüsselt. Noch zu erkennen ist die orientierte Verbindung: Jedes SSH-Paket wird vom Server mit einem TCP-Paket (ACK) bestätigt. Auf die Adresse „http://www.hitech-blog.com/wp-content/2010/05/sshv2.cap“ ist diese Aufzeichnung zu finden.

2.6 Open Source Client und Server

Es sind verschiedene Programme (Clientseitig und Serverseitig) im Internet zu finden. Hier sind ein paar aufgelistet:

Client:

PuTTY (Windows, Unix): http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

OpenSSH (Unix): http://www.openssh.com/

MacSSH (Mac OS X): http://sourceforge.net/projects/macssh/

Server:

OpenSSH (Unix): http://www.openssh.com/

MobaSSH (Windows): http://mobassh.mobatek.net/en/

Cygwin + SSHd (Windows): http://www.fz-juelich.de/jsc/docs/tki/tki_html/t0375/t0375.html

WinSSHD (Windows): www.bitvise.com/winsshd

Mac OS X: Client (ssh) und Server (sshd) sind schon vorinstalliert. Client ist schon aktiviert und der Server muss ihn unter „Systemeinstellungen->Freigaben->Entfernte Anmeldung“ aktivieren.

Ubuntu, Suse, Solaris, etc.:SSH-Clients (ssh) ist schon vorinstalliert. Am einfachsten um einen SSH-Server auf Ubuntu zu installieren, ist es das folgende Paket zu installieren: „openssh-server“. Befehl für die Installation: „sudo apt-get install openssh-server“. Um den SSH-Server zu starten den Befehl „sudo /etc/init.d/ssh start“ im Terminal eintippen.

Windows: SSH-Client und SSH-Server sind nicht vorhanden.

Erzeugung von öffentlichen und privaten Schlüsseln: GnuPGP (http://www.gnupg.org/), PuTTY gen (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) oder ssh-keygen (siehe Kapitel 3.1 – Schlüsselgenerierung) im Terminal.

3 Einsatz

3.1 Remote Fernsteuerung

Wie ich schon im Kapitel 2.3 erläutert habe, wird die Authentifizierung mit dem Public Key am meistens verwendet. Der Public Key des Clients soll dem Server überreicht werden. Es gibt zwei Möglichkeiten dies zu tun.

1. Den öffentlichen Schlüssel lokal auf den Server zu schreiben.
2. beim Verbindungsaufbau den öffentlichen Schlüssel auszutauschen.

Verbindung mit einem SSH-Server

SSH Client: mit dem Befehl „ssh cosweb.dyndns.org -l costa“ wird eine Verbindung mit einem SSH-Server erstellt.

In der Abbildung 5 ist zu erkennen, dass der Client nicht die Authentifizierung des Servers überprüfen kann. Grund dafür ist, dass der öffentliche Schlüssel des Servers nicht in die Datei „~/.ssh/known_hosts“ auf dem Client eingetragen wurde und dieser wird beim Verbindungsaufbau dem Client geschickt.

Schlüsselgenerierung:

Der Befehl „ssh-keygen –t rsa“ erzeugt einen öffentlichen und einen privaten RSA-Schlüssel. Nach der Generierung wird der öffentliche Schlüssel in „~/.ssh/id_rsa.pub“ gespeichert, während sich der private Schlüssel als „~/.ssh/id_rsa“ speichert.

Dann muss der öffentliche Schlüssel in die Datei „~/.ssh/authorized_keys“ auf dem SSH-Server angehängt werden. Die Konfigurationsdatei (/etc/ssh/sshd_config) des Server muss richtig eingestellt werden: „PubkeyAuthentification yes“, „AuthorizedKeysFile ~/.ssh/authorized_keys“,  „PermitRootLogin no“ und „PasswordAuthentication no“.

Befehl einer SSH-Verbindung mit Public-Key Verfahren: „ssh -i ~/.ssh/id_rsa cosweb.dyndns.org -l costa“

3.2 Tunneling

SSH-Client:

Befehl: “ssh -2 -N -f -L 6001:mail.me.com:143 cosweb.dyndns.org -l costa”

2: SSH Version 2, N: not execute a remote command, f: Tunnel im Hintergrund laufen lassen, L: Adresse (6001: Locale Port auf dem Rechner, mail.me.com: Remote Adresse 143: Remote Port), cosweb.dyndns.org: Adresse des SSH-Servers, l: login name

In der Abbildung 9 wird gezeigt, wie ein Tunnel aufgebaut wird. Die Situation ist, dass der Laptop (Client) eine Verbindung mit dem IMAP-Server (me.com) auf Port 143 aufbauen will. Wegen der strengen Regeln der Firewall werden solche Verbindungen geblockt. Um dieses Problem umzugehen, wird der Client zuerst eine Verbindung auf Port 22 mit einem SSH-Server aufbauen: der Verkehr auf Port 22 wird von der Firewall zugelassen. Danach stellt der SSH-Server eine Verbindung mit dem IMAP-Server auf Port 143, wo die Firewall den Verkehr auf Port 143 nicht blockt. Jetzt wenn der Client auf die Adresse „localhost:6001“ zugreift, wird er eine Verbindung durch SSH-Server mit me.com erstellen: Client schickt Datenpakete an SSH-Server und diese werden an me.com weitergeleitet und umgekehrt die Datenpakete, die vom IMAP-Server me.com ankommen, werden am Client geschickt.

 

Tags: Angreifer, client, HTW, OSI-Modell, Paketaufzeichnung, secure shell, Server, Sicherheitsanforderung, ssh