Einrichtung eines Virtual Private Network mit IPsec

Fachhochschule für die Wirtschaft
- FHDW Hannover
Betriebssysteme
Projektarbeit
Einrichtung eines Virtual Private Network
mit IPsec
Prüfer:
Prof. Dr. Hellberg
Verfasser:
Arthur Brack und Arne Möhle
3. Theoriequartal
Studiengang Informatik
21. Dezember 2004
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Projektbeschreibung . . . . . . . . . . . . . . . . . . . . . . .
2 Grundlagen
2.1 Virtual Private Network . . . . . . . . . . . . .
2.1.1 Architekturen . . . . . . . . . . . . . . .
2.1.1.1 Client-to-Client . . . . . . . . .
2.1.1.2 Network-to-Network . . . . . .
2.1.1.3 Client-to-Network . . . . . . .
2.1.2 Überblick über Implementierungen . . .
2.2 Verschlüsselung . . . . . . . . . . . . . . . . . .
2.2.1 Klassifizierung von Kryptosystemen . . .
2.2.1.1 Symmetrische Kryptosysteme .
2.2.1.2 Asymmetrische Kryptosysteme
2.2.2 RSA-Kryptosystem . . . . . . . . . . . .
2.2.3 Public-Key-Infrastruktur (PKI) . . . . .
2.2.4 Diffie-Hellman-Schlüsselaustausch . . . .
2.3 Security Architecture for IP (IPsec) . . . . . . .
2.3.1 Verbindungsmodi . . . . . . . . . . . . .
2.3.1.1 Transport-Modus . . . . . . . .
2.3.1.2 Tunnel-Modus . . . . . . . . .
2.3.2 Security Association (SA) . . . . . . . .
2.3.3 Security Policy (SP) . . . . . . . . . . .
2.3.4 Internet Key Exchange (IKE) . . . . . .
2.3.4.1 Phase 1 . . . . . . . . . . . . .
2.3.4.2 Phase 2 . . . . . . . . . . . . .
2.3.5 Authentication Header (AH) . . . . . . .
2.3.6 Encapsulated Security Payload (ESP) . .
2.3.7 Vor- und Nachteile von IPsec . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
4
4
5
5
5
5
6
7
7
7
7
8
9
10
10
11
11
12
14
14
15
15
17
17
19
20
3 Einrichtung und Konfiguration
3.1 Netzwerk-Aufbau . . . . . . . . . . .
3.2 Installation benötigter Software . . .
3.3 Aufbau der Public-Key-Infrastruktur
3.4 Einrichtung Linux Gateway . . . . .
3.4.1 Konfiguration von Setkey . .
3.4.2 Konfiguration von Racoon . .
3.4.3 Initialisierung von IPsec . . .
3.5 Einrichtung Linux RoadWarrior . . .
3.6 Einrichtung Windows Roadworrior .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
22
22
25
25
26
27
29
32
4 Ausblick
4.1 DHCP-over-IPsec . . . . . . . . . . . . . . . .
4.2 Firewall Traversal . . . . . . . . . . . . . . . .
4.3 Network Address Translation (NAT) Traversal
4.4 Performanz-Untersuchungen . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
34
35
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A Literaturverzeichnis
37
B Ausgewählte Links
38
C Glossar
39
2
Kapitel 1
Einleitung
1.1
Motivation
Insbesondere Firmen haben oft Außendienstmitarbeiter, die Zugriff auf das
lokale Netz der Firma für ihre Arbeit benötigen. Hierfür können zum Beispiel
Leitungen bei Telefondienstanbietern gemietet werden, die eine vertrauliche
und geschützte Verbindung gewährleisten.
Eine weitere Methode besteht darin, das kostengünstigere Internet für
die Verbindung zum lokalen Netz der Firma zu verwenden. Da die Firmendaten jedoch meist vertraulich sind, dürfen diese nicht ungeschützt über das
Internet übertragen werden. Auch sollten sich nur authentifizierte Personen
in das LAN einwählen dürfen. Um dies zu gewährleisten, kann ein Virtual
Private Network (VPN) aufgebaut werden, welches durch einen ’Tunnel’ im
öffentlichen Netz einen sicheren und geschützten Zugang zum lokalen Netz
der Firma bietet.
Hierfür existieren Implementierungen von verschiedenen Herstellern, die
mehr oder weniger stabil und preisgünstig sind. Die Open-Source Gemeinde
bietet allerdings unter dem Betriebssystem Linux eine freie und stabile Implementierung des standardisierten Protokolls IPsec, mit dem man ein Virtual
Private Netzwork aufbauen kann. Dieses wird als Grundlage für diese Projektarbeit verwendet.
1.2
Projektbeschreibung
Zuerst soll das VPN Konzept und dessen unterschiedliche Architekturen vorgestellt werden. Danach wird auf die IPsec-Implementierung und die dazugehörigen Protokolle genauer eingegangen. Zudem werden hierfür notwendige
Grundlagen zur Public-Key-Infrastruktur und Verschlüsselung behandelt.
3
Eingerichtet werden soll eine heterogene Client-to-Network VPN-Architektur mit IPsec, wobei mehrere Clients als RoadWarrior über das Internet
VPN-Tunnel zu einem VPN-Gateway aufbauen können und somit Zugriff auf
das LAN haben. Die Authentifikation der RoadWarrior und des Gateways soll
mit Hilfe von Zertifikaten, also einer Public-Key-Infrastruktur, erfolgen. Das
Gateway wird unter Suse Linux 9.1 laufen, ein RoadWarrior unter Windows
und einer ebenfalls unter Linux.
Am Ende werden auf Probleme beim Einsatz von IPsec und deren Lösungen eingegangen sowie ein Ausblick auf erweiterte Konfigurationsmöglichkeiten gegeben.
4
Kapitel 2
Grundlagen
2.1
Virtual Private Network
In einem Virtual Private Network sind mehrere Hosts und/oder nicht-öffentliche Netzwerke über ein öffentliches Netzwerk so miteinander verbunden, dass
private Daten untereinander ausgetauscht werden können. Dabei wird üblicherweise eine Verbindung über einen Tunnel1 durch das öffentliche Netzwerk
hergestellt, die meistens noch zusätzlich verschlüsselt wird um die privaten
Daten zu schützen.
So kann sich z.B. ein Mitarbeiter einer Firma in das lokale Firmennetzwerk einklinken, indem er einen Tunnel über das Internet erstellt. So hat er
vollen Zugriff auf das Firmennetzwerk, das aber immer noch gegen Angriffe
aus dem Internet geschützt ist. Ebenso ist es möglich zwei Firmennetzwerke,
die räumlich getrennt voneinander existieren, über einen Tunnel im Internet
zu verbinden, um diese als ein logisches Netzwerk darzustellen. Man kann
aber auch öffentliche Leitungen des Telefonnetzes mieten, um ein VPN aufzubauen. In diesem Fall ist keine Verschlüsselung notwendig, da die gemietete
Leitung als ’abhörsicher’ gilt.
Folgende Sicherheitsanforderungen sind beim Aufbau eines VPNs zu gewährleisten:
• Authentifizierung der Kommunikationspartner
• Datenintegrität
• Vertraulichkeit
• Schutz vor Replay-Attacken
1
In einem Tunnel werden die Daten eines Netzwerkprotokolls eingebettet in einem
anderen Netzwerkprotokoll übetragen.
5
2.1.1
Architekturen
In VPNs wird zwischen drei grundlegenden Arten von Architekturen unterschieden, die beliebig miteinander kombiniert werden können. Diese werden
in den folgenden Kapiteln beschrieben.
2.1.1.1
Client-to-Client
Bei einer Client-to-Client Architektur wird wie in Abbildung 2.1 gezeigt eine
gesicherte Verbindung direkt zwischen zwei Hosts aufgebaut.
Abbildung 2.1: Client-to-Client Architektur
2.1.1.2
Network-to-Network
Bei einer Network-to-Network Architektur werden zwei Netzwerke über Gateways, zwischen denen der Tunnel aufgebaut wird, miteinander verbunden.
Der Vorteil dieser Architektur ist, dass nur die Gateways über die VPNSoftware verfügen müssen und die Hosts nicht umkonfiguriert werden müssen.
Allerdings ist damit die Verbindung zwischen dem Gateway und den Hosts
des Netzwerks nicht sichergestellt. Die Abbildung 2.2 zeigt diese Architektur.
2.1.1.3
Client-to-Network
Bei einer Client-to-Network Architektur ist wie in Abbildung 2.3 gezeigt ein
Tunnel zwischen dem Gateway zu einem Netzwerk und einem Host aufgebaut.
Dieses Szenario wird oft eingesetzt, wenn z.B. ein Außendienstmitarbeiter als
RoadWarrior eine Verbindung in das private Firmennetz aufbaut.
6
Abbildung 2.2: Network-to-Network Architektur
Abbildung 2.3: Client-to-Network Architektur
2.1.2
Überblick über Implementierungen
Es gibt verschiede Ansätze ein VPN zu realisieren. Diese unterscheiden sich
maßgeblich darin, dass sie auf unterschiedlichen Protokollschichten des OSIModells aufsetzen. So setzen z.B. SSL-basierte (Secure-Socket-Layer) Lösungen auf der Transportschicht auf, während z.B. L2TP-basierte (Layer-toTunneling-Protocol) Lösungen auf der Sicherungsschicht aufsetzen. VPNProtokolle auf der Transportschicht oder höher bieten nur einen Schutz für
die jeweiligen Applikationen und nicht für den gesamten IP-Verkehr, wogegen Protokolle der Sicherungsschicht und darunter zu hardwareabhängig sind
und damit nicht universell einsetzbar.
Um den gesamten Datenverkehr zu schützen sind also Lösungen, die auf
7
der Vermittlungsschicht aufsetzen, am sinnvollsten. Das Security Architecture for IP (IPsec) ist eine dieser Lösungen und wird in dieser Projektarbeit
behandelt.
2.2
Verschlüsselung
In diesem Kapitel werden Grundlagen zur Verschlüsselung erläutert, die für
das Veständnis der IPsec-Protokolle notwendig sind.
2.2.1
Klassifizierung von Kryptosystemen
Ein Kryptosystem ist ein System, das Verfahren zur Ver- und Entschlüsselung von Informationen beschreibt, mit der Absicht, diese gegenüber Dritten
unleserlich zu machen. Mathematisch besteht ein Kryptosystem aus einer
Menge von Klartexten M , einer Menge von Chiffretexten C, einer Menge von Schlüsseln, dem sogenannten Schlüsselraum K, sowie den Funktionen zur Verschlüsselung encrypt : K × M → C und zur Entschlüsselung
decrypt : K × C → M . Für diese beiden Funktionen gilt mit m ∈ M und
k, k 0 ∈ K:
m = decrypt(k 0 , encrypt(k, m))
Die Sicherheit eines Verschlüsselungsverfahrens hängt von der Größe des
Schlüsselraums und der Güte der Verschlüsselungsfunktion ab.
Man teilt die Kryptosysteme in symmetrische und asymmetrische Kryptosysteme ein, die im folgenden erläutert werden. Die Abbildung 2.4 verdeutlicht noch einmal die Unterschiede.
2.2.1.1
Symmetrische Kryptosysteme
Ein symmetrisches Kryptosystem zeichnet sich dadurch aus, dass zur Verund Entschlüsselung der gleiche Schlüssel verwendet wird, d.h. nach obiger
Definition k = k 0 . Dabei ist es unbedingt erforderlich, dass dieser Schlüssel
geheim bleibt und deshalb nur authorisierten Personen bekannt gegeben wird.
Vertreter von symmetrischen Kryptosystemen sind z.B. das AES-Verfahren (Advanced Encryption Standard) oder das 3DES-Verfahren (Triple Data
Encryption Standard).
2.2.1.2
Asymmetrische Kryptosysteme
Asymmetrische Kryptosysteme benutzen für die Ver- und Entschlüsselung
unterschiedliche Schlüssel. Dabei ist es praktisch unmöglich, bei Kenntnis des
8
Abbildung 2.4: Klassifizierung von Kryptosystemen
einen den anderen Schlüssel zu berechnen. Dieses Verfahren wird auch PublicKey-Verschlüsselung genannt, da der Schlüssel zum Verschlüsseln veröffentlicht werden kann (öffentlicher Schlüssel), während der Schlüssel zum Entschlüsseln geheim bleiben muss (geheimer bzw. privater Schlüssel). Das bekannteste asymmetrische Kryptosystem ist das RSA-Verfahren, das im folgenden erläutert wird.
2.2.2
RSA-Kryptosystem
Das RSA-Verfahren (benannt nach Ronald L. Rivest, Adi Shamir und Leonard Adleman) ist ein asymmetrisches Kryptosystem, bei dem also zur Verund Entschlüsselung unterschiedliche Schlüssel verwendet werden.
Eine wichtige Eigenschaft des RSA-Kryptosystems ist die Möglichkeit,
mit dem privaten Schlüssel eine Nachricht zu verschlüsseln und mit dem
öffentlichen zu entschlüsseln. Denn es gilt für den privaten Schlüssel k 0 , den
öffentlichen Schlüssel k und der Klartextnachricht m:
9
m = decrypt(k 0 , encrypt(k, m)) = decrypt(k, encrypt(k 0 , m))
Dieser Zusammenhang wird bei digitalen Signaturen ausgenutzt, indem
zum Signieren der Hash-Wert2 einer Nachricht gebildet wird, der dann mit
dem privaten Schlüssel verschlüsselt wird.
signature(m) = encrypt(k 0 , hash(m)) = sm
Der Empfänger der Nachricht, der den öffentlichen Schlüssel des Senders kennt, kann nun eine empfangene Nachricht m0 verifizieren, indem er
den Hash-Wert sm wieder entschlüsselt und mit dem eigenen berechneten
der Nachricht m0 vergleicht. Sind beide identisch, so ist sichergestellt, dass
die empfangene Nachricht nicht verändert wurde und dass der Absender der
Nachricht tatsächlich derjenige ist, der den zum öffentlichen Schlüssel passenden privaten Schlüssel besitzt. Es muss also gelten:
decrypt(k, sm ) = hash(m0 )
Um die Verwaltung der öffentlichen Schlüssel und die Zuordnung zu Personen, Institutionen oder Programmen zentral zu halten, wurde die PublicKey-Infrastruktur entwickelt, die im folgenden Kapitel beschrieben wird.
2.2.3
Public-Key-Infrastruktur (PKI)
Mit Public-Key-Infrastruktur bezeichnet man ein System, welches ermöglicht,
digitale Zertifikate auszustellen und diese zu verteilen und zu prüfen.
Ein Zertifikat erbringt den Nachweis, dass ein öffentlicher Schlüssel zu
einer vorgegebenen Person gehört. Dies wird dadurch erreicht, dass es eine vertraulichen Zertifizierungsstelle (Certification Authority (CA)) gibt, die
Zertifikate ausstellt und diese mit ihrer Signatur versieht. Dies geschieht,
indem der Hash-Wert der Daten des Zertifikats (genauer: des Certification
Signing Request) mit dem privaten Schlüssel der Zertifizierungsstelle verschlüsselt wird. Die CA enthält ihrerseits ein eigenes Zertifikat, dessen öffentlicher Schlüssel zu dem privaten Signierungsschlüssel passt und das von ihr
selber signiert wurde.
Abgesehen von dem öffentlichen Schlüssel enthält ein Zertifikat insbesondere Informationen über den Namen des Inhabers des Zertifikates, die
2
Eine Hash-Funktion ist eine nicht umkehrbare Funktion, die Nachrichten variabler
Länge auf einen Wert (Hash-Wert) fester Bitbreite abbildet. Dabei ist es bei genügend
großen Bitbreiten praktisch unmöglich zwei unterschiedliche Nachrichten zu finden, die
den gleichen Hash-Wert ergeben. Beispiele für solche Hash-Funktionen sind MD5 (Message
Digest Algorithm 5) und SHA (Secure Hash Algorithm).
10
Gültigkeitsdauer des Zertifikats, das Signierungsverfahren und den Namen
und die Signatur der CA.
Die Verifizierung eines Zertifikats geschieht, indem die Signatur bzw. der
verschlüsselte Hash-Wert des Zertifikats mit dem öffentlichen Schlüssel der
zugehörigen CA entschlüsselt und mit dem selber berechneten Hash-Wert
verglichen wird. Dies setzt voraus, dass der Empfänger das Zertifikat der CA
besitzt, die in dem empfangenen Zertifikat angegeben ist.
2.2.4
Diffie-Hellman-Schlüsselaustausch
Der Diffie-Hellmann-Schlüsselaustausch ist kein Verschlüsselungsverfahren,
sondern beschreibt eine Möglichkeit, Schlüssel sicher über unsichere Kanäle
auszuhandeln oder auszutauschen. Dies läuft folgendermaßen ab:
1. Die Kommunikationspartner einigen sich auf eine Primzahl p und auf
die Primitivwurzel g mod p mit 2 ≤ g ≤ p − 2.
2. Der Kommunikationspartner 1 wählt ein zufälliges a und der Kommunikationspartner 2 ein zufälliges b mit a, b ∈ {0...p − 2}. Diese bleiben
geheim und werden nicht übertragen.
3. Nun berechnen beide A = g a mod p bzw. B = g b mod p
4. A und B werden über den unsicheren Kanal ausgetauscht.
5. Beide berechnen jetzt den gemeinsamen Schlüssel K mit K = B a mod
p = Ab mod p. Damit ist der gemeinsame Schlüssel K ausgehandelt.
Die Abbildung 2.5 verdeutlicht noch einmal den Ablauf.
2.3
Security Architecture for IP (IPsec)
IPsec stellt eine Sicherheitsarchitektur für die Kommunikation über IP-Netzwerke zur Verfügung und wurde 1998 während der Entwicklung von IPv6
spezifiziert. Folgende Sicherheitsaspekte können durch IPsec gewährleistet
werden:
• Authentifizierung der Kommunikationspartner
• Vertraulichkeit der Kommunikationspartner
• Authentifizierung der Quelle der gesendeten Daten
• Integrität der Daten
11
Abbildung 2.5: Diffie-Hellmann-Schlüsselaustausch
• Vertraulichkeit der Daten
• Schutz vor Replay-Attacken
Diese Punkte werden durch die verschiedenen Verbindungsmodi und die
Protokolle IKE, AH und ESP sichergestellt, die in den folgenden Kapiteln
beschrieben werden.
2.3.1
Verbindungsmodi
IPsec unterstützt zwei verschiedene Methoden zur Übetragung von Informationen, den Transport- und den Tunnel-Modus.
2.3.1.1
Transport-Modus
Im Transport-Modus werden die Daten aus den höheren Protokollschichten
durch das IPsec Header3 geschützt. Dafür wird das IPsec Header zwischen
das IP Header und das Header der höheren Protokollschicht (z.B. TCP oder
UDP) gesetzt. Falls das ESP Protokoll benutzt wird, wird an das Ende des
gesamten Paketes zusätzlich ein ESP Trailer angehängt. Die Abbildung 2.6
zeigt ein duch IPsec im Transport-Modus geschütztes IP-Paket.
3
Ein IPsec Header ist ein ESP und/oder AH Header, die in den folgenden Kapiteln
beschrieben werden
12
Abbildung 2.6: IP-Paket geschützt im Transport-Modus
Der Transport-Modus kann nur zwischen zwei Hosts aufgebaut werden,
für diesen Modus kommt also nur die Client-to-Client Architektur in Frage.
2.3.1.2
Tunnel-Modus
Im Tunnel-Modus wird im Gegensatz zum Transport-Modus das gesamte
IP-Paket in ein anderes IP-Paket eingepackt und durch das IPsec Protokoll
geschützt, indem das IPsec Header zwischen den beiden IP-Headern eingefügt
wird. Dies ist in Abbildung 2.7 dargestellt.
Abbildung 2.7: IP-Paket geschützt im Tunnel-Modus
In diesem Modus lassen sich alle in Kapitel 2.1.1 beschriebenen VPNArchitekturen realisieren. In einem Client-to-Network Szenario könnte die
Kommunikation wie in Abbildung 2.8 dargestellt aussehen, nachdem die Verbindung zwischen dem Gateway und dem Client aufgebaut wurde:
13
Abbildung 2.8: Client-To-Network Szenario mit IPsec
1. Der Host H1 schickt ein Paket, das an den Client H2 addressiert ist,
ab.
2. Das Gateway schützt das Paket mit IPsec und packt es dann in ein
neues IP Paket ein, das als Quelladdresse die im Internet sichtbare
Adresse des Gateways enthält, und schickt es ab.
3. Der Client H2 empfängt das Paket, entpackt es und erhält somit das
ursprünglich von H1 abgeschickte Paket.
4. Der Rückweg ist entsprechend: Das Originalpaket wird eingepackt und
an das Gateway geschickt.
5. Das Gateway entpackt das Paket und schickt das entpackte Paket an
den Host H1 weiter.
6. Der Host empfängt das Originalpaket von H2.
Damit sich der Client normal im LAN bewegen kann, kann dem Client
eine virtuelle IP-Addresse aus dem LAN zugewiesen werden. Die Funktionsweise ist in Kapitel 4.1 beschrieben.
14
2.3.2
Security Association (SA)
Eine Security Association definiert eine Fülle von Parametern, die für die
sichere Kommunikation zwischen zwei Hosts notwendig sind. Eine SA für
IPsec hat unter anderem folgende Parameter:
• Ziel-IP-Adresse (Adresse des Kommunikationspartners)
• IPsec-Protokoll (ESP / AH)
• Security Parameter Index (SPI)
• aktuelle Sequenznummer
• IPsec-Modus (Tunnel-Modus / Transport-Modus)
• Verschlüsselungsparameter (Algorithmus, Schlüssel, etc.)
• Authentifizierungsverfahren
• Lebensdauer der SA
Eine SA ist immer nur unidirektional gültig, beide Kommunikationpartner
benötigen also eine SA für eingehenden und eine für ausgehenden Verkehr.
Eine IPsec Kommunikation zwischen zwei Hosts kann durch mehrere SAs
geschützt werden, dem sogenannten SA-Bündel. Dies ist z.B. der Fall, wenn
das AH-Protokoll zur Autentifizierung und das ESP zur Verschlüsselung genutzt wird. Alle ausgehandelten SAs werden in einer Security Association
Database (SAD) gespeichert und sind eindeutig über das Tupel (Ziel-IPAdresse, IPsec-Protokoll, SPI) identifizierbar.
2.3.3
Security Policy (SP)
Eine Security Policy definiert, wann welche Security Association zu verwenden ist. Dies geschieht durch die Angabe der Kommunikationspartner,
der Richtung der Kommunikation, der zu verwendenden Protokolle (ESP
und/oder AH), sowie des Modus (Tunnel- oder Transportmodus). Zusätzlich
kann angegeben werden, ob überhaupt IPsec zur Sicherung der Pakete angewandt oder diese nicht durch IPsec behandelt werden sollen. Alle SPs werden
in einer Security Policy Database (SPD) gespeichert.
15
2.3.4
Internet Key Exchange (IKE)
Bevor Daten zwischen den Hosts ausgetauscht werden können, müssen IPsecSAs definiert werden. Das in [RFC2409] spezifizierte IKE Protokoll bietet
ein Verfahren an, das die zu verwendenden SAs automatisch aushandelt. Es
gliedert sich in zwei Phasen auf: In der ersten Phase wird eine sogenannte
ISAKMP-SA ausgehandelt, die eine Kommunikationsgrundlage über einen sicheren, authentifizierten Kanal für die zweiten Phase schafft. In der zweiten
Phase werden IPsec-SAs für die spätere Kommunikation mittels ESP oder
AH definiert. Danach ist das IKE abgeschlossen und die normale Kommunikation zwischen den beiden Hosts kann - auf Grundlage der ausgehandelten
IPsec-SAs - beginnen. Das IKE-Protokoll baut auf dem UDP-Protokoll auf
und verwendet dafür üblicherweise den Port 500.
2.3.4.1
Phase 1
Die erste Phase kann in zwei verschiedenen Modi ablaufen, im Main-Modus
oder im Aggressive-Modus, die sich hinsichtlich Aufwand und Sicherheit unterscheiden. Um die Authentifizierung der Kommunikationspartner sicherzustellen, werden folgende Authentifizierungsverfahren unterstützt:
Digitale Signaturen Hierfür werden Zertifikate verwendet, die bei einer
Zertifizierungsstelle registriert sind.
Preshared Keys (PSK) Es werden vorher über einen sicheren Kanal Schlüssel eines symmetrischen Kryptosystems zur Authentifizierung verwendet.
Public-Key-Verfahren Der private Schlüssel wird zum Signieren und der
öffentliche zur Verifizierung verwendet. Hierfür wird RSA eingesetzt.
Revidiertes Public-Key-Verfahren Eine schnellere, verbesserte Variante
des normalen Public-Key-Verfahren.
Es werden allerdings von den meisten Implementierungen, wie von IPsec
unter Windows 2000/XP und den KAME-Tools Setkey und Racoon unter
Linux 2.6, nur die Authentifizierung mit PSK und Zertifikaten unterstützt.
Main-Mode
Der Main-Mode ist der sicherere, aber auch der aufwendigere der beiden
Modi. Er stellt für alle Authentifizierungsalgorithmen die Vertraulichkeit der
Kommunikationspartner sicher. Die Kommunikation in der ersten Phase läuft
im Main-Modus wie folgt ab:
16
1. Der Initiator schickt dem Responder eine Nachricht, in der er einen
oder mehrere Vorschläge für ISAKMP-SAs macht. In diesen SAs sind
unter anderem die Authentifizierungsmethode, der Verschlüsselungsalgorithmus und der Hashalgorithmus enthalten.
2. Der Responder antwortet mit einer Nachricht, in der er einen der Vorschläge auswählt und diesen zurückschickt.
3. In der dritten Nachricht schickt der Initiator das zufällig erzeugte Schlüsselmaterial der Diffie-Hellmann-Berechnung (DH Erg.), einen zufälligen Nonce, der je nach Authentifizierungsalgorithmus unterschiedlich
für die Authentifizierung verwendet wird, sowie möglicherweise weitere
Daten zum Responder.
4. Der Responder schickt die analogen Informationen zurück zum Initiator. Jetzt haben beide Seiten den symmetrischen Schlüssel.
5. In der fünften Nachricht werden Authentifizierungsdaten vom Initiator
übertragen, die bereits mit dem Schlüssel, der durch Diffie-Hellmann
erstellt wurde, verschlüsselt sind, und vom Responder überprüft.
6. Der Responder antwortet im Falle der korrekten Authentifizierung wieder mit den analogen Daten zur fünften Nachricht. Sind diese vom
Initiator akzeptiert, ist die erste Phase abgeschlossen und die zweite
Phase kann beginnen.
Die Authentifizierung mit Zertifikaten, welche wir bei der Konfiguration einrichten werden, erfolgt wie in Abbildung 2.9 verdeutlicht. In den ersten beiden Nachrichten wird ausgehandelt, dass die Zertifikatsmethode zur
Authentifizierung benutzt werden soll. In der dritten und vierten Nachricht
werden die Zertifikate, falls noch nicht vorher ausgetauscht, angefordert. Als
letztes werden in der fünften und sechsten Nachricht die geforderten Zertifikate und die signierten Noncen ausgetauscht, was hier bereits verschlüsselt
geschieht (schraffierte Felder). Können die Signaturen und Zertifikate von beiden Kommunikationspartnern verifiziert werden, sind diese authentifiziert.
Aggressive-Mode Läuft die erste Phase im schnelleren Aggressive-Mode
ab, wird im Falle einer Authentifizierung mit Preshared Keys oder digitalen Signaturen die Identität der Kommunikationspartner nicht vertraulich
behandelt. Dies stellt eine Sicherheitslücke dar, weshalb dieser Modus nicht
benutzt werden sollte und auch nicht weiter erläutert wird.
17
Abbildung 2.9: IKE Main-Modus mit Zertifikaten
2.3.4.2
Phase 2
Die zweite Phase läuft im sogenannten Quick-Mode ab, in dem die für den
späteren Nutzdatenverkehr verwendeten IPsec-SAs ausgehandelt werden. Sie
baut auf der ersten Phase auf, indem die Nachrichten, die in dieser Phase
ausgetauscht werden, mit der bereits ausgehandelten ISAKMP-SA geschützt
werden; d.h. sie stellt die Datenintegrität, Authentifizierung und Vertraulichkeit sicher. In dieser Phase können mehrere IPsec-SAs ausgehandelt werden,
außerdem wird immer wenn die Gültigkeit der IPsec-SAs abgelaufen ist, der
Quick-Modus erneut ausgeführt, um neue IPsec-SAs auszuhandeln.
2.3.5
Authentication Header (AH)
Das Authentication Header Protokoll (AH) ist in [RFC2402] spezifiziert. Es
stellt die Datenintegrität, die Authentifizierung der Quelle und den Schutz
vor Replay-Angriffen sicher. Das AH-Header wird zwischen dem IP-Paket
und den Daten eingefügt und ist wie in Abbildung 2.10 dargestellt aufgebaut:
Die Felder werden im folgenden beschrieben:
18
Abbildung 2.10: Aufbau des AH-Headers
Next Header Dieses Feld gibt das höherschichtige Protokoll an (IPv4 =
4, TCP = 6, UDP = 17, ESP = 50). Weitere Werte sind in [IANA]
definiert.
Payload Length Dieses Feld gibt die Größe des AH-Headers in 32-Bit Worten an, nachdem zwei 32-Bit Worte abgezogen wurden4 .
Reserved Dieses Feld ist für zukünftige Zwecke reserviert und muss mit
Nullen aufgefüllt werden.
Security Parameter Index (SPI) Dieses Feld identifiziert zusammen mit
der Ziel-IP-Adresse und dem IPsec-Protokoll die ausgehandelte Security Association (SA) (siehe Kapitel 2.3.4), für die dieses Paket gültig
ist.
Sequence Number Eine monoton mit jedem gesendeten Paket steigende
Nummer, die vor Replay-Attacken schützen soll. Die Zähler von Sen4
Das AH-Header gehört zur Gruppe der IPv6 Extension Header, für die bestimmte
Regeln bei der Berechnung der Länge des Headers gelten.
19
der und Empfänger werden nach dem Aushandeln der SA mit Null
initialisiert. Wenn 232 Pakete gesendet wurden, muss eine neue SA ausgehandelt werden.
Authentication Data Dieses Feld stellt die Datenintegrität und die Authentifizität des Empfängers sicher. Es enthält eine Signatur, die mit
dem in der SA vereinbarten Signierungsverfahren erstellt wurde. Bei
der Berechnung der Signatur wird das gesamte Paket einbezogen, mit
Ausnahme einiger variabler Felder des IP-Headers, die sich durch das
Routing verändern.
2.3.6
Encapsulated Security Payload (ESP)
Das Encapsulated Security Payload Protokoll (ESP) ist in [RFC2406] spezifiziert. Es stellt zusätzlich zum AH-Protokoll durch Verschlüsselung die Vertraulichkeit der Daten sicher, und entspricht ansonsten dem AH-Protokoll.
Ein durch ESP geschütztes Paket hat den in Abbildung 2.11 gezeigten Aufbau:
Die Felder werden im folgenden beschrieben:
Security Parameter Index (SPI) Dieses entspricht dem Feld im
AH-Header.
Sequence Number Dieses entspricht dem Feld im AH-Header.
Initialization Vector (IV) Der Initialisierungsvektor ist für einige symmetrische Verschlüsselungsverfahren notwendig und wird hiermit übermittelt. Seine Länge hängt von der Art des in der SA vereinbarten
Verschlüsselungsverfahrens ab.
Padding Falls ein Blockverschlüsselungsverfahren verwendet wird, so müssen
die Daten auf ein Vielfaches der Blocklänge gebracht werden, indem der
letzte, unvollständige Block mit Fülldaten aufgefüllt wird.
Padding Length Hier wird die Länge der aufgefüllten Daten gespeichert,
damit diese wieder entfernt werden können.
Next Header Dieses entspricht dem Feld im AH-Header.
Authentication Data Dieses entspricht dem Feld im AH-Header. Bei der
Berechnung der Signatur wird allerdings das Header des IP-Pakets nicht
einbezogen.
20
Abbildung 2.11: Aufbau des ESP-Header und -Trailer
2.3.7
Vor- und Nachteile von IPsec
Vorteile
• standardisiert
• flexible Konfiguration durch Auswahl zwischen z.B. AH oder ESP und
Tunnel- oder Transportmodus
• keine Festlegung auf bestimmte Verschlüsselungsverfahren
• Transparenz gegenüber Applikationen
Nachteile
• sehr komplex, dadurch Gefahr von fehleranfälligen Implementierungen
• noch nicht weit verbreitet
21
Kapitel 3
Einrichtung und Konfiguration
3.1
Netzwerk-Aufbau
Wie bereits erwähnt, simulieren wir den Fall, dass sich Außendienstmitarbeiter in das LAN ihrer Firma aus dem öffentlichen Netz einwählen, was
mit einer Client-to-Network-Architektur umgesetzt wird. Der Netzwerkaufbau wird in Abbildung 3.1 gezeigt.
Abbildung 3.1: Netzwerk Aufbau
Das LAN 192.168.100.0/255.255.255.0 besteht aus einem Linux-Host und
einem Linux-VPN-Gateway, welches die Schnittstelle in das öffentliche Netz
194.25.25.0/255.255.255.0 bildet. Im diesem Netz befindet sich ein Windows
RoadWarrior, sowie ein Linux RoadWarrior.
22
Der Linux-Host im LAN und das Linux-Gateway laufen als Gastbetriebssysteme über VMWare 4.5.2 auf einem Windows XP SP1 Rechner. Der Linux
RoadWarrior läuft ebenfalls als Gastbetriebssystem unter VMWare auf dem
Windows RoadWarrior mit Windows XP SP1. Alle drei Linux-Hosts laufen
unter SUSE Linux Professional 9.1 mit dem Kernel 2.6.4.
Der Linux-Host muss als Standardgateway das Linux-Gateway eingetragen haben, welches selber IP-Forwarding aktiviert haben muss. Für unseren
Aufbau haben der Windows RoadWarrior und der Linux RoadWarrior ebenfalls das Linux-Gateway als Standardgateway eingetragen. In einem realen
Aufbau würde man z.B. das vom Provider zugewiesene Gateway nehmen,
welches Pakete zum Linux-Gateway über das öffentliche Netz routet.
3.2
Installation benötigter Software
Für den Aufbau der Public-Key-Infrastruktur mit X.509-Zertifikaten haben
wir das Tool TinyCA für Linux gewählt, welches eine einfache Schnittstelle zu
OpenSSL bietet. Dieses ist unter SUSE Linux einfach mit YAST einzubinden.
Unter Windows 2000/XP ist die Konfiguration von IPSec sehr kompliziert
und umständlich, allerdings gibt es das Tool ipsec.exe von Markus Müller,
das die Konfiguration erleichtert und unter http://vpn.ebootis.de heruntergeladen werden kann. Dieses setzt wiederum auf den ’Support Tools’ von
Windows 2000/XP auf, welche auf der WindowsXP-Installations-CD unter
’TOOLS/Support Tools’ zu finden sind. Sind die Support Tools installiert,
muss das Programm von Markus Müller in das Verzeichnis der Installation
kopiert werden.
3.3
Aufbau der Public-Key-Infrastruktur
Um eine Public-Key-Infrastruktur aufzubauen, muss zunächst eine Certification Authority vorhanden sein. Hierfür kann eine bereits vorhandene, vertrauenswürdige Zertifizierungsstelle, z.B. VeriSign, benutzt werden. Wir erstellen
für diese Zwecke eine eigene CA, von der die Zertifikate für das Gateway und
die RoadWarrior signiert werden.
Zur Erstellung der CA und der Zertifikate benutzen wir TinyCA. Die
Bedienung des Programmes ist intuitiv, deshalb beschreiben wir nur die Reihenfolge der Erstellung der Zertifikate:
Zuerst wird eine CA erstellt, wobei beachtet werden sollte, dass die verwendete Schlüssellänge mindestens 2048 Bit sein sollte, um optimale Sicherheit zu gewährleisten. Ist die CA erfolgreich erstellt, sieht das Ergebnis ähn-
23
lich wie in Abbildung 3.2 aus.
Abbildung 3.2: Certification Authority in TinyCA
Danach erstellen wir das Zertifikat des Gateways. Hierfür wird zuerst eine
Certification Signing Request gestellt (in TinyCA unter ’Request’) und dieser
von der CA signiert. Ist dies geschehen, sollte das Zertifikat unter ’Certificates’ und der zugehörige private Schlüssel unter ’Keys’ auftauchen. Für den
Windows RoadWarrior und den Linux RoadWarrior ist ebenso vorzugehen.
Das Ergebnis sollte dann wie in Abbildung 3.3 gezeigt aussehen.
Damit die erstellten Zertifikate und Schlüssel beim Aufbau des VPNs
zur Authorisierung genutzt werden können, müssen diese noch in bestimmte
Formate exportiert werden. Für das Linux-Gateway und den Linux RoadWarrior müssen das Zertifikat der CA, die Certificate Revocaton List der
CA, das Zertifikat des Gateways bzw. des RoadWarriors und deren private
Schlüssel jeweils im PEM-Format exportiert werden, wobei darauf zu achten
ist, dass der Schlüssel unverschlüsselt abgespeichert wird. Für den Windows
RoadWarrior muss das Zertifikat inklusive Schlüssel im PKCS#12-Format
exportiert werden. In diesem ist zusätzlich schon das Zertifikat der CA enthalten.
Nun kann das exportiere Zertifikat auf dem Windows RoadWarrior importiert werden. Unter Windows 2000/XP werden alle Zertifikate in einem
zentralen Zertifikatsspeicher gespeichert und vom Betriebssystem verwaltet.
24
Abbildung 3.3: Zertifikate in TinyCA
Allerdings funktioniert das Importieren von Zertifikaten nicht einwandfrei,
weshalb hierfür das Tool ipsec.msc, das ebenfalls von Markus Müller bereitgestellt wird, verwendet wird. Mit diesem Tool muss das Zertifikat der CA in
den Ordner ’Vertrauenswürdige Stammzertifizierungsstellen’ und das Zertifikat des RoadWarriors in den Ordner ’Eigene Zertifikate’ importiert werden.
Die Abbildung 3.4 zeigt den Ordner ’Eigene Zertifikate’ nach dem Importieren.
Auf dem Linux-Gateway und dem Linux RoadWarrior legen wir jeweils
die vier exportierten Dateien (das CA-Zertifikat, die CRL, das eigene Zertifikat und der private Schlüssel) in dem Verzeichnis ’/etc/ipsec/certs/’ ab.
Danach müssen auf beiden Linux-Rechnern OpenSSL-konforme Links zu dem
Zertifikat der CA und der CRL erstellt werden, damit sie beim Aufbau des
VPN gefunden werden können. Dies geschieht mit den Kommandos
ln -s VPNCA-cacert.pem ‘openssl x509 -noout -hash -in
VPNCA-cacert.pem‘.0
und
ln -s crl.pem ‘openssl x509 -noout -hash -in
VPNCA-cacert.pem‘.r0
25
Abbildung 3.4: Zertifikatverwaltung unter Windows
Hierbei werden Links erzeugt, deren Namen den Hashwert des Zertifikats der
CA enthalten und auf das Zertifikat und die CRL verweisen.
3.4
Einrichtung Linux Gateway
Die Konfiguration von IPsec unter Linux lässt sich mit verschiedenen Tools
durchführen, wie z.B. FreeS/WAN, Isakmpd oder den KAME-Tools setkey
und racoon, welche wir hier verwenden. Hierfür ist das iputils-Paket über
YAST zu installieren. Im folgenden wird erläutert, wie setkey und racoon zu
konfigurieren sind.
3.4.1
Konfiguration von Setkey
Mit dem Kommando setkey können die Einträge der Security Association
Database und der Security Policy Database von IPsec editiert werden. Dies ist
nur notwendig, falls statische, manuell konfigurierte Verbindungen aufgebaut
werden sollen. Da dies in unserem Fall automatisch durch racoon, den IKEDaemon, durchgeführt wird, müssen nur für racoon eventuelle, ältere SPDund SAD-Einträge gelöscht werden, was durch folgende Konfigurationsdatei
geschieht:
# lösche SAD und SPD
26
flush;
spdflush;
3.4.2
Konfiguration von Racoon
Racoon ist der IKE-Daemon, der für die IKE-Phase zuständig ist. Er wird
aufgerufen, wenn ein Paket entsprechend einer Security Policy authentifiziert
oder verschlüsselt werden muss, aber keine entsprechende Security Association vorhanden ist. Damit racoon dann die SAs aushandeln kann, müssen die
Parameter für Phase 1 und Phase 2 mit der folgenden Konfigurationsdatei
gesetzt werden.
(1)
path certificate "/etc/ipsec/certs";
(2)
(3)
(4)
(5)
(6)
remote anonymous {
exchange_mode main;
generate_policy on;
passive on;
certificate_type x509 "LinuxGateway-cert.pem"
"LinuxGateway-key.pem";
my_identifier asn1dn;
(7)
(8)
(9)
(10)
(11)
(12)
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group modp1024;
}
}
(13) sainfo anonymous {
(14)
encryption_algorithm 3des;
(15)
authentication_algorithm hmac_md5;
(16)
compression_algorithm deflate;
}
Beschreibung der Zeilen:
(1) Das Verzeichnis der Zertifikate.
(2) Mit dem remote-Befehl wird der Kommunikationspartner (bzw. seine
IP-Adresse) definiert und wie mit ihm in der ersten Phase des IKE
27
kommuniziert werden soll. Der Eintrag ’anonymous’ gilt für jeden Kommunikationspartner, für den kein weiterer remote-Eintrag definiert ist.
(3) Der Modus der ersten Phase.
(4) Es wird angegeben, dass sich die beim Aufbau der Verbindung zu erzeugenden SPD-Einträge nach dem Client richten.
(5) Hier wird festgelegt, dass das Gateway nicht selber eine Verbindung
aufbaut, sondern auf einen Aufbau von außen wartet.
(6) Hier werden das Zertifikat und der private Schlüssel des Gateways angegeben.
(7) Dieser Parameter gibt die Identität an, die an den Kommunikationspartner geschickt werden soll. asn1dn besagt, dass hierfür das Subject-Feld
des Zertifikats benutzt werden soll.
(8) Hier wird ein Vorschlag für eine ISAKMP-SA der ersten IKE-Phase angegeben.
(9) Der zu verwendenden Verschlüsselungsalgorithmus.
(10) Der zu verwendenden Hashalgorithmus.
(11) Die zu verwendende Authentifizerungsmethode.
(12) Die Primzahllänge für den Diffie-Hellmann-Algorithmus.
(13) Hier wird ein IPsec-SA-Vorschlag für die Phase 2 angegeben.
(14) Der zu verwendende Verschlüsselungsalgorithmus.
(15) Du verwendende Authentifizierungsalgorithmus.
(16) Der zu verwendende Kompressionsalgorithmus.
3.4.3
Initialisierung von IPsec
Wir legen die beiden Konfigurationsdateien im Verzeichnis ’/etc/ipsec/’ ab
und erstellen folgendes Script, das beide automatisch einliest und ausführt.
#! /bin/sh
RACOON_OPTS="-l /var/log/racoon.log -v"
28
RACOON_CONF="/etc/ipsec/racoon.conf"
SETKEY_CONF="/etc/ipsec/setkey.conf"
start() {
echo $"Starting ipsec..."
echo $"Starting setkey... "
setkey -f $SETKEY_CONF
echo $"Starting racoon daemon... "
racoon $RACOON_OPTS -f $RACOON_CONF
}
stop() {
echo $"Stopping racoon daemon..."
killall racoon
echo $"Flushing SAD ..."
setkey -F
echo $"Flushing SPD ..."
setkey -F -P
}
restart() {
stop
start
}
showlog() {
less /var/log/racoon.log
}
rmlog() {
rm /var/log/racoon.log
echo racoon log file deleted
}
case "$1" in
29
start)
start
;;
stop)
stop
;;
restart)
restart
;;
showlog)
showlog
;;
rmlog)
rmlog
;;
*)
echo $"Usage: $0 {start|stop|restart|showlog|rmlog}"
exit 1
esac
In der start-Funktion wird zuerst setkey mit der Konfigurationsdatei aufgerufen, danach wird der racoon-Daemon gestartet. In der stop-Funktion
wird der racoon-Prozess zerstört und die SPD- und SAD-Einträge gelöscht.
Sobald eine Verbindung von einem RoadWarrior aufgebaut wird, werden
automatisch die entsprechenden SPD- und SAD-Einträge eingetragen und
ein Tunnel erstellt. Die Einträge der SPD und SAD können mit dem Befehl
’setkey -D -P’ bzw. ’setkey -D’ ausgegeben werden. In Abbildung 3.5 sind
die SAD-Einträge nach einem erfolgreichen Verbindungsaufbau dargestellt,
in Abbildung 3.6 ein Ausschnitt der SPD-Einträge.
3.5
Einrichtung Linux RoadWarrior
Die Konfiguration des Linux RoadWarrior unterscheidet sich kaum vom LinuxGateway. Da der RoadWarrior aktiv die IPsec-Verbindung aufbaut und damit
die Security Policies nun nicht mehr von racoon erstellt werden können, muss
die Konfiguration von setkey.conf folgendermaßen aussehen.
# lösche SAD und SPD
flush;
30
Abbildung 3.5: SAD-Einträge in setkey
Abbildung 3.6: SPD-Einträge in setkey
spdflush;
spdadd 194.25.25.4 192.168.100.0/24 any -P out ipsec
esp/tunnel/194.25.25.4-194.25.25.1/require;
spdadd 192.168.100.0/24 194.25.25.4 any -P in ipsec
esp/tunnel/194.25.25.1-194.25.25.4/require;
31
Die beiden spdadd-Befehle fügen der SPD zwei Einträge hinzu. Der erste
Eintrag besagt, dass in das Netz 192.168.100.0/24 ausgehende Pakete durch
IPsec behandelt werden sollen und durch einen Tunnel zwischen dem Linux
RoadWarrior (194.25.25.4) und dem Linux-Gateway (194.25.25.1) geschützt
werden sollen. Der zweite Eintrag besagt, dass für die Rückrichtung die gleiche Behandlung erfolgen soll.
path certificate "/etc/ipsec/certs";
remote 194.25.25.1 {
exchange_mode main;
generate_policy off;
passive off;
certificate_type x509 "LinuxRoadWarrior-cert.pem"
"LinuxRoadWarrior-key.pem";
my_identifier asn1dn;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method rsasig;
dh_group modp1024;
}
}
sainfo address 194.25.25.4 any address 192.168.100.0/24 any {
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
Die racoon-Konfigurationsdatei ist ebenfalls sehr ähnlich. Da die IP-Adresse des Gateways hier bekannt ist, wird diese beim remote-Eintrag angegeben. Zudem sind generate policy und passive deaktiviert, da die Security
Policies von setkey schon eingetragen wurden und der RoadWarrior die Verbindung aktiv aufbaut. Die sainfo gibt an, dass in der zweiten IKE-Phase
für Verbindungen von 194.25.25.4 in das Netz 192.168.100.0/24 als IPsecSA-Vorschlag die aufgelisteten Algorithmen verwendet werden sollen.
Zum Initialisieren von IPsec kann das gleiche Script wie für das Linux
Gateway genutzt werden. Der Aufbau des Tunnels kann nun z.B. durch einen
Ping oder andere Pakete gestartet werden, denn erst wenn ein Paket an den
32
Host im Zielnetz gesendet wird, wird die IKE-Phase gestartet und die SAs
ausgehandelt.
3.6
Einrichtung Windows Roadworrior
Mit der geleisteten Vorarbeit ist die Einrichtung von IPsec unter Windows
nun nicht mehr schwierig. Es muss lediglich die schon vorhandene Konfigurationsdatei ipsec.conf von Markus Müller angepasst werden:
# Name der Verbindung
conn FHDWVPN
# RoadWarrior IP-Adresse
left=%any
# VPN-Gateway IP-Adresse
right=194.25.25.1
# Zielnetz
rightsubnet=192.168.100.0/255.255.255.0
# CA
rightca="C=DE, L=Hannover, O=FHDW, CN=VPNCA"
# RoadWarrior startet die Verbindungsaufnahme
auto=start
Beschreibung der Konfiguration:
conn Gibt den Namen der Verbindung an.
left Hier wird die IP-Adresse des RoadWarriors angegeben. Da diese dynamisch ist, kann hier ’any’ angegeben werden.
right Dies ist die IP-Adresse des Gateways, zu dem ein Tunnel aufgebaut
werden soll.
rightsubnet Das Netz, mit dem kommuniziert werden soll.
rightca Angaben zur Zertifizierungsstelle, von der das Zertifikat des Gateways signiert sein muss. Dabei ist C=Country, L=Location, O=Organisation und CN=Common Name. Diese Werte für die CA werden zum
Beispiel in TinyCA angezeigt und können von dort übernommen werden.
33
auto Gibt an, dass der RoadWarrior von sich aus die Verbindung startet.
Achtung: Am Ende der einzelnen Zeilen dürfen keine Leerzeichen oder Tabs
stehen, sonst kann die Datei nicht korrekt eingelesen werden!!!
Nachdem die Konfigurationsdatei erstellt wurde, kann eine IP-Sicherheitsrichtlinie namens ’FreeSwan’ mit dem Befehl ’ipsec.exe’ erstellt und aktiviert
werden.
Die Konfiguration der Parameter der IKE-Phase kann mit dem Tool ipsec.msc durchgeführt werden. Dafür muss die erwähnte IP-Sicherheitsrichtlinie
bearbeitet werden. Da diese aber standardmäßig zu den Einstellungen unseres Linux-Gateways passen, ist dies nicht unbedingt notwendig.
Um das VPN aufzubauen muss lediglich ein Paket an einen Host im Zielnetz gesendet werden, z.B. durch einen Ping. Erst dann wird die IKE-Phase
gestartet und die SAs ausgehandelt. Die Abbildung 3.7 zeigt die Ausgabe der
Konsole beim Verbindungsaufbau.
Abbildung 3.7: Verbindungsaufbau unter Windows
Mit dem Kommando ’ipsec.exe -off’ wird die Sicherheitsrichtlinie wieder
deaktiviert.
34
Kapitel 4
Ausblick
In diesem Kapitel werden erweiterte Konfigurationsmöglichkeiten vorgestellt
sowie Themen angesprochen, mit denen man sich weiter beschäftigen könnte.
4.1
DHCP-over-IPsec
Wenn ein Rechner sich über einen Tunnel in ein LAN einwählt, ist es oft
von Vorteil, wenn dieser eine IP-Adresse aus dem lokalen Netz bekommt
und sich scheinbar ’zuhause’ befindet. Dafür muss das Gateway als DHCPServer konfiguriert sein. Ein RoadWarrior erstellt nun zuerst den Tunnel zum
VPN-Gateway und erhält über DHCP dann eine lokale, virtuelle IP-Adresse.
Diese wird nun als die Quelladresse für die weitere Kommunikation mit dem
Netzwerk verwendet, die IP-Adresse des Tunnelendpunktes bleibt bestehen.
Die Kommunikation mit der lokalen Adresse ist in Abbildung 4.1 gezeigt.
Vergleiche auch Abbildung 2.8 ohne lokale Adresse.
Das Protkoll für DHCP-over-IPsec wird in [RFC3456] beschrieben.
4.2
Firewall Traversal
Befinded sich das VPN-Gateway hinter einer Firewall (was sinnvoll ist, falls
die Überlebensdauer mehr als zwei Nanosekunden betragen soll), so muss
beachtet werden, dass die Firewall je nach verwendeten Protokollen ESPPakete (Protokollnummer 50) und/oder AH-Pakete (Protokollnummer 51) in
beide Richtungen passieren lässt. Zusätzlich muss bei der Verwendung von
IKE zum automatischen Aushandeln der Verbindungsparameter der IKEPort (standardmäßig der UDP-Port 500) in beide Richtungen freigegeben
werden.
35
Abbildung 4.1: Client-To-Network Szenario mit lokaler Adresse
4.3
Network Address Translation (NAT) Traversal
Wird ein VPN über NAT-Geräte aufgebaut, so entstehen durch die IPsec
Protokolle ESP und AH verschiedene Probleme: Passiert ein IP-Paket ein
NAT-Gerät, so werden die IP-Adresse(n) und die Portnummer(n) verändert.
Falls nun das IP-Paket durch ESP geschützt ist, so ist zwar das Ändern der
IP-Adressen möglich, das Ändern der Portnummern dagegen nicht, da ein
mögliches TCP- oder UDP-Header authentifiziert und zudem möglicherweise
verschlüsselt ist (siehe Kapitel 2.3.6). Ist ein IP-Paket durch AH geschützt,
so würde eine Änderung der IP-Adressen oder Portnummern die Integrität
verletzen, da wie in Kapitel 2.3.5 beschrieben, eine Signatur über das gesamte
Paket erstellt wird, welche bei Veränderung des Paketes ungültig würde.
Eine Lösungsmöglichkeit für ESP besteht darin, einen UDP-Tunnel aufzubauen, wie in Abbildung 4.2 gezeigt. Dabei wird vom VPN-Sender zwischen
dem IP- und dem ESP-Header ein UDP-Header eingefügt, dessen Portnummern nun beliebig vom NAT-Gerät verändert werden können. Der VPNEmpfänger muss dieses ’NAT Traversal Protocol’ ebenfalls unterstützen und
das UDP-Header wieder entfernen. Das NAT Traversal von IPsec Paketen
wird in [RFC3715] behandelt.
36
Abbildung 4.2: IPsec-Paket im UDP-Tunnel
4.4
Performanz-Untersuchungen
Unsere Projektarbeit behandelt nicht die Untersuchung der Performanz beim
Einsatz von IPsec. Es wäre allerdings interessant zu erfahren, inwieweit sich
der Durchsatz von Daten verringert, wenn AH und/oder ESP im Transport
oder Tunnelmodus verwendet wird und wie hoch der durch IPsec verursachte
Overhead ist.
37
Anhang A
Literaturverzeichnis
VPNLinux VPN mit Linux, Ralf Spenneberg, Addison Wesley Verlag, 2004
(ISBN 3-8273-2114-X)
RFC2401 Security Architecture for the Internet Protocol (IPsec)
RFC2409 The Internet Key Exchange (IKE)
RFC2402 IP Authentification Header (AH)
RFC2408 Internet Security Association and Key Management Protocol
(ISAKMP)
RFC2406 IP Encapsulating Security Payload (ESP)
RFC3715 IPsec Network Address Translation
RFC3456 DHCP Configuration of IPsec Tunnel Mode
38
Anhang B
Ausgewählte Links
ISO/OSI Folien zu ’ISO/OSI Referenzmodell’, Prof. Hellberg,
http://ux-02.ha.bib.de/ hellberg/Netzwerke/ISO-OSI-Referenzmodell.ppt
Sicherheit Folien zu ’Sicherheitsaspekte in heterogenen Netzen’, Prof. Hellberg, http://ux-02.ha.bib.de/ hellberg/Netzwerke/Folien-070800-LAST69.pps
Kryptographie Folien zu ’Kryptographie’, Prof. Hellberg,
http://ux-02.ha.bib.de/ hellberg/BetrieblicheInformationssysteme/EFS23.ppt
ipsec tool Markus Müller IPsec Tool unter http://vpn.ebootis.de/
wikipedia Kryptologie Projekt
http://de.wikipedia.org/wiki/Wikipedia:WikiProjekt Kryptologie
VPN mit Linux online Ausgewählte Kapitel zu VPN mit IPsec aus [VPNLinux] in http://www.spenneberg.org/VPN-Book/
IANA Internet Assigned Numbers Authority,
http://www.iana.org/assignments/protocol-numbers
rcf-editor Alle Request For Comments (RFCs) unter http://www.rfc-editor.org
39
Anhang C
Glossar
asymmetrisches Kryptosystem Ein Kryptosystem, bei dem zur Verschlüsselung ein anderer Schlüssel benutzt wird als zur Entschlüsselung. Dabei wird ein Schlüssel (geheimer Schlüssel) geheim gehalten, der andere (öffentlicher Schlüssel) kann an andere weitergegeben werden. Bei Kenntnis des
einen Schlüssels kann der andere nur mit exponentiellem oder noch höherem
Aufwand berechnet werden. Dazu gehört z.B. das RSA-Kryptosystem.
Authentication Header (AH) Ein Protokoll von IPsec, das die Datenintegrität, die Authentifizierung der Quelle und den Schutz vor ReplayAngriffen sicher stellt, aber nicht die Vertraulichkeit. Protokollnummer: 51.
Authentifizierung Authentifizierung ist die Überprüfung und Erkennung
der Identität einer Person oder eines Programms.
Certificate Revocation List (CRL) Eine CRL ist eine Liste, die Informationen zu der Gültigkeit von Zertifikaten enthält, um feststellen zu können,
ob ein Zertifikat zum aktuellen Zeitpunkt gültig ist oder gesperrt wurde.
Certificate Signing Request (CSR) Ein Certificate Signing Request
ist ein unsigniertes Zertifikat, das von einer Certification Authority signiert
werden soll.
Certification Authority (CA) Eine Certification Authority stellt eine
vertrauliche, zentrale Signierungsinstanz dar, die digitale Zertifikate ausstellt,
indem sie einen Certificate Signing Request mit ihrem privaten Schlüssel
signiert.
40
Client Ein Client ist ein Rechner oder eine Anwendung, das Dienste eines
Servers in Anspruch nimmt.
Diffie-Hellmann-Schlüsselaustausch Der Diffie-Hellmann-Schlüsselaustausch beschreibt ein Verfahren, symmetrische Schlüssel sicher über unsichere
Kanäle auszuhandeln oder auszutauschen.
Encapsulated Security Payload (ESP) Ein Protokoll von IPsec, das
die Datenintegrität, die Authentifizierung der Quelle, die Vertraulichkeit der
Daten und den Schutz vor Replay-Angriffen sicher stellt. Protokollnummer:
50.
Entschlüsselung Ein Verfahren, das verschlüsselte Daten mit Hilfe eines
Schlüssels in die ursprünglichen Daten zurückwandelt.
Gateway Ein Gateway verbindet zwei Netzwerke mit unterschiedlichen
Protokollen miteinander. Dafür nimmt es eine Protokollumsetzung zwischen
den beiden Netzwerken vor.
geheimer Schlüssel Der Schlüssel eines Kryptosystems, der geheim gehalten wird.
Hash-Funktion Eine nicht umkehrbare Funktion, die Nachrichten variabler Länge auf einen Wert (Hash-Wert) fester Bitbreite abbildet. Dabei ist
es praktisch unmöglich zwei unterschiedliche Nachrichten zu finden, die den
gleichen Hash-Wert ergeben. Beispiele für solche Hash-Funktionen sind MD5
(Message Digest Algorithm 5) und SHA (Secure Hash Algorithm).
Host Ein Host ist ein Rechner in einem Netzwerk.
Initialization Vector (IV) Der Initialisierungsvektor ist für einige symmetrische Verschlüsselungsverfahren notwendig. Seine Länge ist abhängig von
der Art des Verschlüsselungsverfahrens.
Internet Key Exchange (IKE) Ein Verfahren von IPsec, mit dem die
Kommunikationspartner authentifiziert werden und automatisch IPsec-SAs
ausgehandelt werden.
41
Internet Protocol (IP) IP ist ein Netzwerkprotokoll, das in der Netzwerkschicht des OSI-Netzwerkschichtenmodells angesiedelt ist.
Internet Protocol 4 (IPv4) IPv4 ist ein IP, das 32 Bit lange Adressen
verwendet und gegenwärtig der Standard im Internet ist.
Internet Protocol 6 (IPv6) IPv6 ist der Nachfolger des IPv4 und benutzt
im Gegensatz zu diesem 128 Bit lange Adressen.
Internet Security Association and Key Management Protocol
(ISAKMP) ISAKMP definiert eine Verfahren, um SAs auzuhandeln und
zu verwalten.
IPsec Tunnelmodus Im Tunnel-Modus wird das gesamte IP-Paket in ein
anderes IP Paket eingepackt und durch das IPsec Protokoll geschützt, indem das IPsec Header (AH und/oder ESP) zwischen den beiden IP-Headern
eingefügt wird.
IPsec Transportmodus Im Transport-Modus werden die Daten aus den
höheren Protokollschichten eines Paketes durch das IPsec-Header (AH und/oder ESP) geschützt. Dafür wird das IPsec Header zwischen das IP Header
und das Header der höheren Protokollschicht (z.B. TCP oder UDP) gesetzt.
Klartext Eine unverschlüsselte Nachricht.
Kryptosystem Ein System, das Verfahren zur Ver- und Entschlüsselung
von Informationen beschreibt, mit der Absicht, diese gegenüber Dritten unleserlich zu machen.
Layer 2 Tunneling Protocol (L2TP) Ein Protokoll zum Aufbau von
VPNs, das auf der Sicherungsschicht des OSI-Modells aufsetzt.
Local Area Network (LAN) Ein LAN ist ein räumlich begrenztes Computernetzwerk.
NAT Traversal Protocol Das NAT Traversal Protocol beschreibt, wie
ein UDP-Tunnel benutzt wird, um ESP-Pakete NAT-fähig zu machen.
42
öffentlicher Schlüssel Der Schlüssel eines asymmetrischen Kryptosystem,
der veröffentlicht wird.
OpenSSL OpenSSL ist eine Open-Source-Implementierung von SSL.
Padding Das Auffüllen eines unvollständigen Blocks mit beliebigen Daten,
so dass eine gewisse Blockgröße erreicht wird.
Payload Data Nutzdaten
privater Schlüssel siehe geheimer Schlüssel
Public-Key-Infrastruktur (PKI) Mit Public-Key-Infrastruktur bezeichnet man ein System, welches ermöglicht, digitale Zertifikate auszustellen (siehe Certification Authority), zu verteilen und zu prüfen (siehe Signierung und
Verifizierung).
Public-Key-Verschlüsselung siehe asymmetrisches Kryptosystem
Replay-Attacke Eine Replay-Attacke ist das erneute Versenden einer vorher abgehörten Nachrichtensequenz. Hierdurch ist es z.B. möglich Zugriff auf
einen Server zu erhalten, dem vorher schon einmal die aufgezeichnete Nachricht mit eventuellen, verschlüsselten Zugangsinformationen gesendet wurde.
RSA-Kryptosystem Ein asymmetrisches Kryptosystem, benannt nach
Ronald L. Rivest, Adi Shamir und Leonard Adleman, das auf dem Faktorisierungsproblem großer Zahlen aufbaut.
Schlüssel Eine zusätzliche Information, die man benötigt um eine Nachricht zu ver- bzw. zu entschlüsseln.
Schlüssellänge Die Anzahl der Bitstellen einer Zahl, aus der der Schlüssel
besteht. Im Falle des RSA-Verfahrens ist dies die Anzahl der Bitstellen des
Moduls n.
Security Association (SA) Eine SA ist eine unidirektionale Vereinbarung zwischen zwei Kommunikationspartnern über zu verwendende Algorithmen und Schlüssel.
43
Security Association Database (SAD) Die Datenbank, in der Security
Associations gespeichert werden.
Security Architecture for IP (IPsec) IPsec stellt eine Sicherheitsarchitektur für die Kommunikation über IP-Netzwerke zur Verfügung. Folgende
Sicherheitsaspekte werden durch IPsec gewährleistet:
• Authentifizierung der Kommunikationspartner
• Authentifizierung der Quelle der gesendeten Daten
• Datenintegrität
• Vertraulichkeit der Daten
• Schutz vor Replay-Attacken
Security Parameter Index (SPI) Eine SPI identifiziert zusammen mit
der Ziel-IP-Adresse und dem IPsec-Protokoll die ausgehandelte Security Association (SA).
Security Policy (SP) Eine Security Policy definiert, wann welche Security
Association zu verwenden ist.
Security Policy Database (SPD) Die Datenbank, in der Security Policies gespeichert werden.
Server Ein Server ist ein Rechner oder eine Anwendung, die Dienste zur
Verfügung stellen, die von Clients in Anspruch genommen werden können.
Signierung Um Daten zu signieren, wird der Hash-Wert der Daten mit einem geheimen Schlüssel verschlüsselt. Im Falle einer Public-Key-Infrastruktur
ist dies der geheime Schlüssel des Senders. Der Empfänger der verschlüsselten
Daten kann diese verifizieren.
Secure Socket Layer (SSL) Ein Protokoll, das dafür genutzt wird, eine
authentifizierte und verschlüsselte Verbindung aufzubauen.
symmetrisches Kryptosystem Ein Kryptosystem, das zur Ver- und Entschlüsselung den gleichen Schlüssel verwendet, bzw. Schlüssel verwendet, die
sich leicht ineindander überführen lassen.
44
Transmission Control Protocol (TCP) Das TCP ist ein zuverlässiges, verbindungsorientiertes Transportprotokoll, das in Schicht 4 des OSINetzwerkschichtenmodells angesiedelt ist.
Tunnel In einem Tunnel werden die Daten eines Netzwerkprotokolls eingebettet in einem anderen Netzwerkprotokoll übetragen.
User Datagram Protocol (UDP) Das TCP ist ein nicht zuverlässiges,
verbindungsloses Transportprotokoll, das in Schicht 4 des OSI-Netzwerkschichtenmodells angesiedelt ist.
Verifizierung Der Empfänger von signierten Daten kann den Hash-Wert
entschlüsseln und diesen mit dem eigenen berechneten Hash-Wert der Daten
vergleichen. Sind beide gleich, so ist der Sender authentifiziert. Im Falle der
Public-Key-Infrastruktur wird mit dem öffentlichen Schlüssel des Senders
entschlüsselt.
Verschlüsselung Ein Verfahren, das Daten mit Hilfe eines Schlüssels so
umwandelt, dass die ursprüngliche Information der Daten nicht mehr erkennbar ist, aber mit Hilfe der Entschlüsselung wiederhergestellt werden kann.
Virtual Private Network (VPN) In einem Virtual Private Network
sind mehrere Hosts und/oder nicht-öffentliche Netzwerke über ein öffentliches Netzwerk so miteinander verbunden, dass private Daten untereinander
ausgetauscht werden können. Dabei wird üblicherweise eine Verbindung über
einen Tunnel durch das öffentliche Netzwerk hergestellt, die meistens noch
zusätzlich verschlüsselt wird um die privaten Daten zu schützen.
X.509 Standard Der X.509 Standard ist eine konkrete Public-Key-Infrastruktur, die den Standard für digitale Signaturen darstellt.
Zertifikat Ein Zertifikat erbringt den Nachweis, dass ein öffentlicher Schlüssel zu einer vorgegebenen Person gehört. Dies wird dadurch erreicht, dass
ein Zertifikat von einer Zertifizierungsstelle (Certification Authority) signiert
wird, indem der Hash-Wert des Datensatzes mit dem privaten Schlüssel der
Zertifizierungsstelle verschlüsselt wird. Dieser Datensatz enthält insbesondere
Informationen über den Namen des Inhabers des Zertifikates, seinen öffentlichen Schlüssel, die Gültigkeitsdauer des Zertifikats, das Signierungsverfahren
und den Namen der Zertifizierungsstelle.
45