SSH2 Sicherheit auf der Anwendungsschicht

Seminarbeitrag
SSH2 Sicherheit auf der
Anwendungsschicht
zum Seminar
Sicherheit in
Kommunikationsprotokollen
Björn Wargenau
EINLEITUNG...............................................................................................................2
Aktuelle Versionen und Implementierungen von SSH.......................................................3
DIE SSH2 PROTOKOLLE...........................................................................................3
Protokollarchitektur.............................................................................................................3
Das Transport Layer Protokoll............................................................................................5
Binary Packet Protocol........................................................................................................5
Kompression.......................................................................................................................7
Verschlüsselung...................................................................................................................7
Integrität der übermittelten Daten........................................................................................8
Schlüsselaustausch..............................................................................................................9
Diffie−Hellman Key Exchange...........................................................................................11
Das User Authentication Protocol .....................................................................................13
Authentication Requests....................................................................................................13
None Authentication Request............................................................................................14
Banner Messages...............................................................................................................16
Public Key Authentisierung...............................................................................................16
Authentisierung mittels Passwort.......................................................................................17
Hostbased Authentisierung................................................................................................18
DAS CONNECTION PROTOCOL.............................................................................19
Kanäle...............................................................................................................................19
Sessions.............................................................................................................................21
TCP/IP Port Forewarding..................................................................................................24
SICHERHEIT VON SSH2.........................................................................................26
Sicherheit gegen aktive Angriffe.......................................................................................26
Sicherheit gegen passive Angriffe.....................................................................................27
Weitere Sicherheitsrisiken.................................................................................................27
QUELLEN .................................................................................................................28
Einleitung
Viele Programme die heute in Netzwerken für Kommunikation und Datenübertragung
verwendet werden sind unsicher, dazu zählen zum Beispiel die häufig verwendeten
Anwendungen Telnet, ftp, Pop sowie die r−Tools. All diese Programme haben zwei
Probleme:
Die Übertragung von Benutzername und Passwort im Klartext
Keine Authentisierung des Kommunikationspartners
Dies kann von Angreifern leicht ausgenutzt werden, um sich Zugang zu Postfächern oder
Benutzerlogins zu beschaffen.
Empfängt zum Beispiel ein Benutzer mittels Pop in einem Ethernet seine E−Mail, so kann
sein Login und Passwort leicht mit einem Snifferprogramm abgefangen werden.
Diese Programme können auch von Laien bedient werden, z.b. wird mit KDE das Programm
KSniff ausgeliefert, welches sogar eine graphische Oberfläche hat.
Mit Hilfe von SSH hat der Benutzer die Möglichkeit die Datenübertragung zu verschlüsseln
und sicherzustellen das der mit dem richtigen Partner kommuniziert.
Das Hauptanwendungsfeld von SSH ist der Ersatz von Telnet, es gibt aber noch weitere
Nutzungsmöglichkeiten.
SSH kann auch dazu verwendet werden die Übertragung von Benutzerdaten durch unsichere
Protokolle, wie z.B. Pop zu sichern.
SSH kann vom Benutzer auf dem System installiert werden, falls es auf dem System nicht
vorhanden ist, es sind keine root Rechte erforderlich.
Aktuelle Versionen und Implementierungen von SSH
Die aktuelle Versionsnummer von SSH ist 2.3
SSH2 ist nicht kompatibel mit der Version SSH1. Das bedeutet ein SSH1 Server kann keine
Anfragen von SSH2 Clients beantworten. Der umgekehrte Fall SSH2 Server und SSH1 Client
kann vom Server unterstützt werden, allerdings muss beim Client in diesem Fall eine
Warnung angezeigt werden.
Implementierungen von SSH2 gibt es unter anderem von
SSH Communications Security www.ssh.com
Eine freie Implementierung gibt es vom
Open SSH Project www.openssh.org
Die SSH2 Protokolle
Protokollarchitektur
Jeder SSH2 Server muss einen Host Key besitzen. Er kann aber auch mehr als einen besitzen.
Mehrere Server können sich den gleichen Host Key teilen. Jeder Host muss mindestens einen
Host Key für jedes zu unterstützende Verschlüsselungsverfahren besitzen.
Der host key wird während des Schlüsselaustausches verwendet, um zu überprüfen, ob der
Client wirklich mit dem korrekten Server spricht. Damit dies möglich ist, muss der Client
vorher den public key des Servers kennen. Dazu können zwei verschiedene Vertrauens
Modelle benutzt werden:
Client Datenbank
Der Client verfügt über eine lokale Datenbank in der jedem Hostnamen der public key des
Hosts zugeordnet ist. Der Vorteil dieser Methode ist das keine zentrale Stelle zur
Authentisierung erforderlich ist.
Ein Nachteil ist das der Benutzer sich selbst um die Verwaltung der public keys kümmern
muss.
Certification Authority CA
Hier wird die Verknüpfung von Hostname und public key von einer certification authority
zertifiziert. Der Vorteil dieser Variante ist das diesem Verfahren der Client nur den CA key
zu kennen braucht.
Nachteile sind: jeder host key muss von der CA zertifiziert werden und der Benutzer muss der
CA vertrauen.
SSH2 Implementierungen sollten bei dem Test von public keys nach der "best effort"
Strategie vorgehen. Das bedeutet das bei der Zuordnung von Hostname zu public key Fehler
auftreten können. Im Protokoll ist die Möglichkeit vorgesehen, das bei der ersten Verbindung
zwischen einem Client und einem Host die Hostname − public key Verknüpfung nicht
überprüft wird. In diesem Fall ist die Verbindung weiterhin sicher gegen passives Abhören,
aber nicht gegen man−in−the−middle Angriffe. Dies vereinfacht die Benutzung von SSH, da
der public key des Servers in diesem Fall bei der ersten Verbindung runtergeladen werden
kann. Allerdings ist diese Art sich einen public key zu beschaffen auch ein
Sicherheitsproblem. Daher wird vorgeschlagen diese Option zu deaktivieren.
SSH2 Implementierungen können zusätzliche Methoden zur Verifikation von Host keys zur
Verfügung stellen. Ein Beispiel ist ein hexadezimaler Fingerprint der mit Hilfe des Hasch−
Algorithmus SHA−1 erzeugt wurde. Derartige Fingerprint können einfach übers Telefon oder
Visitenkarten übermittelt werden.
SSH wird in 3 Protokollen definiert:
Transport layer protocol [SSH−TRANS]
User authentication protocol [SSH−USERAUTH]
Connection protocol [SSH−CONN]
Das Transport Layer Protokoll
Dieses Protokoll stellt Server Authentisierung, Vertraulichkeit und Integrität zur Verfügung.
Verbindungsaufbau
Der Client baut eine TCP Verbindung zum Server auf. Dazu wird in der Regel Port 22
benutzt, dieser wurde für SSH registriert. Nun senden Server und Client einen "identification
string" der Form: "SSH−protoversion−softwareversion comments" .
Der Server kann, bevor er den "identification string" sendet, noch andere Daten senden.
Clients müssen in der Lage sein diese Daten zu erkennen, sie dürfen aber ignoriert werden.
Die Versionsinformationen müssen aus printable us−ascii bestehen und dürfen keine
Leerzeichen oder Minuszeichen enthalten. Der im "identification sting" enthaltene
Kommentarteil kann zusätzliche Informationen enthalten, die dem Benutzer bei
Problemlösungen helfen sollen. Nachdem beide Seiten die Versionsinformationen
ausgetauscht haben beginnt der Schlüsselaustausch. Alle Pakete die von nun an ausgetaucht
werden sollten das "binary packet protocol" benutzen.
Binary Packet Protocol
Pakete dieses Protokolls haben die folgende Form:
packet_length
padding_lengt
h
payload
random
padding
mac
Bedeutung der Felder:
uint32 packet_length:
Die Länge des Paketes in Bytes ohne das Feld packet_length und ohne den MAC.
byte padding_length:
Enthält die Länge des Feldes padding in Bytes.
byte[packet_length − padding_length − 1] payload:
Dieses Feld enthält die Nutzdaten.
byte [padding_length] random padding:
Zufällige Bytefolge mit der das Paket vergrößert wird, bis die Paketlänge ohne MAC
entweder Vielfaches von 8 oder der "cipher block size" ist, je nachdem welcher der
beiden Werte größer ist. Mindestens 4 Bytes lang.
byte [mac_length] mac:
Dieses Feld enthält den "message authentication code", nachdem einer ausgehandelt
wurde. Am Anfang ist dieses Feld leer.
Die minimale Länge eines Binary Packet Protocol Packetes ist 16 Bytes. Alle SSH2
Implementierungen müssen in der Lage sein Pakete zu verarbeiten bei denen die Länge des
playloads 32768 Bytes oder kleiner ist.
Kompression
Es kann zwischen Client und Server ein Kompressionsverfahren ausgehandelt werden. Mit
diesem wird dann das Feld payload verschlüsselt. Bislang sind zwei Kompressionsverfahren
definiert:
none
muss implementiert werden
es erfolgt keine Kompression
zlib
kann implementiert werden
GNU ZLIB (LZ77) Kompression [RFC−1950] und [RFC−1951].
Verschlüsselung
Verschlüsselungsalgorithmus und Schlüssel werden während des Schlüsselaustausches
ausgehandelt.
Ist Verschlüsselung aktiviert dann müssen die Felder packet length, paddinglength, payload
und padding verschlüsselt werden. Es sollen Schlüssel mit einer effektiven Schlüssellänge
von mindestes 128 Bit verwendet werden. Die Verschlüsselungsverfahren müssen für beide
Richtungen unabhängig sein, das bedeutet es ist möglich für die Richtung Client Server ein
anderes Verfahren zu verwendet als bei der Richtung Server Client.
Folgende Verschlüsselungsverfahren sind momentan definiert:
Verfahren
Implementierung
3des−cbc
REQUIRED
blowfish−
cbc
RECOMMENDED
twofish−cbc RECOMMENDED
arcfour
OPTIONAL
idea−cbc
OPTIONAL
cast128−cbc OPTIONAL
none
OPTIONAL
Integrität der übermittelten Daten
Um die Integrität der übermittelten Daten sicherzustellen wird jedem Packet ein MAC
(message authentication code) hinzugefügt. Dieser wird aus dem Inhalt des Paketes, der
Sequenznummer des Paketes und einen Geheimnis, das nur Client und Server kennen,
berechnet.
Mac−Algorithmus und Schlüssel werden während des Schlüsselaustausches ausgehandelt.
Am Anfang der Verbindung ist kein MAC− Algorithmus aktiv und die Länge des MAC
Feldes ist 0. Nach dem Schlüsselaustausch wird der MAC folgendermaßen berechnet:
MAC = mac(key, sequence_number, unencrypted_packet)
wobei
key
ein Geheimnis ist, das nur Client und Server kennen
sequence_number
die Sequenznummer des aktuelles Paketes ist
es wird von 0 gezählt, bei 2^32 springt der Zähler wieder auf 0
Die Sequenznummer wird nie gesendet.
unencrypted_packet
die Felder packet_length,padding_length,payload and padding sind
Schlüsselaustausch
Es gibt für SSH2 nur eine definierte Methode um Schlüssel auszutauschen, hierbei handelt es
sich um das Diffie−Hellman Verfahren.
Der Schlüsselaustausch beginnt damit das Client und Server das folgende Paket senden:
SSH_MSG_KEXINIT
cookie (random bytes)
kex_algorithms
server_host_key_algorithms
encryption_algorithms_client_to_server
encryption_algorithms_server_to_client
mac_algorithms_client_to_server
mac_algorithms_server_to_client
compression_algorithms_client_to_server
compression_algorithms_server_to_client
languages_client_to_server
languages_server_to_client
first_kex_packet_follows
uint32 0 (reserved for future extension)
Bedeutung der Felder:
byte SSH_MSG_KEXINIT:
Ein Byte, das den Typ des Paketes bestimmt
byte[16] cookie (random bytes):
Zufälliger Wert, soll verhindern das die andere Seite die Schlüssel und
Sitzungskennung feststellen kann
String kex_algorithms:
Der Schlüsselaustauschalgorithmus
String server_host_key_algorithms:
List der Algorithmen die der host key des Servers unterstützt
String encryption_algorithms_client_to_server:
Liste der akzeptierbaren symmetrischen Verschlüsselungsalgorithmen
String encryption_algorithms_server_to_client:
Liste der akzeptierbaren symmetrischen Verschlüsselungsalgorithmen
String mac_algorithms_client_to_server:
Liste der akzeptierbaren MAC− Algorithmen
String mac_algorithms_server_to_client:
Liste der akzeptierbaren MAC− Algorithmen
String compression_algorithms_client_to_server:
Liste der akzeptierbaren Kompressions−Algorithmen
String compression_algorithms_server_to_client:
Liste der akzeptierbaren Kompressions−Algorithmen
Der für die Verbindung verwendete Verschlüsselungs−, Kompressions− und Message
Authenticationalgorithmus ist jeweils der erste in der Liste des Clients, der auch beim Server
vorhanden ist.
Nach dem sich Client und Server mit dem KEXINIT−Packet auf Verschlüsselungs−,
Kompressions− und Message− Authentisierungsalgoithmen geeinigt haben wird der
Schlüsselaustauschalgorithmus aufgerufen.
Diffie−Hellman Key Exchange
x=ZufallsZahl()
e=g^x mod p
y=ZufallsZahl()
f=g^y mod p
e
f
K=e^y mod p
H=hash(V_C, V_S, I_C, I_S, K_S, e, f, K)
S=signatur(H)
S
K_S
Verifiziert K_S
K=f^x mod p
H=hash(V_C, V_S, I_C, I_S, K_S, e, f, K)
Teste ob s stimmt
CLIENT
K
x
y
g
e
f
K_S
p
V_S, V_C
I_S, I_C
SERVER
Gemeinsames Geheimnis von Server und Client
Zufallszahl, nur dem Client bekant
Zufallszahl, nur dem Server bekant
Generator, hier in der Regel 2
wird Client berechnet und gesendet lässt ohne y keine Rückschlüsse auf
Geheimnis zu
der Server benötigt e um das Geheimnis zu ermitteln
wird Server berechnet und gesendet lässt ohne x keine Rückschlüsse auf
Geheimnis zu
der Client benötigt f um das Geheimnis zu ermitteln
Public key des Servers
Primzahl
17976931348623159077083915679378745319786029604875601170644
42368419718021615851936894783379586492554150218056548598050
36464405481992391000507928770033558166392295531362390765087
35759914822574862575007425302077447712589550957937778424442
42661733472762929938766870920560605027081084290769293201912
8194467627007
Version Strings von Client und Server
Payload der Keyexchange Packete
Das User Authentication Protocol
Das User Authentication Protokoll setzt auf dem SSH Transport Layer Protokoll auf.
Es authentisiert den Benutzer beim Server. Es geht davon aus das Integrität und
Vertraulichkeit durch die darunter liegenden Protokolle zur Verfügung gestellt werden.
Authentication Requests
Authentication Requests müssen die folgende Form haben:
SSH_MSG_USERAUTH_REQUEST
user name (in ISO−10646 UTF−8 encoding)
service name (in US−ASCII)
method name (US−ASCII)
Rest des Paketes ist abhängig von der gewählten Authentisierungs−Methode
Bedeutung der Felder:
byte : SSH_MSG_USERAUTH_REQUEST
Ein Byte, das den Typ des Paketes bestimmt
String user name :
Name des Benutzers der sich beim Server anmelden will
String service name :
Name des Dienstes den der Benutzer nach der Authentisierung benutzen will
String method name :
Die Methode mit der sich der Benutzer authentisieren will
Existiert der vom Client übermittelte Benutzername nicht, dann kann der Server die
Verbindung beenden, oder eine Liste der möglichen Authentisierungsmethoden senden, aber
jeder Authentisierungs−Versuch muss dann fehlschlagen. Damit wird es einem Angreifer
nicht ermöglicht zu testen, ob ein bestimmter Benutzername existiert.
Lehnt der Server einen Authentisierungsversuch des Clients ab dann antwortet er mit dem
Packet:
SSH_MSG_USERAUTH_FAILURE
authentications that can continue
partial success
Bedeutung der Felder:
byte : SSH_MSG_USERAUTH_FAILURE
Ein Byte, das den Typ des Paketes bestimmt
String user name :
Eine Liste der Authentisierungsmethoden die noch zum Erfolg führen können
boolean partial success :
Falsch, da die Authentisierung fehlgeschlagen ist
War die Authentisierung des Clients erfolgreich dann antwortet der Server mit :
SSH_MSG_USERAUTH_SUCCESS
Bedeutung der Felder:
byte : SSH_MSG_USERAUTH_SUCCESS
Ein Byte, das den Erfolg der Authentisierung anzeigt
Alle Nachrichten, die von nun an vom Client empfangen werden, werden an den Dienst
weitergeleitet , der über dem User Authentication Protocoll läuft.
Nach Empfang der Nachricht SSH_MSG_USERAUTH_SUCCESS startet der Server den
vom Benutzer angegebenen Dienst.
None Authentication Request
Ein Client kann die vom Server unterstützten Authentisierungsmethoden anfordern, indem er
dem Server einen Authentication Request mit dem method namen "none" sendet.
Daraufhin kann der Server die Liste mittels eines SSH_MSG_USERAUTH_FAILURE
Paketes zum Client senden.
Banner Messages
Das User Authentication Protocoll erlaubt es dem Server eine sogenannte Banner Message
zum Client zu senden bevor die Authentisierung stattfindet. Diese sollte dann vom Client an
den Benutzer weitergeleitet werden.
Public Key Authentisierung
Diese Art der Authentisierung muss von allen SSH2 Implementierungen unterstützt werden.
Bei diesem Verfahren gilt der Besitz des privaten Schlüssels als Authentisierung.
Der private Schlüssel des Benutzers ist in der Regel verschlüsselt gespeichert und muss vor
dem Erstellen der Signatur mit Hilfe der Passphrase entschlüsselt werden.
Um die Authentisierung durchzuführen sendet der Client das folgende Packet.
Die allgemeine Form eines SSH_MSG_USERAUTH_REQUEST ist
beschrieben.
weiter
oben
SSH_MSG_USERAUTH_REQUEST
user name
service
"publickey"
TRUE
public key algorithm name
public key to be used for authentication
signature
Bedeutung der Felder:
string : signature
Eine mit dem privaten Schlüssel des Benutzers erstellte Signatur von
session identifier und dem oben angegebenen Packet ohne das Feld Signatur
Der Server muss überprüfen ob der vom Client verwendete Schlüssel für Authentisierungen
verwendet werden darf und ob die Signatur stimmt. Falls dies der Fall ist, ist die
Authentisierung erfolgreich.
Authentisierung mittels Passwort
Bei diesem Verfahren gilt die Kenntnis eines geheimen Passwortes als Authentisierung.
Der Client sendet dazu folgendes Packet an den Server:
SSH_MSG_USERAUTH_REQUEST
user name
service
"password"
FALSE
plaintext password (ISO−10646 UTF−8)
Da über das SSH2 Transport Layer Protokoll eine verschlüsselte Datenübertragung
durchgeführt wird, stellt die Übermittlung des Passwortes kein Sicherheitsrisiko dar. Der
Server antwortet entweder mit der Nachricht SSH_MSG_USERAUTH_SUCCESS oder
SSH_MSG_USERAUTH_FAILURE.
Hostbased Authentisierung
Dieses Verfahren zur Authentisierung basiert auf dem Rechnernamen des Clients, dem Login
des Benutzers auf diesem Rechner und einem privaten Schlüssel auf dem Client. Es ist
bequem aber nicht besonders sicher.
Der Client authentisiert sich indem er eine mit dem privaten Schlüssel des Clients erstellte
Signatur sowie den Rechnernamen und das Login des Benutzers zu Server sendet:
SSH_MSG_USERAUTH_REQUEST
user name
Service
"host based"
public key algorithm for host key
public host key and certificates for client host
client host name (FQDN; US−ASCII)
client user name on the remote host (ISO−10646 UTF−8)
Signature
Bedeutung der Felder:
string : signature
Eine mit dem privaten Schlüssel des Clients erstellte Signatur von
session identifier, und dem oben gezeigten Packet ohne das Feld Signatur.
Der Server überprüft ob der host key zu dem Namen des Client Rechners passt, ob der
angegebene Benutzer sich von diesem Rechner aus einloggen darf und ob die Signatur gültig
ist. Der Benutzername kann bei der Authentisierung auch ignoriert werden.
Falls dieses Verfahren verwendet wird muss darauf geachtet werden, das ein normaler
Benutzer nicht Zugriff auf den privaten Schlüssel des Client Rechners hat.
Das Connection Protocol
Das Connection Protokoll läuft über dem SSH2 User Authentication Protocol.
Es multiplext den verschlüsselten Kanal in verschiedene logische Kanäle. Die vom
Connection Protokoll zur Verfügung gestellten Kanäle können von vielen Anwendungen
benutzt werden.
Standardmäßig wird Unterstützung für sichere interaktive Shellsitzungen, Tunneln beliebiger
TCP/IP Ports und sichere X11 Verbindungen zur Verknüpfung gestellt.
Kanäle
Alle Terminal Sitzungen, X11 Verbindungen usw. laufen über Kanäle. Diese können von
Client und Server erstellt werden.
Will eine Seite einen Kanal öffnen, dann ordnet sie diesem zuerst eine Nummer zu und
sendet dann folgendes Packet:
SSH_MSG_CHANNEL_OPEN
channel type (restricted to US−ASCII)
sender channel
initial window size
maximum packet size
Hier folgen vom Kanal abhängige Daten
Bedeutung einiger Felder:
String
: channel type
Die Art der Verbindung z.B.
− X11
− Shell
uint32 sender channel :
Lokale Nummer des Kanals
uint32 maximum packet size :
maximale Größe von Paketen die empfangen werden
Nun entscheidet die andere Seite ob der Kanal geöffnet werden kann und antwortet mit:
SSH_MSG_CHANNEL_OPEN_CONFIRMATION
recipient channel
sender channel
initial window size
maximum packet size
Hier folgen vom Kanal abhängige Daten
oder mit
SSH_MSG_CHANNEL_OPEN_FAILURE
recipient channel
reason code
additional textual information (ISO−10646 UTF−8)
language tag (as defined in [RFC−1766])
[RFC−2044])
Daten werden dann mit Paketen der folgenden Form übertragen:
SSH_MSG_CHANNEL_DATA
recipient channel
Data
Bedeutung der Felder:
byte SSH_MSG_CHANNEL_DATA :
ein Byte, das den Typ des Paketes bestimmt
uint32 recipient channel :
der Zielkanal
byte[] data :
Nutzdaten
Das Schließen eines Kanals erfolgt mit dem Packet:
SSH_MSG_CHANNEL_EOF
recipient_channel
Bedeutung der Felder:
byte SSH_MSG_CHANNEL_DATA :
ein Byte, das den Typ des Paketes bestimmt
uint32 recipient channel :
der Zielkanal
Sessions
Eine Session ist die Ausführung eines entferntes Programms. Dabei kann es sich um eine
Shell, ein Anwendungsprogramm oder um ein Systemprogramm handeln.
Eine Session wird mit folgendem Packet eröffnet:
SSH_MSG_CHANNEL_OPEN
"session"
sender channel
initial window size
maximum packet size
Eine Session kann durch einen "session chanel open request" vom Client beim Server
angefordert werden.
Clients sollten aus Sicherheitsgründen session chanel open requests ablehnen.
Pseudo Terminal anfordern
Eine Pseudo Terminal wird mit folgendem Packet vom Server angefordert.
Dieses wird für interaktive Shellsitzungen benötigt
SSH_MSG_CHANNEL_REQUEST
recipient_channel
"pty−req"
want_reply
TERM environment variable value (e.g., vt100)
terminal width, characters (e.g., 80)
terminal height, rows (e.g., 24)
terminal width, pixels (e.g., 480)
terminal height, pixels (e.g., 640)
encoded terminal modes
Daraufhin erstellt der Server einen Kanal:
SSH_MSG_CHANNEL_OPEN
"pty"
sender channel
initial window size
maximum packet size
Sichere X11 Verbindungen
Eine sichere X11 Verbindung wird mit folgendem Packet vom Server angefordert:
SSH_MSG_CHANNEL_REQUEST
recipient channel
"x11−req"
want reply
single connection
x11 authentication protocol
x11 authentication cookie
x11 screen number
Daraufhin kann der Server mit folgendem Packet die sichere X11 Verbindung herstellen:
SSH_MSG_CHANNEL_OPEN
"x11"
sender channel
initial window size
maximum packet size
originator address (e.g. "192.168.7.38")
originator port
Starten von Programmen oder einer Shell auf dem Server
Es muss schon eine Session existieren. Dann kann der Client mit dem folgenden Packet ein
Interaktive Shell starten.
SSH_MSG_CHANNEL_REQUEST
recipient channel
"shell"
want reply
Der Client kann auch andere Programme starten, falls er auf der Server die entsprechenden
Rechte hat. Dies erfolgt durch Senden des Paketes:
SSH_MSG_CHANNEL_REQUEST
recipient channel
"exec"
want reply
Command
TCP/IP Port Forewarding
Port Forewarding bedeutet, das Nachrichten die normalerweise über eine unsichere
Verbindung zu einem bestimmten Port des Servers gesendet werden, stattdessen zuerst an
einen lokalen Port gesendet werden. Der SSH Client lauscht auf diesem lokalen Port und falls
dort Daten eintreffen sendet er sie über einen sicheren Kanal zum SSH− Server auf der
Gegenseite weiter, dieser übergibt die Daten dann an den eigentlichen Zielport.
Mit dieser Methode kann zum Beispiel die Übergabe von Benutzername und Passwort beim
Abfragen von Mails gesichert werden, allerdings werden die Daten vom Server zum Client
unverschlüsselt übertragen.
Normalfall:
Login, Passwort
pop client
pop server
Client
Server
Abgesichert:
sicherer Kanal
SSH Client
SSH Server
Login , Passwort
pop client
Client
pop server
Server
Port Forewarding wird mit folgendem Paket vom Server angefordert:
SSH_MSG_GLOBAL_REQUEST
"tcpip−forward"
want reply
address to bind (e.g. "0.0.0.0")
port number to bind
Dieser Dienst wird in der Regel nur vom Server zur Verfügung gestellt. Erhält ein Client
diesen Request sollte er ihn ablehnen.
Nachdem ein Server diesen Request erhalten hat kann er mit folgendem Packet das port
forewarding aktivieren.
SSH_MSG_CHANNEL_OPEN
"forwarded−tcpip"
sender channel
initial window size
maximum packet size
address that was connected
port that was connected
originator IP address
Sicherheit von SSH2
Sicherheit gegen aktive Angriffe
SSH2 kann durch sogenannte "man−in−the−middle" Attacken angegriffen werden.
Normalfall:
public key
Client
Server
Angriff:
Client
Server
public key des Angreifers
Angreifer
Dies wird dadurch möglich, das es dem Client erlaubt werden kann den public key des
Servers herunterzuladen, wenn sich der Client zum ersten Mal mit dem Server verbindet.
Dies kann von einem Angreifer ausgenutzt werden, indem
Verbindungsaufnahme des Clients mit dem Server vorgibt selbst der
durch DNS− oder IP Spoofing. Der Client würde in diesem Fall
Angreifers runterladen. Der Client geht nun davon aus das am anderen
Kommunikationspartner ist und sendet diesem geheime Informationen.
er bei der ersten
Server zu sein, etwa
den public key des
Ende der gewünschte
Vor diesem Angriff kann sich der Client schützen indem
das Runterladen des public keys beim Servers deaktiviert wird, in diesem Fall muss der
public key anders verteilt werden, was die Benutzbarkeit von SSH erschweren würde.
Der Client hat die Möglichkeit die Echtheit des runtergeladenen public keys etwa durch einen
Fingerprint zu überprüfen, dieser ist relativ kurz und kann übers Telefon oder über
Visitenkarten weitergegeben werden.
Der Server kann seinen public key durch eine dritte Stelle (CA) beglaubigen lassen.
Verfügt der Client dann über den public key dieser Stelle kann er diese Beglaubigung prüfen
Sicherheit gegen passive Angriffe
SSH2 ist gegen passive Angriffe, das bedeutet das Abhören der Kommunikation von zwei
Parteien, ohne direkte in diese einzugreifen sicher, wenn man davon ausgeht das die
verwendeten kryptographischen Verfahren sicher sind.
Weitere Sicherheitsrisiken
Erlangt ein Angreifer root Rechte auf dem Server kann die Sicherheit nicht mehr
gewährleistet werden, da er dann auch Zugriff auf den private key des Servers hat.
Ein weiteres Risiko ist eine schwache Passphrase, mit der der private key auf dem Rechner
des Clients geschützt wird. Kann ein Angreifer diese Passphrase erraten und hat Zugriff auf
die Datei in welcher der private key des Benutzers liegt , dann kann er sich beim Server als
Benutzer authentisieren.
Quellen
http://www.ietf.org/html.charters/secsh−charter.html
Seite der IETF mit Definition des SSH2 Protokolls
http://www.gfnet.de/security/ssh.html
Ein Übersicht über SSH
http://kepler.offis.uni−oldenburg.de/lehre/Seminar/SemSichWS99/10/index.html
Seminarbeitrag vom letzten Jahr
http://www.ssh.org/download.html
Kommerzielle SSH2 Version von SSH Communications Security
www.openssh.com
Das Open SSH Projekt bietet eine freie Implementierung von SSH2.
Andrew s. Tannenbaum Computernetzwerke, 3. Auflage
Erläuterung des Diffie−Hellman Verfahren auf Seite 640 bis 642