Überblick:
Diese Diplomarbeit beschäftigt sich mit der Analyse und dem Vergleich ausgewählter am
Markt erhältlicher VPN-Lösungen.
Zu Beginn wird die Motivation der Durchführung dieser Analyse durch SomSoft erläutert.
Auf die Ziele und Anforderungen der Arbeit wird dabei eingegangen.
Kapitel zwei stellt die ausgewählten VPN-Lösungen vor und erklärt deren Funktionsweise
und sicherheitsrelevante Aspekte. Dabei werden Schwachstellen aufgezeigt und erläutert
und es wird auf die Interoperabilität zwischen verschiedenen Betriebssystemen oder Hard-
wareimplementierungen eingegangen.
Im dritten Kapitel wird die Installation, Konfiguration und Wartung der Lösungen erläu-
tert. Von Interesse ist der Ablauf dieser Schritte sowie der Aufwand der Administration
der VPNs.
Dabei werden mögliche Szenarien für VPNs aufgezeigt und die Implementierung dieser
mit jeder der ausgewählten VPN-Lösungen getestet. Auf die notwendige Konfiguration
wird dabei eingegangen sowie Probleme und Schwierigkeiten erfasst.
In Kapitel vier werden die Tests ausgewertet und die Vor- und Nachteile der Lösungen in
verschiedenen Einsatzgebieten diskutiert.
II
Hinweis:
Alle aufgeführten Firmen- und Produktnamen sind Warenzeichen, eingetragene Warenzei-
chen oder sonstige urheber-, marken- bzw. titelrechtlich geschützte Bezeichnungen ihrer
jeweiligen Eigentümer und werden als solche ausdrücklich anerkannt. Die Nennung ge-
schieht lediglich zu Identifikationszwecken und stellt keinen Anspruch an bzw. auf diese
Namen und Warenzeichen dar.
III
Inhaltsverzeichnis
1
Motivation und Ziele
1
1.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
VPN-Technologien
2
2.1
PPTP - Point-to-Point-Tunneling-Protokoll . . . . . . . . . . . . . . . . . . .
3
2.1.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2
Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.3
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.4
Schwachstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.5
Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.2
Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.3
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.2.4
Schwachstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2.5
Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3
L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.3.2
Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3.3
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.4
Schwachstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.3.5
Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.4
Tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.4.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.4.2
Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.4.3
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.4.4
Schwachstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
IV
Inhaltsverzeichnis
2.4.5
Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5
OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.5.2
Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.5.3
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.5.4
Schwachstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.5.5
Interoperabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.6
Weitere Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.6.1
SSL VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.6.2
SSH Secure Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
2.6.3
GNU Virtual Private Ethernet . . . . . . . . . . . . . . . . . . . . . . .
28
2.6.4
Sonstige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3
Gegenüberstellung - Vergleich
30
3.1
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.1.1
PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.1.2
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.1.3
L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.1.4
Tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.1.5
OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.1.6
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2
Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2.1
PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2.2
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.2.3
L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.2.4
Tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
3.2.5
OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.2.6
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.3
Infrastrukturszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.3.2
PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
3.3.3
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.3.4
L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
3.3.5
Tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
3.3.6
OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
V
Inhaltsverzeichnis
3.4
Wartung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
3.4.1
PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
3.4.2
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
3.4.3
L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
3.4.4
Tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.4.5
OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.4.6
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4
Ergebnisanalyse
82
4.1
Zielgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
4.1.1
Privatanwender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
4.1.2
Mittelstandsgewerbe . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.1.3
Gewerbliche Großunternehmen . . . . . . . . . . . . . . . . . . . . .
86
4.1.4
Industrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
4.1.5
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
4.2
VPN-Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
4.2.1
PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.2.2
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.2.3
L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.2.4
Tinc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.2.5
OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.3
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.3.1
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.3.2
Prognose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
Glossar
94
Abkürzungsverzeichnis
104
Literaturverzeichnis
107
Internetquellen
107
Abbildungsverzeichnis
112
Tabellenverzeichnis
113
Danksagung
114
VI
1 Motivation und Ziele
1.1 Einleitung
SomSoft ist ein Unternehmen, welches in der Softwareentwicklung tätig ist. Die zu ent-
wicklenden Projekte sind meist Datenbank-Anwendungen, welche in einer Client-Server-
Struktur arbeiten wobei die Clients auch über das Internet mit dem Server kommunizieren.
In einem aktuellen Projekt ist SomSoft an der Entwicklung eines Service-Management-
Systems für die Automatisierungstechnik beteiligt, dessen Komponenten über eine recht
komplexe Netzstruktur miteinander verbunden sind. Dabei werden vertrauliche Daten
ausgetauscht, die momentan im Testbetrieb unverschlüsselt über das Netz und damit auch
das Internet übertragen werden. Da dieser Umstand datenschutzrechtlich unzumutbar ist
und von keinem Kunden, dank des gestiegenen Bewusstseins für die Sicherheit und Pri-
vatssphäre von Daten während des Transports im Internet, geduldet wird, sollen die Ver-
bindungen per VPN geschützt werden. In anderen Projekten, die auch kleinere Unterneh-
men oder Privatleute betreffen, besteht ebenso der Wunsch nach Sicherheit bei der Date-
übertragung.
1.2 Ziele
Ziel der Diplomarbeit ist es eine Übersicht der am Markt befindlichen Lösungen zur Im-
plementierung von Virtuellen Privaten Netzwerken aufzustellen, ihre Funktionsweise zu
analysieren und auf ihre Einsatztauglichkeit in verschiedenen Infrastrukturen zu testen. Im
Mittelpunkt sollen dabei Sicherheitsaspekte wie verwendete Verschlüsselungsmethoden
und Authentizitätssicherung stehen, aber auch Installation, Konfiguration und Wartung
von mit den Lösungen zu implementierenden Netzen. Anhand der gewonnenen Erkennt-
nisse soll die Anwendbarkeit der Lösungen für Industrie und Wirtschaft sowie Privatan-
wender analysiert werden.
1
2 VPN-Technologien
,,Ein virtuelles privates Netz (VPN) ist ein Netz von logischen Verbindungen zur Übermitt-
lung von privaten Daten und Informationen bzw. Datenverkehr. Eine logische Verbindung
ist eine Netzverbindung zwischen einem Sender und einem Empfänger, bei der der Weg
der Informationen und die Bandbreite dynamisch zugewiesen wird."[1, S.8]
VPNs sind Netzwerke, die zum Transport privater Daten meist öffentliche Netze wie bspw.
das Internet nutzen. Die Verbindung wird dabei durch einen Tunnel zwischen VPN-Client
und -Server realisiert, wobei dieser Tunnel oftmals durch Verschlüsselung geschützt wird.
Auch ohne Verschlüsselung besteht bereits ein VPN, der eigentliche Schutz der Daten vor
unbefugten Zugriffen wird dabei jedoch nicht gewährleistet. Da es am Markt zahlreiche
VPN-Technologien gibt, welche unterschiedlicher Herkunft sind, verschiedene Ansätze
verfolgen und unterschiedliche Einsatzgebiete bedienen können, sollen im Folgenden ei-
nige dieser Technologien vorgestellt werden. Dabei wird auf deren Funktionsweise einge-
gangen und die Umsetzung des Schutzes der transportierten Daten erläutert. Weiterhin
werden Schwachstellen und die Interoperabilität zwischen verschiedenen Systemen auf-
gezeigt. Die untersuchten VPN-Lösungen sind:
· PPTP - Point-to-Point Tunneling Protocol
· IPSec
· L2TP - Layer 2 Tunneling Protocol
· Tinc - Tinc is not cabal
· OpenVPN
2
2 VPN-Technologien
2.1 PPTP - Point-to-Point-Tunneling-Protokoll
2.1.1 Einleitung
Das Point-to-Point-Tunneling-Protocol [Zor99] stellt ein Protokoll dar, welches es erlaubt
das Point-to-Point-Protocol über IP-Verbindungen zu tunneln. Es wurde in Zusammenar-
beit mehrerer Firmen (u.a. Microsoft) entwickelt. Es ist dafür gedacht, Außendienstmitar-
beitern (Roadwarrior) eines Unternehmens den Zugriff auf das Firmennetzwerk auf ein-
fache Art und Weise zu ermöglichen. Microsofts Implementierung von PPTP ist stark in
Verruf geraten, da deren Authentifizierungsmechanismen MS-Chap Version 1 und 2 große
Sicherheitslücken aufweisen, wie von Schneier und Mudge [5] festgestellt wurde. Auf Mi-
crosofts Implementierung soll im folgenden genauer eingegangen werden, da diese in den
meisten PPTP-Lösungen eingesetzt wird.
2.1.2 Funktionsweise
PPTP stellt eine Client-Server-Architektur dar, wobei der Server als PPTP-Network Server
(PNS) und der Client, also das Endgerät, als PPTP-Access Concentrator (PAC) bezeichnet
wird. Ein PPTP-Tunnel besteht aus zwei Verbindungen, einer TCP-Kontrollverbindung
und einem IP Tunnel zur Datenübertragung, welche eine erweiterte Version des GRE-
Protokolls [Net00] zur Tunnelung benutzt.
Die Kontrollverbindung
Zunächst wird eine TCP-Kontrollverbindung vom PAC oder PNS zum Port 1723/TCP der
Gegenstelle aufgebaut. Dabei werden Zugangsinformationen, die Anzahl möglicher PPP-
Verbindungen, die Fähigkeiten von PNS und PAC, sowie deren DNS-Namen übertragen.
Diese Nachricht wird als Start-Control-Connection-Request (Start-CC-Request) bezeichnet
und mittels Start-Control-Connection-Reply (Start-CC-Reply) beantwortet. Um die Bereit-
schaft von PAC und PNS auch ohne Übertragung von Nutzdaten zu überprüfen, wird im
Intervall von 60 Sekunden ein Echo-Mechanismus ausgeführt, bei dem ein Echo-Request
und als Antwort ein Echo-Reply gesendet werden. Bei Nichtbeantwortung eines Echo-
Requests wird automatisch ein Stop-Control-Connection-Request gesendet, der zur Been-
digung der Kontrollverbindung führt. Ist die Kontrollverbindung aufgebaut, werden über
3
2 VPN-Technologien
diese auch Parameteränderungen in der Verbindung mitgeteilt, z.B. um Datenstaus zu ver-
hindern. Wenn mehrere PACs Verbindungen zu einem PNS bestehen, können die Parame-
ter für jede einzelne Verbindung geändert werden, da PPTP Session-orientiert arbeitet und
jede Session separat behandelt.
Jede Nachricht der Kontrollverbindung beginnt mit einem 8 Byte langen Header, der die
Länge der Nachricht, deren Typ sowie ein sog. ,,Magic Cookie" enthält. Der Nachrichten-
typ kann entweder eine Kontrollnachricht oder eine Verwaltungsnachricht sein, wobei es
von letzterem keine Definitionen gibt. Das Magic Cookie hat immer den gleichen Inhalt
und soll sicherstellen, dass der Empfänger mit dem TCP-Strom synchronisiert ist. Von den
Kontrollnachrichten gibt es 15 verschiedene Möglichkeiten, sechs davon für das Manage-
ment der Kontrollverbindung, sieben für das Anrufmanagement, eine weitere für Fehler-
meldungen und eine um die Session zu kontrollieren.
Tunnel-Verbindung
Beim PPTP werden die Nutzdaten per PPP zwischen PAC und PNS übertragen. Diese
werden in GRE Pakete eingeschlossen, welche wiederum über IP transportiert werden.
Der benutzte GRE-Header ist allerdings etwas erweitert gegenüber der eigentlichen GRE-
Spezifikation. Die hauptsächliche Erweiterung besteht im Vorhandensein einer Quittungs-
Nummer (Acknowledgement Number), welche zur Bestätigung empfangener Pakete ver-
wendet wird. Jedes Paket enthält eine aufsteigende Sequenznummer; der Empfänger be-
stätigt den ordnungsgemäßen Empfang, indem in der Antwort die Quittungsnummer
gleich der Sequenznummer gesetzt wird. Wenn eine Quittungsnummer erhalten wird,
werden automatisch alle Pakete mit einer Sequenznummer kleiner gleich dieser Nummer
als quittiert betrachtet.
2.1.3 Sicherheit
PPTP selbst beschreibt keinerlei spezifische Methoden zur Authentifizierung und Verschlüs-
selung. Im darunter liegenden PPP allerdings können verschiedene Methoden für diese
Zwecke eingebunden werden. Das Point-to-Point Protokoll kennt mehrere Authentifizie-
rungsmechanismen wie z.B. PAP (unverschlüsseltes Kennwort), SPAP (Shiva-Password-
Authentication-Protocol), CHAP (Challenge-Authentication-Protocol), sowie Microsofts CHAP
Implementierungen MS-CHAP und MS-CHAP v2.
4
2 VPN-Technologien
In Microsofts Implementierung von PPTP in Windows NT und höher gibt es nun drei
Möglichkeiten der Authentifizierung:
1. Passwörter im Klartext (es wird ein Klartext-Passwort von Client zu Server gesendet)
2. Passwort-Hash (es wird ein Hash des Passworts gesendet)
3. Challenge/Response (Client und Server authentifizieren sich, indem das MS-CHAP
Challenge/Response Protokoll zum Einsatz kommt.
Letztere muss eingesetzt werden, damit die übertragenen Pakete verschlüsselt werden. Es
kommt dann das Microsoft Point-to-Point Encryption Protocol (MPPE [Sys01b]) zum Ein-
satz, was den RC4 Stream-Chiffre mit einem 40-Bit oder 128-Bit Schlüssel nutzt, der Client
und Server bekannt sein muss. Der 40-Bit Schlüssel wird ermittelt, indem aus dem Lan
Manager Hash des Nutzer-Passwortes per SHA ein 64 Bit Schlüssel erzeugt wird und die
höherwertigen 24 Bit auf 0xD1269E gesetzt werden. Ein 128 Bit Schlüssel wird erzeugt,
indem der Windows NT Hash des Passwortes mit einem 64 Bit Zufallswert, der während
des MS-CHAP vom Server zum Client gesendet wurde, zusammengefügt und anschlie-
ßend per SHA gehasht wird. Der 40 oder 128 Bit Schlüssel wird dann benutzt zur Initiali-
sierung des RC4. Um die Pakete mitzuzählen, hat MPPE ein sog. "coherency count". Alle
256 Pakete wird dann ein neuer RC4 Schlüssel generiert, indem der vorherige Schlüssel
und der Originalschlüssel mit SHA gehasht werden. Wenn die Synchronisation verloren
geht, d.h. es kommt ein Paket mit unerwarteter Paketnummer an, wird der RC4 mit dem
momentanen Schlüssel reinitialisiert.
MS-CHAP selbst hat den folgenden Ablauf: Der Client fordert den Login an, und bekommt
vom Server einen 8-Byte Zufallswert übermittelt. Aus diesem berechnet der Client den Lan
Manager Hash und hängt fünf Nullen an um einen 21-Byte String zu erzeugen. Dieser wird
in drei 7-Byte-Schlüssel zerteilt, wobei jeder Teil dazu benutzt wird, den zuvor erhaltenen
Zufallswert zu verschlüsseln. Analog wird diese Prozedur mit dem Windows NT Hash
durchgeführt. Heraus kommt jeweils ein 24-Byte langer Chiffre, welcher zum Server ge-
sendet wird. Der Server führt die gleiche Verschlüsselungsprozedur durch und vergleicht
den erhaltenen Wert mit dem von ihm ermittelten; bei Übereinstimmung ist die Authenti-
fizierung komplett. Ob der Lan Manager oder Windows NT Hash vom Server verwendet
wird, wird per Flag im Paket festgelegt.
5
2 VPN-Technologien
2.1.4 Schwachstellen
Hash-Funktionen
Microsoft benutzt zwei verschiedene Hash-Funktionen für die zu überprüfenden Passwör-
ter. Zum einen ist dies der Lan Manager Hash, welcher noch aus der OS/2-Entwicklung
stammt, zum anderen ist dies der Windows NT Hash.
Lan Manager Hash
Beim Lan Manager Hash geschieht nun folgendes:
Passwörter werden in eine 14 Zeichen lange Kette konvertiert durch Verkürzung zu langer,
oder mit Nullen aufgefüllter zu kurzer Passwörter. Die ganze Zeichenkette wird in Groß-
buchstaben gewandelt und in zwei sieben Byte lange Hälften geteilt. Anschließend wird
jede Hälfte als Schlüssel für DES benutzt und eine fixe Konstante damit verschlüsselt, was
in zwei 8 Byte langen Zeichenketten resultiert. Diese werden wieder zusammengefügt und
als 16 Byte Hash-Wert benutzt. An dieser Stelle ist leicht zu erkennen, dass dies kein siche-
rer Hash sein kann, da zum einen alle Buchstaben in Großbuchstaben konvertiert werden,
was den möglichen Wertebereich immens einschränkt, zum anderen wird selbst ein 30 Zei-
chen langes Passwort als 2 mal 7 Zeichen behandelt durch die Teilung. Weiterhin gibt es
keinen ,,externen" Einfluss auf das Ergebnis, so dass zwei gleiche Passwörter auch den
gleichen Hash ergeben. Die zwei Passworthälften werden zudem unabhängig bearbeitet
und können auch bei einer Brute-Force-Attack unabhängig getestet werden. Auch ist leicht
zu ermitteln, ob ein Passwort kürzer als 8 Zeichen ist, da die zweite Passworthälfte in die-
sem Falle mit Nullen gefüllt wird und dementsprechend immer der gleiche Hash dafür
entsteht.
Windows NT Hash
Der Windows NT Hash ist sicherer als der Lan Manager. Passwörter
länger als 14 Zeichen sind möglich, welche zuerst nach Unicode geändert werden. Das
Passwort wird nicht zerteilt sondern als Ganzes behandelt und mittels MD4 gehasht, was
in einem 16 Byte Ergebnis endet.
Problem
Microsoft untergräbt nun allerdings die erhöhte Sicherheit des Windows NT
Hash, indem bei der Passwortübertragung immer auch der Lan Manager Hash mit über-
tragen wird aus Abwärtskompatibilitätsgründen zu Windows 95, welches nur diesen kennt.
Dadurch sind Passwörter, die kürzer als 15 Zeichen sind, potentiell gefährdet, denn so ist
6
2 VPN-Technologien
es erneut möglich den Passwortinhalt zu ermitteln. Anschließend braucht man nur noch
die Groß/Kleinschreibung auszuprobieren. Bei Passwörtern länger als 14 Zeichen, kennt
man auf diese Weise zumindest schon die ersten 14 Zeichen und kann möglicherweise auf
den Rest schließen.
Authentifizierung - MS-CHAP
Von der Verwendung des MS-CHAP bei der Authentifizierung ist dringend abzuraten, da
auch hier wieder der Lan Manager Hash mitgesendet wird. Die Client-Antwort ist jeweils
dreigeteilt und es kann damit problemlos jedes Drittel separat angegriffen werden. Da bei
Passwörtern kürzer als 8 Zeichen, die zweite Hälfte des Lan Manager Hashes konstant
ist, ist auch das letzte Drittel der Antwort konstant, bzw. es ist der Zufallswert mit einer
Konstanten verschlüsselt.
Verschlüsselung - MPPE
Bei der Verschlüsselung per MPPE Protokoll muss man beachten, dass nicht alle PPP Pake-
te verschlüsselt werden, sondern nur diejenigen, deren Protokollnummer in einem gewis-
sen Bereich liegen. Die Protokollnummer kennzeichnet, welches Protokoll im PPP Paket
transportiert wird. Der Rest, wozu bspw. PAP, CHAP und SPAP gehören, wird in jedem
Falle im Klartext übertragen.
Weiterhin wird bei jeder Authentifizierung des gleichen Nutzers auch der gleiche Schlüs-
sel benutzt, da dieser auf dem Nutzerpasswort basiert. Auch gibt es keine Authentizitätssi-
cherung der verschlüsselten Pakete, d.h. es nicht nachprüfbar, ob die empfangenen Pakete
auf ihrem Weg verändert wurden. Wenn nun in den PPP-Daten ein Protokoll transportiert
wird, was selbst auch keine Prüfung auf Veränderung unterstützt, so können unbemerkt
Daten verändert werden. Im günstigsten Falle für einen Angreifer werden dadurch Steu-
erbits verändert, was ihm Vorteile bringen kann. Er kann aber auch den ,,coherency count"
auf ungültige Werte verändern, so dass die Synchronisation verloren geht und für die Neu-
synchronisation fortlaufend der gleiche Schlüssel verwendet wird, was ihm wiederum er-
möglicht den Originaltext zu ermitteln.
Zu viele Informationen werden zudem im Klartext übertragen, teilweise über die Kontroll-
verbindung. So ist es bspw. durch Einsatz eines Paket-Sniffers möglich IP-Adressen von
7
2 VPN-Technologien
Server und Clients, den Nutzernamen und Maschinenname des Clients uvm. zu ermitteln.
Aus Sicherheitsaspekten dürften derlei Informationen nie zugänglich sein.
2.1.5 Interoperabilität
PPTP-Server gibt es für Windows, Linux (Poptop), Mac OS und FreeBSD (mpd). Auch
exisitieren Hardwareprodukte, welche als PPTP-Server arbeiten können. ,,PPTP Client"
ist existent als Client für MS-PPTP für Linux, FreeBSD, NetBSD und OpenBSD. Die Zu-
sammenarbeit dieser auf verschiedenen Plattformen angesiedelten Programme ist relativ
problemlos möglich.
2.2 IPSec
2.2.1 Einleitung
IPSec entstand während der Arbeit an IPv6. Dies kam dadurch, dass man bei der Ent-
wicklung der neuen IP-Version nicht die gleichen Fehler machen wollte wie bei IPv4, bei
dem Aspekte der Sicherheit, wie Vertraulichkeit, Authentizität und Integrität, vernach-
lässigt wurden. So wurden die IPSec-Protokolle, zu denen das Authentication-Header-
Protokoll [Net98a], Encapsulated-Security-Payload-Protokoll [Net98b] und das Internet-
Key-Exchange-Protokoll [Sys98] gehören, entwickelt, welche genau diese Funktionen be-
sitzen und daraufhin für IPv4 rückportiert wurden.
2.2.2 Funktionsweise
IPSec besitzt zwei unterschiedliche Arten zu arbeiten; den Tunnel- und den Transport-
modus. Je nach Modus unterscheiden sich der Aufbau und die Einsatzmöglichkeiten von
IPSec. Weiterhin ist der Aufbau von IPSec modular. D.h., dass die Algorithmen, die bei
der Authentifizierung, Verschlüsselung und Schlüsselmanagement zum Einsatz kommen,
austauschbar sind. Zudem muss gesichert werden, dass die Kommunikationspartner die
gleichen Algorithmen anwenden, weshalb für die Zeit der Kommunikation eine ,,Verein-
barung" getroffen wird, die IPSec-Security-Associations (SA).
8
2 VPN-Technologien
IPSec-Security-Associations - SA
Die Security Associations sind unidirektionale Parameterdefinitionen. Das bedeutet, dass
jeweils für den ein- und ausgehenden Verkehr einer bidirektionalen Kommunikation ei-
ne SA vorhanden sein muss. Diese beschreibt die Parameter der IPSec-Protokolle wie IP-
Adresse des Ziels, Security Parameter Index (SPI), Sequenznummer, Anti-Replay-Window,
Schlüssel, Protokoll, Algorithmen und Arbeitsmodi für Authentifizierung und Verschlüs-
selung, Lebensdauer der SA und der Schlüssel sowie Tunnel- und Transportmodus. Der
Zugriff auf eine SA ist durch das Tripel SPI, Zieladresse und Security Protokoll eindeutig
möglich. SPI ist dabei ein 32-Bit-Wert zur Unterscheidung von SA mit gleichem Ziel und
Protokoll. Als Zieladresse wird momentan nur eine Unicast-Adresse unterstützt und als
Protokoll kommen AH und ESP in Frage.
Security Policy
Da die SA selbst noch nicht zur Verschlüsselung oder Authentifizierung der Daten führt
sondern nur angibt, wie der Schutz des Verkehrs aussieht, allerdings nicht was und wann
konkret, sind Security Policies nötig. Diese werden in der Security-Policy-Datenbank hin-
terlegt, in welcher damit festgesetzt wird, welche Pakete wie gehandhabt werden. Dabei
gibt es die drei Möglichkeiten :Verwerfen (Discard), Durchlassen (Pass) und Anwendung
von IPSec-SAs (Apply). Zudem existieren IPSec-Selektoren, die die Security Policies fle-
xibel halten, indem die zu schützenden Dienste einzeln definiert, und falls diese Dienste
Ports unterstützen, auch diese Ports angegeben werden können.
Internet-Key-Exchange - IKE
Das Internet-Key-Exchange-Protokoll stellt kein eigenständiges Protokoll dar sondern setzt
auf dem UDP-Protokoll Port 500 auf und basiert auf dem ISAKMP- [Inc98b], Oakley-
Key-Determination- [oCSUoA98] und dem SKEME-Protokoll sowie der IPSec-Domain-of-
Interpretation [Alc98]. Es dient zum authentifizierten Austausch der Schlüssel und der
Aushandlung der IPSec-SAs. IKE arbeitet in zwei Phasen und mit verschiedenen Modi. In
Phase 1 wird zwischen den Kommunikationspartnern eine ISAKMP-SA mittels Main- oder
Aggressive-Mode ausgehandelt, über die die darauf folgenden Verhandlungen erfolgen. In
Phase 2 werden die IPSec-SAs erzeugt durch Verwendung des Quick-Mode, welcher auf
9
2 VPN-Technologien
die aus Phase 1 stammenden ISAKMP-SAs zugreift und daher einen sicheren Kanal be-
nutzt.
Main-Mode
Um den Main-Mode bzw. dessen Austauschvorgänge zu bescheiben, muss
man die zum Einsatz kommenden Authentifizierungsmethoden betrachten, da dies zu
großen Unterschieden führt.
RSA-Signaturen
Zunächst werden vom Initiator im ersten Paket ein oder mehrere Vor-
schläge für die ISAKMP-SA gesendet, welche mögliche unterstützte Authentifizierungs-
und Verschlüsselungsalgorithmen sowie Oakley-Gruppen enthalten. Daraufhin wird vom
Empfänger einer der Vorschläge ausgewählt und in Nachricht 2 bestätigt. Daraufhin kann
eine Anforderung des öffentlichen Schlüssels des Gegenübers erfolgen und es wird das öf-
fentliche Ergebnis einer Diffie-Hellmann-Berechnung sowie ein Zufallswert vom Initiator
verschickt, was zur Berechnung der Signatur vom Empfänger verwendet wird. Der Emp-
fänger tut nun das gleiche, was beiden Partnern die Finalisierung der Diffie-Hellmann-
Berechnung gestattet und damit zum Besitz eines symmetrischen Schlüssels führt. Damit
können folgende Nachrichten wie die Übermittlung des Zertifikats und der Identität be-
reits verschlüsselt erfolgen.
Public-Key-Verschlüsselung
Da bei der Authentifizierung mit PK-Verschlüsselung RSA-
Schlüssel benutzt werden, müssen die öffentlichen RSA-Schlüssel der Partner bereits aus-
getauscht worden sein. Sendung und Bestätigung der Vorschläge für die ISAKMP-SA er-
folgen wie bei den RSA-Signaturen. Daraufhin wird allerdings vom Initiator zusätzlich
zum Ergebnis der DH-Berechnung seine Identität und ein Nonce (Zufallswert) übertragen,
wobei diese bereits mit einem öffentlichen Schlüssel des Empfängers verschlüsselt werden.
Bei Vorhandensein mehrerer öffentlicher Schlüssel wird einer davon ausgewählt und zu-
sätzlich der Hash desjenigen übertragen. Der Empfänger agiert analog. Danach können
beiderseits die Identitäten und Nonces entschlüsselt und die DH-Berechnung zu Ende ge-
bracht werden. Aus dem Nonce und anderen Informationen wird ein Hash ermittelt und
mit dem symmetrischen Schlüssel übertragen. Die Partner können nun anhand des mit
dem Nonce erzeugten Hash davon ausgehen, dass die Gegenstelle den privaten Schlüssel
besitzt, da der Nonce mit diesem verschlüsselt wurde.
10
2 VPN-Technologien
Revidierte Public-Key-Verschlüsselung
Die revidierte Public-Key-Verschlüsselung äh-
nelt der Public-Key-Verschlüsselung mit dem Unterschied, dass die Identitäten und das
Ergebnis der DH-Berechnung nicht mit dem öffentlichen Schlüssel des Partners, sondern
mit einem symmetrischen Schlüssel verschlüsselt werden, wobei dieser Schlüssel aus dem
eigenen Nonce ermittelt wird. Die Gegenstelle kann diesen Nonce mit dem eigenen priva-
ten Schlüssel ermitteln und den symmetrischen Schlüssel in analogem Verfahren ermitteln.
Die Nachrichten 5 und 6 sind ähnlich denen der PK-Verschlüsselung und enthalten Has-
hes, die auf den Nonces basieren und damit der Authentifizierung dienen. Der Vorteil der
revidierten PK-Verschlüsselung liegt in der Verminderung der Public-Key-Verfahren von
4 auf 2 und damit weniger Ver-/Entschlüsselungen.
Preshared Keys - PSK
Nachricht 1 und 2 sind identisch denen der vorher beschriebe-
nen Verfahren. Danach werden wieder Nonce und Ergebnis der DH-Berechnung übertra-
gen, wobei bereits der Preshared Key für die Ausgangswerterzeugung der Berechnung der
Schlüssel verwendet wird. Anschließend können die Identitäten in Nachricht 5 und 6 ver-
schlüsselt ausgetauscht werden. Ein Nachteil ist aber, dass bei durch den ISP dynamisch
vergebenen IP-Adressen für alle Partner der gleiche PSK verwendet werden muss, da ja
die Identität noch nicht ermittelt werden konnte und die IP-Adresse unbekannt ist, und
damit der richtige PSK nicht gewählt werden kann.
Aggressive-Mode
Alle Informationen der Phase 1, die im Main-Mode in sechs Nach-
richten ausgetauscht werden, werden im Aggressive-Mode in drei Nachrichten ausge-
tauscht, was natürlich schneller ist. Allerdings gibt es keinen Identitätsschutz wie im Main-
Mode, so dass bei der Authentifizierung mittels PSK oder RSA-Signaturen die Identitäten
im Klartext übertragen werden. Der Vorteil bei PSK liegt aber darin, dass bei dynamischen
unbekannten IP-Adressen unterschiedliche PSK verwendet werden können eben durch die
nicht verschlüsselte Identität.
Quick-Mode
In Phase 2 des IKE-Protokolls wird der Quickmode verwendet, welcher auf
der Phase 1 aufbaut. Die Nachrichten werden verschlüsselt, authentifiziert und integer
übertragen. So können auch mehrere IPSec-SA unter einer ISAKMP-SA erzeugt werden,
was drei Nachrichten erfordert. Diese beinhalten den SA-Vorschlag, Hash- und Nonce-
Wert sowie eventuell Identitäten und bei Nutzung von Perfect Forward Secrecy den DH-
Wert, was zur Neuberechnung aller Schlüssel dient und sicherstellt, dass durch Ermittlung
11
2 VPN-Technologien
eines Schlüssels nicht auf weitere Schlüssel geschlossen werden kann.
Authentication-Header-Protokoll - AH
Das Authentication-Header-Protokoll (AH, IP-Protokoll 51) wird im RFC-2402 [Net98a]
beschrieben und stellt die Integrität und Authentifizierung der zu übertragenden Pakete si-
cher. Dies geschieht dadurch, indem zwischen IP-Header und Nutzlast der Authentication-
Header eingebracht wird. Dieser Header ist folgendermaßen aufgebaut:
Abbildung 2.1: AH-Protokoll
· Next Header gibt das Protokoll der übertragenen Daten an, Länge 8 Bit
· Length gibt die Länge des AH-Headers in Vielfachen von 32 Bit an, Länge 8 Bit
· Reserved ist reserviert für zukünftige Verwendung und derzeit mit Nullen gefüllt,
Länge 16 Bit
· SPI Security Parameter Index gibt die eindeutige SA an, Länge 32 Bit
· Sequence Number wird vom Absender fortlaufend vergeben und ist für den Emp-
fänger als Schutz vor Replay-Attacken nutzbar, Länge 32 Bit
· ICV Authentifizierungsdaten, die mittels HMAC gebildet werden; dabei wird auch
der äußere IP-Header mit in die Berechnung einbezogen, wobei bestimmte Felder
des IPv4 und IPv6 Headers ignoriert werden.
Das AH-Protokoll bietet keinerlei Vertraulichkeit der Nutzlast, da diese nicht verschlüsselt
wird.
Encapsulated-Security-Payload-Protokoll - ESP
Das Encapsulated-Security-Payload-Protokoll (IP-Protokoll 50) bietet im Gegensatz zum
AH-Protokoll zusätzlich eine Verschlüsselung an und dadurch Vertraulichkeit der Daten.
ESP wird nicht nur als Header eingebracht, sondern bettet die gesamten Daten ein:
12
2 VPN-Technologien
Abbildung 2.2: ESP-Protokoll
· SPI Security Parameter Index gibt die eindeutige SA an, Länge 32 Bit
· Sequence Number wird vom Absender fortlaufend vergeben und ist für den Emp-
fänger als Schutz vor Replay-Attacken nutzbar, Länge 32 Bit
· Payload enthält die meist verschlüsselten Nutzdaten; wenn der Verschlüsselungsal-
gorithmus mit Initialisierungsvektor arbeitet, so wird dieser vor den verschlüsselten
Daten gespeichert
· Padding ist erforderlich, da dieses bei Block-Ciphern zum Auffüllen der Blöcke be-
nötigt wird
· Padding Length enthält die Länge des Padding, um dieses wieder entfernen zu kön-
nen
· Next Header gibt das Protokoll der übertragenen Daten an, Länge 8 Bit
· ICV Authentifizierungsdaten, die mittels HMAC nach der Verschlüsselung der Da-
ten gebildet werden; dabei wird der äußere IP-Header nicht mit in die Berechnung
einbezogen
Tunnel- und Transportmodus
Die IPSec-Protokolle können in zwei verschiedenen Modi betrieben werden: dem Tunnel-
und dem Transportmodus. Der Unterschied liegt darin, dass beim Tunnelmodus das ge-
samte IP-Paket in einen IPSec-Header gekapselt wird und diesem ein neuer IP-Header
vorangestellt wird. Der Aufbau ist folgender:
Der Transportmodus kommt nur dann zum Einsatz, wenn zwei kommunizierende Rech-
ner für die Verschlüsselung zuständig sind. Agiert einer oder beide Rechner allerdings als
Gateway und schützen das gesamte IP-Paket, so wird der Tunnelmodus genutzt, da die
Pakete dann von den Gateways ausgepackt und mittels originalem IP-Header an das Ziel
geschickt werden.
13
2 VPN-Technologien
Abbildung 2.3: IPSec-Arbeitsmodi
2.2.3 Sicherheit
Authentifizierung/Integrität
Die Sicherstellung der Integrität der übertragenen Pakete sowie deren Authentifizierung
werden von IPSec durch Hash-Funktionen durchgesetzt. Der Hash wird aus einem gehei-
men Schlüssel sowie den zu schützenden Daten ermittelt, wobei lediglich die höchstwerti-
gen 96 Bit des HMAC als ICV verwendet werden. Dabei gibt es verschiedene Algorithmen
um den HMAC zu berechnen; laut IPSec-Standard sind die Implementierung von HMAC-
MD5-96 (RFC-2401 [Net98c]) sowie HMAC-SHA-1-96 (RFC-2404 [Gle98]) vorgeschrieben.
Allerdings gibt es weitere Drafts zur Beschreibung der Verwendung von SHA-2 mit 256,
384, 512 Bit Länge und es existieren noch HMAC-RIPEMD-160, HMAC-PANAMA und
HMAC-TIGER als weniger gebräuchliche Verfahren.
Verschlüsselung/Vertraulichkeit
Die Vertraulichkeit der zu übertragenden Daten wird bei IPSec durch symmetrische Ver-
schlüsselung mit einem geheimen Schlüssel im CBC-Modus gewährleistet. Verlangt wird
von den IPSec-Standards die Unterstützung von NULL (RFC-2410 [NIS98b]), CBC-DES
(RFC-1829 [Day95a]) sowie CBC-DES mit explizitem Initialisierungsvektor (RFC-2405 [Inc98a]).
Verwendung finden jedoch nach RFC-2451 [Inc98c] auch die Verschlüsselungsalgorithmen
RC5, RC6, IDEA, CAST-128, Blowfish, 3DES und AES, da diese wesentlich sicherer sind
als DES, welches nur einen 56 Bit langen Schlüssel benutzt. Alle Verfahren sind Cipher-
Block-Chaining-Verfahren, so dass ein Initialisierungsvektor zum Einsatz kommt. Dieser
wird zu Beginn zufällig ermittelt. Der verschlüsselte Block wiederum wird als IV für den
folgenden Block verwendet und in den meisten Fällen wird der letzte Block eines Pakets
als IV für das nächste Paket genutzt. Da bei CBC die Daten in Blöcken verarbeitet werden
14
2 VPN-Technologien
und vermutlich selten die Datenlänge ein Vielfaches der Blocklänge ist, muss der Block
aufgefüllt werden.
Replay-Schutz
Um zu verhindern, dass ein Angreifer aufgezeichnete Pakete nachträglich wieder einspie-
len kann, bietet IPSec einen optionalen Schutz. Dabei wird vom Absender eine monoton
steigende Sequenznummer in die Pakete eingebracht, welche der Empfänger nutzen kann,
um erneut eingespielte Pakete zu erkennen.
2.2.4 Schwachstellen
Eine Schwachstelle von IPSec ist dessen immense Mächtigkeit, d.h. es gibt derart viele Kon-
figurationsmöglichkeiten, dass sogar bezweifelt wird, "dass überhaupt jemand IPSec mit
seinen vielfältigen Details vollständig verstanden hat"[3, S.8]. Dies ist zwar keine Schwach-
stelle im eigentlichen Sinne, kann allerdings zu Problemen führen. Weiterhin sind einige
Funktionalitäten mehr oder minder in Abhängigkeit der Implementierung oder des Pro-
duktes vorhanden.
Da IPSec aus der Entwicklung des IPv6 stammt, wird man bei IPv4 mit einigen Problemen
konfrontiert. So wird bspw. keine Network-Address-Translation (NAT) unterstützt, da bei
IPv6 mit seinem 128 Bit Adressraum wahrscheinlich kein NAT benötigt wird im Gegen-
satz zu IPv4 mit seinem 32 Bit Adressraum. Demnach sind gleichzeitige Verbindungen von
mehreren Arbeitsplätzen, die sich hinter einem NAT-Gateway befinden, nicht möglich. Al-
lerdings ist es durch Erweiterung der IPSec-Protokolle um NAT Traversal möglich, diese
selbst in UDP zu kapseln, welches wiederum NAT unterstützt. Aber auch diese Funktio-
nalität ist nicht durchgängig vorhanden.
Auch ist der Aufbau eines VPN von Roadwarriorn ohne feste IP oft mit Problemen verbun-
den. So ist der Einsatz des Main-Mode schlecht möglich, da Roadwarrior normalerweise
vom ISP eine dynamische IP-Adresse erhalten und somit die Auswahl des richtigen PSKs
beim Kommunikationspartner unmöglich wird. Somit müsste für alle Roadwarrior der
gleiche PSK verwendet werden, was wiederum ein Sicherheitsrisiko darstellt.
Im Aggressive-Mode und der Nutzung von PSK oder Signaturen werden dagegen die
Identitäten im Klartext übertragen, da dieser Modus keinen Identitätsschutz bieten kann,
15
2 VPN-Technologien
was sich unter Umständen ausnutzen lassen kann. Zusätzlich ist der Aggressive-Mode an-
fällig für DoS-Attacken, da durch die Reduzierung der Nachrichtenanzahl der Phase 1 auf
drei bereits das erste Paket eine Verschlüsselung erfahren muss. Dies hat zur Folge, dass
ein Angreifer durch sinnlose Verschlüsselungsvorgänge einen DoS erzeugen kann.
2.2.5 Interoperabilität
Es gibt unzählige Hardwarelösungen am Markt, darunter von Cisco, Checkpoint, Juniper
um nur einige zu nennen. Dazu kommen unterschiedliche Implementierungen software-
seitig in den verschiedenen Betriebssystemen wie Windows oder FreeS/WAN [Fre], racoon
[Rac] und isakmpd für Linux und andere Systeme. Durch die unzähligen Möglichkeiten an
Kombinationen in den Security Associations und andererseits die Eigenheiten jeder Imple-
mentierung der Hardwarehersteller ist eine reibungslose Zusammenarbeit verschiedener
Produkte nicht immer möglich. Dies liegt zum einen daran, dass nicht jede Lösung jeden
Verschlüsselungsalgorithmus unterstützt, andererseits auch nicht alle Authentifizierungs-
methoden eingesetzt werden können. So ist meist die Nutzung von Preshared Keys als
kleinster gemeinsamer Nenner unumgänglich. Zusätzlich wird nicht überall NAT Traver-
sal unterstützt, was den Einsatz eines VPN-Clients hinter einem NAT-Gateway erschwert.
Das Hauptproblem dürfte jedoch das IKE-Protokoll sein, bei dem zu viele verschiedene
Parameter vorhanden sind, die von jeder Lösung unterschiedlich gesetzt werden. Zur Si-
cherstellung der Interoperabilität zwischen bestimmten Produkten werden vom Virtual
Private Network Consortium [VPN] Interoperabilitätstests durchgeführt, die die Zusam-
menarbeit testen sollen. Teilnehmer an diesen Tests, deren Produkt diese besteht, darf sich
das VPNC Certified Logo anhängen. Dies sollte eigentlich das Ziel sämtlicher Hersteller
und Implementierungen von IPSec VPNs sein, die Liste der zertifizierten Produkte ist je-
doch leider recht kurz.
2.3 L2TP
2.3.1 Einleitung
Das Point-to-Point-Protokoll (RFC-1661 [Day94]) definiert einen Mechanismus, mit dem
Pakete beliebiger Protokolle (z.B. IP, IPX, NetBUI, SNA) über eine Layer-2-Verbindung
transportiert werden können. Dabei wird vom Benutzer eine L2-Verbindung angefordert,
16
2 VPN-Technologien
über die anschließend PPP benutzt wird. Dabei sind die Endpunkte der L2- und der PPP-
Verbindung auf dem gleichen physikalischen Gerät. Bei L2TP besteht nun aber die Erwei-
terung, dass diese beiden Endpunkte auf unterschiedlichen Geräten sein können. Dabei
endet die L2-Verbindung auf dem L2TP Access Concentrator (LAC), welcher dann die
PPP-Pakete zum L2TP Network Server (LNS) tunnelt.
2.3.2 Funktionsweise
Das L2TP benutzt zwei verschiedene Nachrichtenarten - Daten- und Steuerungsnachrich-
ten. Um Tunnel und Anrufe aufzubauen, zu verwalten und abzubauen, werden Steue-
rungsnachrichten verwendet, welche aus mehreren sog. AVP (Attribute Value Pair) beste-
hen. Datennachrichten werden verwendet um in PPP gekapselte Daten über den Tunnel
zu transportieren. Der Steuerungskanal garantiert, dass Kontrollnachrichten erfolgreich
übertragen werden; der Datenkanal kann dies nicht. Die beiden Nachrichtenarten werden
in der selben Verbindung geführt, d.h. es ist nur eine Verbindung für beide Arten nötig.
Die PPP-Daten-Pakete werden über den unzuverlässigen Datenkanal geschickt, wobei vor
die Pakete noch der Tunnel-Header zur Bestimmung von Ein- und Ausgang, ein UDP-
Header sowie ein L2TP-Header gesetzt wird. Prinzipiell muss nicht UDP als Transport-
protokoll genutzt werden, Frame Relay und ATM sind ebenso möglich. Da das Internet,
und damit IP, vermutlich am häufigsten benutzt werden und auch in den Testszenarien
zum Einsatz kommt, soll an dieser Stelle nur auf UDP eingegangen werden.
Abbildung 2.4: L2TP-Paket
Kontrollnachrichten
Es gibt verschiedene Arten von Kontroll- oder Steuerungsnachrichten, bspw. für das Ma-
nagement der Steuerungsverbindung, das Call Management, für den Fehlerreport sowie
die Kontrolle der PPP-Sitzung. Steuerungsnachrichten werden somit aus Message Type
17
2 VPN-Technologien
IDs und verschiedenen Paaren aus Attribut und Wert (AVP) bestimmt. Durch diese wird
festgelegt um welche Art Nachricht es sich genau handelt. So werden durch AVP Daten
über die Verbindungsfähigkeiten, Hostnamen, zugewiesene Tunnel-IDs, aufgetretene Feh-
ler und auch die Forderung nach Authentifizierung signalisiert, um nur einen kleinen Teil
der möglichen AVP zu nennen.
Steuerungsverbindung
Um nun PPP über L2TP zu tunneln, sind zwei Schritte nötig - der Aufbau einer Steuerungs-
verbindung für den Tunnel und der anschließende Sitzungsaufbau durch eine Verbin-
dungsanforderung. Der Aufbau der Steuerungsverbindung beinhaltet auch die Authentifi-
zierung der Gegenstelle und kann von entweder von LAC oder LNS initiiert werden. Dem-
nach wird ein Start-Control-Connection-Request gesendet, welcher von der Gegenseite mit
einem Start-Control-Connection-Reply beantwortet wird. Dem folgt eine Start-Control-
Connection-Connected Nachricht und deren Beantwortung durch eine Zero-Length-Body-
Nachricht, was den erfolgreichen Verbindungsaufbau signalisiert. Falls keine Daten ausge-
tauscht werden, wird ca. alle 60 Sekunden eine Hello-Nachricht gesendet, welche wieder-
um mit einer ZLB-Nachricht quittiert wird.
Sitzungsaufbau
Nachdem die Steuerungsverbindung erfolgreich aufgebaut wurde, können mehrere Sit-
zungen angelegt werden, wobei jede zu einem einzelnen PPP-Strom zwischen LAC und
LNS gehört. Da zwischen einem Incoming Call (ein Anruf, der von einem LAC empfan-
gen wird und an den LNS weitergegeben wird) und einem Outgoing Call (ein Anruf von
einem LAC für ein LNS) unterschieden wird, ist auch der Sitzungsaufbau unterschiedlich.
So wird der LNS vom LAC aufgefordert einen Incoming Call anzunehmen, und der LAC
vom LNS aufgefordert einen Outgoing Call zu akzeptieren.
Tunnelung
Sobald ein erfolgreicher Sitzungsaufbau durchgefhrt wurde, können PPP-Pakete transpor-
tiert werden. Dazu werden diese in L2TP gekapselt und vom LAC über den Tunnel ge-
schickt. Der LSN empfängt diese, und behandelt das eingeschlossene PPP-Paket so, als
18
2 VPN-Technologien
wäre es an einem normalen PPP-Interface angekommen. In den zu verschickenden Nach-
richten werden immer Tunnel ID und Session ID des Empfängers eingebracht.
L2TP Header
Der L2TP Header ist für Daten- und Steuerungsnachrichten identisch, wobei es optionale
Felder gibt, welche für Steuerungsnachrichten zwingend notwendig und für Datennach-
richten optional sind. T kennzeichnet den Typ der Nachricht, 0=Daten, 1=Steuerung
Abbildung 2.5: L2TP-Header
L wenn L=1, so ist das Length-Feld gesetzt
S wenn gesetzt, so sind Sequenznummern vorhanden
O wenn gesetzt, so ist das Offsetfeld vorhanden
P wenn gesetzt, so sollen die Pakete mit erhöhter Priorität behandelt werden
x für zukünftige Verwendung reserviert
Ver = 2 für L2TP
Length Gesamtlänge in Byte
Tunnel ID kennzeichnet den Tunnel beim Empfänger
Session ID kennzeichnet die einzelne Sitzung im Tunnel beim Empfänger
Ns, Nr sind Sequenznummern für s=gesendete und r=empfangene Pakete
Offset bestimmt den Beginn der Daten im L2TP-Paket
19
2 VPN-Technologien
2.3.3 Sicherheit
L2TP beinhaltet lediglich eine einfache optionale Tunnel-Authentifizierung mittels CHAP-
Protokoll. Wenn überhaupt gewünscht, so wird diese während des Aufbaus der Steue-
rungsverbindung durchgeführt, indem eine Challenge AVP in die Start-Connection-Request-
oder Start-Connection-Reply-Nachricht eingefügt wird, welche in der folgenden Nachricht
mittels Challenge Response beantwortet werden muss. Entspricht die Antwort nicht den
Erwartungen, sprich sie ist falsch, so darf der Tunnelaufbau keinesfalls durchgeführt wer-
den. Wenn diese Authentifizierung nicht vorgenommen wird, gibt es keinerlei weitere
Möglichkeiten die Vertraulichkeit der Daten zu sichern. Allerdings existiert bei der IETF
ein Vorschlag zur Sicherung der Daten mittels IPSec (RFC-3193 [Sys01a]). Dies ermöglicht
eine sichere End-to-End-Verbindung zwischen den Gegenstellen.
2.3.4 Schwachstellen
L2TP selbst besitzt keine Mechanismen zur Sicherung der übertragenen Daten. Das bedeu-
tet, dass diese unverschlüsselt transportiert werden, was den eigentlichen Wunsch nach
Sicherheit und Vertraulichkeit der Daten nicht erfüllen kann. Weiterhin besteht das Pro-
blem, dass bei Nicht-Nutzung von Sequenznummern bei der Übertragung von L2TP kein
Paketverlust festgestellt werden kann. Toleriert das transportierte Protokoll keine Neu-
sortierung der ankommenden Pakete, so müssen Sequenznummern verwendet werden.
Ebenso kann es für das transportierte Protokoll problematisch sein, wenn Pakete verloren
gehen. Daher benötigt L2TP eine Komponente, die den Schutz der Daten gewährleisten
kann, beispielsweise IPSec oder TLS/SSL. RFC-3193 [Sys01a] beschreibt die Verwendung
von IPSec, RFC-2716 [Cor99] beschreibt die Grundlagen für L2Sec, eine Kombination von
L2TP und TLS.
2.3.5 Interoperabilität
Die Windows Server Versionen 2000 und 2003 besitzen einen L2TP-Server sowie -Client,
Windows 2000 und Windows XP besitzen nur den L2TP-Client. Allerdings muss man sa-
gen, dass dies kein ,,pures" L2TP arstellt, sondern die von der IETF empfohlene Variante
L2TP/IPSec nach RFC-3193 [Sys01a]. IPSec dient in diesem Falle der Paketauthentifizie-
rung, welche bei L2TP nicht vorhanden ist. Weiterhin gibt es für alle BSD und POSIX Platt-
formen (FreeBSD/NetBSD/OpenBSD/Apple Mac OS X, Linux/BSD/UNIX-artige BS) ei-
20
Ende der Leseprobe aus 120 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2005, Analyse und Vergleich von VPN-Protokollen, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/224768
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare