VPN – Virtuelle Private Netzwerke
Manfred Lipp
VPN – Virtuelle Private Netzwerke Aufbau und Sicherheit
An imprint of Pearson Education München • Boston • San Francisco • Harlow, England Don Mills, Ontario • Sydney • Mexico City Madrid • Amsterdam
Die Deutsche Bibliothek - CIP-Einheitsaufnahme Ein Titeldatensatz für diese Publikation ist bei Der Deutschen Bibliothek erhältlich.
Die Informationen in diesem Produkt werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht. Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht vollständig ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar.
Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig. Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet werden. Umwelthinweis: Dieses Buch wurde auf chlorfrei gebleichtem Papier gedruckt. Die Einschrumpffolie – zum Schutz vor Verschmutzung – ist aus umweltfreundlichem und recyclingfähigem PE-Material.
10 9 8 7 6 5 4 3 2 1 05 04 03 02 01 ISBN 3-8273-1749-5 © 2001 by Addison-Wesley Verlag, ein Imprint der Pearson Education Deutschland GmbH, Martin-Kollar-Straße 10–12, D-81829 München/Germany Alle Rechte vorbehalten Einbandgestaltung: atelier für gestaltung n.&h., Niesner & Huber, Wuppertal Lektorat: Rolf Pakendorf,
[email protected] Korrektorat: Friederike Daenecke, Zülpich Herstellung: Anna Plenk,
[email protected] Satz: reemers publishing services gmbh, Krefeld (www.reemers.de) Druck und Verarbeitung: Media Print, Paderborn Printed in Germany
Inhaltsverzeichnis Vorwort
15
Aufbau
16
Danksagung
17
1 Virtuelle private Netzwerke
19
1.1
Was ist ein VPN?
19
1.2
Geschichte und Technologien
20
1.3
Warum VPNs?
24
1.4
Rahmenbedingungen für den Einsatz
26
1.5
Der VPN-Markt
28
1.6
IP-VPNs und das Internet
30
1.7
Entwicklungen und Ausblicke
33
2 VPN-Typen
37
2.1
Remote-Access-VPN
37
2.2
Branch-Office-VPN
41
2.3
Extranet-VPN
42
2.4
VPN-Service-Provider
43
2.4.1
IP-VPN-Dienste
44
2.4.2
Layer-2-VPN-Dienste
46
2.5
Intranet-VPN
47
2.5.1
Virtual Local Area Network (VLAN)
48
2.5.2
VLANs nach IEEE802.1q
50
2.5.3
IP-Tunneling
52
3 Anforderungen an VPNs 3.1
53
Sicherheit
53
3.1.1
Datenvertraulichkeit
53
3.1.2
Schlüsselmanagement
54
3.1.3
Paket-Authentifizierung
55
3.1.4
Datenintegrität
55
3.1.5
Benutzer-Authentifizierung
56
3.1.6
Benutzer-Autorisierung
56
3.1.7
Schutz vor Sabotage
57
3.1.8
Schutz vor unerlaubtem Eindringen
57
Inhaltsverzeichnis
3.2
3.3
3.4
Verfügbarkeit
59
3.2.1
Die Verfügbarkeit von Wählverbindungen
59
3.2.2
Die Verfügbarkeit von permanenten Verbindungen
60
3.2.3
Die Verfügbarkeit von IP-VPNs
60
Performance
61
3.3.1
Die Performance von Wählverbindungen
61
3.3.2
Die Performance von permanenten Verbindungen
61
3.3.3
Die Performance von IP-VPNs
62
Quality-of-Service (QoS)
62
3.4.1
Einführung in QoS-Konzepte
63
3.4.2
Quality-of-Service bei Wählverbindungen
66
3.4.3
Quality-of-Service bei permanenten Verbindungen
67
3.4.4
Quality-of-Service im IP-Protokoll
69
3.4.5
Die IP-Differentiated-Services-Architektur (DiffServ)
69
3.4.6
Differentiated Services in IP-VPNs
74
3.5
Skalierbarkeit und Migrationsfähigkeit
75
3.6
Integration in existierende Netze
76
3.6.1
Management
76
3.6.2
Sicherheit
80
3.7
Koexistenz zu traditionellen WAN-Strukturen
82
3.8
Adressmanagement
83
3.9
Interoperabilität
85
4 Sicherheitstechnologie 4.1
4.2
87
Sicherheit in VPNs
87
4.1.1
Sicherheit in Unternehmensdatennetzen
87
4.1.2
Die Sicherheit von virtuellen privaten Netzen
90
4.1.3
Datenvertraulichkeit
91
4.1.4
Sicherheit in der Netzwerkschicht mit IP Security
93
4.1.5
Benutzer-Authentifizierung
95
Die Grundlagen der Kryptographie
95
4.2.1
Geschichtliches
95
4.2.2
Datenvertraulichkeit
97
4.2.3
Verschleierung und Verschlüsselung
97
4.2.4
Die Kunst der Kryptoanalyse
99
Inhaltsverzeichnis
4.2.5
Einführung in die Kryptographie
101
4.2.6
Verschlüsselungsverfahren
108
4.3
Symmetrische Verschlüsselungsverfahren
113
4.4
Der Data Encryption Standard (DES)
114
4.4.1
Ein Überblick über DES
116
4.4.2
Die DES-Schlüsseltransformation
117
4.4.3
Die DES-Funktion
118
4.4.4
Die DES-Entschlüsselung
120
4.5
Triple-DES
4.6
Cipher Block Chaining (CBC)
122
4.6.1
Die Funktionsweise von CBC
123
Ausblick: Der Advanced Encryption Standard
124
4.7.1
AES-Software-Implementierung
126
4.7.2
AES-Hardware-Implementierung
126
4.7.3
AES-Geschwindigkeit und Optimierungsmöglichkeiten 127
4.7.4
»And the winner is …. Rijndael«
4.7
4.8
4.9
128
Asymmetrische Verschlüsselungsverfahren
129
4.8.1
Die kurze Geschichte der Public-Key-Kryptographie
129
4.8.2
Das Grundprinzip der Public-Key-Kryptographie
131
4.8.3
Mathematische Grundlagen
132
Das Diffie-Hellman-Verfahren
4.10 Das RSA-Verfahren 4.10.1
Zufallszahlen
4.11 Hashfunktionen
136 138 140 141
4.11.1
Algorithmen
142
4.11.2
Keyed Hashing
143
4.11.3
Hash-based Message Authentication Code (HMAC)
143
5 Authentifizierung 5.1
120
145
Möglichkeiten der Authentifizierung
146
5.1.1
Starke und schwache Authentifizierung
146
5.1.2
Wissensbasierende Authentifizierung
146
5.1.3
Besitzbasierende Authentifizierung
147
5.1.4
Kombinationsverfahren
147
5.1.5
Biometrik
148
5.1.6
Verfahren mit Einmal-Token
148
Inhaltsverzeichnis
5.2
5.3
5.4
Digitale Signaturen und digitale Zertifikate
150
5.2.1
Funktionsweise von digitalen Signaturen
150
5.2.2
Digitale Zertifikate nach ITU-X.509-Standard
153
Authentifizierungssysteme und -protokolle
155
5.3.1
PAP und CHAP
155
5.3.2
RADIUS
157
5.3.3
LDAP
160
5.3.4
Chipkarten
160
Public Key Infrastructure (PKI)
162
5.4.1
Vertrauensmodelle
162
5.4.2
Die Certificate Authority (CA)
164
5.4.3
Die Registration Authority (RA)
164
5.4.4
Zertifikat-Management
164
5.4.5
Die Qual der Wahl: Öffentliche oder private Zertifikate
166
5.4.6
Das Signaturgesetz und die EU-Richtlinie
167
6 Tunneling-Technologien im Überblick 6.1
6.2
6.3
6.4
6.5 6.6
169
Tunneling-Modelle
170
6.1.1
Das Intra-Provider-Modell
170
6.1.2
Das Provider-Enterprise-Modell
171
6.1.3
Das Ende-zu-Ende-Modell
172
Tunneling-Protokolle
172
6.2.1
Layer-2-Tunneling-Protokolle
172
6.2.2
Layer-3-Tunneling-Protokolle
173
6.2.3
Multi Protocol Label Switching (MPLS)
174
Standardisierte Tunneling-Protokolle
176
6.3.1
IP Security Protocol (IPSec) im Tunnel-Modus
176
6.3.2
Layer 2 Tunneling Protocol (L2TP)
178
Nicht standardisierte Protokolle
179
6.4.1
Layer 2 Forwarding (L2F)
180
6.4.2
Point-to-Point Tunneling Protocol (PPTP)
180
Verschachtelte Tunneling-Protokolle
181
Welches Protokoll für welchen Zweck?
183
6.6.1
Gegenüberstellung
183
6.6.2
Auswahlkriterien
184
Inhaltsverzeichnis
7 Das IP-Security-Protokoll (IPSec) 7.1
IP Security im Überblick
188
7.1.1
Paketintegrität
188
7.1.2
Paketauthentifizierung
189
7.1.3
Paketvertraulichkeit
189
7.1.4
Verkehrsflussvertraulichkeit
189
7.1.5
Schutz vor wiederholtem Senden von Paketen (Replay-Angriff)
190
Schutz vor weiteren Denial-of-Service-Angriffen
190
7.1.6 7.2
7.3
187
Kryptographische Verfahren in IPSec
191
7.2.1
Datenverschlüsselung in IPSec
191
7.2.2
Integritätsprüfung und Authentifizierung in IPSec
193
7.2.3
Schutz vor Replay-Angriffen
194
Die IPSec-Standardisierung
196
7.3.1
Die IPSec-Architektur
196
7.3.2
Die aktuelle IPSec-Standardisierung
197
7.4
Die IPSec-Sicherheitsassoziation
199
7.5
Die IPSec-Security-Policy
201
7.5.1
Die Security Policy in IPSec
201
7.5.2
Die IPSec-Selektoren
202
7.6
7.7
7.8
7.9
IPSec-Betriebsmodi
203
7.6.1
Tunnelmodus
203
7.6.2
Transportmodus
203
IPSec-Einsatzszenarien
204
7.7.1
Gateway-zu-Gateway
205
7.7.2
Host-zu-Gateway
205
7.7.3
Host-zu-Host
205
IPSec-Protokolle
205
7.8.1
Die Paketverarbeitung in IPSec
205
7.8.2
Das Authentication-Header-Protokoll (AH)
206
7.8.3
Das Encapsulating-Security-Payload-Protokoll (ESP)
209
IPSec-Implementierungen
214
7.9.1
Betriebssystemebene, IPSec-Stack
214
7.9.2
Bump-in-the-Stack (BITS)
215
7.10 Betrachtungen zur IPSec-Performance
215
7.11 Zukünftige Entwicklungen
219
Inhaltsverzeichnis
8 Das Internet-Key-Exchange-Protokoll
221
8.1
Das Henne-Ei-Problem
221
8.2
ISAKMP
222
8.2.1
Die Sicherheit von ISAKMP
223
8.2.2
Der ISAKMP-Header
228
8.2.3
Der generische ISAKMP-Nutzdaten-Header
231
8.3
8.4
8.5
8.6
ISAKMP-Nutzdaten
232
8.3.1
Die Sicherheitsassoziation-Payload
232
8.3.2
Die Proposal Payload
233
8.3.3
Die Transform Payload
233
8.3.4
Key Exchange Payload
234
8.3.5
Identification Payload
235
8.3.6
Certificate Payload
235
8.3.7
Certificate Request Payload
236
8.3.8
Hash, Signature und Nonce Payload
237
8.3.9
Notification Payload
238
8.3.10
Delete Payload
239
8.3.11
Vendor ID Payload
240
8.3.12
Die ISAKMP-Phasen
241
8.3.13
Die ISAKMP-Austauschvorgänge
241
Das Oakley Key Determination Protocol
243
8.4.1
Die Oakley-Gruppe-1
243
8.4.2
Die Oakley-Gruppen 2 bis 5
244
Der Aufbau von IKE
244
8.5.1
Perfect Forwarding Secrecy
245
8.5.2
Die Attribute einer IPSec-Sicherheitsassoziation
245
8.5.3
Die Attribute einer ISAKMP-Sicherheitsassoziation
247
8.5.4
IKE-Sicherheitsverfahren
250
8.5.5
Die Schlüsselerzeugung in IKE
251
8.5.6
IKE-Authentifizierung
254
Der IKE Main Mode
256
8.6.1
Authentifizierung mit Pre-Shared Key
256
8.6.2
Authentifizierung mit digitaler Signatur
260
8.6.3
Authentifizierung mit Public-Key-Verschlüsselung (RSA)
261
Inhaltsverzeichnis
8.6.4 8.7
Authentifizierung mit revidierter Public-KeyVerschlüsselung (RSA)
263
Der IKE Aggressive Mode
265
8.7.1
Authentifizierung mit Pre-Shared-Secret
267
8.7.2
Authentifizierung mit digitaler Signatur
269
8.7.3
Authentifizierung mit standardisierter und revidierter Public-Key-Verschlüsselung
269
8.8
Der IKE Quick Mode
269
8.9
Die Performance von IKE
272
8.9.1
273
IKE und Hardwarebeschleuniger
9 Das Layer 2 Tunneling Protocol 9.1
9.2
277
Das Point-to-Point Protocol (PPP)
277
9.1.1
278
PPP-Remote-Access
9.1.2
PPP-Komponenten
278
9.1.3
PPP-Steuerungsprotokolle und -Dienste
280
9.1.4
PPP-Verbindungsaufbau
282
PPP-Tunneling mit L2TP
284
9.2.1
Virtueller Remote Access mit L2TP
285
9.2.2
PPP-Session-Verteilung in L2TP
286
9.2.3
Die Rolle des LAC (L2TP Access Concentrator)
289
9.2.4
Die Rolle des LNS (L2TP Network Server)
289
9.2.5
Betrachtungen zur Performance von L2TP
289
9.2.6
L2TP-Tunneling-Modelle
292
9.2.7
L2TP-Paketformate
293
9.2.8
L2TP Attribute Value Pairs (AVP)
295
9.2.9
Auf- und Abbau von Tunneln und Calls in L2TP
298
9.2.10
L2TP-Benutzer-Authentifizierung
300
9.3
Die Sicherheit von L2TP
303
9.4
IPSec secured L2TP
305
10 VPN-Design
309
10.1 Ein VPN ist auch nur ein Netzwerk
309
10.2 Die Planung
310
10.3 Die Ist-Aufnahme
310
10.3.1
Technische Aspekte
312
10.3.2
Betriebswirtschaftliche Aspekte
314
10.3.3
Sicherheit
315
Inhaltsverzeichnis
10.4 Der Sollzustand
316
10.4.1
Der unvermeidliche (?) Bruch
316
10.4.2
Randbedingungen
317
10.4.3
Technische Aspekte
319
10.4.4
Betriebswirtschaftliche Aspekte
321
10.5 Die Übergangsphase
322
10.6 Die Sicherheitsstrategie
322
10.7 Auswahl der VPN-Technologie
325
10.7.1
VPN-Typ
10.7.2
325
Tunneling-Protokolle
326
10.8 Ermitteln der QoS-Parameter
327
10.9 Die Realisierung
328
10.9.1
Routing im VPN
10.9.2
Remote Access
330
10.9.3
Kleine Außenstellen und Heimbüros
341
10.9.4
Skalierbarkeit
342
10.9.5
Redundanz und Ausfallsicherheit
343
10.9.6
Durchsatz und Quality-of-Service
344
10.9.7
Sicherheitsstrategie und Firewalls
346
10.9.8
Authentifizierungsverfahren
351
10.9.9
Die Auswahl von Service Providern
352
10.9.10 Service Level Agreements 10.10 Beispiele
329
353 356
10.10.1 Remote-Access-VPN
356
10.10.2 Branch-Office-VPN
359
10.10.3 IP-VPN-Service eines ISP
360
11 Auswahl der VPN-Komponenten
361
11.1 VPN, Feature oder dediziert?
362
11.2 Performance
363
11.2.1
Eigene Messungen
364
11.2.2
Veröffentlichte Testberichte
364
11.2.3
Beurteilungskriterien
364
11.3 Die Herstellerauswahl
366
11.4 Die Auswahl der VPN-Komponenten
370
11.4.1
Das Beispielnetzwerk
370
11.4.2
Allgemein
372
Inhaltsverzeichnis
11.4.3
Leistung
373
11.4.4
Schnittstellen
375
11.4.5
Tunneling-Protokolle
376
11.4.6
Sicherheit
377
11.4.7
Authentifizierung
379
11.4.8
Quality-of-Service und Profile
380
11.4.9
Management, Accounting, Logging und weitere Funktionen 382
11.4.10 VPN-Routing
384
11.5 Die Auswahl von VPN-Clientsoftware
385
Fallstudien
389
12.1 Studie 1: Die Software AG
389
12
12.1.1
Zum Unternehmen
389
12.1.2
Das Projekt
390
12.1.3
Projektablauf und Realisierung
391
12.2 Studie 2: Der Blutspendedienst des DRK
392
12.2.1
Zu den Unternehmen
393
12.2.2
Das Projekt
394
12.2.3
Projektablauf und Realisierung
395
12.3 VPN-Dienste von Service Providern 12.4 Studie 3: Die VIAG Interkom
398 399
12.4.1
Zum Unternehmen
399
12.4.2
Der IP-VPN-Dienst
400
12.4.3
Infrastruktur
404
12.4.4
Remote-Access-VPN
405
12.4.5
Branch-to-Branch-VPN
406
13 Anhang
409
Weiterführende Literatur
409
Links
411
14 Stichwortverzeichnis
413
Vorwort Das Internet, einstmals nur Medium für kryptische E-Mails und FTP-Dateitransfers mit einer überschaubaren Anzahl von Benutzern, hat sich von einer Größe von einigen wenigen 1,5-Mbit/s-Verbindungen (T1-Links) zu einem weltumspannenden, leistungsfähigen Netzwerk mit einer eigenen grafischen Oberfläche entwickelt. Seine Verbindungsgeschwindigkeiten reichen mittlerweile bis in den Terabit-Bereich, was mehr als 660.000 parallelen T1-Links entspricht! Das Internet wird darüber hinaus zunehmend zum Medium für die Geschäftsprozesse vieler Unternehmen, ja sogar ganze Firmen basieren bereits darauf. Kein Unternehmen kann es sich heute mehr leisten, nicht im World Wide Web präsent zu sein und bestimmte Prozesse wie Bestellungen, OnlineDienste oder einfach nur Produktinformationen nicht über dieses Medium seinen Kunden zur Verfügung zu stellen. Die Anzahl der Internet-Zugänge wächst ständig, und damit steigt auch die Zahl der Personen und Organisationen immer weiter, die über sie in Sekundenschnelle erreicht werden können. Somit entsteht natürlich zunehmend der Wunsch, dieses riesige weltweite Netzwerk – und nichts anderes ist das Internet – auch zum Zweck privater Kommunikation zu benutzen, indem man es verwendet, um verschiedene, möglicherweise international verteilte Standorte und Personen miteinander zu verbinden. Die Größe und die mittlere Geschwindigkeit des Internets machen dies möglich, und zwar zu Kosten, die weit unter dem liegen, was man heutzutage für exklusive Verbindungen bezahlen muss. Allerdings ist die Datenkommunikation im Internet nicht vertraulich und integer, da das Internet-Protokoll (IP) keine Sicherheitsfunktionen dafür bereitstellt. Die private Datenkommunikation erfordert jedoch die Vertraulichkeit, Integrität und Authentizität der übertragenen Informationen. Die Technik der virtuellen privaten Netzwerke ist die Lösung, um diese beiden divergierenden Forderungen gleichermaßen erfüllen zu können. Auf der Basis moderner und sicherer Protokolle wie IP Security (IPSec) können die Vorteile des Internets auch auf die private Datenkommunikation unter Wahrung der Vertraulichkeit und Integrität privater Informationen angewendet werden. Damit birgt diese Technologie für Unternehmen jeder Größenordnung ein hohes Ratiopotenzial. Dieses Buch wendet sich sowohl an Leser, die sich allgemein für die relativ neue Technologie sicherer Internet-VPNs interessieren, als auch an solche, die planen, eine VPN-Lösung zu implementieren und einzusetzen. Das Ziel dieses Buches ist es, Ihnen das nötige Wissen zur Planung, Realisierung und Administration von virtuellen privaten Netzwerken zu vermitteln. Besonderer Wert wurde dabei auf Herstellerneutralität gelegt.
15
Vorwort
Aufbau Dieses Buch ist in drei Teile gegliedert: eine Einführung in die Thematik, eine ausführliche technische Beschreibung der wichtigsten VPN-Schlüsseltechnologien und schließlich in Überlegungen und Tipps zur Implementierung. Im Anhang finden Sie ein Verzeichnis von weiterführender Literatur und interessanten Links, auf die in diesem Buch an verschiedenen Stellen verwiesen wird. Der erste Teil besteht aus den ersten drei Kapiteln. Kapitel 1 beschäftigt sich mit der Frage, was ein VPN eigentlich ist, wie es sich gegen andere Netzwerktechnologien abgrenzt und welchen Nutzen der Anwender daraus ziehen kann. Außerdem werden dort aktuelle und zukünftige Entwicklungen sowie Marktanalysen beschrieben. Kapitel 2 hat die unterschiedlichen Typen von virtuellen privaten Netzen zum Thema: die Remote-Access-, Branch-Office-, Extranet- und Intranet-VPNs und die VPN-Dienste, die in zunehmendem Maße von verschiedenen Service Providern und Carriern angeboten werden. In Kapitel 3 werden schließlich die technischen und qualitativen Anforderungen erläutert, die heute von modernen Unternehmensnetzen an VPNs gestellt werden. Vitale Themen wie Datensicherheit, Verfügbarkeit und Quality-ofService sind hierbei die Schwerpunkte. Der zweite Teil des Buches beschreibt ausführlich die in modernen IP-VPNs eingesetzten Technologien. Er besteht aus den Kapiteln 4 bis 9. In Kapitel 4 wird auf das Thema Sicherheit und die Grundlagen der Kryptologie eingegangen. In diesem Kapitel wurde besonderes Augenmerk auf die in heutigen VPNs eingesetzten Sicherheitstechnologien gerichtet. Kapitel 5 befasst sich mit dem Thema Authentifizierung und stellt die verschiedenen Verfahren und Applikationen vor. Das Thema digitale Signaturen und Public Key Infrastructure (PKI) wurde ausführlich behandelt, wobei auch rechtliche Aspekte berücksichtigt werden. Die verschiedenen Tunneling-Modelle, die man in einem VPN einsetzen kann, sind das Thema von Kapitel 6. Hier werden auch die wichtigsten TunnelingProtokolle beschrieben und gegenübergestellt. Kapitel 7 befasst sich mit dem Thema IP Security (IPSec) und beschreibt detailliert die Funktionen dieser Protokollfamilie, die einen weit reichenden Schutz der IP-Kommunikation garantiert. In Kapitel 8 finden Sie eine Beschreibung des Internet-Key-Exchange-Protokolls (IKE). Da IKE für eine sichere IPSec-Kommunikation sehr wichtig ist, ist das Kapitel recht ausführlich ausgefallen. Die verschiedenen Modi und Betriebsarten werden dort detailliert erläutert. Als wichtigster Vertreter seiner Familie wird in Kapitel 9 das Layer-2-Tunneling Protocol (L2TP) und sein Einsatz in Zusammenarbeit mit IPSec in modernen Betriebssystemen vorgestellt. Teil Drei umfasst Kapitel 10 bis 12 und ist der praktischen Umsetzung gewidmet. Kapitel 10 beschreibt die verschiedenen Phasen bei der Planung und Realisierung von VPNs von der Ist-Analyse bis zum Aufbau. Kapitel 11
16
Danksagung
beschäftigt sich mit der Auswahl der VPN-Komponenten. Hier wird, statt der sonst üblichen und schnell veralteten Hersteller- und Produktübersicht, detailliert auf die Kriterien zur Produkt- und Herstellerauswahl eingegangen und beispielhaft die Erstellung eines geeigneten Anforderungskatalogs beschrieben. Kapitel 12 gibt abschließend anhand von Fallstudien verschiedener Unternehmen einen tiefen und informativen Einblick in bereits realisierte VPNs und VPN-Dienste.
Danksagung Insbesondere meinem Vater, meiner Freundin Gaby und meinen ganzen Freunden und Bekannten möchte ich an dieser Stelle für ihre Geduld und ihr Verständnis dafür danken, dass ich in den letzten Wochen und Monaten nur sehr wenig Zeit für sie erübrigen konnte. Da ich dieses Buch neben meiner eigentlichen Berufstätigkeit geschrieben habe, musste ich dafür sehr viele Abende und Wochenenden investieren. Mein weiterer Dank gilt der Firma Nortel Networks und dort insbesondere Andreas Herden, Martin Ruoff und Armin Schmidt für ihre wohlwollende Unterstützung. Sehr viel von dem, was ich an praktischer Erfahrung in dieses Buch einbringen konnte, habe ich bei diesem Unternehmen in zahlreichen Projekten sammeln können. Besonderen Dank möchte ich auch dem Blutspendedienst des Deutschen Roten Kreuzes, den Firmen ASAP.COM, Software AG und VIAG Interkom aussprechen. Insbesondere gilt hier mein Dank den Herren Dieter Kaper, Gerd Mitschke, Christoph Pischka und Oliver Truetsch für ihre wertvollen Informationen und Anregungen zu den Fallstudien in diesem Buch. Auch all den Teilnehmern der VPN-, WAN- und Security-Technology-Seminare der Nortel Networks Network Academy, die mich durch ihre Kritik, ihre Vorschläge und ihre vielen Anregungen zum Schreiben dieses Buches veranlasst haben und deren Namen ich hier verständlicherweise nicht alle nennen kann, sei an dieser Stelle gedankt. Weiterhin möchte ich besonders meinen Lektoren, Frau Friederike Daenecke und Herrn Rolf Pakendorf, für ihre Mühe und ihre tatkräftige Unterstützung bei der Entstehung dieses Buches danken. Für die technische Unterstützung bei der Erstellung des Manuskripts möchte ich Herrn Karl Kienle danken. Stuttgart Manfred Lipp
17
1
Virtuelle private Netzwerke
1.1
Was ist ein VPN?
Was ist ein VPN? Ein VPN (virtuelles privates Netzwerk) ist ein Netzwerk, das ein öffentliches Netzwerk benutzt, um private Daten zu transportieren. Dies ist zugegebenermaßen eine recht allgemein gehaltene Definition, die aber allen Arten von VPNs gerecht wird. In der heutigen Zeit wird ein VPN sehr oft nur auf die Benutzung des Internets als öffentliches Netzwerk reduziert, was aber so nicht stimmt. Wie Sie in diesem Kapitel sehen werden, gibt es eine ganze Reihe anderer, teilweise schon recht alter VPN-Technologien, die überhaupt keinen Gebrauch vom Internet machen. Auch spricht man in diesem Zusammenhang oft nur von Datenübertragung, aber es gibt auch reine Sprach-VPNs und in Zukunft auch so genannte Unified-VPNs, also Netze, die zur gleichzeitigen Übertragung von Sprache, Daten und interaktiven Videokonferenzen geeignet sind. Diese Tendenz, für die sich mittlerweile der Ausdruck Konvergenz oder auch Konvergenz der Netze als allgemein gültiger Begriff etabliert hat, führt zu einigen unverzichtbaren Anforderungen an solche Netzwerke. Denn im Gegensatz zur reinen Datenübertragung, bei der es in den meisten Fällen nicht so sehr darauf ankommt, ob die Pakte verzögert ankommen, und die auch mit zeitweise geringen Bandbreiten auskommt, müssen diese neuen, konvergierten Netze für Datenströme bestimmter Dienste gewisse Qualitäten netzwerkweit garantieren können. Diese Forderung, die in lokalen Netzen und bestimmten Arten von öffentlichen Netzen durchaus realisierbar ist, wird in IP- beziehungsweise Internet-VPNs zu einem extrem kritischen Faktor, der in diesem Buch auch angemessen berücksichtigt ist. Aber zurück zur Definition eines virtuellen privaten Netzwerks. Das Gegenstück zum VPN ist ein echtes privates Netzwerk, also ein Netzwerk, das exklusiv von einem Unternehmen oder einer Organisation betrieben wird. Das heißt, alle Übertragungseinrichtungen und alle Übertragungsmedien gehören diesem Unternehmen oder sind ihm zur exklusiven Nutzung überlassen. Beispiele sind die so genannten Mietleitungen oder Standardfestverbindungen, die einer Organisation zur ausschließlichen Nutzung vermietet werden. Mit geeignetem Equipment zur Daten- oder Sprachübertragung über diese Leitungen wird ein scheinbar rein privates Netzwerk betrieben. Scheinbar deshalb, weil die Verbindungen zwar ausschließlich vom Mieter derselben benutzt werden, jedoch meist, zumindest in Europa, Teil einer öffentlichen Netzwerkinfrastruktur sind. Diese Infrastruktur bietet jedoch umfassende Möglichkei-
19
1 Virtuelle private Netzwerke
ten zum »Anzapfen« dieser Verbindung und stellt somit in jedem Fall ein mögliches Sicherheitsrisiko dar – auch wenn die Betreiber solcher Netze natürlich keinen Missbrauch treiben dürfen und ein Abhören nur aufgrund einer richterlichen Anordnung durch bestimmte Personen zulässig ist. Ein öffentliches Netzwerk hingegen ist eine Kommunikationsinfrastruktur, die von einem Dienstleistungsunternehmen betrieben wird, das die Benutzung des Netzes jedermann gegen ein entsprechendes Verbindungsentgelt ermöglicht. Ein Beispiel hierfür sind öffentliche Telefonnetze. Jeder kann gegen eine entsprechende Gebühr dieses Netz benutzen. Ein VPN versucht, private und öffentliche Netzwerke zu kombinieren, indem das öffentliche Netzwerk als Trägernetzwerk für die private Kommunikation benutzt wird.
1.2
Geschichte und Technologien
Virtuelle private Netzwerke gibt es schon seit einiger Zeit. Sie wurden aber nicht immer so genannt. In der Vergangenheit wurden vielfach andere Begriffe verwendet, z.B. Corporate Network. Ein ganze Reihe, teilweise schon recht lange im Einsatz befindlicher Technologien eignet sich als Basistechnologie für VPNs: 왘 ISDN 왘 Frame Relay 왘 ATM 왘 Das Internet
ISDN Eine schon etwas ältere VPN-Technologie sind zum Beispiel die so genannten geschlossenen Nummernkreise in einem digitalen Telefonnetzwerk wie dem ISDN (Integrated Services Digital Network, ein leitungsvermittelndes, digitales Multiservice-Netzwerk). Das Telekommunikationsunternehmen vergibt hierbei für die Anschlüsse eines Kunden eine Reihe von Telefonnummern, die nur untereinander kommunizieren können. Verbindungen zu oder von Nummern außerhalb dieses Nummernkreises sind nicht möglich. Aus Sicht des Unternehmens sieht dies wie ein privates, abgeschlossenes Telefonnetz aus. In Wirklichkeit wird aber das öffentliche Netzwerk des Telekommunikationsunternehmens benutzt, das die nötige Infrastruktur in Form von Leitungen und Vermittlungssystemen zur Verfügung stellt. Die Kommunikation zu Nummern außerhalb des geschlossenen Nummernkreises ist nur über ein Schnittstellensystem, z.B. eine Nebenstellenanlage, möglich, die einen Übergang zum öffentlichen Netzwerk bietet.
20
Geschichte und Technologien
Frame Relay Eine andere, ebenfalls bereits länger verfügbare VPN-Variante sind Netzwerke, die auf dem Frame-Relay-Verfahren basieren. Frame Relay ist eine Übertragungstechnologie, die ursprünglich zum reinen Datentransport entwickelt wurde, aber auch zunehmend für gemischte Sprach- und Datenübertragung verwendet wird. Der Frame-Relay- Standard wurde eigentlich auf Grundlage des X.25-Standards als ISDN-Datenübertragungsprotokoll entwickelt. Das Frame Relay Forum, das 1991 gegründet wurde, definiert die notwendigen, herstellerübergreifenden Standards hierfür. Obwohl es aus dem X.25-Standard hervorgegangen ist, existieren zu diesem doch wesentliche Unterschiede. So arbeitet Frame Relay mit viel höheren Geschwindigkeiten, mit teilweise bis zu 45 Mbit/s. Da Frame Relay eine hohe Leitungsqualität voraussetzt, wurden auch nicht so aufwendige und ressourcenintensive Mechanismen zu Sicherung der Übertragung benötigt, wie dies beim X.25-Protokoll der Fall ist. Netzwerk A
Router A
Netzwerk B
Netzwerk C
PVC 1 Router B
PVC 2
PVC 3 PVC 4
PVC 5
Router C
PVC 6
Router D
Frame-RelayNetzwerk
Netzwerk D
Abbildung 1.1: Im Frame-Relay-VPN werden die permanenten virtuellen Verbindungen auf der OSI-Schicht 2 abgebildet.
Frame Relay ist aus der Sicht des Anwenders ein verbindungsorientiertes Protokoll. Das heißt, es muss eine so genannte virtuelle Verbindung zwischen zwei Datenübertragungseinrichtungen existieren. Diese kann entweder vom Provider fest konfiguriert und dauerhaft aktiviert werden oder erst bei anstehender Datenübertragung vom Kunden aktiviert und anschließend wieder deaktiviert werden. Die erste Variante nennt man PVC (Permanent Virtual Circuit), und die zweite Variante wird als SVC (Switched Virtual Circuit) bezeichnet. Die Pfade werden deshalb als virtuell bezeichnet, weil in Wirk-
21
1 Virtuelle private Netzwerke
lichkeit keine physikalische Ende-zu-Ende-Verbindung besteht. Tatsächlich ist der Weg der Frames durch ein Frame-Relay-Netzwerk dynamisch; bei Ausfällen oder Überlasten können alternative Routen gewählt werden. Für den Abonnenten eines Frame-Relay-PVCs ist dies alles nicht sichtbar, für ihn stellt sich das Ganze als Punkt-zu-Punkt-Verbindung dar. Neben der hohen Geschwindigkeit bietet Frame Relay aber einiges mehr; insbesondere können verschiedene Dienstqualitäten zwischen Provider und Kunde vereinbart werden. So können Parameter wie garantierte Bandbreite und maximale Bandbreite vereinbart werden. Es ist auch möglich, in einer Verbindung zu einem Frame-Relay-Netz-Zugangsknoten gleichzeitig mehrere PVCs mit verschiedenen Parametern für verschieden priorisierte Dienste wie SAP, Sprache und unkritischen Datenverkehr zu konfigurieren. Auch in Hinblick auf seine große Verbreitung (es wird praktisch weltweit angeboten) eignet sich Frame Relay vom technischen Standpunkt aus gesehen hervorragend als Basis zum Aufbau von VPNs. Für detaillierte Informationen zu Frame Relay sei auf die einschlägige Fachliteratur verwiesen. Der Asynchronous Transfer Mode, ATM Neben Frame Relay hat sich auch ATM (Asynchronous Transfer Mode) als Basis für die Art von öffentlichen Netzwerken etabliert, die sich sehr gut zum Aufbau von VPNs eignen. Beim Stichwort ATM fallen Ihnen zuerst wahrscheinlich zwei Begriffe ein: Geschwindigkeit und Komplexität. Übertragung mit maximaler Bitrate
Daten Sprache
Daten Sprache
Video
Video
Leerzellen
Segmentierung
Reassemblierung
Abbildung 1.2: ATM ermöglicht die Übertragung der verschiedensten Arten von Datenverkehr.
Die ATM-Technologie als solche ist, sobald man sich ein wenig mit ihr beschäftigt hat, gar nicht so komplex. Allerdings steigt die Komplexität mit der Komplexität des Einsatzes dieser Technologie, insbesondere dann, wenn sie zu Dingen benutzt wird, für die sie nicht ausgelegt wurde, beispielsweise für die Emulation von Ethernet- oder Token-Ring-Netzwerken. Wenn mit einem verbindungsorientierten Netzwerk wie ATM ein auf Broadcasts basierendes Netzwerk wie Ethernet emuliert werden soll, dann wird es eben kompliziert.
22
Geschichte und Technologien
In einem ATM-Netzwerk kann man sehr schnell Daten übertragen, aber das ist gar nicht einmal das wichtigste Kriterium für seine Auswahl, sondern es geht um die damit möglichen abgestuften Dienstqualitäten und die gute Eignung zur Übertragung von isochronen Datenströmen wie Sprache oder Video. Im Gegensatz zum Frame-Relay-Verfahren, mit dem Daten von mehreren tausend Byte in einem Frame übertragen werden können, benutzt man bei ATM das Cell Switching. Es werden dabei sehr kleine Zellen übertragen, die eine feste Länge von 53 Byte haben. Die Nutzdatenpakete werden vor der Übertragung in 48 Byte große Zellen aufgeteilt, mit einem Header versehen und in den 53 Byte großen ATM-Zellen synchron übertragen. Auf der Empfängerseite werden die Pakete wieder zusammengesetzt, sofern keine Zellen aufgrund von Überlastsituationen verworfen wurden. Denn ATM, ebenso wie Frame Relay, erlaubt es, Zellen zu verwerfen, sofern sie entsprechend gekennzeichnet sind und einer entsprechenden Dienstklasse angehören. Bei Sprachoder Videoübertragungen ist dies meist kein Problem, denn durch die minimale Größe der ATM-Zellen bleibt die akustische oder optische Störung in der Regel subjektiv unbemerkt. Auch bei den meisten Datenübertragungen ist dieses Verhalten akzeptabel, denn die höheren Übertragungsprotokolle fordern das gesamte Paket einfach noch einmal an. PC
Netzwerk A
Netzwerk C
Tunnel
Internet
Gateway A
Gateway C
Tunnel Tunnel
Tunnel
Gateway B
Netzwerk B
Abbildung 1.3: Im Internet-VPN werden die virtuellen Verbindungen auf der OSI-Schicht 3, der Netzwerkschicht, abgebildet.
Wer sich tiefer in dieses Thema einlesen möchte, dem sei auch an dieser Stelle die umfangreiche weiterführende Literatur empfohlen.
23
1 Virtuelle private Netzwerke
Das Internet In neuerer Zeit spricht man immer öfter von IP-VPNs oder auch InternetVPNs. Der fundamentale Unterschied zu virtuellen privaten Netzwerken auf Basis von ISDN, Frame Relay oder ATM ist der, dass die Trägertechnologie nicht auf der Ebene 2 des OSI-Schichtenmodells, sondern auf der Ebene 3, der Netzwerkschicht, liegt. Der große Vorteil liegt darin, dass man damit von physikalischen Infrastrukturen unabhängig wird. Das IP-VPN transportiert IP-Pakete zwischen zwei Endsystemen. Ob das IP-Paket während der Übertragung in ATM, Frame Relay (oder was auch immer und in welcher Kombination auch immer) eingekapselt wird, ist aus Sicht des VPN unerheblich. Ein Internet-VPN benutzt das Internet, das weltgrößte und immer noch stark wachsende IP-Netzwerk, als öffentliches Netzwerk.
1.3
Warum VPNs?
Der Hauptgrund für den Einsatz virtueller privater Netzwerke besteht in deren niedrigen Betriebskosten. Dies gilt insbesondere für Internet-VPNs; bei VPNs auf Basis von ATM und Frame Relay sind die Einsparungen längst nicht so hoch. Nicht selten sind die Gesamtkosten eines Internet-VPNs, also die Summe aus Investitionen und den Betriebskosten, schon für das erste halbe Jahr geringer als unter Verwendung von traditionellen Netzwerkkomponenten! Somit gibt der Kostenfaktor meist den Hauptausschlag zugunsten dieser neuen Technologie. Der Spitzname für VPNs »Very Profitable Network« kommt nicht von ungefähr.
Monatliche Grundgebühr (2 x E1)
Einwähl-RemoteAccess
VPN-RemoteAccess
DM 1.124,-
DM 4.264,-
Volumengebühr (7,6 Gbyte) Zeitgebühr Dial-In (0,05 DM/min)
DM 792,DM 47.520,-
Zeitgebühr VPN (79,- DM/Monat Flatrate) Summe
DM 4.740 DM 48.644,-
DM 9.796,-
Tab. 1.1: Ein Kostenvergleich zwischen Remote Access auf Basis von Einwähl- und VPN-Technologie
In Tabelle 1.1 sehen Sie eine Beispielrechnung dafür, wie hoch die Einsparungen beim Einsatz eines Remote-Access-VPN sein können. Als Beispiel wurde ein Netzwerk eines mittelständischen Unternehmens gewählt, das maximal 60 gleichzeitige Verbindungen in das Unternehmensnetzwerk zur Verfügung stellen will. Es wurde sehr konservativ gerechnet und der am 11. Dezember
24
Warum VPNs?
2000 billigste Anbieter mit 5 Pf/min (in der Fernzone) genommen. Die übertragene Datenmenge von 7,6 Gbyte berechnet sich unter der Annahme, dass alle 60 B-Kanäle des Remote-Access-Systems zwölf Stunden am Tag und 22 Tage im Monat (dies entspricht einer Verbindungszeit von 950.400 Minuten pro Monat) mit voller Bandbreite ausgelastet sind. Die Alternative dazu, der Einsatz von VPN-Technologie, legt zwei E1-Verbindungen (2 Mbit/s) mit einem monatlichen Datenvolumen von 7,6 Gbyte zu einem ISP zugrunde. Die Einwahl der Benutzer erfolgt bei einem Provider mit einer so genannten Flatrate von DM 79,- pro Monat inklusive Telefongebühren. Die Betriebskosten der beiden Lösungen wurden in beiden Fällen als gleichwertig angenommen. Die Anschaffungskosten der Hardware unterscheiden sich ebenfalls: Ein dem notwendigen Remote-Access-Konzentrator gleichwertiges VPN-System kostet im Schnitt etwa 50% weniger, bei hohen Portdichten sogar bis zu 80% weniger! Das Einspar-Potenzial liegt bei 38.788 DM pro Monat, also bei einer Tarifersparnis von fast 80% – das ergibt eine jährliche Einsparung von 465.465 DM. Und dies ist noch eine vergleichsweise kleine Remote-Access-Lösung. Ich erwähnte bereits, dass dieses Beispiel extrem konservativ gerechnet ist. Denn in der Praxis wird meist etwas schärfer kalkuliert: Es ist nämlich sehr unrealistisch, dass alle 60 B-Kanäle der Remote-Access-Lösung zwölf Stunden am Tag mit voller Bandbreite betrieben werden, wodurch sich die zugrunde gelegte Gesamtbandbreite von 4 Mbit ergeben würde. Es ist vielmehr so, dass eine Verkehrsanalyse in den meisten Fällen ergeben wird, dass die Gesamtbandbreite statistisch gesehen fast immer deutlich darunter liegt. Und nur diese Bandbreite müsste ein VPN-Remote-Access-Konzentrator zur Verfügung stellen, wodurch die Zugangsverbindung zum Internet deutlich schmalbandiger und damit kostengünstiger ausfallen kann. Hier kommt der Vorteil eines IP-VPNs, nämlich über ein paketorientiertes Netzwerk ein leitungsvermittelndes Netz zu simulieren, voll zum Tragen. Die Gründe für den Einsatz von virtuellen privaten Netzen sind recht vielfältig und vom Geschäftsmodell der Betreiber abhängig. In Abbildung 1.7 sehen Sie die Resultate einer Umfrage, die ermitteln sollte, zu welchem Zweck die befragten Unternehmen die VPN-Technologie einsetzen. Nach wie vor nimmt der Remote Access eine führende Stellung ein, wohl deshalb, weil damit am schnellsten sehr hohe Einsparungen zu erzielen sind. Zum anderen bieten Internet-VPNs häufig eine große Flexibilität: Man kann sehr schnell neue Benutzer und Standorte in sein Netzwerk einbinden. Ein neuer Remote-Access-Benutzer braucht sich zum Beispiel nur beim Service Provider anzumelden und kann gleich danach das VPN benutzen. Es müssen keine Geräte beschafft oder erweitert und keine neuen Zugangsleitungen bestellt werden.
25
1 Virtuelle private Netzwerke
Warum hat sich dann nicht jeder schon vor Jahren auf Internet-VPNs gestürzt? Das Problem liegt im Internet begründet, denn eine wichtige Sache bietet das Internet noch nicht: garantierbare Bandbreiten und Verzögerungszeiten. Auch vom Standpunkt der Sicherheit aus gibt es heute oft noch erhebliche Bedenken, das Internet zum Transport privater Daten zu benutzen. Eine ganze Reihe dieser Einwände lässt sich aber durch heute frei verfügbare Technologien zur Datenverschlüsselung und generellen Netzwerksicherheit zerstreuen, einzig das Problem der nicht garantierten Dienstqualität bleibt vorerst noch bestehen. Aber auch daran wird gearbeitet, und es gibt mittlerweile auch schon brauchbare Lösungen – sie müssen nur noch implementiert werden.
1.4
Rahmenbedingungen für den Einsatz
Der sinnvolle und mögliche Einsatz eines VPNs hängt von verschiedenen Rahmenbedingungen ab, die von Land zu Land und von Benutzer zu Benutzer unterschiedlich sein können. Leaders
Challengers
Nortel Networks
Cisco
Execute
Check Point Lucent IBM Axent
3Com
NAI Intel/Shiva
Ability
IRE TimeStep Watchguard Secure Computing
InfoExpress
Compatible Systems VPNet Radguard Red Creek
Niche Players
Altiga
Indus River
Visionaries
Completeness of Vision Abbildung 1.4: Eine Analyse des Remote-Access-VPN-Marktes (Quelle: Gartner Group, 1999)
26
Rahmenbedingungen für den Einsatz
Eine der Hauptmotivationen, der Kostenaspekt, ist sehr variabel, sowohl zeitlich als auch regional. In den meisten Ländern gibt es sehr unterschiedliche Tarife, sowohl im Bereich der öffentlichen Netze als auch für den Internetzugang. Da VPNs oft international ausgelegt werden, muss man mit den unterschiedlichsten Tarifen und Zugangstechnologien kalkulieren, was schnell etwas unübersichtlich werden kann. Ein Beispiel: In den USA oder Kanada bekommt man schnell und sehr kostengünstig DSL-Anschlüsse. In Deutschland bekommt man nach wie vor, außer in den Ballungszentren, meist nur ein bedauerndes Kopfschütteln zu sehen und einen Platz auf der Warteliste zugewiesen. Und wenn es so weit ist, schlagen, im Gegensatz zu Nordamerika, erheblich höhere Kosten zu Buche. Je weiter ein VPN international gespannt wird, desto komplexer werden die Kostenkalkulationen, die auch ständigen Änderungen durch – glücklicherweise meist fallende – Gebühren unterworfen sind. Weiterhin gibt es auch die unterschiedlichsten Zugangstechnologien, die sowohl von der Technik als auch von den Kosten regional wieder sehr unterschiedlich sein können. Hinzu kommt, dass nicht alle Provider immer alles anbieten, was technisch möglich wäre. Während in Deutschland ISDN sehr verbreitet ist, kennt in den USA diese Technik im Heimbereich praktisch niemand, sie wird noch nicht einmal angeboten, außer in ganz wenigen Fällen. Weitere Rahmenbedingungen sind rechtlicher Natur. Bei Internet-VPNs finden in der Regel bestimmte Verschlüsselungstechnologien Anwendung. In bestimmten Regionen unserer Erde darf man solche Produkte aber überhaupt nicht einsetzen; in anderen Ländern sind nur Produkte mit so genannter schwacher Verschlüsselung erlaubt. Wiederum andere Länder beschränken den Export solcher Systeme. In Deutschland fällt die Ausfuhr starker Verschlüsselungssysteme beispielsweise unter das Kriegswaffen-Kontrollgesetz. 12.000 10.000
IP-VPN (US) IP-VPN (Rest) IP-VPN (Global) 2.000
1998
1999
2000
2001
2002
2003
Total global IP-VPN service revenue $US m
Abbildung 1.5: Eine Prognose zur weltweiten Marktentwicklung von IP-VPNs
27
1 Virtuelle private Netzwerke
Auch die Zukunft von VPNs, die auch Sprache übertragen können, ist noch nicht geklärt! Die heutige öffentliche Sprachkommunikation darf nach einer richterlichen Genehmigung von den Strafverfolgungsbehörden abgehört werden – das ist in allen Ländern gang und gäbe. Die Telekommunikationsunternehmen stellen die dafür notwendigen Schnittstellen zur Verfügung. Was wird aber, wenn Sprachdaten zunehmend über Internet-VPNs übertragen werden, und die IP-Pakete durch den Einsatz von starker Verschlüsselung vor jedem Abhören geschützt sind? Wie lange bleibt der Gesetzgeber dabei untätig?
1.5
Der VPN-Markt
Der VPN-Markt ist augenblicklich ein sehr dynamischer Markt. In den USA begann vor etwa drei Jahren ein regelrechter Boom im Bereich der InternetVPNs. Dort schoss eine Reihe kleiner Startup-Unternehmen aus dem Boden, die sich auf reine IP-VPN-Technologie konzentrierten und die erste reine VPN-Hard- und -Software entwickelten. Auch die Großen der Netzwerkbranche reagierten, wie heutzutage üblich, durch die Übernahme einiger dieser Firmen und die Integration von deren Produkten in das eigene Produktportfolio. Dies erschwert leider auch die Auswahl eines Herstellers, da die Zukunft etlicher Firmen und ihrer Produkte nur sehr schwer vorherzusagen ist. Dieses Problem wird noch dadurch verschärft, dass ausgerechnet die kleinen Unternehmen oft die interessantesten und besten Produkte haben. Nicht selten wurden solche Unternehmen von Mitarbeitern großer Firmen gegründet, die ihre Ideen an ihrem alten Arbeitsplatz nicht verwirklichen konnten. Aus Frustration über die meist unvermeidliche Bürokratie und die langen, manchmal schwer nachvollziehbaren Entscheidungswege in Großunternehmen verließen sie ihre Arbeitgeber und gründeten mit anderen Leidensgenossen eine eigene Firma. Geldgeber, die ausreichend Kapital in solche Unternehmen stecken, finden sich in den USA recht problemlos, und die rechtlichen Rahmenbedingungen sind dort ebenfalls innovationsfreundlicher als zum Beispiel in Deutschland. In solchen kleinen Firmen, in der Atmosphäre eines High-Tech-Startups und mit der hohen Motivation ihrer Mitarbeiter, die alle an ihre Ideen glauben, wurden in den letzten Jahren die wichtigsten Technologien und Systeme im Bereich der IP-VPNs entwickelt. Auch in Deutschland begann sich im Jahre 1999 der Internet-VPN-Markt sehr positiv zu entwickeln. Aufgrund des rasanten Wachstums des Internets und des wachsenden Bedarfs von Unternehmen an internationaler, breitbandiger Weitverkehrskommunikation sagen die Analysten sogar ein noch viel stärkeres Marktwachstum voraus. Wie fast alle Entwicklungen, die hauptsächlich in den USA entstanden, war auch diese Technologie erst ein bis zwei Jahre später nach Deutschland gekommen. Dies hing mit einer ganzen Reihe von ungünstigen Faktoren zusammen,
28
Der VPN-Markt
vor allem mit der späten Liberalisierung des Telekommunikationsmarktes, einer gewissen Abwartehaltung der potenziellen Anwender und der ärgerlichen Tendenz einiger Carrier und Service Provider, ihre herkömmlichen WAN-Systeme und Dienstleistungen, in die sie einiges für Entwicklung und Anschaffung investiert hatten, erst einmal weiter zu vermarkten und das Thema VPN am besten gar nicht zu erwähnen. Die Fachliteratur hatte sich auch weitgehend zu dem Thema ausgeschwiegen, und auch in Fachpresse wurde dem Thema lange Zeit eher eine Nischenposition zugewiesen. Selbst die Hersteller hatten es nicht eilig, sich mit dieser Technologie zu befassen, da sie mit traditionellen Routern und Remote-Access-Konzentratoren einen um ein Vielfaches höheren Umsatz machen konnten als mit der vergleichbaren VPN-Technologie. Denn vom so genannten Straßenpreis ausgehend, musste ein Kunde für ein Remote-Access-System mit 1.000 gleichzeitigen analogen oder digitalen Einwählverbindungen etwa 450.000 DM in seine Hardware investieren, im Fall eines VPN-Konzentrators nur etwa 40.000 DM. So fehlte denn aufgrund fehlender Informationen auch lange Zeit der Druck vom Kunden, und das Thema wurde bei uns zu einem Spätstarter. Aber frei nach dem Motto »Lieber spät als nie« boomt der Markt mittlerweile auch in Deutschland, insbesondere im Bereich der Internet-VPNs. 8.000
Umsatz in Millio nen Dolla r
7.000 6.000 5.000 4.000 3.000 2.000 1.000 0 1998 1999
2000
2001
2002
2003 2004 2005
Fram e Relay IP-VPN
Abbildung 1.6: Ein Vergleich zwischen der prognostizierten Entwicklung von Frame-Relayund IP-VPNs (Quelle: The Yankee Group, 2000)
29
1 Virtuelle private Netzwerke
Die zukünftige Marktentwicklung für virtuelle private Netze wird von den Analysten durchweg als sehr positiv bewertet. Die Yankee Group prognostiziert ein Umsatzwachstum in diesem Markt von 260 Millionen US-Dollar (USD) im Jahr 1999 auf 6,8 Milliarden USD im Jahr 2005. Insgesamt wird der Trend beobachtet, dass immer mehr Unternehmen neue Investitionen eher in die VPN-Technologie als in traditionelle WAN-Lösungen tätigen. Die Gartner Group prognostiziert (in der Network World, 13. Januar 2000) ein Wachstum des Gesamtmarktes von heute 145 Milliarden auf über 7 Billionen US-Dollar im Jahr 2001. Hierin sind alle Umsätze, also Hardware, Software, Tarife und Dienstleistungen im Endkunden- und Service-Provider-Bereich, eingerechnet. Hinzu kommt, dass die Carrier und Service Provider IP-VPNs als Komplettlösung in ihr Angebotsportfolio aufgenommen haben und in diesem Bereich eine Reihe unterschiedlicher Lösungen offerieren. Diese reichen vom einfachen Internet-Zugriff bis hin zu Komplettlösungen inklusive Netzwerkmanagement. Es wird wohl in Zukunft immer mehr so aussehen, dass sich der Netzwerkplaner nicht mehr fragt, ob er die VPN-Technologie einsetzen soll, sondern wie.
1.6
IP-VPNs und das Internet
Auslöser für diese Entwicklung gibt es gleich mehrere. Nachdem sich das Internet endgültig von dem Begriff »free« im Sinne von »umsonst« verabschiedet hat und nachdem es aus dem universitären Bereich herausgelöst wurde und sich die Großen der Telekommunikation seiner angenommen haben, wird es in einem Maße ausgebaut, wie es vor einigen Jahren niemand vorausgesagt hätte Diese Entwicklung findet gleichzeitig in mehreren Bereichen statt: 왘 Die Zahl der so genannten Internetanschlüsse und damit gleichbedeutend
die Zahl der Endgeräte nimmt rasant zu. Es ist zwar noch lange nicht so, dass jeder Rechner auf der Welt einen Internetanschluss hat, aber bedingt durch ständig sinkende Kosten und den steigenden Mehrwert des Netzes nimmt ihre Zahl deutlich zu. 왘 Die Bandbreite des Internets wird der in Zukunft notwendigen Kapazität
angepasst. Im Augenblick gibt es sogar ein regelrechtes Bandbreiten-Überangebot, vor allem im Backbone-Bereich. Man darf sich hier durch das manchmal langsame World Wide Web nicht täuschen lassen. Dessen mitunter etwas dürftige Performance beruht meist auf völlig unterdimensionierten Serverfarmen ohne vernünftige Lastverteilung und auf einer zu schmalbandigen Anbindung an den Internet-Backbone. Mit der Netzgeschwindigkeit selbst hat dies meist nichts zu tun, aber nur diese interessiert bei der Planung eines Internet-VPNs. 왘 Die Verfügbarkeit des Internets für den Endkunden wird deutlich höher.
Dies liegt hauptsächlich daran, dass die Service Provider zunehmend durch so genannte SLAs (Service Level Agreement, eine Vereinbarung
30
IP-VPNs und das Internet
zwischen Service Provider und Endkunde über Dienstqualitäten wie Bandbreite und Verfügbarkeit) gezwungen werden, für den Betrieb ihrer Datennetze ähnliche Verfügbarkeitskriterien wie im Sprachvermittlungsbereich anzulegen. Hinzu kommen aktuelle Entwicklungen im Bereich CoS (Class-of-Service, Abstufung verschiedener Dienstqualitäten hinsichtlich Bandbreite, Verzögerung und Verfügbarkeit), mit denen die Service Provider die Schwäche des IPProtokolls in diesem Bereich kompensieren sollen. Dies alles deutet darauf hin, dass das zukünftige Internet ein weltweit verfügbares IP-Netzwerk mit einer hohen, skalierbaren Bandbreite, in Grenzen deterministischen Verzögerungszeiten, einer hohen Verfügbarkeit und einer Vielzahl unterschiedlicher Zugangstechnologien sein wird. 30%
Intranet
34%
Remote Access 20%
Extranet Access
14%
E-Commerce Anderes
2% 0%
10%
20%
30%
40%
Abbildung 1.7: Der Remote Access steht nach wie vor an der Spitze der beliebtesten VPN-Anwendungen. (Quelle: Telechoice, 1999)
Obwohl sich das alles auf den ersten Blick sehr positiv anhört, muss man, zumindest heute und in näherer Zukunft, noch einige Einschränkungen machen. Dies hängt mit der Struktur und der augenblicklich eingesetzten Technologie des Internets zusammen. Das Internet basiert auf dem IP-Protokollstandard und den ganzen anderen damit zusammenhängenden RFCs (Request for Comment, Standards im Internetbereich), die teilweise schon einige Jahre auf dem Buckel haben und unter anderen technischen, gesellschaftlichen und kommerziellen Rahmenbedingungen entwickelt wurden, als heute vorliegen. Wie Sie wahrscheinlich wissen, liegt der Ursprung des IP-Protokolls im militärischen Bereich. Die ARPA (Advanced Research Projects Agency, eine Abteilung des US-Verteidigungsministeriums) entwickelte bereits 1969 ein Netzwerkprotokoll, das Datenpakete zwischen räumlich weit verteilten Rechnern sicher und schnell, auch bei Zerstörung einzelner Übertragungsknoten, transportieren sollte. Das Ergebnis war das TCP/IP-Protokoll. Mit diesem Protokoll wurden dann in den USA auch Behörden- und Wissenschaftsnetze aufgebaut, und es fand seinen Weg in eine breite Öffentlichkeit vor allem über den univer-
31
1 Virtuelle private Netzwerke
sitären Bereich. Obwohl es als Weitverkehrsprotokoll konzipiert wurde, war es auch im LAN-Bereich einsetzbar und wurde in Betriebssysteme wie Unix, Windows und schließlich auch Novell integriert. Aber heutige Applikationen benötigen nicht selten Features, die die IP-Protokolle in ihrer jetzigen Form noch nicht bieten oder die noch nicht flächendeckend im Internet eingesetzt werden. So ist es zum Beispiel heute technisch noch nicht möglich, im Internet eine bestimmte Bandbreite oder Verzögerungszeit zu garantieren. Obwohl dies einige Service Provider in ihren SLAs tun, besitzen sie überhaupt noch nicht die technischen Möglichkeiten dazu, sie hoffen meist einfach, dass es schon klappen wird oder dass man sie nicht erwischt. Außerdem ist die Verfügbarkeit des Internets immer noch ein äußerst kritischer Punkt, da etliche kleinere und mittlere Vermittlungsknoten immer noch mit Routern betrieben werden, die ursprünglich für den Einsatz in Unternehmensnetzen entwickelt wurden und deren Ausfallsicherheit nicht den im Carrier-Umfeld üblichen Maßstäben entspricht. Wenn man sich die Struktur des Internets einmal anschaut, kann man es grundsätzlich in drei unterschiedliche Bereiche gliedern, die vom Backbonebis zum Access-Bereich abgestuft sind (siehe Abbildung 1.8). Im AccessBereich sind IP-Endgeräte zu finden, also Endgeräte wie PCs, Unix-Workstations, VPN-Gateways und Access-Router. Der Internet-Backbone dient ausschließlich dazu, mehrere Netze miteinander zu verbinden. Nationaler ISP
Nationaler ISP
NAP
Regionaler ISP
NAP
Nationaler ISP
Regionaler ISP
Regionaler ISP
Enduser
Lokaler ISP
Enduser
Enduser
Lokaler ISP
Enduser
Lokaler ISP
Enduser
Enduser
Lokaler ISP
Enduser
NAP: Network Access Point Zusätzlich mögliche Verbindungen
Abbildung 1.8: Die Struktur des Internets und die verschiedenen Arten von Internet Service Providern
32
Entwicklungen und Ausblicke
Aufgrund dieser Unterscheidung gibt es auch drei Klassen von ISPs (Internet Service Provider, eine Organisation, die Dienste wie den Zugriff auf das Internet, E-Mail usw. zur Verfügung stellt), und zwar solche, die nur einen Teil des Backbone betreiben, solche, die nur die Access-Technologie bereitstellen, und solche, die beides machen, über deren Infrastruktur sowohl ein Teil des Internet-Backbone-Verkehrs transportiert wird als auch Zugriffsdienste für Endanwender bereitgestellt werden.
1.7
Entwicklungen und Ausblicke
Nach alldem sieht die Zukunft von virtuellen privaten Netzwerken sehr rosig aus. Die wichtigsten Rahmenbedingungen stimmen, die Technologie ist verfügbar, ebenso eine Auswahl der verschiedensten öffentlichen Netze, und die potenziellen Kunden haben die Idee der VPNs angenommen. Nun stellt sich die Frage, welche Art von VPN man einsetzen soll. Was ist am besten geeignet? Was ist zukunftssicher? Was ist am kostengünstigsten? Diese Fragen lassen sich einfach beantworten, denn es gibt praktisch keine Alternative mehr zu einem IP-VPN. Das Internet-Protokoll, so alt es auch sein mag, ist das Netzwerkprotokoll der Zukunft. Es wird alle anderen, noch übrig gebliebenen Netzwerkprotokolle verdrängen. Man muss sich nur einmal die aktuellen Projekte der IETF (Internet Engineering Task Force, dem Gremium zur Entwicklung und Verabschiedung von Internet-Standards) anschauen, dann weiß man, wohin der Internet-Zug fährt. Es wird in Zukunft möglich sein, über das Internet unternehmenskritische Applikationen zu betreiben, Geschäfte abzuwickeln, vertrauliche Informationen zu übertragen und auch zu telefonieren. Wer jetzt sein VPN aufbaut und gewisse Anforderungen hat, die augenblicklich nur über ATM oder Frame Relay zu erfüllen sind, hat trotzdem noch alle Optionen. Denn der Einsatz solcher Netze verbietet nicht den Einsatz von IP als Netzwerkprotokoll. Wenn man sein Netzwerk-Design dementsprechend gestaltet, ist eine spätere Migration kein großer Aufwand mehr und zieht vor allem keinen Bruch in der privaten Netzwerkstruktur nach sich. Die zukünftige Entwicklung im Internet wird vor allem im Bereich der Erhöhung der Bandbreite und der Verfügbarkeit sowie der durchgehenden Implementierung von Bandbreitenmanagement und verschiedenen Dienstqualitäten stattfinden. Die Geschwindigkeiten, die man in Zukunft benötigt, werden mit optischen Übertragungstechnologien erzielt werden. Neueste Entwicklungen wie DWDM (Dense Wave Division Multiplexing, die gleichzeitige Übertragung von mehreren Lichtfarben über eine Glasfaser) vervielfachen die Übertragungskapazitäten von existierenden Glasfaserverbindungen. Aufholverstärker, die bisher elektro-
33
1 Virtuelle private Netzwerke
nisch arbeiteten, also Licht in Elektrizität umwandelten, diese verstärkten und die Elektrizität wieder in Licht umwandelten, werden durch rein optische Verstärker ersetzt, die mit extrem hohen Bandbreiten und minimalster Verzögerung arbeiten. Router dringen in die Dimension von mehreren Tbit/s (1 Terabit = 1.000.000.000.000 Bit) vor; die allerneuesten Entwicklungen gehen in Richtung optischer Router. Hierbei werden die Lichtsignale nicht mehr in Elektrizität umgewandelt und mit herkömmlicher elektronischer Routertechnologie verarbeitet, sondern über mikroskopisch kleine Spiegel (MEM, Micro Electronic Mirror) blitzschnell in den richtigen optischen Pfad weitergeleitet. Mittlerweile laufen Untersuchungen und Entwicklungen, auch verschiedene Dienstklassen oder virtuelle Pfade auf bestimmte Lichtfarben abzubilden und auf diese Weise in ganz neue Dimensionen vorzustoßen. Im Zuge dieser Entwicklungen wird auch die Paketverzögerung im Internet immer geringer. Diese hängt von der Anzahl der verschiedenen Netzknoten und von deren jeweiliger Verarbeitungsgeschwindigkeit ab. Je schneller diese Knoten sind und je weniger Knoten insgesamt durchlaufen werden, desto besser wird dieser Wert. Vor allem die neuen rein optischen Verstärker eliminieren die Verzögerungen, die durch die zweifache Medienkonvertierung in herkömmlichen opto-elektronischen Systemen nicht vermeidbar sind. An der Verfügbarkeit des Internets wird ebenfalls fleißig gearbeitet. Da zunehmend Hersteller am weiteren Auf- und Ausbau beteiligt sind, die teilweise schon seit über hundert Jahren im Telefongeschäft tätig sind und deren Hauptkriterium daher schon immer Ausfallsicherheit war, sind auch hier positive Entwicklungen festzustellen. Dass das Internet insgesamt einmal eine Verfügbarkeit von 99,999% haben wird, ist natürlich noch Zukunftsmusik. Dies liegt daran, dass es genau genommen »das Internet« nicht gibt. Es ist vielmehr ein Zusammenschluss von vielen Zugangs- und Backbone-Netzen verschiedenster Betreiber, in denen die unterschiedlichsten Technologien eingesetzt werden. Aber zumindest im Backbone-Bereich und zunehmend auch im AccessBereich ist die Verfügbarkeit des Netzes ein Thema geworden, das die Kunden auch in den Verträgen mit den Providern festlegen wollen. Auch im Access-Bereich sind die Weichen auf Geschwindigkeit gestellt. Die 64 Kbit/s eines ISDN-B-Kanals reichen den meisten Anwendern und Anwendungen oft schon nicht mehr aus. Neue, schnellere Zugriffstechniken wie die drahtgebundene DSL-Technologie oder neue drahtlose Verfahren bieten Bandbreiten von mehreren hundert Kbit/s bis zu einigen Mbit/s. Glücklicherweise ist der Kostenverlauf der Tarife umgekehrt proportional zu den angebotenen Geschwindigkeiten, so dass auch im Bereich der Heimbüros oder kleinen Niederlassungen zu niedrigen Kosten ein Vielfaches der bisherigen Bandbreiten zur Verfügung steht. Laut einer Studie von Forrester Research vom Mai 2000 wird erwartet, dass, trotz des momentan extrem schleppenden Anlaufs in Deutschland, im Jahr 2005 etwa jeder vierte Haushalt, also etwas über neun Millionen Haushalte, in Deutschland über einen Breitbandanschluss verfügt (siehe Abbildung 1.9). 34
Entwicklungen und Ausblicke
10.000 9.000
Angaben in Tausend
8.000 7.000 6.000 5.000 4.000 3.000 2.000 1.000 0 1999
2000
2001
2002
2003 2004 2005
Abbildung 1.9: Die prognostizierte Entwicklung der Breitbandanschlüsse in Deutschland (Quelle: Forrester Research, 2000)
35
2
VPN-Typen
Bei VPNs unterscheidet man, abhängig vom Einsatzgebiet, zwischen verschiedenen Arten, wobei diese durchaus auch miteinander kombiniert werden können. Die unterschiedlichen Arten von VPNs lehnen sich dabei stark an ihre korrespondierenden klassischen Netzwerkstrukturen an.
2.1
Remote-Access-VPN
Ein Remote-Access-VPN ermöglicht es, von entfernten Systemen aus auf ein Unternehmensnetz zuzugreifen. Auf herkömmliche Weise erreicht man dies durch den Einsatz von RACs im Unternehmensnetz. Ein RAC (Remote Access Concentrator) ist ein System, das an öffentliche Telefonnetze angeschlossen wird und die analoge oder digitale Einwahl in diese Netze ermöglicht. Standard-RACs terminieren Verbindungen unterschiedlicher Natur, wie zum Beispiel ISDN oder analoge Rufe über Modems. Sie werden in der Regel, je nach Anzahl der maximal gleichzeitig zu terminierenden Verbindungen, über einen oder mehrere Primärmultiplexanschlüsse mit dem Telefonnetz verbunden. Diese Primärmultiplexanschlüsse (PMX), in Deutschland als S2M-Anschluss bezeichnet, sind eine digitale, strukturierte 4-Draht-Verbindung mit einer Bandbreite von 2,048 Mbit/s. Sie besteht aus 30 Nutzdatenkanälen, einem Signalisierungskanal und einem Steuerungskanal, kann also gleichzeitig maximal 30 Wählverbindungen betreiben.
Analog
ISDNBRI
ISDN PSTN GSM
S2M
Intranet
RemoteAccessKonzentrator
GSMV .110
Abbildung 2.1: Der Remote-Access-Konzentrator muss Verbindungen mit unterschiedlicher Technologie terminieren.
37
2 VPN-Typen
Die RACs müssen technisch dafür ausgelegt sein, alle vorkommenden analogen und digitalen Protokolle verarbeiten zu können. In heutigen Systemen müssen Modemprotokolle wie V.90, V.34, V34+ und manchmal auch noch X.2 oder k56flex implementiert werden. Im digitalen Bereich müssen sowohl synchrones ISDN als auch asynchrone Varianten wie V.120 und, vor allem wenn eine Einwahl aus einem GSM-Netzwerk unterstützt werden soll, auch das V.110-Protokoll implementiert werden. In der Regel sollen auch noch alle Dienste unter einer einzigen Rufnummer erreichbar sein und erst im RAC unterschieden werden. Dies macht heutige Remote-Access-Konzentratoren technisch sehr komplex und damit auch meist sehr teuer. Weiterhin müssen solche Geräte auch skalierbar sein, da die Anzahl der benötigten Ports in der Regel stetig wächst. Skalierbarkeit bedeutet in diesem Kontext nicht nur, dass eine ausreichend große Anzahl von Einwahlports verfügbar sein muss, sondern auch, dass die interne Verarbeitungskapazität und die Anbindung an das Intranet ebenfalls mitwachsen müssen, andernfalls entsteht zunehmend ein Performance-Engpass. Somit sieht man sich mit einer Reihe von Anforderungen und den damit verbundenen Kosten konfrontiert, die einen Remote-Access-Dienst üblicherweise sehr kostenintensiv machen: 왘 Man muss eine relativ teure Technologie zum Terminieren der verschie-
denartigen Verbindungen aus dem öffentlichen Telefonnetz beschaffen und warten. 왘 Die Technologie muss ständig an neue technische Gegebenheiten und
wachsende Kapazitäten angepasst werden. 왘 Man zahlt eine vergleichsweise hohe Grundgebühr für die benötigten Pri-
märmultiplexanschlüsse. 왘 Die Verbindungsgebühren sind ebenfalls hoch, insbesondere wenn häufig
Verbindungen im Fernbereich oder gar internationale Verbindungen benötigt werden. 왘 Andere Dienste wie DSL (Digital Subscriber Line, Datenübertragung mit
sehr hoher Geschwindigkeit über Standardtelefonleitungen) oder Kabelmodems, die Daten über Breitband-Fernsehkabel übertragen, sind mit RACs nicht zu verarbeiten und erfordern zusätzlichen technischen Aufwand. Ein Remote-Access-VPN befasst sich mit genau diesen kritischen Faktoren, die einen Remote-Access-Dienst sehr teuer und aufwendig machen können. Sein Ziel ist es, die Hardware zum Terminieren der Verbindungen kostengünstig und einfach zu halten und die Verbindungsgebühren zu minimieren. Ein Remote-Access-VPN besteht aus einem VPN-Konzentrator, der die virtuellen Remote-Access-Verbindungen terminiert, und Software-Clients, die auf den entfernten Rechnern installiert werden, um die Verbindungen aufzu38
Remote-Access-VPN
bauen. In seltenen Fällen werden die Verbindungen auch erst im RAC des Internet Service Providers initiiert, so dass in diesem Fall auf dem Endgerät keine spezielle Clientsoftware notwendig ist. Eine detaillierte Diskussion der Vor- und Nachteile dieser beiden Varianten finden Sie in Kapitel 6. An dieser Stelle sei aber schon festgestellt, dass die erstgenannte Variante, die mit der speziellen VPN-Clientsoftware, mittlerweile sehr verbreitet ist. Der VPNKonzentrator terminiert also nur logische Verbindungen, so genannte Tunnel. Die Anbindung zu einem Internet Service Provider erfolgt meist per LANInterface an einem Access-Router, den der Provider zur Verfügung stellt und betreibt, oder in Ausnahmefällen über die WAN-Schnittstelle eines KundenRouters direkt zum Provider. Die Clients können sich mit beliebigen Übertragungstechnologien mit einem Service Provider verbinden. Ob man Modems, ISDN, DSL oder Kabelmodems einsetzt, hängt lediglich davon ab, welche Zugangstechnologie die lokalen Service Provider in den jeweiligen Regionen anbieten. Der Endkunde selbst braucht kein zentrales Equipment zur Terminierung dieser Verbindungen mehr bereitzuhalten, dies erledigen die Service Provider. Der Kunde terminiert nur so genannte Tunnel, die vom Provider zu seinem VPN-Konzentrator aufgebaut werden. Auch eine steigende Anzahl von Benutzern ist damit zum Problem der ISPs geworden, die andererseits aber auch ein vitales Interesse daran haben, dass genügend Ports zur Verfügung stehen. Denn wer sich nicht bei einem Service Provider einwählen kann, der beschert ihm auch keinen Umsatz.
Analog
ISDN BRI
VPNKonzentrator
Internet
Intranet
Breitband-Kabel
DSL
GSM V.110
Abbildung 2.2: Der VPN-Konzentrator terminiert nur eine IP-Verbindung, die Einwahl der Clients erfolgt bei den Internet Service Providern.
39
2 VPN-Typen
Bei den Gebühren ergeben sich mit einem Remote-Access-VPN erhebliche Kostenvorteile, insbesondere bei einer großen Flächendeckung oder bei internationalem Einsatz. Man baut nämlich keine Telefonverbindung vom Endgerät zu einem zentralen RAC im Unternehmensnetz mehr auf, sondern nur noch eine Telefonverbindung zum nächstgelegenen RAC eines Internet Service Providers – und dies meist zum Ortstarif oder zu speziellen Billigtarifen. In einigen Ländern sind Ortsgespräche umsonst, beziehungsweise bereits in der Grundgebühr des Anschlusses enthalten, ansonsten sind sie in der Regel recht preiswert. Auf jeden Fall sind sie aber billiger als die Gebühren für Ferngespräche oder internationale Verbindungen. Bei Kostenvergleichen, die auf Anschlussgebühren, zeitabhängigen Tarifen, Entfernungszonen und Verbindungszeiten basieren, kann man Einsparungen im Bereich von 70 bis 80% erzielen. Bei den Gesamtsummen, die viele Unternehmen pro Jahr für normalen Remote Access ausgeben, ist dies ein erhebliches Einsparpotenzial.
Router A
Standardfestverbindungen
Router C
Intranet
Intranet
Was hierbei nicht mit kalkuliert wurde, sind versteckte oder nicht deterministische Kosten wie Administration, Implementierung neuer Technologien, neue Gebührenmodelle usw.
Router B
Intranet Abbildung 2.3: Die drei Standorte sind hier mit Festverbindungen redundant verbunden.
Ein weiterer wichtiger Punkt, den man beachten sollte, ist der deutlich geringere Port-Preis eines VPN-Konzentrators im Vergleich zu einem RAC. Ab einer Portzahl von einigen tausend Ports kostet ein VPN-Port bei einigen Herstellern weniger als 5% eines Remote-Access-Ports! Der Grund für diesen krassen Preisunterschied liegt darin, dass VPN-Konzentratoren nicht eine Vielzahl von Technologien, wie Telefonsignalisierung, Modemprotokolle, Analogverarbeitung usw., implementieren müssen und daher von der Hardwarearchitektur vergleichsweise einfach aufzubauen sind. Es gibt Hersteller, die sogar Standard-PC-Architekturen mit Windows oder Unix als VPN-Konzentratoren benutzen, also überhaupt keine Hardware-Entwicklungskosten haben.
40
Branch-Office-VPN
Beim Einsatz einer VPN-Technologie, bei der die virtuelle Verbindung auf dem Client initiiert wird, ist man auch völlig unabhängig vom Internet Service Provider. Man kann ihn jederzeit wechseln oder auch problemlos mehrere ISPs gleichzeitig benutzen. Denn der Service Provider ist dann in keiner Weise mehr in die Funktion des VPN involviert, er terminiert lediglich Telefonanrufe und Festverbindungen und überträgt IP-Pakete zwischen Endgeräten und VPN-Konzentratoren.
2.2
Branch-Office-VPN
Branch-Office-VPNs ersetzen die herkömmlichen WAN-Verbindungen, mit denen man verschiedene Standorte oder Netzwerke in diesen Standorten miteinander verbindet. Der Begriff Branch-Office-VPN hat sich mittlerweile weitgehend für diesen VPN-Typ durchgesetzt, gelegentlich spricht man auch von Site-to-Site-VPNs. Warum besteht überhaupt eine Notwendigkeit, bisherige Weitverkehrsnetze, die mit verbreiteten Technologien wie Standardfestverbindungen, Frame Relay oder ATM eingerichtet wurden, durch ein VPN zu ersetzen? Auch hier gibt es einen Hauptgrund, nämlich die hohen Kosten durch die relativ hohen Verbindungsgebühren. Ganz besonders dramatisch sind die Kosten, wenn die zu verbindenden Standorte sehr weit voneinander entfernt oder gar im Ausland liegen. Je nach Anzahl, Entfernung, benötigter Bandbreite und zu übertragender Datenmenge kommen da schnell sehr hohe Kosten zusammen. Tendenzen wie die Globalisierung, internationale Fusionen und Kooperationen sowie die ganzen neuen, so genannten E-Technologien (E-Business, E-Commerce usw.) führen dazu, dass die Kosten für die benötigte Datenkommunikation immer weiter in die Höhe schnellen. Der steigende Kostendruck zwingt auch im Weitverkehrsbereich immer mehr Unternehmen dazu, ihre eingesetzte WAN-Technologie neu zu überdenken und gegebenenfalls zu ändern, um konkurrenzfähig bleiben zu können. Als Ausweg aus dem Kostendilemma bieten sich zunehmend Branch-OfficeVPNs an (siehe Abbildung 2.4). Der Faktor, um den die Übertragungskosten reduziert werden können, hängt im Wesentlichen von folgenden Faktoren ab: der Entfernung zwischen den Systemen, der übertragenen Datenmenge und der eingesetzten Technologie und Geschwindigkeit. Eingreifen kann eine VPN-Lösung hauptsächlich beim ersten Faktor, nämlich bei der Entfernung zwischen den Standorten. Diese bleibt geografisch gesehen zwar nach wie vor bestehen, aber die kostenintensiven, direkten Verbindungen (Standardfestverbindung, Frame-Relay-PVC usw.) zwischen den privaten Netzen werden durch zwei sehr kurze Verbindungen zwischen den Standorten und den Zugangsknoten eines Internet Service Providers ersetzt. Die verbleibende Strecke zwischen diesen beiden POPs (Point of Presence, Zugangsknoten zum Internet) wird vom Internet überbrückt, über das die Datenpakete sehr kostengünstig übertragen werden können.
41
VPNGateway
VPNGateway
Internet
Intranet
Intranet
2 VPN-Typen
VPNGateway
Intranet
Virtuelle Verbindung (Tunnel)
Abbildung 2.4: Ein Branch-Office-VPN verbindet die drei Standorte redundant durch virtuelle Verbindungen (Tunnel) über das Internet.
Das Einsparpotenzial ist hier nicht ganz so hoch wie bei Remote-AccessVPNs, es ist jedoch durchaus möglich, die Gebühren um bis zu 50% zu reduzieren, im internationalen Bereich sogar um noch mehr.
2.3
Extranet-VPN
Ein Extranet-VPN sieht von seiner Struktur her ähnlich aus wie ein RemoteAccess- oder Branch-Office-VPN oder eine Kombination von beiden (siehe Abbildung 2.5). Der fundamentale Unterschied zu den beiden zuvor besprochenen VPNs liegt in der Natur der Teilnehmer. Ein VPN bildet ein rein privates Netzwerk ab, auf das nur Angehörige der eigenen Firma oder Organisation Zugriff haben und das nur eigene Standorte miteinander verbindet. Ein Extranet-VPN hingegen öffnet das private Netzwerk auch für externe Personen oder Organisationen und gewährt diesen (einen meist limitierten und kontrollierten) Zugriff auf Ressourcen im Unternehmensnetzwerk. Extranet-VPNs werden also auf der Basis der normalen VPN-Technologie aufgebaut, aber die Datenpakete stammen nicht von eigenen Mitarbeitern und müssen deshalb gesondert behandelt werden. Dies kann entweder das VPNGateway selbst tun, oder man übergibt die Pakete einem speziell dafür ausgelegten System, meist einer Firewall. In dem Beispiel in Abbildung 2.5 werden die Verbindungen zu eigenen Mitarbeitern im Intranet terminiert, die Verbindungen von der Partnerfirma jedoch auf einer Firewall. Für den eigent-
42
VPN-Service-Provider
VPNGateway
VPNGateway
Internet
VPN Gateway
Intranet
Intranet
lichen Datentransport wird das VPN benutzt. Die Firewall ist für die besondere Behandlung der Extranet-Datenpakete zuständig, also für die dynamische, zustandsabhängige Filterung, für die Zugriffsbeschränkung, das Auditing und das Logging.
Firewall
FremdIntranet Virtuelle Verbindung (Tunnel)
Abbildung 2.5: Ein Extranet-VPN verbindet auch fremde Standorte oder Benutzer mit dem Intranet. Für diese Verbindungen sind spezielle Sicherheitsregeln anzuwenden.
In Abbildung 2.5 sehen Sie die typische Struktur, in der moderne VPN-Konzentratoren und Firewalls miteinander kombiniert werden. In seltenen Fällen missbraucht man auch VPN-Konzentratoren als Firewalls und umgekehrt, aber da beide Systeme eine völlig andere, ja sogar gegensätzliche Funktionalität aufweisen, vermeidet man dies in der Regel. In Kapitel 10 wird ausführlich auf die Kombinationsmöglichkeiten von VPN-Gateways und Firewalls eingegangen.
2.4
VPN-Service-Provider
Bei diesen Arten von VPNs, Remote Access, Branch Office und Extranet, hat man die Wahl, sein VPN selbst aufzubauen oder in verschieden starkem Maße so genannte VPN-Dienste von Service Providern oder Carriern zu benutzen. Das kann man in verschiedenen Abstufungen tun, je nachdem wie stark man sich an einen Provider binden will.
43
2 VPN-Typen
2.4.1
IP-VPN-Dienste
IP-VPNs arbeiten mit virtuellen IP-Verbindungen. Die Endpunkte dieser Verbindungen (Tunnel) sind die IP-Schnittstellen von Routern, VPN-Gateways oder VPN-Clientsystemen. Dies ermöglicht, wie Sie in Abbildung 2.6 sehen, sowohl einen VPN-Betrieb vollständig in Eigenregie, also ganz ohne Mitwirkung eines Providers, als auch ein vollständiges Outsourcing und alle möglichen Zwischenstufen.
VPNGateway
AccessRouter
Carrier
Internet
Carrier
AccessRouter
VPNGateway
ISP
Kunde
Kunde
Service Provider
Kunde
Service Provider Service Provider
Kunde Kunde
Kunde
Service Provider Kunde
Kunde
Abbildung 2.6: Die verschiedenen Stufen von IP-VPN-Diensten und der Grad der Beteiligung durch Kunde, Service Provider und Carrier.
Vollständiger Eigenbetrieb des VPN In diesem Fall ist der Service Provider in keiner Weise in den Betrieb des VPN involviert. Er stellt dem Kunden lediglich einen Internetzugang zur Verfügung. Der Kunde beschafft und betreibt seine Access-Router und VPN-Gateways selbst. Das User- und Gruppenmanagement, ebenso wie die Systemkonfigurationen, liegen im Verantwortungsbereich des Kunden. Die Nachteile dieser Lösung sind der relativ hohe Aufwand für den Kunden und die vielen verschiedenen Schnittstellen. Denn hier sind mindestens drei Organisationen beteiligt: Der Endkunde (Intranet und VPN), ein Carrier (Last-Mile-Übertragung) und ein Service Provider (Access-Router und Internetzugang). Bei Problemen kann es dabei zum allseits bekannten Hin- und Herschieben der Verantwortung kommen.
44
VPN-Service-Provider
Der Vorteil aus der Sicht des Kunden ist der, dass keine Bindung an einen Provider nötig ist und jederzeit zu einem anderen gewechselt werden kann. Access-Equipment-Outsourcing In diesem Fall wird vom Service Provider ein etwas größeres Leistungspaket gekauft, denn er ist in dieser Variante für die vollständige Kommunikation zwischen seiner Infrastruktur und einem fest definierten Punkt, meist dem LAN-Interface seines Access-Routers, verantwortlich. Der Kunde beschafft und betreibt lediglich seine VPN-Gateways, die über einen LAN-Anschluss mit den Access-Routern des Service Providers verbunden werden. Somit ist der Nachteil der vielen Schnittstellen für den Kunden entschärft, denn er hat nur noch einen Ansprechpartner, seinen Service Provider, falls die Weitverkehrsverbindung nicht funktioniert. Seine Vorteile bleiben auch noch weitgehend bestehen, ein Wechsel ist auch hier nicht so kompliziert. In diesem Modell ist der Service Provider in keiner Weise in den VPN-Betrieb involviert. VPN- und Access-Equipment-Outsourcing Dies ändert sich jedoch mit dieser Variante. Hier werden neben den AccessRoutern und der Verbindungsinfrastruktur auch die VPN-Systeme vom Provider gestellt. Der Zugriff auf die VPN-Systeme durch den Service Provider beschränkt sich jedoch auf die reine Systemkonfiguration. Das VPN-Management, also die Konfiguration von Tunneln, Sicherheitseinstellungen, Gruppen, Benutzern usw. obliegt ausschließlich dem Kunden. Dies erfordert aber unbedingt VPN-Gateways, die ein spezielles SplitManagement ermöglichen, das diese beiden Funktionen sauber trennen kann. Big Brother Dies hat auch vor allem rechtliche Gründe. Denn in Deutschland sind Carrier und Service Provider verpflichtet, in ihren Kommunikationsnetzen den Ermittlungsbehörden im Bedarfsfall, der allerdings eine richterliche Genehmigung bedingt, eine technische Möglichkeit zum Abhören (Lauschangriff) zur Verfügung zu stellen. In Internet-VPNs wird jedoch aus Sicherheitsgründen fast ausschließlich IP Security (IPSec) mit starker Verschlüsselung eingesetzt. Wie Sie in Kapitel 7 und 8 erfahren, ist IPSec jedoch so zu implementieren, dass weder eine Schlüsselhinterlegung noch eine Schlüsselrückgewinnung möglich ist. Demnach kann ein Service Provider oder Carrier Abhörmaßnahmen nur dadurch ermöglichen, dass er die IPSec-Verschlüsselung ganz abschaltet, indem er die Sicherheitsstrategie im VPN-Gateway entsprechend ändert.
45
2 VPN-Typen
Da ein Abhören aber nur dann Sinn macht, wenn der Abgehörte nichts darüber weiß, darf der Service Provider seinen Kunden auch nicht darüber informieren – und kommt damit in Teufels Küche, denn die Pakete, die dann ja alle unverschlüsselt durch das Internet transportiert werden, können dadurch auch von anderen, nicht berechtigten Personen abgehört werden. Das Split-Management ist ein möglicher Ausweg aus diesem Dilemma. Denn Endanwender, also Firmen oder Privatpersonen, dürfen, zumindest in Deutschland, nach Belieben verschlüsseln. Auf diese Weise kann der Service Provider oder Carrier dem Kunden ein VPN-Gateway zur Verfügung stellen und teilweise auch managen; der Kunde hat jedoch ein anderes Management-Interface und kann seine Benutzer, Gruppen und Tunnel mit der geeigneten Verschlüsselung konfigurieren. Vollständiges VPN-Outsourcing Dieses Modell ist für den Kunden mit dem geringsten Aufwand verknüpft, denn der vollständige Betrieb des VPN wird vom Service Provider durchgeführt – inklusive der Benutzerverwaltung. Der Nachteil ist der, dass hier eine sehr starke Abhängigkeit vom Provider gegeben ist und ein Wechsel zu einem anderen Provider mit sehr hohem Aufwand verbunden ist. Außerdem behalten viele Kunden aus Sicherheitsgründen die Verwaltung ihrer Benutzer und die Einstellungen für die Verschlüsselungsstärke lieber in eigener Hand.
2.4.2
Layer-2-VPN-Dienste
Layer-2-VPNs werden fast ausschließlich dazu benutzt, virtuelle PPP-Verbindungen zu betreiben. Wie dies technisch umgesetzt wird, ist ausführlich in den Kapiteln 6 und 9 beschrieben. Der Sinn dieses Vorgehens besteht darin, seinen Einwähldienst nicht mehr selbst zu betreiben. Die Service Provider haben in der Regel eine gut ausgebaute Einwähl-Infrastruktur mit einer Vielzahl von POPs, in die sich Kunden zu sehr günstigen Tarifen einwählen können. Beim Layer-2-VPN werden in diesen POPs jedoch nur die Telefonverbindungen terminiert, die Datenverbindungen selbst werden zum VPN-Gateway des Kunden geführt (getunnelt). Der Vorteil für den Kunden ist vor allem der, dass er sehr viele Kosten einsparen kann, sowohl im Tarifbereich als auch beim Management. Statt teurer Remote-Access-Konzentratoren benötigt er nur ein dazu vergleichsweise kostengünstiges VPN-Gateway. Im unteren Teil von Abbildung 2.7 sehen Sie das Prinzip eines solchen Layer2-VPN-Dienstes. Die Remote-Access-Clients wählen sich in den POP eines Internet Service Providers ein. Sie geben dazu eine spezielle zweiteilige User-
46
Intranet-VPN
ID ein, von der ein Teil vom ISP ausgewertet wird, damit dieser erkennen kann, wohin die virtuelle Verbindung durch einen Tunnel zu führen ist. Der zweite Teil der User-ID dient dazu, den Benutzer im VPN-Gateway des Kunden zu authentifizieren.
Abbildung 2.7: Layer-2-VPN-Dienste werden meist für Remote-Access-VPNs eingesetzt.
Natürlich gibt es auch die Möglichkeit, Branch-Office-VPNs auf diese Weise aufzubauen. Hierbei werden statt der Wählverbindungen feste Verbindungen eingesetzt und die Tunnel in der Regel auch statisch konfiguriert.
2.5
Intranet-VPN
Ein Intranet-VPN ist ein spezielles VPN, das dem allgemeinen Begriff eines virtuellen privaten Netzwerks – nämlich der Verwendung eines öffentlichen Netzwerks zum Transport privater Daten – sogar ein wenig widerspricht. Hier werden nicht auf einem öffentlichen, sondern auf einem privaten, meist lokalen Netzwerk verschiedene logische Netzwerke auf der OSI-Ebene 2 (Sicherungsschicht) oder 3 (Vermittlungsschicht) abgebildet. Solch ein Konstrukt verwendet man meist, um bestimmte Gruppen oder Organisationsein-
47
2 VPN-Typen
heiten auf Netzwerkbasis voneinander zu trennen und ihnen eine »eigene« Netzwerkinfrastruktur zur Verfügung zu stellen. Dies kann man auf verschiedene Weise realisieren: 왘 VLANs 왘 VLANs nach IEEE802.1q 왘 IP-Tunneling
2.5.1
Virtual Local Area Network (VLAN)
Das VPN wird hierbei durch Erweiterungen der in lokalen Netzwerken (LAN) eingesetzten Switching-Technologien erzeugt. Die virtuellen Netzwerke werden auf der OSI-Schicht 2 abgebildet. Das LAN-Switching wurde ursprünglich eingeführt, um den Durchsatz in Shared-Media-Netzen wie dem Ethernet zu erhöhen, indem diese Netze in verschiedene, so genannte Collision Domains aufgeteilt werden. Die Switches verbinden diese Collision Domains, um die Pakete weiterzuleiten, die an Stationen in der gleichen Collision Domain in dem gleichen oder in einem anderen Switch adressiert sind. Die in den LAN-Switches eingesetzte Technologie geht nun noch einen Schritt weiter und erlaubt es dem Netzwerkadministrator, eine logische Gruppe von Geräten im gesamten lokalen Netzwerk zu definieren, die dann ein virtuelles LAN (VLAN) bilden. Dieses VLAN kann sich auch über mehrere Switches hinweg erstrecken. In der VLAN-Technologie werden keine speziellen Sicherheitstechnologien, wie Verschlüsselung, Integritätssicherung oder Paketauthentifizierung eingesetzt. Es erfolgt jeweils eine Trennung des Transports der Datenpakete auf der OSI-Schicht 2, und statt auf Sicherheit wurde bei dieser Technologie mehr auf Performance abgezielt. Die Erzeugung eines solchen virtuellen LANs kann je nach gewünschtem Einsatz auf verschiedene Weise erfolgen, woraus auch die Bezeichnung der jeweiligen Art des VLANs abgeleitet wird. Viele moderne Switch-Architekturen beherrschen alle Spielarten der VLAN-Technologie und können sogar routen. Ein so genannter Layer-3-Switch trifft seine Weiterleitungsentscheidungen extrem schnell und routet mit »wire speed«, mittlerweile auch im GigabitBereich. Protokollbasierende VLANs Bei VLANs, die auf Informationen der OSI-Schicht 3, also der Vermittlungsschicht, beruhen, spricht man von protokollbasierenden VLANs. Die Aufteilung der flachen LAN-Topologie in logische Gruppen erfolgt auf Basis von Kennzeichen, die aus den Informationen des Schicht-3-Headers gewonnen
48
Intranet-VPN
werden. Es können virtuelle Netze aufgrund des Typs der Protokolle (z.B. IP, IPX oder AppleTalk) unterschieden werden, oder man gruppiert auf Basis von IP-Subnetzen. PC9
PC1
PC2 PC3 PC4
PC6 PC7
PC10 PC11
1
1 2
2
3 PC5
Layer 2 Switch
Layer 2 Switch
4
PC12
3
Trunkverbindung
4
5
5
6
6
7
7
8
8
PC13 PC14 PC15
PC8
PC16 V-LAN-Mitgliedschaft
V-LAN 1
PC1
PC2
PC4
V-LAN 2
PC3
PC7
PC11 PC12
V-LAN 3
PC5
PC8
PC9
PC6
PC13
PC14
PC15
PC16
PC10
Abbildung 2.8: Ein VLAN, in dem die Zugehörigkeit zu einem virtuellen LAN von der Portnummer des Layer-2-Switchs abhängig ist.
Der Vorteil dieser Variante ist der, dass ein Gerät unabhängig von seiner MAC-Adresse (MAC, Media Access Control, Schicht-2-Adresse der Endstation) an mehreren VLANs partizipieren kann. Es besteht auch keine Notwendigkeit, spezielle VLAN-Informationen in den Header einzufügen (so genanntes Frame Tagging). Falls man eine Gruppierung auf Basis von IP-Subnetzen vornimmt, entfällt auch die in großen Netzen aufwendige Zuordnung jedes Endgerätes zu einem VLAN, da diese implizit durch den IP-Header erfolgt. Die Nachteile dieser Lösung sind unter anderem, dass die Auswertung der Layer-3-Informationen einiges an Performance verbraucht, dass man auf routbare Protokolle wie IP oder IPX angewiesen ist und dass der Einsatz zusammen mit DHCP (Dynamic Host Configuration Protocol, ein Verfahren, das Interface-Parameter wie IP-Adressen dynamisch beim Systemstart zuweist) in der Regel nicht möglich ist.
49
2 VPN-Typen
Portbasierende VLANs Bei diesem Ansatz werden die Gruppen auf der Basis von physikalischen Ports auf einem oder mehreren LAN-Switches definiert. Hierbei ordnet der Netzwerkadministrator manuell die Ports einem virtuellen LAN zu. Dies bedeutet auch, dass die VLANs völlig voneinander isoliert sind und nur auf der OSIEbene 3, also über einen Router, miteinander kommunizieren können. Üblicherweise kann ein Port nur einem einzigen VLAN zugeordnet werden, was auch einsichtig ist, denn es ist gemeinhin auch nicht möglich, einen Port gleichzeitig mehreren realen LANs zuzuweisen. Diese Art von VLAN ist relativ einfach zu verstehen und zu managen. Sie ist auf der anderen Seite aber mit einem gewissen Aufwand verbunden, da jeder Port manuell konfiguriert werden muss. Ein weiterer Nachteil tritt in Erscheinung, wenn ein Benutzer umzieht: Der Administrator muss dessen System auf dem Switch umkonfigurieren. MAC-Adressen-basierende VLANs Hier erfolgt die Zuordnung der Endgeräte zu einem VLAN aufgrund der MAC-Adresse des jeweiligen Systems. Der Administrator pflegt hierfür Tabellen, in denen die Zuordnungen von MAC-Adressen zu VLANs abgelegt sind. Die Ports der LAN-Switches werden dynamisch einem VLAN zugewiesen, sobald sie einen Frame erhalten haben, der die notwendigen Kriterien erfüllt. Vom Standpunkt der Sicherheit aus betrachtet, sind MAC-basierende VLANs die sicherste der drei Varianten, da es sehr schwer ist, eine MAC-Adresse zu »spoofen«. Unter Spoofing versteht man das Vortäuschen einer anderen Adresse. Der Hauptvorteil hierbei ist der, dass die Zugehörigkeit zu einem VLAN bestehen bleibt, auch wenn der Benutzer mit seinem Gerät umzieht, da die MAC-Adresse in seiner Netzwerkkarte fest konfiguriert ist. Allerdings weist diese Variante eine Reihe von Nachteilen auf, vor allem im Bereich der Switch-Performance auf bestimmten Ports, auf denen mehrere MAC-Adressen in verschiedenen VLANs vorkommen. Weiterhin muss das VLAN bei Austausch von Netzwerkkarten in den Endstationen rekonfiguriert werden.
2.5.2
VLANs nach IEEE802.1q
Der relative neue Standard IEEE802.1q definiert im Ethernet-Header unter anderem ein Feld (Tag-Feld), in dem eine so genannte VLAN-ID (VID) mit zwölf Bit Länge enthalten ist und das somit insgesamt 4096 verschiedene VLANs unterscheiden kann. Viel wichtiger in diesem Zusammenhang ist
50
Intranet-VPN
aber die Tatsache, dass die drei anderen VLAN-Varianten von Hersteller zu Hersteller unterschiedlich implementiert werden und dass nunmehr ein verbindlicher IEEE-Standard verabschiedet wurde. Somit kann ein VLAN auch mit Systemen unterschiedlicher Hersteller aufgebaut werden. 0
63
31 Ethernet-Präambel
Delim. Ethernet-
Ethernet-Zieladresse Quelladresse
Längen-/Typfeld
Datenfeld
IEEE802.3-Ethernet-Header 63
0 31 Ethernet-Präambel
Delim. Ethernet-
Ethernet-Zieladresse Quelladresse
Typfeld
Altes Längen-/ Typfeld
Tag-Feld
Datenfeld
IEEE802.1q-Ethernet-Header Tag-Feld Abbildung 2.9: Im IEEE802.1q-Standard ist der Ethernet-Header um vier Byte erweitert.
Ein Nachteil, der nicht bei VLANs auftritt, die auf Layer-3-Protokollinformationen basieren, ist der, dass die VLAN-Informationen beim Transport über Router verloren gehen. Eine Lösungsmöglichkeit wäre in diesem Fall der Einsatz der LAN-Emulation von ATM, da hierbei die Layer-2-Informationen erhalten bleiben. Ein Switch, der VLANs nach IEEE802.1.q unterstützt, kennt grundsätzlich drei Arten von Links: 왘 Trunks 왘 Access Links 왘 Hybrid Links
51
2 VPN-Typen
Trunks Auf diesen Ports werden Frames mit einem VLAN-Tag übertragen. Sie werden meist dazu benutzt, Switches miteinander zu verbinden. Access Links An diese Ports werden Systeme angeschlossen, die selbst kein IEEE802.1q unterstützen, zum Beispiel PCs, ältere Hubs usw. Die VLAN-ID wird eingehenden Frames erst im Switch zugewiesen. Bei ausgehenden Frames muss der Switch das Tag-Feld entfernen. Hybrid Links Da zunehmend mehr Endgeräte IEEE802.1q unterstützen werden, gibt es so genannte Hybrid Links, die sowohl Frames mit als auch ohne Tag-Feld verarbeiten können.
2.5.3
IP-Tunneling
Beim Einsatz der Tunneling-Technologie braucht man beim Aufbau seines VPNs die Netzwerkinfrastruktur, also Switches, Hubs usw., überhaupt nicht an die Gegebenheiten des geplanten virtuellen Netzwerks anzupassen. Hier wird ausschließlich auf der IP-Ebene gearbeitet, und es werden die gleichen Technologien und Systeme verwendet, die auch in »normalen« VPNs, also solchen, die öffentliche IP-Netze benutzen, zum Einsatz kommen.
52
3
Anforderungen an VPNs
Die Einsatzgebiete für virtuelle private Netzwerke sind sehr vielfältig. Je nach den gestellten Anforderungen an Sicherheit, Quality-of-Service sowie anderen Rahmenbedingungen kann man, entsprechend dem Angebot der Service Provider, die komplette Weitverkehrsinfrastruktur, die eigene Business-toBusiness-Kommunikation (B2B) und den Remote Access als virtuelles privates Netzwerk aufbauen. Bei der Auswahl der geeigneten Technologie muss man sehr genau untersuchen, welche Anforderungen an das VPN gestellt werden. In der Regel resultieren diese aus Sicherheitsbedürfnissen, gefolgt von Kostenaspekten, der Verfügbarkeit und – abhängig von den eingesetzten Applikationen – den benötigten Bandbreiten und tolerierbaren Verzögerungszeiten.
3.1
Sicherheit
Im Bereich der Datensicherheit gibt es eine ganze Reihe von Anforderungen, die sich in verschiedene Bereiche gliedern: 왘 Datenvertraulichkeit 왘 Schlüsselmanagement 왘 Paket-Authentifizierung 왘 Datenintegrität 왘 Benutzer-Authentifizierung 왘 Benutzer-Autorisierung 왘 Schutz vor Sabotage 왘 Schutz vor unerlaubtem Eindringen
3.1.1
Datenvertraulichkeit
Es muss sichergestellt werden, dass Unbefugte die Daten auf ihrem Weg durch das Internet nicht lesen können. Vielfach wird auch gefordert, dass das interne Netzwerk mit seinen Verkehrsbeziehungen (Quell- und Zieladressen, Protokoll- und Portnummern) ebenfalls nicht ausgespäht werden kann. Dies wird im allgemeinen durch die Ver-
53
3 Anforderungen an VPNs
schlüsselung der Paketdaten erreicht. Falls die Verkehrsbeziehungen ebenfalls geschützt werden sollen, muss das originale Paket vollständig in den Datenbereich eines neuen Pakets eingepackt werden. Dies nennt man Tunneling. Als Verschlüsselungsverfahren sollten unbedingt standardisierte, wohl bekannte Verfahren wie DES (Data Encryption Standard, ein standardisiertes, weltweit eingesetztes Verschlüsselungsverfahren) oder Triple-DES eingesetzt werden. Meist gibt die eingesetzte VPN-Technologie aus Gründen der Interoperabilität die Verfahren auch schon fest vor. In der Praxis werden wegen ihrer hohen Geschwindigkeit ausschließlich so genannte symmetrische Verfahren eingesetzt, bei denen Sender und Empfänger den gleichen Schlüssel zum Ver- und Entschlüsseln der Daten benötigen.
3.1.2
Schlüsselmanagement
Um auf sicherem und vor allem automatischem Wege eine Verteilung von symmetrischen Schlüsseln zu ermöglichen, benötigt man ein zuverlässiges Schlüsselmanagement. Dessen Aufgabe besteht im Erzeugen aller benötigten Schlüssel zur Verschlüsselung, Integritätsprüfung und Authentifizierung und in deren Verteilung zu den richtigen Gegenstellen in einem VPN (siehe Abbildung 3.1). Intranet
VPN-Client
Internet
VPN-Konzentrator
Tunnel
VPN-Client
Tunnel
Paket-Verschlüsselung Paket-Authentifizierung Paket-Integritätsprüfung
Abbildung 3.1: Beim Transport privater Daten über das Internet müssen verschiedene Sicherheitsaspekte berücksichtigt werden.
Gute Schlüssel, vor allem solche zur Datenverschlüsselung, haben eine relativ kurze Lebensdauer von meist einer Session oder wenigen Stunden und müssen deshalb sehr oft erzeugt und verteilt werden. Manuelle Verfahren scheiden aus diesem Grund, vor allem auch bei größeren Installationen aus. Da Out-ofBand-Verfahren, also die Verteilung der Schlüssel über ein anderes Kommunikationsmedium, praktisch den doppelten Aufwand bei der Auslegung eines Netzes erfordern, scheiden diese ebenfalls in den meisten Fällen aus.
54
Sicherheit
Die heute bekannten Verfahren zum Schlüsselmanagement basieren meist auf so genannten asymmetrischen Verfahren, bei denen zum Ver- und Entschlüsseln jeweils unterschiedliche Schlüssel verwendet werden, von denen einer, der öffentliche Schlüssel (Public Key), allgemein bekannt sein darf. Diese Verfahren nennt man daher auch Public-Key-Verfahren.
3.1.3
Paket-Authentifizierung
Es muss garantiert werden, dass ankommende Pakete auch tatsächlich von dem authentischen Sender kommen und nicht von Dritten mit gefälschten Absenderadressen und neu berechneten Prüfsummen geschickt wurden. Ähnlich wie bei einer Benutzer-Authentifzierung muss tatsächlich jedes ankommende Paket authentifiziert werden, was man durch symmetrische Schlüssel oder so genannte Pre-Shared Secrets, vertrauliche Daten, die nur dem Sender und dem Empfänger bekannt sind, erreicht. Aus Gründen der Geschwindigkeit und der Einfachheit kombiniert man dies meist mit Verfahren zur Prüfung der Datenintegrität.
3.1.4
Datenintegrität
Der Empfänger muss zuverlässig erkennen können, ob ein ankommendes Paket während des Transports verändert wurde. Normale Prüfsummenverfahren reichen hierfür nicht aus, da ein Angreifer nach Änderung eines Datenpakets auch dessen Prüfsumme neu berechnen kann. Spezielle Verfahren auf Basis von symmetrischen Verschlüsselungsverfahren berechnen die Paketprüfsumme und fügen sie in das Paket mit ein. Die Schlüssel sind nur dem Sender und dem Empfänger bekannt. Ein Angreifer, der ein Paket ändern will, kann die Prüfsumme nicht korrekt berechnen. Intranet VPN-Konzentrator VPN-Client
Internet Tunnel
System-Authentifizierung Benutzer-Authentifizierung
Abbildung 3.2: Neben der Verbindung selbst muss beim Remote Access auch der Benutzer authentifiziert werden. 55
3 Anforderungen an VPNs
3.1.5
Benutzer-Authentifizierung
Dies ist ganz wichtig bei Remote-Access-VPNs. Ein Benutzer, der über ein VPN-Gateway Zugriff auf das Intranet verlangt, muss seine Identität möglichst zuverlässig nachweisen. Der Grad dieser Zuverlässigkeit ist von Fall zu Fall verschieden, so dass ein guter VPN-Konzentrator eine Reihe unterschiedlich starker Authentifizierungsverfahren unterstützen muss. Die Abstufung reicht dabei von einfachen Passwortverfahren bis hin zur Verwendung von Tokenkarten oder digitalen Zertifikaten. In diesem Bereich, zum Beispiel bei den Tokenkarten, gibt es keine verbindlichen Standards, so dass man hier immer proprietär ist. Für PKIs (Public Key Infrastructure, eine Infrastruktur zum Management von öffentlichen Schlüsseln und digitalen Zertifikaten) gibt es eine Arbeitsgruppe innerhalb der IETF, die auch schon eine Reihe von Standards hervorgebracht hat.
3.1.6
Benutzer-Autorisierung
Wird das VPN auch als Extranet verwendet, dann greifen auch externe Personen oder Organisationen, denen nur begrenzte Zugriffsrechte gewährt werden dürfen, auf Ressourcen des Unternehmensnetzes zu. Die Autorisierung ist aber nur begrenzt ein Thema für Zugriffssysteme wie Router oder VPN-Konzentratoren. Denn diese Systeme sind nicht in der Lage, auf Benutzer- oder Gruppenebene rollenbasierende Zugriffe auf Verzeichnisse, Datenbanktabellen oder Drucker zu steuern. Diese Funktionen können nur von den Systemen wahrgenommen werden, die diese Ressourcen auch verwalten, also von Betriebssystemen und Datenbankmanagementsystemen. Zugriffssysteme müssen aber die Fähigkeit besitzen, auf der Ebene von Netzwerkprotokollen eine Filterung vorzunehmen. Im Fall des IP-Protokolls heißt dies, dass aufgrund von Host- oder Netzwerkadressen, Protokollnummern, Portnummern usw. Entscheidungen getroffen werden können, ob ein Paket weitergeleitet oder verworfen wird. Aber dies ist keine Filterung auf Benutzerebene mehr, sondern auf Netzwerkebene, da Benutzer normalerweise nicht an feste IP-Adressen gebunden sind. Falls die Filterungen auch aufgrund von Informationen in höheren Ebenen des OSI-Referenzmodells vorgenommen werden sollen, spricht man von Firewalls. Diese wurden bisher meist als Übergangspunkt vom Intranet in das Internet verwendet, sind aber auch als Schutzsystem im Intranet-ExtranetÜbergang einsetzbar. Firewalls bieten eine Filterung von Netzwerkpaketen bis hin zu Dateninhalten, Gateways auf Applikationsebene und Integrationsmöglichkeiten von externen Applikationen wie z.B. Virenschutzprogramme. Manche Router oder VPN-Konzentratoren bieten als Option die Möglichkeit, Firewalls zu integrieren, jedoch ist es aus Gründen der Sicherheit und Performance oft besser, beide Funktionalitäten strikt voneinander zu trennen.
56
Sicherheit
3.1.7
Schutz vor Sabotage
Das VPN-Gateway soll vor Angriffen sicher sein, die darauf abzielen, seine Funktionalität zu beeinträchtigen oder es funktionsunfähig zu machen. Es gibt eine Reihe mehr oder weniger subtiler Arten von Angriffen auf Internetsysteme, denen auch VPN-Gateways ausgesetzt sein können. Vor der plumpsten Art einer solchen DoS-Attacke (Denial-of-Service, dabei wird verhindert, dass ein System seine Dienste erbringen kann), dem Überlasten einer Übertragungsstrecke oder einer Netzwerkschnittstelle, kann man sich nicht schützen, allerdings sind solche Angriffe mittlerweile sehr schnell zurückzuverfolgen, und der Angreifer bekommt in der Folge sehr viel Zeit, um über seine Untaten nachzudenken. Die Strafverfolgungsbehörden haben sich mittlerweile auf der ganzen Welt recht gut auf diese Art von Kriminalität eingestellt. Subtilere Angriffe verschleiern, teilweise recht effizient, ihren eigentlichen Ursprung und schicken wenige, unverdächtig scheinende Pakete zu den Zielsystemen. Sie versuchen sie damit zu umfangreichen Aktivitäten zu bewegen, aufgrund derer ihnen für ihre eigentlichen Dienstleistungen immer weniger Ressourcen zur Verfügung stehen. So genannte DDoS-Angriffe (Distributed DoS) gehen noch einen Schritt weiter und legen ihren Angriff zweistufig an. Im ersten Schritt wird auf einer großen Anzahl von Rechnern unbemerkt ein Programm aufgespielt, das die eigentliche Attacke durchführen soll. Als Nächstes fangen alle diese Rechner zu einem bestimmten Zeitpunkt an, gleichzeitig mit unverdächtig scheinenden Paketen das Zielsystem regelrecht zu bombardieren. Die Zurückverfolgung des Angriffs ist sehr schwer, da er von Hunderten oder Tausenden weltweit verteilter Systeme auszugehen scheint, diese aber selbst auch nur »Opfer« sind. Der wirkliche Urheber hat inzwischen genug Zeit gehabt, seine Spuren zu verwischen.
3.1.8
Schutz vor unerlaubtem Eindringen
Ein VPN-Gateway muss verhindern, dass Unbefugte die Möglichkeit haben, über seine öffentlichen Schnittstellen in das Unternehmensnetzwerk zu gelangen. Denn dies ist der direkte Weg zu den Informationen, die ein Angreifer ausspionieren oder manipulieren will. Der Hacker begnügt sich nicht mit dem, was über Netzwerkverbindungen übertragen wird, sondern er will Zugang zu den Systemen, auf denen die Daten gespeichert und verarbeitet werden. Ganz beliebte Systeme sind Authentifizierungssysteme, auf denen Passwörter und andere kritische Informationen gespeichert werden. Wer solch ein System »geknackt« hat, dem steht ein ganzes Unternehmensnetzwerk offen.
57
3 Anforderungen an VPNs
Da VPN-Gateways in vielen Fällen die einzige Schnittstelle zwischen einem Intranet und dem Internet sind, auf das Millionen Unbekannte Zugriff haben, müssen hier besondere Maßnahmen zum Zugriffsschutz getroffen werden. Man unterscheidet dabei: 왘 Physische Sicherheit 왘 Interface-Sicherheit 왘 Betriebssicherheit
Physische Sicherheit Die Systeme müssen in sicheren Umgebungen betrieben werden. Die Sicherheit des Betriebsraums ist wesentlich, Security-Gateways dürfen nicht in Büros oder normalen EDV-Räumen betrieben werden, sondern nur in entsprechend sicheren Zonen. Sehr gute Systeme sind durch spezielle Maßnahmen gegen unerlaubtes Öffnen des Geräts abgesichert und erzeugen im Zugriffsfall einen entsprechenden Alarm im Netzwerkmanagementsystem. Interface-Sicherheit Die Interfaces, die mit dem Internet verbunden sind, sollten spezielle Mechanismen zum Schutz gegen die verschiedenen Arten von Angriffen aufweisen. Als besonders geeignet erweisen sich so genannte gehärtete IP-Stacks, die eines großen Teils ihrer normalen Funktionalität beraubt und damit gegen eine ganze Reihe von Angriffen immun sind, da die meisten Angriffspunkte überhaupt nicht mehr vorhanden sind. Als schlecht im Sinne von unsicher sind im Allgemeinen VPN-Systeme einzustufen, die als Programm oder Prozess auf nicht sicheren Betriebssystemen laufen. Trotz anders lautender Behauptungen kann die Sicherheit eines Programms nicht größer als die Sicherheit des Betriebssystems sein, auf dem es läuft. Insbesondere die IP-Stacks vieler Betriebssysteme sind beliebte Ziele von Angriffen verschiedenster Art. Betriebssicherheit Hier gilt es dafür Sorge zu tragen, dass sich durch den Betrieb des VPN-Gateways keine Hintertüren für Angreifer öffnen. Da verschiedenen Studien zufolge der weitaus größte Teil von Angriffen von innen heraus erfolgt und nicht vonseiten des Internets, sind hier spezielle Maßnahmen nötig. Insbesondere sollte die Administration der Systeme im LAN verschlüsselt erfolgen, also zum Beispiel mit SSL oder noch besser mit IPSec. Überhaupt sollte man sich ganz genau vergewissern, welche Zugriffsmöglichkeiten im privaten Netz gegeben sind und wie damit umzugehen ist. Ein cleverer Angreifer – und viele davon sind sehr clever – wird, sobald er sieht, dass ein VPN bei-
58
Verfügbarkeit
spielsweise IPSec mit starker Verschlüsselung benutzt, sofort alle Gedanken an einen Angriff auf die IPSec-Verbindung selbst aufgeben und nach anderen Schwachstellen im System suchen. Und eben diese gilt es zu vermeiden.
3.2
Verfügbarkeit
Ein virtuelles privates Netzwerk soll traditionelle Weitverkehrs- oder Remote-Access-Lösungen ergänzen oder sogar ganz ersetzen. Dies bedeutet aber auch, dass ein VPN eine Verfügbarkeit bieten muss, die nicht unter der von herkömmlichen WAN-Infrastrukturen liegt. Die »alten« Lösungen, die auf Standardfestverbindungen, Frame Relay und ISDN basieren, weisen in der Regel eine hohe Verfügbarkeit auf.
3.2.1
Die Verfügbarkeit von Wählverbindungen
Der Remote Access wird über entsprechende PC-Karten oder externe Geräte mittels Wählverbindungen über das analoge oder digitale Fernsprechnetz, bei Bedarf auch über das Mobilfunknetz, aufgebaut und in einem RemoteAccess-Konzentrator terminiert. Diese Netze bieten in der Regel Verfügbarkeitszeiten von mindestens 99,999%. Mit anderen Worten, das Netzwerk zwischen der ISDN-Karte im Notebook eines Außendienstmitarbeiters und dem Primärmultiplexanschluss seines Unternehmens fällt pro Jahr maximal 5,2 Minuten aus! An dieser Stelle auch gleich eine Anmerkung zum Begriff der Verfügbarkeit: Der obige Wert bedeutet nicht, dass das Netz im Jahr im Schnitt 5,2 Minuten ausfällt, sondern dass es garantiert nicht länger als 5,2 Minuten außer Betrieb ist. Bei den in solchen Netzen eingesetzten Hochverfügbarkeitssystemen ist es nicht selten der Fall, dass sie jahrelang überhaupt nicht ausfallen. Für viele Remote-Access-Infrastrukturen ist die so genannte »Niemals besetzt«Eigenschaft eines Telefonnetzwerks ebenso wichtig. Haben Sie schon jemals am soeben abgehobenen Hörer eines am öffentlichen Fernsprechnetz angeschlossenen, funktionsfähigen Telefonapparates kein Freizeichen gehört? Vermutlich nicht. Wenn nun mehr Zugangskanäle in ein Unternehmensnetzwerk gelegt werden, als es potenzielle Benutzer gibt, kann man sich damit eine RemoteAccess-Lösung mit tatsächlich garantiertem Zugriff aufbauen, da man selbst Einfluss auf die Auslegung seiner Systeme hat. Dies ist in vielen Fällen ein entscheidendes Kriterium, zum Beispiel beim Einsatz von Applikationen für Buchungs- oder Reservierungssysteme.
59
3 Anforderungen an VPNs
3.2.2
Die Verfügbarkeit von permanenten Verbindungen
Das Gleiche gilt für die meisten Festverbindungen und anderen WAN-Services. In ihren Verträgen garantieren die Provider entsprechende Verfügbarkeiten. Die für Standardfestverbindungen eingesetzten Fernvermittlungssysteme der großen Carrier bieten Verfügbarkeiten ähnlich der von ISDN, und auch die Frame-Relay- und ATM-Technologie ist mittlerweile mit so genanntem »Carrier-grade«-Equipment aufgebaut, das auch ein mittleres Erdbeben unbeschadet übersteht.
3.2.3
Die Verfügbarkeit von IP-VPNs
Diese Verfügbarkeiten muss ein virtuelles privates Netzwerk ebenfalls bieten können, soll es ein traditionell aufgebautes Netzwerk ergänzen oder gar ersetzen. Denn üblicherweise investiert man nicht in eine Technologie, die qualitativ schlechter ist als die aktuelle. Es sei denn, die neue Technologie bietet enorme Kostenvorteile. Dann ist man schon eher geneigt, einen Kompromiss zu machen oder sich zu überlegen, welche Verfügbarkeit denn wirklich benötigt wird. Es gilt also, überhaupt erst einmal zu ermitteln, welche Verfügbarkeit tatsächlich benötigt wird. In sehr vielen Fällen arbeiten Unternehmen beispielsweise mit Festverbindungen nicht wegen ihrer 99,99% Verfügbarkeit, sondern einfach, weil es zum Zeitpunkt der Entscheidung keine wirklich besseren Alternativen gab. Um die notwendige Mindestverfügbarkeit zu ermitteln, muss man sich Klarheit verschaffen, welche Applikationen in welchem Maße das VPN benutzen werden und welche Implikationen Verbindungsabbrüche verursachen können. Es ist auch wichtig zu wissen, welcher Art der Datenverkehr ist und welches Zeitprofil er aufweist. Wird das VPN zum Beispiel nur während der Bürostunden benutzt, z.B. für Online-Anwendungen, kann man getrost eine nur halb so gute Verfügbarkeit akzeptieren, ohne eine Qualitätseinbuße zu haben. Statistisch gesehen fällt mehr als die Hälfte der Ausfallzeit in Zeiten, in denen das VPN ohnehin nicht benutzt wird. Die Verfügbarkeit eines Internet-VPN kann man nicht allgemein beurteilen. Man muss dabei drei Fälle unterscheiden: 1. Die Verbindungen, auf denen das VPN basiert, gehen zu einem einzigen Provider. 2. Die Verbindungen, auf denen das VPN basiert, gehen zu zwei oder mehreren Providern, die miteinander kooperieren und entsprechende Durchleitungsverträge und/oder Service Level Agreements (SLA) abgeschlossen haben. 3. Die Verbindungen, auf denen das VPN basiert, gehen zu verschiedenen Providern, die keine Verträge miteinander abgeschlossen haben. Es ist nicht nachvollziehbar oder vorherbestimmbar, welchen Weg die Pakete nehmen und wie sie dort behandelt werden. 60
Performance
In den beiden ersten Fällen kann man mit dem oder den Service Providern geeignete Service Level Agreements abschließen, in denen neben anderen Eckwerten auch die Mindestverfügbarkeitszeit vertraglich geregelt ist. Hier werden mittlerweile in den meisten Fällen bereits Verfügbarkeitszeiten garantiert, die deutlich über denen der meisten lokalen Kundennetzwerke liegen. Im dritten Fall ist dies nicht möglich; man kann zwar mit jedem einzelnen Provider SLAs vereinbaren, diese gelten aber nur für ihre eigenen Netze, und es ist keine durchgehende Verfügbarkeit garantiert. Letztendlich mündet das Ganze wieder in eine Kostenkalkulation: Kosten die theoretisch möglichen Ausfälle mehr, als ich durch die neue VPN-Technologie einspare?
3.3
Performance
Mit geeigneten herkömmlichen WAN-Lösungen kann man die meisten Verbindungen mit einer garantierten, festen Bandbreite und kurzen Verzögerungszeiten betreiben.
3.3.1
Die Performance von Wählverbindungen
Eine Wählverbindung eines Remote-Access-Benutzers arbeitet, wenn er einem ISDN-B-Kanal benutzt, mit einer festen, garantierten, nicht schwankenden Übertragungsbandbreite von 64 Kbit/s und unmerklichen Verzögerungszeiten. Modemverbindungen sind mit maximal 56 Kbit/s etwas langsamer und können bei schlechter Leitungsqualität sogar mit langsameren Geschwindigkeiten arbeiten. Dies tun sie leider in der Praxis auch meistens: Die wenigsten haben schon einmal ein V.90-Modem mit 56 Kbit/s an einem öffentlichen Fernsprechnetz arbeiten sehen, meist pegelt sich die Geschwindigkeit zwischen 40 und 50 Kbit/s ein.
3.3.2
Die Performance von permanenten Verbindungen
Standardfestverbindungen Auch die Standardfestverbindungen, wie sie in Deutschland zum Beispiel von der Deutschen Telekom angeboten werden, bieten festgelegte, garantierte Übertragungsraten mit minimalen Verzögerungen, keinem Jitter und einer sehr hohen Verfügbarkeit.
61
3 Anforderungen an VPNs
Frame Relay Bei Frame-Relay-Netzen kann man neben garantierten Mindestbandbreiten (CIR, Committed Information Rate) auch Spitzengeschwindigkeiten (CBR, Committed Burst Rate) vereinbaren, die meist der Geschwindigkeit der Zugangsleitungen entsprechen. So kann man sich zum Beispiel mit einer 64-Kbit/s-Standardfestverbindung auf das Frame-Relay-Netzwerk eines Providers aufschalten lassen und vereinbaren, dass jederzeit eine Übertragung mit 24 Kbit/s garantiert ist – dass man aber, falls es die Auslastung des Netzwerks zulässt, auch bis zur maximalen Leitungsgeschwindigkeit von 64 Kbit/s arbeiten kann. Die Kosten erhöhen oder reduzieren sich durch die hohe Geschwindigkeit nicht, da bei Frame Relay volumenabhängig abgerechnet wird. ATM Für ATM gelten die gleichen Kriterien wie auch für Frame Relay, jedoch sind je nach Provider Geschwindigkeiten bis 155 Mbit/s möglich.
3.3.3
Die Performance von IP-VPNs
Bei all diesen Technologien hat man feste oder kalkulierbare Performancewerte, die ein VPN ebenfalls bieten muss, wenn es diese ablösen soll. Auch hier muss man sich beim konkreten Anforderungsprofil die gleichen Gedanken machen, die man sich auch bei der Frage der Verfügbarkeit gemacht hat. Was brauche ich wirklich? Wenn eine Standardfestverbindung von 64 Kbit/s durch VPN-Technologie ersetzt werden soll, kann man dies beispielsweise auf eine ganz einfache Weise tun, indem man mehrere Tage oder Wochen rund um die Uhr den Datenverkehr analysiert und daraus ein Verkehrsprofil erzeugt. Daraus leitet man seine tatsächlichen Anforderungen hinsichtlich der benötigten Performance ab. Garantien über Durchsatzwerte in Internet-VPNs kann man auch hier in einem Service Level Agreement mit einem oder mehreren Service Providern abschließen. Das ist allerdings bis zu einem gewissen Maße Augenwischerei. Denn in Wirklichkeit wird nichts garantiert, das ist den meisten Providern technisch auch gar nicht möglich, sondern es wird festgelegt, was passiert (Vertragsstrafe), wenn die Bandbreite nachgewiesenermaßen nicht zur Verfügung steht.
3.4
Quality-of-Service (QoS)
Bevor wir uns mit dem Thema Quality-of-Service (QoS) in IP-VPNs auseinander setzen, ist es sinnvoll, die QoS-Thematik selbst etwas eingehender zu beleuchten. Gerade in diesem Bereich, obwohl zur Zeit viel diskutiert, gibt es reichlich Begriffsverwirrung und vor allem auch eine Reihe von unterschiedlichen Konzepten zur Umsetzung des Gedankens.
62
Quality-of-Service (QoS)
Quality-of-Service wird manchmal als Maßnahme gegen eine zu kleine Bandbreite angesehen, aber auch das cleverste QoS-Konzept macht aus einer 64Kbit/s-Leitung keine 2-Mbit/s-Leitung. Was QoS in Wirklichkeit tut, ist, die zur Verfügung stehende Bandbreite ungerecht zu verteilen. Die Systematik, die hinter dieser gezielten Ungerechtigkeit steckt, ist das Thema des folgenden Abschnitts.
3.4.1
Einführung in QoS-Konzepte
Die verschiedenen Konzepte, um QoS in Übertragungsnetzen einzuführen, resultieren aus den verschiedenen Applikationen, die solche Netze gleichzeitig benutzen, und aus der im Weitverkehrsbereich oft limitierten Übertragungskapazität. In lokalen Netzen ist es, im Vergleich zu Weitverkehrsnetzen, nicht so aufwendig, hohe Bandbreiten zur Verfügung zu stellen. In den letzten sechs Jahren hat sich die mittlere Bandbreite in Unternehmens-LANs etwa verhundertfacht, im WAN-Bereich ist solch ein Wachstum offensichtlich nicht zu beobachten. Aus einer 64-Kbit/s-Verbindung ist vielleicht eine 128-Kbit/soder 2-Mbit/s-Verbindung geworden, aber bestimmt keine 6,4-Mbit/s-Leitung. Andererseits operieren Unternehmen immer dezentraler, und die eingesetzten Applikationen werden immer hungriger nach Bandbreite. So fand zunehmend eine Überbuchung der vorhandenen WAN-Bandbreiten statt, und man begann zu untersuchen, ob denn alle Datenpakete die gleiche Priorität besitzen müssen und welche Anforderungen bestimmte Applikationen an die Netzwerkverbindung stellen. Denn das mittlerweile immer häufiger benutzte IP-Protokoll behandelt alle Pakete gleich, leitet sie weiter, so gut es geht (Best-Effort-Transport), und stellt somit ohne zusätzliche Maßnahmen ein Problem dar, falls man den Datenverkehr differenzieren will. Qualitätsparameter Welche Parameter bestimmen nun die Qualität eines Datenflusses oder einer Verbindung? Es sind, neben der Bandbreite, vor allem drei Werte, die darüber entscheiden, ob eine bestimmte Qualität gegeben ist – oder ob eine Übertragung überhaupt erfolgreich ist: 왘 Verzögerungszeit (Delay) 왘 Variation der Verzögerungszeit (Jitter) 왘 Mittlere Fehlerrate
Die Verzögerungszeit ist die Zeit, die vergeht, bis ein Datenpaket vom Sender zum Empfänger gelangt. Eine negative Beeinflussung dieses Wertes erfolgt üblicherweise in Vermittlungssystemen.
63
3 Anforderungen an VPNs
Eine Variation der Verzögerungszeit, der so genannte Jitter, liegt dann vor, wenn die Verzögerungszeit kein fester Wert und damit vorherbestimmbar ist, sondern sich laufend ändert. Die mittlere Fehlerrate ist der Wert, der sich aus dem Verhältnis von korrekt übertragenen und zerstörten oder verlorenen Datenpaketen ergibt. Ein Paket gilt definitionsgemäß auch dann als verloren, wenn es aus Sicht einer Applikation zu spät ankommt. In Tabelle 3.1 sehen Sie, welche Anforderungen verschiedene Applikationen ihrer Natur gemäß an die verschiedenen Quality-ofService-Parameter stellen.
Verzögerung
Variation der Verzögerung
Fehlerrate
E-Mail
Niedrig
Niedrig
Hoch (0 Fehler)
Dateiübertragung (FTP)
Niedrig
Niedrig
Hoch (0 Fehler)
Videostrom (MPEG)
Hoch
Mittel
Niedrig
Videokonferenz
Hoch
Hoch
Niedrig
Telefonie
Hoch
Hoch
Niedrig
Tab. 3.1: Die Priorität der Anforderungen verschiedener Applikationen an die QoS
Zusätzlich zu diesen Qualitätsparametern ist die verfügbare Bandbreite ein Faktor, der einen indirekten Einfluss auf die Verbindungsqualität hat. Die Bandbreite selbst wird in der Regel von der Physik bestimmt, also von elektrischen und optischen Parametern der Leitungen und von der Verarbeitungsgeschwindigkeit der Vermittlungssysteme. An diesem Wert kann meistens auch nichts verändert werden: Die Bits werden in einer Leitung in der Reihenfolge transportiert, in der sie eingeben wurden, und zwar mit der Geschwindigkeit bzw. dem Takt des Mediums. Eingreifen kann man aber in den Vermittlungssystemen, wenn man bestimmte Pakete oder bestimmte Datenflüsse dort unterschiedlich behandelt. Qualitätsanforderungen verschiedener Applikationen In Tabelle 3.1 haben Sie gesehen, dass unterschiedliche Arten von Anwendungen auch sehr unterschiedliche Anforderungen an die verschiedenen Qualitätsparameter stellen. So muss die mittlere Fehlerrate bei einer Dateiübertragung gleich 0 (Null) sein, denn sobald auch nur ein einziges Bit fehlerhaft ist, ist die übertragene Datei nicht mehr integer. Bei der Sprachkommunikation hingegen kann sogar das eine oder andere kleine Paket ganz verloren gehen, man ist ja von »schlechten« Telefonleitungen schon einmal das eine oder andere »Knacken in der Leitung« gewohnt – von dem, was ein MobiltelefonBenutzer über sich ergehen lassen muss, einmal ganz zu schweigen. Das Gleiche gilt auch für Videoübertragungen: Ein paar kleine schwarze Punkte
64
Quality-of-Service (QoS)
nimmt man in einem bewegten Bild subjektiv ohnehin nicht wahr. Was sich aber extrem schlecht auf solche Verbindungen auswirkt, sind große Verzögerungszeiten bei interaktiver Sprach- oder Videokommunikation. Bei einem Mail-Transfer wiederum ist dieser Wert nicht so tragisch, denn ob die E-Mail nach zwei oder nach acht Sekunden ankommt, ändert an deren Qualität überhaupt nichts. Welche Ansätze gibt es nun, die für bestimmte Applikationen erforderliche Qualität einzuhalten? Vorherbestimmte Qualität Ein Paradebeispiel hierfür ist eine Telefonverbindung, zum Beispiel ISDN. Hier wird für die Dauer der Verbindung zwischen den beiden Gesprächspartnern ein Datenpfad mit einem Vielfachen der erforderlichen Bandbreite permanent durch das Netzwerk geschaltet. Die Verzögerung ist minimal, subjektiv garantiert nicht wahrnehmbar und konstant. Somit sind alle drei Qualitätskriterien voll erfüllt. Eine andere Idee ist es, das Transportnetz einfach so überzudimensionieren, dass die gesamte Bandbreite höher ist als die Summe der von allen Datenströmen benötigten Bandbreiten. Somit haben auch im schlimmsten Fall alle Applikationen ihre benötigte Bandbreite, eine relativ kurze, vorherbestimmbare und feste Verzögerungszeit und keine überlastbedingten Fehlerraten. Allerdings hat dieses Konzept einen unschönen Nachteil, denn man schießt hierbei mit Kanonen auf Spatzen. Man stellt viel mehr Ressourcen zur Verfügung, als im Durchschnitt wirklich benötigt werden – und diese müssen auch bezahlt werden. Flussbasierende Qualität Hinter diesem Ansatz steht der Gedanke, eine Reihe von Netzwerkressourcen für einen bestimmten Datenfluss zu reservieren. Dieser Datenfluss kann zum Beispiel eine Verbindung zwischen Netzen, Rechnern oder Applikationen sein. Eine Voraussetzung dafür, dass dies funktioniert, ist sowohl ein Signalisierungsprotokoll als auch die Notwendigkeit, dass alle beteiligten Systeme – vor allem auch alle Vermittlungssysteme – diese Technologie implementiert haben. Sobald ein Datenfluss beginnen soll, erfolgt durch das Signalisierungsprotokoll eine sukzessive Signalisierung an alle beteiligten Systeme, mit der Aufforderung, die entsprechenden Ressourcen für diesen Datenfluss zur Verfügung zu stellen und zu reservieren. Wenn dies erfolgreich war, also alle positiven Rückmeldungen erfolgten, dann kann die Übertragung beginnen. Allerdings ist dieses Konzept mit einigen Problemen behaftet, insbesondere dem der mangelnden Skalierbarkeit in großen Netzen wie etwa dem Internet. In kleineren Netzen oder bei langer Lebensdauer der Datenflüsse ist dies kein Problem, aber die meisten Übertragungen im Internet haben nur eine kurze
65
3 Anforderungen an VPNs
Lebensdauer. Die Folge ist die, dass die permanent notwendige Signalisierung sowie die Reservierung und Freigabe bestimmter Ressourcen und deren Verwaltung bei Hunderttausenden oder Millionen von Datenflüssen auf einem Internet-Router nicht praktikabel sind. Es wurden bisher in den RFCs 2211, 2212 und 2205 hinsichtlich der flussbasierenden Qualität verschiedene Standardisierungsbemühungen unternommen, jedoch setzen sie sich in großen Netzen wie dem Internet nicht durch, da die notwendigen Ressourcen, insbesondere für das Resource Reservation Protocol (RSVP) auf den Internet-Routern zu groß sind. Klassenbasierende Qualität Ein anderer Ansatz, der dieses Problem umgehen soll, ist die so genannte klassenbasierende Qualität oder Class-of-Service (CoS). Die zu übertragenden Netzwerkpakete werden in bestimmte, wohl bekannte Klassen eingeteilt und im Paket-Header entsprechend markiert. Die an diesem Konzept beteiligten Vermittlungssysteme kennen entsprechende Strategien, wie Pakete einer bestimmten Klasse zu behandeln sind. Abhängig von der Art der Vermittlungssysteme (ATM, Frame Relay, LAN-Switch usw.), werden diese Klassenparameter in geeigneter Weise auf die jeweilige Technologie angewendet. Hier ist keine Signalisierung mehr notwendig, denn die für die Verarbeitung benötigten Ressourcen kennt das Vermittlungssystem bereits. Pakete verschiedener Quellen oder Applikationen werden, falls sie der gleichen Klasse angehören, innerhalb ihrer Klasse nach dem Best-Effort-Prinzip transportiert. Aber auch dieses verbindungslose Prinzip weist einige Nachteile auf. Denn ohne eine Signalisierung ist für den Sender oder bestimmte Vermittlungssysteme nicht erkennbar, ob die erforderlichen Ressourcen für die benötigte Service-Klasse auf allen beteiligten Systemen überhaupt verfügbar sind. Ein weiteres Problem kann entstehen, wenn verschiedene Netzwerke – und das Internet ist ein Konglomerat aus verschiedenen Netzen – verschiedene Service-Klassen definiert haben. Hier kann es im Extremfall dazu kommen, dass sich die Pakete nach dem Durchlaufen verschiedener Netze bei konservativer Umsetzung (im Zweifelsfall in die nächsthöhere Klasse) der CoS-Markierungen am Ende in der höchsten Service-Klasse wiederfinden. »Höchste Service-Klasse« klingt zwar gut, bedeutet aber in letzter Konsequenz tatsächlich einen Best-Effort-Transport der Pakete, da diese sich alle in einer einzigen Klasse drängeln.
3.4.2
Quality-of-Service bei Wählverbindungen
Die kritischen Qualitätsparameter bei Wählverbindungen hängen vom verwendeten Medium ab, also davon, ob man ISDN, analoge Telefonie oder Mobilfunk benutzt.
66
Quality-of-Service (QoS)
Im Fall von ISDN liegen alle Werte »im grünen Bereich«, die mittlere Fehlerrate ist praktisch null, die Verzögerung ist minimal, und es gibt keinen Jitter. Darüber hinaus ist die Bandbreite ebenfalls garantiert. Analoge Verbindungen sind ebenfalls fast verzögerungsfrei, die mittlere Fehlerrate ist aus Sicht der höheren Protokolle ebenfalls null. Mobilfunkverbindungen sind aus Datenübertragungssicht katastrophal, denn was dem menschlichen Gehirn an Verarbeitungsleistung abverlangt wird, um den gesprochenen und während der Übertragung oft verstümmelten Text zu entschlüsseln, das leisten Protokolle wie IP im Datenbereich nicht. Hier müssen entsprechende höhere Protokolle unter Umständen den Paketverlust ausgleichen, und die Übertragung ist insgesamt nicht sehr effizient.
3.4.3
Quality-of-Service bei permanenten Verbindungen
Standardfestverbindungen Die kritischen Qualitätsparameter bei Standardfestverbindungen sind alle sehr gut, die mittlere Fehlerrate ist praktisch null, es gibt keinen Jitter, und die Verzögerung kann insgesamt vernachlässigt werden. Darüber hinaus ist die Bandbreite ebenfalls garantiert. ATM ATM wurde, wie Sie vermutlich wissen, primär zum Transport von Sprache und Video entwickelt, aber auch zum Transport anderer Daten. Aus diesem Grund wurde von Anfang an auch auf das Thema Quality-of-Service geachtet. Die Technik wurde auf hohe Geschwindigkeit und geringe Verzögerungen getrimmt. ATM definiert fünf unterschiedliche Service-Klassen, die in Tabelle 3.2 beschrieben sind. Diese unterschiedlichen Klassen sind für verschiedene Arten von Applikationen wie Video, interaktive Sprachübertragung (Telefonie) oder Datenpaketübertragung geeignet. Kategorie
ATM-Parameter
Applikationstyp
Constant Bit Rate (CBR)
PCR, CTD, CDV, CLR
Telefonie, Sprache
Real-time Variable Bit Rate (rtVBR) PCR, CTD, CDV, CLR, SCR Sprache/Video (Paket) Non-real-time VBR (Nrt-VBR)
PCR, SCR, CLR
Frame Relay over ATM
Available Bit Rate (AVB)
PCR, MCR
Daten (IP, IPX)
Unspecified Bit Rate (UBR)
(keine)
Daten (IP, IPX)
Tab. 3.2: Die fünf ATM-Service-Klassen
67
3 Anforderungen an VPNs
In ATM definieren die folgenden sechs verschiedenen Parameter die fünf Service-Klassen: 왘 Peak Cell Rate (PCR), die maximal mögliche Rate, mit der ATM-Zellen
übertragen werden können 왘 Cell Delay Variation (CDV), die Abweichung der Verzögerung zweier
beliebiger ATM-Zellen 왘 Cell Loss Ratio (CLR), das Verhältnis von fehlerfreien zu fehlerhaft über-
tragenen oder verworfenen Zellen 왘 Sustainable Cell Rate (SCR), der mittlere, erreichbare Durchsatz 왘 Minimum Cell Rate (MCR), die minimale Zellübertragungsrate
Obwohl ATM zwischen verschiedenen ATM-Switches kleine Zellen überträgt, ist es verbindungsorientiert und basiert auf virtuellen Verbindungen (VC, Virtual Circuit). Es werden entweder feste virtuelle Verbindungen (PVC, Permanent Virtual Circuit) durch ein ATM-Netz konfiguriert, oder sie werden für die Dauer einer Verbindung geschaltet (SVC, Switched Virtual Circuit) und anschließend wieder deaktiviert. Im Internet, in dem ATM vor allem in den Backbones der Service Provider und Carrier eingesetzt wird, werden vor allem PVCs eingesetzt. ATM bietet die Möglichkeit, die Konfiguration eines ATM-Netzwerks zu vereinfachen, indem man verschiedene VCs zu einem virtuellen Pfad (Virtual Path, VP) zusammenfasst. Frame Relay Frame Relay bietet ebenfalls die Möglichkeit, verschiedene Service-Klassen zur Verfügung zu stellen. Diese unterscheiden sich hauptsächlich durch die zugesicherte Bitübertragungsrate (CIR, Committed Information Rate) und die maximal mögliche Übertragungsrate (EIR, Excess Information Rate). Ähnlich wie ATM ist Frame Relay verbindungsorientiert und transportiert seine Daten in kleinen Paketen (Frames). Auch hier gibt es permanente (PVC) und geschaltete (SVC) virtuelle Verbindungen. Aufgrund seiner Architektur und seiner Ausrichtung auf die Datenübertragung ist nicht so gut für Sprachoder Videoübertragungen geeignet und wird nicht für Geschwindigkeiten über 45 Mbit/s eingesetzt. ATM und Frame Relay sind im Augenblick die einzige Möglichkeit, mit der die Service Provider den Kunden eine Quality-of-Service anbieten können. Der Provider stellt für jede Verbindung einen entsprechenden PVC mit den geeigneten Serviceparametern zur Verfügung. Allerdings existieren in einem großen Netz auf diese Art und Weise sehr viele PVCs, denn wenn ein Kunde beispielsweise zehn Niederlassungen sternförmig vernetzen will, muss der Service Provider N x (N-1) = 10 x 9 = 90 PVCs konfigurieren.
68
Quality-of-Service (QoS)
3.4.4
Quality-of-Service im IP-Protokoll
Das Internet-Protokoll wurde ursprünglich als verbindungsloses Verfahren zum asynchronen Transport von Datenpaketen entwickelt. Es garantiert keine Paketzustellung oder bestimmte Zeiten, in denen ein Paket übertragen wird. Die Vermittlungssysteme (Router) verarbeiten die Pakete in der Reihenfolge, in der sie eintreffen, und machen sich keine Gedanken über deren Wichtigkeit oder die mit den Paketen verknüpfte Anwendung. Falls auf einem schnellen Medium wie Ethernet mehr Pakete in einem Router ankommen, als dieser auf einem langsameren Interface ausgeben kann, kommt es zu Verzögerungen oder im schlimmsten Fall zu Paketverlusten. Dieses Verhalten ist kennzeichnend für IP und das Internet. Dies war lange Zeit auch kein Problem, da über dieses Netz in den Anfängen meist nur E-Mail, FTP und Telnet betrieben wurden – alles Applikationen, die sehr gutmütig auf durch Bandbreitenengpässe bedingte Verzögerungen reagieren. Auch das World Wide Web mit seinem grafischen Interface war zunächst an die Bedingungen im Internet angepasst. Da aber zunehmend Applikationen, die auf den LAN-Betrieb zugeschnitten sind und Anwendungen wie Voice- oder Video-über-IP eingesetzt werden, ist das Best-Effort-Prinzip von IP nicht mehr adäquat. Und genau hier liegt auch das Problem von IP, denn im Gegensatz zu ATM oder Frame Relay, die von vornherein für die Möglichkeit, Quality-of-Service zu bieten, entwickelt wurden, war dies nie die Idee von IP, und man hatte auch nichts dafür vorgesehen. »Nichts« ist allerdings nicht ganz richtig. Es gibt doch ein Byte im IP-Header, das viele Jahre ziemlich stiefmütterlich behandelt und von den meisten Systemen schlicht ignoriert wurde: Das Type-of-Service-Byte (TOS-Byte), das eigentlich für Quality-of-Service-Zwecke gedacht war. Dieses in der Vergangenheit sehr vernachlässigte Feld im IP-Header erlebt zur Zeit eine Renaissance, verbunden mit seiner Umbenennung, denn es heißt jetzt DSCP (Differentiated Services Code Point) und dient dazu, die Zugehörigkeit eines Pakets zu einer bestimmten Service-Klasse anzuzeigen.
3.4.5
Die IP-Differentiated-Services-Architektur (DiffServ)
DiffServ ist eine klassenbasierende Architektur (RFC2475) für die Dienstqualität in IP. Ihr werden aufgrund ihrer hohen Skalierbarkeit die besten Chancen als dominierendes Verfahren eingeräumt. Die Grundidee ist, dass die IPPakete beim Eintritt in ein Netzwerk einer bestimmten Klasse zugeordnet und entsprechend markiert werden. Die Vermittlungssysteme eines DiffServ-Netzwerks werten die Markierungen aus und behandeln die Pakete entsprechend. Die Systeme kennen also nur Service-Klassen und unterscheiden weder bestimmte Datenflüsse noch Adressen. Sie sind für jede Service-Klasse auf ein bestimmtes Verhalten (PHB, Per Hop Behaviour) konfiguriert, das heißt sie lei-
69
3 Anforderungen an VPNs
ten eingehende Pakete in entsprechende Warteschlangen verschiedener Priorität oder verwerfen sie unter bestimmten Umständen (z.B. Überlast) auch. DiffServ verlegt die Komplexität der Klassifizierung des Datenverkehrs auf die Grenzen des Netzwerks. Diese Systeme müssen die zu übertragenden Datenpakete beim Eintritt in das Netz klassifizieren, markieren und bereits ihrer Service-Klasse entsprechend behandeln. Die Router im Netzwerk müssen die Entscheidung, wie ein Paket zu behandeln ist, lediglich aufgrund des DSCP-Felds im IP-Header treffen. Es erfolgt weder eine Signalisierung zwischen den Routern noch müssen die Zustände einer Vielzahl verschiedener Datenflüsse verwaltet werden. Viele dieser Router haben bereits Mechanismen und Ressourcen zur Paket-Priorisierung implementiert, so dass eine Erweiterung auf die DiffServ-Architektur nur ein logischer Schritt ist, der meist keine teuren Erweiterungen der Systeme nach sich zieht. Die Architektur von DiffServ legt fest, dass die Klassifizierung und Markierung der Pakete in einem so genannten Edge-Router erfolgt, also einem Router an der Grenze eines Netzwerks. Endsysteme oder Applikationen müssen diese Architektur nicht unterstützen, können dies aber und tun es auch zunehmend. Wo die Klassifizierung und Markierung letztendlich stattfindet, ist daher unterschiedlich und hängt neben der Qualitätsstrategie des Netzwerks auch von den verschiedenen beteiligten Komponenten, also Applikationen, Betriebssystemen und Netzwerksystemen, ab. Es kann sowohl eine Klassifizierung in den Endsystemen stattfinden, z.B. durch Applikationen, oder dies kann auch auf dedizierten Netzwerkkomponenten nach entsprechenden Regeln (Policies) erfolgen. Diese Regeln können zentral festgelegt und verwaltet und dann auf die beteiligten Systemkomponenten verteilt werden. Es kann auch nötig sein, durch geeignete Policies bestimmte Klassifizierungen an Netzwerkgrenzen zu ändern, da unter Umständen in Endgeräten Markierungen durch Applikationen oder Benutzer vorgenommen wurden, die nicht mit der netzwerkweiten QoS-Strategie konform sind. DiffServ ist ein Protokoll in der Schicht 3, also der Netzwerkschicht. Dadurch, dass es somit unabhängig von Layer-2-Protokollen (wie Frame Relay oder ATM) ist, kann es mit einer Vielzahl von Infrastrukturen genutzt werden. Die Router oder Switches müssen natürlich entsprechend konfiguriert werden, um die entsprechende Service-Klasse korrekt zu behandeln, also muss beispielsweise festgelegt werden, welche ATM-Service-Parameter wie zu konfigurieren sind. Aber dies erfolgt nur in eine Richtung: aus der Sicht des Schichtenmodells von oben nach unten, und es findet keine Wechselwirkung in der Art statt, dass Layer-2-Spezifika die Service-Klasse beeinflussen. Dies ist ein weiterer wichtiger Pluspunkt zugunsten des DiffServ-Modells, denn sehr viele größere Netze benutzen zum Transport von IP-Paketen eine Vielzahl verschiedener Infrastrukturen (ATM, IEEE802.1q, Frame Relay usw.), die unterschiedliche Quality-of-Service- und Priorisierungsmechanismen bieten.
70
Quality-of-Service (QoS)
Diese können den DSCP auswerten, ihn aber nicht ändern, so dass die Klasseninformation während der vollständigen Übertragung erhalten bleibt. 0
1
2
3
4
5
6
101110xx = Expedited Forwarding Code Point (RFC2598)
7
00000000 = Best Effort Forwarding Code Point
Reserved
11x000xx = Network Control Traffic Code Point
Drop Precedence
Class Selector
Assured Forwarding Code Points (RFC2597) Class 1
Class 2
ClassC3
lass 4
Low Drop Precedence
001010
010010
011010
100010
Medium Drop Precedence
001100
010100
011100
100100
High Drop Precedence
001110
010110
011110
100110
Class Selector Code Points (RFC2474) Class 0
Class 1
Class 2
Class 3
Class 4
Class 5
Class 6 Class 7
000000
001000
010000
011000
100000
101000
110000 111000
Abbildung 3.3: Der Differentiated Services Code Point (DSCP) im IP-Header
Die DiffServ-Service-Klassen Zur Zeit sind in DiffServ drei verschiedene Service-Klassen festgelegt: 왘 Premium 왘 Tiered 왘 Best Effort
Zu jeder dieser Klassen gibt es ein festgelegtes Per Hop Behaviour (PHB), das in den Routern oder Switches eines DiffServ-Netzwerks unterstützt werden muss. Das PHB unterscheidet zwischen unmittelbarem Weiterleiten (EF, Expedited forward), garantiertem Weiterleiten (AF, Assured forward) und normalem Weiterleiten (DF, Default forward) der IP-Pakete. Wie das die verschiedenen Systeme technisch realisieren, ist nicht im Standard festgelegt.
71
3 Anforderungen an VPNs
Für den so genannten Premium-Service muss jeder Router permanent einen gewissen Teil seiner Ressourcen reservieren, unabhängig von seiner tatsächlichen Auslastung. Für den Tiered-Service gilt das Gleiche, jedoch werden diese Ressourcen in verschiedene Prioritätsstufen untergliedert. Was an Ressourcen übrig bleibt, wird vom Best-Effort-Service benutzt. In Abbildung 3.3 sehen Sie den Aufbau des DSCP-Felds im IP-Header. DiffServ benutzt derzeit, wie im RFC2474 festgelegt, die ersten sechs Bits davon. Davon legen die ersten drei Bits die Klasse fest, und die folgenden drei Bits geben die Vorrangigkeit innerhalb der jeweiligen Klasse an, mit der Pakete in Überlastsituationen verworfen werden können. Der Codepunkt 101110 markiert den Premium-Service und der Codepunkt 000000 den Best-Effort-Service. Der DiffServ-Edge-Router Der Klassifizierer ist die Funktion, die in einem so genannten Edge-Router ein eingehendes Paket daraufhin prüft, welche Bits im DSCP-Feld zur Klassifizierung des Pakets gesetzt werden müssen. Er teilt die IP-Pakete somit in verschiedene Klassen ein, die der Betreiber des Transportnetzwerks unterstützt. Nach welchen Kriterien eine solche Klassifizierung erfolgt, richtet sich entweder nach dem Service-Level-Agreement (SLA), das mit dem Provider abgeschlossen wurde, und/oder nach der Qualitätsstrategie des Netzwerks. Die Entscheidung des Klassifizierers erfolgt zum Beispiel aufgrund von Quelloder Zieladressen, Port- oder Protokollnummern oder aufgrund des DSCPFelds. Denn es kann durchaus sein, dass ein Paket verschiedene Netze unterschiedlicher Provider durchläuft oder dass in einem Kundennetz bereits schon eine DiffServ-Klassifizierung erfolgt ist. Zur Zeit erfolgt die Markierung statisch nach fest im Edge-Router vorgegebenen Regeln. Anschließend wird das markierte Paket seiner Markierung entsprechend in den passenden Ausgangspuffer geschrieben und von dort in das Transportnetz weitergeleitet. In Abbildung 3.4 sehen Sie in dem Edge-Router neben dem Markierer und dem Klassifizierer noch einen so genannten Shaper. Dieses Modul sorgt dafür, dass der Datenverkehr in das Transportnetz einen bestimmten vereinbarten Wert oder die mögliche Bandbreite einer Verbindung nicht überschreitet. Der DiffServ-PHB-Router Der PHB-Router braucht sich keine Gedanken mehr über die Klassifizierung oder Markierung eines Pakets zu machen, er muss es nur aufgrund der Einträge im DSCP-Feld verarbeiten und in die korrekte Warteschlange stellen. In Abbildung 3.5 können Sie erkennen, dass der PHB-Router eine Teilmenge der Funktionen des Edge-Routers aufweist und somit viel weniger belastet wird. Die Verarbeitung ist demzufolge relativ schnell, denn es muss nur das DSCPFeld ausgewertet werden. Da das PHB für die EF-Klasse bedingt, dass ein jitterfreies, schnelles Weiterleiten der Pakete garantiert ist, muss der Provider umfangreiche Maßnahmen treffen, um dies zu erreichen – und dies verur-
72
Quality-of-Service (QoS)
sacht natürlich entsprechende Kosten. Zukünftige Modelle, die auf dem Einsatz so genannter dynamischer Policy-Server basieren, ermöglichen eine dynamische Zuteilung von Ressourcen für die EF-Klasse aufgrund der aktuellen Netzlast und befreien den Provider damit von der statischen Reservierung der notwendigen Betriebsmittel.
Management-Interface
Policy-ServerInterface
Policy
Classifier
Marker
PriorityQueues
DSCP
InputInterface
OutputInterface
Packet Distributor
Shaper/ Scheduler Abbildung 3.4: Der DiffServ-Edge-Router klassifiziert und markiert die IP-Pakete.
Management-Interface
Policy-ServerInterface
PriorityQueues
InputInterface
Packet Distributor
OutputInterface
Shaper/ Scheduler Abbildung 3.5: Der DiffServ-PHB-Router verarbeitet die IP-Pakete anhand des DSCP-Feldes.
73
3 Anforderungen an VPNs
3.4.6
Differentiated Services in IP-VPNs
Hier müssen zwei unterschiedliche Szenarien betrachtet werden: Setzt der Kunde in seinem Netzwerk bereits DiffServ ein und möchte er, dass der Provider die Pakete entsprechend behandelt, oder soll eine entsprechende Klassifizierung der IP-Pakete erst beim Eintritt in das Provider-Netzwerk erfolgen? Im ersten Fall muss eine Vereinbarung zwischen Kunde und Provider darüber geschlossen werden, wie die Entsprechung der Service-Klassen des Kunden und den mit ziemlicher Sicherheit unterschiedlichen Service-Klassen des Providers auszusehen hat. Weiterhin muss dafür Sorge getragen werden, dass die DSCP-Informationen beim Einkapseln des Pakets durch ein Tunnelingprotokoll nicht verloren gehen. In IP-VPNs benutzt man meist das IPSec-Protokoll, das genau dies tut: Es kopiert den Inhalt des DSCP-Felds bei ausgehenden Paketen in den neu erzeugten IP-Header und macht es damit für den Provider verfügbar. Beim Entkapseln des IP-Pakets auf der Empfängerseite wird das DSCP-Feld im äußeren Header verworfen. Dadurch ergibt sich auch die Möglichkeit für den Service Provider, das DSCP-Feld des IPSec-Pakets beim Eintritt in sein Netzwerk zu ändern, also eine neue Klassifizierung vorzunehmen, ohne dass das originale DSCP-Feld davon betroffen ist. Bei den Layer-2Tunneling-Protokollen fehlt diese Funktionalität zurzeit. Im zweiten Fall ist das Problem, je nach Reihenfolge der Verarbeitungsschritte und der Systeme möglicherweise überhaupt nicht lösbar. Nehmen wir einmal den heute üblichen Fall, ein Internet-VPN mit dem IPSec-Protokoll im Tunnelmodus aufzubauen. In diesem Fall wird das originale IP-Paket vollständig verschlüsselt und in ein anderes IP-Paket eingekapselt. Dies erfolgt meist in einem IPSec-Gateway des Kunden. Das IPSec-Paket wird nun zum Router des Service Providers geschickt, der eine Klassifizierung vornehmen soll. Nur wonach? Alle dafür notwendigen Parameter wie originale IP-Adressen, Portund Protokollnummern usw. sind verschlüsselt. Einzig die äußeren IP-Adressen sind noch erkennbar, aber diese ermöglichen nur eine Priorisierung nach Quell- und Absenderstandort – etwas, was normalerweise nicht zur Paketklassifizierung benutzt wird. Mögliche Auswege sehen zum Beispiel so aus, dass die IPSec-Funktionalität erst nach der Klassifizierung im Edge-Router des Providers greift oder dass das VPN-Gateway des Kunden bereits eine Klassifizierung vornimmt, die nach den Angaben des Service Providers konfiguriert wurde. In diesem Fall muss das IPSec-Gateway die Funktionalität eines Edge-Routers bieten.
74
Skalierbarkeit und Migrationsfähigkeit
3.5
Skalierbarkeit und Migrationsfähigkeit
Wenn Sie heute über den Einsatz eines VPN nachdenken, dann sollten Sie auch bereits an übermorgen denken. Langfristige Voraussagen sind aber ziemlich schwierig und treffen manchmal auch nicht zu, also strebt man eine möglichst hohe Offenheit seines Systems an – Offenheit sowohl in Hinblick auf die Einhaltung von Standards, um gegebenenfalls einen Hersteller wechseln zu können, als auch in Hinblick auf die Modularität und Erweiterbarkeit der Systemkomponenten. »Think big – start small« Mit diesem Leitsatz liegt man genau richtig, denn für VPNs gelten die gleichen Maßstäbe hinsichtlich Skalierbarkeit und Migrationsfähigkeit wie für andere Netzwerktechnologien auch. Während der Planungsphase sollte man sich bereits Gedanken machen, wie das Netz in der Zukunft aussehen kann. Denn sehr viele Rahmenbedingungen sind stetiger Änderung unterworfen, wie zum Beispiel die Zahl der Benutzer, benötigte Bandbreiten und Qualitätsmerkmale durch neue Applikationen, rechtliche Gesichtspunkte und neue Geschäftsfelder oder Akquisitionen. Beim Thema Skalierbarkeit muss man aber unbedingt zwischen Leistung und Sicherheit differenzieren. Denn die Sicherheitsstrategie eines Unternehmens richtet sich nach völlig anderen Kriterien. Ein VPN-Gateway in einem kleinen Zweigbüro benötigt beispielsweise keinen so hohen Datendurchsatz wie seine Gegenstelle in der Unternehmenszentrale, auf der Hunderte von Verbindungen konzentriert werden, jedoch muss es den gleichen Sicherheitsanforderungen genügen. Hier gilt es sehr genau zu prüfen, ob Endgeräte für kleine Außenstellen, die vom Systemdesign her für eine kleine Übertragungsbandbreite ausgelegt sind, diese auch dann noch bieten, wenn eine starke Verschlüsselung eingesetzt wird. Ein Faktor, der sich in den meisten Netzwerken laufend ändert, ist die steigende Zahl von mobilen Anwendern und Heimbüros. Hier sollte, wie es sich in der Praxis gezeigt hat, von vornherein mit einer entsprechend großen Zahl kalkuliert werden. Die Skalierbarkeit im Bereich der Systemleistung ist ein ganz wesentliches Entscheidungskriterium bei der Planung eines VPN. Meist sind Standorte verschiedener Größe, Heimbüros und mobile Mitarbeiter mit der notwendigen Technologie auszustatten. Je nach Einsatzgebiet sind unterschiedliche Datendurchsätze und Anschlusstechnologien notwendig, vom redundanten VPN-Konzentrator bis hinunter zur VPN-Clientsoftware für PCs. Idealerweise sollen diese verschiedenen VPN-Systeme aber auch eine möglichst einheitliche Konfigurations- und Managementoberfläche bieten.
75
3 Anforderungen an VPNs
3.6
Integration in existierende Netze
Selten bekommt ein Netzwerkplaner die Gelegenheit, ein VPN auf der grünen Wiese zu planen. Er hat viel häufiger die Aufgabe, dass ein VPN in bestehende Infrastrukturen zu integrieren. Diese Infrastrukturen sind bestehende lokale Netze, Weitverkehrsnetze und Remote-Dienste sowie die dazugehörigen Management-, Accounting- und Überwachungssysteme. Das zunehmende Verlangen vieler Unternehmen nach Kostentransparenz auch im Netzwerkbereich führt zu nutzer- oder kostenstellenbezogenen Abrechnungssystemen, die vor allem in Verbindung mit WAN- und Remote-Access-Diensten eingesetzt werden, da diese durch die zusätzlich an die Carrier zu entrichtenden Gebühren sehr kostenintensiv sind.
3.6.1
Management
Insbesondere sind bei der Integration der VPN-Komponenten die bereits vorhandenen Managementsysteme zur Konfiguration und Überwachung zu unterstützen, die auch zu diesem Zweck für traditionelles Netzwerkequipment eingesetzt werden. Die wichtigsten Funktionalitäten sind die zur Konfiguration, zur Überwachung und zur Abrechung der Netzwerkdienste. Konfiguration Die Konfiguration von Netzwerkkomponenten erfolgt mittlerweile fast ausschließlich über SNMP (Simple Network Management Protocol, eine Menge von Funktionen zum Konfigurieren und Überwachen von Netzwerkgeräten und einem Übertragungsprotokoll hierfür). Dieses Protokoll wurde entwickelt, um eine problemlose Interoperabilität zwischen Netzwerkmanagementprodukten unterschiedlicher Hersteller zu ermöglichen. Eine Netzwerkmanagementstation, meist eine Grafikworkstation, dient als zentrales Element zur Steuerung und Überwachung, während auf den Netzwerkkomponenten selbst so genannte SNMP-Agents residieren. Diese Agents kommunizieren über das Netzwerk mit der Managementstation, um Konfigurationsparameter zu setzen oder abzufragen. Eine weitere wichtige Funktionalität der Agents ist ihre Fähigkeit, bei kritischen Zuständen auf dem Netzwerkgerät einen so genannten SNMP-Trap zu erzeugen, der unmittelbar zur Managementstation geschickt wird, um diese über das aufgetretene Problem zu informieren. Die Kommunikation der verschiedenen SNM-Komponenten erfolgt über UDP-Pakete, in denen verschiedene Kommandotypen zum Setzen und Lesen von MIB-Objekten oder -Variablen eingekapselt werden. Eine MIB (Management Information Base) ist eine Datenstruktur, die die Summe aller managebaren Objekte der Netzwerkkomponenten darstellt. Leider ist die Sicherheit,
76
Integration in existierende Netze
wenn man es überhaupt so nennen kann, von SNMP auf einem nicht allzu hohen Stand, so dass die Kommunikation mit einfachsten Methoden aufgezeichnet oder unbefugt verändert werden kann. Aus diesem Grund werden sicherheitskritische Systeme im Allgemeinen nicht über SNMP konfiguriert. Auch die Überwachung mit SNMP beschränkt man auf nicht sicherheitskritische Parameter, wie Zähler für übertragene Bytes oder Prüfsummenfehler und Ähnliches. Intranet
VPN-Konzentrator
NetzwerkManagement station
SNMP-Traps
Internet
webbasiertes Management
Syslog
Webbrowser
SyslogServer
Abbildung 3.6: Ein VPN-System muss mehrere Managementprotokolle unterstützen.
Bei sicherheitskritischen Netzwerkkomponenten benutzt man andere Protokolle zu deren Konfiguration. Neben herstellerspezifischen, oft nicht offen gelegten Protokollen haben sich hier das SSL-Protokoll (Secure Socket Layer) und IP Security (IPSec) durchgesetzt. Diese Protokolle sind standardisiert und mittlerweile weit verbreitet. Die Anforderungen an das Management, die aus dem hier Gesagten resultieren, sind genau genommen ein Kompromiss aus dem Wunsch nach reibungsloser Integration in bestehende SNMP-basierende Managementsysteme und der Forderung nach ausreichender Sicherheit. Es kann also auf einem VPNGerät durchaus SNMP unterstützt werden, jedoch mit der Einschränkung, dass die Konfiguration des Geräts abweichend vom Protokoll auf keinen Fall mit SNMP-Set-Befehlen durchgeführt werden darf, sondern über ein sicheres Protokoll erfolgen muss. In letzter Zeit hat sich das so genannte Web-based-Management immer weiter verbreitet. Hierbei greift man über einen Webbrowser direkt auf die Netzwerkgeräte zu, um sie zu konfigurieren oder abzufragen. Der Vorteil dieser
77
3 Anforderungen an VPNs
Methode besteht darin, mit dem Webbrowser eine grafische Benutzeroberfläche zu haben, mit der mittlerweile fast jeder umgehen kann und die praktisch auf jedem Arbeitsplatzrechner installiert ist. Ein weiterer Pluspunkt ist, dass neue Funktionen auf dem Gerät auch gleich in der grafischen Oberfläche verfügbar sind. In traditionellen SNMP-Umgebungen mit speziellen Netzwerkmanagement-Applikationen müssen die Funktionen dem Programm erst bekannt macht werden, bevor man sie benutzen kann. Vor allem mit grafischen Darstellungen, insbesondere in heterogenen Umgebungen, tun sich leider die meisten SNMP-Managementsysteme und die Gerätehersteller etwas schwer. Das Web-Management kann auch in Teilen kompatibel zu SNMP sein, indem der Browser intern die MIB dieses Geräts modifiziert oder abfragt und indem SNMP-Traps verwendet werden, um Alarmierungen abzusetzen. Allerdings ist das HTTP (Hyper Text Transfer Protocol), genau wie SNMP, alles andere als sicher: Man kann es relativ problemlos mitlesen oder verändern. Die Lösung dieses Sicherheitsproblems ist auch hier die Verwendung des SSL-Protokolls, das speziell zur sicheren Browser-Server-Kommunikation entwickelt wurde, oder – noch sicherer – der Einsatz von IPSec. Bei Einsatz und Kombination der richtigen, sicheren Übertragungsprotokolle steht also einem zeitgemäßen webbasierten Management der VPN-Komponenten nichts mehr im Wege. Überwachung Auch für die Überwachung von traditionellen Netzwerkkomponenten hat sich neben dem SNMP-Protokoll zunehmend das webbasierte Management durchgesetzt. Unter Überwachung versteht man in diesem Zusammenhang die gezielte, durch eine Managementstation oder einen Browser ausgelöste Abfrage von Systemparametern und das Versenden so genannter Traps, die von einem Netzwerksystem aufgrund eines kritischen Systemzustands ausgelöst wurden. Das gezielte Abfragen von MIB-Variablen in den Netzwerkkomponenten muss sowohl durch SNMP-Get-Befehle als auch durch einen Browser unterstützt werden. Auch hier gilt es Vorsicht walten zu lassen, falls man damit auch sicherheitsrelevante Parameter abfragt, denn jedermann, der Zugriff auf die Netzwerkverbindung zwischen VPN-Komponente und Managementstation hat, kann SNMP und HTTP mitlesen! Der Einsatz von sicheren Übertragungsprotokollen ist auch hier dringend angeraten. Die Erzeugung von SNMP-Traps zur Signalisierung von Alarmzuständen muss in jedem Fall unterstützt werden. Hier werden keine sicherheitsrelevanten Parameter ungeschützt übertragen. Es wird lediglich der Managementstation mitgeteilt, welches Problem wo aufgetreten ist. Spezielle sichere Übertragungsprotokolle sind hierfür nicht notwendig.
78
Integration in existierende Netze
Aber ein anderer Punkt verdient in diesem Zusammenhang Beachtung: SNMP definiert im Standard nur eine kleine Anzahl von Traps. Will man aber Traps erzeugen, die bei Eindringversuchen in das Netzwerk oder bei anderen einsatzspezifischen Vorfällen oder Situationen generiert werden, muss das VPN-System eine derart erweiterte SNMP-Funktionalität bieten. Generell sollte es möglich sein, für alle kritischen Zustände – und damit sind nicht nur Hardwareprobleme gemeint – die Generierung eines Traps konfigurieren zu können. Accounting Während in lokalen Netzwerken das Accounting, also die auf Benutzer, Organisationseinheiten oder Kostenstellen heruntergebrochene Abrechnung von Netzwerkdiensten, fast niemals eingesetzt wird, ist dies im WAN-Bereich immer öfter und beim Remote Access fast immer zu finden. Dies hat eine Reihe von Gründen. Im LAN-Bereich fallen keine zusätzlichen Übertragungskosten an, man kann eine Weiterverrechnung auf Basis von Netzwerkports, Plattenplatz, Geschwindigkeiten usw. durchführen. Des Weiteren bieten die meisten LAN-Komponenten zurzeit nur sehr rudimentäre oder gar keine Accounting-Möglichkeiten, so dass nicht selten die notwendigen technischen Möglichkeiten gar nicht gegeben sind. Im Bereich der öffentlichen Netze addieren sich zu den Kosten für das Equipment und den Betrieb die teilweise recht hohen Gebühren, die an die Carrier auf zeit- oder volumenabhängiger Basis zu entrichten sind. Diese Kosten will man in der Regel nicht in einem festen Verhältnis auf die Kostenstellen umlegen, da nicht jede Organisationseinheit die Dienste in gleichem Maße in Anspruch nimmt. Es sollen vielmehr die tatsächlich verursachten Kosten ermittelt und weiter verrechnet werden. Somit findet man insbesondere im Remote-AccessBereich Accounting-Funktionalitäten, die eine zeit- und volumenabhängige Abrechnung der Dienste ermöglichen. Auch im Bereich der traditionellen WAN-Router findet man zunehmend Abrechnungsfunktionen auf IP-Ebene. Löst man diese herkömmlichen Strukturen nun durch die VPN-Technologie ab, müssen diese Accounting-Systeme ebenfalls unterstützt werden, auch im parallelen Betrieb während der Migrationsphase. RADIUS (Remote Authentication Dial In User Service, ein Standard, der Protokolle und Funktionen zur Authentifizierung, Autorisierung und zum Accounting von Remote-AccessBenutzern beschreibt) hat sich im Laufe der Jahre zu einem weit verbreiteten Standard mit hoher Interoperabilität zwischen verschiedenen Herstellern entwickelt. Praktisch alle Remote-Access-Systeme, sowohl im Enterprise- als auch im Carrier-Umfeld, arbeiten mit RADIUS zur Benutzer-Authentifizierung und zum Accounting. Um die Datensätze auszuwerten, die von RADIUS-Servern erzeugt werden, gibt es mittlerweile eine Fülle von Programmen. Das Format eignet sich auch zum direkten Importieren in verbreitete Applikationen wie Datenbanken oder Tabellenkalkulationsprogramme.
79
3 Anforderungen an VPNs
Aus diesen Gründen liegt es auf der Hand, dass VPN-Systeme RADIUSAccounting unterstützen müssen. Dadurch können sie einfach und schnell in eine bestehende Infrastruktur integriert werden.
3.6.2
Sicherheit
Sicherheitsstrategie Ein VPN muss sich reibungslos in die Sicherheitsstrategie einer Organisation integrieren lassen. Die Sicherheitsstrategie, auch als Security Policy bezeichnet, ist eine unternehmensweite Definition von Sicherheitsanforderungen, die eine ganze Reihe von Bereichen abdecken müssen, wie zum Beispiel die Behandlung von Kennwörtern, physikalischer Zugangsschutz, Zugriffsregelung auf kritische Ressourcen usw. Sie beschreibt dabei sowohl die Anforderungen als auch die Zuständigkeitsbereiche für deren Umsetzung. Eine gute Sicherheitsstrategie definiert dabei nicht, welche Technologien eingesetzt werden, oder bestimmte Schlüssellängen, dies ist Aufgabe der für die Umsetzung verantwortlichen Organisationseinheiten. Die Security Policy legt lediglich fest, welche Daten über welchen Zeitraum, vor welchen potenziellen Angriffen und durch wen zu schützen sind. Dies klingt einfach und ist es auch. Was komplex ist, ist ihre konsistente Umsetzung. Eine Sicherheitsstrategie legt zum Beispiel fest, dass die Konstruktionsdaten eines Unternehmens mindestens zwanzig Jahre auch vor Zugriffen durch fremde Geheimdienste sicher sein müssen, und benennt optional noch die dafür verantwortlichen Organisationseinheiten. Das war es auch schon, denn die Umsetzung obliegt den betroffenen Organisationseinheiten, die mit diesen Daten umgehen. Im Netzwerkbereich leiten sich daraus die entsprechenden Kriterien ab, um die Übertragungen sowohl im Intranet als auch im Weitverkehrsnetz oder VPN durch starke Verschlüsselung zu schützen. Authentifizierung Üblicherweise sind für Benutzer, die sich per Remote Access in das Unternehmensnetzwerk einwählen, in der Sicherheitsstrategie bestimmte Anforderungen hinsichtlich der Authentifizierung festgelegt. Im lokalen Netzwerk kann man sich ohne besondere Authentifizierung anschließen, denn hier sieht die Security Policy des Unternehmens in der Regel einen physikalischen Zugangsschutz vor, meist per Magnetkarte am Eingang der Gebäude. Dieser Zugangsschutz entfällt beim Remote Access natürlich und muss durch besondere Verfahren zur Identitätsfeststellung nachgebildet werden. Dies trifft auf den traditionellen Remote Access und Remote-Access-VPNs gleichermaßen zu.
80
Integration in existierende Netze
Firewalls In den meisten Organisationen wird heute ein Internetanschluss betrieben. Da man aus Sicherheits- und anderen Gründen (z.B. wegen der Verwendung privater, nicht registrierter IP-Adressen) sein Intranet nicht direkt mit dem Internet verbinden kann, wird diese Funktion in der Regel von so genannten Firewalls vorgenommen. Eine Firewall kontrolliert den gesamten Datenverkehr zwischen Systemen im Internet und dem Intranet. Sie soll einerseits verhindern, dass sich Unbefugte Zugang zum Intranet verschaffen, und andererseits den Datenverkehr kontrollieren, den Systeme im Intranet in das Internet leiten. Hierbei werden die Datenpakete sogar bis auf die Ebene der Dateninhalte geprüft, um zum Beispiel Webseiten mit moralisch fragwürdigem Inhalt zu sperren. Der wichtige Punkt hierbei ist, dass eine Firewall den Verkehr in das Internet kontrolliert. Ein Internet-VPN greift hingegen auf kein einziges Internet-System zu, sondern es benutzt das Internet lediglich als Transportmedium für IP-Pakete. Dies ist eine völlig andere Situation, da die IP-Pakete ausschließlich im privaten Bereich versendet und empfangen werden. Querverbindungen in das Internet sind bei einigen sehr guten, dedizierten VPN-Systemen überhaupt nicht möglich. Aus diesem Grund macht es auch wenig Sinn (und kann von Fall zu Fall sogar Probleme bereiten), wenn man beide Funktionalitäten auf einem System zusammenführt, egal ob man VPN-Funktionen in eine Firewall integriert oder umgekehrt eine Firewall in einen VPN-Konzentrator. Vielmehr ist zu fordern, dass der VPN-Konzentrator als Ablösung klassischer Netzwerkkomponenten wie Router oder Remote-Access-Konzentratoren und die Firewall gleichzeitig nebeneinander zu betreiben sind. PKI Technologien wie E-Business oder E-Commerce und neu geschaffene rechtliche Rahmenbedingungen für digitale Unterschriften haben zusammen mit einem gestiegenen Sicherheitsbedürfnis bei der Benutzung öffentlicher Netze eine Reihe von Applikationen hervorgebracht, die mit elektronischen, digitalen Schlüsseln Daten verschlüsseln oder Dokumente signieren. Bei großen Organisationen fallen dabei eine ganze Reihe verschiedener Schlüssel an, die erzeugt, verwaltet, regelmäßig erneuert und vor allem eindeutig bestimmten Personen zugeordnet werden müssen. Eine Public-Key-Infrastruktur (PKI) leitet ihren Namen von der so genannten Public-Key-Kryptographie (vgl. Kapitel 4) ab, bei der mit zwei verschiedenen Schlüsseln, einem öffentlichen und einem privaten, gearbeitet wird. Mit einem Schlüssel (Public Key, dem öffentlichen Schlüssel) wird verschlüsselt und mit dem anderen (Private Key, dem privaten, geheimen Schlüssel) wieder
81
3 Anforderungen an VPNs
entschlüsselt. Die beiden Schlüssel bilden ein Paar; der öffentliche Schlüssel ist jedermann zugänglich und ist fest an eine Person gebunden, und der private wird von der Person geheim gehalten. Etwas, das mit dem einen Schlüssel verschlüsselt wurde, kann nur mit dem korrespondierenden anderen Schlüssel wieder entschlüsselt werden. Die Bindung einer Person an einen öffentlichen Schlüssel erfolgt über ein so genanntes digitales Zertifikat. Die Erzeugung und Verwaltung dieser Zertifikate, die Registrierung der Benutzer und das Erzeugen und Speichern von Schlüsselpaaren zum Zweck der Datenverschlüsselung auf Rechnern ist die Hauptfunktion einer PKI. Diese kann sowohl von einem Unternehmen selbst betrieben werden, oder man benutzt eine öffentliche PKI. Falls nun digitale Zertifikate zum digitalen Signieren eingesetzt werden, liegt es auf der Hand, diesen Mechanismus auch zur Authentifizierung von Benutzern oder VPN-Systemen einzusetzen. Hier sollten die VPN-Geräte und die Clientsoftware eine entsprechende Unterstützung bieten.
3.7
Koexistenz zu traditionellen WAN-Strukturen
Üblicherweise findet nicht immer sofort eine Ablösung von traditionellen Netzen durch virtuelle private Netze statt. Vielmehr müssen beide für eine gewisse Migrationsphase gleichzeitig zu betreiben sein. Typische Fälle sind der gleichzeitige Einsatz von VPNs und Frame-Relay- oder ATM-Netzen, da es oft der Fall ist, dass die beiden letztgenannten Technologien nicht an jedem benötigten Standort zur Verfügung stehen. Auch normaler Remote Access per Einwahl über das Telefonnetz wird sehr oft parallel zum VPN-Remote-Access betrieben. Hier sollen aus Kostengründen zwar möglichst viele Verbindungen über das VPN laufen, jedoch nutzt man den Einwählteil oft als Backup oder für bestimmte kritische Applikationen, die eine garantierte Einwahl und bestimmte Qualitätsmerkmale benötigen. Um das Ratiopotenzial eines VPN voll ausschöpfen zu können, dürfen Einsparungen, die auf der einen Seite durch geringere Gebühren und günstigeres Equipment erzielt wurden, nicht durch andere, durch die VPN-Technologie anfallende, neue Kosten zunichte gemacht werden. Solche Kosten sind oft versteckt und auf den ersten Blick vielleicht gar nicht mit dem Einsatz eines VPN in Zusammenhang zu bringen. Einer der negativen Kostenfaktoren, vielleicht der schwerwiegendste, sind erhöhte Managementkosten. Diese können erzeugt werden, wenn sich die VPN-Systeme nicht in das vorhandene Netzwerkmanagement integrieren lassen und ein paralleles Management aufgebaut wird.
82
Adressmanagement
Auch Zusatzkosten durch möglicherweise erforderliche IP-Adressänderungen in einem großen Netzwerk sollten vermieden werden, indem man die VPN-Technologie in bestehende Strukturen integriert und nicht umgekehrt bestehende Strukturen an das VPN anpasst.
3.8
Adressmanagement
Das IP-Adressmanagement ist in vielen Unternehmen zunehmend zu einem kritischen Faktor geworden. Dies hat historische Gründe, die mit der Entwicklung und Einführung des IP-Protokolls zu tun haben. IP war viele Jahre ein Protokoll, das fast ausschließlich im Internet eingesetzt wurde. Die Folge war, dass alle beteiligten Geräte offizielle IP-Adressen und etliche Organisationen und Firmen offizielle IP-Netze zugeteilt bekamen. Als TCP/IP praktisch Bestandteil von Unix wurde, es als kostenloser Zusatz für Windows 3.x verfügbar war und Betriebssysteme wie VM oder OS/400 von IBM ebenfalls damit ausgerüstet wurden, gab es ein paar Entwicklungen, an denen viele Unternehmen heute noch zu knabbern haben. Denn in vielen Firmen begannen sich regelrechte »IP-Inseln« zu bilden, oft mit selbst vergebenen, nicht registrierten Adressbereichen. Zuerst wollte man überhaupt keinen Internetzugriff, im Zeitalter des World Wide Web wurde dieser Wunsch von den Anwendern jedoch immer dringlicher vorgetragen. Als Ausweg boten sich Firewalls mit NAT (Network Address Translation, Umsetzung von nicht registrierten in offizielle IP-Adressen) an. Im Intranet der Unternehmen wurden bis dato die IP-Adressen manuell vergeben und statisch auf den Systemen eingetragen. Dokumentiert wurde meist nichts, und wenn doch, dann waren die Daten oft nicht aktuell und unvollständig. Im Verlauf dieser und anderer Entwicklungen wurde der Ruf nach einem einfachen und automatischen Management der IP-Adressen immer lauter. Das Resultat war das DHCP (Dynamic Host Configuration Protocol), ein Verfahren mit dem IP-Schnittstellen automatisch und dynamisch von einem speziellen Server konfiguriert werden. DHCP ist eine Client-Server-Applikation, bei der die Clients beim Start eines Rechners mit einer IP-Schnittstelle von einem DHCP-Server eine IP-Adresse und weitere optionale Konfigurationsparameter anfordern. Es hat mittlerweile eine recht breite Verwendung gefunden. Neben Implementierungen in PC-Betriebssystemen gibt es auch professionelle, hoch skalierbare Systeme, die mit relationalen Datenbanken arbeiten, und einen dynamischen DNS-Server (Domain Name System, ein Verfahren, um Systeme statt mit ihrer IP-Adresse über einen Namen anzusprechen) integriert haben, der die sich ändernden IP-Adressen immer dem korrekten Domainnamen zuordnet.
83
3 Anforderungen an VPNs
VPNKonzentrator
IPSecClient
Intranet
Internet Offizielle, statische IP-Adresse
DHCPServer
Dynamische, offizielle, vom Provider zugewiesene IP-Adresse
DHCP-Request Die private IP-Adresse wird dem Client über das IKE-Protokoll für die Dauer der Verbindung zugewiesen
DHCP-Offer mit einer privaten IP-Adresse für den Client
Abbildung 3.7: Das IP-Adressmanagement in IP-VPNs muss gut geplant werden.
Viele heute eingesetzte Remote-Access-Konzentratoren verwenden DHCP, um den Clientrechnern eine IP-Adresse dynamisch zuzuweisen. Diese Funktionalität muss ein VPN-Konzentrator ebenfalls unterstützen, um in das unternehmensweite IP-Adressmanagement integrierbar zu sein. Idealerweise ist sowohl ein gerichtetes DHCP möglich, bei dem sich die Systeme an dedizierte DHCP-Server wenden, als auch ein ungerichtetes, bei dem per Netzwerkbroadcast ein passender Server gesucht wird. Die Anforderungen im Bereich der IP-Adressverwaltung beschränken sich jedoch keinesfalls nur auf DHCP, es müssen auch andere Mechanismen zur Zuteilung von IP-Adressen unterstützt werden. Hierbei resultieren die Anforderungen sowohl aus der aktuellen Managementumgebung als auch aus zukünftig einzusetzenden Systemen. Insbesondere arbeiten viele RemoteAccess-Konzentratoren mit RADIUS-Servern, auf denen neben der Authentifizierung und dem Accounting auch IP-Adressen userbezogen oder aus einem so genannten Pool heraus vergeben werden. Auch eine gerätesspezifische Vergabe von IP-Adressen auf Basis von Benutzernamen oder aus einem Pool sollte von einem modernen VPN-Konzentrator unterstützt werden. Directory Services (Verzeichnisdienste) erfreuen sich in der Fachwelt einer immer größeren Beliebtheit. Nachdem in der Vergangenheit einige proprietäre Verfahren wie Novell NDS oder Banyan Streettalk und Standards wie X.500 miteinander konkurriert hatten, konzentriert sich die Entwicklung momentan auf das Lightweight Directory Access Protocol (LDAP). Es wird mittlerweile von allen Größen der Netzwerkindustrie sowohl im Bereich der Betriebssysteme als auch im Bereich der Netzwerkkomponenten und Managementsys-
84
Interoperabilität
teme eingesetzt. LDAP ist sehr flexibel und bietet einen fest spezifizierten Satz von Funktionen und Formaten zum Erzeugen, Modifizieren, Abfragen und Löschen von Einträgen in der Verzeichnisdatenbank. Die Struktur eines Verzeichnisses ist frei wählbar und kann somit maßgerecht an unterschiedliche Bedürfnisse angepasst werden. Ein VPN-System, das auch noch in der Zukunft einsetzbar sein soll, muss daher ebenfalls LDAP unterstützen können, um in unternehmensweite Verzeichnisdienste integrierbar zu sein.
3.9
Interoperabilität
Interoperabilität ist eine wichtige und kritische Anforderung an heutige VPNKonzentratoren und VPN-Gateways. Dies hat gleich mehrere Gründe. Je nach Auswahl eines geeigneten Tunneling-Modells (vgl. Kapitel 6) können mehrere Partner an einem VPN beteiligt sein (zum Beispiel ein Internet Service Provider und der Endkunde), die unter Umständen Equipment verschiedener Hersteller einsetzen. Ein anderes Beispiel für die Notwendigkeit der Interoperabilität verschiedener VPN-Systeme ist die Dynamik im Bereich von Firmenzusammenschlüssen oder Kooperationen, die in der heutigen Zeit zu beobachten ist. Hierbei können in den unterschiedlichen Unternehmen Anforderungen der Art entstehen, dass die eingesetzten VPN-Geräte miteinander kommunizieren müssen. Das Automotive Network Exchange (ANX) ist beispielsweise ein VPN, das für Automobilhersteller und Zulieferer mit unterschiedlichsten Geräten auf der Basis des IPSec-Protokolls betrieben wird. Dies erfordert, dass das jeweils verwendete Equipment mit den Gegenstellen interoperabel ist. Die Lösung besteht darin, ausschließlich solche Protokolle einzusetzen, die standardisiert und allgemein akzeptiert sind. Leider hat die Vergangenheit gezeigt, dass auch standardkonforme Implementierungen bestimmter Datenkommunikationsprotokolle keineswegs ein Garant für eine reibungslose Kommunikation sind. Dies liegt an der Tatsache, dass viele Protokolle sehr flexibel sein müssen und gegebenenfalls so konfiguriert werden können, dass eine Kommunikation mit anders konfigurierten Gegenstellen unmöglich ist. Wichtig ist daher, dass es eine oder mehrere mögliche Konfigurationen der Protokolle gibt, bei denen eine Interoperabilität gewährleistet oder sogar nachgewiesen ist. Insbesondere im Bereich des IPSec-Protokolls ist dies zu fordern. ICSA.net ist eine sich selbst als unabhängig bezeichnende Firma, die sich mit Internet-Sicherheit beschäftigt. Die ICSA Labs führen Tests durch, die die Funktionalität und Interoperabilität von IPSec-Implementierungen ermitteln sollen. Geräte oder Programme, die erfolgreich getestet wurden, dürfen
85
3 Anforderungen an VPNs
das ICSA-IPSec-Logo tragen und sind, was viel wichtiger ist, mit einer sehr hohen Wahrscheinlichkeit zu anderen zertifizierten Systemen interoperabel.
86
4
Sicherheitstechnologie
In diesem Kapitel werden die Sicherheitsaspekte beim Einsatz von VPNs betrachtet und die hierfür eingesetzten Technologien ausführlich behandelt. Zuerst erfolgt ein allgemeiner Überblick, mit welchen Techniken die Sicherheitsanforderungen erfüllt werden, die wir im vorangegangenen Kapitel an virtuelle private Netzwerke gestellt haben. Anschließend werden die Grundlagen für diese Technologien ausführlich behandelt, wobei jedoch immer der aktuelle Bezug zum Thema VPNs bestehen bleibt. Insbesondere werden nur solche Algorithmen und Verfahren besprochen, die in aktuellen Netzwerk-Sicherheitsprotokollen verwendet werden, so dass hier auch nur Teilaspekte der Kryptologie behandelt werden. Allgemeine und umfassende Grundlagen zum Thema Kryptologie und verwandte Themen finden Sie in der weiterführenden Literatur hierzu.
4.1
Sicherheit in VPNs
Dieses Thema kann und darf nicht isoliert betrachtet werden. Es ist ein integraler Bestandteil der Netzwerksicherheit, die wiederum nur ein kleiner Teil einer unternehmensweiten Sicherheitsstrategie ist.
4.1.1
Sicherheit in Unternehmensdatennetzen
Der Aspekt Sicherheit spielte in der Vergangenheit aufgrund der Begrenzung der Datennetze auf das Unternehmensgelände und der noch übersichtlichen Anzahl von Weitverkehrsverbindungen eine eher untergeordnete Rolle. Ausgelöst durch veränderte Arbeits- und Kommunikationsweisen beginnt sich dies zu ändern. 왘 Die Zahl der so genannten Remote-Access-Nutzer, also der Mitarbeiter, die
von unterwegs, von einer Außenstelle oder von zu Hause aus Zugriff auf Daten des Firmennetzes benötigen, steigt kontinuierlich. Damit ist das Firmennetz nicht mehr länger auf den Campus begrenzt, sondern es müssen eine Vielzahl von Remote-Access-Verbindungen eingerichtet, betrieben und überwacht werden. 왘 Immer mehr Unternehmen öffnen ihre Firmennetze für Zulieferer, Partner
und Kunden bzw. bieten ihre Produkte auf elektronischem Weg zum Verkauf an. Hierfür sind nationale und internationale Verbindungen notwendig. Da der Aufbau bzw. das Anmieten eines eigenen Leitungsnetzes aber
87
4 Sicherheitstechnologie
für die wenigsten Firmen rentabel ist, werden für solche Anwendungen vermehrt öffentliche Netze wie das Internet oder Teilkapazitäten öffentlicher Netze als so genannte virtuelle private Netze genutzt. 왘 Gleichzeitig hat das Netz für den wirtschaftlichen Erfolg des Unterneh-
mens einen weit höheren Stellenwert als in der Vergangenheit. Denn je mehr geschäftskritische Anwendungen darüber miteinander kommunizieren und je mehr unternehmenskritische Ressourcen daran angeschlossen werden, desto mehr wird das Netz selbst zum geschäftsbestimmenden Faktor. Damit stellt sich automatisch die Frage nach der Datensicherheit und anderen mit ihr zusammenhängenden Aspekten wie Sicherung des Netzzugangs, Systemsicherheit auf Rechner- und Programmebene oder Zugriffsschutz auf gespeicherte Informationen. Datensicherheit ist ein komplexes Thema. Zum einen, weil die Sicherheitstechnologien selbst komplex sind und unterschiedliche Funktionen – und damit einen unterschiedlichen Grad an Sicherheit – bieten. Zum anderen, weil die Datensicherheit immer auch vom Gesamtsicherheitskonzept des Unternehmens betroffen ist. Insofern muss der Einführung von Sicherheitstechnologien eine Sicherheits- beziehungsweise Gefahrenanalyse vorausgehen, die wenigstens folgende Fragen beantworten sollte: 왘 Was ist wem gegenüber wie lange vertraulich zu behandeln? 왘 Welche Maßnahmen müssen von wem dementsprechend eingeleitet wer-
den, und was dürfen sie kosten? 왘 Welche Risiken bestehen für das Unternehmen und wie sind sie zu bewer-
ten? Geschützt werden müssen im Wesentlichen die Systemhardware und -software sowie die Daten selbst. Dabei geht man meist davon aus, dass die Daten das am meisten bedroht sind. Die Hardware kann in Sicherheitsbereichen oder im Hot-Standby-Mode betrieben werden, so dass Angriffe, sofern sie überhaupt möglich sind, schnell bemerkt und aufgefangen werden können. Das gleiche gilt für die Software, die auf diesen Systemen läuft. Viele Daten müssen vertraulich sein, also vor Ausspähung geschützt werden. Und sie müssen integer sein, also vor unerlaubten Veränderungen geschützt werden. Gleichzeitig müssen Daten aber auch verfügbar sein. Hier liegt das Problem, denn 100% sichere Daten sind nicht mehr verfügbar, und 100% verfügbare Daten sind nicht mehr sicher. Als praktikable Lösung bleibt demzufolge nur ein Kompromiss zwischen Verfügbarkeit und Sicherheit.
88
Sicherheit in VPNs
Aus diesem Grund muss der Einführung von Sicherheitstechnologien zunächst eine Datenanalyse vorausgehen, die Fragen wie diese beantwortet: 왘 Welche Arten von Daten sind im Unternehmen vorhanden? 왘 Wie sicher müssen diese Daten sein? 왘 Vor wem müssen sie sicher sein? 왘 Wie hoch sind die Verletzungen der Sicherheit zu bewerten? 왘 Wie lange muss die Sicherheit, insbesondere die Vertraulichkeit, gewähr-
leistet sein – Stunden, Tage, Wochen, Monate, Jahre oder Jahrzehnte? 왘 Zu welchem Preis (Kosten, Verfügbarkeit, Benutzbarkeit) dürfen diese
Ziele erreicht werden? Die Konzernbilanz eines Unternehmens muss in der Regel nur kurze Zeit vertraulich behandelt werden, und selbst wenn während dieser Zeit Einzelheiten an die Öffentlichkeit dringen, wäre das Unternehmen dadurch nicht unbedingt existenziell gefährdet. Wenn andererseits aber Firmengeheimnisse wie Entwicklungsdaten, Patente oder vergleichbar sensible Informationen bekannt werden, kann das Unternehmen erheblichen Schaden davontragen, ja sogar in seiner Existenz gefährdet sein. Ebenso hat die Analyse, von wem ein Unternehmen bedroht wird, starke Auswirkungen auf die einzuführende Sicherheitstechnologie. Eine Firma, die von einer Privatperson angegriffen wird, muss sich weniger schützen als eine, die befürchten muss, von einem Konkurrenzunternehmen oder gar von einem Geheimdienst ausgespäht zu werden. Denn letzteren stehen für einen Angriff ganz andere finanzielle Mittel und technische Ressourcen zur Verfügung als einer Privatperson. Entsprechend mehr Sicherheit zu höheren Kosten wird sich das betroffene Unternehmen anschaffen müssen. Aspekte dieser Art wirken sich direkt auf technische Details aus, zum Beispiel auf die Schlüssellänge bei der Datenverschlüsselung, auf das einzusetzende Verschlüsselungsverfahren oder auf die Kombination von mehreren Sicherheitstechnologien. Nicht zu unterschätzen ist darüber hinaus der Einfluss, den die Anschaffung neuer sicherheitsrelevanter Technologien, wie zum Beispiel virtueller privater Netzwerke auf bereits vorhandene Einrichtungen hat, vor allem wenn durchgängige Sicherheitskonzepte in einer verteilten Systemumgebung realisiert werden sollen. Beispielsweise können aus technischen Gründen bestimmte Authentifizierungsverfahren nicht zusammen mit bestimmten Benutzer- oder Passwort-Verwaltungssystemen eingesetzt werden. Um auszuschließen, dass sich Neuanschaffungen negativ auf vorhandene Technologien auswirken oder gar neue Bedrohungen nach sich ziehen, sollte vorab geklärt werden:
89
4 Sicherheitstechnologie
왘 wie die augenblickliche Systemsicherheit, insbesondere die Zugriffskon-
trolle auf Rechner- und Programmebene, realisiert ist, 왘 wie die Datensicherheit, also die Zugangskontrolle auf Dateiebene, organi-
siert ist, 왘 ob und welche Zugangskontrollen es zu Gebäuden, Räumen oder Zonen
gibt und 왘 welche gesetzlichen Auflagen und betrieblichen Zwänge bei der Einfüh-
rung berücksichtigt werden müssen. Außerdem müssen verbindliche Richtlinien darüber existieren, wer für die Sicherheit verantwortlich ist. Hiervon sind alle Mitarbeiter einer Organisation betroffen, von den Systemadministratoren und Netzverantwortlichen bis hin zu jedem Endbenutzer. Denn was nutzt das ausgefeilteste und teuerste Netzund Systemzugangskonzept, wenn der Mitarbeiter sein Passwort an den PCBildschirm klebt.
4.1.2
Die Sicherheit von virtuellen privaten Netzen
Ein entscheidendes Kriterium beim Entwurf einer Kommunikationsinfrastruktur, die öffentliche Netze benutzt, sei es ISDN, PSTN, GSM, ein ProviderNetzwerk oder das Internet, ist die Sicherheit der zu übertragenden Daten. Diese müssen insbesondere gegen Verletzungen der Vertraulichkeit und der Integrität hinreichend geschützt werden, gefolgt von flankierenden Maßnahmen zum Schutz vor Denial-of-Service- und Replay-Angriffen und weiteren ähnlich gearteten Attacken. Die Anforderungen an die Sicherheit eines VPN leiten sich aus der Sicherheitsstrategie (Security Policy) oder den allgemeinen Anforderungen an die Sicherheit des Unternehmensnetzwerks ab. In der Vergangenheit wurde dies, meist weil die geeignete Technologie fehlte, durch die Verschlüsselung von einzelnen Teilstrecken, durch die Verbindungsverschlüsselung (Link-Encryption) oder die Verschlüsselung auf Applikationsebene gelöst. Mit der Verbindungsverschlüsselung werden die Verbindungen zwischen Vermittlungs- oder Übertragungssystemen oder die Pakete auf der Verbindungsschicht, der Schicht 2 des OSI-Schichtenmodells, verschlüsselt. Das immanente Sicherheitsproblem hierbei liegt in der Dynamik heutiger Netzwerke. Auf der Ebene der Netzwerk-Infrastruktur werden laufend neue Strecken hinzugefügt oder geändert, und die Vermittlungssysteme, die zwischen den verschlüsselten Links sitzen, befinden sich nicht im Einflussbereich des Endteilnehmers beziehungsweise des Endkunden. Auf diesen Vermittlungssystemen liegen die Daten aber unverschlüsselt vor, da ja nur auf den Verbindungswegen selbst verschlüsselt wird. Ein weiteres Problem der Verbindungsverschlüsselung ist die automatische Wegewahl (Routing)
90
Sicherheit in VPNs
beim Transport von Paketen durch ein Netzwerk, die bei modernen gerouteten Netzwerken nicht mehr vorherbestimmbar ist. Somit besteht die Gefahr, dass Daten über nicht verschlüsselte Teilstrecken transportiert werden. Vom Standpunkt der Datensicherheit wäre die beste Methode eine Ende-zuEnde Verschlüsselung auf Applikationsebene. Dies ist aber technisch und organisatorisch nicht mehr handhabbar, insbesondere wenn man viele verschiedene Applikationen einsetzt und diese einer gewissen Dynamik unterworfen sind. Die Lösung heißt hier Verschlüsselung auf Netzwerkebene, also auf der Schicht 3 des OSI-Schichtenmodells. Hier kann man, je nach Anforderung und Infrastruktur, auch gemischt Sicherheit von Rechner zu Rechner, von Rechner zu Netzwerk oder von Netzwerk zu Netzwerk realisieren. Die Sicherheit auf höheren Ebenen anzusiedeln, hat für ein virtuelles privates Netzwerk schon wieder mehr Nach- als Vorteile, da hierbei wieder niemals alle Daten verschlüsselt werden können. Ein VPN ist ein Netzwerk oder zumindest ein Teil eines Gesamtnetzwerks, also ist die notwendige Sicherheitstechnologie auch auf dieser Ebene, der Netzwerkebene, anzuwenden. Da die Sicherheit des Datentransports in einem IP- oder Internet-VPN so wichtig ist, werden einige Aspekte und Lösungen im Folgenden detailliert erläutert.
4.1.3
Datenvertraulichkeit
Die Datenvertraulichkeit ist eine wichtige Anforderung an virtuelle private Netze, falls die Daten, die darüber transportiert werden, im Klartext vorliegen und vertraulich oder sogar geheim sind. Es darf also kein Unbefugter Daten, die er sich durch geeignete Abhörmaßnahmen verschafft hat, lesen können. Dies erreicht man durch eine Verschlüsselung der Informationen durch den Absender. Der Empfänger macht die Informationen durch eine Entschlüsselung wieder lesbar. Die technischen Details einer solchen Verschlüsselung werden im Laufe dieses Kapitels noch eingehend behandelt werden. Es gibt mehrere Ansätze zur verschlüsselten Übertragung von Daten, die sich im Wesentlichen darin unterscheiden, auf welcher Ebene des OSI-Schichtenmodells sie eingesetzt werden. Die unterschiedlichen Möglichkeiten sind: 왘 Verschlüsselung auf Ebene 1, der physikalischen Schicht (z.B. Lichtwellen) 왘 Verschlüsselung auf Ebene 2, der Sicherungsschicht ( z.B. PPP) 왘 Verschlüsselung auf Ebene 3, der Vermittlungsschicht (z.B. IP, IPX) 왘 Verschlüsselung auf Ebene 4, der Verbindungsschicht (z.B. TCP, UDP, SPX)
91
4 Sicherheitstechnologie
왘 Verschlüsselung auf Ebene 5, der Sitzungsschicht (z.B. HTTP) 왘 Verschlüsselung auf Ebene 6, der Darstellungsschicht 왘 Verschlüsselung auf Ebene 7, der Applikationsschicht (z.B. PGP)
Für ein Internet-VPN kommt man sehr schnell zu der Erkenntnis, dass eine Verschlüsselung auf der Vermittlungsschicht, also auf der Ebene des IP-Protokolls, das Sinnvollste und Sicherste ist. Warum ist dies so? Sehen wir uns zuerst einmal die Möglichkeiten an, auf den unteren Ebenen 1 und 2 zu verschlüsseln. Dabei verschlüsseln wir Datenleitungen oder Datenrahmen auf der Sicherungsschicht. Wer eine solchermaßen verschlüsselte Leitung abhört, kann mit den abgefangenen Daten nichts anfangen. Aber in den Vermittlungssystemen liegen die Daten im Klartext vor, da sie in der Schicht 3 verarbeitet werden, an die sie daher unverschlüsselt von der Sicherungsschicht geliefert werden müssen. Jemand, der sich Zugriff auf ein solches System verschafft, kann auch auf die unverschlüsselten Informationen zugreifen. Ein anderes Problem besteht darin, dass in modernen Netzen eine dynamische Wegwahl für die Datenpakete erfolgt, um sie so schnell und so kostengünstig wie möglich zu transportieren. Daraus folgt aber auch, dass der Weg, den die Datenpakete nehmen, nicht vorherbestimmbar ist und deshalb alle möglichen Teilstrecken verschlüsselt werden müssen. Das ist aufgrund der Komplexität weder im Internet noch in Frame-Relay- oder ATM-Netzen realisiert und wird dort auch nicht realisiert werden. Setzen wir nun an anderer Stelle an, und schauen wir uns einmal die Verschlüsselung auf den höheren Ebenen, also den Schichten 4 bis 7 an. Im Extremfall (Schicht 7) erfolgt die Ver- und Entschlüsselung durch die Anwendungen. Es müssen dabei natürlich alle möglichen Anwendungen mit den entsprechenden Funktionen ausgerüstet werden, um den gesamten Datenverkehr sicher zu machen, was sowohl technisch als auch organisatorisch nicht möglich ist. Auch auf tieferen Ebenen bleibt immer das Problem bestehen, dass alle gleichzeitig betriebenen Anwendungen, Protokolle und Verbindungen mit entsprechenden Verschlüsselungsfunktionen ausgerüstet sein müssen, sollen nicht einige Informationen doch noch im Klartext übertragen werden. Die Ebene 3 weist in einem IP- oder Internet-VPN diese ganzen Nachteile nicht auf, da dort nur ein einziges Protokoll, nämlich das Internet-Protokoll (IP), betrieben wird. Integriert man seine Sicherheitstechnologie in das IP-Protokoll, dann werden alle Datenpakete dieses Protokolls von den eingesetzten Sicherheitsverfahren bearbeitet, unabhängig von der darunter liegenden Infrastruktur und unabhängig von den Anwendungen darüber. Wie eingangs erwähnt, kann man in einigen wenigen, speziellen und klar abgegrenzten Fällen auch ohne IP-Sicherheitstechnologie in Internet-VPNs auskommen – und zwar dann, wenn alle Applikationen oder Protokolle, die das
92
Sicherheit in VPNs
VPN benutzen, bereits entsprechende Sicherheitsfunktionen unterstützen. Falls zum Beispiel in einem Remote-Access-VPN die Benutzer ausschließlich webbasierende Anwendungen und E-Mail benutzen, dann kann man bei der Verwendung des SSL-Protokolls und eines sicheren Mailsystems wie zum Beispiel PGP (Pretty Good Privacy, ein kryptographisch geschütztes Mailsystem) die notwendige Sicherheit auch ausschließlich auf höheren Ebenen des OSISchichtenmodells ansiedeln. Aber wehe, wenn auch nur einer der Benutzer in einem derart aufgebauten VPN ein anderes Kommunikationsprogramm benutzt. Dann ist alles, was damit übertragen wird, ungesichert!
4.1.4
Sicherheit in der Netzwerkschicht mit IP Security
Da man beim Design eines VPN auf Skalierbarkeit und Migrationsfähigkeit Wert legen sollte, ist es ein Muss, so weit es irgend möglich ist, mit Standards zu arbeiten. Der Standard für Sicherheit auf der IP-Ebene heißt IP Security oder kurz IPSec. In ihm sind verschiedene Verschlüsselungs- und Authentifizierungsverfahren sowie Schlüsseltausch- und Schlüsselverwaltungsprotokolle festgelegt, die bei korrekter Implementierung eine hohe Interoperabilität gewährleisten. Im Folgenden werden die für ein IP-VPN essenziellen Sicherheitsmerkmale dieses relativ neuen Protokolls behandelt, in Kapitel 7 werden die technischen Aspekte des IPSec-Protokolls ausführlich beschrieben. Datenverschlüsselung in IPSec In IPSec können die Daten auf verschiedene Arten verschlüsselt werden, also mit den unterschiedlichsten Algorithmen und unterschiedlichen Schlüssellängen. Wichtig dabei ist, dass sich die beteiligten Gegenstellen immer auf ein Verfahren einigen können. Aus diesem Grund gibt es einen Verschlüsselungsalgorithmus, der von jeder IPSec-Implementierung unterstützt werden muss, den Data Encryption Standard (DES) mit seiner festen Schlüssellänge von 56 Bit. Viele Implementierungen bieten auch optional das stärkere Triple-DESVerfahren mit einer Schlüssellänge von insgesamt 168 Bit, es ist jedoch nicht vom Standard vorgeschrieben. Um zu vermeiden, dass identische Klartextblöcke nach der DES-Verschlüsselung identische Chiffretextblöcke erzeugen, ist in IPSec das so genannte Cipher-Block-Chaining-Verfahren (CBC) vorgeschrieben, das diesen Mangel von DES behebt. Datenintegrität und Datenauthentizität in IPSec Die Datenintegrität, also der Schutz vor unerlaubter und unbemerkter Veränderung der Datenpakete, wird in IPSec durch spezielle, kryptographisch geschützte Prüfsummen, genannt HMAC (Hash-based Message Authentication Code, Prüfsummen, die durch Hashfunktionen berechnet wurden), erreicht. Das gleiche Verfahren garantiert auch die Feststellung der Authentizität eines IP-Pakets. HMACs basieren auf Einwegfunktionen, die aus den zu
93
4 Sicherheitstechnologie
schützenden Daten und einem Schlüssel einen Wert erzeugen, der nicht mehr zurückzuberechnen ist, auch nicht bei Kenntnis eines der Eingangsparameter. In IPSec werden zwei Funktionen vorgeschrieben, HMAC-MD5 und HMAC-SHA-1, die auf den Hashfunktionen MD5 und SHA-1 aufgebaut sind und mit symmetrischen Schlüsseln von 128 Bit Länge arbeiten. Auch in diesem Bereich garantiert der Standard eine hohe Interoperabilität. Schlüsselmanagement in IPSec Die Verfahren zur Datenverschlüsselung, Authentifizierung und Integritätsprüfung benötigen auf beiden Seiten einer so genannten IPSec-Sicherheitsassoziation jeweils die gleichen Schlüssel. Der DES-Algorithmus benötigt auf der Empfängerseite den gleichen 56 Bit großen Schlüssel zum Entschlüsseln, mit dem der Sender die Daten verschlüsselt hat. Ebenso benötigt z.B. HMACMD5 auf beiden Seiten einen identischen 128 Bit langen Schlüssel zur Integritätsprüfung und Authentifizierung. Wie kommen die Schlüssel dort hin, und wie werden sie geändert? Der IPSec-Standard erlaubt unter anderem die Möglichkeit, dies manuell zu tun. Manuelle Verfahren oder die Übertragung über ein anderes Medium sind aber, vor allem in großen Netzen, nicht praktikabel und oft unsicher. Die Lösung in IPSec ist ein spezielles Protokoll, das über ein unsicheres Übertragungsmedium, in der Regel die zu verwendende Übertragungsstrecke selbst, mit Hilfe eines so genannten asymmetrischen Verschlüsselungsverfahrens die benötigten Schlüssel überträgt beziehungsweise erzeugt. Dieses Protokoll, IKE (Internet Key Exchange), erledigt nicht nur das Schlüsselmanagement, sondern auch die Aushandlung und Konfiguration der IPSec-Sicherheitsassoziation und deren Authentifizierung. Schutz vor Denial-of-Service-Angriffen in IPSec In IPSec wurden neben diesen Diensten auch Verfahren und Protokolle zum Schutz vor einer ganzen Reihe von Angriffen implementiert, die sich gegen das IPSec-System selbst oder das dahinter verborgene Netzwerk richten. Diese Maßnahmen sind sowohl in den IPSec-Sicherheitsprotokollen als auch im IKE-Protokoll zu finden und schützen vor Denial-of-Service-Angriffen, vor Angriffen durch wiederholtes Senden (Replay-Angriffen) und vor so genannten Man-in-the-Middle-Angriffen, in denen sich ein Angreifer unbemerkt in eine Verbindung einschaltet und diese abhört oder modifiziert. Auch hier wurde durch eine konsequente Standardisierung erreicht, dass diese Funktionen in einem Mindestumfang zwischen jedem IPSec-System vereinbar sind.
94
Die Grundlagen der Kryptographie
4.1.5
Benutzer-Authentifizierung
Beim Einsatz von Remote-Access-VPNs oder generell von VPNs, an denen Endgeräte wie PCs oder Workstations als Einzelbenutzersystem teilnehmen, ist eine Authentifizierung der Benutzer notwendig. Auf die heute eingesetzten Technologien wird in Kapitel 5 detailliert eingegangen. An dieser Stelle sei darauf hingewiesen, dass in IPSec nur eine Authentifizierung auf Netzwerkebene stattfindet. Es identifizieren sich also nur die IP-Systeme, nicht die Benutzer oder Applikationen, die diese Systeme zur Kommunikation benutzen. Der Benutzer muss sich also getrennt davon authentifizieren, oder die beiden Authentifizierungen müssen auf eine Art und Weise, die außerhalb des Definitionsbereichs von IPSec liegt, miteinander kombiniert werden.
4.2
Die Grundlagen der Kryptographie
Die Kryptologie ist heutzutage ein Teilbereich der theoretischen Mathematik. Sie besteht aus der Kryptographie, die die Vertraulichkeit von Nachrichten gewährleisten soll, und der Kryptoanalyse, der Kunst, eine verschlüsselte Nachricht wieder lesbar zu machen. Obwohl man oft den Begriff der Verschlüsselung mit Kryptographie gleichsetzt, kann man auch mit anderen Verfahren, z.B. der Verschleierung, den Inhalt von Nachrichten vor Unbefugten schützen.
4.2.1
Geschichtliches
Die Kryptographie war schon immer eng mit dem militärischen Bereich verknüpft. Hier entstand erstmals der Bedarf an öffentlicher Übertragung geheimer Daten. Bereits aus dem Altertum gibt es hierzu die ersten Überlieferungen, vorwiegend über Methoden zur Verschleierung sowie über einfache Substitutions- oder Transpositionsverfahren. Im letzten Jahrhundert, dem Jahrhundert der Weltkriege, wurde die Kryptographie fast ganz vom Militär und von Regierungsbehörden vereinnahmt. Erst in den letzten 30 Jahren wurde sie wieder ein mehr und mehr öffentliches Thema, vor allem bedingt durch die Zunahme der Datenkommunikation über öffentliche Netzwerke (Internet, E-Commerce, Home-Banking usw.) und dem daraus resultierenden Wunsch nach Datenschutz und Datensicherheit. Allerdings üben die Nachrichtendienste dieser Welt immer noch einen starken Einfluss aus, der sich auch vielfach in staatlichen Regulierungen niederschlägt. In einigen Ländern ist sogar die private Datenverschlüsselung bei Todesstrafe untersagt, zivilisiertere Länder begnügen sich mit Einfuhrverboten (Frankreich) von starker Verschlüsselung durch Privatpersonen oder Firmen oder beschränkten lange Zeit den freien Export (USA) von Kryptosystemen.
95
4 Sicherheitstechnologie
Insbesondere die US-amerikanische National Security Agency (NSA), die bis Mitte der 70er Jahre ihre Existenz rundweg ableugnete, obwohl sie jährlich Milliardenbudgets verschlang und einige tausend der besten Mathematiker beschäftigte, wird gern als der böse Bube vom Dienst hingestellt. Tatsache ist, dass ihr Auftrag im weltweiten Abhören und Entschlüsseln von Informationsübermittlungen besteht, um amerikanische Interessen zu schützen. Die Dehnbarkeit dieses Begriffes demonstrierte der ehemalige CIA-Direktor James Woolsey im März 2000, als er in einem Interview in der Washington Post ganz offen zugab, dass bestimmte Informationen aus Abhörmaßnahmen der NSA an US-Firmen weitergegeben wurden – um amerikanische Firmen vor der national culture of bribery (nationale Bestechungskultur) der europäischen Konkurrenz zu schützen, wie er sich ausdrückte. Manch andere, vor allem die Opfer in Europa, werden so etwas allerdings richtigerweise als Industriespionage bezeichnen. In der Tat haben die erfreulichen weltpolitischen Änderungen der letzten Jahrzehnte die Geheimdienstler dieser Welt nicht etwa arbeitslos gemacht. Deren neue Hauptaufgabe, zumindest in den Industrienationen, besteht mittlerweile in der Industriespionage. Die Basis dieser Aktivitäten bildet das US-amerikanische ECHELON-System, das unter aktiver Mitwirkung von Großbritannien und Australien aktiv alles an Kommunikationsmedien abhört, was technisch möglich ist. Und das ist leider nicht wenig. Der Kern des Systems sind Rechnersysteme, die die ausspionierten Informationen auf bestimmte, für die NSA interessant erscheinende Schlüsselbegriffe absuchen. Wenn jemand die Rechner der NSA zu umfangreichen Berechnungen veranlassen möchte, dann braucht er einfach nur eine mit dem E-Mail-Verschlüsselungsprogramm PGP verschlüsselte sinnlose E-Mail in die USA zu schicken und im Betreff-Feld die Begriffe »Airbus« und »Boeing« einzutragen. Es reicht aber auch vermutlich schon aus, diese beiden Worte in einem Inlands-Telefongespräch fallen zu lassen – die NSA betreibt im bayrischen Bad Aibling bisher ungehindert und unkontrolliert eine große, offenbar gut ausgestattete Abhörstation! Bei rechtem Licht besehen, ist die NSA aber nicht mehr oder weniger böse als andere Geheimdienste auch, sie ist aufgrund ihrer Ressourcen nur leistungsfähiger und damit als gefährlicher einzustufen. Das wirkliche Problem für jemanden, der sich vor Ausspähung durch die NSA schützen muss, ist die Frage, was die NSA wirklich zu leisten vermag, welche Ressourcen und welchen Wissens- und Technologievorsprung sie tatsächlich hat. Diese Frage ist bislang ungeklärt und gibt dadurch Anlass für wüste Spekulationen und Verschwörungstheorien. Andererseits sollte man sich im Bereich der Daten- und Netzwerk-Sicherheit ruhig eine Portion kontrollierten Verfolgungswahns gönnen, denn wer sagt »Mein Netzwerk ist sicher«, der hat schon verloren. Im letzten Jahrhundert gab es in der Kryptographie dramatische Entwicklungen. Es wurden zum ersten Mal in großem Stil Maschinen zum Verschlüsseln und auf der Gegenseite zum Brechen der Codes eingesetzt. Dies war weniger
96
Die Grundlagen der Kryptographie
eine Neuerung im Grundlagenbereich, sondern es wurden zum ersten Mal in der Geschichte durch Automaten Geheimtexte erzeugt, die von Menschen nicht mehr zu brechen waren. Dies gelang nur noch mit Automaten mit wesentlich höherer Leistungsfähigkeit als mit der der Chiffriermaschinen. Der Auslöser für diese Entwicklungen waren die neuen Kommunikationstechnologien, die Nachrichten per Kabel oder Funk übertrugen und dadurch nicht mehr abhörsicher waren. Anfangs verbreiteten sich mechanische Systeme, gefolgt von elektromechanischen Rotormaschinen in den beiden Weltkriegen. Später, ab Ende der 70er Jahre waren es rein elektronische Systeme, und heute befassen sich ausschließlich Computer mit der Arbeit der Kryptographie und Kryptoanalyse. Die elektromechanischen Rotormaschinen (z.B. die deutsche Enigma) produzierten bereits Chiffretexte, die von Menschen, selbst mit höchstem Personenund Zeitaufwand, nicht mehr zu entschlüsseln waren. Zur Entschlüsselung wurden erstmalig in der Geschichte in England elektronische Rechenmaschinen, die so genannten »Bombs« eingesetzt, die aus einer Vielzahl von Tyratronen, speziellen Schalter-Röhren, aufgebaut waren. Diese Vorläufer heutiger Computer waren schließlich in der Lage, die Chiffretexte der relativ einfach aufgebauten – und vielleicht gerade dadurch sehr sicheren – deutschen Enigma mit Known-Plaintext- und Chosen-Plaintext-Angriffen zu entschlüsseln. Interessanterweise werden die Grundfunktionen der Enigma, die polyalphabetische Substitution und Permutation, auch heute noch in sehr vielen Neuentwicklungen von Verschlüsselungsverfahren eingesetzt.
4.2.2
Datenvertraulichkeit
Die Kryptographie wird benutzt, um einen bestimmten Grad an Vertraulichkeit von öffentlich zugänglichen Informationen zu erreichen. Die Information darf nur den dazu Berechtigten, im Falle der Datenkommunikation dem Sender und Empfänger, im Klartext zur Verfügung stehen. Während sie zwischen Sender und Empfänger transportiert wird, muss die Information in einer Weise verändert sein, die es Dritten unmöglich macht, Art und Inhalt der Information zurückzugewinnen.
4.2.3
Verschleierung und Verschlüsselung
Als Methoden bieten sich grundsätzlich zwei Verfahren an, die sich aufgrund ihres möglichen Einsatzbereiches unterscheiden. Die Verschleierung und die Verschlüsselung von Informationen. Die Verschleierung wird nur noch selten eingesetzt, da ihre kryptographische Stärke nicht sehr hoch und sie in größeren Umgebungen mit sehr vielen Beteiligten nicht zu handhaben oder sehr unsicher ist. Im militärischen Bereich wird sie gelegentlich noch benutzt, um
97
4 Sicherheitstechnologie
taktische Informationen begrenzter Lebensdauer und mit eingeschränktem Gültigkeitsbereich zu übertragen. Typischerweise werden hier Begriffe durch andere Begriffe ersetzt, um die Bedeutung von Informationen, die zum Beispiel durch Sprechfunkverkehr übertragen werden, zu verschleiern. Ein Beispiel aus der Datenkommunikation ist das Übertragen von vertraulichen Informationen innerhalb anderer, auf den ersten Blick unverdächtiger Informationen. Zum Beispiel kann man die niederwertigen Bits einer Bilddatei benutzen, um darin Informationen verschleiert zu übertragen. Jemand, der die Übertragung mitschneidet oder sich die Datei verschafft, bekommt nur ein Bild angezeigt, und selbst der augenscheinliche Vergleich mit dem Originalbild zeigt im Allgemeinen keinen Unterschied. Jedoch würde ein strenger Vergleich der Bild-Dateien die Unterschiede an den Tag bringen. Klartext Nachricht
Empfänger
Sender
Mitlesen der Nachricht
Verändern der Nachricht
Angreifer
Sender
Nachricht
Angreifer Kein Mitlesen
Empfänger
Keine Veränderung
Nachricht
Nachricht
Entschlüsselung
Verschlüsselung Chiffretext
Abbildung 4.1: Durch Verschlüsselung wird eine Nachricht für Dritte unlesbar.
Die Verschlüsselung ist meist universeller angelegt, in der Regel sind die Verschlüsselungsverfahren selbst sogar offen gelegt. Die Sicherheit wird durch eine Zusatzinformation, den so genannten Schlüssel, erreicht, der neben dem
98
Die Grundlagen der Kryptographie
Klartext als zweite Eingangsgröße den Chiffretext erzeugt. Mit Hilfe dieses Schlüssels können Sender und Empfänger die zwischen ihnen ausgetauschten Informationen ver- und entschlüsseln. Die Verschlüsselungsverfahren, die heute in der Datenkommunikation Anwendung finden, sind sehr universell angelegt und arbeiten nicht mehr wie die Verschleierung auf der Ebene von Sprachbegriffen, sondern auf der Ebene von abstrakten Informationseinheiten wie elektrischen Spannungspegeln, Bits, Bytes usw.
4.2.4
Die Kunst der Kryptoanalyse
Die Kryptoanalyse ist die Kunst, eine verschlüsselte Nachricht wieder lesbar zu machen. Dies ist leichter gesagt als getan. Denn sie ist in der Tat eine Kunst oder genau genommen ein Beweis menschlicher Erfindungsgabe und Fantasie. Es gibt eine ganze Reihe verschiedener Angriffsarten, die sich darin unterscheiden, welche Informationen und Möglichkeiten dem Kryptoanalytiker zur Verfügung stehen. Unter der Krytoanalyse versteht man im Allgemeinen nicht das Erzeugen des Klartextes aus dem Chiffretext, sondern das Auffinden des zur Verschlüsselung verwendeten Schlüssels. Alle heutigen Chiffrierverfahren benutzen praktisch allgemein bekannte, offen gelegte Algorithmen, deren Sicherheit darauf basiert, dass der Schlüssel zum Ver- und Entschlüsseln geheim gehalten wird. Die Sicherheit dieser Verfahren basiert also ausschließlich auf dem Schlüssel, der damit auch zum Hauptangriffsziel der Kryptoanalytiker avanciert. Ciphertext-Only-Angriff Dies ist die größte Herausforderung an einen Kryptoanalytiker. Es steht ihm nur der Chiffretext zur Verfügung, und er kennt weder die Art noch den Inhalt auch nur von Teilen des Klartexts. Das Hauptproblem dieses Angriffs ist die Tatsache, dass der Angreifer gar nicht weiß, wann er einen Teil des Chiffretexts entschlüsselt hat, da er ja keinerlei Kenntnis vom Klartext hat. Known-Plaintext-Angriff (Brute-Force-Angriff) Besser hat es ein Kryptoanalytiker schon, wenn er zum Chiffretext wenigstens einen Teil des zugehörigen Klartextes kennt, also auch weiß, wann der den richtigen Schlüssel gefunden hat. Der Brute-Force-Angriff, also ein Angriff mit Brachialgewalt, ist der typische Vertreter dieser Angriffsart. Man probiert am Chiffretext mit dem bekannten Dechiffrieralgorithmus so lange alle in Frage kommenden Schlüsselvarianten aus, bis man den richtigen gefunden hat. Dies ist der Fall, wenn das Ergebnis der Entschlüsselung gleich dem bekannten Klartext ist.
99
4 Sicherheitstechnologie
Der folgende Pseudocode demonstriert einen Brute-Force-Angriff auf eine DES-Verschlüsselung. Die Funktion bekommt als Eingangsparameter den Chiffretext und den Klartext und liefert als Ergebnis den Schlüssel zurück. Qword sind 64 Bit große Variablen. Die externe Funktion DES entschlüsselt den Ciphertext mit dem key und liefert als Ergebnis einen 64-Bit-String zurück: Function Qword Brute_Force_Attack(Qword Cleartext, Qword Ciphertext) Extern Qword DES_Decrypt(Qwod key,Qword Ciphertext); Qword key; For key = 0 to 72057594037927936 do IF Cleartext == DES_Decrypt(key,Ciphertext) then Return(key) done Return(0)
Wie man leicht erkennen kann, ist das Hauptproblem dieses Verfahrens die Zeit, die für die Suche aufgewendet werden muss. Nehmen wir einmal ein Beispiel aus der Praxis. Der Data Encryption Standard benutzt einen Schlüssel, der 56 Bit lang ist, also insgesamt 72.057.594.037.927.936 verschiedene Werte annehmen kann. Angenommen, ein sehr schneller Rechner bräuchte für jede Dechiffrierung eine Mikrosekunde und der Schlüssel würde statistisch gesehen nach 50% aller Versuche gefunden, dann würde solch ein Angriff immer noch über 1.142 Jahre dauern und wäre praktisch sinnlos. Der Klartext zu einem gegebenen Chiffretext ist sehr oft bekannt, da darf man sich keine Illusionen machen. Bestimmte Datei-Header, Floskeln im Text, Mail-Signaturen usw. sind immer gleich und dadurch auch leicht zu erraten. Es werden auch sehr oft Block-Verschlüsselungsverfahren eingesetzt, die den letzten Block nach einem allgemein bekannten Verfahren mit Füllzeichen (Padding) auffüllen. Das Verhältnis der Schnelligkeit eines Brute-Force-Angriffs zum vorhandenen Budget hierfür ist innerhalb bestimmter technischer Grenzen annähernd linear. In realen Systemen zur Kryptoanalyse von DES arbeiten viele DES-Prozesse parallel mit eigenen Teilbereichen des zu durchsuchenden Schlüsselraumes. Entweder verwendet man Parallelrechner oder spezielle Systeme mit insgesamt Hunderten oder Tausenden parallel arbeitender DES-Chips, die einen 56 Bit langen Schlüssel innerhalb von Stunden oder gar Minuten knacken können. Der NSA unterstellt man, mittlerweile weniger als eine Sekunde zu benötigen, um eine 56-Bit-DES-Verschlüsselung zu brechen. Schutz gegen einen Brute-Force-Angriff erzielt man ganz einfach durch Verlängern des Schlüssels, denn jedes Bit mehr Schlüssellänge verdoppelt die Suchzeit. Der Brute-Force-Angriff ist aber letztendlich auch die Messlatte für die Sicherheit eines Verschlüsselungsalgorithmus. Ein Verschlüsselungsverfahren gilt definitionsgemäß dann als sicher, wenn der Brute-Force-Angriff die schnellste bekannte Methode ist, den Schlüssel zu ermitteln. Damit kann man auch seine
100
Die Grundlagen der Kryptographie
benötigte Schlüssellänge kalkulieren, indem man den Aufwand eines möglichen Angriffs abschätzt und als Resultat seine Schlüssel, natürlich mit einer kräftigen Sicherheitsreserve versehen, hinreichend lang macht. Chosen-Plaintext-Angriff und Adaptive-Chosen-Plaintext-Angriff Beim Chosen-Plaintext-Angriff kann der Kryptoanalytiker selbst Klartext in die Verschlüsselung einschleusen, und beim Adaptive-Chosen-PlaintextAngriff kann er dies sogar in einer Schleife mit immer neuem Klartext tun, abhängig vom Ergebnis der Chiffrierung. Diese beiden Angriffe sind, vor allem im letzteren Fall eher eine Angelegenheit fürs Labor. Genau dort werden diese Verfahren auch eingesetzt, und zwar um Verschlüsselungsverfahren auf ihre Stärke zu testen. Ein in letzter Zeit populär gewordener Vertreter dieser Angriffsart ist die differenzielle Kryptoanalyse, mit der man zum Beispiel DES, zumindest theoretisch, analysieren konnte. Das Ziel dieses Verfahrens ist festzustellen, wie sich der Chiffretext bei gezielten Änderungen des Klartextes ändert, um so auf den Schlüssel zu schließen. Dies sind bisher jedoch alles theoretische Angriffe, die obendrein recht futuristisch anmutende Computer mit 1000 Terabyte RAM und noch viel größere Massenspeicher voraussetzen. Außerdem ist die Komplexität einer differenziellen Kryptoanalyse immer noch größer als die eines Brute-Force-Angriffs. Die weiteren Rahmenbedingungen zu diesem Verfahren sind darüber hinaus völlig unrealistisch, es müssen zum Beispiel zu einem bestimmten Schlüssel 1012 Gbyte Chiffretext und der dazugehörige Klartext bekannt sein, um ihn zu berechnen. Dies kommt in der Praxis äußerst selten vor, und es lässt sich mit modernen Sicherheitsprotokollen, wie zum Beispiel IPSec und IKE, auch wirksam verhindern, dass mit einem einzigen Schlüssel überhaupt so viele Daten verschlüsselt werden.
4.2.5
Einführung in die Kryptographie
Grundbausteine der Kryptographie Das Grundgerüst der Kryptographie ist eine möglichst starke Kombination von Diffusion und Konfusion. Die Diffusion verschleiert gewissermaßen den Zusammenhang zwischen den Informationselementen im Klartext und Chiffretext. Die Konfusion verteilt die Informationselemente des Klartextes im Chiffretext. Oder sie verstärkt – hier haben wir dann unsere Kombination beider Prinzipien – die Diffusion dadurch, dass die Informationselemente im Chiffretext umverteilt werden. Das klingt noch etwas abstrakt, ist aber, wie Sie anschließend sehen werden, mit einfachen Verfahren zu realisieren. Die Diffusion wird in der Praxis durch Substitution und die Konfusion durch Permutation oder Transposition realisiert.
101
4 Sicherheitstechnologie
Substitution Bei der Substitutionschiffrierung wird jedes Zeichen im Klartext durch ein anderes Zeichen im Chiffretext ersetzt. Die Zeichen des Klartexts tauchen nicht mehr im Chiffretext auf. Die Zuordnungsvorschrift der Zeichen, also der Schlüssel, ist nur den Berechtigten, dem Sender und dem Empfänger bekannt. Man unterscheidet unterschiedliche Substitutionsmethoden. Bei der monoalphabetischen Substitution wird jedes mögliche Zeichen des Klartexts durch ein einziges, fest zugeordnetes Zeichen ersetzt. Abbildung 4.2 zeigt ein Beispiel für eine monoalphabetische Substitution. Der ASCII-Text »WISSEN IST MACHT« wird entsprechend der angegebenen Substitutionstabelle – sie stellt den Schlüssel dieses Verfahrens dar – in den Chiffretext »XZ66BPQZ6SQ5FOVS« transformiert. Klartext WISSEN IST MACHT Verschlüsselung
Substitution
Chiffretext XZ66BPQZ6SQ5FOVS Entschlüsselung Substitution
Klartext WISSEN IST MACHT
Schlüssel A C E I M N T W Leer H S . ....
F O B Z 5 P S X Q V 6 . ....
Abbildung 4.2: Eine monoalphabetische Text-Substitutionschiffrierung
Bei der polyalphabetischen Substitution kann jedes mögliche Zeichen des Klartexts durch verschiedene Zeichen im Chiffretext ersetzt werden, zum Beispiel kann A zu X, R oder Z werden, je nachdem, an welcher Stelle es im Klartext vorkommt. Dieses Verfahren fand auch in der bekannten deutschen Schlüsselmaschine Enigma erfolgreich Anwendung. Die Nachteile der monoalphabetischen Substitution lassen sich aus dem Chiffretext in Abbildung 4.2 ablesen. Aufgrund der festen Zuordnung zueinander, tauchen bestimmte Zeichen mehrfach auf. Beispielsweise erscheint die Ziffer 6 dreimal in der kurzen Zeile, dabei zweimal hintereinander; der Buchstabe Q kommt zweimal vor. Ein geübter Angreifer erkennt daraus sofort Folgendes:
102
Die Grundlagen der Kryptographie
Es handelt sich hier um die Verschlüsselung eines ASCII-Textes, die Doppelzeichen müssen auch Doppelbuchstaben im Klartext sein, und die häufig auftauchenden Zeichen sind entweder Leerzeichen im Klartext oder es sind Buchstaben, die in einer bestimmten Sprache oft vorkommen. Dadurch, dass durch die monoalphabetische Substitution die Häufigkeit und die Position der im Klartext vorkommenden Zeichen im Chiffretext nicht verändert, lässt sich eine solche Chiffrierung leicht knacken, sogar durch einen Ciphertext-Only-Angriff. Diesen Nachteil umgeht die polyalphabetische Substitution, indem dort ein Eingangswert im Klartext mehrere verschiedene Ausgangswerte im Chiffretext zur Folge haben kann. 3 Bit Eingabe, N
M=S(N) N
Zeilenadressierung
Spaltenadressierung
11
10
00
01
11
11
10
00
0 1 2 3 4 5 6 7
M = = = = = = = =
3 2 0 1 3 3 2 0
N=S’(N) M
N
Nichtlineare S-Box
2 Bit Ausgabe, M
0 1 2 3
= = = =
2,7 3 1,6 0,4,5
Abbildung 4.3: Die nichtlineare S-Box substituiert unumkehrbar binäre Informationsgrößen.
In modernen Hard- und Software-Implementierungen erfolgt die Substitution mit Hilfe so genannter S-Boxen (Substitution box). Eine S-Box liefert zu einem Eingangswert N einen Ausgangswert M. Der Wertebereich von N kann kleiner oder gleich dem von M sein, im ersten Fall handelt es sich um eine lineare, im zweiten um eine nichtlineare S-Box. Kryptographisch interessant ist die nichtlineare Substitution, weil hier verschiedene Zeichen des Klartexts auf ein Zeichen Chiffretext abgebildet werden, so dass nicht mehr zurückverfolgbar ist, welcher Eingabewert für einen bestimmten Ausgabewert verantwortlich war. Damit hat man bereits eine, wenngleich noch schwache, Einwegfunktionalität realisiert.
103
4 Sicherheitstechnologie
Die nichtlineare S-Box in Abbildung 4.3 transformiert den 3-Bit-Eingabewert N in den 2-Bit-Ausgabewert M. Der Ausgabewert 0 beispielsweise kann zwei mögliche, der Ausgabewert 3 bereits drei mögliche Eingangswerte gehabt haben. In der Praxis werden mehrere verschiedene S-Boxen so lange kaskadiert, bis eine Rückverfolgung des Eingangswertes aus dem Ausgangswert nicht mehr möglich ist. Damit erzielt man eine Einwegfunktionalität und kann den Ausgangswert nicht mehr zurückberechnen, auch nicht, wenn man die internen Tabellen der S-Box(en) kennt. Es ist offensichtlich, dass man solch ein Konstrukt zwar zum Verschlüsseln, aber nicht mehr zum Entschlüsseln benutzen kann. In der Praxis dienen solche Funktionen, also nichtlineare S-Boxen in Verbindung mit Permutationen, auch nicht zum eigentlichen Verschlüsseln, sondern zur Transformation von Schlüsseln. Permutation (Transposition) Bei der Transpositionschiffrierung werden alle Zeichen des Klartextes auf andere Positionen im Chiffretext umgesetzt. Die Zeichen des Originaltextes bleiben im Chiffretext erhalten. Die Art der Transposition, d.h. der Schlüssel, ist nur den Berechtigten, also dem Sender und dem Empfänger, bekannt. Je geringer der Informationsgehalt der Zeichen ist, die permutiert werden sollen, desto stärker ist dieses Verfahren. Eine Permutation von Wörtern einer Sprache ist leicht zu analysieren, die von reinen Buchstaben schon weniger leicht, aber Permutationen auf Bit-Ebene sind nur sehr schwer zurückzuverfolgen. Klartext WISSEN IST MACHT
Spaltentransposition W
I
S
S
E
N
_
I
S
T
_
M
A
C
H
T
_
_
Chiffretext W_AIICSSHSTTE__NM_ Abbildung 4.4: Eine Spaltentransposition vertauscht die ursprünglichen Positionen der Zeichen.
Abbildung 4.4 zeigt ein Beispiel für eine Transpositionschiffrierung, die so genannte Spaltentransposition. Hierbei wird der Klartext »WISSEN IST MACHT« zeilenweise so lange in eine Matrix eingetragen, bis der Text zu Ende ist. Der Chiffretext wird durch ein anschließendes spaltenweises Auslesen der Tabelle erzeugt.
104
Die Grundlagen der Kryptographie
Zur Transposition werden in modernen, praktischen Implementierungen so genannte P-Boxen (Permutation box) eingesetzt. Der Ausgangswert einer P-Box entsteht aus einer bitweisen Vertauschung der Bits des Eingangswerts. P-Boxen können wie S-Boxen in Hard- und Software realisiert werden. Bei Hardware-Implementierungen kann die Permutation durch eine Festverdrahtung mit extrem hohen Geschwindigkeiten realisiert werden. Wie bei der Substitution gibt es hier ebenfalls lineare und nichtlineare Varianten der P-Boxen. Lineare P-Boxen mit einer festen Zuordnung sind kryptographisch wenig interessant. In der Praxis kommen in der Regel nichtlineare P-Boxen vor, die eine so genannte Kompressions- oder Expansionspermutation durchführen. Bei der Expansionspermutation ist die Anzahl der Bits des Ausgangswerts größer als die des Eingangswerts. Bei der Kompressionspermutation ist die Anzahl der Bits des Ausgangswerts kleiner als die des Eingangswerts, hierbei gehen Informationen verloren. Nichtlineare P-Box (Expansionssubstitution)
MSB MSB
8 Bit Ausgabe, M
6 Bit Eingabe, N
LSB LSB
Abbildung 4.5: Die Expansionspermutation erzeugt einen Lawineneffekt.
Abbildung 4.5 zeigt ein Beispiel einer nichtlinearen P-Box. Es handelt sich um eine Expansionspermutation mit einem 6-Bit-Eingangswert N und einem 8-Bit-Ausgangswert M. Um den 8-Bit-Ausgangswert zu erhalten, werden jeweils 2 Bit des Eingangswerts verdoppelt. Die Änderung eines einzigen Bits dieser beiden hat eine Änderung von gleich zwei höherwertigen Bits des Ausgangswerts zur Folge. Das heißt, durch minimale Änderungen des Eingangswerts lassen sich starke Änderungen des Ausgangswertes erzielen. Man spricht hierbei vom einem so genannten Lawineneffekt. Um eine Dechiffrierung zu erschweren, werden in der Praxis Substitutionsund Permutationsverfahren miteinander verknüpft und hinreichend oft kaskadiert, um an einem bestimmten Punkt einen Zustand zu haben, an dem von dem Ausgangswert nicht mehr auf den Eingangswert geschlossen werden kann. Eine solche Produktchiffre sehen Sie in Abbildung 4.6: Hier werden
105
4 Sicherheitstechnologie
Nichtlineare Substitution Nichtlineare Substitution
Expansionspermutation
Nichtlineare Substitution Nichtlineare Substitution
Expansionspermutation
Nichtlineare Substitution Nichtlineare Substitution
Expansionspermutation
nichtlineare Substitutionen und Expansionspermutationen so lange verkettet, bis ein Ausgangswert entstanden ist, aus dem der Ursprungswert nicht mehr zurückberechnet werden kann.
Abbildung 4.6: Eine Produktchiffre verkettet Substitutionen und Permutationen.
Feistel-Netzwerke Feistel-Netzwerke sind der Grundbaustein fast aller heute gebräuchlichen symmetrischen Block-Verschlüsselungsverfahren. Der Name stammt von dem damaligen IBM-Mitarbeiter Horst Feistel, der sich Anfang der 70er Jahre für seinen Arbeitgeber mit der Entwicklung von Chiffrierverfahren beschäftigte. Aus seinem Team stammt auch der Lucifer-Chiffre, ein Algorithmus, der später nach einigen Modifikationen zum Data Encryption Standard (DES) wurde und auch heute noch weltweit in Gebrauch ist. Auf den ersten Blick sieht ein Feistel-Netzwerk oder ein Feistel-Zyklus, der aus zwei so genannten Runden eines Feistel-Netzwerks besteht, gar nicht so aufregend aus. Aber es besticht durch eine Eigenschaft, die es zur Basisstruktur moderner BlockChiffrierverfahren gemacht hat. Es erlaubt nämlich, die unumkehrbaren Produktchiffren, die aus nichtlinearen Substitutionen und Permutationen bestehen, sowohl zur Ver- als auch zur Entschlüsselung zu benutzen! In Abbildung 4.7 ist ein Feistel-Zyklus dargestellt, der aus zwei Runden eines Feistel-Netzwerks besteht. Die Funktion F ist eine Produktchiffre, die auf unumkehrbare Weise aus ihren Eingangswerten – dem Teilschlüssel und einer Hälfte des Klartextes – ihren Ausgangswert erzeugt. Die eigentliche Transformation der anderen Hälfte des Klartextes in den Chiffretext erfolgt jedoch – und das ist der springende Punkt in diesem Verfahren – durch eine einfache Exklusiv-Oder-Verknüpfung. Und diese Funktion, Exklusiv-Oder, ist umkehrbar, denn man kann den Chiffretext mit dem gleichen Schlüssel, mit dem er erzeugt wurde, wieder in den ursprünglichen Klartext umwandeln. Auf unser Beispiel bezogen folgt somit, dass bei Kenntnis der Funktion F und des Schlüs-
106
Die Grundlagen der Kryptographie
sels, aus dem die Teilschlüssel abgeleitet werden, eine Dechiffrierung dadurch möglich ist, dass man den Chiffretext in den Feistel-Zyklus einspeist und lediglich die Reihenfolge der zu benutzenden Teilschlüssel umkehrt. Das Ergebnis ist wieder der Klartext. In unserem Beispiel würde nach einem Zyklus aus dem Klartext (Li,Ri) der Chiffretext (Li+2,Ri+2) durch folgende Transformationen: Erste Runde (die Exklusiv-Oder-Verknüpfung ist im Folgenden mit ⊕ notiert): Li+1 = Ri Ri+1 = Li ⊕ F(Ri,Ki) Zweite Runde: Li+2 = Ri+1 Ri+2 = Li+1 ⊕ F(Ri+1,Ki+1) Durch die Umkehrung, also wenn dieser Zyklus mit dem Chiffretext (Li+2,Ri+2) und dem Teilschlüssel Ki+1 beginnt, erhalten wir wieder den Klartext (Li,Ri): Erste Runde: Li+1 = Ri+2 Ri+1 = Li+2 ⊕ F(Ri+2,Ki+1) Zweite Runde: Li = Ri+1 Ri = Li+1 ⊕ F(Ri+1,Ki) Des Weiteren folgt daraus auch, dass es – eine entsprechend unumkehrbare Funktion F vorausgesetzt – nicht mehr möglich ist, auch bei Kenntnis von zusammengehörendem Klar- und Chiffretext, einen oder mehrere Teilschlüssel zu rekonstruieren. Die einzig verbliebene Angriffsart ist somit ein BruteForce-Angriff. Praktische Implementierungen begnügen sich nicht mit nur einem FeistelZyklus, sondern verketten ihn zu mehreren Runden. DES benutzt zum Beispiel acht Zyklen, also insgesamt 16 Runden. Die zu verwendende Anzahl der Runden hängt maßgeblich von der Qualität der Funktion F ab, die als einzige über die Sicherheit des Chiffriererfahrens entscheidet.
107
4 Sicherheitstechnologie
Li
Ri
Klartext
Teilschlüssel 1
F(Ri,Ki)
1. Runde
Ki
1 Zyklus
Li+1
Ri+1 Teilschlüssel 2
F(Ri+1,Ki+1)
2. Runde
Li+2
Ri+2
Li+N
Ri+N
Ki+1
Chiffretext
Abbildung 4.7: Ein Feistel-Zyklus, bestehend aus zwei Runden eines Feistel-Netzwerks
4.2.6
Verschlüsselungsverfahren
Alle in der Praxis eingesetzten Verschlüsselungsverfahren benutzen einen allgemein bekannten Algorithmus, der den Chiffretext aus dem Klartext und aus einem Schlüssel erzeugt. Die Sicherheit dieser Verfahren basiert damit ausschließlich auf der Geheimhaltung und der Qualität des Schlüssels, nicht auf der Vertraulichkeit des Algorithmus selbst. Aus diesem Grunde sind auch alle ernst zu nehmenden Algorithmen offen gelegt. Dies bedeutet, dass jeder diese Algorithmen analysieren und auf Schwachstellen testen kann und somit unsichere Kandidaten sehr schnell entdeckt werden. So gibt es vermutlich kein Verfahren, an dessen Kryptoanalyse sich mehr Personen und Organisationen versucht haben, als an DES und Triple-DES. Die Tatsache, dass es noch keiner »geknackt« hat, also noch niemand ein Verfahren angewendet hat, das schneller als ein Brute-Force-Angriff ist, spricht letztendlich für dessen Sicherheit.
108
Die Grundlagen der Kryptographie
Es gibt zwei grundsätzlich verschiedene Verfahren, die auf Schlüsseln basieren: Die symmetrische oder Secret-Key-Verschlüsselung und die asymmetrische oder Public-Key-Verschlüsselung. Symmetrische Verschlüsselung Bei der symmetrischen Verschlüsselung kennen alle beteiligten Gegenstellen einen geheimen Schlüssel, den so genannten Secret Key, der sowohl zum Verals auch zum Entschlüsseln benutzt wird. Symmetrische Verfahren werden in Form von Datenstrom- oder Datenblock-Verschlüsselungen verwendet. Das Grundprinzip funktioniert, wie in Abbildung 4.8 dargestellt. Zunächst vereinbaren Sender und Empfänger einen gemeinsamen Schlüssel. Dieser dient dem Sender zur Verschlüsselung des Klartexts und dem Empfänger zur Entschlüsselung des Chiffretexts. Klartext
Klartext
WISSEN IST MACHT
WISSEN IST MACHT
Symmetrischer Schlüssel
Verschlüsselung
Entschlüsselung Chiffretext
P/h9?fa4Hfd$lGfa50he6s
Abbildung 4.8: Eine symmetrische Verschlüsselung
Ältere Algorithmen wurden in der Regel zur Implementierung in Hardware entwickelt, neuere Verfahren wurden universeller ausgelegt und erreichen auch als Software-Implementierung eine hohe Performance. So gibt es heute bereits DES-Chips mit mehr als 1 Gbit/s Durchsatz. RC4, als Vertreter reiner Software-Verschlüsselung, wurde speziell für den Betrieb auf der 80x86-Prozessor-Serie der Firma Intel entwickelt und optimiert. Da die Sicherheit dieser Verfahren ausschließlich von der Länge und der Vertraulichkeit des Schlüssels abhängt, sind sie leicht an verschiedene Sicherheitsanforderungen anzupassen. Um sich vor einem Brute-Force-Angriff zu schützen, gibt es verschiedene Empfehlungen, wie lang der Schlüssel sein sollte, und zwar abhängig davon, von wem ein Angriff erwartet wird und wie lange Informationen geheim gehalten werden müssen. Allerdings sind solche
109
4 Sicherheitstechnologie
Empfehlungen mit einer gewissen Vorsicht zu genießen, denn wer kann heute schon sagen, welche Technologie in 20 Jahren zur Verfügung stehen wird. Zu diesem Zeitpunkt sind Daten, die heute mit einem jetzt noch sicheren Verfahren verschlüsselt werden, vielleicht innerhalb von Stunden oder Minuten zu dechiffrieren.
Schlüsselart
Länge
Mögliche Kombinationen
Testzeit
Parallele Tests
Kofferschloss
10 Bit
Kurzes Passwort
28 Bit
1.000
2s
1
17 Minuten
8.1450.625
1 µs
1
40 Sekunden
RC4-Schlüssel 40 Bit
1.099.511.627.776
1 µs
1
6 Tage
RC4-Schlüssel 40 Bit
1.099.511.627.776
1 µs
50
2,8 Stunden
RC4-Schlüssel 40 Bit
1.099.511.627.776
1 µs
1.000.000 0,05 Sekunden
DES-Schlüssel 56 Bit
72.057.594.037.927.900 1 µs
DES-Schlüssel 56 Bit
72.057.594.037.927.900 1 µs
1
Mittlere Suchzeit
1.142 Jahre
1.000.000 10 Stunden
IDEASchlüssel
128 Bit 3,4 * 1038
1 µs
1
IDEASchlüssel
128 Bit 3,4 * 1038
1 µs
1.000.000 5,4 * 1018 Jahre
5,4 * 1024 Jahre
Tab. 4.1: Brute-Force-Angriffe auf verschieden lange Schlüssel
In Tabelle 4.1 sehen Sie einen Vergleich zwischen Brute-Force-Angriffen auf Schlüssel verschiedener Länge. Als Zeitbedarf wurde eine Mikrosekunde pro Test angesetzt. Für das RC4-Verfahren mit 40 Bit wirksamer Schlüssellänge, wie es in praktisch allen Webbrowsern mit der (alten) US-Exportlizenz eingesetzt wird und mit dem somit auch Ihre Kreditkarteninformationen verschlüsselt werden, sehen Sie in der Zeile 4, dass der Zeitaufwand für einen Angriff mit 50 parallelen Systemen nur 2,8 Stunden beträgt. Das DES-Verfahren mit seiner Schlüssellänge von 56 Bit beschäftigt eine Workstation schon über 1.000 Jahre – falls der Rechner überhaupt so lange funktioniert und das Resultat dann noch jemanden interessiert. Ein Brute-Force-Angriff auf ein starkes Verschlüsselungsverfahren mit 128-Bit-Schlüssel würde theoretisch 5,4 x 1024 Jahre dauern. Man kann den Aufwand zum Suchen eines Schlüssels vergrößern, indem man sehr viele, schnelle Hardwaresysteme parallel einsetzt und jedes nur einen Teilbereich des möglichen Schlüsselraums durchsuchen lässt. Mit Investitionen im siebenstelligen Dollarbereich sind Systeme denkbar – wer weiß, vielleicht gibt es sie auch schon –, die 1.000.000 Suchvorgänge pro Minute schaffen können. Der 56-Bit-DES-Schlüssel wäre mit einem
110
Die Grundlagen der Kryptographie
solchen System in 10 Stunden gefunden; der IDEA-Schlüssel wäre mit einer Suchzeit von 5,4 x 1018 Jahren immer noch sicher. Ein 40-Bit-Schlüssel wäre damit jedoch bereits im Schnitt nach 50, garantiert nach 100 Millisekunden gefunden! Anhand dieser Tabelle können Sie erkennen, dass Verschlüsselungsverfahren mit einer Schlüssellänge von 128 Bit oder größer, vor einem BruteForce-Angriff sicher sind. Selbst wenn sich in den nächsten zehn Jahren die Geschwindigkeit der Prozessoren um den Faktor 1.000.000.000 steigern sollte, betrüge die Suchzeit immer noch 5,4 x 109 Jahre mit einem solchen Supercomputer. Asymmetrische Verschlüsselung Im Gegensatz zur symmetrischen Verschlüsselung verwenden die asymmetrischen Verfahren zwei verschiedene Schlüssel. Auf der einen Seite ist dies der öffentliche Schlüssel oder Public Key, den jeder kennt und der zum Verschlüsseln (Chiffrierschlüssel) einer Nachricht verwendet wird. Auf der anderen Seite gibt es einen geheimen Schlüssel oder Private Key, den nur der Empfänger der Nachricht kennt und der zum Entschlüsseln (Dechiffrierschlüssel) dient. Eine mit einem öffentlichen Schlüssel verschlüsselte Nachricht kann mit demselben oder einem anderen öffentlichen Schlüssel nicht mehr entschlüsselt werden. Private Key und Public Key sind einander fest zugeordnete »Schlüsselpaare«, die aus einem mathematischen Verfahren, das nicht zurückzuverfolgen ist, voneinander abgeleitet werden. Die bekanntesten Public-Key-Verfahren sind RSA und Diffie-Hellman, die später in diesem Kapitel noch ausführlich besprochen werden. Abbildung 4.9 zeigt den Ablauf einer asymmetrischen Verschlüsselung. Der Klartext wird mit dem öffentlichen Schlüssel verschlüsselt. Auf der Gegenstelle wird der Chiffretext mit dem privaten Schlüssel entschlüsselt. Der öffentliche Schlüssel ist jedermann zugänglich. Er kann zum Beispiel auf einem öffentlichen Server abgelegt sein, da jede Person, die einer anderen Person nach diesem Prinzip eine Nachricht zusenden will, deren öffentlichen Schlüssel zum Verschlüsseln benötigt. Der Empfänger benutzt seinen privaten Schlüssel, um die Nachricht wieder zu entschlüsseln. Nur er allein kann die Nachricht entschlüsseln, weil nur er seinen privaten Schlüssel besitzt. Es gibt asymmetrische Verfahren, zum Beispiel RSA, die umgekehrt auch mit dem privaten Schlüssel verschlüsseln und mit dem öffentlichen Schlüssel wieder entschlüsseln können. Diese Betriebsart spielt zur Verschlüsselung von Nachrichten keine Rolle, sondern wird für Anwendungen zur Authentifizierung durch digitale Signaturen eingesetzt.
111
4 Sicherheitstechnologie
Klartext
Klartext
WISSEN IST MACHT
WISSEN IST MACHT
Öffentlicher Schlüssel
Privater Schlüssel
Entschlüsselung
Verschlüsselung Chiffretext 7245b0738cd6199a25f28
Abbildung 4.9: Die asymmetrische Verschlüsselung benutzt zwei unterschiedliche Schlüssel zur Ver- und Entschlüsselung.
Auch bei asymmetrischen Algorithmen muss man sich vor Angriffen schützen. Asymmetrische Verfahren arbeiten aus technischen Gründen allerdings mit weit größeren Schlüssellängen als symmetrische. Ein heute sicherer asymmetrischer RSA-Schlüssel beginnt in der Regel bei einer Länge von 1024 Bit. Deshalb gelten hier andere Werte zum Schutz vor Angriffen. Asymmetrische Verfahren sind wesentlich langsamer als symmetrische. Deshalb werden sie selten zur Verschlüsselung von Nutzdaten, wie Datenpaketen und Dateien, eingesetzt. In der Praxis dienen sie dazu, ein symmetrisches Schlüsselpaar für den Sender und Empfänger zu erzeugen. Dieser Vorgang dauert mit einem 133-MHz-Pentium-PC kaum länger als zwei bis drei Sekunden bei einem 2048 Bit großen Schlüssel. Da sich keine nennenswerte Verzögerung ergibt, kann der Schlüssel so groß wie möglich gewählt werden. Dies ist auch aus einem anderen Grund empfehlenswert. Alle asymmetrischen Verfahren benutzen Algorithmen, die auf bestimmten, bisher als unlösbar geltenden mathematischen Problemen basieren. Es ist zwar sehr unwahrscheinlich, dass sie jemals vollständig gelöst werden, aber es können durchaus drastische Optimierungen eingeführt werden. Das heißt, dass zumindest theoretisch in Zukunft die Gefahr der Rückberechnung besteht, auch wenn der Aufwand heute noch im Bereich von mehreren Milliarden Jahren liegt. Auch hier gilt deshalb die gleiche Empfehlung wie bei symmetrischen Verfahren: Einen Schutz vor der Rückberechnung des Schlüssels und vor Brute-Force-Angriffen bieten nur entsprechend große Schlüssellängen, die in Abhängigkeit davon zu wählen sind, welche Informationen wie lange geschützt werden müssen. Generell sollte man seine Schlüssellängen, sofern es das Verarbeitungsvermögen der eingesetzten Systeme und die verwendeten Algorithmen zulassen, mit einer kräftigen Sicherheitsreserve versehen.
112
Symmetrische Verschlüsselungsverfahren
4.3
Symmetrische Verschlüsselungsverfahren
Die symmetrischen Verfahren verwenden in der Regel entweder die Datenblock- oder die Datenstrom-Verschlüsselung. Bei einer Datenblock-Verschlüsselung werden jeweils komplette Blöcke einer bestimmten Größe mit einem Schlüssel verschlüsselt (siehe Abbildung 4.10). Beim bekanntesten Vertreter dieser Verfahren, dem Data Encryption Standard (DES), ist der Datenblock beispielsweise 64 Bit groß. Kleinere Blöcke werden auf die benötigte Größe aufgefüllt (Padding), um korrekt verarbeitet werden zu können. Klartext BLOCKCHIFFRE
Block 1
BLOCKCHI
Füllzeichengenerator B
lock 2
FFRE@@@@
Verschlüsselung
Verschlüsselung
Ff0d62723d8fe
7245b0738cd619
Chiffretext
Chiffretext
Abbildung 4.10: Eine Datenblock-Verschlüsselung
Bei der Datenstrom-Verschlüsselung (siehe Abbildung 4.11) wird ein Datenstrom, der aus Bits, Bytes oder anderen systemabhängigen Informationsgrößen besteht, so lange fortlaufend verschlüsselt, bis der Eingangsdatenstrom vollständig verarbeitet wurde. Die Datenstrom-Verschlüsselung ist oft schneller als die Datenblock-Verschlüsselung und hat eine geringere Latenz. Eine Schwachstelle der Datenblock-Verschlüsselung ist das Padding, denn die Art und Weise, wie aufgefüllt werden muss, muss sowohl dem Sender als auch dem Empfänger bekannt sein und ist sogar oft in Standards veröffentlicht. Da man statistisch gesehen davon ausgehen kann, dass im Schnitt der letzte Block zu 50% aufgefüllt wurde, bietet sich bei der Datenblock-Verschlüsselung immer die Möglichkeit eines Know-Plain-Text-Angriffs. Deshalb sollte die reine Datenblock-Verschlüsselung möglichst nie zur Übertragung von sehr kurzen Nachrichten, zum Beispiel von Telnet- oder Terminal-Sessions, angewandt werden.
113
4 Sicherheitstechnologie
Klartext BLOCKCHIFFRE
KlartextBytestrom Chiffretext
Verschlüsselung
Ff0d62723d8fe
SchlüsselBytestrom
Schlüsselstromgenerator
Abbildung 4.11: Eine Datenstrom-Verschlüsselung
Die Datenstrom-Verschlüsselung liest den Eingangsdatenstrom und verschlüsselt ihn so lange mit einem Schlüsselstrom, der von einem Schlüsselstrom-Generator erzeugt wird, bis der Eingangsdatenstrom vollständig bearbeitet wurde. Ein Padding ist hier offensichtlich nicht notwendig.
4.4
Der Data Encryption Standard (DES)
Der Data Encryption Standard, DES, ist der Klassiker der symmetrischen Datenblock-Verschlüsselungsverfahren schlechthin. Er ist ein Standard des USamerikanischen National Bureau of Standards (NBS) und ist in der Federal Information Processing Standard Publication (FIPS-Pub) 46-2 beschrieben. In diesem Dokument sind alle Details des Verfahrens beschrieben. Man kann diesen Standard benutzen, um DES zu implementieren, es ist alles vollständig beschrieben. Der Standard wurde im Juli 1977 verabschiedet und in den Jahren 1983, 1988 und 1993 wiederholt überprüft und verlängert. Er ist also bereits über 23 Jahre alt, und es wurde noch kein Fall bekannt, in dem DES gebrochen wurde, indem eine Kryptoanalyse eingesetzt wurde, die schneller als ein Brute-Force-Angriff ist. Seine Stärke, und auch die des von ihm abgeleiteten Tripple-DES-Verfahrens, liegt vor allem auch darin, dass ihm die National Security Agency (NSA) seine Qualität nicht nur offiziell bescheinigt hat, sondern sogar selbst noch Verbesserungen vornahm. Wie kam es zu diesem, für die NSA nun wirklich ungewöhnlichen Verhalten? Die Entwicklung eines Vorläufers vom DES begann bereits Ende der 60er Jahre, in einem Forschungsprojekt von IBM unter der Leitung von Horst Feistel. Das Verfahren sollte bei Lloyd’s of London in den Geldautomaten, die
114
Der Data Encryption Standard (DES)
ebenfalls von IBM stammten, eingesetzt werden und erhielt den Namen Lucifer-Chiffre. IBM sah gute Möglichkeiten einer kommerziellen Vermarktung und begann mit weiteren Entwicklungen, die das Ziel hatten, das Verfahren in einem einzigen Chip bzw. einem einzigen Hybridbaustein zu implementieren. In dieser Phase wurde bereits die NSA involviert, die dem Entwickler-Team mit Rat und Tat zur Seite stand – und heraus kam ein Algorithmus, dessen ursprünglicher 128-Bit-Schlüssel um 72 Bit auf nur noch 56 Bit verkürzt war! Parallel dazu veröffentlichte das NBS, aus dem später das National Institute of Standards and Technology (NIST) hervorging, im Jahre 1973 eine Ausschreibung für einen einheitlichen Verschlüsselungsalgorithmus. Da die Kryptologie bis zu diesem Zeitpunkt hauptsächlich im militärischen und nachrichtendienstlichen Bereich eingesetzt wurde, hielten sich die Menge und die Qualität der eingereichten Verfahren stark in Grenzen – entweder waren die Verfahren als geheim eingestuft oder unbrauchbar. Erst nach einer zweiten Ausschreibung im Jahr 1974 reichte IBM das Lucifer-Verfahren ein. Das NBS konsultierte daraufhin externe Experten, um den Algorithmus zu beurteilen, und zwar die NSA, wie Sie richtig vermutet haben. Um die genauen Vorgänge damals ranken sich Gerüchte und widersprüchliche Aussagen vor allem dahingehend, ob die NSA an dem Entwurf etwas verändert hatte oder nicht. Tatsache ist jedoch, dass die NSA wohl davon ausgegangen ist, dass DES nur in Chips oder nicht analysierbaren Hardwaremodulen implementiert werden würde. Der 56-Bit-Schlüssel schien für zivile Ansprüche ausreichend lang, aber für die NSA innerhalb von Wochen oder Tagen zu brechen. Die Veränderungen am Algorithmus gegenüber seinem ersten Entwurf, egal ob sie nun von IBM oder der NSA vorgenommen wurden, machten ihn sicher gegen die differenzielle Kryptoanalyse. Interessanterweise wurde die differenzielle Kryptoanalyse aber erst 1990 zum ersten Mal öffentlich beschrieben, fünfzehn Jahre nachdem DES dagegen sicher gemacht wurde. Wie dem auch sei, die NSA bescheinigte dem DES, dass er ein sicherer Algorithmus ist. Die schnellste Angriffsmethode – auch heute noch – ist ein BruteForce-Angriff. Das NBS veröffentlichte DES dann in allen Einzelheiten, die notwendig sind, um ihn zu implementieren. Der Data Encryption Standard wurde in den letzten 23 Jahren zum wohl am weitesten verbreiteten Chiffrieralgorithmus aller Zeiten – trotz aller anfänglichen Kritik. Und die war sehr laut und ist bis heute nicht verstummt. Der nur 56 Bit lange Schlüssel war von Anfang an der hauptsächliche Kritikpunkt. Man hatte ihn schon damals für zu kurz gehalten und die ursprüngliche Länge von 128 Bit gefordert. Allerdings konnten sich die Kritiker damals nicht gegen die NSA durchsetzen.
115
4 Sicherheitstechnologie
4.4.1
Ein Überblick über DES
64-Bit-Klartext-Block
64-Bit-Schlüsselstring
Eingangspermutation
56-Bit-DES-Schlüssel
Schlüsseltransformation K1
Runde 16 DES
K16
FeistelNetzwerk Ausgangspermuation
64-Bit-Chiffretext-Block
Abbildung 4.12: DES im Überblick
Das Design von DES ist sehr stark hardwareorientiert. Die Entwicklungen begannen bei IBM bereits Ende der 60er Jahre, und die Rechner waren damals auf einem völlig anderen Leistungsniveau angesiedelt als heutige Systeme. Die Integrationsdichte von Bauelementen war nicht mit dem zu vergleichen, was heute möglich ist. Die Computer arbeiteten zu dieser Zeit nicht mit Mikroprozessoren, sondern mit Hybridelementen, kleinen Baugruppen auf denen logische Funktionen durch diskrete Dioden und Transistoren ausgeführt wurden. Speichergrößen wurden in Byte und Kilobyte gemessen, und Massenspeicher arbeiteten mit Papier oder Magnetbändern. In diesem technischen Umfeld, und das ist wirklich bemerkenswert, wurde ein Verschlüsselungsalgorithmus entwickelt, der in heutigen PCs, Workstations und Supercomputern arbeitet und in modernen Chips Durchsatzraten von über 1.000.000.000 Bits pro Sekunde erreicht. Weil er für den Hardwareeinsatz entwickelt wurde, ist DES nicht so leistungsfähig in Software zu implementieren. Jedoch ist dies bei der Leistungsfähigkeit heutiger Rechner kein Problem mehr – und es gibt auch schon die ersten Netzwerkadapter mit integrierten Chips zur Berechnung von DES und anderen kryptographischen Verfahren.
116
Der Data Encryption Standard (DES)
DES transformiert einen 64 Bit großen Klartextblock unter Verwendung eines 56-Bit-Schlüssels in einen 64 Bit großen Chiffretextblock. Der Data Encryption Standard basiert auf dem Einsatz von Feistel-Netzwerken. Er verwendet acht Feistel-Zyklen, also insgesamt 16 Runden, um dieses Ziel zu erfüllen. Bevor der Klartext der ersten Runde zugeführt wird, durchläuft er eine lineare Eingangspermutation, die nach der letzten Runde durch eine Ausgangspermutation wieder aufgehoben wird. Diese beiden Permutationen haben keinen kryptographischen Ursprung, sondern sind Anfang der 70er Jahre aus Anforderungen heraus entstanden, die aus der damals verfügbaren Hardware resultierten. Die 16 Runden sind alle identisch aufgebaut, die DES-Funktion ist ebenfalls in allen Runden die gleiche. Der einzige Unterschied liegt in den 16 Teilschlüsseln, die als eine der beiden Eingangsvariablen der Runden verwendet werden.
4.4.2
Die DES-Schlüsseltransformation
Diese Teilschlüssel werden durch Schlüsseltransformationen aus dem 56-BitSchlüssel erzeugt und sind jeweils 48 Bit groß. Die Schlüsseltransformation ist so aufgebaut, dass nach der 16. Transformation der Originalschlüssel wieder hergestellt ist. Schlüssel-String (64 Bit) Jedes achte Bit wird entfernt
DES-Schlüssel (56 Bit) Transformation 1
28 Bit
28 Bit
28-Bit-Schieberegister
28-Bit-Schieberegister
Kompressionspermutation
Teilschlüssel K1
48 Bit
Transformation 2
28 Bit
28 Bit
Abbildung 4.13: Die DES-Schlüsseltransformation
117
4 Sicherheitstechnologie
Die Schlüsseltransformation ist in Abbildung 4.13 illustriert. Der Schlüssel wird als 64 Bit großer Wert an den DES-Algorithmus übergeben. Dieser entfernt jedes achte Bit daraus und benutzt die verbleibenden 56 Bits als Schlüssel. Im DES-Dokument wird zwar permanent (und falsch!) von einem 64-Bit-Schlüssel gesprochen, jedoch finden davon tatsächlich nur 56 Bit Verwendung. Der Grund für diesen Sachverhalt besteht darin, dass die Datenkommunikation zu Anfang der 70er Jahre nicht die Qualität heutiger Datennetze aufwies, und jedes achte Bit in dem 64-Bit-Schlüssel als Paritätsbit benutzt wurde, um Übertragungsfehler zu erkennen. Diese Bits sind natürlich nicht zufälliger Natur, sondern werden aufgrund der sieben Informationsbits berechnet, die links davon stehen. Der DES-Algorithmus selbst wertet die Paritätsbits nicht aus, er entfernt sie einfach nur. Aus diesem Grund kann man DES auch beliebige 64-Bit-Schlüssel zuführen, in denen das jeweils achte Bit kein Ergebnis einer Paritätsberechnung ist, wie dies zum Beispiel auch in IPSec und IKE üblich ist. In den beiden Schieberegistern (Shift), jedes enthält eine Hälfte des 56-BitSchlüssels, werden die Bits rundenabhängig um ein oder zwei Bit-Positionen nach links rotiert. Rotiert heißt dabei, dass die Bits, die links »hinausgeschoben« werden, auf der rechten Seite des Registers wieder auf der niedrigsten Bit-Position erscheinen. Die Summe der Rotationen ist 28, so dass nach 16 Runden wieder das ursprüngliche Bitmuster in den Registern steht.
4.4.3
Die DES-Funktion
In Abbildung 4.14 sehen Sie die DES-Funktion im Detail. Die Eingangswerte sind der Teilschlüssel und, im Fall der ersten Runde, die rechte Hälfte des Klartextes oder im Weiteren die rechte Hälfte des Ausgangsblocks der vorangegangenen Runde (Rn). Der Wert Rn wird in einer Expansionspermutation auf 48 Bit erweitert und mit den 48 Bit des entsprechenden Teilschlüssels Exklusiv-Oder-verknüpft. Das Ergebnis wird in einer nichtlinearen S-BoxSubstitution wieder auf 32 Bit reduziert und durchläuft anschließend eine lineare Permutation. Das Resultat ist das Ergebnis der DES-Funktion. Dieses Ergebnis wird im Feistel-Netzwerk mit der linken Hälfte des Klartextes oder der Ausgabe der vorangegangenen Runde Exklusiv-Oder-verknüpft.! Die S-Boxen der DES-Funktion sind der wichtigste und kritischste Teil des Data Encryption Standard. Ihre Funktion entscheidet über Sicherheit oder Unsicherheit des Verfahrens. Wie die Funktionswerte, in Abbildung 4.15 sehen Sie die fünfte S-Box, erzeugt wurden, ist nicht offen gelegt! Ob die Entwickler einfach nur gewürfelt haben oder wochenlange Berechnungen vorausgegangen sind, bleibt nach wie vor im Dunkeln. Auch heute, 23 Jahre nach der offiziellen Verabschiedung des Standards, wahren noch alle Beteiligten ihr Stillschweigen. Es ist jedoch so, dass eine möglichst gleichmäßige, mehrfache Substitution aller Bits erreicht wurde. Lediglich inoffiziell wurde bekannt,
118
Der Data Encryption Standard (DES)
Ri-1 32 Bit
Expansionspermutation 48 Bit 48 Bit
Teilschlüssel Ki
48 Bit
Nichtlineare S-Box-Substitution 32 Bit
Permutation (P-Box) 32 Bit Ergebnis der DES-Funktion
Abbildung 4.14: Die DES-Funktion
dass die Werte in den S-Boxen, die angeblich von der NSA gegenüber dem originalen IBM-Entwurf geändert wurden, einen zuverlässigen Schutz gegen die differenzielle Kryptoanlayse bieten. Dies ist richtig, zeigt aber auch, dass dieses Verfahren, und vor allem auch der Schutz davor, der NSA schon vor 25 Jahren bekannt gewesen ist! Eingabe-Register (48 Bit) S-Box -1-
S-Box -2-
S-Box -3-
S-Box -4-
S-Box -5-
S-Box -6-
S-Box -7-
S-Box -8-
Ausgabe-Register (32 Bit) Bits 1 und 6 adressieren eine Zeile Bits 2 bis 5 adressieren eine Spalte Beisp.: Subst(101010) = 1101 (13)
S-Box - 5 0 0 1 2 3
1
2
3
4
5
6
7
2 12 4 1 7 10 11 6 14 11 2 12 4 7 13 1 4 2 1 11 10 13 7 8 11 8 12 7 1 14 2 13
8
9 10 11 12 13 14 15
8 5 3 15 13 5 0 15 10 3 5 9 12 5 6 6 15 0 9 10
0 14 9 9 8 6 3 0 14 4 5 3
Abbildung 4.15: Die fünfte S-Box der DES-Funktion
119
4 Sicherheitstechnologie
4.4.4
Die DES-Entschlüsselung
Durch eine DES-Entschlüsselung wird ein 64 Bit großer Chiffretext mit Hilfe des 56-Bit-Schlüssels, mit dem dieser Chiffretext erzeugt wurde, wieder in einen 64 Bit großen Klartextblock transformiert. Dies geschieht mit dem gleichen Algorithmus. Denn Sie haben im Abschnitt über Feistel-Netzwerke gelesen, dass man dieses sowohl zum Ver- als auch zum Entschlüsseln benutzen kann. Im Fall von DES laufen die Runden dazu einfach nur in umgekehrter Reihenfolge ab. Dies ist einfach dadurch zu realisieren, dass der Prozess in der ersten Runde mit dem Teilschlüssel 16 beginnt und in der letzten Runde mit dem Teilschlüssel 1 endet. Praktisch implementieren kann man dies ganz einfach, indem man die Richtung in den Schieberegistern umkehrt. Somit kann man den Algorithmus sowohl zum Verschlüsseln als auch zum Entschlüsseln benutzen. Genau genommen ist die Entschlüsselung eine Verschlüsselung, denn wenn man statt des Chiffretextes einen Klartext in die Dechiffrierung einspeisen würde, würde man einen Chiffretext erhalten. Dies macht man sich auch beim Triple-DES-Verfahren zunutze, um zum DES-Algorithmus kompatibel zu sein.
4.5
Triple-DES
Was für ein Eigentor die NSA sich mit DES geschossen hatte, wurde eigentlich erst mit der Entwicklung und Einführung von Triple-DES deutlich. Denn dieses Verfahren, um es gleich vorweg zu nehmen, kann auch eine National Security Agency nicht knacken. DES ist für die NSA kein Problem, da kommt ein Brute-Force-Angriff in Sekundenschnelle zu einem Ergebnis oder besser gesagt zu einem Schlüssel – mit Triple-DES ist allein schon der Versuch reine Zeitverschwendung. DES war schon zu Zeiten seiner Einführung 1977 zur Zielscheibe scharfer Kritik einer ganzen Reihe von Kryptologen geworden, unter ihnen auch Persönlichkeiten wie Whitfield Diffie. Deren Kritik richtete sich dabei weniger gegen den Algorithmus selbst als gegen dessen wirksame Schlüssellänge von nur 56 Bit. Diese wurde damals schon als viel zu kurz für ernsthafte Anwendungen angesehen. Diese Kritik hat die NSA aber herzlich wenig interessiert, denn wenn jemand die technischen Ressourcen hatte, DES mit einem Brute-ForceAngriff zu entschlüsseln, dann diese Organisation. Die Zeit arbeitete für die NSA, denn die Rechner wurden immer leistungsfähiger, und damit wurde die Zeit, die zur Berechnung eines DES-Schlüssels benötigt wurde, immer kürzer, während sich an der Sicherheit des Algorithmus wegen seiner festen Schlüssellänge nichts änderte. Denn schnellere Rechner verschlüsseln zwar schneller, aber dadurch nicht sicherer. Außerdem hatte die NSA ja auch noch »Plan B« in der Schublade, die US-Exportbeschränkungen für kryptographische Produkte. Die National Security Agency hat die Macht, andere Ministerien,
120
Triple-DES
wie zum Beispiel das US-Außenhandelsministerium, zu ihrem verlängerten Arm zu machen und die Ausfuhr bestimmter Produkte ganz einfach zu verbieten oder wenigstens per Genehmigungsverfahren regulieren zu lassen.
DES Encrypt 56 Bit
Schlüssel K1
DES Decrypt 56 Bit
Schlüssel K2
DES Encrypt 56 Bit
Chiffretext (64 Bit)
Klartext (64 Bit)
Aber mit zunehmender Entwicklung der Datenverarbeitung wurde der DESSchlüssel immer mehr zum Schwachpunkt des ganzen Verfahrens. Denn mittlerweile konnten kleine Organisationen oder sogar gut ausgerüstete Einzelpersonen den Schlüssel mit einem Brute-Force-Angriff brechen. Sie haben in diesem Kapitel erfahren, dass der Schutz gegen einen Brute-Force-Angriff genau genommen recht einfach ist, man braucht nur den Schlüssel länger zu machen. Denn mit jedem Bit mehr Schlüssellänge verdoppelt sich auch die Suchzeit. Allerdings bedingt dies einen Algorithmus mit variabler Schlüssellänge, und genau das ist DES nicht. Der DES-Schlüssel ist 56 Bit lang, und die Erzeugung der Teilschlüssel aus jedem einzelnen dieser Bits ist im Standard genau festgelegt.
Schlüssel K3
Abbildung 4.16: Triple-DES verkettet drei DES-Durchläufe zu einer Verschlüsselung.
Aus dieser Sackgasse schien es auf den ersten Blick keinen praktikablen Ausweg zu geben. Denn den Algorithmus zu ändern, hätte eine Inkompatibilität zu bestehenden Systemen bedeutet. Das gleiche galt für die Entwicklung eines gänzlich neuen Algorithmus. Der Ausweg, der sich bot, hieß Triple-DES, also eine dreifache Verschlüsselung mit DES, und damit die Möglichkeit, auch Standard-DES benutzen zu können. Triple-DES verkettet, wie in Abbildung 4.16 zu sehen ist, drei DES-Durchläufe miteinander, die jeweils unterschiedliche Teilschlüssel benutzen. Es erfolgt zuerst eine Verschlüsselung mit dem Schlüssel K1, dann eine Entschlüsselung mit dem Schlüssel K2 und zuletzt wieder eine Verschlüsselung mit dem Schlüssel K3. Somit wurde der Klartext dreifach verschlüsselt, und für einen Brute-Force-Angriff müsste man alle 2168 Möglichkeiten ausprobieren, die die drei Schlüssel zusammen bieten. Und dies ist nicht möglich. Die geforderte Kompatibilität zu DES erreicht man ganz einfach dadurch, dass man den 56-Bit-DES-Schlüssel gleichzeitig allen drei Stufen von Triple-DES zuführt.
121
4 Sicherheitstechnologie
An dieser Stelle ist noch eine Sonderversion zu erwähnen, die gelegentlich zu finden ist und nur eine effektive Schlüssellänge von 112 Bit aufweist. In dieser Variante sind der erste und der letzte Schlüssel der drei Triple-DES-Stufen gleich. Somit ergibt sich für einen Brute-Force-Angriff ein zu durchsuchender Schlüsselraum von 112 Bit. Für diesen Wert ergeben sich allerdings Suchzeiten, die in Jahrtausenden gemessen werden, so dass auch hier noch von einem starken Algorithmus gesprochen werden kann.
4.6
Cipher Block Chaining (CBC)
Bei aller Stärke von DES, abgesehen von seiner Grund-Schlüssellänge, und Triple-DES – es sind monoalphabetische Algorithmen! Das heißt, dass zu einem gegebenen Schlüssel gleiche Klartextblöcke auch gleiche Chiffretextblöcke erzeugen. Damit wäre aber die Möglichkeit eines Angriffs mit statistischen Methoden gegeben, da ein Angreifer in der Praxis sehr schnell erkennen kann, wenn sich bestimmte Muster im Chiffretext wiederholen. Zum Beispiel erzeugen die immer gleichen Signaturen in E-Mails oder auch die Mail-Header in der Regel mehrere Blöcke Chiffretext, die sich untereinander auch gleichen. Ein solcher Angriff vermag jedoch nicht den Schlüssel zu berechnen. Es ist aber möglich, auf den Klartext zurückzuschließen, was auch schon schlimm genug ist. Aus diesem Grunde wird DES, wie auch alle anderen Blockchiffre-Verfahren, in einer speziellen Betriebsart, dem CBC-Modus (Cipher Block Chaining) betrieben. Das Ziel dieses Verfahrens ist es, mit Hilfe eines monoalphabetischen Block-Chiffreverfahrens eine polyalphabetische Ver- oder Entschlüsselung durchzuführen. Es sollen also gleiche Klartextblöcke zu einem gegebenen Schlüssel verschiedene Chiffretextblöcke erzeugen. Klartextblock MI LetzterChif fretextblock C I-1
DES Encrypt
CI
Chiffretextblock
Abbildung 4.17: Das Cipher Block Chaining eliminiert den Monoalphabetismus von DES.
122
Cipher Block Chaining (CBC)
CBC erreicht dies, indem jeder Klartextblock vor der Verschlüsselung mit dem unmittelbar vorher erzeugten Chiffretextblock Exklusiv-Oder-verknüpft wird. Auf diese Weise ist garantiert, dass sich die Blöcke, die dem DES-Algorithmus als Eingangswert zugeführt werden, von den ursprünglichen Eingangsblöcken unterscheiden. Demzufolge erzeugen gleiche Klartextblöcke verschiedene Chiffretextblöcke, und es liegt praktisch eine polyalphabetische Verschlüsselung vor.
4.6.1
Die Funktionsweise von CBC
Wie in Abbildung 4.17 zu sehen ist, benutzt man zur Exklusiv-Oder-Verknüpfung den Chiffretext des unmittelbar vorher verschlüsselten Blocks. Was aber macht man mit dem ersten Klartextblock? Um dieses Problem zu lösen, benötigt man noch einen weiteren Parameter, den so genannten Initialisierungsvektor (IV). Dieser Initialisierungsvektor, dessen Länge gleich der Länge der Klartextblöcke sein muss, also 64 Bit im Falle von DES, ist hinsichtlich seiner Erzeugung und Vertraulichkeit recht unkritisch. In der Praxis erzeugt man einfache Pseudo-Zufallszahlen oder benutzt den gespeicherten Chiffretext der letzten Verschlüsselung. In Abbildung 4.18 sehen Sie, dass der Initialisierungsvektor sowohl zum Ver- als auch zum Entschlüsseln benutzt wird. Im Gegensatz zum Schlüssel und dem Klartext braucht der IV aber nicht geheim zu sein. Manche Protokolle wie IP Security übertragen ihn in jedem Datenpaket unverschlüsselt vor dem Chiffretext. M
M
M
E
E
E
C
C
C
C
C
C
D
D
M
M
IV
D
IV
M
E=Encrypt, D=Decrypt, M=Klartext, C=Chiffretext, IV=Intialisierungsvektor
Abbildung 4.18: CBC-Ver- und -Entschlüsselung mit explizitem Initialisierungsvektor
123
4 Sicherheitstechnologie
Wichtig für den Initialisierungsvektor ist, dass er sich während der Verwendungsdauer des Schlüssels nicht wiederholt, dass also bei verschiedenen Paketen oder Übertragungssitzungen nicht der gleiche verwendet wird.
4.7
Ausblick: Der Advanced Encryption Standard
Obwohl er immer noch nicht »geknackt« ist und man mit Triple-DES das Problem des kurzen, nur 56 Bit langen Schlüssels entschärft hat, sucht man seit einiger Zeit schon nach einem Nachfolger für den doch schon etwas betagten DES-Standard. Man, das ist das amerikanische National Institute of Standards and Technology (NIST), eine Behörde des US-Handelsministeriums, die sich unter anderem mit Standards für IT-Sicherheit befasst. Am 2. Januar 1997 begann das NIST mit den Vorbereitungen für die Ausschreibung des Advanced Encryption Standard (AES), der zur Sicherung von Informationen in US-Regierungsbehörden bis weit in das nächste Jahrhundert geeignet sein sollte. Da dieser nationale Behördenstandard auch von der USamerikanisch dominierten Internet Engineering Task Force (IETF) als zwingend vorgeschriebener Verschlüsselungsalgorithmus in den IPSec-Standard adaptiert werden wird, sind hier ein paar Worte zum Auswahlverfahren und dem zum Zeitpunkt der Drucklegung dieses Buches verbliebenen, vorgeschlagenen und vorläufigen AES-Kandidaten angebracht. Am 12. September 1997 wurden Industrie und Forschung in aller Welt um Einreichung eines passenden Algorithmus gebeten. Dies sollte ein nicht als geheim eingestuftes, offen gelegtes und weltweit kostenfreies Verfahren sein, das bestimmten Anforderungen genügen musste: 왘 Der AES muss öffentlich spezifiziert werden und darf daher nicht als
geheim eingestuft sein. 왘 Der AES muss ein symmetrischer 128-Bit-Blockchiffrieralgorithmus sein. 왘 Der AES muss eine, bei 128 Bit beginnende, nach oben erweiterbare
Schlüssellänge unterstützen. Explizit unterstützt werden müssen Schlüssel mit 128, 196 und 256 Bit. 왘 Der AES muss sowohl in Software als auch in Hardware zu implementie-
ren sein. 왘 Der AES muss entweder frei verfügbar sein oder unter die ANSI-Patentpo-
litik fallen.
124
Ausblick: Der Advanced Encryption Standard
Die eingereichten Algorithmen werden, sofern sie diesen Bedingungen genügen, intensiv auf folgende Punkte hin geprüft: 왘 Sicherheit 왘 Performance und Effizienz 왘 Speicheranforderungen, insbesondere Arbeitsspeicherverbrauch 왘 Eignung zur Hardware- und Software-Implementierung 왘 Eignung zum Einsatz auf Chipkarten 왘 Einfachheit 왘 Flexibilität 왘 Lizenzbedingungen
Im Hinblick auf zukünftige Entwicklungen, insbesondere im Bereich Electronic Commerce, müssen die Algorithmen sowohl sehr performant in Software als auch in Hardware implementiert werden können. Auch an Smartcards wurde gedacht, die Algorithmen sollen auf den verschiedenen Modellen mit dem Smartcard-üblichen geringen Arbeitsspeicher von teilweise nur 64 Byte auskommen! Am 20. August 1998 veröffentlichte das NIST die Beschreibungen von fünfzehn Algorithmen, die von den unterschiedlichsten Organisationen aus zwölf verschiedenen Ländern zur Prüfung eingereicht wurden. Es wurde anschließend weltweit um Kommentare zu den AES-Kandidaten gebeten, um – ebenfalls mit möglichst breiter Mitwirkung – die Sicherheit, Performance und universelle Einsetzbarkeit der Verfahren kritisch zu beurteilen. Dieses Verfahren wurde am 15. April 1999 abgeschlossen. Aufgrund dieser Kommentare und ihrer weiteren Auswertung blieben letztendlich fünf, nach Ermessen des NIST ernst zu nehmende Algorithmen übrig. Dies waren MARS, RC6, Rijndael, Serpent und Twofish. Der Prozess soll im Sommer 2001 abgeschlossen sein, wobei sich das NIST auch ausdrücklich offen hält, dass der AES auch aus mehreren Algorithmen bestehen kann. Inzwischen, Stand Dezember 2000, hat sich das NIST für einen der Kandidaten entschieden und diesen als vorläufigen AES vorgeschlagen. Ein weiterer Algorithmus wurde bisher nicht ausgewählt, da das NIST TripleDES als geeigneten Backup-Algorithmus ansieht. Die offizielle Verabschiedung des Standards wird für 2001 erwartet – falls sich bis dahin keine neue politische Situation in den USA ergibt und die NSA dagegen einschreitet.
125
4 Sicherheitstechnologie
4.7.1
AES-Software-Implementierung
Da der alte DES-Standard, die Entwicklungen bei IBM begannen bereits Ende der 60er Jahre, für die damals verfügbare Hardware entwickelt wurde, sind dessen Software-Implementierungen nicht besonders leistungsfähig. Es müssen sogar, will man den DES standardkonform in Software implementieren, kryptographisch völlig sinnlose, sich gegenseitig aufhebende Operationen wie die lineare Eingangs- und Ausgangspermutation implementiert werden, nur weil sie Anfang der 70er Jahre wegen der damals zur Verfügung stehenden Hardware nötig waren. AES hingegen soll möglichst unabhängig von der eingesetzten Systemarchitektur sein. Sowohl heutige Intel-, PowerPC- oder Sparc-Prozessoren als auch zukünftige Prozessoren müssen unterstützt werden können. Deshalb ist das Design auch auf höhere Programmiersprachen hin abgestimmt. Gewisse Registerbreiten oder spezielle Prozessorbefehlssätze dürfen nicht erforderlich sein, eine Implementierung in C läuft sowohl auf einem Z80- als auch auf einem PowerPC-Prozessor. So fordert das NIST, dass sowohl eine ANSI-C-Referenzimplementierung im Sourcecode als auch optimierte Implementierungen in ANSI-C und Java zum eingereichten Algorithmus mitgeliefert werden. Eine Organisation, die einen Algorithmus einreicht, muss weiterhin garantieren, dass er zum einen auf 8-Bit-Prozessoren in Smartcard-Umgebungen zu implementieren ist und zum anderen auch als Basis für Stromchiffrierverfahren, Pseudo-Zufallsgeneratoren, MAC-Generatoren und Hashverfahren verwendet werden kann. Somit wurden durch das Einreichen der Algorithmen eine Reihe von Sourcen in C, Java und Assembler veröffentlicht, teilweise schon mit Optimierungen für bestimmte Prozessoren oder Smartcards. Da alles wirklich sehr gut dokumentiert und beschrieben ist, ist dieser öffentliche Auswahlprozess eine wahre Fundgrube für kryptographisch Interessierte.
4.7.2
AES-Hardware-Implementierung
Bei einer Verschlüsselung mit sehr hoher Bandbreite setzt man nicht selten Hardwarelösungen ein, sowohl als Beschleunigerkarten, um das Muttersystem zu entlasten, als auch als reine Verschlüsselungsgeräte. Man kann es schon fast als Faustregel nehmen, dass symmetrische Blockchiffrierverfahren als echte Hardware-Implementierung um den Faktor 10 schneller sind als ihr Softwarepedant. Das kann sich zwar von Algorithmus zu Algorithmus unterscheiden, und bestimmte Verfahren sind auch in Software sehr gut zu optimieren, jedoch oft auf Kosten eines immensen Speicherverbrauchs. Oder man programmiert in Maschinensprache und benutzt bestimmte Prozessor-Eigenschaften – dann allerdings auf Kosten der Portabilität.
126
Ausblick: Der Advanced Encryption Standard
Bei der Hardware-Implementierung gibt es drei verschiedene Möglichkeiten: 왘 Der Algorithmus wird in einem speziell für ihn entwickelten Chip imple-
mentiert. 왘 Der Algorithmus wird in speziellen Prozessoren, wie digitalen Signalpro-
zessoren (DSP), Encryption-Chipsätzen und Ähnlichem per Mikrocode implementiert. 왘 Der Algorithmus wird in einer Smartcard implementiert.
Die Geschwindigkeiten hierbei unterscheiden sich teilweise erheblich. Am besten schneidet meist der Chip ab, der speziell für den Algorithmus entworfen wurde. Hiermit sind nicht programmierbare Microcontroller gemeint, sondern wirklich neue Maskendesigns. An zweiter Stelle hinsichtlich der Geschwindigkeit sind Implementierungen in DSPs und ähnlichen Chips zu finden. Implementierungen in Smartcards fallen genau genommen gar nicht unter die Rubrik Hardware-Implementierung. Da sie aber sehr oft fälschlicherweise in diesem Zusammenhang genannt werden, sind sie hier mit aufgeführt. Denn bei einer Smartcard entsteht genau der umgekehrte Effekt: Das Ganze wird nicht schneller, sondern langsamer, und zwar meist um Größenordnungen. Dies wird auch verständlich, wenn wir uns einmal das Innenleben einer Smartcard anschauen. Es handelt sich dabei einfach um eine kleine, flache Computerzentraleinheit mit CPU, ROM, RAM und einfacher I/O-Peripherie. Die Auslöser der Performanceprobleme von Smartcards sind zum einen der Prozessor, meist ein 8-Bit-System auf Z80- oder 6805-Basis mit Geschwindigkeiten unter 20 MHz, und zum anderen der spärliche Arbeitsspeicher von oft nur 64 oder 128 Byte Größe! Diese beiden Faktoren zusammen verhindern eine wirkungsvolle Optimierung, und es tritt auch noch ein weiterer negativer Effekt auf: Der Schlüssel und je nach Algorithmus viele Werte wie S-Box-Einträge müssen laufend dynamisch neu berechnet und wieder gelöscht werden, da die Daten aufgrund der geringen Speicherkapazität nicht dauerhaft im Arbeitsspeicher bleiben können. So können Smartcards leicht hundertmal langsamer als Implementierungen auf einem 200-MHzPentium-Pro-PC sein; als aktuellen Wert für ihre Implementierung nennt die Twofish-Truppe um Bruce Schneier zum Beispiel den Faktor 92.
4.7.3
AES-Geschwindigkeit und Optimierungsmöglichkeiten
Die Geschwindigkeiten der AES-Kandidaten sind schon als Software-Implementierung sehr hoch. Somit ist ihre Sicherheit bei Schlüssellängen bis zu 256 Bit und mehr schon signifikant höher als die von Triple-DES – und das bei einer Geschwindigkeit, die deutlich über der von 56-Bit-DES liegt.
127
4 Sicherheitstechnologie
MARS von IBM soll auf einem Pentium-Pro mit 200 MHz einen Durchsatz von 65 Mbit/s bringen, die Geschwindigkeit von RC6 wird von der Ron-RivestTruppe auf einem 180-MHz-Pentium-Pro-PC mit 64 MB RAM und NT4.0, also unter realen PC-Bedingungen, mit 42 Mbit/s bei beliebiger Schlüssellänge angegeben. Wer schon Erfahrung in der Programmierung hat, weiß, dass sich zwei Optimierungsmöglichkeiten oft gegenseitig ausschließen: die Optimierung auf Geschwindigkeit und die auf Arbeitsspeicherverbrauch. Mit anderen Worten: Mit ausreichend Speicher kann man ein Programm sehr schnell machen, und umgekehrt führt das Optimieren auf keinen Speicher meist zum Verlangsamen der Ausführungsgeschwindigkeit. Aus diesen Gründen finden sich meist zwei Varianten, in denen die AES-Kandidaten implementiert werden. Zum einen gibt es die Variante, bei der aufgrund von Hardwarelimitierungen sehr wenig Speicher zur Verfügung steht und bei der man auf Speicherplatz optimiert. Zum anderen gibt es die Variante, bei der genügend Speicher vorhanden ist, um die Ausführungsgeschwindigkeit zu optimieren. Was bei Algorithmen, die Funktionen wie schlüsselabhängige S-Boxen einsetzen, noch hinzukommen kann, ist die Möglichkeit, eine große Anzahl von Zwischenwerten vorauszuberechnen und zu speichern. Damit hat man zwar zu Beginn der Verschlüsselung eine gewisse Verzögerung, kommt dafür aber bei allen nachfolgenden Blöcken in den Genuss einer noch höheren Geschwindigkeit.
4.7.4
»And the winner is …. Rijndael«
Zum Erstaunen vieler Beobachter fiel die Vorentscheidung des NIST auf einen Algorithmus, der nicht in den USA entwickelt wurde. Der Rijndael-Algorithmus wurde in Europa, genauer gesagt in Belgien, entwickelt. Er ist eine Entwicklung von Dr. Joan Daemen von Proton World International und von Dr. Vincent Rijmen von der katholischen Universität Leuven. Aus deren Nachnamen wurde der Name des Algorithmus abgeleitet. Rijndael hat sich letztendlich gegen die Entwürfe von IBM, RSA, Counterpane und anderer hochkarätiger Kryptographie-Spezialisten durchgesetzt. Der Algorithmus wurde vom NIST ausgewählt, weil er die ausgewogenste Verteilung hinsichtlich aller gestellten Anforderungen aufwies und gleichermaßen leistungsfähig sowohl in Soft- und Hardware als auch auf Hochleistungs-Parallelrechnern und Smartcards zu implementieren ist. Die Sicherheit des Verfahrens entspricht ebenfalls den gestellten Anforderungen. Darüber hinaus ist der Rijndael-Algorithmus eines der ganz wenigen symmetrischen Verschlüsselungsverfahren, das nicht auf Feistel-Netzwerken beruht. Es wird zwar auch eine Reihe von Transformationsrunden durchlaufen, aber in jeder dieser Runden werden alle Bits transformiert – und nicht nur die Hälfte der Bits wie im Feistel-Netzwerk. Rijndael ist ein sehr schneller Algorithmus,
128
Asymmetrische Verschlüsselungsverfahren
der auch auf Smartcards sehr performant zu implementieren ist. Sein Bedarf an Hardware-Ressourcen ist dabei ebenfalls sehr gering. Rijndael kann auch sehr gut auf Parallelrechnern implementiert werden, da sich seine Transformationen für die Verschlüsselung eines einzigen Blocks sehr gut parallelisieren lassen. Die nichtlineare Komponente von Rijndael bilden, wie in allen anderen Algorithmen auch, S-Boxen auf Byte-Basis, die hier aber auf dem endlichen GaloisFeld GF(28) beruhen. Die Anzahl der zu durchlaufenden Runden hängt auch von der Länge des Schlüssels ab, und somit sinkt bei Rijndael der Durchsatz bei großen Schlüsseln! Jedoch kann der Algorithmus sehr schnell die Werte der S-Boxen vorberechnen und, falls die Systemumgebung dies zulässt, auch speichern, um die eigentliche Transformation zu beschleunigen. Wer sich die Beschreibung des Algorithmus ansieht und kein Zahlentheoretiker ist, der wird bei einem Vergleich mit der Einfachheit von DES zuerst einmal erschrecken. Allerdings ist die Abhängigkeit der S-Boxen von bestimmten mathematischen Strukturen auch ein Kritikpunkt, denn hier könnte sich theoretisch ein wunder Punkt herauskristallisieren, falls sich äquivalente mathematische Beschreibungen zu Rijndael entwickeln ließen. An dieser Stelle vielleicht noch ein Hinweis zu den anderen fünf Finalisten: Das NIST betont ausdrücklich, dass sich, insbesondere im Hinblick auf die Sicherheit der Algorithmen, nicht herausgestellt habe, dass die »Verlierer« schlechter oder unsicherer seinen als Rijndael. Sie werden in Zukunft mit Sicherheit auf den einen oder anderen Algorithmus stoßen, da die Unternehmen ihre Entwicklungen sicher vermarkten werden. Diese Verfahren sind sicher und in entsprechenden Umgebungen schnell – in jedem Fall aber schneller als DES und mindestens genauso sicher!
4.8
Asymmetrische Verschlüsselungsverfahren
In diesem Kapitel wurde bisher stillschweigend davon ausgegangen, dass die symmetrischen Schlüssel zum Chiffrieren und Dechiffrieren bei Sender und Empfänger bekannt sind. Wie sie dorthin gelangt sind, wurde nicht weiter beachtet. Dies kann jedoch ein sehr schwerwiegendes Problem sein, insbesondere dann, wenn sehr viele mögliche Sender und Empfänger existieren oder sich zwei Partner vorher gar nicht kennen. Wo liegt das Problem?
4.8.1
Die kurze Geschichte der Public-Key-Kryptographie
Nehmen wir einmal den Fall an, dass zwei Personen ihre Kommunikation, bespielsweise ihre Internet-E-Mail, verschlüsseln möchten. Da beide sehr sicherheitsbewusst sind, möchten sie das Triple-DES-Verfahren benutzen. In
129
4 Sicherheitstechnologie
diesem Fall können sich beide persönlich treffen und den Schlüssel austauschen, oder sie können ihn sich per Post auf Papier oder Datenträger zustellen. Aber in keinem Fall können sie den Austausch aber über das Internet vornehmen, denn dann könnte ein Unbefugter mitlesen! Selbst das Postverfahren ist nicht hundertprozentig sicher. Wenn beide zudem einige tausend Kilometer voneinander entfernt wohnen, ist ein persönliches Treffen unvorteilhaft, insbesondere dann, wenn es sich nicht nur um zwei Personen, sondern um die 100.000 Mitarbeiter eines Unternehmens handelt. Und was ist, wenn sich beide gar nicht vorher persönlich kennen? Oder wenn Sie, um ein praktisches Beispiel zu nehmen, sich an einem E-Commerce-Webserver anmelden und Ihre Kreditkarteninformationen verschlüsselt übertragen möchten? Wie einigen Sie und der Server sich auf einen symmetrischen Schlüssel? Dieses Problem war für die Kryptologen in aller Welt eine harte Nuss. Den meisten erschien das Problem praktisch unlösbar, so dass sich in den sechziger und siebziger Jahren fast niemand mehr ernsthaft mit der Thematik der Schlüsselverteilung auseinander setzte. Zum Glück gab es aber noch einige Unentwegte, die sich den Kopf darüber zerbrachen, wie dieses Problem gelöst werden konnte. Zwei dieser Forscher, die Mathematiker Whitfield Diffie und Martin Hellman, begannen im Jahr 1974 eine Zusammenarbeit, deren Resultat (sowie die daraus folgenden Entwicklungen) die Kryptologie revolutionieren sollte. Ralph Merkle, eine weitere Kryptographie-Größe, stieß noch zu dem Team, und zwei Jahre später, im Jahr 1976, war es soweit. Martin Hellman hatte einen Ansatz gefunden, der auf dem Problem des diskreten Logarithmus (siehe unten) beruhte und als Diffie-Hellman-Merkle-Verfahren Geschichte machte. Bei der Vorstellung ihrer Lösung vor einem verblüfften Fachpublikum anlässlich einer Tagung der National Computer Conference 1976 staunten die Experten über die geniale Einfachheit und gleichzeitige Stärke des Verfahrens, und den ersten Teilnehmern dämmerte die wirkliche Bedeutung dessen, was sie gerade eben gehört hatten, für die weitere Entwicklung unserer Informationsgesellschaft. Für Whitfield Diffie war das aber genau genommen nur ein halber Durchbruch. Das Verfahren eignete sich zwar hervorragend zum Schlüsseltausch, aber man konnte keine Daten damit verschlüsseln. Ihm schwebte die ganze Zeit über ein gänzlich neues Prinzip vor, bei dem man etwas mit einem speziellen Schlüssel verschlüsseln konnte, das nur mit einem dazugehörigen anderen Schlüssel wieder zu entschlüsseln war – ein asymmetrisches Verschlüsselungsverfahren. Der Schlüssel zum Verschlüsseln konnte bei diesem Konzept jedermann weltweit bekannt sein, denn er konnte ja nur zum Ver-, aber nicht mehr zum Entschlüsseln benutzt werden. Als Methode zur Realisierung schwebte Diffie eine besondere Einwegfunktion vor, zu der es eine so genannte Hintertür- oder Falltür-Funktion (trapdoor function) gibt, die deren Einwegfunktionalität umgehen kann. Die Kenntnis dieser Hintertür ist die Basis für die Entschlüsselungsfunktion.
130
Asymmetrische Verschlüsselungsverfahren
Whitfield Diffie stellte dieses Konzept 1975 der Öffentlichkeit vor, und tatsächlich begannen einige Forscher, allen voran natürlich Diffie, Hellman und Merkle, damit, die geeigneten Einwegfunktionen zu suchen – jedoch vorerst ohne Erfolg. Die Idee war super, nur eine passende Einwegfunktion nebst dazugehöriger Hintertür-Funktion war einfach nicht zu finden. Erst im April 1977 und über 3.000 Meilen von der Wirkungsstätte Whitfield Diffies entfernt, an der Ostküste der USA, im Labor für Computerwissenschaften des Massachusetts Institute of Technology (MIT), fand ein anderes Forscher-Trio eine Lösung des Problems. Dr. Ronald Rivest hatte dort ein Jahr zuvor den Artikel von Diffie und Hellman über die asymmetrische Kryptographie gelesen und unmittelbar begriffen, was für ein Potenzial darin verborgen lag. Er konnte damals auch seine beiden Kollegen Adi Shamir und Leonard Adleman überzeugen, sich mit ihm zusammen auf die Suche der Einwegfunktion und ihrer Hintertür zu machen. Nachdem sie ein Jahr lang zunehmend frustrierter eine ganze Reihe unbrauchbarer Ansätze aussortiert hatten, kam Ron Rivest im April 1977 ein Verfahren in den Sinn, das heute als das RSA-Verfahren (siehe unten), benannt nach den Initialen der drei Forscher, weltbekannt und eines der am meisten eingesetzten so genannten Public-Key-Verfahren ist. RSA machte sich ein anderes mathematisches Problem zunutze als das DiffieHellman-Verfahren, nämlich das so genannte Faktorisierungsproblem. Es ist nämlich sehr einfach und schnell möglich, zwei sehr große Primzahlen miteinander zu multiplizieren, aber es ist praktisch unmöglich, das Ergebnis wieder in die ursprünglichen Faktoren zu zerlegen. Die zur Entschlüsselung notwendige Hintertür des Verfahrens leitet sich aus der Kenntnis der beiden Primfaktoren ab. Beide Verfahren, RSA- und Diffie-Hellman, wurden in den USA kurz nach ihrer Veröffentlichung patentiert. Jawohl, Sie haben richtig gelesen, patentiert, denn obwohl es in den USA, wie auch in praktisch allen anderen Staaten, normalerweise nicht möglich ist, mathematische Algorithmen zu patentieren, wurden beide Verfahren geschützt. Jedoch sind beide Patente mittlerweile abgelaufen, und jedermann kann die Verfahren frei von irgendwelchen Gebühren einsetzen.
4.8.2
Das Grundprinzip der Public-Key-Kryptographie
Die Grundpfeiler der Public-Key-Kryptographie sind ungelöste oder so genannte schwierige mathematische Probleme. Besonders geeignet sind mathematische Funktionen, die sich in eine Richtung sehr einfach und schnell berechnen lassen, deren Umkehrung hingegen sehr schwierig und langwierig ist. Langwierig bedeutet hier Zeitspannen zwischen einigen tausend Jahren und dem Alter des Universums. Praktisch gesehen sind solche Einwegfunk-
131
4 Sicherheitstechnologie
tionen also nicht umkehrbar. Nicht umkehrbar bedeutet aber auch, dass man etwas, was durch diese Funktionen verschlüsselt wurde, nicht mehr in sinnvoller Zeit entschlüsseln kann. Das ist richtig und bei speziellen Algorithmen, wie dem Diffie-Hellman-Verfahren zur Schlüsselerzeugung, auch essenziell. Andere Public-Key-Algorithmen, die sowohl ver- als auch entschlüsseln sollen, bedienen sich eines speziellen Tricks, der so genannten Falltür-Funktion (trapdoor function). Diese Funktion kennt eine Art und Weise, wie sie mit einem speziellen Geheimnis, dem privaten Schlüssel, den Chiffretext wieder in den Klartext transformieren kann. Wie dieser Trick funktioniert, werden Sie nach dem folgenden kleinen Überblick über die mathematischen Grundlagen der Public-Key-Kryptographie am Beispiel des RSA-Verfahrens erfahren.
4.8.3
Mathematische Grundlagen
Dieser Abschnitt soll nur einen recht oberflächlichen, aber zum Verständnis notwendigen Überblick über die Mathematik geben, die in der Public-KeyKryptographie benutzt wird. Wer sich tiefer in das Gebiet der Zahlentheorie einarbeiten möchte, dem sei die weiterführende Literatur hierzu empfohlen. Primzahlen Eine Primzahl ist eine Zahl, die nur durch 1 und sich selbst teilbar ist. Es gibt unendlich viele Primzahlen. Die einzig bekannte gerade Primzahl ist die 2, alle anderen sind ungerade. Jede gerade Zahl größer als 2 ist die Summe zweier Primzahlen. Das ist zwar mathematisch nicht bewiesen, sondern nur eine Vermutung, die so genannte Goldbachsche Vermutung, trifft aber auf alle bisher untersuchten geraden Zahlen zu. Die Häufigkeit des Vorkommens von Primzahlen nimmt mit wachsender Größe der Zahlen ab. Im Bereich von Zahlen bis 512 Bit Länge gibt es ca. 10151 Primzahlen. Im Vergleich dazu besteht unser Universum aus »nur« ca. 1077 Atomen! Das vereinfacht die Erzeugung von Primzahlen auf Zufallsbasis enorm, denn die Wahrscheinlichkeit, dass zwei unabhängige Systeme zufällig die gleiche Primzahl auswählen, ist kleiner als die Wahrscheinlichkeit, sein Leben lang jeden Tag im Lotto zu gewinnen. Aber wie erzeugt man auf Zufallsbasis eine große Primzahl? Natürlich sind nicht alle Primzahlen bekannt, und man kann auch vor allem nicht alle 10151 Primzahlen im Bereich von 512 Bit berechnen und diese in einem Primärspeicher speichern. Primzahlerzeugung Das Problem der Erzeugung von sehr großen Primzahlen lässt sich etwas entschärfen, wenn man sich mit etwas weniger als 100% zufrieden gibt, wenn es also ausreicht, wenn eine Zahl mit 99,999% Wahrscheinlichkeit eine Primzahl
132
Asymmetrische Verschlüsselungsverfahren
ist. Man generiert große, ungerade Zufallszahlen und testet diese mit probalistisch arbeitenden Testverfahren, die mit einer bestimmten Wahrscheinlichkeit arbeiten. Eines der bekanntesten, schnellsten und am häufigsten implementierten Verfahren ist der Rabin-Miller-Algorithmus. Eine vollständige Rechner-Implementierung zur Primzahlerzeugung auf Basis dieses Algorithmus für 512-Bit-Zahlen arbeitet nach folgendem Algorithmus: 1. Erzeuge eine Zufallszahl p der Länge 512 Bit. 2. Setze das höchst- und das niederwertige Bit von p auf 1, um die Zahl hinreichend groß und garantiert ungerade zu machen. 3. Mache einen ersten Test, ob p durch die bekannten Primzahlen von 3 bis 2000 teilbar ist. Dadurch werden bereits über 95% aller ungeraden, nicht primen Zahlen eliminiert. 4. Falls keine Teilbarkeit besteht, wird der Rabin-Miller-Algorithmus für p sechsmal durchlaufen. Wenn alle Tests erfolgreich waren, hat man mit hinreichender Wahrscheinlichkeit eine 512 Bit große Primzahl p gefunden. Aufgrund der hohen Wahrscheinlichkeit von 99,999% müssen alle Angreifer (oder etwas neutraler formuliert: Kryptoanalytiker) in ihren Verfahren davon ausgehen, dass es sich tatsächlich um eine Primzahl handelt – wahrscheinlich ist es ja auch eine. Modulo primitiv Eine Zahl g ist modulo n primitiv, wenn es für jedes b > 0 < n eine Zahl z gibt mit gz = b (mod n). Man nennt g auch Generator (mod n). In unserem obigen Beispiel von Diffie-Hellmann »erzeugt« man ein g, das modulo primitiv zu n ist, auf folgende Art und Weise: Man nimmt nacheinander Zahlen, sinnvollerweise fängt man mit sehr kleinen an, und probiert sie aus. Das dauert in der Regel nicht sehr lange, da Generatoren sehr häufig vorkommen. Relativ prim Zwei Zahlen sind relativ prim zueinander, wenn sie außer 1 keinen gemeinsamen Teiler besitzen. Die Zahlen 15 und 28 sind relativ prim zueinander, sie sind zwar keine Primzahlen, haben aber außer 1 keinen gemeinsamen Teiler. Aufgrund ihrer Natur ist eine Primzahl zu allen Zahlen, die kein Vielfaches ihr selbst sind, relativ prim. Rechnen mit Resten (Moduln) In der Kryptographie spielt die modulare Arithmetik, also das Rechnen mit Resten, eine wichtige Rolle. Praktisch kein Public-Key-Verfahren kommt daran vorbei. Ein einfaches Beispiel für modulare Arithmetik ist unsere Armbanduhr, die die aktuelle Tageszeit »Modulo 12« anzeigt: 22 mod 12 = 10, d.h.
133
4 Sicherheitstechnologie
es wird 10 Uhr (22 dividiert durch 12 ist 1 Rest 10) angezeigt, falls es 22:00 Uhr ist. Aber es wird auch 10 Uhr angezeigt, wenn es tatsächlich 10 Uhr ist. Mathematisch ausgedrückt heißt dies: 22 und 10 sind äquivalent modulo 12. Allgemein ausgedrückt gilt für alle a ≥ 0 und 0 > b < n: a = b (mod n), wenn es eine ganze Zahl k gibt, mit a = b + kn Das Ergebnis von a mod n nennt man das Residuum, die Operation selbst modulare Reduktion. Die modulare Arithmetik verhält sind analog der normalen Arithmetik, sie ist kommutativ, distributiv und assoziativ: (a + b) mod n = ((a mod n) + (b mod n)) mod n (a * b) mod n = ((a mod n) * (b mod n) mod n Speziell im Bereich der Berechnungen in Computern sollte man sich auch folgende Beziehung vergegenwärtigen: a8 mod n = (a * a * a * a * a * a * a * a) mod n = ((a2 mod n)2 mod n)2 mod n Was macht die modulare Arithmetik für die Kryptographie eigentlich so interessant? Schauen wir uns einmal kurz die Mathematik des weiter unten beschriebenen Diffie-Hellman-Verfahrens an. Hier wird ein Wert A durch die Funktion A = gx mod n erzeugt. Entsprechend große x und n vorausgesetzt, handelt es sich dabei um eine Einwegfunktion, denn man kann x nicht mehr aus A zurückberechnen, auch nicht bei Kenntnis von g und n. Nehmen wir der Einfachheit halber einmal kleine Zahlen für ein kurzes Beispiel; g soll gleich 2 und n gleich 11 sein. Die Zahl n muss eine Primzahl sein. Als Vergleich dazu nehmen wir die Funktion B = gx, also die gleiche Exponentiation, jedoch ohne modulare Reduktion. Diffie-Hellman erlaubt es, alle Werte außer der geheim zu haltenden Zahl x zu veröffentlichen. Somit haben wir zwei Funktionen, A = 2x mod 11 und B = 2x. Das Ziel eines Angriffs auf das Verfahren ist es, den geheimen Wert x zu ermitteln, alle anderen Werte sind ja bekannt. Das Verfahren, x bei der Funktion B = gx zu ermitteln ist einfach. Nehmen wir einmal den Fall, dass x = 6 und damit B = 64 wäre. Man wählt eine Hilfszahl h und wählt einen möglichen Wert dafür aus, zum Beispiel 4, und rechnet 24 = 16. 16 ist kleiner als 64, also wird h höher gewählt, z.B. 8, und man rechnet 28 = 256. Dieser Wert ist größer als 64, also muss der Wert x dazwischen liegen. Man nimmt einen Zwischenwert, und mit h = 6 ergibt sich 26 = 64, und schon man hat den Wert x gefunden. Dies ist durch den stetigen Verlauf der Funktion B = 2x möglich, denn es gilt immer, dass bei einem x > y auch 2x > 2y ist. Die maximale Zahl der Schritte dieses Algorithmus lässt sich genau festlegen, denn für eine n Bit lange Zahl benötigt man maximal n Schritte.
134
Asymmetrische Verschlüsselungsverfahren
Mit der modularen Reduktion würde die Funktion Folgendes ergeben: B = 26 mod 11 = 9. Man würde auch hier h = 4 wählen und rechnet 24 mod 11 = 5. 5 ist kleiner als 9, also wählt man x größer, z.B. gleich 8. 28 mod 11 = 3. Das Ergebnis ist jedoch, trotz größerem h, kleiner geworden – was nun? Hier versagt unser einfacher Algorithmus schon, denn man weiß an diesem Punkt nicht mehr, ob man das nächste h jetzt größer oder kleiner wählen soll. Wo liegt der fundamentale Unterschied beider Funktionen? Dies wird vielleicht am schnellsten klar, wenn man deren Graphen einmal vergleicht. In Abbildung 4.19 sehen Sie, dass der Verlauf der Funktion gx (mod n) sehr unstetig zwischen den Werten 0 und n-1 schwankt – ganz im Gegensatz zur stetig ansteigenden Funktion gx. y = 2X 256 128 64 32 16 8 4 2
1
X
y = 2X (mod 11) 10 8
6 4 2 1
2
3
4
5
Abbildung 4.19: Die Graphen der Funktionen
6
y=2x
7
und y=
8
2x
X
(mod 11) im Vergleich
135
4 Sicherheitstechnologie
Dies ist nur ein einfaches Beispiel, und auch das Beispiel mit der modularen Reduktion wäre noch kein Problem. In der Praxis verwendet man jedoch Zahlen ganz anderer Größenordnung. Das im IKE-Protokoll (siehe Kapitel 8) eingesetzte Diffie-Hellman-Verfahren fordert für n eine streng getestete Primzahl von mindestens 768 Bit Länge und empfiehlt für x eine Zahl mit mindestens 160 Dezimalstellen mit x < n. Die Eulersche Totientenfunktion Das Resultat der Eulerschen Totientenfunktion ϕ(n) ist die Anzahl von positiven ganzen Zahlen kleiner n, die relativ prim zu n sind. Falls die Zahl n eine Primzahl ist, sind alle Zahlen kleiner n relativ prim, also ist in diesem Fall ϕ(n) = n – 1. Falls die Zahl keine Primzahl, jedoch das Produkt zweier Primzahlen p und q ist, dann gilt ϕ(n) = ϕ(p) * ϕ(q) = (p – 1)(q – 1). Der Satz von Euler, der auf dem Satz von Fermat beruht, besagt, dass für alle x, die relativ prim zu n sind, gilt: xϕ(n) = 1 mod n. Inverse Elemente und Fermats Theorem Multiplikativ inverse Elemente sind in normalen Zahlensystemen, wie den rationalen Zahlen, leicht zu finden. Das inverse Element zu a ist die Zahl x, die mit a multipliziert 1 ergibt, also a * x = 1 oder x = 1/a oder x = a-1. Es existiert zu jedem Element ein inverses Element. Bezüglich der modularen Arithmetik sieht dies etwas anders aus, es kann sogar so sein, dass zu bestimmten Zahlen überhaupt kein inverses Element existiert. Fermats Theorem besagt, dass für alle Primzahlen p und alle Zahlen a < p gilt: ap mod p = a oder ap-1 mod p = 1. Wenn wir nun das inverse Element x suchen mit ax mod p = 1, dann kann man, wenn p eine Primzahl ist und a < p ist, Fermats Theorem benutzen. Denn es gilt: ap-1 mod p = 1 und ax mod p = 1 zur Bestimmung des inversen Elements. Diese beiden Gleichungen kann man kombinieren zu: ax mod p = ap-1 mod p Und x = ap-2 mod p
4.9
Das Diffie-Hellman-Verfahren
Das Diffie-Hellman-Verfahren ist der Urvater der Public-Key-Kryptographie. Es kann nicht zum Ver- und Entschlüsseln von Daten benutzt werden, sondern nur zur Erzeugung von symmetrischen Schlüsseln. Es basiert auf dem Problem, dass eine Exponentiation mit wenig Aufwand durchführbar ist, die Um-
136
Das Diffie-Hellman-Verfahren
kehrung davon, das Auffinden des Logarithmus, jedoch sehr viel länger dauert. Ein schwieriges mathematisches Problem wird daraus, wenn es sich dabei auch noch um den diskreten Logarithmus handelt. Die Funktion z = gx mod n ist schnell zu berechnen, die Rückberechnung von x aus z ist jedoch sehr langwierig. Wieso ist x aus gx mod n sehr viel schwerer zu bestimmen als aus gx? Den gesuchten Wert von x bestimmt man für die Funktion gx mit Hilfe einer schrittweisen Approximation aus dem Wert z, indem man eine Hilfszahl p mit einem Startwert annimmt, gp berechnet und mit z vergleicht. Ist z größer, probiert man ein größeres, im anderen Fall ein kleineres p aus und nähert sich auf diese Weise dem gesuchten Wert. Dieser ist gefunden, wenn gp = z ist, und man benötigt maximal so viele Schritte, wie die Zahl x an Bit-Stellen aufweist. Im Fall der Funktion gx mod n ist die Sache so nicht zu machen, denn aufgrund der sehr unsteten Funktion kann man nicht sagen, ob man, falls gp mod n größer als z ist, p vergrößern oder verkleinern muss – beides ist gleich wahrscheinlich. Diese Schwierigkeit macht man sich beim Diffie-Hellman-Verfahren zunutze, denn selbst bei bekanntem z, n und g, ist x nicht in sinnvoller Zeit errechenbar. Einen Schlüsseltausch kann man in folgender Weise realisieren: Die Gegenstellen A und B möchten sich auf einen symmetrischen Schlüssel einigen. Jeder erzeugt für sich zu diesem Zweck eine sehr große Zufallszahl und hält sie geheim. A benutzt zwei Hilfszahlen, die Zahl g und die Zahl n, eine sehr große Primzahl. In der Praxis, zum Beispiel im IKE-Protokoll sind g und n im Standard festgelegt, somit allgemein bekannt und brauchen nicht mehr explizit übertragen zu werden. 왘 A berechnet a = gx mod n und schickt a (sowie gegebenenfalls g und n) zu B. 왘 B berechnet b = gy mod n und schickt b zu A. 왘 A berechnet k = bx = (gy mod n)x = gyx mod n. 왘 B berechnet k’ = ay = (gx mod n)y = gxy mod n. 왘 Da gyx mod n = gxy mod n, ist auch k = k’, und beide Seiten haben somit
einen identischen Schlüssel. Jemand, der die Übertragung von a, b, g und n abgehört hat, kann trotzdem ohne die Kenntnis wenigstens eines der beiden geheimen Werte x und y den Schlüssel nicht berechnen. Um das Diffie-Hellman-Verfahren sicher zu machen, müssen diese Zahlen gewissen Bedingungen genügen. Die Zahl n muss eine sehr große, zuverlässig getestete Primzahl sein. Üblich sind Längen von 768 oder 1024 Bit; manchmal verwendet man auch noch größere Zahlen. Für g nimmt man meist den Wert 2. Die geheimen Werte x und y sollen auch sehr groß sein, müssen aber stets kleiner als n sein. Sie sollten durch Zufallsgenera-
137
4 Sicherheitstechnologie
toren oder sehr gute Pseudo-Zufallsgeneratoren erzeugt werden und nach der Berechnung der symmetrischen Schlüssel vernichtet werden. Die Qualität und Vertraulichkeit von x und y, den privaten Diffie-Hellman-Werten, ist kritisch für den gesamten Schlüsseltausch. In praktischen Implementierungen des Diffie-Hellman-Verfahrens, zum Beispiel dem IKE-Protokoll, sind die Werte n und g in einem Standard festgelegt und veröffentlicht. Sie müssen aus diesem Grund nicht mehr explizit beim Schlüsseltausch übertragen oder gar von einer Seite vorher noch berechnet werden.
4.10 Das RSA-Verfahren Etwa ein Jahr, nachdem Whitfield Diffie und Martin Hellman durch ihre Arbeit frischen Wind, um nicht zu sagen Sturm, in die Kryptologie-Szene gebracht hatten, gingen drei Forscher an der Ostküste der USA mit einer weiteren bahnbrechenden Arbeit an die Öffentlichkeit. Die Professoren Ronald Rivest, Adi Shamir und Leonard Adleman vom Massachusetts Institute of Technology stellten das nach ihnen benannte RSA-Verfahren vor. Der wesentliche Unterschied zum Diffie-Hellman-Verfahren ist der, dass man mit RSA Daten ver- und entschlüsseln konnte. Denn die drei Wissenschaftler hatten das gefunden, was Whitfield Diffie und Martin Hellman bereits ein Jahr zuvor postuliert hatten: eine Einwegfunktion zur Verschlüsselung und die dazugehörige Falltür-Funktion zur Entschlüsselung. Die Funktion von RSA beruht auf einem anderen mathematischen Problem als das Diffie-Hellman-Verfahren, nämlich auf der Schwierigkeit, eine große Zahl in ihre Primfaktoren zu zerlegen. Denn es ist einfach und schnell durchführbar, aus den beiden großen Primzahlen p und q die Zahl n = pq zu berechnen. Die Umkehrung, also nur vom Wert n ausgehend, die zwei Primzahlen zu finden, die miteinander multipliziert n ergeben, ist ein hartes mathematisches Problem. Wie funktioniert nun das RSA-Verfahren genau? Das Tupel {n,e} bildet den öffentlichen Schlüssel und das Tupel {n,d} den privaten Schlüssel, von dem offensichtlich d nur der tatsächlich geheime, private Teil ist, da n auch Teil des öffentlichen Schlüssels ist. Die Transformation des Klartexts M in den Chiffretext C erfolgt mit dem öffentlichen Schlüssel {n,e} durch: C = Me mod n. Die Entschlüsselung erfolgt mit dem privaten Schlüssel {n,d}: M = Cd mod n.
138
Das RSA-Verfahren
Man kann beide Funktionen auch als M = (Me)d mod n zusammenfassen. Das Schlüsselpaar {n,e} und {n,d} wird wie folgt berechnet: Die Zahl n ist das Produkt zweier großer, möglichst vergleichbar langer Primzahlen p und q: n = pq. Anschließend wählt man e derart, dass es relativ prim zu (p – 1)(q – 1) ist. Hier kann man sich ohne lange Berechnungen und Tests geeignete Zahlen aussuchen, indem man Primzahlen wählt, die ungleich p und q sind, was für kleine Primzahlen der Fall ist. Für besonders schnelle Berechnungen wählt man sehr kleine e, zum Beispiel 3, 17 oder 216 +1 (65537). Diese Primzahlen wurden mit Bedacht gewählt, denn sie sind hervorragend geeignet, um mit ihnen binäre Exponentiationen durchzuführen, da sie, aus binärer Schreibweise gesehen, nur aus zwei Einsen und sonst nur Nullen bestehen. Die binäre Schreibweise der Primzahl 65537 ist zum Beispiel 1000000000000001. Der private Schlüsselteil d, der relativ prim zu n sein muss, wird über den erweiterten Euklidschen Algorithmus bestimmt: ed = 1 mod ((p-1)(q-1) Nach der Berechnung von d müssen p und q zuverlässig vernichtet werden. Wenn diese beiden Primzahlen nicht mehr bekannt sind, kann man auch d nicht mehr bestimmen. Man müsste aus der öffentlichen Zahl n ihre beiden Primfaktoren p und q zurückberechnen – was aber ein hartes mathematisches Problem darstellt. Die mathematischen Zusammenhänge sind beim RSA-Verfahren etwas komplexer als beim Diffie-Hellman-Algorithmus. Die folgende Beschreibung geht nicht sehr ins Detail, wer tiefer in die Materie einsteigen möchte, dem seien weiterführende Bücher zur Zahlentheorie und Kryptographie empfohlen. 1. Wir haben gesehen, dass folgender Zusammenhang gilt: C = Me mod n, M = Cd mod n und (Me)d = M mod n. Da (Me)d = Med, zerlegt man den Exponenten gewissermaßen in einen öffentlichen Teil e und einen privaten Teil d. 2. Die Zahl n wurde erzeugt, indem man zwei große Primzahlen p und q miteinander multipliziert hat. Da p und q prim sind, gilt für sie die Eulersche Totientenfunktion ϕ(n) = (p – 1)(q – 1). 3. Da e und d bezüglich mod ϕ(n) invers sein müssen, damit der obige Zusammenhang gültig ist, gilt ed = 1 mod ϕ(n), und man kann ein k bestimmen, mit ed = k ϕ(n) + 1. 4. Nach dem Theorem von Fermat gilt Mp-1 = 1 mod p. Da (p-1) einer der beiden Faktoren von ö(n) ist, kann man auch Mkϕ(n) = 1 mod p schreiben. Wenn wir beide Seiten der Gleichung mit M multiplizieren, erhalten wir Mkϕ(n) + 1 = M mod p.
139
4 Sicherheitstechnologie
5. Das gleiche kann man auch für die zweite Primzahl q durchführen und erhält analog dazu Mkϕ(n) + 1 = M mod q. 6. Nach (1) gilt (Me)d = Med = M mod n. Nach (3) gilt weiterhin ed = k ϕ(n) + 1. Somit gilt Med = Mk ϕ(n) + 1 = M mod n. Nach (4) und (5) gelten Mkϕ(n) + 1 = M mod p und Mkϕ(n) + 1 = M mod q. Also gilt auch M mod p = M mod q = Mk ϕ(n) + 1 = M mod n. Da wir gesehen haben, dass ed = k ϕ(n) + 1 ist, ist auch Med = (Me)d = M mod n. Bei sachkundiger Implementierung sind noch keine praktikablen Angriffe gegen RSA bekannt geworden, die einfacher sind als eine Faktorisierung von n. Die ganzen bisher bekannten Angriffe waren gegen (manchmal nicht optimale) Implementierungen von RSA gerichtet und nicht gegen den RSA-Algorithmus selbst. Falls man alle Richtlinien beachtet und entsprechende ProgrammierToolkits, zum Beispiel das von RSA Data Security, einsetzt, kann nach heutigen Erkenntnissen – beim Einsatz eines hinreichend großen n – nichts schief gehen.
4.10.1
Zufallszahlen
Das Thema Zufallszahlen ist Gegenstand einer Reihe von Büchern und auch von RFCs der Internet Engineering Task Force (IETF). Gemeinhin ist es nicht schwer, eine zufällige Zahl zu erzeugen, man kann zum Beispiel würfeln oder Roulette spielen. Es ist aber weitaus schwieriger, auf einem Computer eine echte oder dem sehr nahe kommende Zufallszahl zu erzeugen. Das liegt daran, dass ein Computer aufgrund seiner Programmierung nur vorherbestimmte Dinge tut, auch wenn einem das angesichts des Verhaltens moderner PCBetriebssysteme manchmal recht unglaublich erscheint. Aber es ist eine Tatsache, dass Pseudo-Zufallszahlen – so nennt man solche Größen, die durch Computerprogramme erzeugt wurden – sehr schwach sind und oft mit einem überschaubaren Aufwand rekonstruiert werden können. Solche Programmfunktionen – fast jede Programmiersprache oder Programmierumgebung hat eine RND-Funktion (Random Function) – basieren auf einem sich wiederholenden Muster, das auf einem jedes Mal anderen Startwert basiert. Kennt man diesen Startwert oder kann man ihn ungefähr abschätzen, so kann man auch die Zufallszahl(en) mit einigem Aufwand rekonstruieren. Aber auch in einem Computer gibt es Dinge, die nicht so einfach rekonstruierbar sind und eine starke Zufallskomponente haben. Die mittlere Zugriffszeit von Festplattenlaufwerken, der Inhalt des Arbeitsspeichers und vieles mehr kann schon eine gute Grundlage bilden. Nimmt man mehrere solche Werte, fügt sie zusammen und benutzt sie als Eingangsvariablen für eine Hashfunktion, so ist das Ergebnis schon eine sehr gute Pseudo-Zufallszahl. Da man in der Regel nicht alle paar Millisekunden neue Zufallszahlen benötigt, ist der Aufwand einer solchen Methode durchaus vertretbar. 140
Hashfunktionen
Am sichersten sind solche Zufallsgeneratoren, die ihre Ausgabe durch Messung von wirklich zufälligen Naturphänomenen erzeugen, zum Beispiel anhand von Halbleiterrauschen oder der kosmischen Strahlung. Dafür benötigt man natürlich spezielle Hardware, die solche Ereignisse in digitale Werte umwandelt. Diese ist in Standardrechnern wie PCs, Workstations usw. bisher werksseitig nicht eingebaut und kann nur in Form eines Zusatzmoduls eingesetzt werden. Jedoch ist es gut möglich, dass in wenigen Jahren ein HardwareZufallsgenerator-Chip in jedem Chipsatz von PC-Motherboards enthalten ist, zusammen mit RSA-, Diffie-Hellman- und AES-Chips.
4.11 Hashfunktionen Hashfunktionen sind keine Funktionen, die sich zum Ver- oder Entschlüsseln eignen. Sie werden manchmal auch als Einweg-Kompressionsfunktionen bezeichnet, weil sie aus einem großen, beliebig langen Eingangswert einen kurzen Ausgangswert fester Größe berechnen. Man kann solche Werte benutzen, um Datenbankindizes oder Prüfsummen zu erzeugen. Hashfunktionen, vor allem solche, die in der Sicherheitstechnologie Verwendung finden, sollen im Allgemeinen folgenden Eigenschaften genügen: 왘 Es soll einfach und somit auch schnell möglich sein, aus einem beliebig
langen Eingangswert M einen Hashwert h der endlichen Größe n zu erzeugen. 왘 Es soll unmöglich sein, aus diesem Hashwert h den zugehörigen Ein-
gangswert M zu berechnen. 왘 Es soll unmöglich sein, zu einer gegebenen Nachricht M eine Nachricht M’
zu berechnen, die den gleichen Hashwert erzeugt, den auch die Nachricht M erzeugt. Dies sind die grundsätzlichen Designkriterien. Die ersten beiden sind leicht zu implementieren, beim letzten jedoch drängt sich Ihnen bestimmt die Frage auf, ob dies überhaupt möglich ist. Hierüber streiten sich die Gelehrten, jedoch so viel sei gesagt: Eine Berechnung als solche ist nicht möglich, es gibt keine Formel, keinen Algorithmus, der aus einer beliebigen Nachricht M eine andere Nachricht M’ berechnet, so dass beide den gleichen Hashwert haben. Jedoch kann man eine Nachricht M’ finden, die den gleichen Hashwert der Nachricht M hat. Dies ist auch offensichtlich, denn die Nachricht M kann beliebig lang sein und kann unendlich viele Werte annehmen. Der Hashwert hat eine endliche Größe, in der Praxis findet man Werte zwischen 128 und 256 Bit. Somit ist die Menge der Nachrichten M’, die den gleichen Hashwert erzeugen auch unendlich groß – man muss nur eine finden. Ein solches Ereignis nennt man Kollision. Für den unten beschriebenen MD5-Algorithmus wurden schon Kollisionen gefunden, für andere Verfahren wie SHA oder RIPEMD noch nicht.
141
4 Sicherheitstechnologie
Somit ist noch ein anderes Designkriterium von Wichtigkeit, nämlich dass kleinste Differenzen in der Nachricht M sehr große Änderungen im Hashwert h erzeugen müssen. Meist fordert man, dass sich im Hashwert 50% aller Bits ändern, falls sich in der Nachricht M nur ein Bit verändert hat. Ändern sich jedoch sehr viele Bits in der Nachricht oder ändert sich auch ihre Länge, dann kann das Ausmaß der Änderung im Hashwert ruhig kleiner werden, da sich in diesem Fall die Natur und der Inhalt der Nachricht erheblich geändert haben. Diese Änderungen sind auf anderen Ebenen wie der Applikationsoder Darstellungsschicht im Fall von Datenübertragungen leicht erkennbar.
4.11.1
Algorithmen
Es gibt eine ganze Reihe von Hashalgorithmen, von denen hier zwei vorgestellt werden. Die Auswahl fiel deshalb auf die beiden im Folgenden beschriebenen Algorithmen, weil sie im IPSec-Standard als obligatorische Verfahren festgelegt wurden. Message Digest 5 (MD5) Dieses Verfahren kennen die meisten, zumindest vom Namen her. Es ist nicht nur in IPSec zu finden, sondern auch in allen möglichen anderen Protokollen wie CHAP, OSPF, L2TP, und es gibt sogar PC-Versionen davon, um Dateien auf Veränderungen zu überprüfen. MD5 wurde vom Kryptologie-Guru Ron Rivest entwickelt und ist im RFC1321 inklusive seines C-Quellcodes beschrieben. Der Aufbau von MD5 soll hier nicht zu sehr vertieft werden. Das Verfahren erzeugt aus einem Eingangswert beliebiger Länge einen 128-Bit-Hashwert. Neben dem Eingangswert selbst geht auch die Länge des Wertes in die Berechnung des Hashwerts mit ein. In Abbildung 4.20 sehen Sie das Ergebnis der MD5-Funktion, die auf die beiden Texte angewendet wurde, die sich nur um einen Buchstaben unterscheiden. Die beiden Hashwerte h und h’ sind sehr unterschiedlich, während man den Unterschied der beiden Texte beim ersten Hinsehen vielleicht gar nicht bemerkt.
WISSEN IST MACHT
MD 5
WISSEN IST NACHT
MD 5
3eb9c0237f40bbb5f9b6e9bd9d2 c53d4323a0d963648fb2e6ec6e5
Abbildung 4.20: Die MD5-Funktion erkennt kleinste Abweichungen in den beiden Nachrichten.
142
Hashfunktionen
Secure Hash Algorithm (SHA) Der Secure Hash Algorithm (SHA) ist ein neueres Verfahren, das einen größeren Hashwert als MD5 erzeugt. Es wird sehr oft als besser als MD5 bezeichnet. Dies liegt vor allem an seinem internen Aufbau, seiner größeren Anzahl an Verarbeitungsrunden und dem höheren Lawineneffekt, der durch verbesserte Rückkopplungsfunktionen erreicht wurde. Auch sind bisher keine Kollisionen bekannt geworden. Andererseits misstrauen viele Anwender dem Algorithmus, da seine Entwicklung maßgeblich von NSA beeinflusst wurde und seine Entwurfskriterien nicht offen gelegt wurden. SHA ist im FIPS-PUB 1801 (Secure Hash Standard) beschrieben. Er erzeugt einen 160 Bit langen Hashwert aus einem beliebig langen Eingangswert.
4.11.2
Keyed Hashing
Hashverfahren bieten sich an, um die Integrität von Nachrichten zu schützen. Wenn der Sender den Hashwert einer Nachricht berechnet und der Empfänger dies mit der von ihm erhaltenen Nachricht tut, dann kann er beide Hashwerte miteinander vergleichen, um zu prüfen, ob die Nachricht während des Transports verändert wurde. Aber wie kommt der Empfänger zum Hashwert des Senders? Eine elegante Art wäre es, den Hashwert einfach mit der Nachricht mitzuschicken. In diesem Fall wäre aber kein Schutz mehr gegeben. Denn ein Angreifer könnte sowohl die Nachricht ändern als auch den Hashwert neu berechnen. Dies kann man verhindern, indem man so genannte Keyed-HashFunktionen verwendet. Solche Funktionen bilden ihren Hashwert aus der Nachricht M und einem Schlüssel K. Dieser Schlüssel ist sowohl dem Sender als auch dem Empfänger bekannt. Jetzt kann man den Hashwert mit der Nachricht zusammen verschicken, denn ein Angreifer kann zwar immer noch die Nachricht verändern, aber ohne den passenden Schlüssel kann er den Hashwert nicht mehr neu berechnen, und der Empfänger würde sofort anhand der unterschiedlichen Hashwerte die Änderung bemerken
4.11.3
Hash-based Message Authentication Code (HMAC)
Nachdem nun die Hashfunktionen selbst durch symmetrische Schlüssel sicher gegen Änderungen bzw. Neuberechnungen geworden sind, fehlt nur noch eine Verbesserung, um sie resistenter gegen Kollisionen zu machen. Zu diesem Zweck wurde das HMAC-Verfahren entwickelt. Es ist kein Hashalgorithmus, sondern es kombiniert existierende Verfahren wie MD5 oder SHA mit symmetrischen Schlüsseln und einem speziellen Padding, um auf diese Weise ein starkes Verfahren zur Authentifizierung und Integritätsprüfung zu erhalten. In Abbildung 4.21 ist das Verfahren in Verbindung mit dem MD5Algorithmus zu sehen. Die HMAC-Verfahren gelten in der Fachwelt als sicher vor Kollisionen, auch wenn das zugrunde liegende Hashverfahren dies nicht ist. Auf diese Weise kann man auch einen Veteranen wie MD5, für den schon
143
4 Sicherheitstechnologie
Kollisionen gefunden wurden, weiterhin verwenden, und seinen Geschwindigkeitsvorteil gegenüber anderen Algorithmen ausnutzen.. Schlüssel
Nachricht Inner-Pad
MD 5
Outer-Pad MD5-Hash (128 Bit)
MD 5 MD5-Hash (128 Bit)
HMAC-MD5
Abbildung 4.21: HMAC-MD5 eliminiert die Kollisionsgefahr von MD5.
144
5
Authentifizierung
Die Authentifizierung als solche muss man im Hinblick auf ihren Einsatz in virtuellen privaten Netzen in zwei verschiedene Klassen unterteilen: 왘 Die Authentifizierung einer natürlichen Person. Hierbei wird versucht, die
Identität einer nicht persönlich anwesenden Person durch verschiedene Methoden festzustellen. Falls beispielsweise ein Anwender über ein Remote-Access-VPN Zugriff auf sein Unternehmensnetzwerk wünscht, muss er einem Zugangs-Kontrollsystem nachweisen, dass er auch tatsächlich der ist, der er (durch die Eingabe seiner User-ID in eine Anmeldemaske) zu sein vorgibt. 왘 Die Authentifizierung von Übertragungseinheiten eines Netzwerkprotokolls, um
bestimmte Angriffe wie Spoofing oder Man-in-the-Middle abzuwehren. Hier soll der Absender (ein VPN-Gateway oder ein Router) eines Pakets zweifelsfrei identifiziert werden. Dieser Prozess ist meist zweistufig: Die erste Stufe ist der Verbindungsaufbau, während dessen sich Gegenstellen gegenseitig identifizieren, und in der zweiten Stufe, der Datenübertragungsphase, werden die Pakete daraufhin überprüft, ob sie auch wirklich von der Gegenstelle kommen, zu der die Verbindung aufgebaut wurde. Diese beiden Formen der Authentifizierung darf man nicht miteinander verwechseln, da ihr jeweiliges Ergebnis völlig unterschiedliche Aussagen macht. Verbindet man zum Beispiel zwei Netzwerke über IPSec-Security-Gateways miteinander, so authentifizieren sich zwar die Systeme gegenseitig und ebenso wird jedes übertragene Paket überprüft – aber über die Benutzer in diesen Netzen gibt das Ganze keinerlei Aufschluss. Es kann jedoch in bestimmten Fällen vorkommen, dass man beide Verfahren sinnvoll miteinander kombinieren kann. Ein Beispiel ist das IKE-Protokoll, das innerhalb der IPSec-Protokollfamilie dazu benutzt wird, eine Verbindung aufzubauen und die beteiligten Gegenstellen zu authentifizieren. Falls eine dieser Gegenstellen ein Einzelplatzsystem ist, kann man die Authentifizierung des Benutzers mit der Authentifizierung des betreffenden Systems gleichsetzen und – durch eine Kombination der notwendigen Verfahren – sowohl den Benutzer als auch seinen Rechner authentifizieren.
145
5 Authentifizierung
5.1
Möglichkeiten der Authentifizierung
Es gibt eine ganze Reihe verschiedener Verfahren und Technologien, um Personen oder Systeme zu authentifizieren. Diese Verfahren haben eine unterschiedliche Stärke hinsichtlich ihrer Beweiskraft. Praktisch alle Verfahren sind mit einem geeigneten Aufwand zu überlisten; die Authentifizierung macht also in Wirklichkeit diesen Aufwand so hoch, dass er einem potenziellen Angeifer nicht mehr vertretbar erscheint. Selbst biometrische Verfahren oder eine persönliche Anwesenheit, Verfahren, die man oft als »absolut sicher« bezeichnet, sind in Wirklichkeit nicht hundertprozentig sicher: Denken Sie nur an eineiige Zwillinge oder die Möglichkeiten plastischer Chirurgie. Die unterschiedlichen Authentifizierungsverfahren beurteilt und klassifiziert man nach ihrer Beweiskraft und unterteilt sie in so genannte schwache oder starke Verfahren.
5.1.1
Starke und schwache Authentifizierung
Eine starke Authentifizierung erbringt den tatsächlichen Nachweis der Identität durch Überprüfung der persönlichen Anwesenheit. Eine schwache Authentifizierung beweist, dass die betreffende Person etwas weiß oder etwas hat, das normalerweise nur die tatsächlich zugangsberechtigte Person kennt oder besitzt. Insofern haben die verschiedenen Authentifizierungsverfahren eine unterschiedliche Stärke.
5.1.2
Wissensbasierende Authentifizierung
Im einfachsten Fall, der wissensbasierenden Authentifizierung, kennen der Benutzer und das Zugangskontrollsystem gemeinsam ein Geheimnis – das Passwort oder Kennwort. Das heißt, ein Benutzer meldet sich beispielsweise bei einem Remote-Access-Konzentrator oder einem VPN-Konzentrator unter Angabe seiner Benutzer-ID und seines Passworts an, woraufhin dieser die Richtigkeit der Angaben durch Vergleich mit seinen gespeicherten Daten überprüft und daraufhin eine Verbindung entweder aufbaut oder ablehnt. Da in der Vergangenheit keine Alternativen zur Verfügung standen, ist das Passwort-Verfahren die am weitesten verbreitete, aber auch die am wenigsten sichere Methode der Benutzer-Authentifizierung. Die Schwachstellen sind: schlecht gewählte Passwörter (z.B. die Verwendung von Eigennamen oder zu kurzen Kennwörtern), das Aufschreiben von Kennwörtern, die Weitergabe an Dritte oder zu viele verschiedene Kennwörter für ein und denselben Benutzer, wenn er Zugang zu mehreren Ressourcen benötigt. Nur eine ständige Benutzer-Erziehung zum richtigen Passwort-Verhalten kann diese Schwächen mildern, sie kann diese aber niemals vollständig eliminieren. Bei lokalen Zugriffen auf Netzwerke oder Systeme kann das Passwort-Verfah-
146
Möglichkeiten der Authentifizierung
ren durch zusätzliche organisatorische oder technische Maßnahmen, wie Zugangskontrollsysteme zu Gebäuden oder Räumen bzw. durch die Einschränkung der Netzanmeldung auf bestimmte Stationen, unterstützt werden.
5.1.3
Besitzbasierende Authentifizierung
Man hat die Schwächen der wissensbasierten Authentifizierung schon recht früh erkannt und nach Alternativen gesucht. Die besitzbasierende Authentifizierung ist eine davon. Bei diesem Verfahren besitzt der zugriffsberechtigte Anwender etwas, das ihn am Zugangskontrollsystem authentifiziert. Dies kann eine Chipkarte oder auch eine so genannte Token-Karte sein, die dem Benutzer eindeutig zugeordnet wurde und einmalig ist. Der Benutzer erhält Zugang oder keinen Zugang, indem das Kontrollsystem die auf der Karte gespeicherten Informationen, die dem Benutzer eindeutig zugewiesen sind, liest und mit den eigenen Daten vergleicht. Dieses Verfahren wird als sicherer als das Passwort-Verfahren angesehen, weil solche Karten nur – wenn überhaupt – mit einem gewissen Aufwand zu duplizieren sind. Probleme entstehen allerdings bei Verlust oder Diebstahl. Also ist auch dieses Verfahren noch weit davon entfernt, eine zuverlässige Authentifizierung zu gewährleisten.
5.1.4
Kombinationsverfahren
Den nächsten Grad an Sicherheit erreicht man durch die Kombination der ersten beiden Varianten, wie Sie sie in Abbildung 5.1 sehen. Das heißt, dass der Anwender sowohl einen Gegenstand, z.B. eine Chipkarte, besitzt als auch ein Passwort oder eine PIN (Persönliche Identifikationsnummer) kennt und dass er sich mit beiden gleichzeitig ausweisen muss. Nur die Karte bzw. nur das Passwort oder die PIN allein reicht nicht aus. Ein Beispiel hierfür, das wir alle kennen, sind die Geldautomatenkarten. Sein Geld aus einem Geldautomaten bekommt man nur durch den Nachweis des Besitzes der Karte und die Kenntnis der damit verbundenen geheimen PIN. Nur mit der PIN oder der Karte allein geht man leer aus. PIN (Wissen) Wissensbasierende Information (PIN, Passwort, ...)
Zugangskontrollsystem
Besitzbasierende Information (Token, Chipkarte, ...) Überprüfung der Besitzund Wissensinformationen
Chipkarte (Besitz)
Abbildung 5.1: Die Kombination von wissens- und besitzbasierender Authentifizierung
147
5 Authentifizierung
5.1.5
Biometrik
Die stärkste Art des Nachweises der persönlichen Identität eines Benutzers kann entweder durch die Überprüfung der persönlichen Anwesenheit, z.B. durch eine Live-Bildübertragung bei der Netzanmeldung, oder durch biometrische Verfahren wie Fingerabdruck-Leser, DNS-Analysator oder Augennetzhaut-Scanner erbracht werden. Solche Authentifizierungsverfahren sind sehr stark, weil sie nur mit erheblicher krimineller Energie außer Kraft gesetzt werden können. Sie sind heute allerdings noch nicht in großer Stückzahl im Einsatz, weil sie entweder noch nicht serienreif sind oder eine breite Anwendung, z.B. von Bildübertragungssystemen an jedem Arbeitsplatz, noch zu teuer ist. Aufgrund der großen Nachfrage nach sehr sicheren Authentifizierungsverfahren und der sich abzeichnenden Erfolge, z.B. bei der Entwicklung von kostengünstigen Fingerabdruck-Lesern, dürfte diesen Verfahren aber die Zukunft gehören. Allerdings sind einige dieser Verfahren allein auch noch sehr schwach. Es stellt beispielsweise kein großes Problem dar, sich von einer Person Fingerabdrücke zu beschaffen – man hinterlässt ja genug. Auch hier ist die Kombination von biometrischen Verfahren mit anderen erforderlich.
5.1.6
Verfahren mit Einmal-Token
Eine besonders sichere Variante stellen Token-Karten dar, die einen so genannten Einmal-Code (One-Time-Token) erzeugen, wie zum Beispiel das SecurIDVerfahren der Firma RSA Security. Der Benutzer erhält eine Token-Karte mit einer ihm eindeutig zugeordneten Seriennummer, eine User-ID und eine PIN. Bei der Netzanmeldung gibt er seine User-ID ein und liest die von der TokenKarte erzeugte Ziffernfolge – das Token – ab. Dieses gibt er, zusammen mit seiner PIN, in die Anmeldemaske ein. Diese Ziffernfolge ist nur für eine bestimmte Zeitdauer, in der Regel eine Minute, gültig und kann nur ein einziges Mal zur Anmeldung verwendet werden. Man kann sich also in diesem Fall nur einmal pro Minute authentifizieren. Da mehrere Anmeldungen mit dem gleichen Token nicht möglich sind, stellt es auch kein Sicherheitsproblem dar, wenn ein Token nach der Authentifizierung bekannt würde. Zur Authentifizierung werden die User-ID, das Token und die PIN zum Zugangskontrollsystem geschickt. Dieses berechnet aufgrund der aktuellen Zeit, der User-ID und der in seiner Datenbank gespeicherten PIN ebenfalls ein Token. Stimmen beide Token überein, ist der Benutzer authentisch. Dieses Verfahren ist deshalb so stark, weil bei jeder Anmeldung ein neues Token erzeugt wird und dieses Token jeweils nur eine begrenzte zeitliche Gültigkeit besitzt. Selbst wenn jemand bei der Übertragung zur Gegenstelle oder beim Eintippen das Token und die PIN mitliest und die User-ID des Benutzers
148
Möglichkeiten der Authentifizierung
kennt, können die Informationen zu einer erneuten Anmeldung nicht mehr benutzt werden. Ein Angreifer kennt dann zwar alle drei Faktoren, die zur Authentifizierung benötigt werden, aber einer dieser Faktoren, das Token, ist nur ein einziges Mal gültig und nicht vorherbestimmbar. Benutzer
Zugangskontrollsystem
Token-Karte (Besitz) Serien-Nr.
Serien-Nr.
Hash-Algorithmus
Hash-Algorithmus Benutzerdatenbank
Token
Token’
PIN’
User-ID PIN Token
PIN (Wissen)
Vergleich 1 User-ID PIN Token
User-ID (Identifikation)
Vergleich 2 Abbildung 5.2: Eine Authentifizierung mit einer Token-Karte
In Abbildung 5.2 sehen Sie die Funktion des Token-Verfahrens im Detail. Der Benutzer besitzt eine Token-Karte und kennt seine geheime PIN. Auf der Token-Karte befindet sich eine 64 Bit große Seriennummer, die zur Zuordnung der Karte zum Benutzer und zur Sicherstellung der Eindeutigkeit der Karte benutzt wird. Das Authentifizierungssystem hat eine Liste der Benutzer, ihrer PINs und der Seriennummern der den Benutzern zugeordneten Karten in seiner Datenbank gespeichert. Die Token-Karten und der Authentifizierungsserver müssen zeitsynchron sein. Nehmen wir in diesem Beispiel einmal an, die Clientsoftware unterstützt das Token-Verfahren nicht und bietet als Anmeldemaske ein Feld für den Benutzernamen und das Passwort an. Dann sieht der Ablauf der Authentifizierung wie im folgenden Abschnitt beschrieben aus. Die Token-Karte erzeugt in minütlichem Abstand ein neues Token, das mit einer speziellen Hashfunktion aus der aktuellen Uhrzeit und der Seriennummer der Karte erzeugt wird. Der Benutzer liest das Token, eine mehrstellige Ziffernfolge, ab und trägt seine PIN, gefolgt vom Token in das Passwort-Feld der Anmeldemaske ein. Im Feld zur Eingabe des Benutzernamens gibt er
149
5 Authentifizierung
seine User-ID ein. Diese Informationen werden dann zum Authentifizierungssystem geschickt. Dieses fragt anhand der User-ID in seiner Datenbank die PIN und die Seriennummer der Token-Karte des Benutzers ab und berechnet aus seiner aktuellen Uhrzeit und der Seriennummer ebenfalls ein Token. Falls dieses Token und das vom Benutzer geschickte übereinstimmen, die PIN korrekt ist und das Token nicht vorher schon einmal benutzt wurde, wird der Benutzer vom System angemeldet.
5.2
Digitale Signaturen und digitale Zertifikate
Seit der Einführung der Public-Key-Kryptographie und der Veröffentlichung des RSA-Verfahrens kann man auch digitale Signaturen zur Authentifizierung einsetzen. Die Stärke dieser Authentifizierung hängt aber weniger von den eingesetzten Verfahren selbst ab als von der Art und Weise, wie die privaten und öffentlichen Schlüssel verwaltet werden und wie verbindlich die Zuordnung eines öffentlichen Schlüssels zu einer Person oder einem System ist.
5.2.1
Funktionsweise von digitalen Signaturen
Die Technologie, die hinter der digitalen Signatur steht, ist meist die Umkehrung der RSA-Verschlüsselung, indem man etwas mit dem privaten Schlüssel verschlüsselt und das Ergebnis nur mit dem korrespondierenden öffentlichen Schlüssel wieder lesbar machen kann. Dieses Verfahren ist offensichtlich nicht zum Schutz der Datenvertraulichkeit geeignet, da jedermann Zugang zum öffentlichen Schlüssel haben kann. Der Trick dieses Verfahrens liegt darin, dass man, wenn man etwas mit dem öffentlichen Schlüssel einer Person entschlüsseln kann, weiß, dass nur diese Person selbst die Verschlüsselung vorgenommen hat, da nur sie den notwendigen privaten Schlüssel besitzt. Außerdem sind aus den gleichen Gründen die entschlüsselten Daten auch integer. So weit die Theorie. Um dies aber in ein praktikables und in letzter Instanz auch rechtsverbindliches Verfahren umzusetzen, müssen einige Rahmenbedingungen geschaffen werden: 왘 Die Sicherheit des privaten Schlüssels 왘 Die Bindung einer Person an einen öffentlichen Schlüssel 왘 Verteilung und Management der Schlüssel 왘 Vertrauensbeziehungen
150
Digitale Signaturen und digitale Zertifikate
Die Sicherheit des privaten Schlüssels Die Sicherheit des privaten Schlüssels ist essenziell. Er darf sich nur im Besitz des Benutzers befinden. Es dürfen somit auch keine Sicherheitskopien davon existieren. Der Schlüssel muss offensichtlich vor dem Zugriff Dritter sicher sein. Dies kann man durch organisatorische und technische Maßnahmen erreichen. Ein Beispiel sind Chipkarten, auf denen der private Schlüssel verschlüsselt gespeichert ist. Der Schlüssel kann vom Benutzer nur dann in eine durch den Signatur-Algorithmus benutzbare Form transformiert werden, wenn er die Chipkarte besitzt und das entsprechende Passwort kennt. Die Bindung einer Person an einen öffentlichen Schlüssel Derjenige, der eine digitale Signatur verifizieren will, muss sicher sein können, dass er auch den öffentlichen Schlüssel dazu benutzt, der dem Signierenden gehört. Es muss also beispielsweise ein Verzeichnis von eindeutigen Benutzernamen mit dem zugehörigen öffentlichen Schlüssel existieren. Dieses Verzeichnis muss von einer Institution verwaltet werden, die für alle Beteiligten vertrauenswürdig ist. Verteilung und Management der Schlüssel Es muss ein zuverlässiges Verfahren existieren, das die Schlüssel an die Orte transportiert, an denen sie benötigt werden. Der private Schlüssel sollte möglichst überhaupt nicht transportiert werden müssen, sondern am besten an dem Ort (Chipkarte, Rechner), an dem er verwendet wird, erzeugt werden. Vertrauensbeziehungen Die Verwaltung und Verteilung der öffentlichen Schlüssel durch eine bestimmte Institution bedingt, dass ihr alle Beteiligten trauen. Es muss also gewissermaßen eine Art Vertrauensinfrastruktur existieren, in der Folgendes zutreffen muss: 1. Die Person B vertraut der Person A. 2. Die Person C vertraut der Person A. 3. Wenn die Person B der Person A traut, traut sie dadurch auch der Person C. 4. Wenn die Person C der Person A traut, dann traut sie dadurch auch der Person B. 5. Dies gilt insbesondere auch, wenn sich die Personen B und C vorher nicht kennen.
151
5 Authentifizierung
Absender
Empfänger
Dokument
MD5
Hash
Dokument
Zertifikat
Zertifikat
Absender
Absender
Signatur
Signatur
Privater Schlüssel des Absenders
Öffentlicher Schlüssel des Absenders
MD5
Hash’
Vergleich
RSA
Hash
Signatur
RSA Signatur
Abbildung 5.3: Eine digitale Signatur mit MD5 und RSA
Die Person A nimmt in unserem Beispiel eine besondere Stellung ein, da ihr alle trauen müssen, damit unser Beispiel funktioniert. Man nennt dies eine indirekte Vertrauensbeziehung, da sich hier B und C gegenseitig vertrauen, ohne sich kennen zu müssen. Unser Problem der Verwaltung und eindeutigen Zuordnung der öffentlichen Schlüssel wird nun dadurch gelöst, dass sich A des Problems annimmt. Er teilt allen Interessierten, die ihm trauen, mit, welche Person welchen öffentlichen Schlüssel besitzt. Auf diesem Modell basieren alle heutigen Infrastrukturen zur Verwaltung von öffentlichen Schlüsseln und digitalen Zertifikaten. In diesen Zertifikaten steht genau beschrieben, wem das Zertifikat gehört und wie sein öffentlicher Schlüssel ist. Neben dem weit verbreiteten RSA-Verfahren gibt es auch noch andere Signatur-Algorithmen und einen Digital Signature Standard (DSS), der auf dem Digital Signature Algorithm (DSA) basiert. Da die verwendeten Public-KeyVerfahren sehr langsam sind, verschlüsselt man nicht die kompletten Daten, die man signieren will. Man benutzt, wie Sie in Abbildung 5.3 am Beispiel von RSA und MD5 sehen, statt dessen ein schnelles Hashverfahren und verschlüsselt nur dessen Ergebnis mit dem asymmetrischen Verschlüsselungsverfahren.
152
Digitale Signaturen und digitale Zertifikate
5.2.2
Digitale Zertifikate nach ITU-X.509-Standard
Wie sieht nun eigentlich ein digitales Zertifikat aus? Es soll ja die Identität einer Person oder auch eines Systems, das ein Zertifikat benutzen soll, an dessen öffentlichen Schlüssel gebunden werden. In einem Zertifikat muss also ein eindeutiger Name der betreffenden Instanz stehen, der Schlüssel selbst, Informationen über den verwendeten Signatur-Algorithmus und der Gültigkeitsbereich, sowohl zeitlich als auch hinsichtlich der Infrastruktur. Die Zertifikat-Struktur wurde von der ITU standardisiert und liegt mittlerweile in der dritten Version vor, die jedoch abwärtskompatibel ist. Ein System, das Zertifikate der Version 3 verarbeiten kann, kann auch (eine entsprechende Implementierung vorausgesetzt) Zertifikate der Version 1 verwenden, aber nicht umgekehrt. In Abbildung 5.4 sehen Sie das Format eines Zertifikats nach dem ITU X.509-Standard, den es mittlerweile in zwei, noch gleichzeitig gültigen Versionen gibt. Heute werden fast nur noch Zertifikate der Version 3 (X.509v3) eingesetzt. Die Felder haben folgende Bedeutung: Version of Certificate Die Versionsnummer des vorliegenden Zertifikats. Gültige Werte in diesem Feld sind 0 (Version 1) und 2 (Version 3). Certificate Serial Number Dieses Feld enthält die Seriennummer des Zertifikats. Die Seriennummer ist nur innerhalb des Gültigkeitsbereichs der ausstellenden Certificate Authority (CA, siehe unten) eindeutig. Signature Algorithm for Certificate Authority Beschreibt den Signatur-Algorithmus, mit dem die Certificate Authority das vorliegende Zertifikat signiert hat. Issuer (Certification Authority) X.500 Name Hier steht der Name der ausstellenden Certificate Authority im X.500-Format. Validity Period for Certificate In diesem Feld wird die Gültigkeitsdauer des Zertifikats in Form eines Anfangs- und Ablaufdatums festgelegt. Subject X.500 Name Hier steht der so genannte Distinguished Name des Besitzers des vorliegenden Zertifikats, zum Beispiel DN=Manfred Lipp, OU=Competence Center, O=Nortel Networks, C=DE.
153
5 Authentifizierung
Digitales Zertifikat nach X.509 Version of Certificate Certificate Serial Number Signature Algorithm for Certificate Authority Issuer (Certification Authority) X.500 Name
X.509v1
Subject Public Key Information
X.509v2
Subject X.500 Name
X.509v3
Validity Period for Certificate
Algorithm Identifier Public Key Value
Issuer Unique Identifier Subject Unique Identifier Extension Field (Variable)
Certification Authority’s Digital Signature
Abbildung 5.4: Ein Zertifikat nach ITU-X.509
Subject Public Key Information Informationen zum öffentlichen Schlüssel des Inhabers des vorliegenden Zertifikats. Hier werden der verwendete Public-Key-Algorithmus, die Länge des öffentlichen Schlüssels und der Schlüssel selbst festgelegt. Issuer Unique Identifier (nur Version 2 und 3) Dies ist eine optionale Zeichenkette, die sicherstellen soll, dass der Name der CA eindeutig ist. Subject Unique Identifier (nur Version 2 und 3) Dieser optionale String soll die Eindeutigkeit des Benutzernamens sicherstellen. Extension Field (nur Version 3) Dieses flexible Erweiterungsfeld (Extension Field), das nur in X.509 Version 3 benutzt wird, besitzt ein flexibles Format, um auch zukünftige Funktionalitäten abbilden zu können, ohne jedes Mal den Standard ändern zu müssen. In diesem Feld werden Schlüssel-, Policy- und Benutzer-Attribut-Informationen abgelegt.
154
Authentifizierungssysteme und -protokolle
Certificate Authority’s Digital Signature Digitale Signatur des vorliegenden Zertifikates mit dem privaten Schlüssel der Certificate Authority.
5.3
Authentifizierungssysteme und -protokolle
Die in den vorangegangenen Abschnitten beschriebenen Verfahren und Technologien werden in verschiedenen Protokollen und Authentifizierungssystemen eingesetzt.
5.3.1
PAP und CHAP
Die in den vorausgegangenen Abschnitten beschriebenen Authentifizierungsverfahren werden sowohl bei der Anmeldung eines Benutzers im lokalen Netz auf dem Firmengelände als auch von Remote-Nutzern, zum Beispiel in Außenstellen oder zu Hause, verwendet. Bei Remote-Anmeldungen spielt ein zusätzlicher Faktor – die Übertragung über das Weitverkehrsnetz – eine Rolle. Zur Authentifizierung über das Weitverkehrsnetz gibt es unterschiedliche Protokolle. Auf Point-to-Point-(PPP)-Verbindungen kommen zwei standardisierte Protokolle zum Einsatz, das Password Authentication Protocol (PAP) und das Challenge Handshake Authentication Protocol (CHAP). Beim PAP werden die vom Benutzer am Rechner eingegebene User-ID und das Passwort im Klartext zur Überprüfung an die Gegenstelle, z.B. einen Remote-Access-Konzentrator am Firmenhauptsitz, übertragen und von diesem mit den in seiner Datenbank gespeicherten Informationen verglichen. Die Echtheit des Benutzers wird bei Übereinstimmung bestätigt, oder der Zugriff wird verweigert. PAP wird von bestimmten anderen Authentifizierungsverfahren, z.B. SecurID und anderen Token-Verfahren und von der noch zu besprechenden Passthrough-Authentifizierung vorausgesetzt. Der Hauptnachteil dieses Verfahrens ist, dass bei einem Abhören der Leitung das Passwort im Klartext zur Verfügung steht. Wer PAP trotzdem verwendet und mehr Sicherheit will, muss zusätzlich andere Verfahren, z.B. eine Leitungsverschlüsselung, einsetzen. PAP in Verbindung mit einem Tokenverfahren stellt jedoch kein Sicherheitsproblem dar. CHAP ist eine Drei-Phasen-Handshake-Prozedur, in der das Kennwort nicht explizit übertragen wird, sondern als ein Eingabewert für einen Hash-Algorithmus dient. In Abbildung 5.5 sehen Sie den Ablauf einer Benutzeranmeldung mit CHAP. Die erste Phase wird eingeleitet, sobald der Benutzer eine
155
5 Authentifizierung
PPP-Verbindung zu einem WAN-Zugangssystem, beispielsweise einem Remote-Access-Konzentrator am Firmenhauptsitz aufbaut. Als Antwort schickt dieser seine CHAP-Challenge zurück, die aus einer zuvor erzeugten Zufallszahl X und seiner eigenen Kennung, beispielsweise seinem Gerätenamen, besteht. Danach wird über eine Hashfunktion, meist MD5, aus dem Passwort und der Zufallszahl X ein 128 Bit großer Hashwert berechnet. Dieser Hashwert wird zusammen mit der User-ID des Benutzers als CHAPResponse an den RAC auf der Gegenseite geschickt. Der RAC nimmt die User-ID und überprüft, ob diese mit dem zugehörigen Passwort in seiner Datenbank hinterlegt ist. Ist dies der Fall, ermittelt er aus dem hinterlegten Passwort und der Zufallszahl X ebenfalls einen Hashwert und vergleicht diesen mit dem vom Benutzer übertragenen. Stimmen beide überein, schickt der RAC eine so genannte CHAP-Success-Message, andernfalls eine CHAP-Failure-Message zurück. Bei einer CHAP-Success-Message wird eine Verbindung bis zum Ende aufgebaut, bei einer CHAP-Failure-Message wird die bestehende Verbindung sofort unterbrochen. Benutzer
Zugangskontrollsystem Zufallsgenerator
PasswortEingabe
RND
CHAP-Challenge
X
X Passwort
MD5 Benutzerdatenbank
User-ID Hash
CHAP-Response
MD5
User-ID Hash
Vergleich
User-ID (Identifikation)
CHAP-Accept/Reject
Abbildung 5.5: Das dreiphasige CHAP-Verfahren
156
Hash’
Authentifizierungssysteme und -protokolle
Weiterhin bietet das CHAP-Protokoll die Möglichkeit, die bestehende Verbindung zu überwachen, um mögliche Angriffe durch Spoofing abzuwehren. Zu diesem Zweck kann als CHAP-Konfigurationsoption ein Zeitintervall festgelegt werden, innerhalb dessen die Authentifizierung in unregelmäßigen Abständen wiederholt wird. Dadurch, dass das Passwort nicht im Klartext, sondern nur ein nicht zurückzuverfolgender Hashwert über die WAN-Leitung übertragen und die Verbindung konstant überwacht wird, ist CHAP sicherer als PAP. Aber CHAP hat auch Nachteile. Weil das Verfahren voraussetzt, dass sowohl an der Quell- als auch an der Zieladresse das Benutzerpasswort im Klartext vorliegt, kann es nicht zusammen eingesetzt werden mit: 왘 Authentifizierungsverfahren, die überhaupt keine für CHAP verwend-
bare Kennwörter benutzen, z.B. Token-Verfahren. 왘 Authentifizierungssystemen, die Betriebssystem-Accounts verwenden,
denn die Passwörter können von den Betriebssystemen nicht mehr in Klartext umgewandelt werden. Der letzte Punkt tut besonders dann weh, wenn man netzwerkweit nur noch eine User-ID und ein Kennwort verwenden will – beim so genannten SingleSign-On. Viele Remote-Access-Systeme bieten die Möglichkeit, auf die Authentifizierungsdienste von Netzwerkbetriebssystemen wie Novell, Unix oder NT zurückzugreifen, um ein bestehendes Benutzerkonto auch für den Fernzugriff auf das Netzwerk zu benutzen. Somit müsste sich der Benutzer nur ein einziges Passwort merken, und der administrative Aufwand zur Benutzerverwaltung wäre ebenfalls reduziert. Aber da praktisch kein Betriebssystem in der Lage ist, ein Benutzerpasswort im Klartext zu rekonstruieren, CHAP dies aber erfordert, bleibt für die betriebssystemgestützte Authentifizierung nur PAP übrig.
5.3.2
RADIUS
Für Anwender, die mit einer zentralen Datenbank zur Authentifizierung arbeiten und trotzdem CHAP einsetzen wollen, bietet der Remote Authentication Dial In User Service (RADIUS) eine Alternative. RADIUS ist ein im RFC2038 und RFC2039 festgelegtes Protokoll zur Authentifizierung von Remote-Nutzern. Es ist eine Client-Server-Architektur, die für Access-Geräte unterschiedlicher Hersteller ausgelegt ist, sofern diese Systeme einen RADIUS-Client implementiert haben. Die Authentifizierung erfolgt entweder über eine RADIUS-eigene Datenbank auf dem RADIUS-Server oder über die Pass-Through-Authentifizierung durch das Netzwerkbetriebssystem. Im ersten Fall sind die Benutzerdaten, also die User-IDs, Passwörter und Sitzungsattribute, in einer lokalen RADIUS-Datenbank abgelegt. Die Passwörter werden üblicherweise im Klartext gespeichert; es gibt aber auch RADIUS-Server, die Passwörter verschlüsseln und wieder entschlüsseln können. Beide Datenbanktypen unterstützen sowohl PAP als auch CHAP.
157
5 Authentifizierung
Dial-In-Client
RADIUSServer
RADIUSClient
ISDN PSTN
Dial-In-Client
RADIUS-Protokoll
Remote-Access-Konzentrator Interne Benutzerdatenbank
Abbildung 5.6: RADIUS ist eine Client-Server-Architektur.
Die Anmeldung erfolgt nach dem folgenden zweistufigen Konzept, das Sie in Abbildung 5.6 sehen: Der Benutzer baut in unserem Beispiel eine Verbindung zu einem Remote-Access-Konzentrator mit einer RADUIS-Client-Implementierung auf. Der RADIUS-Client fragt beim zentralen RADIUS-Server nach, ob sich der Benutzer anmelden darf. Der RADIUS-Server vergleicht dazu die User-ID und das Passwort und schickt im Erfolgsfall an den Remote-AccessKonzentrator ein Paket mit denjenigen Sitzungsattributen zurück, die dieser benötigt, um die Sitzung für den betreffenden Benutzer zu konfigurieren. Diese Sitzungsattribute können zum Beispiel die IP-Adresse, die dem Benutzer zugewiesen werden soll, bestimmte Paket-Filter, Idle-Timer usw. sein. Man kann somit RADIUS außer zum Authentifizieren und für das Accounting auch zur Autorisierung und zur Konfiguration der PPP-Verbindung verwenden. Das RADIUS-Protokoll legt zu diesem Zweck eine Reihe von Standardattributen und den zugehörigen Datentypen und -formaten fest und bietet auch die Möglichkeit, herstellerspezifische Attribute einzubinden. RADIUS hat sich im Remote-Access-Bereich und bei den Internet Service Providern seit Jahren schon als Standard durchgesetzt. Allerdings hat die Authentifizierung durch eine RADIUS-eigene Datenbank auch einige Nachteile, vor allem den, dass die Benutzer ihre Passwörter nicht selbst ändern können. Denn der RADIUS-Standard umfasst nur die AccessSysteme mit einem RADIUS-Client, den RADIUS-Server und das Kommunikationsprotokoll. Die eigentlichen Remote-Access-Clients werden nicht berücksichtigt, also gibt es auch kein Programm oder Verfahren, mit dem die Benutzer ihre Passwörter auf dem RADIUS-Server ändern können. Eine Änderung der Kennwörter ist aber in gewissen Zeitabständen unter Sicherheitsaspekten notwendig. Dadurch bleibt trotz des Vorteils der zentralen Speicherung und Pflege der Benutzerdaten immer noch ein gewisser Verwaltungs- und Kostenaufwand für den Administrator bestehen, denn er muss nicht nur bei der erstmaligen Generierung, sondern auch bei jeder Änderung jedem Benutzer das Passwort erneut auf eine sichere Art und Weise zuschicken.
158
Authentifizierungssysteme und -protokolle
Dial-In-Client
RADIUSServer
RADIUSClient
ISDN PSTN
RADIUS-Protokoll
Remote-Access-Konzentrator Dial-In-Client
Authentifizierungsprotokol l
Authentifizierungssystem Abbildung 5.7: RADIUS erlaubt auch eine Authentifizierung durch externe Systeme.
Anwender mit extrem ausgeprägtem Sicherheitsdenken wenden außerdem bei RADIUS-Servern, die intern verschlüsselt gespeicherte Passwörter wieder entschlüsseln können, ein, dass damit ein gewisses Sicherheitsloch entstehe. Denn ein Passwort, das von einem System zu entschlüsseln sei, könne theoretisch auch von einer Person entschlüsselt werden. Der letztgenannte Einwand kann nicht ausgeräumt werden. Anwender, die diese Meinung vertreten, müssen auf eine zentrale RADIUS-Benutzerverwaltung verzichten und statt dessen die verteilte Datenhaltung in den RemoteAccess-Systemen akzeptieren. Die andere Schwachstelle – dass Benutzer ihr Passwort nicht ändern können – ist durch Einsatz der Passthrough-Authentifizierung auszuschalten, allerdings ist dann CHAP nicht mehr einsetzbar. Bei der Passthrough-Authentifizierung sind die Benutzerkonten im Netzbetriebssystem angelegt. Sobald der Benutzer sein Passwort in seinem Betriebssystem ändert, ist es damit auch für seinen Fernzugriff geändert. Zur oben beschriebenen zweistufigen Anmeldung kommt bei der Passthrough-Authentifizierung eine weitere Stufe hinzu, wie Sie im Beispiel der NT-Authentifizierung in Abbildung 5.7 sehen. Der RADIUS-Server gibt die Authentifizierungsanfrage an das Netzbetriebssystem weiter, das die Benutzerdaten mit seinen Benutzerkonto vergleicht. Diese weitere Phase der Authentifizierung bringt etwas mehr Verzögerungszeit mit sich; dafür spart sie dem Administrator viel Zeit und damit Kosten bei der Passwortverwaltung. Denn in diesem Fall ist, sobald der Benutzer sein Passwort in der NT Domain verändert, damit auch gleichzeitig sein Remote-Passwort geändert. Es ergibt sich eine Vereinfachung im Passwortgebrauch, da sich der Benutzer mit der Eingabe seiner User-ID und seines Passworts sowohl am RemoteAccess-Konzentrator als auch am Netzwerkbetriebssystem anmeldet. Das
159
5 Authentifizierung
heißt, er nimmt mit einem Passwort zwei Sicherheitsbarrieren auf einmal. Allerdings kann dies von Fall zu Fall mit der Sicherheitsstrategie einiger Unternehmen in Konflikt kommen, da diese gerade beim Remote Access oft eine Zweistufigkeit fordert.
5.3.3
LDAP
Das Lightweight Directory Access Protocol (LADP) nimmt eine zunehmend wichtige Rolle als Basis für unternehmensweite Verzeichnisdienste ein. Unternehmen wie Microsoft, Novell, Sun/Netscape und viele andere benutzen diesen Standard bereits. LDAP ist kein Authentifizierungssystem im eigentlichen Sinn, es bietet diese nur als Option an, da der Benutzername und die Passwörter wichtige Attribute in einem Verzeichnisdienst (Directory Service) sind. Dienste wie LDAP zeichnen sich in guten Implementierungen unter anderem dadurch aus, dass die Lese-Zugriffe extrem schnell sind. Schreibende Zugriffe sind durch die Optimierungen gelegentlich eher langsam (das muss aber nicht sein), denn sie machen in einem produktiven Directory Service meist weniger als 1% der Datenbankzugriffe aus.
5.3.4
Chipkarten
Chipkarten werden vermutlich die Medien der Zukunft sein, wenn es um die Speicherung von digitalen Zertifikaten geht. Leider sind die Standardisierungsbemühungen noch nicht besonders erfolgreich verlaufen, so dass viele Hersteller immer noch ihre proprietäre Soft- und Hardware einsetzen. Eine einzige persönliche Chipkarte, mit der man Bargeld bekommt, sich ärztlich behandeln lässt, sich an einem Zugangskontrollsystem authentifiziert und Verträge elektronisch unterschreibt, ist leider noch Zukunftsmusik. Dies liegt neben fehlenden, weltweit akzeptierten Standards auch an einer Reihe rechtlicher und internationaler Rahmenbedingungen, an denen allerdings gerade fleißig gearbeitet wird. Bei den Chipkarten – nicht zu verwechseln mit einfachen Magnetkarten – unterscheidet man grundsätzlich zwischen Karten, die nur Daten speichern können, und Karten mit so genannter Eigenintelligenz. Zur Speicherung von Zertifikaten benutzt man die letztgenannte Gruppe, also Karten, die über einen Prozessor, Programm- und Arbeitsspeicher sowie eine Ein-/Ausgabeschnittstelle verfügen. In diesen Chipkarten werden in der Regel nicht nur die privaten Schlüssel der Besitzer gespeichert, sondern auch die Signatur erzeugt. Auf diese Weise »verlässt« der private Schlüssel niemals die Chipkarte, sie bekommt nur das zu signierende Dokument zugeführt und liefert die Signatur zurück. Dies bedeutet auch, dass die Signatur-Algorithmen auf der Karte ablaufen.
160
Authentifizierungssysteme und -protokolle
Kontaktflächen
1
8
2
7
3
6 4 5
Chipkarte
1 2 3 4 5 6 7 8
= = = = = = = =
Versorgungsspannung Reset Taktsignal Reserviert Masse (0 V) Programmierspannung Ein-/Ausgabeschnittstelle Reserviert
Interne Struktur
EEPROM
CPU
I/O-Port (Interface)
Ein/Ausgabe
ROM
Abbildung 5.8: Der Aufbau einer Standard-Chipkarte
Wie Sie in Abbildung 5.8 sehen, sind wenigstens die Funktionen der Pins der Kontaktfläche, mit der die Karte mit der Außenwelt kommuniziert, im ISOStandard 7816-2 festgelegt. In der Regel darf der private Schlüssel nicht aus der Chipkarte ausgelesen werden können. Die Verarbeitung der dann auf der Karte notwendigen kryptographischen Funktionen erfolgt in guten Chipkarten über einen zweiten Prozessor (Kryptoprozessor), der auf Algorithmen wie RSA oder DES hin optimiert ist. Der Zugriff auf die Karten ist durch eine PIN oder ein Passwort geschützt, so dass auch hier wieder eine Zwei-Faktor-Authentifizierung vorliegt. Es ist technisch sehr kompliziert, extrem aufwendig und in vielen Fällen bisher unmöglich, aus Chipkarten den privaten Schlüssel auszulesen. Jedoch gab es schon praktische Angriffe, bei denen beispielsweise die Werte der Speisespannung, die von außen an die Karte angelegt werden muss, gemessen werden, um Auskunft über Zustände von S-Boxen oder bestimmten Speicherblöcken zu erhalten. Gezielte Funktionsstörungen durch Manipulationen an der Betriebsspannung oder an dem von außen zugeführten Taktsignal sind ebenfalls Methoden, mit denen echte Angreifer und die Testlabors der Hersteller versuchen, solche Chipkarten zu »knacken«.
161
5 Authentifizierung
5.4
Public Key Infrastructure (PKI)
5.4.1
Vertrauensmodelle
Im Abschnitt über digitale Signaturen wurde bereits darauf hingewiesen, dass man für eine praktische Anwendung der Public-Key-Kryptographie zum Signieren von Daten oder zur Authentifizierung bestimmte Infrastrukturen und Vertrauensmodelle benötigt. Digitale Zertifikate, wie sie im X.509-Standard beschrieben sind, dienen dazu, die Identität einer Person, einer Organisation oder auch die eines Security-Gateways fest mit deren öffentlichem Schlüssel, dem Public Key, zu verbinden. Dies wird von einer so genannten Certificate Authority (CA) vorgenommen, einer Institution, der alle, in der von ihr verwalteten Public Key Infrastructure (PKI), Beteiligten vertrauen. Direkte Vertrauensbeziehungen Nehmen wir zuerst einmal den anderen, einfacheren Fall, in dem sich die Beteiligten alle bereits kennen und sich durch persönlich zugestellte öffentliche Schlüssel ihre PKI aufbauen. Dies nennt man eine unmittelbare Vertrauensbeziehung (Direct Trust). In diesem Fall können die öffentlichen Schlüssel direkt, zum Beispiel per Diskette oder über ein anderes sicheres Medium ausgetauscht werden. In jedem Fall muss die Vertrauensbeziehung aller Beteiligten untereinander aber schon vor dem Austausch der öffentlichen Schlüssel und der darauf basierenden elektronischen Transaktion bestehen. Dies funktioniert noch gut in einer kleinen geschlossenen Gruppe, aber in größeren, dezentralen Organisationen tauchen schon größere Probleme auf. In offenen Umgebungen jedoch funktioniert dies überhaupt nicht, da sich die Beteiligten vor der elektronischen Transaktion überhaupt nicht kennen bzw. in keiner Beziehung zueinander stehen. Indirekte Vertrauensbeziehungen Also muss auf eine andere Weise einer Person verbindlich ihr öffentlicher Schlüssel zugeordnet und dieser verteilt werden. Ein direkter, elektronischer Austausch ist jedoch nicht sicher, da hier Man-in-the-Middle-Angriffe möglich sind. Die Lösung ist eine zentrale Stelle, bei der die betroffenen Personen vorstellig werden oder auf eine andere, sichere Art ihre Identität nachweisen und dort ihren öffentlichen Schlüssel hinterlegen. Diese zentrale Organisation, die Certificate Authority, stellt der betreffenden Person oder auch Organisation anschließend ein so genanntes digitales Zertifikat aus, in dem unter anderem der eindeutige Name der Person oder Organisation und deren öffentlicher Schlüssel gespeichert ist. Dieses Zertifikat wird abschließend mit dem privaten Schlüssel der Certificate Authority signiert, ist somit von niemandem mehr änderbar und stammt eindeutig von der ausstellenden CA.
162
Public Key Infrastructure (PKI)
Die gewünschte gegenseitige Vertrauensstellung erreicht man dadurch, dass alle Beteiligten der CA trauen und damit alle auch einem von dieser CA ausgestellten Zertifikat trauen. In diesem Zertifikat (vgl. Abbildung 5.4) steht neben anderen Informationen zur Lebensdauer und den verwendeten Algorithmen und Schlüssellängen der eindeutiger Name seines Besitzers und sein öffentlicher Schlüssel. Wie funktioniert nun eine digitale Signatur in der Praxis? In Abbildung 5.3 haben Sie ein Beispiel gesehen, in dem ein Dokument signiert wird. Als Vorbedingung wurde hierbei angenommen, dass sowohl der Sender als auch der Empfänger Mitglieder der gleichen PKI und im Besitz des öffentlichen Schlüssels der Certificate Authority sind. Als Signatur-Algorithmus wird RSA, zusammen mit MD5 als Hashverfahren, verwendet. Das digital zu signierende Dokument wird vom Absender mit dessen privatem Schlüssel signiert. Da dies bei großen Dokumenten sehr langwierig ist, wird nicht das Dokument selbst, sondern nur sein Hashwert mit dem im Zertifikat spezifizierten Public-Key-Algorithmus verschlüsselt. Der Sender schickt sein Zertifikat zusammen mit dem Dokument und seiner Signatur zum Empfänger, damit dieser seinen öffentlichen Schlüssel hat. Zuerst muss das Zertifikat des Senders auf Echtheit und Gültigkeit geprüft werden. Dies geschieht mit dem öffentlichen Schlüssel der CA. Die CA hat das Zertifikat des Senders zum Zeitpunkt seiner Ausstellung mit ihrem privaten Schlüssel signiert, indem sie über das Zertifikat einen Hashwert gebildet und diesen mit RSA verschlüsselt hat. Der Empfänger bildet über das Zertifikat ebenfalls einen Hashwert, entschlüsselt die Signatur auf dem Zertifikat mit dem öffentlichen Schlüssel der CA und vergleicht beide Werte. Sind sie gleich, wurde das Zertifikat von der CA ausgestellt und nicht verändert. Nun kann aufgrund der Zeitangaben im Gültigkeitsfeld des Zertifikats überprüft werden, ob es gültig ist und ob anhand bestimmter anderer Attribut-Einträge im Zertifikat bestimmte Einschränkungen für dessen Besitzer gelten. Wenn alles in Ordnung ist, kann der Empfänger die digitale Signatur mit dem öffentlichen Schlüssel, der im Zertifikat des Absenders eingetragen ist, dechiffrieren und erhält als Ergebnis den Hashwert, den der Absender über das Dokument gebildet hat. Anschließend berechnet der Empfänger über das erhaltene Dokument ebenfalls einen Hashwert und vergleicht dann beide Werte. Sind sie gleich, weiß der Empfänger, dass das Dokument nicht verändert wurde und dass es mit dem öffentlichen Schlüssel der Person oder Organisation verschlüsselt wurde, deren Name im Zertifikat steht. Somit ist das Dokument authentisch und integer. Das Zertifikat des Absenders wird meist mit dem Dokument zusammen zum Empfänger geschickt, da dieser in der Regel nicht die Zertifikate aller möglichen Absender vorliegen hat. Falls der Empfänger den öffentlichen Schlüssel oder das Zertifikat des Senders bereits auf eine andere Weise erhalten hat, braucht der Sender sein Zertifikat nicht mitzuschicken.
163
5 Authentifizierung
Falls man eine digitale Signatur ausschließlich zum Authentifizieren benutzt, wird natürlich kein Dokument übertragen und signiert. In diesem Fall signiert die Gegenstelle meist irgendwelche nicht vorherbestimmbare Zufallszahlen und schickt diese zusammen mit der Signatur und ihrem Zertifikat zum Authentifikator. Dieses Verfahren wird Ihnen im Kapitel über das IKEProtokoll (Kapitel 8) wieder begegnen.
5.4.2
Die Certificate Authority (CA)
Eine Certificate Authority kann eine private oder öffentliche Institution sein oder auch eine Organisationseinheit innerhalb eines Unternehmens. Sie ist für die Ausstellung, Verteilung, Erneuerung und Sperrung von digitalen Zertifikaten verantwortlich. Da die CA für die Bindung eines öffentlichen Schlüssels an die Identität einer Person oder Organisation verantwortlich ist, muss diese Identität auch sorgfältig geprüft werden. Üblicherweise werden davon abhängig auch verschiedene Stufen digitaler Zertifikate ausgestellt. Die höchste Stufe ist in der Regel die, die ein persönliches Erscheinen und den Nachweis der Identität durch einen Personalausweis erforderlich macht, während niedrige Stufen beispielsweise oftmals nur eine gültige E-Mail-Adresse erfordern. In offenen Umgebungen wie dem Internet sind für elektronische Transaktionen so genannte Serverzertifikate üblich. Hier werden vertrauliche Daten, z.B. Kreditkarteninformationen und Ähnliches, übertragen, die vor unbefugtem Zugriff geschützt sein müssen. Das Serverzertifikat identifiziert den Server, zu dem die Verbindung aufgenommen wurde.
5.4.3
Die Registration Authority (RA)
Die Registration Authority (RA) fungiert als Annahmestelle für Anträge zur Erteilung von digitalen Zertifikaten. Ihre Hauptfunktion besteht in der zuverlässigen Identifizierung eines Antragstellers. Im Unternehmensbereich obliegt diese Funktion meist den Personalabteilungen; öffentliche RAs haben entweder eigene Annahmestellen oder benutzen Dienstleistungen anderer Organisationen, die eine entsprechende Infrastruktur betreiben – zum Beispiel die Deutsche Bundespost. Ein Antragssteller für ein rechtsgültiges Zertifikat muss gegenüber der RA seine Identität durch persönliche Anwesenheit und Ausweisdokumente nachweisen.
5.4.4
Zertifikat-Management
Ein zentrale Funktion in einer PKI ist das Management von Zertifikaten und öffentlichen Schlüsseln. Zertifikate müssen signiert werden, erneuert werden, verteilt werden und gegebenenfalls vor ihrem natürlichen Ablauf gesperrt
164
Public Key Infrastructure (PKI)
werden. Diese Funktion wird, je nach Größe der PKI, von einem oder mehreren Systemen wahrgenommen, die dafür meist verbreitete relationale Datenbanken und Verzeichnisdienste benutzen. Lebensdauer eines Zertifikats Die Lebensdauer eines Zertifikats ist ein wichtiger Faktor, der insbesondere bei Zertifikaten, die natürlichen Personen ausgestellt werden, einen entscheidenden Einfluss auf die Sicherheit und den damit verbundenen Aufwand hat. Zertifikate, die eine sehr kurze Lebensdauer haben, müssen sehr oft verlängert oder erneuert werden. Dies hat je nach Größe der PKI einen erheblichen Administrationsaufwand zur Folge. Andererseits stellen Zertifikate, die sehr lange gültig sind, für viele Sicherheitsverantwortliche ein Sicherheitsrisiko dar. Dies hängt damit zusammen, dass die Zertifikate in vielen Umgebungen auch dazu benutzt werden, bestimmte Rechte oder Einschränkungen mit einer Person zu verbinden. Je nach Tätigkeit und Vertrauenswürdigkeit der Person kann sich dies natürlich laufend ändern. Falls hier nicht organisatorisch dafür gesorgt wird, dass diese Änderungen Eingang in das Zertifikat der betreffenden Person finden, dann können hier tatsächlich Sicherheitslöcher entstehen. Eine kurze Gültigkeit des Zertifikats würde dieses Problem entschärfen, denn ein erneuertes Zertifikat würde immer die aktuellen Rechte und Einschränkungen des Betreffenden enthalten. Zertifikate, die beispielsweise für Security-Gateways ausgestellt werden, haben meist eine lange Gültigkeitsperiode, da sich ihr Sicherheitsstatus und ihre Funktionalität nicht so oft ändern, wie dies bei einer Person der Fall ist. Protokolle zur Anforderung und Verteilung von Zertifikaten Es gibt eine Reihe meist herstellerspezifischer Verfahren und Protokolle zur Verteilung von Zertifikaten. Dabei muss man zwischen der Anforderung eines Zertifikats (Certificate Request) und der Zustellung des von der Certificate Authority signierten Zertifikats unterscheiden. Viele Hersteller haben zu diesem Zweck eigene Verfahren entwickelt, aber aufgrund der zunehmenden Bedeutung der digitalen Signatur zur Benutzer-Authentifizierung hat die Internet Engineering Task Force (IETF) eine entsprechende Arbeitsgruppe gegründet, die an den nötigen Standards arbeitet und schon ziemliche Fortschritte gemacht hat. Sperrlisten Beim Lesen dieses Abschnitts werden Sie sich vielleicht gefragt haben, was passiert, wenn beispielsweise ein Zertifikat mit einer Gültigkeitsdauer von drei Monaten ausgestellt wurde, dessen Besitzer aber aus unschönen Grün-
165
5 Authentifizierung
den von seinem Unternehmen vor dem Ablaufdatum des Zertifikats entlassen wurde. Dann könnte sich der Betreffende mit diesem Zertifikat weiterhin auf den Systemen seines Unternehmens authentifizieren. Das ist in der Tat so. Um dieses Problem auf ein erträgliches Maß zu reduzieren, verwendet man so genannte Zertifikat-Sperrlisten (CRL, Certificate Revocation List), in denen die Seriennummern von Zertifikaten enthalten sind, die zwar aufgrund ihrer Zeiteinträge noch gültig sind, aber von der Certificate Authority für ungültig erklärt wurden. Diese Liste wird an die Systeme verteilt, die sie benötigen. Je nach Durchdringung der PKI mit entsprechenden Applikationen, die öffentliche Schlüssel benutzen, können dies alle beteiligten Systeme sein. In anderen Fällen, in denen Signaturen nur zur Authentifizierung benutzt werden, müssen nur die beteiligten Zugangskontrollsysteme die Sperrlisten erhalten. Allerdings sind die Sperrlisten selten sehr zeitnah, denn die Verteilung erfolgt meist in bestimmten Intervallen.
5.4.5
Die Qual der Wahl: Öffentliche oder private Zertifikate
Ich möchte im Zusammenhang mit unserem Thema, den virtuellen privaten Netzen, nicht zu sehr auf dieses für viele Unternehmen neue und gleichzeitig kritische Thema eingehen. Denn kein Unternehmen wird auf die Idee kommen, ausschließlich zur Benutzer-Authentifizierung eine PKI in seinem VPN einzuführen. Aber eine PKI und deren Zertifikate zur Authentifizierung zu benutzen, wenn sie bereits vorhanden sind oder im Aufbau ist, das ist eine andere Sache. Ebenso zeugt es auch von Weitsichtigkeit, das Thema digitale Signatur zu berücksichtigen, auch wenn noch keine aktuellen Projekte anstehen oder in Planung sind. Obwohl das Thema PKI in erster Linie kein Netzwerkthema ist, spielt es im Bereich der Benutzer-Authentifizierung eine zunehmend wichtige Rolle. Die Frage, ob man in seinem Unternehmen eine eigene, private PKI betreibt oder eine öffentliche verwendet, hängt von einer ganzen Reihe sicherheitstechnischer, unternehmerischer und gesetzlicher Rahmenbedingungen ab. Der wesentliche Unterschied liegt in der Kompatibilität mit Zertifikaten anderer PKIs in anderen Unternehmen und in rechtlichen Fragen. Die Kostenfrage spielt natürlich auch eine Rolle: Insbesondere bei kleineren Unternehmen ist es in der Regel nicht wirtschaftlich, eine eigene PKI mit der nötigen Hard- und Software und dem geeigneten Personal zu betreiben. Rechtlich gültige Zertifikate sind generell bei einer externen Certificate Authority zu beantragen. Hier bleibt keine andere Wahl, denn diese Zertifikate bedingen ein von den zuständigen Aufsichtsbehörden zugelassenes Trust-Center, das bestimmte Auflagen erfüllen muss. In Deutschland wird all dies vom Signaturgesetz SigG, im Artikel 3 des Gesetzes zur Regelung von Rahmenbe-
166
Public Key Infrastructure (PKI)
dingungen für Informations- und Kommunikationsdienste, dem IuKDG (Informations- und Kommunikationsdienste-Gesetz) vom 22.7.1997 und in der daraus abgeleiteten Signaturverordnung SigV vom 8.10.1997 geregelt.
5.4.6
Das Signaturgesetz und die EU-Richtlinie
Man darf sich von dem Ausdruck »mit dem Signaturgesetz konform« nicht dahin gehend in die Irre leiten lassen, ein mit einer solchen Signatur elektronisch unterschriebenes Dokument wäre rechtlich der Schriftform gleichzusetzen – das ist nicht der Fall. Eine Qualifizierung als Privaturkunde gemäß § 416 ZPO (Zivilprozessordnung) kommt bei einem digital signierten elektronischen Dokument auch nicht in Betracht, denn im SigG fehlt jede gesetzliche Bezugnahme. Leider ist die Rechtsunsicherheit gegenüber Dokumenten in Schriftform auch nicht in dem Maße geschrumpft, wie es sich viele Anwender gewünscht haben mögen. Einzig die Authentizität des Absenders einer Nachricht und die Integrität der darin übertragenen Daten gelten als so genannte gesetzliche Vermutungswirkungen. Was aber gilt, ist, dass jemand, der eine andere als die digitale Signatur nach dem SigG einsetzt, im Rahmen eines möglichen Prozesses einen rechtlichen Nachteil erleiden kann. Es gibt in Deutschland mittlerweile einige private Unternehmen, die alle rechtlichen und technischen Voraussetzungen erfüllen, um als öffentliche Trust-Center gesetzeskonforme digitale Zertifikate auszustellen. Allerdings müssen die Trust-Center, die solche Signaturen erzeugen, extreme Sicherheitsauflagen erfüllen und in regelrechten Hochsicherheitsbunkern ihrer Tätigkeit nachgehen. Sogar die Türen müssen dort nicht nur aus dickem Stahl hergestellt sein, sondern auch eine Zertifizierung haben. Das führt natürlich dazu, dass gesetzeskonforme Zertifikate recht teuer werden. Kritiker sprechen von einer »Überregulierung«, die obendrein noch voll am Markt und den Bedürfnissen der Anwender vorbei zielt. Denn bisher kann man nur von einem Flop reden: Statt der Millionen erwarteter Zertifikate haben die Firmen nur wenige tausend vertreiben können. Die Finanzwelt benutzt eigene Standards und interessiert sich bislang nicht sonderlich für gesetzeskonforme Signaturzertifikate. Viele Unternehmen setzen eigene PKIs ein oder benutzen öffentliche, nicht zertifizierte und dadurch viel billigere Trust-Center. Viele dieser nicht SigG-konformen Trust-Center bieten verschieden »starke« Zertifikate an: normale, die man sich per gültiger (und überprüfter) E-MailAdresse erteilen lassen kann, und andere, starke Zertifikate, die eine persönliche Anwesenheit mit gültigen Ausweispapieren bei einer RA erfordern. Somit können Kunden auswählen, welche Sicherheitsstufen sie benötigen, und für das benötigte Maß an Sicherheit bezahlen. Viele andere Staaten, beispielsweise auch die USA, setzen statt auf staatliche Überregulierung auf eine Selbstregulierung durch den Markt – eine Idee, die der Europäischen Union (EU) mittlerweile auch gekommen ist.
167
5 Authentifizierung
So werden in der EU-Richtlinie zur digitalen Signatur (Richtlinie 1999/93/EG des Europäischen Parlaments und des Rates vom 13. Dezember 1999 über gemeinschaftliche Rahmenbedingungen für elektronische Signaturen), die am 19. Januar 2000 in Kraft getreten ist, gänzlich andere Töne angeschlagen als im zum Zeitpunkt der Entstehung dieses Kapitels noch gültigen deutschen Signaturgesetz. Es werden darin zwei verschieden starke Arten von Signaturen, die »elektronische Signatur« und die »fortgeschrittene elektronische Signatur«, festgeschrieben, die auch eine unterschiedliche rechtliche Bedeutung erlangen. So unterscheidet diese Richtlinie im Artikel 2 (Begriffsbestimmungen) zwischen: 1. »Elektronische Signatur«: Daten in elektronischer Form, die anderen elektronischen Daten beigefügt oder logisch mit ihnen verknüpft sind und die zur Authentifizierung dienen. 2. »Fortgeschrittene elektronische Signatur«: eine elektronische Signatur, die folgende Anforderungen erfüllt: 왘 Sie ist ausschließlich dem Unterzeichner zugeordnet. 왘 Sie ermöglicht die Identifizierung des Unterzeichners. 왘 Sie wird mit Mitteln erstellt, die der Unterzeichner unter seiner alleini-
gen Kontrolle halten kann. 왘 Sie ist so mit den Daten, auf die sie sich bezieht, verknüpft, dass eine
nachträgliche Veränderung der Daten erkannt werden kann. Zusammen mit weiteren Regelungen entspricht damit die »fortgeschrittene elektronische Signatur« nahezu der im alten deutschen Signatur-Gesetz beschriebenen Signatur. Im Augenblick ist ein Gesetzentwurf des Bundeskabinetts vom 16. August 2000 im Gesetzgebungsverfahren, der voraussichtlich im Frühjahr 2001 in Kraft treten wird. Der Auslöser dafür war die oben genannte EU-Richtlinie, deren Umsetzungsfrist am 19. Juli 2001 abläuft. Das alte Signatur-Gesetz, so das Bundeskabinett in seiner Begründung für den Neuentwurf, soll wegen der erheblichen strukturellen und inhaltlichen Änderungen gegenüber dem geltenden Signaturgesetz ... durch den vorgelegten Gesetzentwurf insgesamt abgelöst werden. Ein weiterer wichtiger Punkt der Richtlinie und deren nationaler Umsetzung ist die Gleichstellung aller in anderen EU-Staaten erteilter und im Sinne der EU-Richtlinie gleichwertiger Zertifikate. Das heißt, ein Zertifikat eines Trust-Centers, das aufgrund der gesetzlichen Umsetzung der EU-Richtlinie in einem anderen EU-Mitgliedsstaat akkreditiert ist, ist einem in Deutschland von einem dort akkreditierten Trust-Center erteilten Zertifikat gleichwertig – also ist der bisher rein deutsche Wettbewerb gesetzeskonformer Trust-Center untereinander mittlerweile dabei, ein europäischer zu werden. Erweiterungen durch Abkommen mit Nicht-EU-Staaten sind ebenfalls geplant bzw. in Vorbereitung.
168
6
Tunneling-Technologien im Überblick
Das Tunneling ist die Basis moderner VPNs. Mit Hilfe dieser Technologie kann man Pakete eines Netzwerkprotokolls in Pakete eines anderen Netzwerkprotokolls kapseln und über dieses Netzwerk übertragen. Auf diese Weise kann man zum Beispiel IPX-Pakete durch ein IP-Netzwerk transportieren. Eine andere, speziell für IP-Netze interessante Anwendung ist das Verstecken von privaten, nicht registrierten Netzwerk- und Hostadressen, indem man IP in IP tunnelt. Auf diese Weise kann man seine privaten Netze über das Internet miteinander verbinden. Man kapselt hierzu die IP-Pakete mit privaten Adressen in Pakete mit offiziell registrierten IP-Adressen ein und transportiert diese durch das Internet zur Gegenstelle, die die originalen Pakete wieder auspackt. Übertragungsstrecke TunnelEndpunkt
Daten L-3 L-2 L-1
Tunneling-Protokoll
Encapsulation
Daten L-3 Protocol Header L-3 L-2 L-1
TunnelEndpunkt
Decapsulation
Daten L-3 L-2 L-1
Abbildung 6.1: Tunneling ist eine Technologie zum Einkapseln und Transportieren von Netzwerkpaketen in anderen Netzwerkpaketen.
Es gibt eine ganze Reihe von Tunneling-Protokollen, von denen jedoch zwei eine besondere Rolle spielen: das Layer 2 Tunneling Protocol (L2TP) und das IP Security Protocol (IPSec) im Tunnel-Modus. Diese beiden Protokolle sind relativ neu. Sie sind standardisiert, und sie verdrängen zunehmend alle anderen Tunneling-Protokolle in Neuinstallationen. Diesen beiden Protokollen werden aus diesem Grund auch zwei eigene Kapitel (Kapitel 7, IPSec, und Kapitel 9, L2TP) gewidmet. In Abbildung 6.1 sehen Sie einen solchen Vorgang. Die Netzwerkpakete (Layer 3) werden in andere Netzwerkpakete mit einem neuen Layer-3-Header eingekapselt (Encapsulation), und es wird ein Tunnel-Header eingefügt. An diesem Header, der zwischen dem neuen Layer-3-Header und der Nutzlast
169
6 Tunneling-Technologien im Überblick
angeordnet sein muss, erkennt der Empfänger, dass es sich um ein Paket des betreffenden Tunneling-Protokolls handelt. Er wertet den Header aus, entpackt das originale Paket (Decapsulation) und transportiert es weiter. Zwischen dem Sender und dem Empfänger, den so genannten Tunnelendpunkten, die durch die Netzwerkadressen des neuen Layer-3-Headers festgelegt sind, besteht eine Tunnelverbindung. In manchen Fällen ist es nicht notwendig, im IP-Protokoll einen speziellen Tunnel-Header einzufügen, denn gemäß dem Standard benutzt man das Protokollfeld des IP-Headers dazu anzuzeigen, welches Protokoll auf den Header folgt. Üblicherweise ist dies TCP (mit Protokollnummer 6) oder UDP (mit Protokollnummer 17). Wenn jedoch die Nummer 4 (IP) in diesem Feld enthalten ist, weiß die Gegenstelle, dass ein IPPaket folgt, also ein vollständiges Paket eingekapselt wurde. Auf diese Weise kann man IP-in-IP-Tunneling ohne einen speziellen Header verwenden. Die Tunnelendpunkte können in der Regel sowohl normalen Netzwerkverkehr als auch Tunnelpakete verarbeiten. Wie ein Paket zu behandeln ist, erkennt der Empfänger am Tunnel-Header oder an der IP-Protokollnummer. Der Sender nimmt eine Einkapselung aufgrund der Verarbeitungsstrategie einer höheren Protokollschicht vor. Dabei kann es sich um eine Sicherheitsstrategie handeln oder um interne Tabellen mit Kennzeichnungen, aus denen hervorgeht, welche Pakete normal zu transportieren sind und welche getunnelt werden müssen. Es gibt allerdings eine Ausnahme: Security-Gateways werden aus Sicherheitsgründen manchmal so konfiguriert, dass sie ausschließlich Tunneling-Protokolle terminieren und keine »normalen« Protokolle wie zum Beispiel SNMP, FTP usw.
6.1
Tunneling-Modelle
In Abhängigkeit davon, wo die Tunnel beginnen und enden, kann man drei verschiedene, so genannte Tunneling-Modelle unterscheiden: das Ende-zuEnde-Modell, das Provider-Enterprise-Modell und das Intra-Provider-Modell. In Abbildung 6.2 sehen Sie die drei Modelle im Vergleich.
6.1.1
Das Intra-Provider-Modell
Das Intra-Provider-Modell zeichnet sich dadurch aus, dass die Tunnel bei den Service Providern beginnen und enden. Gegenüber den beiden anderen Modellen hat diese Variante einen entscheidenden Vorteil: Auf der Seite des Kunden muss keine spezielle Hard- oder Software installiert werden, er kann seine vorhandenen Systeme weiter benutzen und ist nicht in das Tunneling involviert. Die notwendigen Gateways werden von den Providern betrieben und stehen normalerweise auch in deren Räumen. Dieses Modell wird vorwiegend für Remote-Access-VPNs verwendet, kann jedoch auch für BranchOffice-VPNs eingesetzt werden.
170
Tunneling-Modelle
Das Bay Dial VPN Service Protocol (BayDVS) der Firma Nortel Networks ist ein Vertreter der für dieses Modell geeigneten Tunneling-Protokolle. Die RemoteAccess-Clients sind Standardprogramme und meist bereits in den Betriebssystemen integriert (Microsoft DFÜ-Netzwerk, Unix PPPD usw.). Das VPNGateway auf der Seite des Service Providers verbindet den Tunnelendpunkt zum Beispiel über einen Frame-Relay-PVC mit dem Router des Kunden. Der Kunde weiß somit, dass aller Verkehr über diesen PVC durch einen oder mehrere Tunnel zu den POPs (Point of Presence) des Providers geführt wird. Er selbst setzt aber keinerlei spezielle Tunneling-Technologie ein.
6.1.2
Das Provider-Enterprise-Modell
Beim Provider-Enterprise-Modell sind sowohl die Service Provider als auch die Endkunden in das Tunneling involviert. Die Tunnel beginnen im POP des Service Providers und enden im Gateway des Kunden. Dieses Modell wird primär für Remote-Access-VPNs eingesetzt, kann aber auch in Branch-OfficeVPNs Verwendung finden. In diesem Modell muss der Kunde eine spezielle Hard- oder Software als VPN-Gateway einsetzen. Die Clientsoftware kann ein beliebiges Einwählprogramm (Microsoft DFÜ-Netzwerk usw.) sein, da der Tunnel erst im POP des Providers beginnt. POP
Client ISDN PSTN
Kunde
Carrier
Gateway
Internet
Service Provider
Carrier
Kunde
Intra-ProviderModell Provider-EnterpriseModell
Ende-zu-Ende-Modell Abbildung 6.2: Die drei Tunneling-Modelle im Vergleich
Typische Tunneling-Protokolle für dieses Modell sind das Layer 2 Tunneling Protocol (L2TP) und Layer 2 Forwarding (L2F). In selteneren Fällen setzt man hierfür auch das Point-to-Point Tunneling Protocol (PPTP) ein.
171
6 Tunneling-Technologien im Überblick
6.1.3
Das Ende-zu-Ende-Modell
Im Ende-zu-Ende-Modell werden die Tunnel ausschließlich vom Kunden aufgebaut. Die Carrier und/oder Service Provider sind dabei gar nicht in das Tunneling involviert. Sie transportieren im Fall von IP-VPNs ausschließlich IP-Pakete. Dass in diesen Paketen andere Pakete eingekapselt sind, können sie zwar erkennen (wenn sie das wollen), aber es hat keinen Einfluss auf den Transport der IP-Pakete. Üblicherweise stehen die Gateways zum Netzwerk eines Providers in den Räumen der Endkunden, sind deren Eigentum und werden auch von ihnen betrieben. Jedoch kann dieses Modell auch als so genannter Carrier Managed Service von einem Service Provider oder Carrier betrieben werden. Die Remote-Access-Clients wählen sich in die POPs der Service Provider ein, und eine spezielle VPN-Clientsoftware im Endgerät des Kunden baut daraufhin einen Tunnel zu einem VPN-Gateway im Kundennetzwerk auf. Theoretisch kann man fast alle Tunneling-Protokolle in einem Ende-zu-EndeModell einsetzen, jedoch sind einige Protokolle besser dafür geeignet als andere. Im Ende-zu-Ende-Modell setzt man vorwiegend IPSec im Tunnelmodus und das Point-to-Point Tunneling Protocol (PPTP) ein. In seltenen Fällen verwendet man das Layer 2 Tunneling Protocol (L2TP) mit einer speziellen Clientsoftware in diesem Modell.
6.2
Tunneling-Protokolle
Man kann die Tunneling-Protokolle in zwei verschiedene Klassen einteilen: die Layer-2-Tunneling-Protokolle und die Layer-3-Tunneling-Protokolle. Die Unterscheidung basiert auf der Schicht des OSI- oder IP-Schichten-Modells, deren Pakete eingekapselt werden. Layer-2-Protokolle kapseln Pakete der Sicherungsschicht (Layer 2) in andere Pakete, meist solche der Schicht 3, ein. Layer-3-Protokolle kapseln Pakete der Netzwerkschicht (Layer 3) in andere Pakete der Netzwerkschicht ein.
6.2.1
Layer-2-Tunneling-Protokolle
In Abbildung 6.3 sehen Sie die Funktionsweise des Layer-2-Tunneling. In diesem Beispiel werden PPP-Rahmen (PPP, Point-to-Point Protocol, ein Protokoll, um verschiedene Netzwerkprotokolle über eine Punkt-zu-Punkt-Verbindung zu transportieren) in IP-Pakete eingekapselt. In den PPP-Rahmen können Pakete verschiedener anderer Netzwerkprotokolle wie IP, IPX, VinesIP, NetBEUI usw. enthalten sein. In unserem Beispiel tunnelt das Layer 2 Tunneling Protocol (L2TP) IP und IPX. Beim Tunneling entsteht ein gewisser Overhead, denn außer dem L2TP-Header werden zusätzliche UDP-, IP- und
172
Tunneling-Protokolle
PPP-Header erzeugt. Bei großer Nutzdatenlänge fällt dieser Anteil allerdings nicht so sehr ins Gewicht. Der Vorteil von Layer-2-Tunneling-Protokollen ist der, dass eine Vielzahl von Netzwerkprotokollen getunnelt werden kann, ohne dass sich das Tunneling selbst darum kümmern muss, da dies bereits auf der PPP-Ebene erfolgt ist. Applikation
ApplikationsPakete
Applikation Applikationspakete
Applikationspakete
TCP
SPX
TCP
SPX
IP
IPX
IP
IPX
PPP
PPP
L2TPHeader
L2TPHeader
ApplikationsPakete
TCP
SPX
UDP
UDP
TCP
SPX
IP
IPX
IP
IP
IP
IPX
Layer-2
Layer-2
Layer-1
Layer-1
PPP
PPP
Übertragungsmedium Abbildung 6.3: Das Layer-2-Tunneling kapselt Pakete der Schicht 2, hier PPP, ein.
6.2.2
Layer-3-Tunneling-Protokolle
Das Layer-3-Tunneling arbeitet eine Schicht höher als Layer-2-Protokolle. Hier werden Pakete der Netzwerkschicht in andere Pakete dieser Schicht eingekapselt, wie Sie in Abbildung 6.4 sehen. Der Paket-Overhead ist geringer als der von Layer-2-Protokollen. Allerdings muss der Tunneling-Prozess die von den höheren Schichten ankommenden Pakete analysieren und im Tunnel-Header vermerken, welche Art von Protokoll getunnelt wird. In dem Beispiel, das in Abbildung 6.4 zu sehen ist, wird IPSec im Tunnel-Modus eingesetzt. Das gezeigte IPSec-AH-Protokoll (vgl. Kapitel 7) fügt einen IPSec-AHHeader ein. Andere Protokolle, zum Beispiel IPSec-ESP, können neben dem Header auch einen Trailer in das zu erzeugende Paket einfügen.
173
6 Tunneling-Technologien im Überblick
Applikation
Applikation Applikationspakete
UDP
TCP Applikationspakete TCP IP
UDP
Applikationspakete
UDP
TCP
IP
IP
IPSec-AHHeader
IPSec-AHHeader
IP
IP
Layer-2
Layer-2
Layer-1
Layer-1
Applikationspakete TCP
UDP
IP
Übertragungsmedium Abbildung 6.4: Das Layer-3-Tunneling kapselt Pakete der Schicht 3, hier IP, ein.
6.2.3
Multi Protocol Label Switching (MPLS)
Im Bereich von Backbone-Netzen setzt sich zunehmend MPLS (Multi Protocol Label Switching) als Tunneling-Protokoll durch, obwohl es streng genommen gar keins ist. In Netzen mit niedriger und mittlerer Übertragungsbandbreite und einer überschaubaren Anzahl von Netzen und Vermittlungssystemen ist IP ein ideales Netzwerkprotokoll. In sehr großen Netzen mit zunehmend höheren Geschwindigkeiten bis in den Gbit-Bereich wird die relativ umständliche Layer-3-Verarbeitung der IP-Pakete jedoch immer mehr zu einem Problem. Beim Routing auf Layer-2-Ebene, zum Beispiel in einem ATM-Netz, hat man diese Performance-Probleme nicht, ist jedoch auf ein bestimmtes Transportmedium festgelegt und damit extrem unflexibel. Man will also die Flexibilität und Unabhängigkeit der Layer-3-Vermittlung, aber auch die Performance eines Layer-2-Protokolls. Die Lösung liegt eigentlich auf der Hand, man braucht »nur« eine zusätzliche Protokollschicht einzufügen, die zwischen der Ebene 2 und 3 liegt. Diese Ebene stellt die notwendige Entkopplung zwischen den beiden Schichten dar und bildet eine Art virtuelle, topologieunabhängige Schicht 2. In dieser Schicht werden so genannte Label verwendet, aufgrund derer die Weiterleitungsentscheidungen in den MPLS-Routern oder -Switches getroffen werden. MPLS ist nicht die einzige Entwicklung dieser Art. Gegenüber herstellereigenen Protokollen wie dem Tag-Switching von Cisco oder ARIS (Aggregate RouteBased IP Switching) von IBM bietet MPLS jedoch den Vorteil der offiziellen Standardisierung durch die Internet Engineering Task Force (IETF), die eine spezielle
174
Tunneling-Protokolle
MPLS-Arbeitsgruppe zu diesem Zweck ins Leben gerufen hat. MPLS ist zwar völlig unabhängig vom Layer-3-Protokoll, jedoch ist aufgrund der Entwicklungen im Netzwerkbereich eine Fokussierung auf das IP-Protokoll erfolgt. MPLS ist genau genommen kein echtes Tunneling-Protokoll, da es keine Kapselung von Paketen im Sinne von Protokollen wie L2TP oder IPSec vornimmt, sondern nur einen zusätzlichen Transport-Header zwischen Layer 2 und 3 einfügt. Man bezeichnet MPLS deshalb auch scherzhaft als »Layer-2½-Protokoll«. MPLS ist ein reines Carrier- und Service-Provider-Protokoll und wird üblicherweise in deren Backbones eingesetzt. Ein Einsatz in Unternehmensnetzen macht nur in sehr großen Netzwerken Sinn. Jedoch ist eine gewisse Durchdringung in Campusnetze durchaus denkbar, da MPLS nicht nur unabhängig von der Schicht 3, sondern auch von der Topologie, also der Schicht 2, ist. Es kann dadurch auch zum Beispiel in Ethernet-Switches eingesetzt werden. Alle beteiligten Router und WAN-Switches müssen das Protokoll kennen und entsprechend ihrer Rolle verarbeiten können. Es gibt, ähnlich zum DiffServModell, Router, die an der Grenze des Netzwerks normale IP-Pakete in MPLS-Pakete und zurück transformieren und reine MPLS-Transport-Router. Diese Systeme, deren Anordnung im Netzwerk Sie in Abbildung 6.5 sehen, nennt man Label Edge Router (LER) und Label Switching Router (LSR). MPLSRouter müssen sich wie IP-Router über die Vergabe der Label austauschen. Dies kann über ein spezielles Label Distribution Protocol (LDP) oder auch über das Resource Reservation Protocol (RSVP) geschehen. LSR
LER
LSR
LER
LSR
LSR
LSR
LSR
LSR
Applikationspaket
Applikationspaket TCP
UDP
TCP
UDP
IP (Layer-3)
Applikationspaket TCP
UDP
IP (Layer-3)
Label
IP (Layer-3)
Layer-2
Layer-2
Layer-2
Layer-1
Layer-1
Layer-1
Abbildung 6.5: MPLS fügt zum Pakettransport durch ein MPLS-Netz temporär eine neue Schicht (Label) zwischen Layer 2 und 3 ein.
Ein großer Vorteil von MPLS ist der, dass es keine Hardwaremodifikationen voraussetzt. 175
6 Tunneling-Technologien im Überblick
6.3
Standardisierte Tunneling-Protokolle
Es gibt eine ganze Reihe verschiedener Tunneling-Protokolle, aber nur ganz wenige davon wurden von einem Standardisierungsgremium auch als verbindlicher Standard verabschiedet. Die für IP-VPNs interessanten und zukunftssicheren Protokolle sind das IP Security Protocol (IPSec) und das Layer 2 Tunneling Protocol (L2TP). GRE (Generic Routing Encapsulation) spielt als allein stehendes TunnelingProtokoll keine große Rolle, dient aber als Grundlage für andere nicht standardisierte Protokolle, wie zum Beispiel für das Point-to-Point Tunneling Protocol (PPTP) oder Bay-DVS. Aus diesem Grund wird in diesem Buch auch nicht explizit auf GRE eingegangen.
6.3.1
IP Security Protocol (IPSec) im Tunnel-Modus
IPSec im Tunnel-Modus dient meist als Basis für das Ende-zu-Ende-Modell. Alle beteiligten Systeme müssen mit einer entsprechenden IPSec-Implementierung ausgerüstet sein. In Abbildung 6.6 sehen Sie am Beispiel eines Remote-Access-VPNs die Funktionsweise. Die IPSec-Tunnel beginnen und enden auf dem Endsystem des Kunden, meist einem Rechner mit IPSecClientsoftware und einem IPSec-Gateway. Die Carrier und Service Provider sind nicht am Tunneling beteiligt und transportieren aus ihrer Sicht nur die IP-Pakete zwischen Client und Gateway. Das öffentliche Interface des IPSecGateways hat eine feste, offiziell registrierte IP-Adresse. Auch der Client bekommt bei der Einwahl in den POP eines Service Providers eine offizielle IP-Adresse zugewiesen. Das private Interface des Gateways kann in einem nicht registrierten IP-Netzwerk liegen. IPSecClient ISDN PSTN
Kunde
IPSecGateway
POP
Carrier
Internet
Service Provider
IPSec-Tunnel
IPSec Daten IP IPSec IP L-2 L-1
Abbildung 6.6: IPSec im Tunnel-Modus
176
Carrier
Kunde
Standardisierte Tunneling-Protokolle
Beim Client ist die Sache ein klein wenig komplexer. Er hat auch zwei IPAdressen: zum einen die ihm vom Provider für die DFÜ-Verbindung (DFÜ, Datenfernübertragung) zugewiesene, offizielle, und zum anderen seine private IP-Adresse aus dem Adressbereich des Kundennetzes. Einige IPSec-Implementierungen erfordern leider, dass der Client immer die gleiche offizielle IP-Adresse zugewiesen bekommt, wodurch diese damit faktisch zu einer statischen Adresse wird. Das ist den Internet Service Providern (ISP) ein Greuel, da deren verfügbare Adressen immer mehr zur Neige gehen. Üblicherweise werden den Einwähl-Clients die IP-Adressen vom den ISPs dynamisch aus einem so genannten IP-Adress-Pool zugewiesen. Diese Pools haben in der Regel so viele Adressen, wie der Provider an gleichzeitigen physikalischen Verbindungen zur Verfügung stellen kann. Da sich aber nie alle Kunden eines ISPs gleichzeitig einwählen, haben die Provider ihre POPs in der Regel überbucht, sie haben also mehr Kunden als Einwählports – und damit auch weitaus weniger IP-Adressen als Kunden. Falls nun pro Client eine feste IPAdresse reserviert werden müsste, wären die Provider gezwungen, eine viel größere Anzahl von Adressen vorzuhalten, als wirklich zum Betrieb benötigt werden – und das wird langsam zu einem Problem, da die Adressen für IP Version 4 weltweit immer knapper werden. Manche Provider sträuben sich daher gegen statische IP-Adressen für Remote-Access-Clients, oder sie verlangen entsprechende Gebühren, was dem eigentlichen Zweck eines VPN – Kosten zu senken – widerspräche. Also sollte bei der Auswahl der IPSec-Client-Implementierung darauf geachtet werden, dass diese eine dynamische Zuweisung der offiziellen IP-Adressen unterstützt. Die private IP-Adresse kann bei guten Client-Implementierungen auch dynamisch durch den Tunnel vom Gateway zugewiesen werden. Hier ist vom IPSec-Standard kein Verfahren festgeschrieben, es existieren lediglich standardisierte Funktionen, um herstellerspezifische Erweiterungen einzubinden. Manche Implementierungen, zum Beispiel FreeS/WAN in Linux, unterstützen leider nur eine manuelle, statische Konfiguration der privaten Client-IPAdresse. IPSec ist primär ein Sicherheitsprotokoll auf IP-Ebene; IP-Tunneling ist eine mögliche Option – die allerdings in VPNs fast immer eingesetzt wird. Die Sicherheitsfunktionen von IPSec sind in Kapitel 7 ausführlich beschrieben. Die Einkapselung der privaten IP-Pakete – IPSec kann nur IP-Pakete tunneln – erfolgt je nach Sicherheitsstufe durch einen IPSec-Header oder einen IPSecHeader und -Trailer. Ein Protokollfeld in den IPSec-Headern gibt an, welches Protokoll im IPSec-Paket eingekapselt ist. Dies sind im Tunnel-Modus ausschließlich IP-Pakete oder, falls es sich um den IPSec-Transport-Modus handelt, Pakete der Transportschicht (Layer 4), z.B. UDP oder TCP.
177
6 Tunneling-Technologien im Überblick
6.3.2
Layer 2 Tunneling Protocol (L2TP)
Das Layer 2 Tunneling Protocol wurde primär für den Einsatz im ProviderEnterprise-Modell entwickelt. Wie Sie in Abbildung 6.7 sehen, beginnt dabei der L2TP-Tunnel im Remote Access Concentrator (RAC) des Service Providers und endet in einem Gateway beim Kunden. Die Funktionalität der Tunnelendpunkte ist rollenbasierend, der Tunnel wird von einem LAC (L2TP Access Concentrator) aufgebaut, der im RAC des Providers implementiert ist. Das entgegengesetzte Ende des Tunnels bildet der LNS, der L2TP Network Server, der entweder auf Routern oder auf speziellen VPN-Gateways implementiert ist. L2TPLAC (RAC)
Client ISDN PSTN
Kunde
Carrier
PPP
Daten IP PPP L-1
L2TPLNS
Internet
Service Provider
Carrier
Kunde
L2TP-Tunnel
Daten IP PPP L2TP UDP IP L-2 L-1
Abbildung 6.7: L2TP im Provider-Enterprise-Modell
Der RAC des Service Providers erkennt an bestimmten Kennzeichen eines eingehenden Rufs (angerufene Nummer, Benutzer-ID usw.), ob es sich um eine Verbindung in das Netzwerk des Providers handelt oder ob die Verbindung zu einem Endkunden getunnelt werden soll. Dieses Verhalten nennt man auch zwangsweises Tunneling (Compulsory Tunneling), da der Client nicht selbst entscheiden kann, ob ein Tunnel aufgebaut wird oder nicht. Im ProviderEnterprise-Modell muss das Equipment beim Kunden eine L2TP-LNS-Funktionalität bieten. Das betreffende System muss aber nicht notwendigerweise dem Kunden gehören und muss auch nicht von ihm verwaltet werden – oft bieten die Service Provider komplette Lösungen an, inklusive VPN-Systemen, Konfiguration, Wartung und Betrieb. Leider sind in L2TP keinerlei Sicherheitsfunktionen wie Datenverschlüsselung oder Authentifizierung verfügbar.
178
Nicht standardisierte Protokolle
L2TPLAC ISDN PSTN
Kunde
L2TPLNS
POP
Carrier
Internet
Service Provider
Carrier
Kunde
L2TP-Tunnel Daten IP PPP L2TP UDP IP L-2 L-1
Abbildung 6.8: L2TP im Ende-zu-Ende-Modell
L2TP kann auch im Ende-zu-Ende-Modell eingesetzt werden. Zu diesem Zweck wird die LAC-Funktionalität vom Remote-Access-Konzentrator des Service Providers auf den Client verlagert. Dieser so genannte »Virtual LAC« auf dem Clientrechner baut den L2TP-Tunnel zum LNS auf, und die Carrier und Service Provider sind nicht mehr in das Tunneling involviert. Im Gegensatz zum zwangsweisen Tunneln, nennt man dies freiwilliges Tunneln (Voluntary Tunneling). Ein Beispiel für eine solche Funktionalität finden Sie bei Windows 2000 Professional, das als VPN-Protokoll auch L2TP als virtuellen LAC implementiert hat. Das Layer 2 Tunneling Protocol ist aufgrund seiner wachsenden Bedeutung in Kapitel 9 ausführlich beschrieben.
6.4
Nicht standardisierte Protokolle
Neben den standardisierten Tunneling-Protokollen gibt es eine ganze Reihe anderer Protokolle, die jedoch niemals in Form eines verbindlichen Standards das Licht der Welt erblickt haben. Manche dieser Protokolle wurden zwar in Standardisierungsprozesse eingebracht, haben diese aber niemals vollständig durchlaufen oder existieren nur als informeller Standard. Das Point-to-Point Tunneling Protocol (PPTP) oder Layer 2 Forwarding (L2F) sind Beispiele hierfür. Andere Protokolle sind proprietär und werden nur innerhalb der Produktlinien bestimmter Hersteller verwendet, wie zum Beispiel der Altavista Tunnel, der Bay Dial VPN Service (Bay-DVS) oder das Ascend Tunnel Management Protocol (ATMP). Manche dieser proprietären Protokolle schmücken sich zwar mit 179
6 Tunneling-Technologien im Überblick
RFC-Nummern, allerdings sind diese nur informeller Natur und repräsentieren keinen verbindlichen Internetstandard.
6.4.1
Layer 2 Forwarding (L2F)
Das Layer 2 Forwarding ist ein Layer-2-Tunneling-Protokoll, das hauptsächlich von der Firma Cisco zum Einsatz im Provider-Enterprise-Modell entwickelt wurde. Es gibt praktisch keine Client-Implementierungen, sondern nur Softwaremodule für Remote-Access-Konzentratoren und Router. L2F ist sehr eng mit L2TP verwandt, viele L2TP-Network-Server können auch als Endpunkt für einen L2F-Tunnel dienen. L2F bietet keine Sicherheitsdienste wie Datenverschlüsselung oder starke Authentifizierung, kann aber, wie auch L2TP und PPTP, verschiedene Netzwerkprotokolle tunneln.
6.4.2
Point-to-Point Tunneling Protocol (PPTP)
Das Point-to-Point Tunneling Protocol wurde von einer Reihe von Firmen entwickelt, die zu diesem Zweck das so genannte PPTP-Forum gründeten. Der Software-Riese Microsoft war, neben Unternehmen wie Ascend Communications, 3Com und anderen, maßgeblich an der Entwicklung beteiligt und hat seine PPTP-Clientsoftware in alle seine Betriebssysteme integriert bzw. für ältere Systeme wie Windows 95 Updates (Microsoft Dialup Networking Update 1.3) auf den Markt gebracht. PPTP kann sowohl als Basis für das Ende-zu-Ende-Modell dienen als auch durch Implementierungen in RemoteAccess-Konzentratoren im Provider-Enterprise-Modell eingesetzt werden. PPTP hat einen dem L2TP ähnlichen Aufbau. Für den Steuerungskanal verwendet PPTP jedoch das TCP-Protokoll. Als Layer-2-Protokoll kapselt PPTP PPP-Rahmen mit einem modifizierten GRE-Header ein. PPTP bietet auch einige Sicherheitsfunktionen wie Datenverschlüsselung (MPPE, Microsoft Point-to-Point Encryption) und Benutzer-Authentifizierung, die allerdings bei weitem nicht die Stärke von IPSec aufweisen. Insbesondere die Ableitung des Schlüssels, mit dem die Daten verschlüsselt werden, aus der Benutzer-Authentifizierung war in der Vergangenheit Zielscheibe einiger erfolgreicher Angriffe. Der Schlüssel des eingesetzten RC4-Protokolls ist zwar, je nach der Version von PPTP, entweder 40 oder 128 Bit lang – aber er wird aus einem Hashwert des Benutzer-Passworts erzeugt. Also muss ein Brute-Force-Angriff (vgl. Kapitel 4) nicht alle 240 oder 2128 möglichen Schlüssel testen, sondern braucht praktisch nur einen Wörterbuchangriff auf das Benutzer-Passwort durchzuführen. Microsoft hat mit einem Update auf die erfolgreichen Angriffe reagiert und eine neue, sicherere Authentifizierung namens MS-CHAPv2 implementiert. Aus Kompatibilitätsgründen kann das neue Verfahren beim Verbindungsaufbau jedoch durch die alte Version ersetzt werden, was eine nicht unbeträchtliche Angriffsfläche bietet. In jedem Fall basiert die 180
Verschachtelte Tunneling-Protokolle
Sicherheit der Verschlüsselung in PPTP auf der Sicherheit des Benutzer-Passworts – und das ist vielen Anwendern ein zu hohes Sicherheitsrisiko. Viele gute Sicherheitsstrategien legen darüber hinaus auch gewisse Verfahren und Richtlinien zur Schlüsselerzeugung und -Verwaltung fest, so dass der Einsatz von PPTP oft schon an dieser Hürde scheitert. Auch Microsoft verabschiedet sich langsam von seinem Problemprotokoll PPTP. Im neuen Windows 2000 werden verschiedene Tunneling-Protokolle – nach wie vor auch noch PPTP – angeboten, jedoch wird für neue Installationen die modernere und sicherere Variante L2TP/IPSec (siehe Kapitel 9) empfohlen. In Provider-Enterprise-Modellen setzen die Service Provider zunehmend auf L2TP, so dass auch hier PPTP immer weiter verdrängt wird.
6.5
Verschachtelte Tunneling-Protokolle
Manchmal bietet ein Tunneling-Protokoll allein nicht alle Funktionen, auf die man großen Wert legt. Die in diesem Kapitel besprochenen Layer-2-TunnelingProtokolle können verschiedene Netzwerkprotokolle wie IP, IPX usw. tunneln, zeichnen sich aber nicht gerade durch gute Sicherheitsfunktionen aus. IPSec auf der anderen Seite hat hervorragende Sicherheitsfunktionen, kann aber nur IP tunneln. Was liegt also näher, als zwei verschiedene Tunneling-Protokolle miteinander zu kombinieren. Das kann man auch tun, indem man Tunnel ineinander verschachtelt. Wie dies prinzipiell funktioniert, sehen Sie in Abbildung 6.9. Beim Verschachteln von Tunneln ist es wichtig, dass sich die Tunnel, wie Sie in der Abbildung sehen, nicht überlappen – die Tunnel müssen vollständig ineinander enthalten sein. Man kann grundsätzlich sowohl Protokolle gleichen als auch verschiedenen Typs ineinander verschachteln. Übertragungsstrecke Tunneling-Protokoll A Tunneling-Protokoll B
Daten L-3 L-2 L-1
Daten L-3 Header A
Daten L-3 Header A
Daten L-3 Header A
Daten L-3 Header A
L-3 L-2 L-1
L-3 Header B
L-3 Header B
L-3 L-2 L-1
L-3 L-2 L-1
L-3 L-2 L-1
Daten L-3 L-2 L-1
Abbildung 6.9: Tunneling-Protokolle können auch ineinander verschachtelt werden. 181
6 Tunneling-Technologien im Überblick
Tunneling-Protokoll A Tunneling-Protokoll B Übertragungsstrecke Abbildung 6.10: Dies geht nicht! Tunneling-Protokolle dürfen sich beim Verschachteln nicht überlappen.
Nehmen wir einmal als Beispiel aus der Praxis eine Remote-Access-VPN, um den Sinn und den Einsatz der Verschachtelung von Tunneling-Protokollen zu erläutern. IPSec ist ein Sicherheitsprotokoll, das man gern im Ende-zu-EndeModell einsetzt, um die gewünschte Sicherheitsfunktionalität möglichst auf der ganzen Übertragungsstrecke zwischen Client und VPN-Gateway zur Verfügung zu haben. Dabei gibt es aber möglicherweise ein Problem: Das Endezu-Ende-Modell bedeutet immer, dass der Client freiwillig tunnelt. Ein Benutzer könnte somit aber auf seinem Firmen-PC seinen Dialer manuell starten und sich zum ISP verbinden, ohne seinen IPSec-Client zu benutzen. Das kann unter Umständen von einer Sicherheitsstrategie verboten sein. Mit dem Provider-Enterprise-Modell, zum Beispiel mit L2TP als TunnelingProtokoll, wäre das nicht möglich, denn hier erfolgt ein zwangsweises Tunneling. Der Remote-Access-Konzentrator beim Service Provider kann z.B. aufgrund der angerufenen Nummer (also der Einwahlnummer des ISP, die der Dialer anrufen muss) entscheiden, ob und wohin ein Tunnel aufgebaut werden muss. Der Client kann dies nicht mehr beeinflussen. Allerdings ist L2TP kein Sicherheitsprotokoll. Die Lösung ist eine Verschachtelung von IPSec und L2TP. In Abbildung 6.11 sehen Sie, wie dies realisiert wird: IPSec wird im Ende-zu-Ende-Modell betrieben und garantiert so die geforderte Sicherheit. Mit L2TP im ProviderEnterprise-Modell wird garantiert, dass, sobald sich der Client beim Provider einwählt, er zwangsweise mit L2TP bis zum LNS im Kundennetzwerk getunnelt wird. Diese Lösung hat allerdings auch ihren Preis in Form eines zusätzlichen Protokoll-Overheads in den Datenpaketen. In diesem Zusammenhang fällt auch oft der Begriff »L2TP über IPSec« oder »IPSec secured L2TP« oder kurz »L2TP/IPSec«. Hierbei handelt es sich nicht um eine Verschachtelung von Tunneling-Protokollen, da IPSec hierbei nicht im Tunnel-, sondern im Transport-Modus arbeitet. Hier hat man die Vielfalt der Protokolle, die L2TP tunneln kann, mit der Sicherheit von IPSec kombiniert. L2TP wird dabei zum Tunneln benutzt, und die erzeugten UDP/IPPakete werden mit IPSec im Transport-Modus verschlüsselt und authentifiziert. Diese Kombination ist in Kapitel 9 ausführlich beschrieben. Sie wird auch von Windows 2000 unterstützt.
182
Welches Protokoll für welchen Zweck?
L2TPLAC
IPSecClient
ISDN PSTN
Kunde
Carrier
L2TPLNS
IPSecGateway
Internet
Service Provider
Carrier
Kunde
IPSec-Tunnel
L2TP-Tunnel
Daten IP IPSec IP PPP L-1
Daten IP IPSec IP PPP L2TP UDP IP L-2 L-1
Daten IP IPSec IP L-2 L-1
Abbildung 6.11: Eine Kombination von IPSec und L2TP
6.6
Welches Protokoll für welchen Zweck?
Diese Frage ist eigentlich gar nicht so kompliziert, da verschiedene Protokolle für bestimmte Funktionen von vornherein ausscheiden. Wenn Sie zum Beispiel IPX über ein IP-Netzwerk transportieren müssen, scheidet IPSec an diesem Punkt bereits aus. Die Gegenüberstellung im folgenden Abschnitt soll die Protokolle nicht wertend miteinander vergleichen, denn sie wurden teilweise mit völlig unterschiedlichen Zielsetzungen und Einsatzszenarien entwickelt.
6.6.1
Gegenüberstellung
In Tabelle 6.1 sind die vier wichtigsten Tunneling-Protokolle – IPSec, L2TP, PPTP und L2F – gegenübergestellt. Hier soll aber wie gesagt kein Vergleich im Sinne von gut oder schlecht stattfinden, sondern ein Vergleich der wichtigsten Funktionen der Protokolle. Hier können Sie anhand eines Pflichtenhefts oder Anforderungskatalogs schnell ein geeignetes Protokoll finden – oder eine Kombination von zwei Protokollen.
183
6 Tunneling-Technologien im Überblick
IPSec
L2TP
PPTP
L2F
Protokolltyp
Layer 3
Layer 2
Layer 2
Layer 2
Standardisiert (RFC)
Ja
Ja
Nein
Nein
Paket-Authentifizierung
Ja
Nein
Nein
Nein
Benutzer-Authentifizierung
Ja
Ja
Ja
Ja
Datenverschlüsselung
Ja
Nein
Ja
Nein
Schlüsselmanagement
Ja
Nein
Nein
Nein
QoS-Signalisierung
Ja
Nein
Nein
Nein
IP-Tunneling
Ja
Ja
Ja
Ja
IPX-Tunneling
Nein
Ja
Ja
Ja
Primäres Modell
Ende-zuEnde
ProviderEnterprise
Ende-zuEnde
ProviderEnterprise
Tab. 6.1: Ein Vergleich verbreiteter Tunneling-Protokolle
6.6.2
Auswahlkriterien
Mit der Auswahl eines oder mehrerer Tunneling-Protokolle treffen Sie eine wichtige Entscheidung während der Planung des VPNs. In heutigen, modernen Netzwerken ist man bestrebt, möglichst auf Standards oder wenigstens auf De-facto-Standards zu setzen. Aus diesem Grund reduziert sich die Menge der zur Auswahl stehenden Tunneling-Protokolle ganz erheblich: Es bleiben die in Tabelle 6.1 beschriebenen Verfahren, aus denen man ein geeignetes Protokoll auswählen sollte. Leider gibt es dafür keine allgemeingültige Checkliste oder eine Art VPN-Kochbuch, denn es spielen einfach zu viele unternehmensspezifische Planungs- und Entscheidungskriterien eine Rolle. Die wichtigsten Faktoren sind dabei: 왘 Die Netzwerkprotokolle, die übertragen werden müssen 왘 Die Sicherheitsstrategie des Unternehmens 왘 Die eingesetzten Applikationen 왘 Benötigte Client-Unterstützung (Betriebssysteme) 왘 Der VPN-Typ 왘 Kompatibilitätsanforderungen
Die Netzwerkprotokolle, die übertragen werden müssen Dieser Faktor ist neben der Sicherheitsstrategie der am meisten ausschlaggebende. Unter Umständen sollten Sie auch Ihre mittel- und langfristige Netzwerkstrategie zu Rate ziehen, ob nicht vielleicht eine Protokoll-Konsolidie-
184
Welches Protokoll für welchen Zweck?
rung stattfinden soll – und nur noch IP übrig bleibt. Diese Tendenz ist im Augenblick bei fast allen Unternehmen zu beobachten; bei etlichen ist dieser Prozess auch schon abgeschlossen. Ein VPN ist in diesem Zusammenhang möglicherweise ein guter Punkt, um mit dieser Konsolidierung zu beginnen und nur noch IP zu tunneln. Jetzt werden Sie vielleicht einwenden, dass diese Überlegung nichts gebracht hat, denn alle vier Protokolle tunneln IP. Das ist richtig, aber es bleiben mehr Alternativen, um die nachfolgenden Kriterien erfüllen zu können. Die Sicherheitsstrategie des Unternehmens Die Netzwerkabteilung eines Unternehmens ist in der Regel dafür verantwortlich, die Sicherheitsstrategie des Unternehmens im Netzwerkbereich zu implementieren. Im Fall von Internet-VPNs entstehen dadurch oft ganz bestimmte Anforderungen an die Sicherheitsdienste, die ein geeignetes Tunneling-Protokoll zur Verfügung stellen muss. An diesem Punkt scheiden schon Protokolle wie L2F und L2TP aus, es sei denn, sie werden mit entsprechenden Sicherheitsprotokollen kombiniert. Wenn die Anforderungen an die Sicherheit der Datenübertragung sehr hoch sind, bleibt praktisch keine Alternative zu IPSec. Müssen unbedingt auch andere Netzwerkprotokolle als IP getunnelt werden, kann man L2TP/IPSec verwenden. Die eingesetzten Applikationen Hier ist nicht von Interesse, welche Applikationen benutzt werden, sondern welche Anforderungen an Verzögerungszeiten und Bandbreite sie stellen. Es ist auch von Interesse, ob im privaten Netzwerk bereits Quality-of-ServiceDienste auf IP-Ebene eingesetzt werden und ob diese Informationen an den Service Provider gesendet werden sollen. Hier spielt in gewissem Maße auch schon die Auswahl der VPN-Systeme mit hinein, auf die Kapitel 11 näher eingegangen wird. Benötigte Client-Unterstützung (Betriebssysteme) Wenn, zum Beispiel in einem Remote-Access-VPN, ein Ende-zu-Ende-Modell eingesetzt wird, müssen für das entsprechende Betriebssystem auch ClientImplementierungen des auszuwählenden Tunneling-Protokolls existieren. Dies dürfte für L2F schon das Aus sein; hier muss man sich zwischen den restlichen drei Protokollen entscheiden. Der VPN-Typ Natürlich ist es auch wichtig, welcher VPN-Typ zum Einsatz kommt, ob man also ein Remote-Access-, ein Branch-Office- oder ein Extranet-VPN aufbauen will – oder beliebige Kombinationen davon. Die Tunneling-Protokolle haben ihre spezifischen Schwerpunkte und sind für bestimmte Einsatzszenarien
185
6 Tunneling-Technologien im Überblick
nicht geeignet. So bieteten nur ganz wenige Service Provider im Augenblick ein Provider-Enterprise-Modell mit zwangsweisem Tunneling mit IPSec an. Und Branch-Office-VPNs mit L2F fallen auch unter die Rubrik exotisch. Kompatibilitätsanforderungen Insbesondere wenn das VPN auch Extranet-Dienste zur Verfügung stellen muss, ist die Kompatibilität ein ganz wesentliches Entscheidungskriterium. Denn dann muss ein Tunneling-Protokoll eingesetzt werden, das die Organisationen, die angebunden werden sollen, auch benutzen. Natürlich muss nicht notwendigerweise nur ein einziges Tunneling-Protokoll im VPN eingesetzt werden. Falls man aus bestimmten Gründen zum Beispiel sein VPN mit PPTP aufbaut, die externen Extranet-Systeme aber IPSec einsetzen, kann man für diesen genau abzugrenzenden Bereich auch IPSec einsetzen. Falls die Forderung nach Kompatibilität jedoch einer grundsätzlichen Strategie des Unternehmens entspringt – mit dem Ziel, eine möglichst hohe Interoperabilität und Herstellerunabhängigkeit zu erzielen –, sollte man standardisierte Protokolle wie IPSec oder L2TP einsetzen.
186
7
Das IP-Security-Protokoll (IPSec)
Wenn Sie schon einmal mit einem Protokollanalysator IPSec-Pakete aufgezeichnet und analysiert haben, werden Sie sich mit Sicherheit darüber gewundert haben, dass in Ihrem Netz plötzlich IP Version 6 läuft, obwohl dieses Protokoll auf keinem einzigen Ihrer Systeme installiert ist. Denn genau das zeigen die Analysatoren in der Regel an, obwohl es sich in Wirklichkeit um normale »alte« IP-Version-4-Pakete handelt. Um dies zu erklären, muss man um einige Jahre zu dem Zeitpunkt zurückgehen, an dem sich einige Leute daran gemacht hatten, ein neues IP-Protokoll zu spezifizieren, das IPng (IP next generation) oder aufgrund der Protokollnummer IP Version 6 genannt wird. Der Anlass dazu war hauptsächlich die Tatsache, dass irgendwann der durch die 4-Byte-Limitierung begrenzte IPAdressraum nicht mehr ausreichen würde. Außerdem sollte das Protokoll flexibler ausgelegt sein und schon im ursprünglichen Standard Dinge wie Quality-of-Service und Sicherheit unterstützen. Vor allem auch die Header-Struktur der Pakete sollte flexibler ausgelegt werden, um spätere Erweiterungen einfacher in das Protokoll zu implementieren. Leider hat IP in der Version 6, die inkompatibel zur Version 4 ist, bis heute keine nennenswerte Verbreitung gefunden. Die Gründe dafür sind recht vielschichtig: Eine Umstellung bringt bei der heutigen Verbreitung des IP-Protokolls einiges an Aufwand mit sich, beide Protokolle müssen auf vielen Systemen koexistieren, und vor allem gibt es gibt nach wie vor noch IP-Adressen. Denn die ursprüngliche Annahme, dass die Adressen schon seit Jahren ausgegangen sein müssten, ging davon aus, dass jedes IP-System auch eine offiziell registrierte und somit weltweit einmalige Addresse zugewiesen bekommt. Aber viele Unternehmen und Organisationen betreiben Netze mit nicht registrierten Adressen und setzen am Übergangspunkt zu öffentlichen IP-Netzen Verfahren wie NAT (Network Address Translation) ein, die ihre privaten Adressen dynamisch in offizielle umsetzen. Solche Systeme haben meist einen Satz von einigen hundert offiziellen Addressen (Address-Pools), die auf einige zigtausend private Adressen umgesetzt werden. Vielfach werden auch Rechneradressen nicht mehr statisch vergeben, sondern dynamisch, ebenso wie Internet Service Provider Adressen für ihre Kunden dynamisch aus Adress-Pools vergeben. Kurzum: Anstatt auf IP Version 6 umzusteigen, hat man bisher auf einen sparsamen Umgang mit IP-Adressen gesetzt. Diese Entwicklung wird zwar demnächst ein Ende haben, wenn durch die Einführung von UMTS, IP-Telefonie und einer ganzen Reihe neuer IP-basierender Dienste eine riesige Zahl von IP-Adressen benötigt wird. Spätestens
187
7 Das IP-Security-Protokoll (IPSec)
wenn jeder neue Kühlschrank per SNMP gesteuert wird und jedermann über das IP-Protokoll telefoniert, benötigt man allein wegen des viel größeren Adressraums IP Version 6. Allerdings wird bis dahin noch einige Zeit vergehen, und die heutigen sowie die in den nächsten Jahren zu installierenden VPNs werden noch auf dem IP-Protokoll der Version 4 basieren. Aber durch die Verschleppung des neuen IP-Protokolls wurden auch die wichtigen Erweiterungen in IP Version 6 wie Qualtity-of-Service und Sicherheit nicht verfügbar. Also hat sich die IETF daran gemacht, diese Funktionalitäten auf IP Version 4 zu portieren. Praktisch alle Funktionen von IPSec stammen aus der Entwicklung von IP Version 6, man hat sogar die Protokollnummern beibehalten und verwirrt dadurch, wie eingangs beschrieben, auch moderne Protokollanalysatoren. Die Standards, die IPSec spezifizieren, beschreiben generell beide IP-Versionen: Alle Parameter wie Protokollnummer, Formate usw. sind gleich, lediglich die Paketformate sind unterschiedlich. In den RFCs werden die Unterschiede zwischen IP Version 4 und Version 6 explizit angesprochen, so dass hier keine Verwechslungen möglich sind.
7.1
IP Security im Überblick
IP Security bietet einen weit reichenden Schutz von IP-Datagrammen. Insbesondere werden folgende Bereiche abdeckt: 왘 Paketintegrität 왘 Paketauthentifizierung 왘 Paketvertraulichkeit 왘 Verkehrsflussvertraulichkeit 왘 Schutz vor Replay-Angriffen 왘 Schutz vor weiteren Denial-of-Service-Angriffen
7.1.1
Paketintegrität
IPSec schreibt bestimmte Verfahren vor, mit denen die Paketintegrität, also der Schutz vor unerlaubter Veränderung der Pakete auf dem Transport, gewährleistet werden kann. Diese Funktionalität ist ein Muss, es gibt nur eine einzige Ausnahme, bei der diese Funktionalität nicht durch spezielle Funktionen sichergestellt werden muss, sondern bei der andere Dienste diesen Schutz mit zur Verfügung stellen. Diese Ausnahme liegt bei einer Verschlüsselung der Daten vor, denn dann kann eine wirkungsvolle Änderung, also ein Angriff, nur erfolgen, wenn der Angreifer den Schlüssel kennt, was aber in IPSec praktisch unmöglich ist (vgl. Kapitel 8, IKE).
188
IP Security im Überblick
Die Paketintegrität wird sichergestellt, indem in das IPSec-Paket ein so genannter Hash-based Message Authentication Code (HMAC) eingefügt wird. Dabei handelt sich um einen krpytographisch durch einen symmetrischen Schlüssel abgesicherten Hashwert, der über das zu versendende IP-Paket gebildet wird. Die korrekte Berechnung des HMAC ist nur dem Sender und dem Empfänger des Pakets möglich, da nur diese über den notwendigen Schlüssel verfügen.
7.1.2
Paketauthentifizierung
Die Paketauthentifizierung, also die Gewährleistung, dass das Paket auch vom authentischen Absender und niemand anderem kommt, der sich mit gefälschten Absenderadressen in die Kommunikation einklinkt, ist praktisch ein Abfallprodukt der Paketintegritätsprüfung. Denn diese bildet ihren HMAC unter anderem aus einem symmetrischen Schlüssel, der ausschließlich dem Sender und Empfänger, oder genauer formuliert, dem Initiator und Responder der IPSec-Sicherheitsassoziation (SA), bekannt ist. Wenn der Empfänger eines IPSec-Pakets den HMAC überprüft und keine Änderungen festgestellt hat, dann sind zwei Dinge sichergestellt: Erstens wurde das Paket auf dem Transport nicht verändert, und zweitens kommt das Paket auch definitiv vom anderen Partner der SA, denn außer dem Empfänger selbst kennt nur noch dieser den symmetrischen Schlüssel, der zur HMAC-Berechnung benötigt wird.
7.1.3
Paketvertraulichkeit
Die Vertraulichkeit der Daten oder – im Falle von IPSec im Tunnelmodus – der vollständigen, privaten IP-Pakete wird durch deren Verschlüsselung erreicht. Die Verschlüsselung der Daten kann auch benutzt werden, um die Paketintegrität und die Paketauthentizität in gewissem Maße sicherzustellen. Denn die in IPSec eingesetzten Algorithmen sind symmetrische Verfahren, deren Sicherheit zusammen mit anderen Faktoren darauf basiert, dass der Schlüssel nur dem Sender und dem Empfänger bekannt ist. Ein verschlüsseltes Paket ändern kann somit auch nur jemand, der den Schlüssel ebenfalls kennt, was man durch den Einsatz des IKE-Protokolls zum Erzeugen der notwendigen Schlüssel wirkungsvoll verhindern kann.
7.1.4
Verkehrsflussvertraulichkeit
IPSec kann man in zwei verschiedenen Modi betreiben, dem TransportModus und dem Tunnel-Modus. Letzterer kapselt ein privates IP-Paket in den Datenbereich eines neu erzeugten IP-Pakets ein. Sobald dieser Datenbereich verschlüsselt wird, kann sich ein Angreifer, der das neue Paket auf dem Transport mitliest, keine Informationen mehr über Verkehrsbeziehungen im priva-
189
7 Das IP-Security-Protokoll (IPSec)
ten Netzwerk verschaffen. Denn das komplette private Paket, inklusive Adressen, Protokollnummern usw. ist verschlüsselt. Die einzige Information, die ein Angreifer ermitteln kann, ist die Gesamtmenge an Paketen, die zwischen IPSec-Gateways oder -Hosts verschickt werden.
7.1.5
Schutz vor wiederholtem Senden von Paketen (Replay-Angriff)
Ein Replay-Angriff ist eine Art von Angriff, mit der ein Angreifer trotz Schutzmechanismen wie Integritätsprüfung, Authentifizierung und zusätzlicher Datenverschlüsselung seine Pakete in eine IPSec-Verbindung einschleusen und den Empfänger zu umfangreichen, ressourcenintensiven, aber völlig sinnlosen Berechnungen veranlassen kann. Die Sinnlosigkeit würde aber erst von der Applikation erkannt, die das private IP-Paket anschließend weiterverarbeitet. Der Trick des Angreifers besteht einfach darin, dass er IPSecPakete aufzeichnet und diese nochmals zum Empfänger schickt. Dieser verarbeitet das Paket auch ganz normal, denn es ist mit einem korrekten HMAC versehen, lässt sich entschlüsseln und sieht von der Sicherheitsseite aus betrachtet normal aus. Wenn nun eine ausreichend große Anzahl von solchen Pakten wiederholt zum Empfänger geschickt wird, muss er erhebliche Ressourcen für die kryptographische Verarbeitung aufwenden, die ihm dann für die Verarbeitung ordnungsgemäßer Pakete schließlich fehlen. Um sich vor derartigen Angriffen zu schützen, wurden in IPSec spezielle Maßnahmen eingeführt. IP Security überprüft hierbei optional durch einen Anti-Replay Service (ARS) jedes eingehende Paket zu allererst daraufhin, ob es schon einmal angekommen ist.
7.1.6
Schutz vor weiteren Denial-of-Service-Angriffen
Es gibt mittlerweile eine Reihe teilweise recht ausgeklügelter Denial-of-Service-Angriffe, also Attacken, die darauf abzielen, ein Gerät in einen Zustand zu versetzen, in dem es seine ursprünglichen Aufgaben nicht oder nur noch in unzureichendem Maße ausführen kann. Solche Angriffe zielen oft auf den TCP-Stack ab oder versuchen, rechenintensive Funktionen in einem System anzustoßen. Einen Schutz hiervor kann man erreichen, indem man auf viele Funktionen eines normalen IP-Stacks verzichtet und einen so genannten gehärteten Stack implementiert. Dies ist allerdings nur bei dedizierten VPNGateways möglich, die beispielsweise auf ihrem öffentlichen Interface ausschließlich Tunneling-Protokolle wie IPSec und L2TP terminieren. Ein gehärteter Stack ist so programmiert, dass er nur die Protokolle 50 (IPSec ESP), 51 (IPSec AH) und 17 (UDP) mit den Portnummern 500 in die Schicht 3 durchlässt. Eine TCP-Verarbeitung gibt es auf dieser Ebene nicht, dadurch fallen schon eine ganze Reihe möglicher Angriffe weg. Die IPSec-Protokolle selbst
190
Kryptographische Verfahren in IPSec
haben bereits eine ganze Reihe eingebauter Schutzmechanismen, ebenso das IKE-Protokoll, das mit UDP-Paketen der Portnummer 500 arbeitet. Alle anderen Pakete werden bereits vor der Ebene 3 ohne weitere Meldung (silent discard) verworfen und können keinen weiteren Schaden mehr anrichten.
7.2
Kryptographische Verfahren in IPSec
Diese ganzen Anforderungen an die Sicherheit der Datenübertragung bedingen, dass eine Reihe von kryptographischen Verfahren eingesetzt wird, flankiert von gewissen Richtlinien zur Implementierung in IPSec, um die verschiedenen möglichen Angriffe abzuwehren.
7.2.1
Datenverschlüsselung in IPSec
Die Datenverschlüsselung in IPSec wird mit symmetrischen Verfahren (vgl. Kapitel 4) durchgeführt, die im Cipher-Block-Chaining-Modus (CBC) mit explizitem Initialisierungsvektor (IV) betrieben werden. DES, der Data Encryption Standard, ist als Algorithmus zwingend von jeder Implementation zu unterstützen, andere Verfahren wie Triple-DES, IDEA, Cast, Blowfish, RC5 usw. können optional implementiert werden. Alle diese symmetrischen Verfahren bedingen, dass in jedem Endpunkt einer IPSec-Verbindung (Sicherheitsassoziation) die gleichen, ausreichend langen Schlüssel vorliegen. Wie diese Schlüssel dorthin gelangen, wird in Kapitel 8 näher beschrieben. Wichtig zu wissen ist an dieser Stelle, dass diese Schlüssel vor dem Einsatz des IPSec-ESP-Protokolls, das die Datenverschlüsselung implementiert, den beiden Kommunikationspartnern zur Verfügung stehen müssen. Je nach Algorithmus werden Schlüssel verschiedener Länge benutzt. Die am häufigsten in IP Security eingesetzten Algorithmen zur Verschlüsselung und die von diesen verwendeten Schlüssellängen sind: 왘 DES, mit einem 56 Bit langen Schlüssel 왘 Triple-DES, das einen aus drei 56-Bit-Teilschlüsseln bestehenden 168-Bit-
Schlüssel benötigt 왘 IDEA benutzt einen 128 Bit langen Schlüssel 왘 Blowfish arbeitet mit einen 448 Bit großen Schlüssel
Der Einsatz dieser Verfahren, die in der Regel monoalphabetisch sind, muss im CBC-Modus erfolgen. Der Initialisierungsvektor für diese Betriebsart wird in jedem Paket mit übertragen und dem Chiffretext unmittelbar vorangestellt. In Abbildung 7.1 ist eine Verschlüsselung mit dem DES-Algorithmus in IPSec schematisch dargestellt. Man kann hier auch erkennen, wie die Verschlüsse-
191
7 Das IP-Security-Protokoll (IPSec)
lung die Paketgröße verändert, da der Initialisierungsvektor und eventuell notwendige Füllzeichen (Padding) in das Paket mit aufgenommen werden müssen. In diesem Fall, einem zugegebenermaßen sehr ungünstig konstruierten, werden die 25 Byte Originaldaten auf 40 Byte vergrößert, also um mehr als 60%. Klartextdaten, 25 Byte
PaddingGenerator
Zufallsgenerator
RND
8 Byte
8 Byte
8 Byte
1 7 Byte
DES
DES
DES
DES
8 Byte
8 Byte
8 Byte
8 Byte
IV, 8 Byte
IV, 8 Byte
8 Byte
8 Byte
8 Byte
8 Byte
40 Byte
Abbildung 7.1: IPSec-Datenverschlüsselung mit Triple-DES-CBC und explizitem Initialisierungsvektor (IV)
Der Initialisierungsvektor sollte zufälligen Ursprungs sein und möglichst nicht aus dem verwendeten Schlüssel des Verschlüsselungsprogramms abgeleitet werden. Er kann ungesichert übertragen werden und wird dem Chiffretext in einem IPSec-ESP-Paket direkt vorangestellt. Für nachfolgende Pakete kann der letzte Chiffretextblock als IV verwendet werden. Im vorliegenden Beispiel ist weiterhin zu sehen, wie der Klartext in für den jeweiligen Chiffrieralgorithmus passende Teile zerlegt wird. Im Fall von DES oder auch Triple-DES müssen diese Blöcke genau 64 Bit groß sein. Falls, wie in Abbildung 7.1, der letzte Block keine 64 Bit (8 Byte) lang ist, muss er mit Füllzeichen auf die erforderliche Länge aufgefüllt werden. Da das DES-Verfahren als mittlerweile nicht mehr ausreichend angesehen wird, um sensible Daten zu schützen, bieten praktisch alle für dieses Buch untersuchten IPSec-Implementierungen auch Triple-DES als optionalen Algorithmus an, manche Systeme sogar zusätzlich noch Blowfish oder IDEA.
192
Kryptographische Verfahren in IPSec
7.2.2
Integritätsprüfung und Authentifizierung in IPSec
Zum Schutz der Datenintegrität und zur Authentifizierung greift man auf Hash-Algorithmen zurück, die in entsprechenden Betriebsarten sicher vor so genannten Kollisionen sind. Die in IPSec vorgeschriebenen Verfahren sind HMAC-MD5-96 und HMAC-SHA1-96, also Algorithmen, die auf den bekannten Hashfunktionen MD5 und SHA1 aufsetzen. Die Funktionsweise dieser Verfahren ist in Kapitel 4 beschrieben. Diese Verfahren arbeiten ebenfalls mit einem symmetrischen, 128 Bit langen Schlüssel, der ausschließlich den beiden Kommunikationsendpunkten bekannt sein darf. Dieser Schlüssel wird ebenfalls vom IKE-Protokoll generiert und muss vorhanden sein, sobald IPSec-Pakete übertragen werden. In Abbildung 7.2 ist die generelle Funktion innerhalb IPSec skizziert, wobei die Position des ICV (Integrity Check Value) im ausgehenden Paket vom jeweiligen IPSec-Protokoll abhängig ist. Es hängt auch vom jeweiligen Protokoll ab, welche Bereiche des Pakets gesichert werden. Näheres dazu ist in den Kapiteln zum AH- und ESP-Protokoll zu finden. Zu sicherndeDaten
128-Bit-Schlüssel
HMACMD5-96
ICV, 96 Bit
Zu sicherndeDaten
Abbildung 7.2: In IPSec kann man HMAC-MD5-96 zur Authentifizierung und Integritätsprüfung von Datenpaketen einsetzen.
Die Hashverfahren werden nicht direkt eingesetzt, sondern arbeiten im HMAC-Modus, der die Verfahren sicher vor so genannten Kollisionen macht. Eine Kollision liegt dann vor, wenn zwei verschiedene Eingabewerte den gleichen Hashwert erzeugen. Für das MD5-Verfahren hat man bereits Kollisionen demonstriert, jedoch waren diese eher akademischer Natur. Es gibt zum jetzigen Zeitpunkt keine bekannte mathematische Methode, solche Werte zu berechnen, die einen gleichen Hashwert produzieren, insbesondere dann nicht, wenn sich diese Werte ähneln sollen und gleich lang sein müssen. Nichtsdestoweniger hat man das Kollisionsproblem in Fachkreisen zur Kenntnis genommen und lässt als Schutzmaßnahme dagegen die Hashver-
193
7 Das IP-Security-Protokoll (IPSec)
fahren generell im HMAC-Modus arbeiten; aus dem MD5-Verfahren wird z.B. HMAC-MD5-96. Die Zahl 96 bedeutet, dass der Hashwert auf 96 Bit verkürzt wird, indem man die niederwertigen 32 Bit aus dem Wert entfernt. In den RFCs 2403 und 2404 sind die Benutzung der Hash-based Message Authentication Codes auf Basis von SHA1 und MD5 spezifiziert, das HMACVerfahren selbst ist im RFC2104 beschrieben. IPSec erlaubt auch die optionale Verwendung anderer Verfahren zur Integritätssicherung, jedoch sind in heutigen Implementierungen fast ausschließlich HMAC-MD5-96 und HMAC-SHA1-96 zu finden.
7.2.3
Schutz vor Replay-Angriffen
Der Schutz vor wiederholtem Senden von Paketen (Replay-Angriff) wird in IPSec durch den ARS (Anti-Replay Service) gewährleistet. Zu diesem Zweck ist in jedem IPSec-Paket, egal mit welchem Protokoll es erzeugt wurde, ein 32 Bit großes Feld enthalten, in dem eine monoton steigende Sequenznummer enthalten ist. Sobald eine IPSec-Sicherheitsassoziation aufgebaut wird, wird dieser Zähler mit 0 initialisiert. Obwohl der ARS in IPSec optional ist, wird in ausgehenden Paketen der Zähler immer um eins erhöht. Falls auf ARS verzichtet wird, betrifft dies nur den Empfänger, er wertet das Feld in diesem Fall einfach nicht aus. Da die Pakete aufgrund der Wegefindung in IP-Netzen nicht in der Reihenfolge ankommen müssen, in der sie abgeschickt wurden, reicht es nicht aus, im Empfänger zu prüfen, ob die Sequenznummer des ankommenden Pakets um eins höher ist als die des vorhergehenden Pakets der entsprechenden Sicherheitsassoziation. Statt dessen verwaltet der Empfänger ein so genanntes Empfangsfenster. Dieses Fenster ist meist 64 Bit, mindestens jedoch 32 Bit groß. Pakete, die innerhalb dieses Fensters ankommen, werden verarbeitet. Pakete, die links davon liegen, sind entweder schon einmal eingetroffen oder kommen schlicht zu spät an und werden verworfen. Falls ein Paket eintrifft, das rechts vom aktuellen Fenster liegt, wird es der IPSec-Integritätsprüfung unterworfen. Falls es diese besteht – und nur dann –, wird das Fenster so weit verschoben, bis das Paket an der rechten Grenze des Fensters steht. In Abbildung 7.3 wird die Funktionsweise an einem 32 Bit breiten ARS-Fenster demonstriert. Das linke Element im Fenster hat den Wert N, wobei N dem Wert des Sequenzzählers des Pakets entspricht, das an dieser Stelle angekommen ist. Das Paket mit der Sequenznummer N-6 fällt nicht in das Fenster, sondern liegt links davon. Dies bedeutet, dass das Paket entweder zu spät eintrifft oder bereits schon einmal eingetroffen ist, also wird es verworfen. Das Paket N+7 liegt zwar im Bereich des Fensters, ist aber schon einmal angekommen und wird somit auch verworfen. Das Paket N+21 liegt im Fenster, ist auch noch nicht vorher angekommen und kann demnach verarbeitet werden.
194
Kryptographische Verfahren in IPSec
Das Paket N+40 hingegen liegt rechts des Fensterbereichs. Es wird auf Integrität und Authentizität geprüft, und falls diese Prüfung erfolgreich war, wird das Fenster so weit nach rechts verschoben, bis das neue Paket darin erscheint. Paketfluss Fenstergröße=32 Anti-Replay Window
N Paket N-6
Paket N+7
Paket N+21
Paket N+40
Paketauthentifizierung Paketintegritätsprüfung
Anti-Replay Window
N
Fensterwirdumacht Positionenverschoben
Abbildung 7.3: Der IPSec-Anti-Replay-Service (ARS)
An dieser Stelle vielleicht ein Tipp zur Konfiguration von IPSec-Sicherheitsassoziationen: Viele Implementierungen bieten die vom Standard ausdrücklich zugelassene Möglichkeit an, beim Einsatz der Verschlüsselung im ESP-Protokoll auf die explizite Prüfung der Integrität und Authentizität durch HMACMD5-96 oder HMAC-SHA1-96 zu verzichten. In diesem Fall besteht aber leider die Möglichkeit, dass bestimmte Denial-of-Service-Angriffe trotz aktivem ARS ausgeführt werden. Denn wenn ein Angreifer den Verkehr mitliest und ständig selbst Pakete mit der aufgezeichneten verschlüsselten Nutzlast erzeugt, deren Sequenznummern sehr weit rechts außerhalb des Fensters liegen, passieren folgende zwei fatalen Dinge: Erstens wird das Fenster sehr weit nach rechts verschoben, so dass die ordnungsgemäß eintreffenden Pakete links außerhalb des Empfangsbereichs liegen und daher verworfen werden. Zweitens werden ausgerechnet die gefälschten Pakete weiterverarbeitet und durchlaufen die rechenintensive Entschlüsselung. IPSec selbst kann nicht mehr erkennen, dass es sich um unzulässige Pakete handelt, das können nur noch die höheren Anwendungsschichten, also UDP, TCP oder IP, falls es sich um IPSec im Tunnelmodus handelt. Erst diese Protokolle stellen dann fest, dass bei der Entschlüsselung der Pakete ein ziemlicher Unsinn her-
195
7 Das IP-Security-Protokoll (IPSec)
ausgekommen ist, da die Daten bereits schon einmal angekommen sind. Bis zu diesem Punkt wurde aber schon einiges an Ressourcen aufgewendet, die an anderer Stelle fehlen. Man sollte also in jedem Fall die explizite Paketintegritätsprüfung und Paketauthentifizierung benutzen, auch bei der Verschlüsselung der Daten. Die verwendeten Algorithmen und Systeme sind mittlerweile recht schnell, so dass hierdurch keine nennenswerten Leistungseinbußen entstehen.
7.3
Die IPSec-Standardisierung
Die Standardisierung von IPSec ist recht weit fortgeschritten. In den RFCs 2401 bis 2412 und einigen anderen, darin angesprochenen Dokumenten ist alles Wissenswerte über IP Security nachzulesen.
7.3.1
Die IPSec-Architektur
Die Architektur von IPSec ist in einer Reihe von RFCs zusammengefasst, die im folgenden Kapitel beschrieben sind. Die IPSec-Architektur selbst können Sie als Übersicht in Abbildung 7.4 sehen. Architektur
AH
ESP
Verschlüsselungsalgorithmus
Authentifizierungsalgorithmus
IPSec Domain of Interpretation (DOI) Schlüsselverwaltung
Anwendungsstrategie Abbildung 7.4: Die Architektur von IP Security
196
Die IPSec-Standardisierung
Ausgehend von dieser Architektur und den jeweiligen Anwendungsstrategien, ergeben sich folgende typische Kombinationen von IPSec-Diensten: 왘 ESP mit Verschlüsselung, Integritätsprüfung, Authentifizierung und ARS 왘 ESP mit Verschlüsselung, Integritätsprüfung und Authentifizierung 왘 ESP mit Verschlüsselung und ARS 왘 ESP mit Verschlüsselung 왘 ESP mit Integritätsprüfung, Authentifizierung und ARS 왘 ESP mit Integritätsprüfung und Authentifizierung 왘 AH mit Integritätsprüfung, Authentifizierung und ARS 왘 AH mit Integritätsprüfung und Authentifizierung
Weiter differenzieren kann man dies noch durch die verschiedenen Algorithmen, die für die verschiedenen Dienste zur Verfügung stehen. Im Bereich des Schlüsselmanagements kann die Anwendungsstrategie festlegen, wie dieses zu erfolgen hat und auf welche Art sich die Kommunikationspartner gegenseitig authentifizieren. Diesem Teil, dem Internet Key Exchange (IKE), ist Kapitel 8 gewidmet.
7.3.2
Die aktuelle IPSec-Standardisierung
IPSec ist sowohl für IP Version 4 als auch für Version 6 in einer Reihe von RFCs standardisiert. Die folgende Aufzählung ist nicht vollständig, es werden nur die wichtigsten Dokumente beschrieben, die für das Verständnis von IP Security notwendig sind. RFC 2401: Security Architecture for the Internet Protocol Dieses Dokument beschreibt die Basisarchitektur von IPSec-Systemen. Es werden verschiedene Sicherheitsdienste für den Datenverkehr auf IP-Ebene festgelegt. Das Zusammenspiel der unterschiedlichen Komponenten, die ein IPSec-System ausmachen, wird ebenso festgelegt wie die Implementierung einer Sicherheitspolitik auf Netzwerkebene und das Konzept der Sicherheitsassoziation. RFC 2402: IP Authentication Header Dieser RFC erläutert, wie die Integrität und Authentizität von IP-Datagrammen durch Einsatz von entsprechenden Algorithmen sicherzustellen ist. Weiterhin wird der Schutz gegen so genannte Replay-Angriffe beschrieben.
197
7 Das IP-Security-Protokoll (IPSec)
RFC 2403: The Use of HMAC-MD5-96 within ESP and AH In diesem Papier wird festgelegt, wie der MD5-Algorithmus in Verbindung mit dem HMAC-Verfahren in den IPSec-Protokollen ESP und AH zur Integritätsprüfung und Authentifizierung eingesetzt wird. RFC 2404: The Use of HMAC-SHA-1-96 within ESP and AH Dieses Dokument beschreibt, wie der MD5-Algorithmus in Verbindung mit dem HMAC-Verfahren in den IPSec-Protokollen ESP und AH zur Integritätsprüfung und Authentifizierung verwendet wird. RFC 2405: The ESP DES-CBC Cipher Algorithm with explicit IV Dieser Request for Comments legt fest, wie der DES-Algorithmus zum Verund Entschlüsseln von Datagrammen im Cipher-Block-Chaining-Modus (CBC) einzusetzen ist. Ebenso wird angegeben, wie der Initialisierungsvektor in IPSec zu behandeln ist. RFC 2406: IP Encapsulating Security Payload (ESP) Hierin wird das am häufigsten eingesetzte IPSec-Protokoll beschrieben, das alle Dienste zur Sicherstellung von Vertraulichkeit, Integrität und Authentizität der Datagramme sowie Mechanismen zum Schutz gegen Replay-Angriffe zur Verfügung stellen kann. RFC 2407: The Internet IP Security Domain of Interpretation for ISAKMP Dieses Papier spezifiziert Datenformate, Strukturen, Konstanten und Richtlinien, mit denen ISAKMP eine Sicherheitsassoziation für IPSec erzeugen kann. RFC 2408: Internet Security Association and Key Management Protocol Dieses im Vergleich zu den anderen IPSec-RFCs recht umfangreiche Dokument beschreibt das Internet Security Association and Key Management Protocol, oder kurz ISAKMP. Dies ist ein von speziellen Verschlüsselungsalgorithmen oder Schlüsselerzeugungstechniken unabhängiges Rahmenwerk, das als Grundlage für konkrete Schlüsselmanagement-Protokolle wie z.B. IKE dient. RFC 2409: The Internet Key Exchange IKE, das Internet Key Exchange Protocol, ist das Thema dieses Papiers. Dieses Protokoll beschreibt, wie Sicherheitsassoziationen ausgehandelt werden, wie symmetrische Schlüssel erzeugt werden und wie sich die beiden Gegenstellen gegenseitig authentifizieren. Es werden auch alle Maßnahmen zum Schutz gegen eine Reihe von Angriffen wie Spoofing, Denial-of-Service usw. beschrieben.
198
Die IPSec-Sicherheitsassoziation
RFC 2412: The OAKLEY Key Determination Protocol Dieser RFC beschreibt das OAKLEY-Protokoll, das die sichere Erzeugung von Schlüsseln auf zwei Gegenstellen auf Basis des Diffie-Hellman-Verfahrens beschreibt. Einige Teile dieses Protokolls sind auch Bestandteil von IKE. RFC 2451: The ESP CBC-Mode Cipher Algorithms In diesem Standard wird erläutert, wie verschiedene, optionale Verschlüsselungsalgorithmen im ESP-Protokoll von IPSec eingesetzt werden.
7.4
Die IPSec-Sicherheitsassoziation
Eine Sicherheitsassoziation (SA) ist das Fundament von IPSec. Sie bestimmt das Verhalten dieses Sicherheitsprotokolls, also welche Verschlüsselungsalgorithmen verwendet werden, die Lebensdauer der SA, das Authentifizierungsprotokoll usw. Die verschiedenen SAs werden in der Security Association Database (SAD) gespeichert. Eine Sicherheitsassoziation ist immer unidirektional. Dies bedeutet, wie in Abbildung 7.5 gezeigt, dass in der Praxis für bidirektionalen Datenverkehr immer mindestens zwei SAs zwischen den Kommunikationsendpunkten existieren müssen. In diesem Fall hat jedes der beiden Systeme eine eingehende (Inbound-SA) und eine ausgehende (Outbound-SA) Sicherheitsassoziation. Es können aber durchaus auch mehrere SAs über eine Verbindung existieren, wenn Pakte mit unterschiedlichen Sicherheitsstufen transportiert werden müssen. IPSecGateway Privates (sicheres) Netzwerk
Dest Cipher: Auth: ARS: PFS: SA-Life .... ....
IPSecGateway Privates (sicheres) Netzwerk
Unsicheres Netzwerk
141.28.1.5 3-DES-CBC HMAC-MD5-96 True True 8 Hrs
Outbound-SA Inbound-SA
Inbound-SA Outbound-SA Dest Cipher: Auth: ARS: PFS: SA-Life .... ....
141.28.156 3-DES-CBC HMAC-MD5-96 True True 8 Hrs
Abbildung 7.5: Die Sicherheitsassoziationen in IPSec sind unidirektional. 199
7 Das IP-Security-Protokoll (IPSec)
Der Security Parameter Index (SPI), der in jedem IPSec-Protokollheader eingetragen ist, ordnet jedes Paket eindeutig einer SA zu. Denn falls innerhalb einer IP-Verbindung mehrere SAs mit dem gleichen Protokoll existieren, die sich z.B. nur in der Stärke der Verschlüsselung unterscheiden, dann ist der SPI der einzige eindeutige Wert, denn die Quell- und die Zieladresse sowie Protokollnummer wären in jedem IP-Paket gleich. Eine weitere, allerdings in keinem Standard festgelegte Verwendung des SPI findet man kleinen SOHO-Routern (Small Office Home Office) verschiedener Hersteller, die ihre Verbindung zum Internet über Wählverbindungen mit dynamischer Zuweisung von IP-Adressen herstellen. Ohne den Einsatz von IPSec wurden die verschiedenen Rechner hinter diesem Router per NAT/PAT (Network Address Translation/Port Address Translation) auf die vom ISP zugewiesene IP-Adresse abgebildet, indem man ihre TCP- oder UDP-Portnummern ändert und der Router eine Tabelle pflegt, in der die privaten Adressen den Portnummern zugewiesen werden. Mit IPSec ist dies nicht möglich. Erstens besitzen ESP oder AH überhaupt keine Portnummern, und zweitens werden die Pakete auf Integrität geprüft. Mit AH funktioniert dies demnach gar nicht. Mit ESP, das den äußeren Header nicht auf Integrität prüft, kann man eine andere Verteilungsstrategie der Pakete im privaten Netz einsetzen. Da der SPI eindeutig ist, kann man im Router eine Tabelle pflegen, in der die Pakete aufgrund des SPI dem richtigen Rechner zugeordnet sind. Allerdings funktioniert dies nur, wie in Kapitel 8 erklärt wird, wenn die Rechner IKE im so genannten Aggressive Mode einsetzen, was die meisten PC-Implementierungen aber können. SAs werden in der Regel durch das IKE-Protokoll erzeugt. Falls die IPSecSicherheitsstrategie ein Paket prüft, das IPSec-Diensten zugeführt werden muss, wofür aber noch keine Sicherheitsassoziation existiert, dann startet IPSec das IKE-Protokoll, um diese zu generieren. Sobald dieser Prozess abgeschlossen ist, kann das Paket ordnungsgemäß verarbeitet und anschließend übertragen werden. Die manuelle Erzeugung von SAs wird im Standard ebenfalls berücksichtigt, ist aber wegen der Fehleranfälligkeit und der immanenten Sicherheitsprobleme in fast keinem System implementiert. Das Löschen von Sicherheitsassoziationen erfolgt durch das Protokoll, das sie erzeugt hat, meist IKE. Die Gründe hierfür liegen entweder in der Sicherheitsstrategie, wenn die Lebensdauer der SA abgelaufen ist oder wenn die maximale Anzahl von Bytes, die innerhalb der SA übertragen wurden, überschritten ist. Oder die Gegenstelle verlangt, dass die SA gelöscht wird, beispielsweise weil ein neuer Schlüssel ausgetauscht wird.
200
Die IPSec-Security-Policy
Eine Sicherheitsassoziation pflegt eine Datenbank, in der Felder bzw. Strukturen enthalten sind, die für den Betrieb der SA notwendig sind. Diese Felder sind: Sequence Number Dies ist der Sequenzzähler für ausgehende Pakete. Anti-Replay Window Dies ist das ARS-Fenster. Es wird für ankommende Pakete verwendet. Sequence Number Overflow Dieses Feld gibt an, ob nach einem Überlauf des Sequenzzählers noch weiter übertragen werden darf und damit die SA weiter existieren kann. Lifetime Dieses Feld enthält die Lebensdauer der SA durch Angabe der zeitlichen Länge, der Anzahl der maximal zu übertragenden Bytes oder beides. Es gibt darüber hinaus auch zwei Arten der Lifetime, eine, die die SA sofort nach Eintritt der Terminierungskondition beendet (hard), und eine andere (soft), die dem IPSec-Kernel eine Nachricht schickt, damit dieser eine neue SA erzeugen kann und die Kommunikation nicht unterbrochen wird. Mode Hier wird angezeigt, ob IPSec innerhalb dieser SA im Tunnel- oder Transportmodus arbeitet. Tunnel Destination Hier steht, falls es sich um einen IPSec-Tunnelmodus handelt, die IP-Zieladresse des äußeren Headers. PMTU Parameters Bei IPSec im Tunnelmodus werden die PMTU-Informationen, die man zur Fragmentierung benötigt, in dieser Struktur gespeichert.
7.5
Die IPSec-Security-Policy
7.5.1
Die Security Policy in IPSec
Die Sicherheitsstrategie oder Security Policy in IPSec legt fest, welche Dienste auf ein- oder ausgehende Pakete anzuwenden sind. Die Regeln, aus denen sich diese Strategie zusammensetzt, sind in einer speziellen Datenbank, der
201
7 Das IP-Security-Protokoll (IPSec)
Security Policy Database (SPD) abgelegt. Diese Strategie wählt eine von drei Arten aus, wie die Pakete behandelt werden. Die Pakete werden entweder verworfen (discard), nicht durch einen IPSec-Dienst transformiert und sofort weiterbearbeitet (bypass) oder durch IPSec umgeformt (apply) und dann weiterverarbeitet. Für ausgehende Pakete liefert die SPD im letzten der drei Fälle (apply) einen Verweis auf einen Eintrag in der Security Association Database, in der die spezifischen Optionen und Parameter hinterlegt sind, mit denen eine Sicherheitsassoziation aufgebaut oder bereits unterhalten wird. Falls die ausgewählte SA noch nicht aktiv ist, wird ein Key-Management-Protokoll, in der Regel IKE, gestartet, um sie zu etablieren. Erst dann wird das Paket übertragen. Die Security Policy Database ist eine Datenstruktur im Kernel (Kernbereich) des Betriebssystems, auf dem der IPSec-Stack implementiert ist. Auf Applikationsebene müssen entsprechende Werkzeuge zum Ändern, Löschen und Hinzufügen von Einträgen existieren. Zunehmend werden auch Schnittstellen zu netzwerkweiten Verzeichnisdiensten wie LDAP eingesetzt, um eine übergreifende Sicherheitsstrategie einsetzen zu können.
7.5.2
Die IPSec-Selektoren
Die Security Policy Database enthält verschiedene Selektoren, mit denen festgelegt wird, welche Dienste auf bestimmte Pakete angewendet werden. Folgende Informationen aus dem IP-, TCP- und UDP-Header der zu inspizierenden Pakete können als Selektoren benutzt werden: 왘 Zieladresse 왘 Quelladresse 왘 Protokoll 왘 Portnummer (des Transportprotokolls) 왘 Name
Zieladresse Die IP-Zieladresse kann in Form von Adressbereichen, Netzwerken, Hostadressen oder ohne weitere Spezifikation (Wildcard) angegeben werden. IPSecGateways benutzen in der Regel keine Hostadressen und bieten daher allen dahinter liegenden privaten Systemen Schutz. Quelladresse Die IP-Quelladresse kann ebenfalls in Form von Adressbereichen, Netzwerken, Hostadressen oder als Wildcard angegeben werden.
202
IPSec-Betriebsmodi
Protokoll Dieser Selektor bezieht sich, sofern vorhanden, auf das Protokollfeld des Transportprotokolls. Falls kein Transportprotokoll verwendet wird, z.B. beim Verschachteln von IPSec-SAs, dann wird das Feld nicht verwendet. Portnummer (des Transportprotokolls) Dieser Selektor bezieht sich auf das Tupel aus Ziel- und Ursprungsportnummer des Transportprotokolls (TCP, UDP, ...). Auch hier können Wildcards benutzt werden. Name Dieses Feld wird im Augenblick von IPSec nicht benutzt. Es wird momentan nur vom IKE-Protokoll als Selektor verwendet.
7.6
IPSec-Betriebsmodi
7.6.1
Tunnelmodus
Der Tunnelmodus wird eingesetzt, um komplette IP-Pakete einschließlich Header zu schützen. Dies wird erreicht, indem ein neues IP-Paket erzeugt wird, in dessen Datenbereich das zu übertragende Paket eingefügt wird. Auf diese Weise erreicht man auch eine weitgehende Vertraulichkeit des Verkehrsflusses, da ein Angreifer beim Einsatz des ESP-Protokolls keinerlei Informationen über das Originalpaket erhält. Alle Adressen und Protokollnummern des Originalpakets sind verschlüsselt. Der Tunnelmodus kann in allen drei IPSec-Einsatzszenarien verwendet werden, also in Gateway-zu-Gatway-, Host-zu-Gateway- und Host-zu-Host-Verbindungen. Im Gegensatz zu anderen Tunneling-Protokollen, die es erlauben, auch Pakete anderer Netzwerkprotokolle, wie z.B. IPX, einzukapseln, ist mit IPSec nur IPin-IP-Tunneling möglich.
7.6.2
Transportmodus
Der IPSec-Transportmodus wird benutzt, um höhere Protokollschichten zu schützen, die im Datenbereich der IP-Pakete eingekapselt sind. Der PaketOverhead ist im Gegensatz zum Tunnelmodus etwas geringer, da kein zusätzlicher IP-Header konstruiert werden muss.
203
7 Das IP-Security-Protokoll (IPSec)
Der Transportmodus kann ausschließlich in IPSec-Host-zu-Host-Verbindungen benutzt werden, da der Kommunikationsendpunkt auch gleichzeitig der Sicherheitsendpunkt ist. Weiterhin können sich Angreifer Informationen über die Netzwerkstruktur und internen Verkehrsbeziehungen verschaffen – selbst beim Einsatz der Verschlüsselung im ESP-Modus, die in diesem Fall nur auf das höhere Protokoll angewendet wird. Protokollnummern geben weiterhin Aufschluss über eingesetzte Anwendungen.
7.7
IPSec-Einsatzszenarien
Abhängig davon, wo die IPSec-Verbindungen initiiert und terminiert werden, kann man die möglichen Einsatzszenarien in drei Gruppen unterteilen, die in vielen praktischen Fällen auch gemischt eingesetzt werden können: 왘 Gateway-zu-Gateway 왘 Host-zu-Gateway 왘 Host-zu-Host IPSecGateway
Privates (sicheres) Netzwerk
IPSecGateway
Privates (sicheres) Netzwerk
Unsicheres Netzwerk
IPSec-SA Gateway-zu-Gateway IPSecClientsoftware
IPSecGateway
Privates (sicheres) Netzwerk
Unsicheres Netzwerk
IPSec-SA Host-zu-Gateway IPSecClientsoftware
IPSecClientsoftware
Unsicheres Netzwerk
IPSec-SA Host-zu-Host
Abbildung 7.6: Die verschiedenen IPSec-Einsatzszenarien
204
IPSec-Protokolle
7.7.1
Gateway-zu-Gateway
Hier erfolgt der Schutz der IP-Datagramme durch IPSec zwischen zwei Gateways. Es sind meist VPN-Gateways oder Router. Der Haupteinsatzzweck ist die Verbindung von privaten Netzen über unsichere Verbindungswege.
7.7.2
Host-zu-Gateway
Hier erfolgt der Schutz der IP-Pakete auf dem Transport von einem Endgerät (Host) zu einem Gateway. Ein typisches Einsatzgebiet ist Remote Access über unsichere Transportnetze.
7.7.3
Host-zu-Host
Dieses Szenario, in dem zwischen Endsystemen IP-Datagramme übertragen werden, trifft man selten an. Ein mögliches Einsatzgebiet sind Intranet-VPNs.
7.8
IPSec-Protokolle
7.8.1
Die Paketverarbeitung in IPSec
Ausgehende Pakete Ausgehende Pakete werden von der höheren Schicht (Transportebene) an das IP-Protokoll weitergegeben. Es erfolgt eine Abfrage in der Security Policy Database, was mit dem betreffenden Datagramm geschehen soll. Abhängig von den Informationen über das Paket gibt es folgende drei Möglichkeiten: 왘 Discard (Fallenlassen), das Datagramm wird verworfen. 왘 Bypass (Umgehen), das Datagramm umgeht IPSec und wird verschickt. 왘 Apply (Anwenden), es wird ein Verweis auf eine SA zurückgeliefert, das
Datagramm entsprechend verarbeitet und anschließend verschickt. Falls IPSec feststellt, dass für das betreffende Paket im dritten Fall (Apply) noch keine SA existiert, wird das IKE-Protokoll aufgerufen, um die notwendige Sicherheitsassoziation zu erzeugen. Das Paket wird erst übertragen, nachdem die SA erzeugt wurde. Eingehende Pakete Diese Verarbeitung unterscheidet sich grundsätzlich von der ausgehender Pakete. Bei eingehenden Paketen prüft die IPSec-Schicht zuerst, ob es sich um ein IPSec-Paket handelt und ob dafür bereits eine Sicherheitsassoziation aufgebaut wurde. Falls keine SA existiert, wird das IPSec-Paket sofort fallen gelassen. Im anderen Fall wird aufgrund der Informationen in der Security Association Database die notwendige Transformation des Pakets durchgeführt. 205
7 Das IP-Security-Protokoll (IPSec)
Falls das Paket kein IPSec-Paket ist, wird geprüft, ob auf das Paket eine Security Policy anwendbar ist. Wenn dies der Fall ist, aber keine Sicherheitsassoziation dafür besteht, wird das Paket sofort verworfen. Wenn keine Security Policy anwendbar ist, wird das IP-Paket an die nächsthöhere Verarbeitungsschicht weitergereicht. Dieses Verhalten gilt für normale IP/IPSec-Stack-Implementierungen; spezielle »gehärtete« Implementierungen verwerfen sofort alle Nicht-IPSecPakete, außer UDP-Paketen mit der Portnummer 500, die vom IKE-Protokoll benutzt werden. Standard-konform ist dieses Verhalten – allerdings mit höherem Verarbeitungsaufwand und geringerer Sicherheit – dadurch erreichbar, dass eine Sicherheitsstrategie existiert, die alle möglichen IP-Pakete umfasst.
7.8.2
Das Authentication-Header-Protokoll (AH)
Authentication Header Authentication Header ist ein IPSec-Protokoll, das außer der Datenvertraulichkeit alle in IPSec geforderten Schutzmechanismen bietet. Die detaillierte Spezifikation ist im RFC2402 nachzulesen. Die Hauptaufgabe des AH besteht in der Authentifizierung der Datenpakete und der Sicherung ihrer Integrität. Optional kann man den Schutz vor wiederholtem Senden von Datagrammen (Replay-Angriffen) aktivieren. Originales IP-Paket Neuer IPHeader
IPSec-AH im Tunnelmodus
IP
AH
IP
TCP
Daten
IP
TCP
Daten
Authentifizierter Bereich
Originales IP-Paket
IPSec-AH im Transportmodus
IP
IP
TCP
Daten
AH
TCP
Daten
Authentifizierter Bereich
Abbildung 7.7: Das IPSec-Authentication-Header-Protokoll (AH)
Der Schutz der Datenintegrität erstreckt sich über das vollständige IP-Paket, also auch über den IP-Header. Somit kann auch keinerlei Form von NAT (Net-
206
IPSec-Protokolle
work Address Translation, Umsetzung von IP-Adressen) auf Pakete angewendet werden, die mit dem Authentication Header gesichert wurden. Falls dies in bestimmten Fällen ein Problem sein sollte, muss man das ESP-Protokoll einsetzen. Da sich einige Werte im IP-Header während des Transports ändern können, dürfen die betreffenden Felder natürlich nicht in den Prüfwert eingehen und werden von der Berechnung mit 0 bewertet. Diese fünf Felder sind: Type of Service, Flags, Fragment Offset, Time to Live und Header Checksum. Das Authentication-Header-Protokoll wird im IP-Header durch die Protokollnummer 51 gekennzeichnet. Der eigentliche Header, der zwischen IP-Header und Nutzdaten eingefügt wird, ist recht einfach aufgebaut. Es werden auch keine Trailer oder Füllzeichen benötigt, wodurch die Pakete nicht so sehr vergrößert werden. In IP Version 4 hat der Authentication Header meist eine Länge von 24 Byte, die sich allerdings bei Einsatz anderer optionaler HMAC-Verfahren unter Umständen vergrößern kann. Der Authentication Header setzt sich aus den im Folgenden erläuterten Feldern zusammen (vgl. Abbildung 7.8): Next Header Dieses Feld zeigt an, welche Art von Daten auf den Authentication Header folgt. Im Tunnelmodus ist dies immer der Wert 4 (IP). Im Transportmodus hängt dies von den Nutzdaten ab. Dies sind meist TCP- oder UDP-Pakete. 0
7
15
31
Neuer IP-Header
Reserved
Security Parameter Index (SPI) Sequence Number (Anti-Replay Service) Integrity Check Value (ICV), Authentifizierungsdaten
Authentication Header
Next Header Payload Length
Eingekapseltes IP-Paket
Abbildung 7.8: Das IPSec-AH-Paketformat
207
7 Das IP-Security-Protokoll (IPSec)
Payload Length Dieses Feld gibt die Länge des Headers an. Da, wie eingangs erwähnt, IPSec ein Protokoll aus IP Version 6 ist, erfolgen die Berechnungen auch entsprechend dem RFC2460 in Vielfachen von 64-Bit Werten. Reserved Dieses Feld ist für zukünftige Erweiterungen reserviert und hat den Wert 0. Security Parameter Index (SPI) Der Security Parameter Index ist eine innerhalb eines IPSec-Systems eindeutige 32-Bit Zahl, die zusammen mit der Zieladresse des äußeren IP-Headers eindeutig eine Sicherheitsassoziation identifiziert. Sequence Number In diesem Feld ist der Wert eines 32-Bit-Zählers enthalten, der bei jedem neuen IP-Paket um eins erhöht wird. Er dient auf der Empfängerseite zum Schutz vor wiederholtem Senden von Datagrammen. Integrity Check Value (ICV), Authentication Data Hier stehen die eigentlichen Informationen zur Authentifizierung und Integritätsprüfung, der so genannte ICV (Integrity Check Value). Mit welchem Verfahren die Werte erzeugt wurden, wird nicht im AH-Protokoll festgelegt, sondern vorher vom IKE-Protokoll oder manuell spezifiziert. Vom Standard werden HMAC-MD-96 und HMAC-SHA-96 vorgeschrieben, andere Verfahren können optional implementiert werden. Die Verarbeitung ausgehender Pakete Im Transportmodus wird der AH-Header direkt nach dem IP-Header in das IP-Paket eingefügt. Im Next-Header-Feld wird die Nummer des Protokolls eingetragen, das im Nutzdatenbereich eingekapselt ist. Das SPI-Feld erhält die Nummer aus der entsprechenden SA, ebenso wird der Wert des Sequenzzählers auf einen gültigen Wert gesetzt, also um eins gegenüber dem letzten Paket erhöht, das innerhalb dieser SA übertragen wurde. Das Protokollfeld im IP-Header wird auf 51 (AH) gesetzt. Im Tunnelmodus erhält das Feld Next Header den Wert 4, und der AH wird zwischen dem inneren und dem äußeren IP-Header eingefügt. Die restlichen Felder werden wie im Transportmodus behandelt. Dann wird ein neuer IPHeader mit der Senderadresse des Geräts und der Zieladresse, die in der SA festgelegt wurde, erzeugt und das Protokollfeld auf 51 gesetzt.
208
IPSec-Protokolle
Die restliche Verarbeitung ist bei Tunnel- und Transportmodus gleich. Das Paket wird mit dem in der Sicherheitsassoziation spezifizierten Authenticator authentifiziert, und der Wert wird in das Authentication-Data-Feld eingetragen. Dabei ist zu beachten, dass im Gegensatz zu ESP das vollständige IPPaket berechnet wird, inklusive des neuen IP-Headers. Dies bedeutet, dass AH mit keiner Art von NAT (Network Address Translation) eingesetzt werden kann! Von der Berechnung des ICV werden nur die Felder ausgenommen, die sich während der Übertragung ändern können. Als Letztes wird die Paketprüfsumme berechnet und in den IP-Header eingetragen. Nun kann das Paket verschickt werden. Die Verarbeitung eingehender Pakete Die Verarbeitung eingehender AH-Pakete erfolgt in umgekehrter Reihenfolge. Bevor die eigentliche Verarbeitung erfolgen kann, muss aufgrund von SPI und IP-Quell- und Zieladressen in der Security Association Database (SAD) ein entsprechender Eintrag mit den notwendigen Optionen und Parametern gefunden werden. Anschließend wird überprüft, ob das Paket schon einmal eingetroffen ist. Hierzu wird, falls diese Option (ARS) im Empfänger aktiviert ist, der Sequenzzähler im AH-Header ausgewertet und geprüft, ob sich der Zählerwert im Empfangsfenster befindet. Falls dem so ist, wird der HMAC des Pakets vom Empfänger berechnet und mit dem Wert im Paket verglichen. Sind beide gleich, so wurde das Paket nicht verändert, ist also authentisch, und aufgrund des Next-Header-Feldes wird geprüft, wie das Paket weiter verarbeitet werden soll. Ist in dem Feld eine 4 (IP) eingetragen, so handelt es sich um ein Paket im Tunnelmodus, und das eingekapselte Paket wird entpackt und der nächsthöheren Verarbeitungsschicht zugeführt. Steht in diesem Feld ein anderer Wert, dann wird das vorliegende Paket sofort zur entsprechenden Verarbeitungsschicht weitergeleitet.
7.8.3
Das Encapsulating-Security-Payload-Protokoll (ESP)
Das Encapsulating-Security-Payload-Protokoll bietet alle Sicherheitsfunktionen, die auch AH bietet, plus einem zusätzlichen Schutz der Datenvertraulichkeit. Um dies zu erreichen, wird ein Teil des IP-Pakets verschlüsselt und ein Header sowie ein Trailer in das Datagramm eingefügt. Die Datenintegritätsprüfung und Authentifizierung erstreckt sich im Gegensatz zum Authentication Header nicht über das vollständige Paket, sondern der IP-Header wird von der Berechnung ausgenommen. ESP ist ebenfalls ein IP-Protokoll, ihm wurde die Nummer 50 zugeordnet.
209
7 Das IP-Security-Protokoll (IPSec)
Ebenso wie beim Authentication Header sind die Algorithmen, die zur Integritätsprüfung und zur Verschlüsselung benutzt werden, nicht im ESP-Protokoll spezifiziert, sondern bereits vom IKE-Protokoll oder manuell festgelegt worden. ESP muss mindestens einen der beiden Sicherheitsmechanismen Verschlüsselung oder Integritätsprüfung unterstützen. Es ist also möglich, ESP mit Verschlüsselung, ESP mit Integritätsprüfung oder ESP mit Verschlüsselung und Integritätsprüfung zu betreiben, nicht jedoch ESP ohne eines dieser beiden Verfahren. Die erste Variante ohne Integritätsprüfung und Authentifizierung birgt aber gewisse Sicherheitsrisiken und sollte möglichst vermieden werden. Originales IP-Paket Neuer IPHeader
IPSec-ESP im Tunnelmodus
IP
ESP
IP
TCP
Daten
IP
TCP
Daten
Auth
Verschlüsselter Bereich Authentifizierter Bereich
Originales IP-Paket IP
IPSec-ESP im Transportmodus
IP
TCP
Daten
ESP TCP
Daten
Auth
Verschlüsselter Bereich Authentifizierter Bereich
Abbildung 7.9: Das IPSec-Encapsulating-Security-Payload-Protokoll (ESP)
Encapsulating Security Payload fügt dem originalen Datagramm unter Umständen mehr an zusätzlicher Länge hinzu als das AH-Protokoll, mindestens jedoch 4 Byte mehr. Der ESP-Header folgt direkt auf den IP-Header, und der ESP-Trailer mit den Authentifizierungsdaten wird direkt an die Nutzdaten angehängt. Es sind folgende Felder spezifiziert (siehe Abbildung 7.10):
210
IPSec-Protokolle
0
7
15
31
Neuer IP-Header Security Parameter Index (SPI) Sequence Number (Anti-Replay Service) Initialisierungsvektor (IV)
Authentifiziert
Verschlüsselt
Eingekapseltes IP-Paket
Padding Padding Len. Next Header Integrity Check Value (ICV), Authentifizierungsdaten
Abbildung 7.10: Das IPSec-ESP-Paketformat
Security Parameter Index (SPI) Der Security Parameter Index ist eine innerhalb eines IPSec-Systems eindeutige 32-Bit-Zahl, die zusammen mit der Zieladresse des äußeren IP-Headers eindeutig eine Sicherheitsassoziation identifiziert. Sequence Number (Anti Replay Service) In diesem Feld ist der Wert eines 32-Bit-Zählers enthalten, der bei jedem neuen IP-Paket um eins erhöht wird. Er dient auf der Empfängerseite zum Schutz vor dem wiederholten Senden von Datagrammen. In abgehenden Paketen wird der Zähler immer hochgezählt, so dass die Entscheidung, ob er benutzt wird, ausschließlich auf der Empfängerseite liegt. Initialisation Vector Der Initialisierungsvektor ist eine 64 Bit große Zufallszahl, die für den CipherBlock-Chaining-Modus (CBC) benötigt wird. Dieser Modus ist im RFC2405 als DES-Betriebsart vorgeschrieben. Padding Das Padding (Auffüllen) wird im ESP-Protokoll für verschiedene Zwecke verwendet. Bestimmte Verschlüsselungsalgorithmen setzen voraus, dass die zu verschlüsselnden Daten ein Vielfaches einer bestimmten Blockgröße sind.
211
7 Das IP-Security-Protokoll (IPSec)
Beim DES-Verfahren zum Beispiel ist diese Blockgröße 64 Bit. Nutzdaten, die kein Vielfaches davon sind, werden auf die erforderliche Länge aufgefüllt. Eine weitere Verwendung besteht darin, auch wenn gar keine Verschlüsselung in ESP spezifiziert wurde, die beiden Felder Padding Length und Next Header an ihre richtige Position zu bringen. In Verbindung mit einem Verschlüsselungsalgorithmus kann man durch das Padding auch die Länge der Originaldaten verschleiern und damit ESP ohne Integritätsprüfung vor so genannten Cut-and-Paste-Angriffen schützen. Padding Length In diesem Feld ist festgelegt, wie lang das Padding-Feld ist. Eine 0 zeigt an, dass kein Padding verwendet wurde. Next Header Dieses Feld gibt an, welche Art von Daten im Nutzdatenfeld enthalten ist, im Tunnelmodus ist dies immer der Wert 4 (IP), im Transportmodus meist 6 (TCP) oder 17 (UDP). Integrity Check Value (ICV), Authentication Data Hier stehen die eigentlichen Informationen zur Authentifizierung und Integritätsprüfung, der so genannte ICV (Integrity Check Value). In ESP ist die Authentifizierung optional; falls keine ausgewählt wurde, entfällt dieses Feld. Die Verarbeitung ausgehender Pakete Im Transportmodus wird der ESP-Header direkt nach dem IP-Header in das IP-Paket eingefügt und der ESP-Trailer an das Paket angehängt. Im Next-Header-Feld wird die Nummer des Protokolls eingetragen, das im Nutzdatenbereich eingekapselt ist. Das SPI-Feld erhält die Nummer aus der entsprechenden SA, ebenso wird der Wert des Sequenzzählers auf einen gültigen Wert gesetzt, also um eins gegenüber dem letzten Paket erhöht, das innerhalb dieser SA übertragen wurde. Falls notwendig, werden Füllzeichen eingefügt und das Feld Padding Length auf den entsprechenden Wert gesetzt. Das Protokollfeld im IP-Header wird auf 50 (ESP) gesetzt. Im Tunnelmodus umschließen ESP-Header und -Trailer das eingekapselte IPPaket. Das Feld Next Header erhält bei IP Version 4 den Wert 4. Die restlichen Felder werden wie im Transportmodus behandelt. Dann wird ein neuer IPHeader mit der Senderadresse des Geräts und der Zieladresse, die in der SA festgelegt wurde, erzeugt und das Protokollfeld auf 50 gesetzt. Die restliche Verarbeitung ist bei Tunnel- und Transportmodus identisch. Es wird zunächst alles zwischen dem Initialisierungsvektor und dem ESPAuthentication-Data-Feld mit dem Verschlüsselungsalgorithmus verschlüsselt, der für die angewendete SA festgelegt wurde. Daraufhin wird das Paket
212
IPSec-Protokolle
vom ESP-Header bis zum ESP-Trailer mit dem in der Sicherheitsassoziation spezifizierten Authenticator authentifiziert und der Wert in das Authentication-Data-Feld eingetragen. Als Letztes wird die Paketprüfsumme berechnet und in den IP-Header eingetragen. Nun kann das Paket verschickt werden. In Abbildung 7.11 ist die Verarbeitung eines ESP-Pakets im Tunnelmodus skizziert. Die IPSec-Security-Policy prüft zuerst anhand ihrer Datenbank, ob für das zu versendende Paket eine Regel zutrifft, und liefert im Erfolgsfall einen Verweis auf einen Eintrag in der Sicherheitsassoziationsdatenbank (SAD) zurück. In dieser Datenbank sind alle Parameter und Optionen hinterlegt, die IPSec benötigt, um eine Sicherheitsassoziation aufzubauen bzw. zu unterhalten. Im Falle unseres Beispiels existiert ein entsprechender Eintrag, und es ist auch bereits eine Sicherheitsassoziation aktiv, innerhalb derer das Paket transportiert werden kann. In der SAD ist genau festgelegt, wie das zu übertragende Paket bearbeitet werden muss (Tunnelparameter, Verschlüsselungsalgorithmus, Schlüssel, Authentifizierungsalgorithmus, SPI, letzter Wert des Sequenzzählers usw.).
Security Policy
IP Neuer IPHeader
IP Security Association Database
TCP
Daten
Paket-Einkapselung
ESP
IP
TCP
Daten
SPI, Seq-Ctr. 3-DES, Keys 1-3.
IP
ESP HMAC-SHA1-96
HMAC-SHA-1-96, Key
IP
Triple-DES-CBC DES
ESP
Auth Verschlüsselter Bereich Authentifizierter Bereich
Abbildung 7.11: Die Verarbeitung eines ausgehenden IPSec-ESP-Pakets
213
7 Das IP-Security-Protokoll (IPSec)
Die Verarbeitung eingehender Pakete Die Verarbeitung eingehender Paket erfolgt in genau umgekehrter Reihenfolge. Bevor die eigentliche Verarbeitung erfolgen kann, muss aufgrund von SPI und IP-Quell- und Zieladressen in der SAD ein entsprechender Eintrag mit den notwendigen Optionen und Parametern gefunden werden. Dann wird überprüft, ob das Paket schon einmal eingetroffen ist. Hierzu wird, falls diese Option im Empfänger aktiviert ist, der Sequenzzähler im ESP-Header ausgewertet und nachgeschaut, ob sich der Zählerwert im Empfangsfenster befindet. Falls das Paket einmalig ist, wird der HMAC des Pakets vom Empfänger berechnet und mit dem Wert im Paket verglichen. Sind beide gleich, so wurde das Paket nicht verändert und ist authentisch. Nachdem also festgestellt worden ist, dass das Paket zum ersten Mal eingetroffen, integer und authentisch ist, kann es der rechenintensiven Entschlüsselung zugeführt werden. Sobald das Paket entschlüsselt ist, wird aufgrund des NextHeader-Feldes geprüft, wie das Paket weiterverarbeitet werden soll. Ist in dem Feld eine 4 eingetragen, handelt es sich um ein Paket im Tunnelmodus, und das eingekapselte Paket wird entpackt und der nächsthöheren Verarbeitungsschicht zugeführt. Steht in diesem Feld ein anderer Wert, wird das vorliegende Paket sofort zur entsprechenden Verarbeitungsschicht weitergeleitet.
7.9
IPSec-Implementierungen
Die IPSec-Funktionalität kann auf verschiedene Arten implementiert werden. Dies hängt von einigen Faktoren ab, zum Beispiel davon, ob gemischte, also IP- und IPSec-Funktionalität auf dem gleichen Interface notwendig ist oder nicht.
7.9.1
Betriebssystemebene, IPSec-Stack
In dieser Variante wird der ursprüngliche IP-Stack durch einen neuen Stack ersetzt, der eine zusätzliche IPSec-Funktionalität aufweist. Dies ist eine leistungsfähige Implementierung, die allerdings nur in bestimmten Systemumgebungen einsetzbar ist, z.B. in Routern oder dedizierten VPN-Gateways. Falls es sich bei dem Gateway um ein reines VPN-System handelt, kann man auch ganz spezielle, gehärtete Stacks einsetzen, die zusätzliche Sicherheit bieten können. Diese Implementierungen verarbeiten ausschließlich diejenigen Protokolle, die für ihre Funktionalität benötigt werden. Ein spezieller IPSecStack würde zum Beispiel alle Pakete außer Protokoll 17 mit Portnummer 500 (IKE), Protokoll 50 (ESP) und Protokoll 51 (AH) ohne weitere Aktivitäten verwerfen (silent discard) und wäre dadurch vor einer ganzen Reihe von Denialof-Service-Angriffen sicher.
214
Betrachtungen zur IPSec-Performance
Applikationsschichten
Applikationsschichten TCP
UDP
TCP
UDP IP
IPSec
IPSec
Datenübertragungsschicht
Datenübertragungsschicht
IPSec hat die IP-Schicht ersetzt
IPSec als zusätzliche Schicht zwischen IP- und Datenübertragungsschicht
Abbildung 7.12: Die verschiedenen Arten einer IPSec-Implementierung
7.9.2
Bump-in-the-Stack (BITS)
Insbesondere für PC-Implementierungen, in denen die IPSec-Funktionalität nicht vom Hersteller des Betriebssystems eingebaut ist, muss man eine andere Implementierung wählen. Denn anderenfalls würde man massiv in die Netzwerkfunktionalität eingreifen, und bei jedem Update des Betriebssystems würde IPSec wieder vom herstellereigenen IP-Stack ersetzt werden. Als Lösung fügt man IPSec als zusätzliche Verarbeitungsschicht zwischen IPEbene und Datenübertragungsschicht ein. Hier wird zwar die Netzwerkschicht zweimal durchlaufen, was nicht der leistungsfähigste Ansatz ist, aber dafür ist diese Methode sehr flexibel und sowohl vom IP-Stack als auch von der Übertragungstechnologie fast unabhängig.
7.10 Betrachtungen zur IPSec-Performance Über die so genannte Performance von IPSec ist in der letzten Zeit ein derart großer – man muss es leider wirklich so drastisch formulieren – Unsinn veröffentlicht worden, dass diesem Thema hier ein eigener Abschnitt gewidmet ist. Mit dem Begriff »Performance von IPSec« fangen die Missverständnisse bereits an, denn IPSec ist eine Protokolldefinition; IPSec weist daher weder einen bestimmten Datendurchsatz auf, noch kennt es Verzögerungszeiten. Auch Aussagen wie die, dass man sich, anstatt IPSec einzusetzen, Gedanken über eine Hardwareverschlüsselung machen sollte, sind barer Unsinn, da sich IPSec und Hardwareverschlüsselung nicht ausschließen – im Gegenteil: Eine ganze Reihe von Herstellern setzt Hardwarebausteine zur Verschlüsselung von IPSec ein. Es wurden wohl, aus welchen Gründen auch immer, nicht gut
215
7 Das IP-Security-Protokoll (IPSec)
gelungene Implementierungen von IPSec dazu benutzt, das Protokoll als solches als schlecht einzustufen – ein unzulässiger Vorgang, wie Sie im Folgenden auch sehen werden. Ich möchte an dieser Stelle versuchen, einmal pragmatisch an das Thema heranzugehen, und zeigen, was die Performance von IPSec-Implementierungen tatsächlich beeinflusst und welchen praktischen Effekt dies haben kann. Ich habe mit Bedacht, obwohl die technische Durchführung kein Problem gewesen wäre, auf Messungen verzichtet, da ich am Sinn bestimmter Messungen erhebliche Zweifel hege und wirklich ganz selten einen Messaufbau gesehen habe, der mit einer echten Netzwerkumgebung mit all ihren verschiedenen Applikationen, Protokollen und fehlkonfigurierten Komponenten auch nur annähernd vergleichbar wäre. Die meisten Messungen, die veröffentlicht werden, stammen von Herstellern, »unabhängigen« Reports (die Anführungszeichen stehen hier für eine Einschränkung, denn nicht wenige solcher Vergleichstests werden von einem der Testkandidaten finanziert – der dann auch prompt gewinnt) oder Fachzeitschriften. Letztere sind oft der rettende Strohhalm, denn diese haben zumindest die Möglichkeit, wirklich unabhängig zu testen oder testen zu lassen. Aber letztendlich sind Labor-Messungen niemals identisch mit dem Verhalten der Systeme in der realen Welt unserer heutigen Sprach- und Datennetze. Die Performance von IPSec-Implementierungen hängt von einer Reihe von Faktoren ab. Zuerst einmal legt die Security Policy selbst den Aufwand fest, den eine IPSec-Implementierung treiben muss, um die notwendigen Transformationen durchzuführen. Es ist offensichtlich, dass AH mit HMAC-MD5-96 im Transportmodus weitaus weniger Verarbeitungsressourcen benötigt, als ESP mit Triple-DES und HMAC-SHA1-96 im Tunnelmodus – um gleich einmal zwei Extremfälle zu betrachten. Zum anderen sind natürlich die Ressourcen des Systems, auf dem IPSec implementiert ist, dafür entscheidend, ob eine ausreichende Leistung zur Verfügung steht. Ein anderer Faktor ist die zusätzliche Paketgröße, die von IPSec erzeugt wird. Auch hier ist der Extremfaktor wieder der ESP-Tunnelmodus mit Authentifizierung und Verschlüsselung. Der Overhead fällt hier umso mehr ins Gewicht, je kleiner die Nutzlastpakete sind. Damit wird zunehmend die Nutzbandbreite verkleinert, und eine Steigerung der Übertragungskosten ist die Folge. Das IKE-Protokoll kann für eine IPSec-Sicherheitsassoziation auch eine Datenkomprimierung aushandeln, falls beide Gegenstellen dies unterstützen. Dies ist auch sehr wichtig, da zum einen die Pakete kleiner werden und zum anderen verschlüsselte Pakete nicht mehr komprimierbar sind. Verschlüsselungsverfahren erzeugen nämlich ein Bitmuster, in dem praktisch keine sich wiederholenden Muster mehr vorkommen. Darauf bauen allerdings die Komprimierungsverfahren auf. Die gut gemeinte Idee, auf tieferen Schichten,
216
Betrachtungen zur IPSec-Performance
z.B. auf PPP-Ebene, eine Datenkomprimierung zu aktivieren, bringt gar nichts, außer der Verschwendung von Rechenleistung und Speicherplatz und, je nach eingesetztem Verfahren, sogar zusätzlicher Paketlänge. Also sollte die IPSec-Komprimierung aktiviert werden, wodurch die Daten vor der Verschlüsselung komprimiert werden. Allerdings sollte man sich in diesem Fall vor Augen halten, dass dies auch wieder ressourcen-intensiv ist und die Gesamtleistung des Systems nachteilig beeinflussen kann. Zusammenfassend kann man sagen, dass heutige moderne Rechner mit ausreichend Arbeitsspeicher und hinreichend leistungsfähigen CPUs der Pentium-Klasse mit IPSec-Clients keine Probleme haben. Manche Hersteller lassen sogar bei der Installation ihrer Clientsoftware eine Testroutine ablaufen, die testet, ob es sich um ältere CPUs handelt, und die Installation dann nicht mehr zulässt. Bei IPSec-Gateways oder VPN-Remote-Access-Konzentratoren auf IPSecBasis hängt es sehr stark vom Design des Systems ab, wie hoch seine Leistungsfähigkeit ist. Allgemein kann man sagen, dass ein speziell für Tunneling und IPSec entwickeltes System ohne spezielle Hardwarebeschleuniger durchaus Leistungen im Bereich von 40 bis 50 Mbit/s bei mehreren tausend SAs mit Triple-DES-Verschlüsselung bieten kann. Viele Systeme bieten die Option, Hardwarebeschleuniger einzubauen, um die Leistung weiter zu erhöhen. Bei der Auswahl solcher Karten ist allerdings Vorsicht geboten. Einige Karten bieten nur eine extrem limitierte Funktionalität. Manche Boards verarbeiten nur einen einzigen Verschlüsselungsalgorithmus, z.B. Triple-DES, andere Verfahren wie DES, MD5, SHA1, und vor allem die IPSec-Komprimierung erfolgt weiterhin in Software. Viel besser stehen solche Boards da, die die komplette Palette von IPSec-Transformationen in Hardware realisiert haben und damit das Muttersystem ganz entscheidend entlasten. Manche Chipsätze unterstützen sogar Public-Key-Verfahren wie RSA und Diffie-Hellman und bringen somit auch einen ernormen Leistungsschub in das extrem rechenintensive IKE-Protokoll. Auf eine solche Funktionalität ist ganz besonders dann Wert zu legen, wenn in einem kurzen Zeitraum eine große Anzahl von Sicherheitsassoziationen aufgebaut werden und eine Authentifizierung auf Basis von digitalen Signaturen und Zertifikaten erfolgt. Dies ist üblicherweise bei Remote-Access-VPNs der Fall, wenn sich zu bestimmten Stoßzeiten sehr viele Benutzer anmelden. Bei Hardwarebeschleunigern muss man zwei Ansätze unterscheiden: Einmal spezielle Erweiterungsboards, die mit speziellen Krypto-Chips ausgestattet sind, in denen die Algorithmen tatsächlich per Hardware abgebildet sind, sowie andere Boards, die mit so genannten »General-Purpose-Prozessoren« ausgestattet sind, die lediglich die System-CPU entlasten und keine spezielle Logik zum Verarbeiten von kryptologischen Verfahren implementiert haben.
217
7 Das IP-Security-Protokoll (IPSec)
Spezielle Chips, wie der 7901 der Firma Hi/fn, haben zum Beispiel die ganze Logik von DES, Triple-DES, SHA-1, MD5 und LZS-Kompression in Hardware realisiert und ermöglichen dabei Durchsätze von IPSec-ESP (Triple-DES, HMAC-SHA1 und Datenkomprimierung, also »Worst-case«-Bedingungen) von 37 Mbit/s. Der Chip unterstützt auch Public-Key-Verfahren, allerdings nicht mit einem speziellen Maskendesign, sondern nur mit einer normalen CPU. Somit sind auch nur 6 IKE-Verbindungen pro Sekunde mit Pre-SharedKey-Authentifizierung möglich und nur 1,5 Verbindungen, falls man digitale Signaturen benutzt. Mehr zur Beschleunigung von Public-Key-Algorithmen im IKE-Protokoll erfahren Sie im nächsten Kapitel. Ein anderes Qualitätskriterium für IPSec, speziell bei Sprach- oder interaktiven Videoanwendungen, ist die Verzögerungszeit (Delay) der Pakete. Hier gibt es bestimmte Grenzen, die nicht überschritten werden dürfen. Beispielsweise sollte bei Sprachanwendungen die Paketlaufzeit unter 200 ms liegen. Hier zuerst die schlechte Nachricht: Eine Echtzeitanwendung für bestimmte Maschinensteuerungen, die eine Verzögerung von einer Millisekunde (1/1000 Sekunde) gegenüber unverschlüsseltem IP nicht mehr toleriert, ist für manche IPSec-Implementierungen ein Problem. Die gute Nachricht ist die, dass man in solchen Umgebungen ohnehin selten IPSec einsetzt und alle sonstigen Daten-, Sprach- und Videoapplikationen mit Verzögerungen im Bereich einiger Millisekunden überhaupt keine Probleme haben. Kleine und mittlere Access-Router, die eigentlich nie für IPSec entwickelt wurden, weisen in der Regel Paketlaufzeiten von 1 ms bis 3 ms auf. Einer der besagten Tester hatte sich darüber erbost, dass die Paketlaufzeit durch IPSec um etwa 150% erhöht wurde. 150%! Das wären ja unglaubliche 2,5 ms bis 7,5 ms Verzögerungszeit. Wenn ich nur den Wert 7,5 ms als Paketlaufzeit kennen würde, würde ich sagen: Okay, klingt ja nicht schlecht, kein Problem für Sprache, Daten und Video. Diese Größenordnung relativiert sich endgültig, wenn man sich einerseits ins Gedächtnis zurückruft, welche Laufzeiten in günstigen Fällen im Internet auftreten (im Mittel 30 bis 200 ms), und andererseits berücksichtigt, dass dieser Wert in einem echten VPN-System deutlich niedriger, in der Regel unter 1 ms, sein wird. Zusammenfassend ist zu sagen, dass gute Implementierungen von IPSec, sowohl im traditionellen Daten- als auch im Sprach- und Videoumfeld eingesetzt werden können. Der Durchsatz ist sehr gut, und die Verzögerungen sind sehr klein, in jedem Fall aber um Größenordnungen kleiner als die durch die Router produzierten Delays. Man darf sich nicht durch einige wenige schwarze Schafe und IPSec-Implementierungen auf Standardroutern, die niemals für Verschlüsselungssoftware ausgelegt wurden, täuschen lassen. Ein gutes, auf Verschlüsselung und Tunneling optimiertes VPN-System, und
218
Zukünftige Entwicklungen
davon gibt es mittlerweile einige, lässt in Bezug auf Performance heute keine Wünsche mehr offen – und wem das immer noch nicht ausreicht, der kann in vielen Systemen Hardwarebeschleuniger nachrüsten.
7.11 Zukünftige Entwicklungen Die Zukunft von IPSec kann man in Augenblick ruhigen Gewissens als rosig bezeichnen. Dies hat zwei Gründe. Zum einen gibt es momentan kein ernst zu nehmendes, konkurrierendes Protokoll, und andererseits ist IPSec im IP-Protokoll der Zukunft, IP Version 6, bereits integriert. Genau genommen wurde es ja von diesem neuen Protokoll auf das alte IP portiert. Die Industrie tut ihr Eigenes dazu, indem IPSec in die Betriebssysteme und das Netzwerkequipment fast aller Hersteller Einzug gehalten hat. Da das NIST mittlerweile mit Rijndael den Nachfolgealgorithmus von DES ausgewählt hat (vgl. Kapitel 4), ist es absehbar, dass dieses Verfahren in Zukunft in IPSec obligatorisch oder wenigstens empfehlenswert werden wird, insbesondere da es frei von Lizenzgebühren ist. Allerdings ist IP Security längst nicht überall einsetzbar. Insbesondere im Bereich von IP-Multicasting muss man vorerst darauf verzichten. Dies hängt damit zusammen, dass IPSec von seiner Struktur her ein reines Punkt-zuPunkt-Protokoll ist. Beim Multicast kommuniziert ein IP-System jedoch mit einer Gruppe von IP-Systemen, die unter einer so genannten Multicastadresse erreichbar sind. Hier kann man weder IPSec noch IKE einsetzen. Eine der wichtigsten Entwicklungen im IPSec-Umfeld sind daher die Aktivitäten im Bereich der Multicasting-Arbeitsgruppe der Internet Engineering Task Force. Hier ist allerdings noch einiges an Entwicklungsarbeit notwendig, bis man zu brauchbaren Lösungsvorschlägen kommen wird. Weiterhin in Arbeit sind Standards für DHCP, die Konfiguration von IPSec, die Erkennung von »toten Gegenstellen« und weitere Verbesserungen und Erweiterungen der IPSec-Protokollfamilie.
219
8
Das Internet-KeyExchange-Protokoll
8.1
Das Henne-Ei-Problem
Im vorangegangenen Kapitel zum Thema IP Security wurde davon ausgegangen, dass die für die verschiedenen kryptographischen Algorithmen benötigten Schlüssel bereits dort sind, wo sie benötigt werden. Beide Gegenstellen einer IPSec-Sicherheitsassoziation teilen sich einen gleichen, symmetrischen Schlüssel, mit dem eine Seite ver- und die andere Seite wieder entschlüsseln kann. In Kapitel 4, Sicherheitstechnologie, wurde außerdem erwähnt, dass die Lebensdauer der Schlüssel nicht zu hoch sein soll, sie also regelmäßig erneuert werden sollen.
Jetzt fragt man sich natürlich, wie das im Netzwerkumfeld zu bewerkstelligen ist, wenn beide Partner einer Sicherheitsassoziation (SA) über ein physikalisches Medium, nennen wir es im Weiteren einfach Leitung, miteinander verbunden sind. Über diese Leitung kann man die Schlüssel nicht austauschen, denn sie ist ja nicht gesichert, da noch keine Schlüssel auf beiden Seiten vorliegen. Diese müssen erst ausgetauscht werden. Das typische Henne-EiProblem: Was war zuerst da? Ein Ausweg, der lange Zeit der einzige war, bestand darin, die Schlüssel über ein anderes, sicheres Medium zu den Gegenstellen zu transportieren. Die manuelle Schlüsselverteilung, also der Transport des oder der Schlüssel auf Papier oder Datenträger und die manuelle Hinterlegung auf den Sicherheitssystemen, ist ein Beispiel hierfür. Diese Verfahren haben jedoch alle einen Nachteil: Sie erhöhen meist die Komplexität und damit auch meist die Fehleranfälligkeit und in der Folge die Unsicherheit des gesamten Systems. Lange Zeit wurde nach einem anderen Weg gesucht, von dem man sich aber nie so recht vorstellen konnte, wie er funktionieren würde. Dieser andere, neue Weg zur Schlüsselverteilung ist erst seit Mitte der 70er Jahre bekannt, seit Whitfield Diffie und Martin Hellman mit ihrer die Kryptographie revolutionierenden Arbeit eine Lösung des Schlüsseltausch-Problems präsentierten (vgl. Kapitel 4), die auch nach ihnen benannt wurde. Das DiffieHellman-Verfahren ist ein auf Methoden der Public-Key-Kryptographie beruhender Algorithmus zum sicheren Erzeugen von Schlüsseln durch die Übertragung bestimmter Informationen über ein unsicheres Medium. Auf Basis dieses Verfahrens wurde eine Reihe von Schlüsseltauschprotokollen entwickelt, die zum Teil auch die Grundlage des Internet-Key-Exchange-Protokolls (IKE) bilden, das zum Erzeugen einer IPSec-Sicherheitsassoziation eingesetzt wird.
221
8 Das Internet-Key-Exchange-Protokoll
Das IKE-Protokoll ist eine Instanziierung von ISAKMP, dem Internet Security Association and Key Management Protocol und benutzt Austauschschritte, die im Oakley-Protokoll spezifiziert werden. IKE ist kein auf IPSec festgelegtes Protokoll, sondern wird durch Spezifikationen in der IPSec Domain of Interpretation (IPSec-DOI) im RFC2407 für den Einsatz mit IP Security mit entsprechenden Datenstrukturen, Konstanten und Funktionen versehen. Andere DOIs können IKE auch für andere Protokolle nutzbar machen, die einen sicheren Schlüsseltausch benötigen. IKE benutzt, ebenso wie IPSec, das Konzept der Sicherheitsassoziationen (SA), die sich allerdings von den IPSec-SAs unterscheiden, unter anderem, da sie bidirektional sind und zwischen Initiator und Responder unterscheiden, je nachdem von welcher Seite IKE gestartet wurde. IKE kann in den verschiedensten Modi und Kombinationen mit etlichen Authentifizierungsverfahren arbeiten, es kann mehrere SAs für IPSec in einem Austausch erzeugen und kann verschiedene Sicherheitsstufen implementieren. Diese Flexibilität von IKE macht das Protokoll allerdings auch sehr komplex und langwierig zu implementieren. IKE, oder besser gesagt dessen praktische Implementierung, ist auch sehr oft der Auslöser, wenn IPSec-Systeme unterschiedlicher Hersteller keine Sicherheitsassoziation miteinander erzeugen können. Aus diesem Grund ist dieses Kapitel sehr ausführlich angelegt, um Ihnen die Möglichkeit zu geben, bei Problemen die Meldungen der Logfiles richtig zu interpretieren und die notwendigen Maßnahmen einzuleiten. Außerdem ist das IKE-Protokoll äußerst sicherheitskritisch, denn von ihm hängen alle später eingesetzten Dienste und die von diesen verwendeten Schlüssel ab.
8.2
ISAKMP
Das Internet Security Asscociation and Key Management Protocol ist ein Regelwerk, das das Verhalten der beteiligten Gegenstellen in den verschiedenen Phasen der Verbindungsverhandlung festlegt. Es legt die Paketformate der auszutauschenden Pakete fest, definiert bestimmte Funktionen und legt die Übergänge zwischen den verschiedenen Zuständen einer ISAKMP-Aushandlung fest. Aber es legt nicht fest, wie dies zu geschehen hat, und ist daher auch nicht unmittelbar in Form eines Protokolls zu implementieren. Dies bleibt den Dokumenten zu IKE, Oakley und der IPSec-DOI vorbehalten. Im Internet Security Asscociation and Key Management Protocol werden verschiedene Austauschvorgänge beschrieben, innerhalb derer der Initiator einer Verbindung mit dem Responder bestimmte Nachrichten austauscht. Anzahl, Art und zeitliche Abfolge der Nachrichten sowie die benötigten Informationen in diesen Paketen hängen von der Art des Austauschvorgangs ab.
222
ISAKMP
ISAKMP ist nicht an bestimmte kryptographische Protokolle oder Algorithmen gebunden, ebensowenig an IPSec oder bestimmte Schlüsseltauschprotokolle. Es bietet vielmehr eine flexible Möglichkeit, Sicherheitsassoziationen aufzubauen, und erlaubt es, die verschiedensten Techniken dafür einzusetzen. Damit bekommt man auch eine elegante Möglichkeit geboten, im Zuge der technologischen Entwicklungen neue Verschlüsselungsverfahren oder Schlüsseltauschprotokolle zu implementieren, ohne das zugrunde liegende Protokoll verändern zu müssen. Das Internet Security Asscociation and Key Management Protocol bietet innerhalb seiner Funktion zur Erzeugung von Sicherheitsassoziationen für ISAKMP und IPSec auch Schutz vor einer ganzen Reihe von Angriffen, insbesondere vor Denial-of-Service-Angriffen, dem Stehlen von Verbindungen und Man-in-the-Middle-Angriffen. ISAKMP spezifiziert Nachrichten, die zwischen Initiator und Responder ausgetauscht werden, und legt ihre Formate fest. Diese Nachrichten werden in heute üblichen Implementierungen in UDP-Pakete mit der Quell- und Zielportnummer 500 eingepackt. Es sind zwar optional auch weitere Kombinationen von Protokoll- und Portnummern möglich, jedoch müssen alle Implementierungen den UDP-Port 500 unterstützen. ISAKMP regelt die Erzeugung von Austauschvorgängen und den dafür benötigten Nachrichten zum Erzeugen, Konfigurieren und Löschen von Sicherheitsassoziationen. Weiterhin wird der Austausch von Werten beschrieben, die von den Schlüsseltausch-protokollen benötigt werden. Diese Protokolle selbst sind aber nicht Gegenstand von ISAKMP, sondern sie benutzen nur dessen Nachrichten. Es werden fünf verschiedene Arten von Austauschvorgängen definiert, die verschiedene Ziele verfolgen und unterschiedlich starke Schutzmechanismen implementiert haben. Darin ist innerhalb eines gewissen Rahmens präzise festgelegt, in welcher Abfolge die Nachrichten zu übertragen sind, wie sie verarbeitet werden müssen, welche Art von Nutzdaten enthalten sein sollen und welche optional sind. Die Sicherheitsstrategie von IKE und IPSec hat ebenfalls noch einen Einfluss auf das Verhalten eines Austauschvorgangs, speziell darauf, wann er aufgrund bestimmter kritisch erscheinender Zustände abzubrechen ist.
8.2.1
Die Sicherheit von ISAKMP
ISAKMP ist aufgrund der Tatsache, dass es eine Sicherheitsassoziation für Sicherheitsprotokolle wie IP Security aushandelt, natürlich als äußerst sicherheitskritisch anzusehen. Denn falls sich in dieser Phase bereits Ansatzpunkte für Angriffe bieten, sind die nachfolgenden Sicherheitsassoziationen auch betroffen. Denn selbst der sicherste Verschlüsselungsalgorithmus ist wirkungslos, wenn sein Schlüssel bekannt ist.
223
8 Das Internet-Key-Exchange-Protokoll
Aus diesem Grund wurde eine ganze Reihe von Schutzmechanismen für das Internet Security Asscociation and Key Management Protocol festgelegt. Diese sind aber nicht mit dem zu verwechseln, was ISAKMP für die folgenden Sicherheitsassoziationen der Sicherheitsprotokolle aushandelt. Authentifizierung Ein ganz wesentlicher Punkt in diesem Zusammenhang ist die gegenseitige Authentifizierung der beiden Gegenstellen. Hier muss man sich aber noch einmal vor Augen halten, dass es sich hierbei keinesfalls um eine BenutzerAuthentifizierung handelt, sondern um eine gegenseitige Identifikation auf der Netzwerkebene. Diese kann zwar mit einer Benutzer-Authentifizierung kombiniert werden, falls es sich bei einer Gegenstelle um einen Host handelt, dessen spezifische Informationen zur Identifikation des Systems vom Benutzer selbst stammen, beispielsweise ein Passwort (Pre-Shared Secret) oder ein digitales Zertifikat der betreffenden Person. Aber im Kontext von ISAKMP bzw. IKE, das, wie im Folgenden beschrieben, dessen Austauschvorgänge benutzt, werden wir von einer Authentifizierung der Endsysteme ausgehen und uns nicht damit beschäftigen, wie die notwendigen, geheimen Informationen zum Nachweis der Identität zur Verfügung gestellt wurden. Als Mechanismen zur Authentifizierung dienen im Wesentlichen Methoden, die auf Basis von Einwegfunktionen Zufallszahlen in Verbindung mit geheimen Informationen zur Identität der betreffenden Gegenstelle in einen Wert transformieren, der über ein unsicheres Medium zur Gegenstelle übertragen werden kann. Die Gegenstelle berechnet ebenfalls diesen Wert und vergleicht beide. Im Fall einer Übereinstimmung ist die Gegenseite authentisch. Als Funktion wird in der Regel die Hashfunktion eingesetzt, die in den ersten Nachrichten innerhalb eines Austauschvorgangs vereinbart wurde. Da diesen Verfahren je nach Qualität ihrer Implementierung nur eine begrenzte Sicherheit bescheinigt wird, werden von der Sicherheitsgruppe der Internet Engineering Task Force (IETF) solche Verfahren bevorzugt, die auf digitalen Signaturen unter Verwendung von Public-Key-Algorithmen (vgl. Kapitel 4) und digitalen Zertifikaten (vgl. Kapitel 5) basieren. Allerdings wird dadurch eine erhebliche zusätzliche Komplexität eingeführt, die durch die erforderliche Verwaltung der öffentlichen Schlüssel oder Zertifikate bedingt ist. In vielen Organisationen ist die dazu notwendige Infrastruktur in Form von Schlüsselverwaltungssystemen oder Verzeichnisdiensten noch nicht oder nicht in ausreichendem Maße implementiert. Als Folge davon sieht die Realität der Authentifizierung im IP-Security- und ISAKMP-Umfeld größtenteils so aus, dass sie nach wie vor auf so genannten Pre-Shared Keys, also de facto einem Passwort in Verbindung mit einem Hashverfahren, beruht. Nichtsdestotrotz fordert der Standard zwingend, dass auch eine starke Authentifizierung implementiert werden muss. Hierzu wird die Benutzung eines Algorith-
224
ISAKMP
mus zur Erzeugung von digitalen Signaturen vorgeschrieben. Dieser ist zwar nicht spezifiziert, jedoch findet man in fast allen Implementierungen das RSA-Verfahren, dessen Patentschutz mittlerweile abgelaufen ist, oder den Digitalen Signaturstandard (DSS) vor. Aber man kann, insbesondere bei IPSec-Gateways, auch die Authentifizierung per Pre-Shared Key relativ sicher machen. Denn hier kann man entsprechend lange und nicht per Wörterbuchangriff zu erratende hexadezimale Zahlen eingeben. In IPSec-Hostimplementierungen, in denen der Pre-Shared Key ein Kennwort ist, das der Benutzer im Gedächtnis zu behalten muss, ist dies nicht möglich, hier bieten sich alle bekannten Möglichkeiten von Angriffen auf Passwörter. An dieser Stelle sei auch ein wichtiger Sicherheitstipp angebracht: Viele IPSecHostimplementierungen bieten optional eine starke Authentifizierung auf Basis von Token-Karten mit Einmalcodes an. Diese hat aber keinen Einfluss auf die Authentifizierung in ISAKMP, IPSec-ESP oder IPSec-AH! Denn diese Form des Identitätsnachweises eines Benutzers erfolgt in vernünftigen Implementierungen unter dem Schutz einer bereits etablierten Sicherheitsassoziation, die vorher auf Basis von Pre-Shared Keys erzeugt wurde. Nachfolgende SAs benutzen ohnehin Werte, die auf dem Schlüsseltausch basieren. Also authentifizieren, wie gesagt, solche Systeme ausschließlich den Benutzer. Die einzige Schnittstelle zu IKE besteht darin, dass bei einer fehlgeschlagenen Authentifizierung die Sicherheitsassoziation gelöscht und IKE terminiert wird. Kryptographie und die Sicherheit des Schlüsseltauschs Die Kryptographie ist die Stütze des Internet Security Asscociation and Key Management Protocol, denn sehr viele seiner Funktionen basieren auf den Entwicklungen und Technologien dieser Wissenschaft. Insbesondere die Erzeugung von symmetrischen Schlüsseln zur Verwendung mit Verschlüsselungsverfahren oder Algorithmen zur Integritätsprüfung und Authentifizierung basiert auf der Public-Key-Kryptographie. Mit der Public-Key-Kryptographie bieten sich zwei verschiedene Möglichkeiten des Schlüsseltauschs an: Man kann den Schlüssel selbst mit einem Algorithmus wie dem RSA-Verfahren verschlüsseln und zur Gegenstelle übertragen, oder man kann mit einem speziellen Verfahren, wie dem von DiffieHellman, den Schlüssel auf beiden Seiten erzeugen. Man kann also zwischen der Schlüsselübertragung und der Schlüsselerzeugung wählen. Im ISAKMPStandard wird, zugegebenermaßen etwas schwammig formuliert, lediglich ein authentifizierter Schlüsseltausch vorgeschrieben. IKE schlägt die Methode der Schlüsselerzeugung per Oakley-Protokoll mit dem Diffie-Hellman-Verfahren vor, und praktisch alle Implementierungen richten sich auch danach.
225
8 Das Internet-Key-Exchange-Protokoll
Die Authentifizierung des Schlüsseltauschs in ISAKMP ist unabdingbar, denn Public-Key-Algorithmen wie RSA oder Diffie-Hellman selbst bieten keinerlei Schutz gegen so genannte Man-in-the-Midle-Angriffe, bei denen sich ein Angreifer in die Kommunikation einschaltet und den beiden Gegenstellen jeweils die andere vorspiegelt. Die Authentifizierung kann direkt während des Schlüsseltauschs oder unmittelbar danach erfolgen, sollte aber zum Schutz vor Denial-of-Service-Angriffen rechenintensiven Funktionen stets vorangestellt sein. Die Behandlung von Schlüsseln innerhalb von Netzwerk-Sicherheitsprotokollen wie IKE und IP Security unterscheidet sich in einem entscheidenden Punkt von anderen Anwendungen. Während verschlüsselte Daten verschiedener Applikationen teilweise Jahre oder Jahrzehnte geheim bleiben müssen und nach oder innerhalb dieser Zeitspanne zur weiteren Verwendung entschlüsselt werden müssen, liegen im Netzwerkbereich ganz andere Voraussetzungen vor. Die Schlüssel werden dort nur solange benötigt, bis das letzte übertragene Paket innerhalb der Lebensdauer einer Sicherheitsassoziation vom Empfänger entschlüsselt wurde. Dann kann – oder um es ganz deutlich zu sagen – muss der Schlüssel zuverlässig vernichtet werden, denn er wird definitiv nicht mehr benötigt. Als noch kritischer ist die Behandlung der privaten Komponenten eines Schlüsseltauschverfahrens wie Diffie-Hellman einzustufen. Denn hier wird der private, auf zufälliger Basis erzeugte Schlüssel nur so lange benötigt, bis beide Seiten daraus ihren symmetrischen Hauptschlüssel berechnet haben. Die erforderliche Lebensdauer liegt somit maximal im einstelligen Sekundenbereich. Eine längere Speicherung birgt ein erhebliches Sicherheitsrisiko, da nur ein einziger bekannt gewordener privater Schlüssel auf einer der beiden Seiten einer Sicherheitsassoziation die komplette Kommunikation kompromittiert, d.h. dass Vertraulichkeit, Integrität und Authentizität der übertragenen Pakete nicht mehr gewährleistet sind. Aus diesem Grund muss die private Diffie-Hellman-Komponente sofort nach der Erzeugung des symmetrischen Schlüssels sicher vernichtet werden. In der Regel erfolgt dies durch mehrfaches Überschreiben und die anschließende Freigabe des vom Algorithmus benutzten Speicherbereichs. Schutz vor Denial-of-Service-Angriffen Die schlechte Nachricht zuerst: Ein absoluter Schutz gegen Denial-of-ServiceAngriffe ist in keinem Übertragungssystem möglich. Das einfache Fluten von öffentlichen Schnittstellen mit Datenpaketen ist immer eine, wenn auch brachiale und mittlerweile meist mit einer empfindlichen Strafe für den Angreifer endende Möglichkeit.
226
ISAKMP
Die gute Nachricht ist die, dass es gegen die subtileren Angriffe eine ganze Reihe brauchbarer Schutzmechanismen gibt. In ISAKMP basiert der Schutz auf so genannten Anti-Clogging-Tokens (ACT), schlicht Cookies genannt. Mit Hilfe dieser Technik kann man wirkungsvoll verhindern, dass ein Angreifer mit gefälschten IP-Absenderadressen an einer ISAKMP-Aushandlung teilnimmt und die Gegenstellen zu ebenso umfangreichen wie sinnlosen Berechnungen und Operationen veranlasst. Schutz vor dem Stehlen von Verbindungen Ein Angreifer, der eine Verbindung stehlen will, indem er Vermittlungssysteme entsprechend manipuliert, um anstelle einer der beiden Gegenstellen weiter an ISAKMP-Aushandlungen teilzunehmen, wird dadurch abgeblockt, dass die Authentifizierung mit der Aushandlung der Sicherheitsassoziation und des Schlüsselaustauschs verbunden ist. Schutz vor Man-in-the-Middle-Angriffen Ein Man-in-the-Middle-Angriff auf eine ISAKMP-Aushandlung würde versuchen, bestimmte Nachrichten zu ändern oder zu löschen. In Abbildung 8.1 sehen Sie einen vereinfacht dargestellten Angriff auf die Aushandlung einer Sicherheitsassoziation in ISAKMP. Der Initiator möchte in diesem Beispiel mit dem Responder wahlweise das ESP-Protokoll ohne, mit DES- oder mit Triple-DESVerschlüsselung vereinbaren. Er würde, wie in Abbildung 8.1 oben gezeigt, eine Nachricht mit dem entsprechenden Vorschlag abschicken, und der Responder, dessen strenge Sicherheitsstrategie in unserem Fall nur eine starke Verschlüsselung zulässt, würde aus diesem Angebot den Vorschlag ESP-3-DES auswählen. Der Angreifer, unser Man-in-the-Middle, schaltet sich nun in die Verbindung ein und versucht, dem Initiator den originalen Responder vorzutäuschen und umgekehrt. Er manipuliert die Antwort des Responders dahin gehend, dass er aus dem Vorschlag des Initiators keine Verschlüsselung (ESP-NULL) auswählt, obwohl der Responder in Wirklichkeit 3-DES selektiert hat. Dann würde der Initator im Weiteren mit dem Man-in-the-Middle unverschlüsselt kommunizieren, der originale Responder würde aber wie von ihm gefordert mit Triple-DES-Verschlüsselung arbeiten. Beim Man-in-the-Middle selbst und auf der Strecke zwischen ihm und dem Initiator wären die Daten unverschlüsselt und somit nicht mehr vertraulich. Die Gegenstellen selbst glauben aber jeweils, mit dem originalen Partner zu kommunizieren und sich auf eine beiderseitig akzeptable Protection Suite geeinigt zu haben. Gegen diese Art von Angriff richten sich gleich eine ganze Menge von Maßnahmen in ISAKMP. Zum einen sind das die bereits beschriebenen Maßnahmen gegen das Stehlen von Verbindungen sowie die Bindung der Austauschvorgänge an eine Authentifizierung. Die Erzeugung der Cookies basiert unter anderem auf der aktuellen Zeit, so dass hierdurch auch gleichzeitig ein Schutz
227
8 Das Internet-Key-Exchange-Protokoll
gegen wiederholtes Senden gewährleistet wird. Andere Angriffe, z.B. auf spezielle Protokolle wie TCP, werden durch den Einsatz von UDP vermieden. Der sichere Transport von UDP-Paketen wird durch geeignete Maßnahmen im ISAKMP erreicht, so dass der Verzicht auf das verbindungsorientierte TCP keine Probleme mit sich bringt. Normale IKE-Aushandlung
Initiator
Responder
Vorschlag: ESP-NULL oder ESP-DES oder ESP-3-DES
ESP-3-DES akzeptiert 3-DES-Verschlüsselung
Man-in-the-Middle-Angriff Initiator
Man-in-the-Middle
Vorschlag: ESP-NULL oder ESP-DES oder ESP-3-DES
Responder
Vorschlag: ESP-NULL oder ESP-DES oder ESP-3-DES
ESP-3-NULL akzeptiert
ESP-3-DES akzeptiert
Unverschlüsselt !
3-DES-Verschlüsselung
Abbildung 8.1: Ein Man-in-the-Middle-Angriff auf eine IKE-Aushandlung
8.2.2
Der ISAKMP-Header
In Abbildung 8.2 sehen Sie das Format des ISAKMP-Headers. Die Felder haben folgende Bedeutung: Initiator Cookie und Responder Cookie Die ersten 16 Byte dieses Headers werden von so genannten Cookies, je eines vom Initiator und eines vom Responder, belegt. Diese Cookies dienen vor allem zum Schutz vor Replay-Angriffen und Angriffen mit gefälschten Absenderadressen. Gebildet werden diese Werte aufgrund von Informatio-
228
ISAKMP
nen, die nur dem Erzeuger bekannt sind, sowie einem Zeitstempel, die als Parameter für eine geeignete Funktion dienen, um den Wert zu berechnen. Es gibt keine feste Vorschrift, jedoch wird empfohlen, eine schnelle Hashfunktion wie MD5 zu benutzen und einen Hashwert über die IP-Adressen, die Portnummern, eine lokal erzeugte, geheime Zufallszahl, die aktuelle Zeit und das Datum zu bilden. Somit ist nämlich garantiert, dass Informationen in die Cookies mit eingehen, die auf spezifischen Eigenschaften der Gegenstelle und der Verbindung beruhen, aber durch den Einfluss der aktuellen Zeit innerhalb ihrer Abfolge garantiert unterschiedlich sind. 0
15
7
31
UDP Header Initiator Cookie
Responder Cookie Next Payload
Version
Exchange Type
Flags
Message ID Length
Nutzdaten Abbildung 8.2: Der ISAKMP-Header folgt dem UDP-Header
Die beiden Cookies zusammen bilden innerhalb der Verbindung zwischen den beiden IP-Endsystemen einen eindeutigen, 128 Bit großen Wert und dienen zusätzlich zu ihrer Sicherheitsfunktion auch als ISAKMP-Security-Parameter-Index (SPI). Next Payload Die Art der Informationen, die auf den ISAKMP-Header folgen, wird durch bestimmte vordefinierte Typennummern festgelegt. Folgende, im Weiteren näher beschriebene Nutzdaten sind spezifiziert: 왘 Keine Nutzdaten enthalten (None) 왘 Sicherheitsassoziation 왘 Proposal
229
8 Das Internet-Key-Exchange-Protokoll
왘 Transform 왘 Key Exchange 왘 Identification 왘 Certificate 왘 Certificate Request 왘 Hash 왘 Signature 왘 Nonce 왘 Notification 왘 Delete 왘 Vendor ID
Die Art der Informationen bestimmt auch deren Struktur und eventuell deren Länge, sofern darin keine variabel langen Werte enthalten sind. Version (Major Version, Minor Version) Die Version des Protokolls wird in einem Haupt- und Nebenfeld festgelegt. Die Implementierungen sollten niemals Pakete verarbeiten, bei denen ein Feld oder beide Felder höhere Versionsnummern enthalten als sie selbst. Exchange Type Der Wert dieses Feldes legt fest, um welche Art von Austausch es sich bei diesem Paket handelt. Die Arten legen unter anderem implizit fest, wie viele Austauschoperationen durchgeführt werden, welche Nutzdaten im Paket folgen, welche Zustandsänderungen nach diesen Operationen eintreten und was sie in Summe bewirken sollen. Folgende Exchange Types sind in ISAKMP definiert: 왘 None (Keine Operation) 왘 Base Exchange 왘 Identity Protection Exchange (daraus wird der IKE Main Mode abgeleitet) 왘 Authentication Only Exchange 왘 Aggressive Exchange 왘 Informational Exchange
230
ISAKMP
Flags Optionen, die die weitere Verarbeitung des ISAKMP-Pakets steuern. Folgende drei Optionen können im Augenblick aktiviert werden: 왘 E-Bit (Encryption-Bit) 왘 C-Bit (Commit-Bit) 왘 A-Bit (Authentication-Only-Bit)
Das Encryption-Bit wird gesetzt, wenn angezeigt werden soll, dass die Daten, die auf den Header folgen, verschlüsselt sind. Die Verschlüsselung wurde mit dem Algorithmus durchgeführt, der in der ISAKMP-Sicherheitsassoziation ausgehandelt wurde. Das Commit Flag dient zur Synchronisierung der Schlüsselerzeugung. Man kann es benutzen, um zu verhindern, dass verschlüsselte Daten eintreffen, bevor die Sicherheitsassoziation vollständig aufgebaut wurde und beide Seiten bereit sind. Mit gesetztem A-Bit wird angezeigt, dass ein Informational Exchange mit Notify-Daten vorliegt das nicht verschlüsselt ist, aber mit dem vereinbarten Authentifizierungsverfahren auf Integrität geprüft werden muss. Message ID Eine Identifikationsnummer für die vorliegende Nachricht. Sie wird auf Zufallsbasis erzeugt. Length Dieses Feld gibt die Länge der vollständigen Nachricht, also ISAKMP-Header plus Nutzdaten, in Byte an.
8.2.3
Der generische ISAKMP-Nutzdaten-Header
Auf den ISAKMP-Header folgen die Nutzdaten, die aus mehreren Instanzen bestehen können, die aufeinander folgen können. Die Nutzdaten bestehen aus Strukturen, die alle mit einem generischen Header beginnen. 0
7
Next Payload
31
15
Reserved
Payload Length
Abbildung 8.3: Der generische ISAKMP-Nutzdaten-Header
231
8 Das Internet-Key-Exchange-Protokoll
In diesem Header sind die für alle Arten von Nutzdaten gültigen Informationen enthalten: Next Payload Dieses Feld zeigt an, ob nach der Nutzdatenstruktur noch eine weitere folgt und welcher Art sie ist. Ist dieses Feld 0, dann folgt nichts mehr nach. Der Typ der ersten Struktur wird im ISAKMP-Header festgelegt. Reserved Dieses Feld ist für spätere Erweiterungen reserviert. Payload Length Die vollständige Länge der vorliegenden Nutzlast, inklusive Header.
8.3
ISAKMP-Nutzdaten
Dem generischen Header folgen die Datenstrukturen, in denen die Nutzlast, also der Inhalt der Nachricht, enthalten ist. Für jeden der verschiedenen Nutzlasttypen gibt es ein spezielles Format zur Repräsentation der zu übertragenden Informationen.
8.3.1
Die Sicherheitsassoziation-Payload
Diese Datenstruktur wird benutzt, um Sicherheitsattribute auszuhandeln und festzulegen, in welcher Umgebung (DOI) die Aushandlung stattfindet. Abbildung 8.4 zeigt das Datenformat. Die Felder haben folgende Bedeutung: Domain of Interpretation (DOI) Dieser Wert gibt an, in welcher Umgebung die Aushandlung erfolgt. 0 bedeutet, dass eine ISAKMP-SA ausgehandelt wird, der Wert 1 steht für IPSec. Situation Dieses Feld hängt von der jeweiligen DOI ab und beschreibt die Situation, in der die Aushandlung stattfindet. 0
7
Next Payload
31
15
Reserved
Payload Length
Domain of Interpretation (DOI) Situation
Abbildung 8.4: Die SA-Payload 232
ISAKMP-Nutzdaten
8.3.2
Die Proposal Payload
In dieser Struktur sind die Informationen enthalten, mit denen eine Sicherheitsassoziation zwischen Initiator und Responder ausgehandelt wird. Diese so genannten Proposals enthalten die Sicherheitsfunktionen, die benutzt werden sollen, um die notwendigen Dienste zur Verfügung zu stellen. In der Regel werden in einem Austausch mehrere Vorschläge gemacht, die logisch verknüpft werden können. Die Felder haben folgende Bedeutung: Proposal Nr Die Nummer des aktuellen Vorschlags. 0
7
31
15
Next Payload
Reserved
Proposal Nr
Protocol-ID
Payload Length SPI Size
# Transforms
Security Parameter Index (SPI)
Abbildung 8.5: Die Proposal Payload
Protocol-ID Die Protokoll-ID der gewünschten Sicherheitsfunktionen. Diese Funktionen sind in der Regel ESP, AH usw. SPI Size Dieses Feld gibt die Länge des folgenden Security Parameter Index (SPI) in Byte an. No of Transforms Anzahl der Vorschläge (Proposals), die gemacht werden. SPI Hier wird der SPI der sendenden Gegenstelle eingetragen.
8.3.3
Die Transform Payload
In der Transform Payload werden die Informationen zu den gewünschten Sicherheitsdiensten selbst hinterlegt. Es können mehrere Transformationen in einer Nachricht vorkommen, ihre Anzahl wird in der Proposal Payload angegeben.
233
8 Das Internet-Key-Exchange-Protokoll
0
7
31
15
Next Payload
Reserved
Payload Length
Transform Nr
Transform-ID
Reserved
Security Association Attributes
Abbildung 8.6: Das Format der Transform Payload
Transform Nr Die eindeutige Nummer der Transform Payload. Transform-ID Die in der DOI für die entsprechenden Funktionen spezifizierten Konstanten werden in diesem Feld eingetragen. SA Attributes Hier sind die Attribute der Sicherheitsassoziation enthalten.
8.3.4
Key Exchange Payload
Diese Nachricht enthält Informationen, die zur Erzeugung der Sitzungsschlüssel benötigt werden. Das Key-Exchange-Data-Feld enthält zum Beispiel die öffentlichen Werte eines Diffie-Hellman-Austauschs im Fall des IKE-Protokolls. 0
7
Next Payload
31
15
Reserved
Payload Length
Key Exchange Data
Abbildung 8.7: Die Key Exchange Payload
Das Format, in dem die Daten in diesem Feld eingetragen sind, hängt dabei von der DOI und dem ausgewählten Schlüsseltauschverfahren ab.
234
ISAKMP-Nutzdaten
8.3.5
Identification Payload
In dieser Datenstruktur sind Informationen zur Identität der Gegenstelle enthalten. Diese werden benutzt, um den Partner zu identifizieren und mit diesen Informationen auch eine Authentifizierung durchführen zu können. 0
7
Reserved
Next Payload
31
15
ID Type
Payload Length
DOI Specific ID Data Identification Data
Abbildung 8.8: Die ID Payload
ID Type Dieser Wert legt fest, welcher Art die Informationen zur Identifikation sind. DOI Specific ID Data Hier stehen DOI-spezifische Identifizierungsdaten. Identification Data In diesem Feld sind die Identitätsinformationen enthalten.
8.3.6
Certificate Payload
Diese Nutzlast dient dazu, digitale Zertifikate zu übertragen, falls diese zur Authentifizierung benötigt werden. Eine Certificate Payload muss zu jedem Zeitpunkt einer Aushandlung akzeptiert werden. Falls keine Directory Services zur Verfügung stehen, mit denen Zertifikate verteilt werden, sollten Zertifikate in den Exchanges übertragen werden. 0
7
Next Payload
31
15
Reserved
Payload Length
Encoding Certificate Data
Abbildung 8.9: Die Certificate Payload
235
8 Das Internet-Key-Exchange-Protokoll
Certificate Encoding Dieses Feld enthält Informationen über die Kodierung des Zertifikats oder über die Art der Daten im nachfolgenden Feld. Folgende Kodierungen werden unterstützt: 왘 PKCS#7-kodiertes X.509-Zertifikat 왘 PGP-Zertifikat 왘 DNS-signierter Schlüssel 왘 X.509-Zertifikat zur Signatur 왘 X.509-Zertifikat zum Schlüsseltausch 왘 Kerberos Token 왘 Certificate Revocation List (CRL) 왘 Authority Revocation List (ARL) 왘 SPKI-Zertifikat 왘 X.509-Attribut-Zertifikat
Certificate Data Hier befindet sich das eigentliche Zertifikat oder eine Information in einem der oben angeführten Datenformate.
8.3.7
Certificate Request Payload
Dies ist eine Datenstruktur, die dazu benutzt wird, in einer ISAKMP-Nachricht von der Gegenstelle ein Zertifikat anzufordern. Sie ist nicht an bestimmte Nachrichten oder Zustände von IKE gebunden und sollte dann verwendet werden, wenn den beteiligten Gegenstellen kein Verzeichnisdienst für die Aufgaben der Zertifikatverteilung zur Verfügung steht. Der Empfänger einer Certificate Request Payload muss dem Sender sein Zertifikat zusenden. 0
7
Next Payload
31
15
Reserved
Payload Length
Cert. Type Certificate Authority
Abbildung 8.10: Das Format der Certificate Request Payload
236
ISAKMP-Nutzdaten
Certificate Type Der Typ des angeforderten Zertifikats wird in diesem Feld eingetragen. Es gelten die gleichen Typvereinbarungen wie in der Certificate Payload. Certificate Authority In diesem Bereich steht ein Wert, der die Certificate Authority identifiziert, die der Sender akzeptiert. In Fällen, in denen dies nicht notwendig ist, kann dieses Feld auch leer bleiben. Das Format des Eintrags ist meist der so genannte Distinguished Name der ausstellenden CA. Weitere Informationen zum Thema Zertifikate sind in Kapitel 5 nachzulesen.
8.3.8
Hash, Signature und Nonce Payload
Diese,von ihrer Struktur her identischen drei Datentypen übertragen entweder einen Hashwert, eine digitale Signatur oder einen Nonce. Hash Dieses Feld enthält einen Hashwert, der aus der Hashfunktion gebildet wurde, die durch ISAKMP-Nachrichten zur Bildung der ISAKMP-Sicherheitsassoziation zwischen den beiden Gegenstellen vereinbart wurde. Die Länge der Daten im Hash-Feld hängt vom verwendeten Algorithmus ab. 0
7
Next Payload
31
15
Reserved
Payload Length
Hash Data / Signature Data / Nonce Data
Abbildung 8.11: Die Hash-, Signature- oder Nonce Payload
Signature Im Falle einer Signature Paylaod ist der Wert im Datenfeld eine digitale Signatur, die von der Funktion erzeugt wurde, die bei der Aushandlung der ISAKMP-Sicherheitsassoziation vereinbart wurde. Die Länge ist auch vom Signaturalgorithmus abhängig. Nonce Nonce ist ein Name für einen Wert, der eine sehr starke Zufallskomponente enthält. Er wird verwendet, um den Nachrichtenaustausch vor Angriffen durch wiederholtes Senden (Replay-Angriff) zu schützen. Er wird meist in Schlüsseltauschpaketen mit übertragen.
237
8 Das Internet-Key-Exchange-Protokoll
8.3.9
Notification Payload
Diese Datenstruktur wird verwendet, um darin Informationen zwischen zwei IKE-Gegenstellen auszutauschen. Dies können Mitteilungen über bestimmte Fehlerzustände sein, zum Beispiel darüber, warum in einer Aushandlung ein Vorschlag zurückgewiesen wurde. Die Felder haben folgende Bedeutungen: Domain of Interpretation (DOI) Dieses Feld zeigt, in welcher Domain of Interpretation (ISAKMP oder IPSec) die Mitteilung erfolgt. Protocol-ID Hier steht die Protokollnummer des Protokolls, auf das sich die Mitteilung bezieht. Im Fall von IP Security können das ISKMP, IPSec-ESP und IPSec-AH sein. 0
7
Next Payload
31
15
Reserved
Payload Length
Domain of Interpretation (DOI)
Protocol ID
SPI Size
Notify Message Type
Security Parameter Index (SPI) Notification Data Abbildung 8.12: Die Notification Payload
SPI Size Dieser Wert gibt an, wie groß das Feld Security Parameter Index im übernächsten Bereich der Datenstruktur ist. Falls es sich um eine ISAKMP-Notification handelt, ist dieser Wert irrelevant, da der SPI in diesem Fall aus der Kombination von Initiator- und Responder-Cookie besteht. Notify Message Type Der Typ der Nachricht, der in einem 16 Bit langen Wert kodiert ist, legt fest, um welche Art von Notification Payload es sich handelt. Im Augenblick sind im Standard nur solche Typen festgelegt, die Auskunft über die Fehlerzustände geben, aufgrund derenr der Aufbau einer Sicherheitsassoziation gescheitert ist.
238
ISAKMP-Nutzdaten
Security Parameter Index In diesem Feld steht der SPI der empfangenden Gegenstelle. Notification Data Hier stehen nähere Angaben zu dem Fehler, der durch den Notify Message Type spezifiziert wurde.
8.3.10
Delete Payload
Wenn eine Gegenstelle eine Sicherheitsassoziation gelöscht hat, schickt sie ihrem Partner diese Nachricht, um dies anzuzeigen. Sie erwartet keine Bestätigung mehr, dass der Empfänger die Nachricht erhalten hat . Es wird empfohlen, dass eine Gegenstelle, die eine Delete Payload erhält, die entsprechende Sicherheitsassoziation ebenfalls löscht, da sie nicht mehr in Benutzung ist und auch nicht reaktiviert werden kann. Domain of Interpretation (DOI) Dieses Feld teilt mit, in welcher Domain of Interpretation (ISAKMP oder IPSec) die Mitteilung erfolgt. 0
7
Next Payload
31
15
Reserved
Payload Length
Domain of Interpretation (DOI)
Protocol ID
SPI Size
Number of SPIs
Security Parameter Index(es) (SPI)
Abbildung 8.13: Die Delete Payload
Protocol ID Hier steht die Protokollnummer des Protokolls, das durch die gelöschte SA geschützt wurde. Im Fall von IP Security können dies ISKMP, IPSec-ESP und IPSec-AH sein. SPI Size Dieser Wert gibt die Länge der SPIs an. Da nur ein einziges Protokoll pro Datenstruktur möglich ist, sind alle SPIs vom gleichen Typ und gleich lang. Falls eine ISAKMP-Sicherheitsassoziation gelöscht wird, ist dieser Wert obsolet, da deren SPI aus den beiden Cookies besteht.
239
8 Das Internet-Key-Exchange-Protokoll
Number of SPIs Falls mehrere zu einem Protokoll gehörende SPIs gelöscht werden, kann dies in einer einzigen Mitteilung erfolgen. In diesem Fall werden die SPIs der gelöschten Sicherheitsassoziation nacheinander in einer Delete Payload übertragen. Was jedoch nicht funktioniert, ist, mehrere verschiedene Protokolle in einer Nachricht unterzubringen. Es muss für jedes Protokoll eine eigene Datenstruktur verwendet werden. Security Parameter Index(es) Hier stehen der oder die gelöschten SPIs, falls es sich nicht um eine ISAKMPSA handelt.
8.3.11
Vendor ID Payload
In das Datenfeld dieser Nachricht kann der Hersteller des IPSec-Systems eine selbst definierte Konstante eintragen. Damit kann er seine eigenen Implementierungen und auch verschiedene Versionen davon identifizieren. Die Vendor ID wird nicht selten benutzt, um in der IKE-Phase 2, nach dem Aufbau der ISAKMP-SA, herstellerspezifische Nachrichten und Informationen austauschen zu können. Dazu müssen sich beide Gegenstellen die notwendigen IDs zugeschickt haben. Die Vendor ID muss während des Aufbaus der ISAKMP-Sicherheitsassoziation ausgetauscht werden; später, in Phase 2, ist dies nicht mehr möglich. 0
7
Next Payload
31
15
Reserved
Payload Length
Vendor ID (VID) Abbildung 8.14: Die Vendor ID Payload
Eine mögliche Anwendung der Vendor ID, in Verbindung mit nachfolgenden privaten Payloads, ist die Konfiguration von entfernten IPSec-Clientsystemen mit Parametern wie dynamisch zugewiesenen IP-Adressen, WINS-Adressen, Policies usw. Im Datenfeld selbst wird kein Text eingetragen, sondern ein Hashwert, der im Allgemeinen über den Namen der Firma, den Produktnamen und eine Versionsnummer berechnet wurde.
240
ISAKMP-Nutzdaten
8.3.12
Die ISAKMP-Phasen
Die Austauschvorgänge im Internet Security Asscociation and Key Management Protocol werden in zwei Phasen unterteilt. In der Phase 1 wird eine ISAKMP-Sicherheitsassoziation aufgebaut, unter deren Schutz – dies ist dann die Phase 2 – die Austauschvorgänge für die Sicherheitsprotokolle wie IPSecESP oder IPSec-AH erfolgen können. Dies ist natürlich ein etwas zeitaufwendiger Prozess, wenn zum Beispiel für eine IPSec-ESP-Sicherheitsassoziation vorher noch eine ISAKMP-SA aufgebaut werden muss. Falls aber innerhalb einer Verbindung noch weitere Protokoll-SAs erzeugt werden sollen, kann dies unter dem Schutz der ISAKMP-SA erfolgen, was dann insgesamt nicht mehr so aufwendig ist. Die Austauschvorgänge in den entsprechenden Phasen werden während der Beschreibung des IKE-Protokolls ausführlich erläutert, deshalb folgt hier nur ein kurzer Überblick über die Phasen als solche: Phase 1 Die Phase 1 ist die Phase, in der noch keine Sicherheitsdienste (Verschlüsselung, Integritätsprüfung, Authentifizierung) zwischen Initiator und Responder zur Verfügung stehen. Also müssen hier besondere Sicherheitsvorkehrungen greifen. In der Phase 1 wird eine ISAKMP-Sicherheitsassoziation etabliert, die die notwendigen Sicherheitsdienste aushandelt und zur Anwendung bringt, um sowohl sich selbst als auch die Operationen in der folgenden Phase 2 zu schützen. Phase 2 Die Operationen in der Phase 2 sind bereits durch die Sicherheitsdienste geschützt, die in der Phase 1 ausgehandelt wurden. Aus diesem Grund kommt man in der Phase 2 auch mit weniger Nachrichten als in der Phase 1 aus, weshalb diese Phase im IKE-Protokoll, das die ISAKMP-Austauschvorgänge benutzt, auch als IKE Quick Mode bezeichnet wird. Hier werden die eigentlichen Security-Protokolle ausgehandelt, die zum Schutz der Nutzdaten dienen, die zwischen den beiden Gegenstellen übertragen werden sollen.
8.3.13
Die ISAKMP-Austauschvorgänge
Im ISAKMP sind verschiedene Austauschvorgänge festgelegt, die auch vom IKE-Protokoll benutzt werden. Diese Vorgänge legen genau fest, in welcher Reihenfolge welche Art von Nachrichten ausgetauscht werden, wie diese Nachrichten aufgebaut sind und wie die Nachrichten von den IKE-Instanzen zu verarbeiten sind. Eine ausführliche Beschreibung der Austauschvorgänge und Nachrichten erfolgt in den Kapiteln zum IKE-Protokoll. Hier wird nur ein Überblick vermittelt, welche Arten es gibt.
241
8 Das Internet-Key-Exchange-Protokoll
Folgende Austauschvorgänge sind im Internet Security Asscociation and Key Management Protocol spezifiziert: Base Exchange Dieser Vorgang besteht aus insgesamt vier Nachrichten, zwei in jede Richtung. In den ersten beiden Nachrichten wird die Sicherheitsassoziation ausgehandelt, die beiden folgenden dienen zum Schlüsseltausch und zur Authentifizierung. Die Informationen zur Authentifizierung, also auch zur Identität der Gegenstellen, und zum Schlüsseltausch werden in einer Nachricht zusammengefasst und somit im Klartext übertragen, da zu diesem Zeitpunkt offensichtlich aufgrund der noch fehlenden Schlüssel keine Verschlüsselung möglich ist. Identity Protection Exchange Hier wird das Manko, dass in der Base Exchange die Informationen zur Identität der Kommunikationspartner im Klartext übertragen werden, behoben. Allerdings wird dies durch einen Overhead in Form zweier zusätzlicher Nachrichten erkauft, so dass hier insgesamt sechs statt vier Nachrichten ausgetauscht werden müssen. Hier werden in den letzten beiden Nachrichten die Informationen zur Identität übertragen, verschlüsselt mit dem Schlüssel, der aus den Daten der beiden vorhergehenden Exchanges vom Schlüsseltauschprotokoll berechnet wurde. Daher rührt auch der Name für diesen Austauschvorgang. Dieser Austausch ist die Grundlage für den IKE Main Mode, den man in IPSec-Security-Gateways einzusetzen pflegt. Aggressive Exchange Dieser Austausch besteht aus insgesamt nur drei Nachrichten und zeichnet sich dadurch aus, dass in diese Nachrichten so viel an Informationen gepackt wird, wie zum Zeitpunkt des Sendens möglich ist. Ein Schutz der Identität findet nicht statt, und es besteht eine etwas größere Gefahr von Denial-of-Service-Angriffen, da die notwendigen Umlaufzeiten für Schutzmaßnahmen wie Anti-Clogging-Tokens nicht gegeben sind. Dieser Exchange ist die Basis für den IKE Aggressive Mode, der vor allem in Remote-Access-Applikationen in IPSec-PC-Implementierungen eingesetzt wird. Authentication Only Exchange Dieser Austausch dient ausschließlich dazu, Nachrichten auszutauschen, in denen Informationen zur Authentifizierung enthalten sind. Im IKE-Protokoll finden sie keine Verwendung.
242
Das Oakley Key Determination Protocol
Informational Exchange Ein derartiger Austausch besteht nur aus einer einzigen Nachricht. Eine Bestätigung ist, trotz Verwendung von UDP als Transportprotokoll, nicht vorgesehen. Dieser Austausch dient zum Management von Sicherheitsassoziationen und zur Information über Fehlerzustände.
8.4
Das Oakley Key Determination Protocol
Das Oakley Key Determination Protocol ist ein Schlüsseltauschprotokoll, das auf der Grundlage von ISAKMP und des Diffie-Hellman-Verfahrens einen authentifizierten Schlüsseltausch ermöglicht. Es dient neben dem Internet Security Asscociation and Key Management Protocol als Grundlage des IKEProtokolls. Oakley benutzt die Austauschvorgänge des ISAKMP-Protokolls. Das Format der Nachrichten und ihre Verarbeitung wird in den folgenden Kapiteln zu IKE näher erläutert. An dieser Stelle seien jedoch die so genannten Oakley-Gruppen erwähnt. Diese Gruppen spezifizieren die Umgebung, in der ein Schlüsseltausch stattfindet, indem sie Grundparameter des Diffie-Hellman-Algorithmus festlegen. Es werden der Generator und die Primzahl angegeben, die als Modulus benutzt wird. Weiterhin wird festgelegt, ob die Gruppe auf elliptischen Kurven oder dem Modulus einer Exponentiation beruht. Das Gruppenkonzept bringt unter anderem den Vorteil, dass sich Schlüsseltauschprogramme nur noch auf die Gruppe einigen müssen. Eine Übertragung der ganzen anderen notwendigen Informationen kann entfallen, da sie den Gegenstellen ja im Voraus bekannt sind. Im IKE-Protokoll muss die Oakley-Gruppe 1 unterstützt werden, andere Gruppen sind optional. In die Gruppen wurde sehr viel an Arbeit investiert, so wurden zum Beispiel alle Primzahlen getestet, was bei einer 1536 Bit großen Primzahl doch schon einiges an Aufwand erfordert. Es sind zur Zeit fünf wohl bekannte Oakley-Gruppen definiert.
8.4.1
Die Oakley-Gruppe-1
Diese Gruppe basiert auf modularer Exponentiation und verwendet eine 768 Bit große Primzahl als Modulus und den Generator 2. Um sich ein Bild von dieser 232-stelligen Primzahl machen zu können, sei sie hier einmal in dezimaler Schreibweise dargestellt: 1.552.518.092.300.708.935.130.918.131.258.481.755.631.334.049.434.514.313.202. 351.194.902.966.239.949.102.107.258.669.453.876.591.642.442.910.007.680.288.8 64.229.150.803.718.918.046.342.632.727.613.031.282.983.744.380.820.890.196.28 8.509.170.691.316.593.175.367.469.551.763.119.843.371.637.221.007.210.577.919 243
8 Das Internet-Key-Exchange-Protokoll
Der Diffie-Hellman-Algorithmus bildet seinen öffentlichen Wert, indem er die Zahl 2, den so genannten Generator, mit einer 180 Dezimalstellen großen Zufallszahl, dem privaten Wert, exponenziert und durch die obige Primzahl modulo dividiert. Das Ergebnis ist der öffentliche Wert des Diffie-HellmanVerfahrens, der über ein unsicheres Medium zur Gegenseite geschickt werden kann. Man kann hier auch erkennen, dass solche Verfahren einiges an Rechenzeit verschlingen, und sollte sich dies beim Design seines VPN vor Augen halten. Diese Gruppe muss in IKE implementiert werden, alle anderen Gruppen sind optional.
8.4.2
Die Oakley-Gruppen 2 bis 5
Die restlichen Oakley-Gruppen definieren eine modulare Exponentiation mit einem 1024-Bit-Modulus (Gruppe 2) und einem 1536 Bit großen Modulus (Gruppe 5) oder basieren auf Gruppen elliptischer Kurven über Galois-Feldern mit 2155 Feldelementen (Gruppe 3) oder 2185 Elementen (Gruppe 4). Diese Gruppen sind optional, die meisten Implementierungen unterstützen zusätzlich zur obligatorischen Gruppe 1 noch die Gruppe 2 mit einer 1024 Bit großen Primzahl.
8.5
Der Aufbau von IKE
Das Internet-Key-Exchange-Protokoll benutzt ISAKMP, Oakley und die IPSec Domain of Interpretation, um Sicherheitsassoziationen für Sicherheitsprotokolle zu erzeugen und den erforderlichen Schlüsseltausch durchzuführen. Das Konzept des universellen Schlüsseltauschprotokolls SKEME (Secure Key Exchange Mechanism) diente als Grundlage für IKE. Obwohl alle diese Protokolle einen mehr oder minder starken Einfluss auf das Internet-Key-Exchange-Protokoll hatten, ist es ein von diesen völlig unabhängiges, eigenständiges Protokoll. Zusätzlich zu den in ISAKMP festgelegten Austauscharten werden in IKE zwei neue Exchanges eingeführt: der Quick Mode und der New Group Mode. Der Quick Mode wird in Phase 2 eingesetzt und dient dazu, auf schnelle Art und Weise mit nur drei Nachrichten eine IPSec-Sicherheitsassoziation aufzubauen. Der New Group Mode wird dazu benutzt, zwischen Initiator und Responder eine neue Oakley-Gruppe mit allen notwendigen Parametern zu vereinbaren. Er wird genau genommen zwischen Phase 1 und Phase 2 ausgehandelt, denn sein Ergebnis muss der Phase 2 bereits zur Verfügung stehen. Andererseits darf der New Group Mode nur unter dem Schutz einer ISAKMPSicherheitsassoziation ausgehandelt werden, was in Phase 1 geschieht.
244
Der Aufbau von IKE
IKE definiert alle notwendigen Austauschvorgänge so weit, dass es unmittelbar zu implementieren ist – und zwar sowohl mit der IPSec DOI für IP-Security-Protokolle als auch unter Verwendung anderer DOIs auch mit anderen Protokollen. Hier interessiert aber nur der Einsatz in Verbindung mit IPSec. Das IKE-Protokoll legt auch ein Rollenverhalten für die beteiligten Gegenstellen fest und unterscheidet zwischen dem Initiator, der, wie der Name bereits vermuten lässt, die Kommunikationsvorgänge beginnt, und dem Responder, der darauf antwortet. IKE benutzt Nachrichten und Austauschvorgänge von ISAKMP und benutzt dessen Daten- und Paketformate. Ebenso wird dessen Modell der beiden Phasen umgesetzt, innerhalb derer die notwendigen Sicherheitsassoziationen erzeugt werden. In Phase 1 sind drei Austauschvorgänge (Exchange) möglich: der IKE Main Mode, der auf dem ISAKMP Identity Protection Exchange aufbaut, der IKE Aggressive Mode, abgeleitet vom gleichnamigen ISAKMP-Austauschvorgang, sowie der Informational Exchange. In der Phase 2 gibt es den so genannten IKE Quick Mode, der keine ISAKMP-Entsprechung hat, jedoch auf dessen Nachrichten und Informationsformaten basiert. Das Oakley Key Determination Protocol liefert die notwendigen Grundlagen für einen sicheren und authentifizierten Schlüsseltausch. Dort sind auch die Oakley-Gruppen mit allen notwendigen Funktionen definiert, um die notwendige Umgebung spezifizieren, in der die Austausch- und Berechnungsvorgänge stattfinden.
8.5.1
Perfect Forwarding Secrecy
Auf praktisch allen heute verfügbaren IPSec-Security-Gateways und IPSecHostimplementierungen kann man optional die so genannte Perfect Forwarding Secrecy (PFS) aktivieren. Diese Option legt fest, wie Schlüssel in einer Sicherheitsassoziation generiert werden. Hierzu gibt es grundsätzlich zwei verschiedene Möglichkeiten: Entweder man generiert alle Schlüssel auf Basis der gleichen Grunddaten, oder man erzeugt Schlüssel immer aus völlig neuen, von den bisher benutzten völlig unabhängigen Daten. Letzteres bezeichnet man als Perfect Forwarding Secrecy. Dadurch wird erreicht, dass die nachfolgenden Schlüssel nicht von einer Kompromittierung eines Schlüssels betroffen sind, egal wodurch diese zustande kam. Denn ohne PFS wäre es denkbar – sofern ein Schlüssel bekannt wäre –, dass Schlüssel, die aus dem gleichen Hauptschlüssel erzeugt werden, ebenfalls bekannt werden könnten. Mit PFS hingegen ist garantiert, dass alle Schlüssel, die unter dieser Option erzeugt wurden, völlig unabhängig voneinander sind.
8.5.2
Die Attribute einer IPSec-Sicherheitsassoziation
Die Attribute einer IPSec-Sicherheitsassoziation werden in der IKE-Phase 2 zwischen dem Initiator und Responder ausgehandelt. Sie dienen dazu, zusätzlich zu den ausgehandelten Sicherheitsdiensten der Protection Suite 245
8 Das Internet-Key-Exchange-Protokoll
weitere Optionen zwischen den Gegenstellen zu vereinbaren. Diese Attribute werden in speziellen ISAKMP-Nutzlastformaten übertragen. Hierbei unterscheidet man grundsätzlich zwischen Attributen variabler und fester Länge, was auch das Format der Pakete bestimmt. Das erste Bit in der Datenstruktur, die zur Übertragung eingesetzt wird, legt fest, ob es sich um ein Attribut fester (1) oder variabler (0) Länge handelt. Das zweite 15 Bit lange Feld legt den Typ des Attributs fest, und das dritte Feld enthält entweder den Wert oder die Länge des Attributs, je nachdem, ob es eine feste Länge hat oder nicht. Falls es ein Attribut variabler Länge ist, ist noch ein viertes Feld vorhanden, in dem der Attributwert enthalten ist. Es gibt eine Reihe verschiedener Attribute, von denen folgende obligatorisch für die Aushandlungen in der Phase 2 (IPSec-Aushandlung) einer IKE-Implementierung sind: 왘 SA Life Type 왘 SA Life Duration 왘 Authentication Algorithm 왘 Optionale IPSec-Attribute
SA Life Type Dieses Attribut legt die Einheit in Sekunden oder Kilobyte fest, in der die Lebensdauer der vorliegenden Sicherheitsassoziation angegeben ist. In der Regel sollte man eine Lebensdauer auf Basis übertragener Pakete festlegen, denn nur damit kann man seine Sicherheitsstrategie darauf ausrichten, wie viele Daten maximal entschlüsselt werden können, falls der dazugehörige Schlüssel kompromittiert ist. SA Life Duration Hiermit wird die Länge der Lebensdauer der vorliegenden SA abhängig vom SA Life Type in Sekunden oder Kilobyte festgelegt. Hier ein Tipp, falls es bei IPSec-Implementierungen verschiedener Geräte zu Problemen beim Aufbau einer SA kommt. Oft sind unterschiedliche Werte in den beteiligten Endgeräten die Ursache für derartige Probleme. Der Standard, hier die IPSec DOI, schreibt kein verbindliches Verhalten vor, falls aufgrund der Sicherheitsstrategie des Responders die vom Initiator vorgeschlagene Lebenszeit nicht akzeptabel ist. Hier gibt es drei Möglichkeiten: Entweder kann die Aushandlung sofort scheitern, der Responder akzeptiert das Proposal, benutzt aber einfach seine eigenen Werte ohne Rückmeldung an den Initiator, oder er akzeptiert den Vorschlag, benutzt seine eigene Lebensdauer und informiert den Responder mit einem informellen Nachrichtenpaket über seinen eigenen Wert.
246
Der Aufbau von IKE
Authentication Algorithm Dieser Wert muss vorhanden sein, um den korrekten Authentifizierungsalgorithmus für IPSec-ESP oder IPSec-AH festzulegen. Es gibt nur eine Ausnahme, in der dieser Wert nicht präsent muss, und zwar dann, wenn IPSecESP ohne Authentifizierung benutzt wird. In diesem Fall darf dieser Wert nicht vorhanden sein. Optionale IPSec-Attribute Weitere optionale IPSec-Attribute spezifizieren Dinge wie IPSec-Modi (Tunnel- oder Transportmodus), weitere Oakley-Gruppen, Werte für spezielle Verschlüsselungsalgorithmen mit variabler Schlüssellänge und Rundenzahl und private Komprimierungsverfahren. Folgende Attribute sind in der IPSec Domain of Interpretation festgelegt: 왘 Group Description 왘 Encapsulating Mode 왘 Key Length 왘 Key Rounds 왘 Compress Dictionary Size 왘 Compress Private Algorithm
8.5.3
Die Attribute einer ISAKMP-Sicherheitsassoziation
Im Internet Key Exchange Protocol gibt es noch eine Reihe weiterer Attribute, die in der Phase 1 zur Aushandlung der ISAKMP-SA benutzt werden und daher nicht im IPSec-DOI, sondern direkt im IKE-Protokoll festgelegt sind: 왘 Encryption Algorithm 왘 Hash Algorithm 왘 Authentication Method 왘 Group Attributes 왘 Life Type 왘 Life Duration 왘 PRF 왘 Key Length 왘 Field Size 왘 Group Order
247
8 Das Internet-Key-Exchange-Protokoll
Encryption Algorithm Dieses Attribut legt den Verschlüsselungsalgorithmus fest, der zur Verschlüsselung der IKE-Nachrichten benutzt wird. Folgende Algorithmen sind im Augenblick von der IANA (Internet Assigned Numbers Authority) festgelegt, weitere können folgen oder privat zwischen zwei Gegenstellen festgelegt werden: 왘 DES-CBC (obligatorisch) 왘 Triple-DES-CBC 왘 IDEA-CBC 왘 Blowfish-CBC 왘 RC5-R16-B64-CBC 왘 CAST-CBC
Im Augenblick gibt es noch keinen festgelegten Wert für den Advanced Encryption Standard, jedoch sind bereits Arbeiten innerhalb der IETF im Gange, diesen nach seiner offiziellen Standardisierung in IPSec und IKE zu implementieren. Hash Algorithm Das Hashverfahren, das innerhalb von IKE zur Integritätsprüfung und Authentifizierung benutzt werden kann, kann aus den drei folgenden Algorithmen ausgewählt werden: 왘 MD5 (obligatorisch) 왘 SHA (obligatorisch) 왘 Tiger
Die Algorithmen müssen sowohl den HMAC als auch ihren natürlichen Modus unterstützen. Falls kein PRF-Attribut (siehe unten) zwischen den beiden Gegenstellen vereinbart wird, dann werden diese Algorithmen als Pseudo Random Function (PRF) in IKE benutzt, unter anderem auch, um den Hauptschlüssel zu berechnen. Authentication Method Hier wird festgelegt, welche Authentifizierungsmethode in der Phase 1 benutzt wird. Folgende Varianten sind aushandelbar: 왘 Pre-Shared Key (obligatorisch) 왘 DSS Signatures 왘 RSA Signatures
248
Der Aufbau von IKE
왘 Encrypt with RSA 왘 Revised Encryption with RSA
Die Aushandlung einer Authentifizierungsmethode hat einen entscheidenden Einfluss auf das Verhalten der Aushandlungen und ihre Nachrichtenformate. Group Attributes Diese Attribute ermöglichen es, eine andere als die Oakley-Gruppe 1 zwischen Initiator und Responder zu vereinbaren, die später weiteren Austauschvorgängen in der Phase 2 zur Verfügung stehen kann. Dabei kann auf wohl bekannte Oakley-Gruppen zurückgegriffen werden, indem man einfach deren Gruppenattribut austauscht oder man komplett neue Gruppen spezifiziert und die notwendigen Parameter wie Primzahlen, Generatoren, Kurvenparameter usw. austauscht. Die auf modularer Exponentiation basierende Gruppe 1, mit einer 768 Bit großen Primzahl, ist in IKE obligatorisch. Folgende Parameter können zusätzlich zur Gruppennummer (Group Description) ausgetauscht werden, um eine andere Gruppe zu erzeugen: 왘 Group Description
Default 768-Bit-MODP Group (obligatorisch) Alternate 1024-Bit-MODP Group EC2N Group on GP[2155] EC2N Group on GP[2185] 왘 Group Type
MOP (Modulare Exponentiation) ECP (Elliptische Kurven über Galois-Feld GF[P]) EC2N (Elliptische Kurven über Galois-Feld GF[2N]) 왘 Group Prime or Irreducible Polynomial 왘 Group Generator One 왘 Group Generator Two 왘 Group Curve A 왘 Group Curve B
Life Type Damit wird die Einheit der Lebensdauer der ISAKMP-SA festgelegt. Diese kann in Sekunden oder Kilobyte angegeben werden.
249
8 Das Internet-Key-Exchange-Protokoll
Life Duration Hierin wird die Länge der Lebensdauer der vorliegenden SA in der im Attribut Life Type ausgehandelten Einheit angegeben. PRF Dieses Attribut wird in fast keiner Implementierung benutzt. Es gibt auch keine Spezifikationen hierzu. Als PRF (Pseudo Random Function) werden in IKE daher meist die HMAC-Versionen des ausgehandelten Hashalgorithmus verwendet. Jedoch können Implementierungen auch private Funktionen angeben und in einer IKE-Aushandlung vereinbaren. Key Length Bei Verschlüsselungsalgorithmen mit variabler Schlüssellänge muss hier die verwendete Größe des Schlüssels angegeben werden. Falls Algorithmen mit fester Schlüssellänge benutzt werden, darf dieses Attribut nicht verwendet werden. Field Size Die Feldgröße in Bits einer Diffie-Hellman-Gruppe wird in diesem Attribut übertragen. Group Order Hierin werden Angaben zur Gruppenreihenfolge zu einer Diffie-HellmannGruppe übertragen, die mit elliptischen Kurven arbeitet.
8.5.4
IKE-Sicherheitsverfahren
Im Internet-Key-Exchange-Protokoll werden sowohl bidirektionale ISAKMPSicherheitsassoziationen als auch unidirektionale SAs für die Sicherheitsprotokolle von IPSec erzeugt. Zu jeder SA existiert eine so genannte Protection Suite (PS), die von den beiden Seiten ausgehandelt wurde und festlegt, welche Sicherheitsverfahren benutzt werden, um die Daten zu schützen, die innerhalb der SA übertragen werden. Standard-konforme Implementierungen von IKE und den IP-Security-Protokollen können immer – sofern beide Gegenstellen eine zueinander passende Sicherheitsstrategie verfolgen – eine Sicherheitsassoziation erzeugen. Das wird garantiert, indem alle Implementierungen einen Mindestsatz von Sicherheitsdiensten zur Verfügung stellen müssen, auf die sich alle Beteiligten einigen können. Alle IKE-Implementierungen müssen folgende Dienste für ihre ISAKMP-Sicherheitsassoziation zur Verfügung stellen und aushandeln können: 왘 DES als Verschlüsselungsalgorithmus 왘 MD5 und SHA als Hashverfahren
250
Der Aufbau von IKE
왘 Authentifizierung mittels Pre-Shared Key 왘 Modulare Exponentiation in der Oakley-Gruppe 1
Weitere Dienste wie Triple-DES oder andere Hashalgorithmen sind optional und sollten, müssen aber nicht zur Verfügung stehen. In der Praxis werden auch meist Triple-DES und gelegentlich die Oakley-Gruppe 2 implementiert, um etwas mehr an Sicherheit zu bieten.
8.5.5
Die Schlüsselerzeugung in IKE
Die Erzeugung der Schlüssel in IKE ist ein Punkt, dem man eine gewisse Beachtung schenken sollte, nicht zuletzt deshalb, weil damit auch ein Teil der oft hitzig geführten Diskussionen um Schlüssellängen etwas an Bedeutung verliert. Wenn Sie bereits in dem Stadium sind, für Ihr geplantes IPSec-VPN bestimmte Gateways und Client-Implementierungen auszuwählen, werden Sie sich nicht selten fragen, wie denn Systeme verschiedener Hersteller mit 112-Bit-TripleDES, 168-Bit-Triple-DES und 192-Bit-Triple-DES oder einfach nur Triple-DES miteinander kommunizieren können. Obendrein treten dann noch Anbieter mit so genannter 128-Bit-Software auf den Plan und behaupten, wie alle anderen auch, mit den übrigen kompatibel zu sein. Nach dem was in Kapitel 4 beschrieben wurde, kann das eigentlich gar nicht möglich sein. Ist es auch nicht. Leider sind viele dieser Angaben, milde ausgedrückt, unpräzise, aus dem Zusammenhang gebracht und in einigen Fällen schlicht falsch. Um die Zusammenhänge etwas zu verdeutlichen, betrachten wir an dieser Stelle, ohne hier den genauen Ablauf der Nachrichten zum Schlüsseltausch kennen zu müssen, wie die IKE-Schlüssel für die IKE- und IPSec-ESP-Sicherheitsassoziationen erzeugt werden. Nehmen wir einmal der Einfachheit halber an, beide SAs sollen Triple-DES als Verschlüsselungs- und MD5 als HashAlgorithmus benutzen. Man benötigt also drei Schlüssel mit je 56 Bit Länge (aus einem 64-Bit-String). Nehmen wir weiterhin an, es erfolge eine Authentifizierung mit einem Pre-Shared Key im IKE Main Mode. Dann würde die Erzeugung der Schlüssel zur Verschlüsselung der Nutzdaten auf folgende Art und Weise erfolgen: Es werden verschiedene Schlüssel berechnet: ein Grundschlüssel (SKEYID), aus dem alle weiteren Schlüssel abgeleitet werden, ein Schlüssel (SKEYID_e) zur Verschlüsselung der ISAKMP-SA, ein Schlüssel (SKEYID_a) zur Authentifizierung der Nachrichten und ein Schlüssel (SKEYID_d), aus dem in nachfolgenden IPSec-Sicherheitsassoziationen in Phase 2 weitere Schlüssel generiert werden können. Diese Schlüssel werden im Fall der Authentifizierung mit einem Pre-Shared Key auf folgende Weise erzeugt:
251
8 Das Internet-Key-Exchange-Protokoll
SKEYID = HMAC-MD5(Pre-Shared Key + Ni) SKEYID_d = HMAC-MD5(SKEYID + KE + Ci + Cr + 0x00) SKEYID_a = HMAC-MD5(SKEYID + SKEYID_d + KE + Ci + Cr + 0x01) SKEYID_e = HMAC-MD5(SKEYID + SKEYID_d + KE + Ci + Cr + 0x02) Das Pluszeichen steht für eine Verkettung der Werte. Die Bezeichner Ci und Cr sind die Werte der Initiator- und Responder-Cookies. An diesem Beispiel, an dem uns hier nicht so sehr die Art der Berechnung interessiert, sieht man sehr gut, dass alle vier Schlüssel nur so lang sein können wie die Ausgabe der Hashfunktion, in unserem Fall 128 Bit. Falls aus diesem Wert nun die erforderlichen Werte für den Triple-DES-Algorithmus in der ISAKMP-SA gewonnen werden sollen, muss dieser Wert auf mindestens 192 Bit vergrößert werden. Dies erfolgt durch eine relativ einfache und schnelle Verkettungsfunktion: KEYMAT = K1 + K2 mit: K1 = HMAC-MD5(SKEYID_e + 0x00) K2 = HMAC-MD5(SKEYID_e + K1) Aus diesem 256 Bit langen String können die drei Teilschlüssel für Triple-DES extrahiert werden. Allerdings – und an dieser Stelle sollte man auf diesen Punkt hinweisen – ist diese Methode nicht geeignet, tatsächlich eine kryptographische Stärke des Schlüssels von tatsächlich 168 Bit zu gewährleisten. Bei den verwendeten Schlüssellängen ist dies zwar kein Sicherheitsproblem, aber eine Brute-Force-Attacke müsste in diesem Fall nicht alle 2168 Möglichkeiten von Triple-DES ausprobieren, sondern nur die 2128 Möglichkeiten von SKEYID_e und könnte daraus mit obiger, schnell auszuführender Rechenanweisung die drei Teilschlüssel generieren. Aber wenn man die Kosten hierfür, also die Berechnungszeit für KEYMAT, mit einkalkuliert, dann liegt die Sicherheit hier immer noch deutlich über 128 Bit, was in jedem Fall heutzutage ausreichend ist. Aus dem Schlüssel SKEYID_d werden alle Schlüssel für unsere IPSec-ESPSicherheitsassoziation erzeugt, also die drei 56-Bit-Schlüssel für Triple-DES und der 128-Bit-Schlüssel für HMAC-MD5-96. Falls als Option Perfect Forwarding Secrecy (PFS) ausgehandelt wurde, erfolgt in der IKE-Phase 2, im QuickMode-Austausch, nochmals ein neuer Diffie-Hellman-Schlüsseltausch; es stehen also wieder neue KE-Werte zur Verfügung. Wenn keine PFS eingesetzt wird, benutzt man in dieser Phase einfach die Werte aus der Phase 1. Nachdem diese Austauschvorgänge abgeschlossen sind, wird im IKE Quick Mode das Schlüsselmaterial erzeugt, das von den IPSec-ESP-Sicherheitsprotokollen benötigt wird. Das Schlüsselmaterial ist eine Bitfolge ausreichender Länge, aus der die Schlüssel für Triple-DES und HMAC-MD5 extrahiert wer-
252
Der Aufbau von IKE
den. Dies hat selbstverständlich auf allen Seiten in der gleichen Art zu erfolgen, denn sonst wäre offensichtlich keine Entschlüsselung oder Authentifizierung auf der jeweils anderen Gegenstelle mehr möglich, da es sich um symmetrische Algorithmen handelt, die identische Werte benötigen! Aus diesem Grund wurde in dem Standard zur Sicherheitsarchitektur für IPSec (RFC2401) und einem weiteren Dokument zu Benutzung von Verschlüsselungsalgorithmen in IPSec (RFC2451) genau festgelegt, wie aus einem hinreichend langen Schlüsselmaterial die benötigten Schlüssel extrahiert werden müssen. Der RFC2401 legt dabei Folgendes fest: Für symmetrische Verschlüsselungsverfahren werden die Schlüssel aus den n höchstwertigen Bits extrahiert, und die restlichen Bits werden für die Hashalgorithmen im HMACModus benutzt, wobei die Zahl n die Summe aller benötigten Bits des Verschlüsselungsverfahrens ist. Der RFC2451 legt fest, wie die verschiedenen Algorithmen mit Schlüsseln versorgt werden. In unserem Fall wird dort spezifiziert, dass Triple-DES mit drei unabhängigen Teilschlüsseln von je 64 Bit Länge, also insgesamt 192 Bits, versorgt werden muss. In jedem Schlüssel wird später jedes achte Bit entfernt, so dass drei Schlüssel mit 56 Bit zur Verfügung stehen. Also benötigen wir für unsere Sicherheitsassoziation Schlüsselmaterial mit insgesamt mindestens 320 Bit Länge. Dies wird in IKE auf folgende Weise erzeugt: KEYMAT = K1 + K2 + K3 wobei K1 bis K3 auf folgende Weise erzeugt werden: K1 = HMAC-MD5(SKEYID_d + KE + Protokoll + SPI + Ni + Nr) K2 = HMAC-MD5(SKEYID_d + K1 + KE + Protokoll + SPI + Ni + Nr) K3 = HMAC-MD5(SKEYID_d + K2 + KE + Protokoll + SPI + Ni + Nr) Hier wird ein 384 Bit langer Wert erzeugt, dessen erste 320 Bit zur Verwendung als Schlüssel in der IPSec-ESP-Sicherheitsassoziation herangezogen werden. Bei dieser Verkettungsfunktion ist, im Gegensatz zu der für die ISAKMP-SA benutzten, die Möglichkeit gegeben (wie in unserem Beispiel zu sehen), durch Benutzung der Perfect Forwarding Secrecy die Daten der neuen Schlüsselaushandlung (KE) in Phase 2 mit in die Berechnung aufzunehmen. Auf diese Weise wird eine hohe kryptographische Stärke des Schlüsselmaterials erreicht. Damit wurde aufgezeigt, dass Triple-DES in IPSec-ESP mit drei unabhängigen Teilschlüsseln zu je 56 Bit arbeitet (aus den 64 Bits der drei ursprünglichen Teilschlüssel wurde jedes achte Bit entfernt), was eine Gesamtlänge von 168 Bit ergibt. Es gibt im standardkonformen IPSec keine Schlüssellängen von 128 oder 192 Bit – und schon gar keine Implementierung, die mit Triple-DES und zwei unabhängigen Teilschlüsseln mit insgesamt 112 Bit arbeitet! Solche Implementierungen, wenn es sie denn gäbe, wären zu allen anderen Systemen inkompatibel.
253
8 Das Internet-Key-Exchange-Protokoll
An dieser Stelle sei noch erwähnt, dass die Sicherheit dieser ganzen Verfahren davon abhängt, dass beide Seiten einer Sicherheitsassoziation den Schlüsseltausch (und insbesondere die privaten Zufallszahlen des Diffie-Hellman-Verfahren) vernünftig und sicher erzeugen und diese Werte sobald möglich vernichten. Sobald nur eine Seite ein böses Spiel treibt und in der Zufallszahl nur eine Entropie von zum Beispiel 20 Bit hätte oder die Zahl gar speichert und weitergibt, wäre damit die ganze Sicherheit der Verbindung verloren, egal wie gut die Gegenstelle ihre eigene Zufallszahl erzeugt! Denn das Wesen des Diffie-Hellman-Austauschs liegt gerade darin, dass zur Erzeugung des Schlüssels nur der eigene private Wert benötigt wird.
8.5.6
IKE-Authentifizierung
IKE legt in der Aushandlung der Sicherheitsassoziation weiterhin fest, auf welche Art die Authentifizierung erfolgen soll. IKE erlaubt die folgenden vier verschiedenen Methoden: 왘 Pre-Shared Key 왘 Digital Signature 왘 Public Key Encryption (RSA) 왘 Revised Mode of Public Key Encryption (RSA)
Pre-Shared Key Hier erfolgt die Authentifizierung durch Bildung eines Hashwertes über eine ganze Reihe von Werten durch die vereinbarte Hashfunktion. Die Werte bestehen aus dem Hauptschlüssel, der unter anderem aus dem Pre-Shared Key berechnet wurde, den gesamten Nutzdaten der Sicherheitsassoziation (Proposals), den öffentlichen Diffie-Hellman-Werten, den beiden Cookies und den Identitäten von Initiator und Responder. Die Hashfunktion (PRF, Pseudo Random Function) wird entweder explizit für die SA ausgehandelt, oder es wird die HMAC-Variante der allgemein ausgehandelten Hashfunktion benutzt. Digital Signature Die Authentifizierung erfolgt durch die digitale Signatur eines Hashwertes, der analog zu dem obigen erzeugt wurde. Die Signatur erfolgt mit dem privaten Schlüssel und einem Signaturalgorithmus, meist RSA. Optional können noch von der Gegenstelle die Zertifikate des Gegenübers angefordert werden, um dessen öffentlichen Schlüssel zu bekommen, falls dieser nicht lokal gespeichert oder über einen Verzeichnisdienst online zur Verfügung steht. Die Zertifikate werden dann zusammen mit der Signatur übertragen.
254
Der Aufbau von IKE
Public Key Encryption (RSA) In diesem Verfahren werden so genannte Nonces, spezielle Zufallszahlen, sowie die Identitäten mit dem öffentlichen Schlüssel der Gegenstelle verschlüsselt. Zu diesem Zweck muss der Initiator den öffentlichen Schlüssel des Responders bereits vorher kennen. Als Verfahren wird meist RSA eingesetzt, und der Chiffretext muss im PKCS#1-Format kodiert sein. Die PKCS-Formate sind Industriestandards der Firma RSA Data Security und auf deren Webseite beschrieben. Leider wird diese Art der Authentifizierung nicht oft benutzt, obwohl sie vom Sicherheitsstandpunkt erhebliche Vorteile, auch gegenüber digitalen Signaturen, aufweist. Der Grund liegt in der Performance, die hier benötigt wird, denn zusätzlich zum Diffie-Hellman-Schlüsseltausch sind vier zusätzliche Public-Key-Ver- bzw. Entschlüsselungen pro Gegenstelle notwendig. Somit ist diese Art der Authentifizierung in Systemen wie Remote-AccessVPN-Konzentratoren, die teilweise eine große Anzahl von Verbindungen in kurzer Zeit aufnehmen müssen, nicht praktikabel, weil die Public-Key-Verfahren praktisch die komplette Rechenzeit okkupieren und den Anmeldevorgang sehr stark verzögern und den laufenden Datenverkehr stören würden. Hier müsste man sehr viel in umfangreiche Ressourcen, wie Hardwarebeschleuniger für Public-Key-Verfahren, investieren, was ein solches System in der Summe sehr teuer machen würde. Revised Mode of Public Key Encryption (RSA) Also hat man das Verfahren revidiert und die Zahl der Public-Key-Operationen reduziert. Hier wird zwar der Nonce-Wert immer noch mit dem öffentlichen Schlüssel verschlüsselt, jedoch wird die Identität mit dem ausgehandelten symmetrischen, etwa 1000fach schneller arbeitenden Verfahren verschlüsselt. Der Schlüssel wird aus dem Nonce abgeleitet und auch gleichzeitig benutzt, um die Nachrichten zum Schlüsseltausch zu verschlüsseln. Von der Art der Authentifizierung im IKE-Protokoll hängt auch die Art und Weise ab, mit der die Hauptschlüssel berechnet werden, aus denen sich die Schlüssel zur Verschlüsselung, Integritätsprüfung und Authentifizierung ableiten. Heutige Implementierungen basieren hauptsächlich auf den ersten beiden Verfahren mit Pre-Shared Key oder digitalen Signaturen. Die beiden anderen Verfahren, insbesondere das letzte, haben leider bisher nur wenig Verbreitung gefunden. Deshalb leider, weil man in einem IKE Aggressive Mode Exchange mit den Public-Key-Verfahren die Identitäten der Kommunikationspartner schützen könnte, da sie in jedem Fall verschlüsselt übertragen werden.
255
8 Das Internet-Key-Exchange-Protokoll
8.6
Der IKE Main Mode
Im IKE Main Mode wird eine ISAKMP-Sicherheitsassoziation erzeugt. Hierfür stehen zwei Austauschtypen zur Verfügung: der so genannte IKE Main Mode, eine Instanziierung des ISAKMP Identity Protection Exchange, und der IKE Aggressive Mode. Sie unterscheiden sich durch die Anzahl von benutzten Nachrichten und die damit verbundene Sicherheitsstufe. Unter bestimmten Bedingungen kann eine Sicherheitsstrategie sogar den Einsatz des Aggressive Mode verbieten. Im Folgenden sind die Austauschvorgänge im Main Mode beschrieben. Da sie sich, je nach dem ausgehandelten Verfahren zur Authentifizierung, sehr stark in den Formaten und Bedeutungen der Nachrichten unterscheiden, werden sie für jede Version der Übersichtlichkeit halber einzeln beschrieben. Bei den im Folgenden beschriebenen Main-Mode-Austauschvorgängen wird von folgenden gleichen Bedingungen ausgegangen: Es sollen DES-CBC, MD5 und die Oakley-Gruppe 1 ausgehandelt und benutzt werden. Die vier Beispiele unterscheiden sich nur in der Art der Authentifizierung.
8.6.1
Authentifizierung mit Pre-Shared Key
Die Authentifizierung dieses Austauschs basiert auf einem Pre-Shared Key, also einer Information, die beiden Systemen zur Verfügung steht. Die praktische Implementierung sieht in der Regel so aus, dass der Pre-Shared Key manuell auf den Systemen eingetragen wird oder bei IPSec-Hostimplementierungen aus dem Benutzerpasswort gewonnen wird. Der IKE Main Mode besteht aus sechs Nachrichten, die nach ihrer Reihenfolge und nach ihren Aufgaben nach in drei Gruppen zu unterteilen sind: Aushandlung der Sicherheitsassoziation, Schlüsseltausch und Authentifizierung. Wie in Abbildung 8.15 zu sehen ist, beginnt der Austausch mit zwei Nachrichten, in denen sich Initiator und Responder auf eine Protection Suite für die ISAKMP-Sicherheitsassoziation einigen – oder auch nicht, falls die Vorschläge für den Responder nicht akzeptabel sind. Im Gegensatz zu anderen Protokollen, wie zum Beispiel PPP, findet hier keine mehrstufige Verhandlung statt, sondern der Initiator unterbreitet eine Reihe von Vorschlägen in einer einzigen Nachricht, und der Responder wählt einen Vorschlag davon aus oder lehnt alles ab. In letzterem Fall kommt die Aushandlung zum Ende, indem sie schlicht terminiert wird. Die Vorschläge (Proposals) des Initiators können sehr komplex aufgebaut und logisch (Und, Oder) miteinander verknüpft werden. Bei bestimmten Umgebungen, zum Beispiel im Fall von Remote-AccessVPNs, in denen eine zentrale Sicherheitsstrategie eingesetzt wird, sieht es in der Praxis meist so aus, dass der Initiator alles in einen Vorschlag packt, was er an Funktionen unterstützt, und das zentrale VPN-Gateway aus diesem Packen das Proposal auswählt, das seiner Sicherheitsstrategie entspricht.
256
Der IKE Main Mode
Sobald die ersten beiden Nachrichten ausgetauscht, verarbeitet und ausgewertet sind, steht fest, ob sich Initiator und Responder auf eine ISAKMPSicherheitsassoziation einigen konnten oder nicht. Im letzteren Fall wird der Verbindungsaufbau abgebrochen; ansonsten wird durch den vom Responder ausgewählten Vorschlag der weitere Verlauf des Austauschvorgangs festgelegt. In unserem Fall soll eine Authentifizierung auf Basis eines Pre-Shared Key erfolgen. Initiator
Responder
Nachricht 1 Hdr SA
Proposal 1 Transf. 1
...... Proposal n
Transf. n
Nachricht 2 Hdr SA
Proposal
Transform
Abbildung 8.15: Die ersten beiden Nachrichten des IKE Main Mode
Die folgenden beiden Nachrichten dienen zur Übertragung von Informationen, mit deren Hilfe der Initiator und der Responder lokal den symmetrischen Hauptschlüssel berechnen können. Zu diesem Zweck erzeugen sich beide je zwei strikt zufällige Zahlen, von denen eine als Exponent (x im Initiator und y im Responder) für das Diffie-Hellman-Verfahren und die andere als Nonce-Wert dient. Da sich beide Seiten auf die Oakley-Gruppe 1 geeinigt haben, werden nun die öffentlichen Diffie-Hellman-Werte aus der Basis 2, der 768 Bit großen Primzahl n und dem geheimen Exponenten berechnet. Der Initiator erzeugt seinen Wert mit 2x (mod n), und der Responder berechnet 2y (mod n). Die Zahlen 2 und n brauchen nicht ausgetauscht zu werden, da sie implizit durch Auswahl der Oakley-Gruppe 1 in den beiden ersten Nachrichten festgelegt wurden. Aus diesen ganzen Werten formen der Initiator und der Responder die benötigten Datenstrukturen für ihre Nachrichten und tauschen diese anschließend aus, wie in Abbildung 8.16 zu sehen ist. Es erfolgt aber auf keiner der beiden Seiten sofort eine Berechnung des Hauptschlüssels. Dies wird so lange verzögert, bis die Cookies ausgewertet sind und damit der jeweilige Absender verifiziert ist. SKEYID = HMAC-MD5(Pres-Shared Key + Ni) SKEYID_d = HMAC-MD5(SKEYID + KE + Ci + Cr + 0x00) SKEYID_a = HMAC-MD5(SKEYID + SKEYID_d + KE + Ci + Cr + 0x01) SKEYID_e = HMAC-MD5(SKEYID + SKEYID_d + KE + Ci + Cr + 0x02)
257
8 Das Internet-Key-Exchange-Protokoll
SKEYID_e wird zur Verschlüsselung der ISAKMP-Nutzdaten benutzt, und SKEYID_a dient zur Authentifizierung der Pakete mit Hilfe der ausgehandelten Hashfunktion. In unserem Beispiel sind dies DES zur Datenverschlüsselung und HMAC-MD5 als Hash-Algorithmus. Der Schlüssel SKEYID_d dient als Grundschlüssel der IPSec-SAs, die in der IKE-Phase 2 erzeugt werden. Initiator
Responder
Nachricht 3 Hdr
KE i
Ni
Nachricht 4 Hdr
KE r
Nr
Abbildung 8.16: Die beiden Nachrichten zum Schlüsseltausch im IKE Main Mode
An diesem Beispiel wird offensichtlich, dass – falls eine Authentifizierung mit einem Pre-Shared Key durchgeführt wird – der Responder wissen muss, wessen Pre-Shared Key er für die Berechnung von SKEYID benutzen soll. Er besitzt die Keys aller möglichen Gegenstellen und muss einen davon auswählen. Die Identität des Initiators wird ihm aber erst in der vorletzten Nachricht mitgeteilt, die jedoch bereits verschlüsselt sein muss, und zwar mit einem Schlüssel, der teilweise auf dem Pre-Shared Key basiert. Als einzige Möglichkeit, vorher den richtigen Key auszuwählen, bleibt leider nur die Kenntnis der IP-Adresse des Initiators. Leider deshalb, weil damit keine dynamische Zuweisung der IP-Adresse an den Initiator möglich ist, denn der Responder muss eine Tabelle mit IP-Adressen und zugehörigen Pre-Shared Keys pflegen. Aber bei der Einwahl bei Internet Service Providern werden grundsätzlich die IP-Adressen dynamisch zugewiesen. Mögliche Auswege für Remote-AccessVPNs bieten die nachfolgend beschriebene Authentifizierung mit digitalen Signaturen oder der IKE Aggressive Mode. Die letzten beiden Nachrichten im IKE Main Mode dienen zur gegenseitigen Authentifizierung von Initiator und Responder. Eine beiderseitige Authentifizierung ist im IKE-Protokoll obligatorisch. Zu diesem Zweck bilden beide Seiten einen geeigneten Hashwert, anhand dessen die Gegenstelle die Identität des Senders überprüfen kann. Als Eingangswerte für die Hashfunktion dienen die beiden öffentlichen Diffie-Hellmann-Werte (KEi, KEr), der Initiatorund der Responder-Cookie (Ci, Cr), die Daten der Vorschläge des Initiators für die ISAKMP-Sicherheitsassoziation (SA) und die Identität des Senders (IDi, IDr):
258
Der IKE Main Mode
HASH_I = HMAC-MD5(SKEYID, KEi + KEr + Ci + Cr + SAi + IDi) HASH_R = HMAC-MD5(SKEYID; KEr + KEi + Cr + Ci + SAi + IDr) Der Initiator erzeugt eine Nachricht, in der er seine Identität (IDi) und seinen Hashwert (HASH_I) zum Responder schickt, um sich zu authentifizieren. Alles außer dem ISAKMP-Header ist in dieser Nachricht verschlüsselt, in unserem Beispiel mit DES, um die Identität des Initiators zu verbergen. Daraus resultiert auch die Namensgebung (Identity Protection Exchange) dieses Austauschvorgangs. Der Responder authentifiziert sich auf die gleiche Art durch die verschlüsselte Übermittlung seines Hashwerts (HASH_R) und seiner Identitätsinformationen (IDr) an den Initiator. Initiator
Responder
Nachricht 5 Hdr
IDi
HASH_I
Verschlüsselt (DES-CBC)
Nachricht 6 Hdr
IDr
HASH_R
Verschlüsselt (DES-CBC)
Abbildung 8.17: Die Authentifizierung des IKE-Main-Mode-Austauschs erfolgt in den letzten beiden Nachrichten.
Hier wieder ein Praxistipp: Falls es Probleme innerhalb eines Austauschvorgangs gibt, bekommt man oft die Fehlermeldung, dass die Authentifizierung fehlgeschlagen sei. Als Problemquelle vermutet man hier natürlich zuerst den Pre-Shared Key, was in der Regel auch zutrifft. Aber diese Meldung kann auch ein Indiz für einen Angriff sein. Denn die Authentifizierung in den letzten beiden Nachrichten schlägt auch dann fehl, wenn die anderen Werte wie Cookies, SA-Vorschlag usw. verändert wurden, und nicht nur, wenn der PreShared Key, auf dem SKEYID basiert, nicht identisch ist. Nachdem diese sechs Nachrichten übermittelt und fehlerfrei verarbeitet wurden, besteht eine ISAKMP-Sicherheitsassoziation, unter deren Schutz in der IKE-Phase 2 weitere SAs für IPSec-Protokolle wie IPSec-ESP oder IPSec-AH erzeugt werden können. Dieser Schutz besteht aus Diensten zur Sicherstellung der Nachrichtenintegrität, der Authentizität und der Vertraulichkeit der übertragenen Daten durch Einsatz der ausgehandelten kryptographischen Verfahren.
259
8 Das Internet-Key-Exchange-Protokoll
8.6.2
Authentifizierung mit digitaler Signatur
Eine Authentifizierung mittels einer digitalen Signatur unterscheidet sich innerhalb der ersten beiden Nachrichten im IKE Main Mode nur durch den Inhalt der Vorschläge vom vorhergehenden Beispiel. Hier wird statt der PreShared-Key-Authentifizierung eine mit digitaler Signatur erfolgende ausgehandelt. Initiator
Hdr SA
Responder
Nachricht 1 ...... Proposal n
Proposal 1 Transf. 1
Transf. n
Nachricht 2 Hdr SA
Proposal
Transform
Nachricht 3 Hdr
KEi
Ni
[CERT_REQ]
Nachricht 4 Hdr
KEr
Hdr
IDi
Nr
[CERT_REQ]
Nachricht 5 [Certificate]
SIG_I
Verschlüsselt (DES-CBC)
Nachricht 6 Hdr
IDr
[Certificate]
SIG_R
Verschlüsselt (DES-CBC)
Abbildung 8.18: Ein IKE-Main-Mode-Austausch mit einer Authentifizierung durch digitale Signaturen
Die beiden Nachrichten zum Schlüsseltausch können als optionalen Wert eine Anforderung eines digitalen Zertifikats der Gegenstelle (CERT-REQ) enthalten. Falls dies nicht benötigt wird, sind die Nachrichten zwar identisch zu denen der Pre-Shared-Key-Version, aber die Behandlung der übertragenen Werte unterscheidet sich vor der anderer Authentifizierungsmethoden. Der Wert des Hauptschlüssels, aus dem sich alle anderen Schlüssel ableiten, wird nach folgender Rechenvorschrift ermittelt: SKEYID = HMAC-MD5(Ni + Nr +KE)
260
Der IKE Main Mode
KE ist das Ergebnis des Diffie-Hellman-Verfahrens, also 2xy mod n. Aus diesem Grundwert werden alle weiteren Schlüssel auf die in Abschnitt 8.5.5 beschriebene Weise erzeugt. Die letzten beiden Nachrichten, die zur wechselseitigen Authentifizierung von Initiator und Responder dienen, übertragen keinen Hashwert, sondern jeweils eine Signatur der Hashwerte HASH_I und HASH_R. Im Fall von RSA als Signaturalgorithmus würden die Signaturen aus den Hashwerten wie folgt erzeugt: SIG_I = RSA(Ki_private, HASH_I) SIG_R = RSA(Kr_private, HASH_R) Die privaten Schlüssel Ki_private und Kr_private korrespondieren mit deren öffentlichen Schlüsseln, die zum Verifizieren der Signatur benötigt werden. Diese Schlüssel sind der Gegenstelle entweder bereits bekannt, oder sie werden in einem Zertifikat übertragen, das innerhalb der dritten und vierten Nachricht angefordert werden kann. Im ersten Fall müssen die öffentlichen Schlüssel auf eine andere Art und Weise, die über den Definitionsbereich des IKE-Protokolls hinausgeht, auf den beteiligten Gegenstellen bekannt gemacht werden. Dies kann entweder durch manuelle Schlüsselhinterlegung oder etwas moderner und zuverlässiger durch den Einsatz eines Verzeichnisdienstes erfolgen. Dies gilt auch für Zertifikate: Hier verwendet man eine so genannte PKI (Public Key Infrastructure, vgl. Kapitel 5), die die nötige Infrastruktur zur Verwaltung und Verteilung von digitalen Zertifikaten bereitstellt.
8.6.3
Authentifizierung mit Public-Key-Verschlüsselung (RSA)
Diese Art von Verschlüsselung benutzt ein asymmetrisches (Public-Key-)Verfahren, das zur Ver- und Entschlüsselung unterschiedliche, jedoch einander zugeordnete Schlüssel und Algorithmen benutzt. Die beiden Schlüssel werden unterschiedlich behandelt; es gibt einen öffentlichen Schlüssel und einen privaten Schlüssel. Der öffentliche Schlüssel (Public Key) darf jedermann bekannt sein, der private (Private Key) hingegen muss vertraulich bleiben und darf niemandem außer seinem Besitzer bekannt sein. Private Schlüssel werden in der Regel in verschlüsselter Form in speziellen Formaten auf Datenträgern oder Smartcards gespeichert. In Kapitel 4 wurden die asymmetrischen Verschlüsselungsverfahren ausführlich besprochen. Auch im IKE Main Mode verwendet man ein solches Verfahren zur Authentifizierung des Benutzers. Das Prinzip ist recht einfach: Die Seite, die sich identifizieren möchte, überträgt ihren mit dem öffentlichen Schlüssel der Gegenstelle verschlüsselten Nonce- und ID-Wert. Der Empfänger entschlüsselt die Daten und verifiziert sie. Dies kann aber niemand sonst nachvollziehen, da nur der Empfänger im Besitz des notwendigen privaten Schlüssels ist.
261
8 Das Internet-Key-Exchange-Protokoll
Die Art der Authentifizierung wird in den ersten beiden Nachrichten vereinbart. Die Nachrichten zum Schlüsseltausch unterscheiden sich wesentlich von denen zur Authentifizierung mit Signaturen oder einem Pre-Shared Key. Eine Vorbedingung dieses Verfahrens ist, dass der Initiator den öffentlichen Schlüssel des Responders, den er zum Verschlüsseln benötigt, bereits vor dem Austauschvorgang kennt. Ein Austausch von Zertifikaten zu diesem Zweck ist nicht möglich, da diese vorher übertragen werden müssten und damit nicht verschlüsselt werden können. Damit wäre jedoch die Identität der Teilnehmer an dem Austauschvorgang nicht mehr gewährleistet, was aber für diesen Austauschtyp obligatorisch ist. Üblicherweise werden die öffentlichen Schlüssel durch digitale Zertifikate verteilt, da hier eine zuverlässige Bindung der Identitäten der Teilnehmer an diesem Verfahren an ihre öffentlichen Schlüssel besteht. Initiator
Responder
Hdr SA
Nachricht 1 ...... Proposal n Transf. n
Proposal 1 Transf. 1
Nachricht 2 Hdr SA
Proposal
Transform
Nachricht 3 Hdr
KEi
[Hash(Cert)]
IDi
Ni
Verschlüsselt (RSA)
Nachricht 4 Hdr
KEr
IDr
Nr
Verschlüsselt (RSA)
Nachricht 5 Hdr
HASH_I Verschlüsselt (DES-CBC)
Nachricht 6 Hdr
HASH_R Verschlüsselt (DES-CBC)
Abbildung 8.19: Die Authentifizierung mittels RSA-Public-Key-Verschlüsselung im IKE Main Mode
In den Nachrichten zum Schlüsseltausch werden also, wie in Abbildung 8.19 zu sehen, neben den öffentlichen Diffie-Hellman-Werten auch der verschlüsselte Nonce-Wert und die verschlüsselte Identität des Initiators und in der
262
Der IKE Main Mode
vierten Nachricht umgekehrt auch die des Responders übertragen. Falls der Initiator mehrere öffentliche Schlüssel des Responders besitzt, muss der diesem weiterhin mitteilen, welchen er benutzt hat. Dies tut er, indem er einen Hashwert über das Zertifikat bildet, dessen Schlüssel benutzt wurde, und diesen Wert mit zum Responder schickt. Dieser kann anhand des Hashwertes ermitteln, welchen seiner privaten Schlüssel er zum Dechiffrieren benutzen muss. Bei der Verschlüsselung der Nonce- und Identitätswerte werden nur die Nutzdaten verschlüsselt. Die Payload-Header müssen unverschlüsselt bleiben, um die Art und vor allem die Länge der Nutzlast bekannt zu machen. Die verschlüsselten ID- und Nonce-Nutzdaten, hier durch ein vorangestelltes * gekennzeichnet, werden durch eine RSA-Verschlüsselung wie folgt erzeugt: *IDi = RSA(Kr_public, IDi) *Ni = RSA(Kr_public, Ni) *IDr = RSA(Ki_public, IDr) *Nr = RSA(Ki_public, Nr) Die Entschlüsselung der Informationen erfolgt mit den korrespondierenden privaten Schlüsseln von Initiator und Responder. Die letzten beiden Nachrichten innerhalb dieses Austauschvorgangs tauschen wieder die Hashwerte von Initiator und Responder aus, um eine abschließende Authentifizierung beider Identitäten und des vollständigen Austauschs vorzunehmen. Dieses Verfahren ist sehr zuverlässig, allerdings zu einem sehr hohen Preis. Denn beide Gegenstellen müssen jeweils vier RSA-Operationen durchführen, jeweils zwei zum Ver- und zwei weitere zum Entschlüsseln. Dies macht diese Art der Authentifizierung sehr rechenintensiv und in der Folge davon sehr langsam. Eine Ver- oder Entschlüsselung mit RSA ist etwa 1000fach langsamer als ein symmetrisches Verfahren wie DES. Dies wirft dann Probleme auf, wenn innerhalb einer kurzen Zeitspanne sehr viele ISAKMP-SAs aufgebaut werden müssen, wie es zum Beispiel in Remote-Access-VPNs der Fall ist. Also hat man dieses Verfahren etwas verändert und eine revidierte, schnellere Version der Public-Key-Verschlüsselung spezifiziert.
8.6.4
Authentifizierung mit revidierter Public-KeyVerschlüsselung (RSA)
Diese Version unterscheidet sich von der vorhergehenden dadurch, dass man einen der Verschlüsselungsschritte nicht mit RSA, sondern mit einem symmetrischen Verfahren durchführt. Die Menge der in den Schlüsseltausch-Nachrichten übertragenen Daten ist dadurch zwar etwas größer, aber die Ausführungszeit der notwendigen Berechnungen ist dafür wesentlich kürzer geworden.
263
8 Das Internet-Key-Exchange-Protokoll
Hier wird, wie in Abbildung 8.20 illustriert, nur der Nonce-Wert mit RSA verschlüsselt. Der Rest der Nutzdaten wird mit dem in den ersten beiden Nachrichten ausgehandelten symmetrischen Verfahren verschlüsselt, in unserem Fall also mit DES-CBC. Außer der Identität wird auch noch der öffentliche Diffie-Hellman-Wert verschlüsselt, was noch ein höheres Maß an Sicherheit in diesem Verfahren gewährleistet. Auch hier kann ein Hashwert übertragen werden, um ein bestimmtes Zertifikat zu indizieren, aus dem der benutzte öffentliche Schlüssel entnommen wurde. Die Schlüssel, die benötigt werden, um den öffentlichen Diffie-Hellman-Wert und den Nonce-Wert von Initiator und Responder zu verschlüsseln, wurden aus folgenden Werten berechnet: Kei = HMAC-MD5(Ni + Ci) Ker = HMAC-MD5(Nr + Cr) Initiator
Responder
Hdr SA
Nachricht 1 ...... Proposal n
Proposal 1 Transf. 1
Transf. n
Nachricht 2 Proposal
Hdr SA
Transform
Nachricht 3 Hdr [Hash(Cert)]
Ni
KEi
RSA
IDi
[Certificate_i]
DES-CBC
Nachricht 4 Hdr
Nr
KEr
RSA
IDr
DES-CBC
Nachricht 5 Hdr
HASH_I
DES-CBC
Nachricht 6 Hdr
HASH_R
DES-CBC
Abbildung 8.20: Die Authentifizierung durch die revidierte Public-Key-Verschlüsselung im IKE Main Mode
264
Der IKE Aggressive Mode
Es werden für beide Richtungen unterschiedliche Schlüssel verwendet. Falls ein Verschlüsselungsverfahren längere Schlüssel benötigt, als die 128 Bit, die HMAC-MD5 erzeugt, dann erfolgt so lange eine Verkettung des Hashwertes nach folgender Regel, bis die notwendige Gesamtlänge erreicht wurde: K = K1 + K2 +....+Kn Die benötigten Teilschlüssel K1 bis Kn werden wie folgt berechnet: K1 = HMAC-MD5(Kei + Ni + 0x00) K2 = HMAC-MD5(Kei + K1) ...... Kn = HMAC-MD5(Kei + Kn-1) Die zu übertragenden, mit DES verschlüsselten ID- und KE-Nutzdaten, hier durch ein vorangestelltes* gekennzeichnet, werden auf folgende Weise erzeugt: *IDi = DES(Kei, IDi) *IDr = DES(Ker, IDr) *KEi = DES(Kei, KEi) *KEr = DES(Ker, KEr) Da DES üblicherweise im CBC-Modus betrieben wird, werden hierfür Initialisierungsvektoren (IV) benötigt. Der erste IV besitzt den Wert 0x0000000000000000, die nachfolgenden erhalten den Wert des Chiffretextes der jeweils vorhergehenden Verschlüsselung. Die beiden letzten Nachrichten in diesem Austausch führen wieder die abschließende Authentifizierung durch die Hashwerte von Initiator und Responder durch.
8.7
Der IKE Aggressive Mode
Der IKE Aggressive Mode ist eine Instanziierung des ISAKMP Aggressive Exchange, der den Aufbau einer ISAKMP-Sicherheitsassoziation mit nur drei Nachrichten ermöglicht. Aufgrund der Struktur dieses Austauschvorgangs muss die IP-Adresse des Initiators nicht vorher bekannt sein und kann somit auch, zum Beispiel bei der Einwahl bei einem Internet Service Provider, dynamisch zugewiesen werden. Das Prinzip des IKE Aggressive Mode ist es, so viel an Informationen in die Nachrichten hineinzupacken, wie es zum gegebenen Zeitpunkt möglich ist. Allerdings hat dies auch seinen Preis, der hier in Form einer etwas reduzier-
265
8 Das Internet-Key-Exchange-Protokoll
ten Sicherheit gegen bestimmte Arten von Denial-of-Service-Angriffen in Erscheinung tritt. Der Grund besteht darin, dass bereits vor dem Umlauf der Cookies sehr rechenintensive Prozesse stattfinden. Weiterhin ist die Identität des Initiators bei einer Authentifizierung mittels Pre-Shared Key nicht geschützt, da dieser seine Identitätsinformationen bereits in die erste, noch unverschlüsselte Nachricht einfügt. Dies birgt andererseits den Vorteil, dass die IP-Adresse des Initiators nicht statisch sein muss. Die Aushandlungsmöglichkeiten sind ebenfalls etwas eingeschränkt, da in der ersten Nachricht bereits Werte übertragen werden, die bestimmte Voraussetzungen bedingen, die im Main Mode noch aushandelbar wären. Zum Beispiel wird der öffentliche Diffie-Hellman-Wert des Initiators bereits in der ersten Nachricht übermittelt. Also muss sich der Initiator schon zu diesem Zeitpunkt für eine Oakley-Gruppe entschieden haben und kann nicht mehr verschiedene Vorschläge mit verschiedenen Gruppen machen. Initiator
Responder
Hdr SA
Nachricht 1 Prop.1 Transf. 1 … Prop.n Transf. n KEi Ni IDi Nachricht 2
Hdr SA Proposal Transform KEr
Nr
IDr
HASH_R
Nachricht 3 Hdr
HASH_I
Abbildung 8.21: Der IKE Aggressive Mode mit Pre-Shared-Key-Authentifizierung
In praktischen Implementierungen, also zum Beispiel in einem RemoteAccess-VPN, in dem der IKE Aggressive Mode üblicherweise verwendet wird, ist diese Einschränkung jedoch nicht so einschneidend. Denn in solch einem abgeschlossenen Netz mit einer übergreifenden Sicherheitsstrategie und der Kenntnis der technischen Möglichkeiten der eingesetzten Systeme kennt der Initiator bereits die Sicherheitsstrategie und kann dem Responder ein relativ kurzes Proposal unterbreiten. Er muss nicht alle möglichen Kombinationen und Optionen dort hineinpacken, sondern kann ganz wenige, unter Umständen vielleicht sogar nur einen einzigen Vorschlag machen, von dem er weiß, dass ihn der Responder annimmt.
266
Der IKE Aggressive Mode
Ein anderes Szenario ist ein Extranet-VPN. Da hier oft Geräte verschiedener Hersteller in verschiedenen Firmen mit unterschiedlichen Sicherheitsstrategien eine ISAKMP-Sicherheitsassoziation aufbauen sollen, sind die Auswahlmöglichkeiten in der Regel reichhaltiger. Allerdings arbeiten solche Verbindungen meist zwischen IPSec-Security-Gateways, die eine feste IP-Adresse besitzen und somit im flexibleren IKE Main Mode arbeiten können.
8.7.1
Authentifizierung mit Pre-Shared-Secret
In unserem Beispiel in Abbildung 8.22 sehen Sie den Aufbau einer ISAKMPSicherheitsassoziation im IKE Aggressive Mode. Die Authentifizierung erfolgt durch Pre-Shared Secrets. In der ersten Nachricht schickt der Initiator der ISAKMP-Sicherheitsassoziation seine Vorschläge (SAi), seinen öffentlichen Diffie-Hellman-Wert (KEi), seinen Nonce-Wert (Ni) und seine Identitätsinformationen (IDi) zum Responder. Diese Nachricht ist unverschlüsselt und enthält im ISAKMP-Header nur das Initiator-Cookie. Somit muss der Responder mit seinen Berechnungen für den Schlüsseltausch beginnen, bevor er sein eigenes Cookie zurückbekommen hat. Er weiß somit noch nicht sicher, ob er auch tatsächlich mit dem Initiator kommuniziert. Initiator
Responder
Nachricht 1 Hdr SA Prop.1 Transf. 1 ...... KEi Ni
IDi
[Cert_Req]
Nachricht 2 Hdr SA Pro/Trans KEr Nr IDr [Cert_Req] [Cert] SIG_R
Nachricht 3 Hdr
[Cert]
SIG_I
Abbildung 8.22: Der IKE Aggressive Mode mit Signatur-Authentifizierung
Der Responder sucht nun aufgrund der ID-Informationen des Initiators den zugehörigen Pre-Shared Key aus seiner Datenbank und berechnet über das Diffie-Hellman-Verfahren seinen Hauptschlüssel (SKEYID) und alle weiteren, notwendigen Schlüssel. Deren Berechnung erfolgt in der gleichen Weise wie im IKE Main Mode.
267
8 Das Internet-Key-Exchange-Protokoll
Initiator
Responder
Nachricht 1 ...... [Hash(Cert)]
Hdr SA Prop.1 Transf.1
KEi
IDi Ni (RSA)
Nachricht 2 Hdr SA Prop.1/Trans. KEr
IDr
Nr
HASH_R
(RSA)
Nachricht 3 Hdr
HASH_I
Abbildung 8.23: Der IKE Aggressive Mode mit Public-Key-Authentifizierung
Der Responder berechnet außerdem seinen öffentlichen Diffie-Hellman-Wert und hat damit genügend Informationen, um seinen Hashwert HASH_R zu berechnen. Diesen Hashwert überträgt er zusammen mit seinem öffentlichen Diffie-Hellman-Wert (KEr), dem von ihm ausgewählten Vorschlag (SAr), seinem Nonce-Wert (Nr) und seiner Identitätsinformation (IDr) zum Initiator. Dieses Paket ist ebenfalls noch unverschlüsselt, enthält jetzt aber beide Cookies. Der Initiator kann nun sein Cookie verifizieren und anschließend seine Berechnungen vornehmen, um die erforderlichen Schlüssel zu erzeugen. Nachdem dies geschehen ist, erzeugt der Initiator seinen Hashwert HASH_I und überträgt ihn in der dritten und letzten Nachricht des IKE-AggressiveMode-Austauschs zum Responder. Diese Nachricht ist verschlüsselt, und das Cookie des Responders ist jetzt auch einmal »umgelaufen«. Er kann es auswerten und anschließend den erhaltenen Hashwert überprüfen, um den Initiator und den Austauschvorgang zu authentifizieren. Initiator
Responder
Nachricht 1 Hdr SA Prop.1 Tran.1 ...... [Hash(Cert)] Ni KEi IDi [Cert] RSA
DES-CBC
Nachricht 2 Hdr SA Prop.1/Trans. Nr RSA
KEr
IDr
HASH_R
DES-CBC
Nachricht 3 Hdr
HASH_I
Abbildung 8.24: Der IKE Aggressive Mode mit revidierter Public-Key-Authentifizierung
268
Der IKE Quick Mode
8.7.2
Authentifizierung mit digitaler Signatur
Auch hier werden nur drei Nachrichten benötigt, in denen alle benötigten Datenstrukturen enthalten sind. Der Unterschied zur Authentifizierung mit einem Pre-Shared Key besteht auch im Aggressive Mode darin, dass statt der Hashwerte HASH_I und HASH_R die digitalen Signaturen dieser Hashwerte übertragen werden. Optional können noch digitale Zertifikate übertragen werden. Auch hier gelten alle Einschränkungen wie im vorangegangenen Beispiel, insbesondere die, dass die Identitäten nicht verborgen sind und eine gewisse Gefahr durch Denial-of-Service-Angriffe besteht.
8.7.3
Authentifizierung mit standardisierter und revidierter Public-Key-Verschlüsselung
Die generelle Funktionsweise der Authentifizierung entspricht der im IKE Main Mode. Auch hier werden so viele Daten wie möglich in die Nachrichten gepackt. Hier werden auch nur drei UDP-Pakete zwischen Initiator und Responder ausgetauscht, um eine ISAKMP-Sicherheitsassoziation aufzubauen. Diese Art der Authentifizierung hat gegenüber den beiden vorher beschriebenen den großen Vorteil, auch im IKE Aggressive Mode die Identität der beteiligten Gegenstellen zu verbergen. Denn die Identitätsinformationen werden mit dem öffentlichen Schlüssel der jeweiligen Gegenstelle verschlüsselt und erst dann übertragen. Die Angriffspunkte für Denial-of-Service-Angriffe bleiben jedoch bestehen, weil vollständige Cookie-Umläufe bis zur Berechnung der Diffie-Hellman-Funktion nicht möglich sind. Auch mit der geänderten Methode der Public-Key-Verschlüsselung werden die Identität von Initiator und Responder geschützt, indem sie verschlüsselt übertragen werden. Die Berechnung der Schlüssel und die Verschlüsselung selbst erfolgen auf die gleiche Art wie im IKE Main Mode, wodurch eine insgesamt höhere Verarbeitungsgeschwindigkeit ermöglicht wird.
8.8
Der IKE Quick Mode
Der IKE Quick Mode basiert auf keinem ISAKMP-Austauschtyp, sondern existiert nur im IKE-Protokoll und ist immer an einen vorangegangenen Phase-1-Austausch gebunden. Mit dem Quick Mode, der nur in der IKEPhase 2, also unter dem Schutz einer in Phase 1 erzeugten ISAKMP-SA, möglich ist, werden die Sicherheitsassoziationen von IPSec oder anderen Sicherheitsprotokollen ausgehandelt. Innerhalb einer ISAKMP-SA können mehrere IPSec-SAs erzeugt werden. Es können auch innerhalb eines Quick-ModeAustauschvorgangs gleichzeitig mehrere SAs erzeugt werden.
269
8 Das Internet-Key-Exchange-Protokoll
Da durch die ISAKMP-SA bereits Dienste zur Integritätsprüfung, Authentifizierung und Sicherstellung der Vertraulichkeit zur Verfügung stehen, kann der Austausch durch nur insgesamt drei Nachrichten erfolgen. Es werden im Weiteren auch die Identitäten der Gegenstellen als gegeben angesehen, die sich in Phase 1 gegenseitig authentifiziert haben. Der Quick Mode erzeugt eine Sicherheitsassoziation für nachfolgende Sicherheitsprotokolle und benutzt daher ähnliche Mechanismen, wie es die ISAKMP-Austauschvorgänge in der Phase 1 tun. Auch hier werden Nonce-Werte erzeugt und ausgetauscht, um sich einerseits vor Angriffen durch wiederholtes Senden von Nachrichten zu schützen und andererseits neue Zufallswerte zur Generierung von Schlüsselmaterial zu erhalten. Zu diesem Zweck kann optional, falls die Sicherheitsstrategie dies vorschreibt, ein Austausch von neu erzeugten öffentlichen Diffie-Hellman-Werten stattfinden. Alle Pakete in Phase 2 werden verschlüsselt übertragen. Im ersten Paket des Initiators in unserem Beispiel, in dem eine IPSec-ESP-Sicherheitsassoziation mit Triple-DES und HMAC-MD5-96 erzeugt werden soll, müssen der Vorschlag (SA), der Nonce-Wert und der HASH_1 enthalten sein. Optional können noch Client-IDs (IDc) und im Fall von Perfect Forwarding Secrecy (PFS) der öffentliche Diffie-Hellman-Wert (KEi) übertragen werden. Initiator
Responder
Nachricht 1 Hdr
HASH_1
SA
Ni
KEi
IDi
IDr
IDi
IDr
Verschlüsselt
Nachricht 2 Hdr
HASH_2
SA
Nr
KEr
Verschlüsselt
Nachricht 3 Hdr
HASH_3
Verschlüsselt
Abbildung 8.25: Der IKE-Quick-Mode-Austausch erfolgt unter dem Schutz der ISAKMP-SA.
Der Hashwert HASH_1 wird auf folgende Weise ermittelt: HASH_1 = HMAC-MD5(SKEYID_a + MID + SA + Ni [+ KEi [+ Idci + IDcr]]) Die HMAC-Version des in Phase 1 bereits ausgehandelten MD5-Hashverfahrens wird als Pseudo Random Function (PRF) zum Erzeugen der Hashwerte benutzt. MID ist hierbei die Message ID aus dem ISAKMP-Header; die optio-
270
Der IKE Quick Mode
nalen Parameter sind in eckige Klammern gesetzt. Der Hashwert muss in jedem Paket unmittelbar auf den ISAKMP-Header folgen, und die SA-Nutzdaten in den ersten beiden Nachrichten müssen nach dem Hashwert eingefügt werden. Die Reihenfolge der restlichen Nutzdaten ist optional, mit Ausnahme der Client-IDs, die am Ende einer Nachricht stehen. Diese Client-IDs werden dann benutzt, wenn für einen anderen Initiator und Responder, als den in Phase 1 beteiligten, ein Quick-Mode-Austausch erfolgt. Der Responder verarbeitet die eingegangene Nachricht und konstruiert, falls kein Fehler aufgetreten ist und er einen Vorschlag des Initiators akzeptabel findet, die zweite Nachricht dieses Austauschvorgangs. Der Hashwert HASH_2 dieser Nachricht wird, je nach Nutzdaten, wie folgt erzeugt: HASH_2 = HMAC-MD5(SKEYID_a + MID + Ni + SA + Nr [+ KEr [+ IDcr]]) Auch hier kann im Falle von PFS optional der öffentliche Diffie-Hellman-Wert mit übertragen werden. Der Initiator verarbeitet die Nachricht und erzeugt die dritte und letzte Nachricht dieses Austauschvorgangs, in der nur der HASH_3 enthalten ist. Dieser Hashwert wird aus den folgenden Werten erzeugt: HASH_3 = HMAC-MD5(SKEYID_a + 0x00 + MID + Ni + Nr) Nachdem der Responder die Nachricht verarbeitet und den Hashwert überprüft hat, ist der Quick-Mode-Austausch abgeschlossen. Der Quick Mode berechnet auch die für die erzeugte IPSec-Sicherheitsassoziation benötigten Schlüssel. In unserem Beispiel wurde das IPSec-ESP-Protokoll ausgehandelt, mit HMAC-MD5-96 und Triple-DES als Funktionen zur Authentifizierung und Verschlüsselung. Insgesamt werden hierfür 320 Bit an Schlüsselmaterial benötigt. Diese 320 Bits bestehen aus 128 Bit für HMACMD5-96 und drei mal 64 Bit für Triple-DES. Beachten Sie, dass der Triple-DESAlgorithmus seine drei 56-Bit-Schlüssel aus den drei 64-Bit-Strings dadurch erzeugt, dass er jedes achte Bit daraus entfernt. Der in diesem Beispiel benötigte Grundschlüssel KEYMAT kann, je nachdem, ob PFS gefordert ist, auf zwei verschiedene Arten erzeugt werden. Im Fall von PFS wurden im Quick Mode öffentliche Diffie-Hellman-Werte zwischen Initiator und Responder ausgetauscht, die mit in die Berechnung einfließen. Aus diesen beiden Werten und ihrem privaten, geheimen Wert berechnen beide Seiten den identischen Wert KE als Ergebnis des Diffie-Hellman-Verfahrens. Der Grundschlüssel mit PFS wird wie folgt berechnet: KEYMAT = HMAC-MD5(SKEYID_d + KE + Protokoll + SPI + Ni + Nr) Die Werte für das Protokoll, in unsrem Fall IPSec-ESP, und den Security Parameter Index (SPI) stammen aus dem Paket, in dem der Vorschlag für die Sicherheitsassoziation ausgewählt wurde.
271
8 Das Internet-Key-Exchange-Protokoll
Das Ergebnis der HMAC-MD5-Funktion ist aber nur 128 Bit lang, also muss das benötigte 320 Bit lange Schlüsselmaterial (K) durch Verkettung dieses Wertes erzeugt werden: K = K1 + K2 + K3 mit K1 = HMAC-MD5(SKEYID_d + KE + Protokoll + SPI + Ni + Nr) K2 = HMAC-MD5(SKEYID_d + K1 + KE + Protokoll + SPI + Ni + Nr) K3 = HMAC-MD5(SKEYID_d + K2 + KE + Protokoll + SPI + Ni + Nr) Falls keine Perfect Forwarding Secrecy benötigt wird, erzeugt IKE den Grundschlüssel aus dem dafür vorgesehenen Grundschlüssel (SKEYID_d) der ISAKMP-Sicherheitsassoziation und den Nonce-Werten des vorliegenden Quick-Mode-Austauschs: KEYMAT = HMAC-MD5(SKEYID_d + Protokoll + SPI + Ni + Nr) Das Ergebnis der HMAC-MD5-Funktion ist auch in diesem Fall nur 128 Bit lang, also erfolgt wieder eine Verkettung: K = K1 + K2 + K3 mit K1 = HMAC-MD5(SKEYID_d + Protokoll + SPI + Ni + Nr) K2 = HMAC-MD5(SKEYID_d + K1 + Protokoll + SPI + Ni + Nr) K3 = HMAC-MD5(SKEYID_d + K2 + Protokoll + SPI + Ni + Nr) Aus diesen 384 Bit werden für das IPSec-ESP-Protokoll die ersten 192 Bit für Triple-DES und die folgenden 128 Bit für den HMAC-MD5-Algorithmus verwendet; der Rest bleibt ungenutzt.
8.9
Die Performance von IKE
Wie in den vorangegangenen Abschnitten deutlich wurde, werden in IKE eine ganze Reihe teilweise recht aufwendiger Rechenoperationen durchgeführt. Ihre Anzahl und Art richten sich ausschließlich nach der verwendeten Sicherheitsstrategie. So ist zum Beispiel der Aufbau einer IPSec-Sicherheitsassoziation unter Verwendung von Public-Key-Verfahren zur Authentifizierung und Perfect Forwarding Secrecy sehr aufwendig und langwierig zu berechnen, während der gleiche Vorgang mit einer Pre-Shared-Key-Authentifizierung ohne PFS um ein Vielfaches schneller ist. Man muss sich immer vor Augen halten, in welchen Dimensionen hier gerechnet wird. Asymmetrische (Public-Key-)Verfahren wie Diffie-Hellman oder RSA erzeugen und rechnen mit Primzahlen in Bereichen von 768 oder 1024 Bit, führen Berechnungen mit Exponenten im Bereich von 180 Dezimal-
272
Die Performance von IKE
stellen durch oder dividieren durch 1024 Bit große Primzahlen. Solche Operationen, die zudem nicht mit voller Unterstützung von numerischen Coprozessoren auf Basis Gleitkomma-Arithmetik durchgeführt werden können, verschlingen eine immense CPU-Zeit und auch einiges an Speicher für ihre Zwischenergebnisse. Auf Security-Gateways, die verschiedene Netze miteinander verbinden, fällt IKE nicht so sehr ins Gewicht, da es nur relativ selten aktiv ist und wenige SAs erzeugt und verwaltet. Hier kann man auch bedenkenlos die Intervalle für eine neue Schlüsselgenerierung auf kurze Werte oder übertragene Datenvolumina, z.B. 100 Mbyte oder 1 Gbyte, setzen und generell mit Perfect Forwarding Secrecy arbeiten. Im Fall von Remote-Access-VPNs sieht die Sache allerdings schon ganz anders aus, denn hier müssen oft in relativ kurzen Zeitspannen sehr viele Sicherheitsassoziationen erzeugt werden – pro Benutzer werden ja mindestens eine ISAKMP-SA und zwei unidirektionale IPSec-SAs erzeugt. Bei solchen Abschätzungen muss man ebenfalls berücksichtigen, dass solche Anmeldevorgänge auch bereits bestehende Verbindungen beeinflussen, indem sie die dort benötigten Ressourcen abziehen. Der magische Wert für Remote-Access-VPN-Konzentratoren, über den sich fast alle Hersteller leider beharrlich totschweigen, ist denn auch nicht so sehr der Datendurchsatz als solcher, sondern die Angabe, wie viele Anmeldungen pro Minute erfolgen können. Interessant ist in diesem Zusammenhang auch die etwas ketzerische Frage, ob während dieser Zeitspanne die 1000 vielleicht bereits angemeldeten Benutzer überhaupt noch Daten übertragen können oder ob der VPN-Konzentrator nur noch mit IKE-Funktionen beschäftigt ist.
8.9.1
IKE und Hardwarebeschleuniger
Der Datendurchsatz ist natürlich auch ein wichtiger Faktor, aber er ist durch den Hersteller am leichtesten in den Griff zu bekommen. Meist setzt man Beschleunigerhardware ein, die die symmetrischen und die Hashverfahren auf speziellen Chips abarbeitet. Für Public-Key-Verfahren gibt es leider nur ganz wenige Chipsätze, und diese besitzen oft auch nicht den Beschleunigungsfaktor von Chips zur Verarbeitung von symmetrischen Algorithmen. Also werden in sehr vielen Systemen, auch solchen mit Hardwareverschlüsselung, gerade die rechenintensiven Public-Key-Verfahren immer noch per Software implementiert. An dieser Stelle ein Tipp, falls Sie vor der Auswahl oder Beurteilung von Hardware- gegenüber Softwareverschlüsselung stehen: Sehr oft wird damit geworben, dass Hardwareverschlüsselung schneller als deren Softwarevariante sei. Dies stimmt nicht immer, es ist zwar sehr oft der Fall, insbesondere bei Algorithmen wie DES, die bereits als Hardwareverfahren entwickelt wurden, aber eben nicht immer. Algorithmen, die speziell zur Implementierung
273
8 Das Internet-Key-Exchange-Protokoll
in Software entworfen und optimiert worden sind, können unter Umständen sogar an Performance einbüßen, da die Verwaltung der Beschleunigerkarten durch das System sowie die Prozess- und die Datenverteilung eine gewisse Zusatzlast erzeugen. Man muss weiterhin sehr genau untersuchen, welche Protokolle die Hardware überhaupt unterstützt. Je größer die Protokollvielfalt, desto besser. Was aber auf alle Fälle unterstützt werden sollte, ist eine Hardware-Datenkompression, da die Kompression auf den Schichten unterhalb von IPSec sinnlos ist, da verschlüsselte Daten nicht mehr komprimiert werden können. Es sollte im Idealfall auch möglich sein, die Performance eines VPN-Konzentrators durch den Einsatz von mehreren, parallel betriebenen Hardwarebeschleunigern skalieren zu können. Die ideale Hardware würde RSA, Diffie-Hellman, DES, Triple-DES, MD5, SHA1 und IPSec-Kompression mit entsprechenden Chipsätzen unterstützen, so dass das Muttersystem die rechenintensiven Prozesse auf die Karten auslagern kann. Insbesondere für IKE sollten Diffie-Hellman und RSA durch spezielle Chipsätze bearbeitet werden können, ansonsten bringt eine Beschleunigerkarte keinen nennenswerten Performance-Gewinn. Ein kleines Beispiel soll verdeutlichen, welche Leistungssteigerung gute Beschleuniger-Chips bringen können. Die kalifornische Firma Hi/fn stellt verschiedene Chips her, die speziell zum Beschleunigen von kryptographischen Algorithmen entwickelt wurden. Zum Vergleich nehmen wir zwei Chips dieser Firma. Einer davon, der Hi/fn 6500, besitzt ein spezielles Maskendesign zur Beschleunigung von modularer Arithmetik. Der andere Chip, der Hi/fn 7901, ist ein spezieller Beschleuniger für symmetrische Verfahren, der »nur« eine normale Integer-CPU für Public-Key-Verfahren eingebaut hat. Hi/fn 7901, Integer-CPU
Hi/fn 6500, Public-Key-ASIC
Pre-Shared Key
6 IKE-SA/Sekunde
300 IKE-SA/Sekunde
Digitale Signatur
1,5 IKE-SA/Sekunde
115 IKE-SA/Sekunde
Tab. 8.1: Vergleich zwischen Integer-CPU und ASIC-Design zur Beschleunigung von PublicKey-Arithmetik
Zum Vergleich habe ich zwei verschiedene IKE-Aushandlungen herangezogen, einmal eine Authentifizierung mit Pre-Shared Key, die zwei Public-KeyBerechnungen (Diffie-Hellmann, 1024 Bit) benötigt, und zum anderen eine Authentifizierung mit digitaler Signatur. Der zweite Fall ist wesentlich aufwendiger. Er benötigt pro Gegenstelle zwei 1024-Bit-Diffie-Hellman-Berechnungen (Oakley-Gruppe.2), eine 1024-Bit-RSA-Verschlüsselung und zwei 1024-Bit-RSA-Entschlüsselungen.
274
Die Performance von IKE
Man kann sehr gut erkennen, wie groß der Unterschied zwischen einer »normalen« Integer-CPU und einem speziellen Maskendesign für bestimmte Public-Key-Algorithmen ist. Falls Sie vor der Auswahl von Hardwarebeschleunigern stehen, sollten Sie sich sehr genau darüber informieren, wie die Karte und die verwendeten Chips aufgebaut sind, ansonsten können Sie leicht unangenehme Überraschungen erleben. Als sehr sinnvoll erweisen sich Designs mit getrennten Chips für symmetrische und asymmetrische Verfahren oder neue »Super-Chips«, die beide Methoden in Form eines entsprechenden Maskendesigns unterstützen.
275
9
Das Layer 2 Tunneling Protocol
Das Layer 2 Tunneling Protocol (L2TP) unterscheidet sich grundsätzlich von IPSec. IPSec ist primär ein Sicherheitsprotokoll auf IP-Ebene mit der Option, IP-Pakete zu tunneln. L2TP hingegen ist ein reines Tunneling-Protokoll auf PPP-Ebene, das auch andere Protokolle als nur IP einkapseln kann. Das Layer 2 Tunneling Protocol wurde entwickelt, um PPP (Point-to-Point Protocol, ein Verfahren zum Transport von Netzwerkprotokollen über Punktzu-Punkt-Verbindungen) die Datenkommunikation über andere als Punktzu-Punkt-Verbindungen zu ermöglichen. Sein vorrangiges, aber nicht ausschließliches Einsatzgebiet ist daher der »virtuelle« Remote Access über Wählverbindungen und ein IP-Netzwerk. L2TP ist als Verbesserung und Weiterentwicklung zweier älterer, nicht standardisierter Verfahren, des Point-to-Point Tunneling Protocol (PPTP) und des Layer 2 Forwarding (L2F), zu verstehen. Die generelle Struktur und die jeweiligen Vorteile beider Verfahren wurden in das Layer 2 Tunneling Protocol, das im RFC 2661 beschrieben ist, übernommen. Obwohl sowohl PPTP als auch L2F heute noch in bestehenden Installationen verwendet werden, findet keine Weiterentwicklung der beiden Verfahren mehr statt, und in neuen Projekten wird zunehmend L2TP als Tunnelingverfahren und IPSec als Sicherheitsprotokoll eingesetzt.
9.1
Das Point-to-Point Protocol (PPP)
Um L2TP richtig verstehen zu können, muss man auch die Arbeitsweise von PPP verstehen. Das Point-to-Point Protocol wurde entwickelt, um verschiedenste Netzwerkprotokolle wie IP, IPX, Appletalk usw. über eine Punkt-zuPunkt-Verbindung zu übertragen. Derartige Verbindungen kommen bei leitungsvermittelnden Netzen oder Festverbindungen vor. Vor der Entwicklung von PPP wurden diese Verbindungen mit proprietären, meist auf Basis von HDLC (High-Level Data Link Control) arbeitenden Verfahren betrieben. PPP ermöglichte erstmals Punkt-zu-Punkt-Verbindungen auch zwischen Produkten verschiedener Hersteller. Mittlerweile ist dieses Protokoll in praktisch jedem Router und jedem Rechner (z.B. Microsoft DFÜ-Netzwerk, Unix-pppd) implementiert. Der Zugriff auf das Internet über Wählverbindungen, den die Internet Service Provider (ISP) weltweit anbieten, basiert fast ausschließlich auf PPP; auch bei Festverbindungen niedriger Bandbreite wird es im ISPUmfeld sehr oft benutzt.
277
9 Das Layer 2 Tunneling Protocol
9.1.1
PPP-Remote-Access
In Abbildung 9.1 sehen Sie ein typisches Unternehmensszenario für einen Remote Access, in dem sich ein Rechner per Wählverbindung über einem Remote Access Concentrator (RAC) Zugriff auf ein Intranet verschafft. Sowohl im PC als auch im RAC übernimmt das PPP-Protokoll die Aufgabe, diese Punkt-zu-Punkt-Verbindung zu initialisieren, aufrechtzuerhalten und zu beenden. In PPP sind alle Gegenstellen (Peers) gleichwertig, es gibt weder eine dedizierte Server- oder Clientfunktionalität noch ein rollenbasierendes Verhalten wie Initiator oder Terminator. Es ist auch nicht unbedingt notwendig, dass die PPP-Gegenstellen immer den gleichen Funktionsumfang unterstützen. Die Kommunikationsoptionen und -parameter können während der Initialisierungsphase untereinander ausgehandelt werden. Lediglich wenn bestimmte Funktionen von einer Seite als zwingend erforderlich angesehen werden und die Gegenstelle diese nicht in ausreichend erscheinendem Maße unterstützen kann, wird ein Verbindungsaufbau abgebrochen. Dies ist aber nur in ganz wenigen Fällen gegeben, zum Beispiel dann, wenn eine Seite Datenverschlüsselung auf PPP-Ebene möchte und die andere dies nicht kann. Rechnermit DFÜ-Client ISDN PSTN GSM
Intranet
Wählverbindung
Remote Access Concentrator (RAC)
Point-to-Point Protocol (PPP) Abbildung 9.1: Remote Access mit PPP über Wählverbindungen
9.1.2
PPP-Komponenten
PPP basiert auf dem HDLC-Protokoll, allerdings nur insoweit, als es dessen Rahmenstruktur benutzt. Die HDLC-Adressierung wird nicht benutzt, da nur zwischen zwei Endpunkten kommuniziert wird. Die Adressfelder dienen nur zur Identifikation von PPP-Rahmen, indem dort feste, definierte Werte eingesetzt werden. PPP kann man – in Abhängigkeit von ihrer Funktion – in verschiedene, in der PPP-Terminologie als Sublayer bezeichnete Schichten untergliedern. Wie Sie in Abbildung 9.2 sehen, gibt es für jede dieser Funktionen in den verschiedenen Schichten Steuerprotokolle zur Aushandlung und Konfiguration dieser Dienste und die implementierten Dienste selbst, die die zu übertragenden Pakete entsprechend umformen oder Prozeduren wie die Authentifizierung durchführen.
278
Das Point-to-Point Protocol (PPP)
Die Multiplex-Schicht In dieser Schicht konfigurieren die Steuerprotokolle die spätere Behandlung und den Transport von Paketen der zu übertragenden Netzwerkprotokolle (wie IP oder IPX). Dies betrifft die Bekanntgabe oder Zuweisung von Netzwerkadressen, die Übermittlung notwendiger Parameter für bestimmte Protokolle usw. Die beiden wichtigsten Protokolle sind das IPCP (IP Control Protocol) und das IPXCP (IPX Control Protocol). PPP ermöglicht die Übertragung einer ganzen Reihe weiterer Netzwerkprotokolle, jedoch hat sich IP derart stark durchgesetzt, dass diese praktisch keine Rolle mehr spielen.
Verarbeitung Multiplex-Schicht - Netzwerkprotokoll-Verteilung Dienste-Schicht - Kompression - CHAP, PAP
Steuerungsprotokoll IPCP IPXCP CCP Auth. ECP
- Verschlüsselung Medienabhängige Schicht - HDLC-Adressierung
LCP
- Framing, Escaping - Frame Check Sequence (FCS) Abbildung 9.2: Die verschiedenen Verarbeitungsschichten in PPP
In der Datenphase wird in dieser Schicht das Multiplexen und Demultiplexen der Netzwerkpakete vorgenommen. Da PPP die gleichzeitige Übertragung verschiedener Protokolle ermöglicht, müssen ausgehende Pakete gekapselt und gekennzeichnet werden. Ankommende Pakete müssen aufgrund der Kennzeichnungen in den PPP-Frames zur korrekten Weiterverarbeitung in den richtigen Netzwerk-Stack geleitet werden. Die Dienste-Schicht In diesem Bereich werden Dienste angesiedelt, die die zu übertragenden Daten umformen oder Funktionen wie die Authentifizierung durchführen. Üblicherweise sind im PPP die Authentifizierungsprotokolle PAP und CHAP verfügbar; mittlerweile bietet das EAP (Extensible Authentication Protocol)
279
9 Das Layer 2 Tunneling Protocol
auch weiter reichende Funktionen und die Möglichkeit, herstellerspezifische Verfahren einzubinden. Weitere Dienste sind die Datenkompression und in manchen, seltenen Fällen auch die Datenverschlüsselung. Entsprechende Steuerprotokolle handeln zwischen den PPP-Gegenstellen die notwendigen Optionen und Parameter aus. Als wichtigstes Protokoll in diesem Bereich ist das CCP (Compression Control Protocol) zu nennen, das die Datenkomprimierung steuert und damit Bandbreite und dadurch Übertragungskosten einsparen kann. Die medienabhängige Schicht Hier spielt als Steuerprotokoll das LCP (Link Control Protocol) die Hauptrolle. Sobald über eine Punkt-zu-Punkt-Verbindung eine PPP-Session gestartet wird, erwacht das LCP zum Leben und konfiguriert das Verhalten der Gegenstellen. LCP definiert bestimmte Dienste, wie zum Beispiel die Authentifizierung, die in der Dienste-Schicht angesiedelt sind. Somit erstreckt sich der Wirkungsbereich des Link Control Protocol über die Grenzen der medienabhängigen Schicht hinaus. Die Dienste in dieser Schicht übernehmen die Konstruktion von PPP-Frames, die Berechnung von Prüfsummen und alles andere, was notwendig ist, um ein PPP-Paket an die darunter liegende Übertragungsschicht weiterzuleiten.
9.1.3
PPP-Steuerungsprotokolle und -Dienste
Die Steuerprotokolle haben eine zentrale Bedeutung, denn sie handeln die gewünschten Dienste zwischen zwei PPP-Gegenstellen aus und konfigurieren sie anschließend auch interaktiv. Man unterscheidet dabei grundsätzlich zwischen Link-, Dienst- und Netzwerksteuerprotokollen, je nachdem auf welcher Ebene sie angesiedelt sind. Im Folgenden werden einige wichtige und in praktisch allen PPP-Implementierungen vorhandene Protokolle erläutert: 왘 Das Link Control Protocol (LCP) 왘 Das Password Authentication Protocol (PAP) 왘 Das Challenge Handshake Authentication Protocol (CHAP) 왘 Das Compression Control Protocol (CCP) 왘 Das IP Control Protocol (IPCP)
Das Link Control Protocol (LCP) Das LCP (Link Control Protocol) ist das Protokoll, das immer in der Startphase jeder PPP-Verbindung ausgeführt wird. Es legt die eigentlichen, medienabhängigen Parameter fest und handelt anschließend die im Weiteren auszuführenden Steuerprotokolle und Dienste aus. Dies sind in der Praxis Authenti-
280
Das Point-to-Point Protocol (PPP)
fizierungsverfahren, Datenkompression und Netzwerksteuerprotokolle zur Konfiguration der Übertragung von IP, IPX usw. über die PPP-Verbindung. Diese Konfiguration wird in Form einer Reihe von Anfragen, Antworten, Änderungsvorschlägen oder Ablehnungen durchgeführt. Dieser Vorgang kann auch asynchron erfolgen; eine Gegenstelle wartet mit ihrer nächsten Anfrage nicht, bis ihre vorherige beantwortet ist. In einer Anfrage können auch mehrere Optionen enthalten sein. Im PPP-Standard sind Configure Request (REQ), Configure Acknowledge (ACK), Configure Negative Acknowledge (NAK) und Configure Reject (REJ) als LCP-Botschaften zwischen PPP-Peers spezifiziert. Das Password Authentication Protocol (PAP) PAP ist ein relativ einfach aufgebautes Authentifizierungsprotokoll. Es wird von der zeitlichen Abfolge her zwischen der LCP- und der NCP-Phase ausgeführt und entscheidet, ob eine Verbindung weiter aufgebaut oder unmittelbar beendet wird. Es ist in einem eigenen Standard, dem RFC1334, beschrieben. Die Authentifizierung erfolgt, indem die Seite, die ihre Identität nachweisen muss, der Gegenstelle einen Authenticate Request schickt, in dem die Peer-ID (üblicherweise der Benutzername) und ein Passwort im Klartext enthalten sind. Die Gegenstelle überprüft das Passwort und schickt, falls es richtig ist, ein Authenticate Acknowledge, ansonsten ein Authenticate Negative Acknowledge zurück und beendet die Verbindung. Dies ist natürlich vom Standpunkt der Sicherheit aus betrachtet nicht gerade berauschend, denn jeder, der Zugriff auf die Übertragung oder Leitung hat, bekommt eine User-ID samt zugehörigem Passwort praktisch auf dem Präsentierteller geliefert. Dies hat zur Entwicklung eines weiteren Authentifizierungsprotokolls geführt, des Challenge Handshake Authentication Protocol. Das Challenge Handshake Authentication Protocol (CHAP) Dieses Protokoll ist fortschrittlicher als PAP, denn hier erfolgt die Authentifizierung in einem dreiphasigen Handshake-Verfahren, ohne dass dabei überhaupt ein Passwort übertragen wird. Die Funktionsweise ist in Kapitel 5 ausführlich beschrieben. Das Wesentliche bei CHAP ist, neben seiner höheren Sicherheit, auch die Option, das Protokoll während einer bestehenden PPP-Session mehrfach in unregelmäßigen, nicht vorherbestimmbaren Zeitabständen auszuführen. Damit kann man verhindern, dass ein Angreifer die Verbindung »stiehlt« und mit gefälschten IP-Adressen die Kommunikation weiterzuführen versucht. Dies kann er nur bis zum nächsten CHAP-Zyklus tun, denn dann muss er als PPP-Peer einen Hashwert berechnen, ohne dass er das CHAP-Secret kennt. Der Angreifer kann dann entweder gar keine oder nur eine falsche CHAPResponse generieren, und die Verbindung wird beendet.
281
9 Das Layer 2 Tunneling Protocol
Das Compression Control Protocol (CCP) Mit dem CCP handeln PPP-Gegenstellen einen Algorithmus zur Datenkompression aus. Es ist eine ganze Reihe von Algorithmen spezifiziert, jedoch werden von den meisten PPP-Implementierungen nur wenige unterstützt. Die häufigsten sind die Algorithmen von Stack Electronics (Stack LZS) und Microsoft (MPPC), eine Variante von LZS. Im Remote-Access-Bereich sollte aufgrund der Dominanz von Microsoft bei den Clients in jedem Fall dessen Point-to-Point Compression (MPPC) verfügbar sein. Das IP Control Protocol (IPCP) Das wichtigste Protokoll im Bereich der Netzwerksteuerprotokolle ist das IP Control Protocol (IPCP), das die Konfiguration des Internet-Protokolls innerhalb der PPP-Session steuert. Neben der Publizierung oder Zuweisung von IP-Adressen und Netzwerkmasken können optional auch DNS- oder WINSAdressen zugewiesen werden. Wie in allen Steuerprotokollen werden hier keine IP-Pakete selbst übertragen, dies erfolgt erst in der Datenphase.
9.1.4
PPP-Verbindungsaufbau
In Abbildung 9.3 ist der zeitliche Ablauf einer PPP-Verbindung von der Initialisierung durch eine Seite bis hin zur Datenphase dargestellt. In der LCPPhase werden die physikalischen Verbindungsparameter und weitere Steuerprotokolle ausgehandelt. Sobald sich die Gegenstellen geeinigt haben, wird das spezifizierte Authentifizierungsprotokoll, im beschriebenen Fall CHAP (Challenge Handshake Authentication Protocol, vgl. Kapitel 5), gestartet. Falls die Authentifizierung erfolgreich ist, werden die weiteren Protokolle gestartet, falls nicht, wird die PPP-Verbindung sofort beendet. In unserem Beispiel konfiguriert das CCP (Compression Control Protocol) anschließend das Datenkompressionsverfahren, das verwendet werden soll. Falls sich die beiden Gegenstellen nicht einigen können, wird hier, im Gegensatz zur fehlgeschlagenen Authentifizierung, die Verbindung nicht terminiert, sondern die Daten werden eben unkomprimiert übertragen. Anschließend wird das IPCP (IP Control Protocol) ausgeführt, das die beiden Gegenstellen für die Übertragung von IP-Paketen über die PPP-Verbindung konfiguriert. Es können auch während einer Session mehrere Netzwerkprotokolle wie IPX, NetBEUI, VinesIP usw. übertragen werden. PPP ist üblicherweise so implementiert, dass nur in ganz wenigen Fällen keine Verbindung zustande kommt. Sobald beide Gegenstellen in der Lage sind, PPP-Pakete zu übertragen, und die Authentifizierung erfolgreich war, gibt es immer einen kleinsten gemeinsamen Nenner, auf den sich beide Gegenstellen einigen können. Wenn bestimmte Funktionen oder Parameter
282
Das Point-to-Point Protocol (PPP)
nicht möglich sind, ihr Fehlen aber keine fatalen Folgen hat, werden sie ignoriert, oder es werden andere Werte ausgehandelt – Hauptsache, man hat eine Verbindung. Es gibt in der Praxis auch nur wenige Fälle, in denen ein Abbruch erfolgt, obwohl eine Übertragung von PPP-Paketen möglich wäre: bei fehlgeschlagener Authentifizierung, falls überhaupt kein Netzwerksteuerprotokoll ausgehandelt werden konnte oder falls eine Seite PPP-Verschlüsselung will und die Gegenseite diese nicht unterstützt. PPP-Endpunkt B
PPP-Endpunkt A LCP Configure Request A LCP Configure Request B
LCP Configure Acknowledge B LCP Configure Acknowledge A CHAP Challenge CHAP Response CHAP Accept CCP Configure Request B CCP Configure Acknowledge A IPCP Configure Request B IPCP Configure Acknowledge A
IP-Paketübertragung (komprimiert) Abbildung 9.3: Der PPP-Verbindungsaufbau
Somit stellt sich PPP als wirklich robustes Protokoll auf OSI-Ebene 2 dar, das aus diesem Grund eine weite Verbreitung im Bereich von Wähl- und zunehmend auch von Festverbindungen gefunden hat. Insbesondere Einwahlkonzentratoren benutzen fast ausschließlich PPP. Es hat sich daher auch als integraler Bestandteil von Betriebssystemen wie Windows, MacOS, Linux oder OS/2 durchgesetzt, so dass dort keine zusätzliche Software für RemoteAccess-Funktionalität mehr notwendig ist.
283
9 Das Layer 2 Tunneling Protocol
9.2
PPP-Tunneling mit L2TP
Die Nachteile einer Standard-Remote-Access-Lösung aus Sicht des Endkunden sind allerdings nicht unerheblich. Zum einen sind die Übertragungsgebühren hoch, vor allem, wenn viel in der Fernzone oder gar im Ausland gearbeitet wird. Zum anderen ist die Auslastung oft unbefriedigend oder, im anderen Extrem, werden die Konzentratoren überlastet. Im ersteren Fall sind nicht immer alle Ports belegt, also sind die Kosten pro Nutzer hoch, im anderen Fall ist das Gerät sehr oft überlastet, und die Benutzer finden besetzte Leitungen vor. Die ständige Kapazitätsüberwachung und -planung erfordern weitere Ressourcen, ebenso die Wartung des Remote-Access-Equipments. Aus Sicht des Endkunden wäre es daher schön, die Technologie nicht selbst zu betreiben. Allerdings würde er die Verbindungen schon gern selbst terminieren, vor allem auch zur Benutzer-Authentifizierung. Es gibt aber kein einzelnes System, das all dies erledigt. Nun kommt das Layer 2 Tunneling Protocol ins Spiel, in dem der Remote Access Concentrator, wie in Abbildung 9.4 zu sehen ist, in zwei Funktionseinheiten und vor allem in zwei separate Geräte unterteilt wird. Das eine Gerät, das von einem Carrier oder ISP betrieben wird, terminiert die Wählverbindungen und den medienabhängigen Teil von PPP, und das zweite Gerät auf der Seite des Endkunden terminiert die höheren Schichten der PPP-Sessions. Die Verbindung zwischen den beiden Funktionseinheiten erfolgt über einen L2TP-Tunnel. Auf diese Weise liegt die reine Einwahl, der Betrieb der Geräte, die Kapazitätsplanung usw. auf der Seite der Service Provider, während die Terminierung und vor allem auch die Steuerung und Konfiguration der PPPVerbindungen auf der Seite des Endkunden angesiedelt ist.
ISDN PSTN GSM
LAC
Internet
L2TP PPP L2TP-Tunnel Abbildung 9.4: Virtueller Remote Access mit L2TP
284
LNS
Intranet
Rechner mit DFÜ-Client
PPP-Tunneling mit L2TP
9.2.1
Virtueller Remote Access mit L2TP
In der L2TP-Terminologie bezeichnet man die Funktionalitäten als LAC (L2TP Access Concentrator) und LNS (L2TP Network Server). In Wirklichkeit hat man dafür oft keine speziellen Geräte, sondern die notwendigen Funktionen werden in bereits vorhandenes Equipment implementiert. So können viele Einwahlkonzentratoren sowohl selbst PPP terminieren als auch gleichzeitig als LAC arbeiten und die PPP-Pakete tunneln. Auf der anderen Seite haben viele Router eine zusätzliche LNS-Funktionalität erhalten und können L2TP-Tunnel und die darin enthaltenen PPP-Verbindungen terminieren. Letzteres ist aber, und das muss an dieser Stelle erwähnt werden, oft ein extremes Performance-Problem. Denn der Remote Access Concentrator wird dadurch entlastet, dass er als LAC nur noch einen kleinen Teil der PPP-Funktionalität behält; der Router bekommt hingegen sehr, sehr viel zusätzliche Arbeit, da er nun alle PPP-Sessions anstelle des RAC terminieren muss. Und das ist etwas, wofür ein Router in der Regel von seinem Systemdesign her nicht ausgelegt ist. Lediglich wirklich neue Entwicklungen oder spezielle VPN-Systeme, die dieser Technologie Rechnung tragen, sind für einen LNS-Einsatz geeignet. In Abbildung 9.5 sind schematisch die Komponenten von L2TP dargestellt. Durch den Tunnel werden sowohl die PPP-Sessions als auch eine Steuerverbindung übertragen, über die der LAC und der LNS miteinander kommunizieren. Als Tunnelmedium dient heutzutage fast ausschließlich IP; dies ist jedoch nicht zwingend, man kann mit L2TP auch direkt auf niedrigeren Protokollen wie ATM oder Frame Relay aufsetzen – oder auch auf Ethernet, denn auf diese Weise, nämlich L2TP über Ethernet, realisiert man in der Regel die Multilink-Multichassis-Funktionalität in Einwahlkonzentratoren. In einem L2TP-Tunnel können mehrere PPP-Sessions existieren. Sobald die letzte Session abgebaut wurde, baut die Steuerverbindung auch den Tunnel selbst ab.
-
Abbildung 9.5: Die Komponenten des Layer-2-Tunneling-Protokolls 285
9 Das Layer 2 Tunneling Protocol
In der Spezifikation des Layer 2 Tunneling Protocol werden bestimmte Begriffe verwendet, deren Bedeutung im L2TP im Folgenden geklärt werden sollte. Call Als Call bezeichnet man eine PPP-Verbindung innerhalb eines L2TP-Tunnels. Der Name kommt daher, dass es sich bei der physikalischen Verbindung meist um eine Wählverbindung (Telefonie, Switched Virtual Circuits usw.) handelt. Innerhalb eines L2TP-Tunnels können ein, mehrere oder auch gar kein Call aktiv sein. Control Connection Innerhalb eines L2TP-Tunnels existiert genau eine Steuerverbindung zwischen LNS und LAC. Diese Verbindung steuert den Auf- und Abbau von Calls und Tunneln und überwacht den Zustand eines existierenden Tunnels. Tunnel Im Sinne von L2TP existiert ein Tunnel zwischen LAC und LNS, sobald eine Control Connection zwischen beiden besteht.
9.2.2
PPP-Session-Verteilung in L2TP
Bevor wir uns die Funktionalität und den Aufbau von L2TP näher ansehen, sollte eine Frage geklärt werden, die sich beim Lesen der vorangegangenen Absätze vermutlich bereits aufgedrängt hat. Woher weiß der LAC eigentlich, zu welchem LNS er die PPP-Sessions zu tunneln hat? Die Praxis sieht ja so aus, dass die Provider Hunderte oder Tausende von Einwahlkonzentratoren weltweit betreiben und eine Vielzahl von Kunden betreuen. Diese Kunden legen ihre User aber selbst an und authentifizieren sie auch selbst in ihrem LNS. Der Provider kennt also nicht die Zuordnung von Benutzernamen zu Kundenunternehmen, außerdem kommt hinzu, dass durchaus auch mehrere gleiche Usernamen vorkommen können, da die Kunden nichts voneinander wissen und somit identische IDs vergeben können. Der LAC muss also folgende Entscheidungen treffen: 1. Ist die PPP-Verbindung lokal zu terminieren? 2. Ist die PPP-Verbindung auf einem ihm bekannten LNS zu terminieren? 3. Existiert bereits ein Tunnel dorthin, oder muss er vorher aufgebaut werden?
286
PPP-Tunneling mit L2TP
Es gibt in der Praxis zwei Lösungen für dieses Problem: zum einen eine Zuordnung der PPP-Session aufgrund eines Zusatzes im Benutzernamen, der während der Authentifizierung zum RAC geschickt wird, und zum anderen eine Zuordnung aufgrund der angerufenen Nummer, die beim Rufaufbau übermittelt wird. Beide Möglichkeiten sind in Abbildung 9.6 dargestellt. Call-Verteilung aufgrund des Benutzernamens In diesem Fall wird den User-IDs der Kunden eine so genannte Domain-Kennung angehängt (Suffix) oder vorangestellt (Präfix). Aus dem Benutzernamen mlipp würde dabei beispielsweise
[email protected] werden. Anhand des Suffixes nortelnetworks.com erkennt das Authentifizierungssystem des Service Providers, dass es sich um einen User handelt, der zu einem bestimmten LNS getunnelt werden muss. In seiner Datenbank befindet sich auch der entsprechende Eintrag mit den notwendigen Parametern, um einen Tunnel dorthin aufzubauen. Es ist offensichtlich, dass der LAC in diesem Fall das LCPProtokoll und sogar einen Teil des Authentifizierungsprotokolls abwickeln muss. Denn erst dann, wenn die sich einwählende PPP-Gegenstelle ihre Identität in Form eines Benutzernamens bekannt gibt, kann der LAC anhand des Suffixes oder Präfixes entsprechend agieren. Da aber die Authentifizierungsphase nach Beendigung des LCP erfolgt, muss das Link Control Protocol komplett vom LAC abgewickelt werden. Der LNS bekommt von der Verbindungsaushandlung erst einmal gar nichts mit. Falls im LCP als Authentifizierungsprotokoll CHAP ausgehandelt wird, muss der LAC sogar ein CHAP-Challenge erzeugen. Als erstes Indiz für einen neuen Call bekommt der LNS ein Authentifizierungspaket vom LAC zugeschickt, in dem User-ID und Kennwort (PAP-Authentifizierung) oder CHAP-Challenge, CHAP-Response und User-ID (CHAP-Authentifizierung) enthalten sind. Falls der LNS selbst mit der sich einwählenden PPP-Gegenstelle über LCP die Verbindung aushandeln will, kann er durch den L2TP-Tunnel selbst noch einmal LCP starten. Dabei können alle bereits zwischen PPP-Client und LAC ausgehandelten Optionen, inklusive des Authentifizierungsprotokolls, neu ausgehandelt werden, und es wird eine neue Authentifizierung durchlaufen. Dies ist ein mögliches Verhalten des LNS. Ein anderes, schnelleres, besteht darin, die vom LAC begonnene Authentifizierung zu komplettieren, sich die bereits ausgehandelten LCP-Optionen mitteilen zu lassen und zu prüfen, ob sie akzeptabel sind. Nur falls dies nicht der Fall ist, kann der LNS noch einmal das LCP starten.
287
9 Das Layer 2 Tunneling Protocol
Client A
Netzwerk B
User-ID:
[email protected] 109.244.1.2
LNS
LAC ISDN PSTN
Internet Netzwerk A
TMS Client B
144.10.23.1
Ruft 071175234 an
LNS Tunnel-Management-Server (TMS) Datenbank
Call placement (DNIS=071175234)
DNIS
Endpoint
0711 75234 0605 14625 ..... .....
144.10.23.1 F5sg2H 192.20.3.4 ga67h
L2TP L2TP
LCP/Auth (
[email protected])
Domain
Endpoint
Secret
Type
nortel.com pearson.de .... ....
109.244.1.2 190.19.3.9
g28Gh4 9sgtaz
L2TP L2TP
L2TP-Tunnel
Secret
Type
PPP-Session
Abbildung 9.6: Call- und Tunnelverteilung aufgrund der angerufenen Nummer (DNIS, Dialed Number Information String) oder eines Zusatzes im Benutzernamen
Call-Verteilung aufgrund der gewählten Nummer Dieses Verfahren macht sich den Umstand zunutze, dass ein physikalischer Telefonanschluss über mehrere Nummern aus einem so genannten Rufnummernblock erreichbar sein kann. Jeder Kunde bekommt also eine eindeutige Nummer, mit der er sich beim Provider einwählt. Die angerufene Nummer wird bei der Einwahl dem Authentifizierungssystem übergeben, das zu dieser Nummer (DNIS, Dialed Number Information String) einen entsprechenden Eintrag in seiner Datenbank hat. In diesem Fall nimmt der LAC überhaupt nicht an der Authentifizierung teil. Diese und der größte Teil der LCP-Aushandlungen finden direkt zwischen dem LNS und der PPP-Gegenstelle statt.
288
PPP-Tunneling mit L2TP
Heutige Einwahlkonzentratoren und Authentifizierungssysteme, zumeist RADIUS-Server, kennen beide Verfahren und können diese gleichzeitig – sogar gleichzeitig für einen Kunden – verwenden.
9.2.3
Die Rolle des LAC (L2TP Access Concentrator)
Der L2TP Access Concentrator (LAC) ist für die Verarbeitung der medienabhängigen PPP-Schichten verantwortlich und entscheidet, ob eine eingehende Verbindung als normale PPP-Verbindung lokal terminiert wird oder ob ein Tunnel zu einem LNS aufgebaut werden muss. Je nachdem auf welche Art diese Entscheidung getroffen wird – aufgrund des DNIS oder des Benutzernamens –, führt der LAC zusätzlich noch einen Teil der Authentifizierung durch. Wie bereits erwähnt wurde, ist die LAC-Funktionalität meist auf DialIn-Systemen in den POPs von Service Providern und Carriern implementiert. Solche Systeme sind in der Lage, sowohl selbst PPP zu terminieren als auch PPP-Verbindungen zu tunneln. Die zusätzliche L2TP-LAC-Funktionalität bringt in den meisten Implementierungen keine Performanceprobleme mit sich, da meist nur ein Tunnel zu den Kundennetzen aufgebaut werden muss, durch den mehrere Calls geleitet werden können. Außerdem findet der größte Teil der PPP-Verarbeitung dabei nicht mehr auf dem LAC, sondern auf dem LNS statt. Dies spart ebenfalls Speicher- und Rechenzeitressourcen auf dem Einwahlsystem.
9.2.4
Die Rolle des LNS (L2TP Network Server)
Der L2TP Network Server (LNS) ist das Gerät, auf dem die PPP-Verbindungen der Remote-Access-Clients terminiert werden. Hier arbeiten alle Dienste zum Ver- und Entpacken der Netzwerkprotokolle, der Datenkomprimierung, der Authentifizierung und der Kontrolle der Verbindungsqualität. Lediglich die medienabhängigen Dienste werden vom LAC abgewickelt. Zusätzlich zur LNS-Funktionalität muss eine Schnittstelle zu Authentifizierungs- und Accountingsystemen existieren, meist zu RADIUS-Servern, die sich als dominierender Standard hierfür durchgesetzt haben.
9.2.5
Betrachtungen zur Performance von L2TP
Je nach Anwendungsfall sind auf einem LNS mehrere hundert oder tausend PPP-Sessions gleichzeitig zu terminieren. Dies stellt natürlich gewisse Anforderungen an die Leistungsfähigkeit eines solchen Systems. Viele Hersteller haben die L2TP-LNS-Funktionalität als zusätzliches Feature auf ihren Routern implementiert. Man kann dies zwar nicht verallgemeinern, aber hierbei kann es zu deutlichen Performanceeinbußen auf solchen Systemen kommen. Die meisten Hersteller weisen jedoch fairerweise auf solche
289
9 Das Layer 2 Tunneling Protocol
Einschränkungen hin. Diese Leistungsengpässe werden nicht dadurch verursacht, dass die Geräte nichts taugen, sondern entstehen aufgrund des Routerdesigns. Die meisten Router wurden schon vor etlichen Jahren entwickelt – mit dem ausschließlichen Ziel zu routen und die notwendigen LAN- und WAN-Interface-Protokolle zu terminieren. Die Systeme wurden für diesen Zweck optimiert, und zwar sowohl im Hinblick auf die Hard- als auch auf die Software. Das Resultat sind sehr leistungsfähige Routerplattformen. Werden diese allerdings für andere Funktionen verwendet, für die sie nicht ausgelegt sind, so werden nicht nur diese Funktionen mit mangelhafter Performance ausgeführt, sondern das ganze System bekommt letztendlich Leistungsprobleme. Dies betrifft sowohl im Falle von L2TP das Terminieren von Hunderten oder Tausenden von PPP-Sessions als auch, wie im vorhergehenden Kapitel erläutert, die Verschlüsselungsfunktionen in IPSec. Nehmen wir als anschauliches Beispiel einmal einen Router der Mittelklasse, der zwei WAN- und zwei LAN-Interfaces aufnehmen kann und die im Unternehmensbereich üblichen Routingprotokolle beherrscht. Beim Design eines solchen Systems ist unter anderem die Wirtschaftlichkeit eine Vorgabe. Es darf keine Überdimensionierung dahin gehend geben, dass zu teure Prozessoren und zu viel Speicher eingebaut werden. An dem Gerät muss ja schließlich auch etwas verdient werden, und es hat konkurrenzfähig zu sein. Hier setzt man als Szenario typischerweise an, dass die beiden WAN-Schnittstellen mit maximal 2 Mbit/s betrieben werden und darauf Protokolle wie PPP, Frame Relay, X.21 usw. laufen. Die LAN-Interfaces sind meist EthernetSchnittstellen mit 10 bzw. 100 Mbit/s. Wenn man bei der Kalkulation der benötigten Leistung im WAN-Bereich den schlimmsten Fall annimmt, dann müssen die beiden WAN-Schnittstellen über ein entsprechendes Leitungsprotokoll insgesamt 62 mal 64 Kbit/s mit PPP terminieren. Wenn nun zusätzlich in ein solches System LNS-Funktionalität implementiert wird, dann kommen Protokolle wie L2TP und RADIUS hinzu. Auf den WANSchnittstellen selbst werden in typischen Szenarien zwar nur noch pro Interface einmal die entsprechenden Link-Protokolle terminiert, es kommen pro eingewähltem Benutzer aber jeweils eine PPP-Session und pro Datenpaket die entsprechenden Kapselungsdienste von L2TP hinzu. Wenn nun die Zahl der Benutzer, was nicht unüblich ist, in die Hunderte oder gar Tausende geht, dann werden auch ebenso viele PPP-Sessions auf diesem Router terminiert. Und dafür sind die meisten Systeme einfach nicht konstruiert. Abhilfe schaffen hier spezielle VPN-Systeme, deren Hard- und Softwaredesign speziell auf eine solche Funktionalität ausgelegt ist. Hier wurden bereits beim Design die Rahmenbedingungen beim Einsatz als virtueller Remote Access Concentrator oder IP Security Gateway berücksichtigt.
290
PPP-Tunneling mit L2TP
Weitere Kriterien bei der Überlegung, L2TP einzusetzen, sind auch die Performance und die Qualität der Übertragungsstrecke zwischen LAC und LNS. Herkömmlicher Remote Access wird auf Basis von leitungsvermittelnden Netzen wie ISDN oder analogen Telefonnetzen betrieben. Hierbei erfolgt die Übertragung der Datenpakete mit der technisch möglichen Geschwindigkeit, z.B. 64 Kbit/s bei ISDN, und minimaler Verzögerung. Außerdem kommen die Pakete in der Reihenfolge an, in der sie abgeschickt wurden – oder gar nicht. Vertauschungen bei der Reihenfolge gibt es in der Regel nicht. Das PPP-Protokoll läuft in diesem Fall auf einer realen Punkt-zu-Punkt-Verbindung, wofür es ursprünglich auch entwickelt wurde. L2TP macht damit Schluss. Denn hier wird die reale Punkt-zu-Punkt-Verbindung durch den L2TP-Tunnel ersetzt, der jedoch auch über Nicht-Punktzu-Punkt-Verbindungen laufen kann. Oft werden L2TP-Pakete in UDP/IP eingekapselt und zwischen LAC und LNS übertragen. In der Praxis ist das verwendete IP-Netzwerk das Internet oder der Backbone eines Carriers oder Service Providers. Das Resultat: Weder die Geschwindigkeit noch die Reihenfolge, in der die Pakete ankommen, sind vorherbestimmbar und können je nach Last auf dem Transportnetz großen Schwankungen unterliegen. Also müssen auf der einen Seite LAC und LNS zusätzliche Funktionen zur Verfügung stellen, um Probleme zu entschärfen, die insbesondere bei einer Vertauschung der Paketreihenfolge entstehen. Als Beispiel sei an dieser Stelle die Van-Jacobson-(VJ)-TCP-Header-Komprimierung genannt. Dieses Verfahren macht sich die Tatsache zunutze, dass die Informationen in aufeinander folgenden TCP/IP-Headern nur in ganz wenigen Bits voneinander abweichen, und überträgt, nachdem der erste vollständige Header gesendet wurde, nur noch die Differenz zum jeweils vorhergehenden. Auf diese Weise spart man Bandbreite. Das funktioniert aber logischerweise nur, wenn die Reihenfolge der Pakete nicht verändert wird, was bei echten Punkt-zu-Punkt-Verbindungen, nicht aber bei UDP/IP gegeben ist. Hier muss entweder das darunter liegende Protokoll, also L2TP, zusätzliche Maßnahmen einführen, um die Paketreihenfolge einzuhalten, oder es kann der Fall eintreten, dass jedes Mal, wenn ein Paket nicht in der richtigen Reihenfolge ankommt, der VJ-Algorithmus annimmt, das Paket wäre verloren, und so lange alle weiteren eingehenden Pakete verwirft, bis ein Paket mit vollständigem TCP/IP-Header eintrifft. Das wäre natürlich ein Performanceverlust anstelle eines Gewinns. Andere Beispiele sind Kompressions- oder Verschlüsselungsprotokolle, die auf so genannten Histories basieren und damit ebenfalls eine unveränderte Reihenfolge der eingehenden Pakete benötigen. L2TP muss also bestimmte, kritische Eigenschaften einer realen Punktzu-Punkt-Verbindung emulieren, insbesondere hinsichtlich der Paketreihenfolge und der Signalisierung an das PPP-Protokoll, ob Pakete verloren wurden. Dies bedingt einen zusätzlichen Paket-Overhead der L2TP-Datenpakete
291
9 Das Layer 2 Tunneling Protocol
durch Sequenzzähler und erfordert eine zusätzliche Verarbeitungsleistung, ebenso wie einen größeren Speicherbedarf zur Zwischenspeicherung von Paketen, die außerhalb der korrekten Reihenfolge angekommen sind.
9.2.6
L2TP-Tunneling-Modelle
Das Layer 2 Tunneling Protocol kann in zwei verschiedenen Modellen (vgl. Kapitel 6) betrieben werden, dem Provider-Enterprise-Modell (Compulsory Tunneling) und dem Ende-zu-Ende-Modell (Voluntary Tunneling). Netzwerk A
Compulsory-Tunneling-Modell Client A
LNS
LAC Virtual LAC
ISDN PSTN
Internet Netzwerk B
TMS Client B Voluntary-Tunneling-Modell L2TP-Tunnel
LNS PPP-Session
Abbildung 9.7: Die beiden Tunneling-Modelle von L2TP
In Abbildung 9.7 sind beide Modelle dargestellt. Die beiden Modelle unterscheiden sich durch den Punkt, an dem der L2TP-Tunnel initiiert wird. Der Remote-Access-Client A wählt sich in den Einwahlkonzentrator eines Service Providers ein und wird an dieser Stelle zum LNS seines Zielnetzwerks getunnelt. Der Client selbst hat keinen Einfluss auf das Tunneln, dies wird allein vom LAC gesteuert. Aus diesem Verhalten ist auch die englische Bezeichnung Compulsory Tunneling, zwangsmäßiges Tunneln, abgeleitet. Mit diesem Modell kann der Service Provider einem Kunden garantieren, dass dessen Clients jedes Mal, wenn sie sich anmelden, unbedingt zu einem entsprechend eingerichteten LNS getunnelt werden und keinen direkten Zugriff auf das Netzwerk des Providers oder das Internet haben. Das Entscheidungskriterium für den LAC ist hier die angerufene Nummer (DNIS) oder ein Zusatz im Benutzernamen. Voluntary Tunneling, freiwilliges Tunneln, ist das andere Modell, das mit L2TP realisiert werden kann. In dieser Variante ist der Remote Access Concentrator des Service Providers in keiner Weise in das Tunneln involviert. Statt dessen
292
PPP-Tunneling mit L2TP
ist die LAC-Funktionalität auf dem Client, Client B in Abbildung 9.7, implementiert. Der Tunnel beginnt also bereits im Clientrechner (virtueller LAC) und wird im entsprechenden LNS terminiert. Der Einwahlkonzentrator selbst überträgt dabei nur IP-Pakte zwischen Client und LNS. In diesem Fall kann der Client selbst entscheiden, ob und wie getunnelt wird. Dieses Modell wird in der Praxis jedoch sehr selten eingesetzt, da die Kunden in der Regel möchten, dass die Clients zwangsweise zum eigenen Netzwerk getunnelt werden.
9.2.7
L2TP-Paketformate
In L2TP existieren zwei funktionell grundsätzlich verschiedene, aber ähnlich konstruierte Arten von Paketen. Dies sind zum einen Datenpakete, die PPPFrames innerhalb eines Calls zwischen LAC und LNS transportieren, und zum anderen Steuerungspakete, die innerhalb einer Steuerverbindung zwischen LAC und LNS verschickt werden. 0
1
5
0 L 0 0 F 0 S P 0 0 0 0 0 Vers.
3
1
Length (optional)
Tunnel ID
Call ID
Ns (optional)
Nr (optional)
Offset Size (optional)
Offset Pad (optional)
Data (PPP Frame)
Abbildung 9.8: Das Format eines L2TP-Datenpakets
In Abbildung 9.8 ist die Struktur eines L2TP-Datenpakets zu sehen. Die Hauptfunktion ist die Kapselung eines PPP-Rahmens in ein L2TP-Paket und die Zuordnung des Pakets zu einem Tunnel und einem Call innerhalb dieses Tunnels. Weiterhin können optional Sequenzzähler zur Steuerung der Paketreihenfolge und Füllzeichen (Padding) enthalten sein. Die Felder in einem Datenpaket haben folgende Bedeutung: T-Bit Das T-Bit ist das erste Bit in einem L2TP-Paket und zeigt an, ob es sich um ein Datenpaket (0, wie in Abbildung 9.8) oder um ein Steuerungspaket (1, wie in Abbildung 9.9) handelt.
293
9 Das Layer 2 Tunneling Protocol
L-Bit Dieses Bit zeigt an, ob in dem Paket ein Längenfeld (1) enthalten ist oder nicht (0). In Steuerungspaketen muss ein Längenfeld enthalten sein, in Datenpaketen kann in vielen Fällen darauf verzichtet werden. F-Bit Wenn dieses Bit gesetzt (1) ist, dann sind im Paket die Sequenzzähler Ns und Nr enthalten. In Steuerungspaketen sind diese obligatorisch, in Datenpaketen sind sie optional. 0
15
1 1 0 0 1 0 0 0 0 0 0 0 0 Vers.
31 Length
Tunnel ID
Call ID
Ns
Nr
MH 0 0 0 0
Overall Length Attribute
Vendor ID Value .......
......... Value ......... ......... Value MH 0 0 0 0
Overall Length Attribute
Vendor ID Value .......
......... Value
Abbildung 9.9: Das Format eines L2TP-Steuerungspakets mit zwei AVPs (Attribute Value Pairs)
S-Bit Falls das Offset-Size-Feld vorhanden ist, muss das S-Bit gesetzt werden. In L2TP-Steuerungspaketen muss dieses Bit immer 0 sein, da dieses Feld dort nicht existiert. Version Dies ist die Versionsnummer von L2TP; der augenblicklich einzig gültige Wert ist 2. Length Dieser 16-Bit-Wert gibt die vollständige Länge des L2TP-Pakets in Byte an. Ein Paket kann somit maximal 65.535 Byte groß sein.
294
PPP-Tunneling mit L2TP
Tunnel ID Dies ist der eindeutige Bezeichner eines bestimmten L2TP-Tunnels. Er wird gemäß der L2TP-Spezifikation auf Zufallsbasis erzeugt. Mit Hilfe der Tunnel ID kann der Empfänger des Pakets dieses einem bestimmten Tunnel zuordnen. Call ID Die Call ID ist ein innerhalb eines Tunnels eindeutiger Bezeichner eines Calls, also einer PPP-Session. Auch er wird auf Zufallsbasis erzeugt. Durch die Größe des Bezeichners von 16 Bit ist die maximale Anzahl von Calls, die in einem Tunnel existieren können, auf 65.535 beschränkt. Ns Dieser Wert (Ns, Next Send) stellt die Sequenznummer eines Pakets dar. In Steuerungspaketen muss dieser Wert enthalten sein, in Datenpaketen ist er optional und dient dort zur Steuerung der korrekten Paketreihenfolge. Nr Next Received (Nr) ist die Sequenznummer des Steuerungspakets, das der Sender des vorliegenden Pakets als Nächstes empfangen möchte. In Datenpaketen hat dieser Wert keinen Sinn und wird daher auf 0 gesetzt. Offset-Size Diesen Wert gibt es nur in Datenpakten, falls dort das S-Bit gesetzt wurde. Er gibt an, wie viele Byte zwischen dem L2TP-Header und dem PPP-Frame liegen. Offset-Pad In den Zwischenraum zwischen L2TP-Header und PPP-Frame wird, falls der Wert Offset-Size größer 0 ist, die Anzahl von Füllzeichen geschrieben, die dem Wert von Offset-Size entspricht. Die Füllzeichen sind in der Regel Bytes mit dem Wert 0x00.
9.2.8
L2TP Attribute Value Pairs (AVP)
In Steuerungspaketen sind so genannte AVPs (Attribute Value Pairs) enthalten, die diejenigen Befehle und Optionen enthalten, die zwischen LAC und LNS ausgetauscht werden. Diese Datenstrukturen bestehen aus einem festen Header, der auch den Bezeichner des jeweiligen Attributs enthält, und einem Attributwert variabler Länge. In Abbildung 9.9 folgen zwei verschiedene AVPs dem L2TP-Steuerungspaket-Header.
295
9 Das Layer 2 Tunneling Protocol
Im AVP-Header finden wir verschiedene Flags und Felder mit folgender Bedeutung: M-Bit Dieses Flag (M, Mandatory) zeigt an, ob der AVP zwingend ist, und steuert damit das Verhalten des Empfängers, falls dieser ein AVP mit gesetztem M-Bit empfängt, aber mit dem Inhalt des AVP nichts anfangen kann. In diesem Fall, der dann vorliegt, wenn entweder die Vendor-ID, der Attributbezeichner oder beide unbekannt sind, muss der Empfänger den Tunnel beenden. H-Bit Das H-Bit (Hide-Bit) wird dann gesetzt, wenn der Wert des AVP versteckt sein soll. Dies wird durch die Verschlüsselung des Value-Feldes erreicht. Die ersten sechs Bytes (Flags, Overall Length, Vendor-ID und Attribute) eines AVP sind immer unverschlüsselt. RND
Initialisierungsvektor
Shared Secret
MD 5
Klartextblock 1
Shared Secret
Klartextblock 2
Attribute
Chiffretextblock 1
MD 5
Chiffretextblock 2
Abbildung 9.10: Der AVP-Verschlüsselungsalgorithmus
Eine praktische Anwendung für versteckte, beziehungsweise verschlüsselte AVPs ist die Proxy-Authentifizierung. Dabei schickt der LAC die User-ID und
296
PPP-Tunneling mit L2TP
das Passwort des PAP-Protokolls zum LNS. Da diese Informationen im Klartext vorliegen, sollten sie beim Transport über ein öffentliches Netz wie das Internet verschlüsselt werden. Die in L2TP spezifizierte Verschlüsselung ist allerdings vom Sicherheitsstandpunkt aus gesehen nicht gerade umwerfend. Der Algorithmus zum Ver- und Entschlüsseln ist eine schlichte Exklusiv-Oder-Verknüpfung des Klartextes mit einem 128 Bit großen Schlüssel. Dieser Schlüssel wird aus einer Zufallszahl, die mit einem CBC-Initialisierungsvektor vergleichbar ist, dem Attribut und einem Shared Secret mit Hilfe der MD5-Funktion berechnet. Dieses Shared Secret wird auch, wie in Kapitel 9.2.9 beschrieben wird, zur Authentifizierung von LNS und LAC beim Aufbau eines L2TP-Tunnels benutzt. Die MD5-Funktion ist als Basis des CHAP-Verfahrens ebenfalls bereits im System vorhanden. Die Verschlüsselung arbeitet, wie in Abbildung 9.10 zu sehen ist, in einem Output-Feedback-Modus mit einem expliziten Initialisierungsvektor. Aus dem Shared Secret, dem Attributwert und dem Initialisierungsvektor wird über MD5 ein 128 Bit großer Wert erzeugt, der mit den ersten 16 Byte des originalen AVP-Subformats Exklusiv-Oder-verknüpft wird. Damit sind die ersten 16 Bytes verschlüsselt. Aus diesem Wert und dem Shared Secret wird über MD5 wieder ein 128-Bit-Wert erzeugt, mit dem die nächsten 16 Bytes verschlüsselt werden. Dies wird so lange weitergeführt, bis der originale Wert vollständig verschlüsselt ist. Aus Sicherheitsgründen wird die Länge des originalen Wertes im Value-Feld verschleiert, indem man ein so genanntes Hidden-AVP-Subformat erzeugt, das aus einem Längenfeld, dem Originalwert und Füllzeichen besteht. Dieses Format wird mit dem beschriebenen Verfahren verschlüsselt und als Wert in das Value-Feld des AVP eingetragen. An dieser Stelle sei auch bereits darauf hingewiesen, dass die Verschlüsselung nur auf Steuerungspakete (siehe Abbildung 9.9) angewendet werden kann, nicht jedoch auf L2TP-Datenpakete. Overall Length Dieses Feld gibt die Gesamtlänge des AVP in Byte an. Vendor ID Für AVPs, die von der IETF spezifiziert worden sind, ist dieser Wert 0. Herstellerspezifische AVPs enthalten eine Vendor ID, die der von der IANA (Internet Assigned Numbers Authority) zugewiesenen Nummer gemäß dem RFC1700 entspricht. Somit ist die Kombination von Attribut und Vendor ID weltweit eindeutig, denn selbst wenn unterschiedliche Hersteller die gleichen Attributbezeichner verwenden, so unterscheiden sie sich doch durch ihre Vendor ID.
297
9 Das Layer 2 Tunneling Protocol
Attribute Dieses Feld enthält den Bezeichner des Attributs als 16-Bit-Wert. Value In diesem Feld steht der Wert des Attributs. Er kann, innerhalb der maximalen Größe des AVP, beliebig lang sein, und sein Wert wird vom Empfänger anhand des Attribute- und Vendor-ID-Feldes interpretiert.
9.2.9
Auf- und Abbau von Tunneln und Calls in L2TP
In Abbildung 9.11 ist der Auf- und Abbau eines Calls und eines Tunnels in zeitlicher Abfolge skizziert. Es wird in diesem Beispiel davon ausgegangen, dass zum Zeitpunkt des Calls noch kein Tunnel zwischen dem LAC und dem LNS existiert. Die Erkennung und Zuweisung einer Tunnelverbindung durch den LAC soll aufgrund der DNIS-Information bei Rufaufbau erfolgen. LAC
Client
LNS
ISDN PSTN
RADIUS
Internet
TMS
Callplacement TMSQuery TMSReply
DNIS-Eintrag vorhanden
Start-control-connection-request Start-control-connection-reply Start-control-connection-connected
LCP Negotiation
Incoming-call-request(Auth.)
Incoming-call-reply Callcompletion
Authent. Request Authent. Reply
Incoming-call-connected ForwardLCPOptions NCP(IPCP ,CCP ,...)Negotiations
L2TPDatamessages(PPPFrames) Calldisconnect
Stop-control-connection-notify Call-disconnect-notify
Abbildung 9.11: Der Auf- und Abbau eines Tunnels und eines Calls in L2TP
298
PPP-Tunneling mit L2TP
Der Client, ein Remote-Access-System mit PPP, baut eine Wählverbindung zum Einwahlkonzentrator auf. Der Remote Access Concentrator schickt daraufhin ein Authentication-Request-Paket zum Tunnel-Management-System (TMS), das meist ein RADIUS-Server ist. In diesem Paket ist unter anderem auch die DNIS-Information enthalten. Das TMS findet in unserem Fall zu dieser Rufnummer einen Eintrag, in dem die folgenden Informationen enthalten sein müssen: die Art des aufzubauenden Tunnels (L2TP, L2F usw.) und die Zieladresse des LNS, zu dem der Tunnel aufgebaut werden soll. Meist ist noch ein Shared Secret hinterlegt, mit dem der Tunnelaufbau authentifiziert werden kann und Hidden-AVPs verschlüsselt werden können. Mit diesen Parametern versucht nun der LAC, einen Tunnel zum LNS aufzubauen, indem er einen Start-control-connection-request an den LNS schickt. Der LNS antwortet mit einem Start-control-connection-reply, falls er dem Wunsch des LAC, einen Tunnel zu erzeugen, folgt. Sobald der LAC diese Antwort erhält, komplettiert er seinen Tunnelaufbau, und beide Seiten, LAC und LNS, sind über eine Control Connection miteinander verbunden. Im Sinne von L2TP ist damit ein Tunnel aufgebaut. Innerhalb dieses dreiphasigen Handshake-Verfahrens kann auch die Authentifizierung der beiden Tunnelendpunkte erfolgen. Dazu wird ein dem CHAPVerfahren analoger Mechanismus auf Basis von MD5 mit Challenge-, Response- und Accept/Reject-Paketen unter Verwendung eines Shared Secret auf LAC und LNS eingesetzt. Da der Tunnel aufgrund der DNIS-Informationen aufgebaut wurde, brauchte der LAC bisher nur minimale LCP-Operationen auszuführen. Die restlichen LCP-Aushandlungen können jetzt durch den Tunnel zwischen dem Client und dem LNS direkt erfolgen, ohne dass der LAC noch involviert ist. Nachdem die Übertragungsparameter und Authentifizierungsprotokolle ausgehandelt wurden, kann die Authentifizierung des Benutzers (Clients) erfolgen. Da der LNS die LCP-Optionen, die der LAC bereits mit dem Client ausgehandelt hat, nicht kennt, schickt ihm dieser seine Optionen in einem Informationspaket (Forward LCP-Options) zu. Somit kennt der LNS alle LCP-Optionen, die von ihm selbst und die vom LAC ausgehandelt wurden, und er hat den Benutzer authentifiziert. Nun können die Netzwerksteuerungsprotokolle gestartet werden, und nach deren Abschluss können L2TP-Datenpakete und damit auch Netzwerkpakete übertragen werden. Wird die Verbindung vom Client unterbrochen, also der Call terminiert, kann auch der Tunnel selbst abgebaut werden, wenn sonst keine weiteren Calls in diesem Tunnel mehr aktiv sind. Der Abbau wird ebenfalls über entsprechende Steuerungspakete geregelt.
299
9 Das Layer 2 Tunneling Protocol
9.2.10
L2TP-Benutzer-Authentifizierung
Die Benutzer-Authentifizierung lässt sich in drei verschiedene Stufen untergliedern, die sich dadurch unterscheiden, inwieweit der LAC in die Authentifizierung involviert ist. Im ersten Fall, in dem der LAC aufgrund der DNISInformationen beim Aufbau der Wählverbindung bereits erkennen kann, dass ein L2TP-Tunnel zu einem LNS aufgebaut werden soll, erfolgt die Authentifizierung vollständig zwischen dem LNS und der PPP-Gegenstelle. Der LNS handelt alle LCP-Optionen aus und ebenso das zu verwendende Authentifizierungsprotokoll. Protokolle wie PAP, CHAP oder MS-CHAP (Microsoft CHAP, eine Microsoft-spezifische Variante von CHAP) werden zwischen LNS und der einwählenden Gegenstelle direkt abgewickelt. Diese Variante, die allerdings nur mit einer auf DNIS basierenden Tunnelverteilung funktioniert, ist problemlos mit allen PPP-Implementierungen auf der Clientseite möglich. Für den Client sieht es so aus, als ob er nur mit einer einzigen Instanz und nicht mit dem LAC und dem LNS kommuniziert. Die anderen beiden Verfahren zur Benutzer-Authentifizierung basieren darauf, dass in der User-ID (Benutzername, CHAP-Name usw.) eine Kennung enthalten ist, aufgrund derer der LAC entscheiden muss, ob und wohin ein Tunnel aufzubauen ist. Um aber in den Besitz einer User-ID zu gelangen, muss der LAC das vollständige LCP abwickeln und die Authentifizierung so lange durchführen, bis er die nötigen Informationen erhält. Diese Funktionalität wird auch als Proxy Authentication bezeichnet, da der LAC anstelle des LNS die notwendigen ersten Schritte zur Authentifizierung des Benutzers durchführt. LAC
Client
LNS
ISDN PSTN
RADIUS
Internet
TMS
Call placement TMS Query TMS Reply
DNIS-Eintrag vorhanden
Tunnelaufbau LCP Negotiation Authentifizierung (PAP, CHAP, MS-CHAP)
Authent.
Abbildung 9.12: Die L2TP-Benutzer-Authentifizierung bei DNIS-basierender Erzeugung der Tunnel
300
PPP-Tunneling mit L2TP
Im Fall unserer Beispiele in Abbildung 9.13 und Abbildung 9.14 mit PAP als Authentifizierungsprotokoll erhält der LAC ein PAP-Authentication-RequestPaket, in dem der Benutzername und das Passwort enthalten sind. Aufgrund der User-ID kann der LAC erkennen, dass ein L2TP-Tunnel zum LAC aufgebaut werden muss, und er baut diesen auf. Anschließend schickt der LAC das Authentication-Request-Paket zum LNS. Dieser kann jetzt entweder die Authentifizierung wie in Abbildung 9.13 einfach fortführen, oder er kann noch einmal LCP starten, neue Optionen und sogar ein anderes Authentifizierungsverfahren mit der PPP-Gegenstelle aushandeln (LCP Renegotiation) und dieses dann auch ausführen. Im ersten Fall wird der Benutzer authentifiziert, und der LNS akzeptiert die bereits vom LAC ausgehandelten LCP-Optionen und das Authentifizierungsprotokoll. Im zweiten Fall startet der LNS noch einmal LCP-Aushandlungen mit dem Client, in deren Folge sich beide auch auf ein anderes Authentifizierungsprotokoll einigen können, das anschließend ausgeführt werden muss. LAC
Client
LNS
ISDN PSTN
RADIUS
Internet TMS
Call placement TMS Query TMS Reply
LCP
Kein DNISEintrag vorhanden
Negotiation ..., PAP, … PAP-Auth-Req
TMS Query TMS Reply
Domain-Eintrag vorhanden
Tunnelaufbau PAP-Auth-Req-Forward
Authent. PAP-Authentication-Accept
Abbildung 9.13: Partielle Benutzer-Authentifizierung auf dem LAC (Proxy Authentifizierung)
Allerdings kann dieses Verhalten (siehe Abbildung 9.14) – neue LCP-Aushandlung und eine Wiederholung der Authentifizierung – bei gewissen PPPImplementierungen in älteren PC-Betriebssystemen auch Probleme bereiten. Die Verbindung wird schlicht abgebrochen, da dieses Verhalten, insbesondere eine bereits ausgehandelte und begonnene Authentifizierung neu auszuhandeln und zu starten, in PPP zwar erlaubt ist, aber gewöhnlich niemals vor301
9 Das Layer 2 Tunneling Protocol
kommt. In diesem Fall muss der LNS die Authentifizierung fortführen, was aus Geschwindigkeitsgründen auch meist das übliche Verhalten ist. Die meisten LNS-Implementierungen starten nur dann eine LCP-Neuaushandlung, wenn die vom LAC bereits ausgehandelten Optionen und Authentifizierungsverfahren für sie nicht akzeptabel sind. Dies ist aber nur sehr selten der Fall, da die meisten LNS auf die meistens bereits in den Systemen vorhandene PPP-Funktionalität aufbauen. LAC
Client
LNS
ISDN PSTN
RADIUS
Internet TMS
Call placement TMS Query TMS Reply
LCP
Kein DNISEintrag vorhanden
Negotiation ..., PAP, … PAP-Auth-Req TMS Query TMS Reply
Domain-Eintrag vorhanden
Tunnelaufbau PAP-Auth-Req - Forward LCP Renegotiation (...., CHAP, ....) CHAP-Challenge CHAP-Response Authent. CHAP-Authentication-Accept
Abbildung 9.14: Eine L2TP-Benutzer-Authentifizierung, in der der LNS die LCP-Optionen und das Authentifizierungsprotokoll ändert (LCP Renegotiation)
Noch weiter in die Authentifizierung involviert wird der LAC im Falle von CHAP. In Abbildung 9.15 sehen wir, dass der LAC in diesem Fall den dreiphasigen CHAP-Zyklus startet. Er erzeugt dazu eine Zufallszahl und schickt diese in einem CHAP-Challenge-Paket zum Client. Dieser erzeugt aus seinem Passwort und der Zufallszahl mit der MD5-Funktion einen Hashwert und schickt diesen, zusammen mit seiner User-ID, in einem CHAP-Response Paket zum LAC. Der LAC schaut sich die User-ID an und prüft, ob dort eine Domainkennung enthalten ist. Wenn ja, wird mit den Informationen, die der Tunnel-Management-Server (TMS) zu dieser Domain hat, ein Tunnel zum entsprechenden LNS aufgebaut.
302
Die Sicherheit von L2TP
LAC
Client
RADIUS
LNS
ISDN PSTN
Internet TMS
Call placement TMS Query LCP
TMS Reply
Kein DNISEintrag vorhanden
Negotiation ..., CHAP, … CHAP-Challenge CHAP-Response
TMS Query TMS Reply
Domain-Eintrag vorhanden
Tunnelaufbau
CHAP-Chall. + CHAP-Resp. Fwd.
Authent.
CHAP-Authentication-Accept
Abbildung 9.15: L2TP-Proxy-Authentifizierung am Beispiel von CHAP
Anschließend übermittelt er dem LNS die von ihm erzeugte CHAP-Challenge zusammen mit der CHAP-Response des Clients. Der LNS überprüft nun die Identität des Benutzers und erzeugt, abhängig vom Ergebnis der Authentifizierung, eine CHAP-Accept- oder CHAP-Reject-Message. In diesem Beispiel (Proxy-Authentifizierung) sehen die LCP-Aushandlung und die Authentifizierung für den Client so aus, als ob er mit einer einzigen PPP-Gegenstelle kommuniziere. Es erfolgen keine, aus Sicht von PPP, ungewöhnlichen Aktivitäten wie LCP-Neuaushandlung oder Neustart des Authentifizierungsprotokolls, ohne dass das vorhergehende Protokoll ordnungsgemäß terminiert wurde.
9.3
Die Sicherheit von L2TP
Genau genommen müsste die Überschrift zu diesem Unterkapitel eigentlich lauten: Die Unsicherheit von L2TP. Bevor sich Ihnen beim Lesen dieses Abschnitts aber der Gedanke aufdrängt, L2TP sei eigentlich ein völlig unbrauchbares Protokoll zum Einsatz in öffentlichen Netzen, sollten Sie sich vor Augen halten, dass L2TP kein Sicherheitsprotokoll ist, dies niemals sein sollte und dies niemals sein wird. L2TP ist, der Name sagt es eigentlich schon,
303
9 Das Layer 2 Tunneling Protocol
ein reines Tunneling-Protokoll. Sicherheitsmaßnahmen werden auf anderen Ebenen eingesetzt, auf der Transport- oder der Netzwerkebene (L2Sec, IPSec usw.) oder auf applikationsnahen Ebenen wie SSL, PGP usw. Aus diesem Grunde sind auch in L2TP nur minimale Sicherheitsmechanismen eingebaut, die sich hauptsächlich auf den Bereich der Control Connection und der Tunnelauthentifizierung beschränken. Im Vergleich zu Sicherheitsprotokollen wie IP Security bietet L2TP keinen Schutz der Datenvertraulichkeit und der Datenintegrität, und es findet auch keine Paketauthentifizierung statt. Falls hierfür Bedarf vorhanden ist, dann wird vom L2TP-Standardisierungsgremium empfohlen, die Sicherheitsdienste der darunter liegenden Transportprotokolle zu benutzen, also im Falle von L2TP/UDP beispielsweise IPSec im Transport-Modus einzusetzen. Auf diese Weise wird die Verbindung zwischen LNS und LAC vollständig – also Steuerungs- und Datenkanäle – geschützt. L2TP selbst bietet eine zugegebenermaßen recht simple Authentifizierung von LNS und LAC beim Aufbau eines Tunnels. Diese Authentifizierung basiert auf einem dreiphasigen Handshake-Verfahren, ähnlich wie CHAP, das die Existenz eines Shared Secret auf den beteiligten Gegenstellen voraussetzt. Dieses Shared Secret ist auch gleichzeitig der Schwachpunkt des Verfahrens, denn es wird in den meisten Implementierungen eine Kombination aus Buchstaben, Ziffern und Sonderzeichen im Klartext gespeichert. Somit besteht die Gefahr von Wörterbuchangriffen, Brute-Force-Attacken oder eines Angriffs auf den LAC oder LNS selbst, da das Shared Secret dort entweder direkt im Klartext gespeichert oder zumindest einfach rekonstruierbar ist. Als weitere Sicherheitsmaßnahme ist die Verwendung von Hidden-AVPs innerhalb der Steuerungsverbindung möglich, wie in Abschnitt 9.2.8 bei der Vorstellung des H-Bit erläutert wird. Diese im Vergleich zu Algorithmen wie DES oder IDEA eher rudimentäre Verschlüsselung ist leider mit einem überschaubaren Aufwand zu »knacken«. Man muss sich lediglich das Shared Secret beschaffen (siehe oben) und kann damit den benutzten 128-Bit-Schlüssel berechnen, oder man startet eine Kryptoanalyse auf das Ergebnis der Exklusiv-Oder-Verknüpfung, die in L2TP als Ver- und Entschlüsselungsalgorithmus verwendet wird. Im Gegensatz beispielsweise zum PPTP hat man beim Design von L2TP darauf verzichtet, bestimmte Dienste oder Funktionen an darunter liegende Protokolle zu binden. So werden Pakete des Steuerungskanals im PPTP aus Gründen der Verlässlichkeit über TCP transportiert, Datenpakete dagegen über UDP. L2TP ist dagegen ein so genanntes »self containing protocol«, also ein Protokoll, dass völlig unabhängig von den darunter liegenden Schichten arbeitet. L2TP kann daher auf UDP/IP, Frame Relay, ATM usw. aufsetzen. Die Zuverlässigkeit, die PPTP durch die Verwendung von TCP erreicht, ist im L2TP-Protokoll selbst implementiert. Der Verzicht auf TCP birgt zugleich aber auch einen wichtigen Sicherheitsvorteil. Denn das TCP-Protokoll ist gegen eine Reihe von protokollspezifischen Angriffen anfällig: die so genannten Denial-of-Service-Angriffe. Beim Einsatz von UDP ist man davor geschützt.
304
IPSec secured L2TP
9.4
IPSec secured L2TP
Falls man L2TP in IP-Umgebungen wie dem Internet oder den Backbones von Service Providern einsetzt, ist IPSec das empfohlene Verfahren, um die notwendige Sicherheit zu gewährleisten. Durch die Entscheidung von Microsoft, dieses Verfahren (IPSec secured L2TP oder kurz L2TP/IPSec) als Basis seiner VPN-Technologie in Windows 2000 einzusetzen, ist es mit einem Schlag sehr populär geworden. Zugleich markiert es auch die Abkehr Microsofts vom jahrelang bevorzugten PPTP und eine Hinwendung zu offenen Standards wie IP Security und L2TP. Durch diese Kombination von IPSec und L2TP beseitigt man entscheidende Schwachstellen in beiden Verfahren. IPSec ist ein sehr sicheres Protokoll, aber von seinem Design her ausschließlich auf Sicherheit ausgelegt – mit der Option, einzig und allein IP zu tunneln. IPX und andere Protokolle bleiben außen vor. L2TP andererseits kann aufgrund seines Designs alle möglichen Protokolle tunneln, sofern sie in PPP einzukapseln sind. Aber L2TP bietet praktisch keine nennenswerten Sicherheitsfunktionen. Durch die Kombination beider Protokolle heben sich beide Schwächen gegenseitig auf, und man hat ein sehr flexibles Tunneling-Protokoll mit höchster Sicherheit. Client
RAC
Gateway IP-Netz
ISDN
IPSec PPP IPSec
L2TP PPP L2TP
L2TP/IPSec PPP PPP L2TP IPSec
Abbildung 9.16: IPSec, L2TP und L2TP/IPSec im Performance-Vergleich
305
9 Das Layer 2 Tunneling Protocol
Allerdings erkauft man sich diesen Vorteil zu einem hohen Preis. Sehen wir uns einmal in Abbildung 9.17 den Vergleich zwischen IPSec, L2TP und L2TP/IPSec als Basis eines einfachen VPNs an, und überschlagen wir den Aufwand (Rechenzeit, Speicher), den die beteiligten Systeme damit haben. Zum Rechnen nehmen wir als praxisnahes Beispiel einmal ein mittelgroßes Unternehmen an, das im Schnitt 1.000 Benutzern gleichzeitig Remote Access gewähren will. Beim Vergleich der Protokolle sieht man Folgendes: IPSec Hier wird auf dem Client zusätzlich zur PPP-Verbindung für die Verbindung zum RAC noch das IPSec-Protokoll mit mindestens zwei IPSec-Sicherheitsassoziationen (SAs) terminiert. Der RAC des Service Providers terminiert 1.000 PPP-Verbindungen. Auf dem Gateway im Kundennetz werden ebenfalls 2.000 IPSec-SAs verarbeitet. L2TP L2TP erfordert auf dem Client gar keinen zusätzlichen Aufwand, da der Tunnel erst im RAC des ISP initiiert wird. Der RAC unterhält einen einzigen Tunnel zum LNS im Gateway des Kunden. Dort werden jedoch alle 1.000 PPPVerbindungen der Clients terminiert. 1000 Clients
1 RAC
1 Gateway
(Pro Client) PPP IPSec L2TP PPP IPSec L2TP PPP IPSec L2TP
IPSec
1
L2TP
1
L2TP/IPSec
2
2
2000
1000 1
2
1
1000
1000
1
1000 2000 1000
Abbildung 9.17: Die Protokollterminierungen bei einem Remote-Access-VPN mit IPSec, L2TP und L2TP/IPSec
L2TP/IPSec Hier wird der Begriff Ende-zu-Ende-VPN sehr ernst genommen, denn sowohl auf dem Client als auch auf dem Gateway des Kunden wird sehr viel an Verarbeitungsleistung benötigt. Auf dem Client werden gleich zwei PPP-Sessions terminiert, eine zum ISP und eine zum Gateway. Zusätzlich terminiert ein virtueller LAC einen L2TP-Tunnel zum LNS im Gateway. Die beiden IPSecSAs runden das Ganze ab, auch sie müssen im Gateway terminiert werden.
306
IPSec secured L2TP
Der RAC terminiert 1.000 PPP-Sessions und nimmt weder an L2TP noch an IPSec teil. Auf dem Gateway werden dann aber 1.000 L2TP-Tunnel, 1.000 PPPSessions und 2.000 IPSec Security Associations terminiert! Man sieht also, dass L2TP/IPSec ein elegantes Verfahren darstellt, die Vorteile von L2TP und IPSec zu nutzen, ohne deren Nachteile in Kauf nehmen zu müssen, dass das ganze aber auch einen gewissen Preis hat. Denn ein System, das Tausende von PPP-Sessions, L2TP-Tunneln und IPSec-SAs gleichzeitig terminiert, benötigt eine üppige Ausstattung mit Rechenleistung und Speicher. Von dem Gedanken, ein herkömmlicher Router oder gar ein PC könnte dies mit angemessener Leistung tun, sollten Sie sich lösen. Hier sollten Sie spezielle Systeme einsetzen, die für so etwas entwickelt wurden. Client
RAC
Gateway IP-Netz
ISDN
1. PPP-Verbindung 2. IPSec-Sicherheitsassoziation 3. L2TP-Tunnel 4. PPP-Session 5. IP, IPX, … Kommunikation
IP
Daten
PPP IP
Daten
L2TP PPP IP
Daten
UDP L2TP PPP IP
Daten
IP
ESP
UDP L2TP PPP IP
Daten
ESP
PPP IP
ESP
UDP L2TP PPP IP
Daten
ESP
Abbildung 9.18: Die Funktionsweise von L2TP/IPSec beim Erzeugen eines ausgehenden Pakets
Nachdem nun klar ist, worauf Sie sich einlassen, folgt hier ein kurzer Überblick, wie L2TP/IPSec nun eigentlich funktioniert. Zwischen dem L2TP/IPSec-Client und dem Gateway muss zuerst eine IP-Verbindung aufgebaut werden. Der Client baut hierzu eine PPP-Verbindung zum RAC auf. Zwischen Client und
307
9 Das Layer 2 Tunneling Protocol
Gateway wird dann eine IPSec-Verbindung etabliert, und anschließend kann über diese sichere Verbindung ein L2TP-Tunnel aufgebaut werden, durch den nun die privaten Netzwerkpakete in PPP-Frames transportiert werden können. Die in der Abbildung 9.18 dargestellte Paketverarbeitung läuft nun wie folgt ab: Die IP-Pakete werden in PPP-Frames eingekapselt. Diese PPP-Pakete werden anschließend in L2TP-Datenpakete gekapselt und diese wiederum in UDP/IP-Pakete eingepackt. Um diese Pakete herum wird ein IPSec-Header und -Trailer konstruiert, die Daten werden verschlüsselt, und es wird ein Message Authentication Code (MAC) berechnet. Anschließend wird das Paket nochmals in PPP gekapselt und kann nun zum Einwahlkonzentrator des Service Providers geschickt werden. Dies ist nicht nur eine recht aufwendige Verarbeitung, auch der Paket-Overhead kann sich im Vergleich zur Nutzlast, dem originalen IP-Paket, sehen lassen. Aber wie gesagt, bei Kenntnis des Sachverhalts und einer davon ausgehend vernünftigen Auslegung der Komponenten und ihrer Leistungsfähigkeit hat man die Möglichkeit, in den Genuss der Sicherheit von IPSec zu kommen und trotzdem auch Nicht-IPPakete übertragen zu können.
308
10
VPN-Design
Das Design eines virtuellen privaten Netzwerks ist nicht leichter oder schwerer als das eines mit Standardtechnologie aufgebauten Netzes. Nach meiner mehrjährigen Erfahrung mit IP-VPNs in mittlerweile sehr vielen, teilweise international tätigen Unternehmen waren es meist weniger praktische Probleme, mit denen die Planer und Betreiber von VPNs zu kämpfen hatten. Vielmehr war es oft eine gewisse Unsicherheit gegenüber dem Thema Datensicherheit und den damit verbundenen Technologien wie der Kryptologie. Hier treffen ja auch zwei Welten aufeinander: Der klassische Netzwerker will ein möglichst hohes Maß an transparenter Kommunikation, und der Sicherheitsverantwortliche will genau das Gegenteil, nämlich eine nach verschiedenen Kriterien eingeschränkte Kommunikation. Bisher konnten die Gegensätze organisatorisch getrennt werden; die Netzwerker bauten ihre »privaten« Netze, und die Verbindung zur Öffentlichkeit, meist in Form des Internets, erfolgte in aller Regel über eine Firewall. Mit dem Aufkommen der InternetVPNs wurde diese Trennung aufgehoben, und beide Seiten müssen sehr eng zusammenarbeiten und sich auf Kompromisse einigen, was in manchen Fällen allerdings auch zu Konflikten führen kann.
10.1 Ein VPN ist auch nur ein Netzwerk Mit diesem Leitsatz, der bis auf wenige Ausnahmen durchgehend anwendbar ist, kann man sich sein Leben als VPN-Planer sehr erleichtern. Der Trick dabei ist einfach der, dass man sich an genau die gleichen Kriterien hält, die auch beim Design eines Routernetzwerks und einer Remote-Access-Lösung gelten. Die Sicherheitsstrategie gilt auch für solche Netze, denn auch sie benutzen öffentliche Netze wie ISDN, Frame Relay oder ATM. Der Unterschied ist einfach nur, dass das öffentliche Netzwerk jetzt Internet heißt und ein Netzwerk mit virtuellen Verbindungen auf der Netzwerkschicht des OSI-Modells vorliegt. So viel zur Theorie. Die Wirklichkeit sieht, wie Sie wissen, leider etwas anders aus, denn in sehr vielen Organisationen wurde die Sicherheitsstrategie, die bei Internet-VPNs plötzlich zum K.o.-Kriterium aufgestiegen ist, überhaupt nicht angewendet. Hand aufs Herz: Wer verschlüsselt denn seine Dial-InRemote-Access-Verbindungen, wer verschlüsselt seine Frame-Relay- oder ATM-PVCs? Nach vorsichtigen Schätzungen anhand dessen, was die RouterMarktführer umgesetzt haben, sind deutlich weniger als 1% aller WAN- und Remote-Access-Verbindungen durch Verschlüsselung gegen Verletzungen der Datenvertraulichkeit geschützt! Und das, obwohl alle Telefonnetze
309
10 VPN-Design
gesetzlich zur Bereitstellung von Abhöreinrichtungen verpflichtet sind. Natürlich darf das nur mit einer richterlichen Genehmigung erfolgen, aber die Gefängnisse sind voll von Leuten, die Gesetze gebrochen haben. Und pikanterweise ist es, technisch gesehen, wesentlich einfacher, eine Kommunikation über ein leitungsvermittelndes Medium wie ISDN, Frame Relay oder ATM abzuhören, als wenn diese über ein echtes, rein paketvermittelndes IPNetz wie das Internet erfolgt. Fakt ist also, dass im Bereich der herkömmlichen WAN-Infrastruktur nichts von dem getan wurde, was viele Sicherheitsstrategien für die Datenkommunikation über öffentliche Netze fordern. Man hat einfach Augen und Ohren verschlossen und Verbindungen wie Standardfestverbindungen oder FrameRelay-PVCs kurzum als privat eingestuft. Dies muss aber spätestens beim Thema Internet-VPN korrigiert werden, da hier keine spitzfindigen Formulierungen mehr gegen die Zeitungs- und Nachrichtenbeiträge helfen, die die Entscheidungsträger in den Unternehmen zum Thema Viren und andere Gefahren aus den Tiefen des Internets fast tagtäglich zu lesen und zu hören bekommen. Allerdings kann man das Thema Sicherheit in der Planungsphase zeitlich etwas nach hinten verschieben, und zwar bis zur Auswahl der Tunnelingund Sicherheitsprotokolle. Bis dahin kann man mit einfachen Analogien arbeiten und die virtuellen Verbindungen ganz einfach wie reale Verbindungen – oder andere virtuelle Verbindungen, wie sie in ATM oder Frame Relay verwendet werden – betrachten, und sein Design entsprechend aufsetzen.
10.2 Die Planung »640 Kbyte sind genug.« Dieser Ausspruch, es ist kaum zu glauben, stammt von Microsoft-Gründer Bill Gates und verdeutlicht sehr gut das mittlerweile allseits bekannte Dilemma, dass man heute in der Informationstechnologie keine wirklich verlässlichen Zukunftsprognosen stellen und diese zur Grundlage für eine langfristige Planung machen kann. Die Planung eines VPN ist jedoch ebenso kritisch wie die Planung eines »normalen« Netzwerks, denn hier werden meist relativ langfristige Entscheidungen gefällt und auch die damit verbundenen Investitionen getätigt.
10.3 Die Ist-Aufnahme Die Ist-Aufnahme ist ein sehr wichtiger Prozess, der neben seiner Bedeutung für eine solide Planung auch wichtige Erkenntnisse über den tatsächlichen Zustand eines Netzwerks vermittelt. Aus dem Ergebnis lassen sich nebenbei auch Informationen für andere Projekte im Bereich der LAN-Technologie und
310
Die Ist-Aufnahme
für andere Netzwerkbereiche gewinnen. Natürlich bietet die Ist-Aufnahme auch eine gute Gelegenheit, die Netzwerkdokumentation wieder einmal auf einen aktuellen Stand zu bringen, da diese nicht selten der Wirklichkeit etwas hinterherhinkt. Ein Fehler ist dabei aber unbedingt zu vermeiden, nämlich Dinge in die IstAufnahme eines Netzwerks aufzunehmen, die keinerlei Beitrag zur Funktion des Netzwerks leisten. Das erhöht zwar den Aufwand der Ist-Aufnahme, macht sie aber auch erst zu einer solchen. Ein Beispiel: Ein WAN-Router sei mit einer Software ausgestattet, die verschiedene Routingprotokolle für IP, IPX, AppleTalk und VinesIP unterstützt; es werden aber nur IP (mit OSPF) und IPX (mit IPX-RIP) geroutet. Eine korrekte Ist-Aufnahme weist dieses Gerät als Router mit OSPF und IPX-RIP und einer Option für AppleTalk und VinesIP aus. Warum ist diese anscheinende Wortklauberei so wichtig? Ganz einfach: Aus der Ist-Aufnahme wird zusammen mit dem Sollzustand letztendlich ein Anforderungskatalog erstellt, auf dessen Basis die neu zu beschaffenden Systeme ausgewählt werden. Wenn der Router jetzt als System, das IP, IPX, VinesIP und AppleTalk routet, aufgenommen worden wäre, müsste das neue System ebenfalls alle diese Features unterstützen, obwohl der Sollzustand dies vielleicht gar nicht fordert. Der Grund dafür ist die Migrationsphase, während der beide Welten für einen gewissen Zeitraum nebeneinander existieren müssen. Im anderen, korrekten Fall würde man jedoch sehen, dass im Augenblick kein VinesIP und AppleTalk benötigt wird, dass es in Zukunft (Sollzustand) ebenfalls nicht benötigt wird und somit in den neuen Systemen überflüssig ist – und damit auch nicht beschafft und bezahlt werden muss. Für ein kleines Netzwerk, dessen Topologie der Netzwerkadministrator ohnehin komplett im Kopf hat, mag dies vielleicht noch etwas übertrieben scheinen. Aber sobald die Anzahl der Router zwei-, drei- oder sogar vierstellig ist, die Geräte auf weit auseinander liegende Standorte verteilt sind und die Inventarisierung von verschiedenen Personen durchgeführt wird, kommt man um eine strukturierte, gut vorbereitete Ist-Aufnahme und -Auswertung nicht mehr herum. Was ist bei der Ist-Aufnahme nun alles zu ermitteln? Es müssen sowohl technische als auch betriebswirtschaftliche Erkenntnisse gesammelt und aufbereitet werden, nicht zuletzt deshalb, um das tatsächliche Ratiopotenzial eines VPN beurteilen zu können. Hier kann es – das sei an dieser Stelle nicht verschwiegen, obwohl es kein Thema dieses Buches ist – zu Konflikten mit der Arbeitnehmervertretung kommen. Denn wenn man Daten sammelt, die Auskunft über das Verhalten von Benutzern geben können, ist der Betriebsrat in aller Regel zustimmungspflichtig. Dies gilt insbesondere für Verkehrsanalysen. Hier sollte also rechtzeitig mit dem Betriebsrat gesprochen werden, um Konflikte von vornherein zu vermeiden.
311
10 VPN-Design
10.3.1
Technische Aspekte
Hardware Neben einer reinen Hardwareinventur der Router, Switches, Hubs, Remotebridges, Remote-Access-Konzentratoren, Firewalls und Workstations für Netzwerkmanagement-Applikationen sollte auch eine Funktionsbeschreibung und Abschätzung der aktuellen Leistungsfähigkeit erfolgen. Man muss ermitteln, was wo installiert ist, wozu es benutzt wird und benutzt werden kann, was es leistet (Durchsatz, QoS) und inwieweit es erweiterbar ist. In unserem Fall ist es dabei gar nicht mal als schlecht zu bewerten, wenn es sich herausstellt, dass bei einem weiteren Wachstum des Netzwerks bestimmte Geräte das Ende ihrer Verwendbarkeit bereits erreicht haben. Auch hier ist es notwendig, nicht benutzte Module oder Schnittstellen zu kennzeichnen. Software Hierbei gilt es, die auf den inventarisierten Netzwerksystemen installierte Software und weitere Programme zu ermitteln, die eine bestimmte Netzwerkfunktionalität ausüben, beispielsweise Netzwerkmanagement-Applikationen, Dial-In-Clients, DHCP- und DNS-Server, Konfigurationstools usw. Neben der reinen Inventarisierung sollte auch die tatsächlich benutzte Funktionalität hervorgehoben werden – und nur diese, denn Features oder Module, die (aus welchen Gründen auch immer) nicht benutzt werden, dürfen bei einer Ist-Aufnahme keine Rolle spielen. Man kann sie zwar aufnehmen, sollte dies auch tun, muss sie aber entsprechend kennzeichnen. Netzwerkprotokolle Es wird nicht selten vorkommen, dass eine ganze Reihe unterschiedlicher Netzwerkprotokolle in lokalen Netzwerken eingesetzt wird. Im WAN-Umfeld werden aus verschiedenen Gründen oft nur wenige Protokolle verwendet, meist IP, gefolgt von IPX und seltener AppleTalk, VinesIP und Hostprotokollen wie SNA. Über den Sinn oder Unsinn einer solchen Protokollvielfalt muss man sich erst später, bei der Definition des Sollzustands, Gedanken machen. Bei der Aufnahme der Protokolle es ist auch wichtig, ein Mengengerüst aufzustellen, aus dem man ablesen kann, wie viele Benutzer und Applikationen die betreffenden Protokolle überhaupt einsetzen. Verbindungen Hierbei geht es um die Aufstellung aller Verbindungen und Verbindungstypen mit ihren technischen Möglichkeiten. Es sind hierbei erst einmal all die Parameter aufzunehmen, die die jeweilige Technologie kennzeichnen, also Werte
312
Die Ist-Aufnahme
wie maximal zur Verfügung stehende Bandbreite, garantierte Bandbreite, Verzögerung, Verfügbarkeit, Serviceklassen usw. An dieser Stelle kann zu Planungszwecken auch die Mietdauer der Leitung oder Verbindung mit angegeben werden, um später daraus einen geeigneten Migrationsplan abzuleiten und gegebenenfalls fristgerecht bestimmte Leitungen kündigen zu können. Unter diesen Punkt fallen auch Wählverbindungen – oder genauer gesagt: die Verbindungen der Remote-Access-Konzentratoren zu einem Carrier. Verkehrsbeziehungen Dieser Punkt verdient eine besondere Beachtung, denn er bietet in Verbindung mit der zu installierenden VPN-Technologie einen guten Ansatzpunkt zur Optimierung des Netzwerks – also dafür, mehr Leistung für weniger Geld zu bekommen. Denn wenn man aus der Anzahl und Art der bisher existierenden Verbindungen die Anforderungen an die virtuellen Verbindungen eines VPN ableitet, liegt man sehr oft gründlich falsch. Denn wenn Sie beispielsweise aus der Tatsache, dass zwei Niederlassungen über eine 128-Kbit/s-Festverbindung verbunden sind, ableiten, eine virtuelle Verbindung über ein IP-VPN müsse mit garantiert 128 Kbit/s arbeiten, dürfe nur eine unveränderliche Verzögerungszeit von wenigen Millisekunden aufweisen und habe 99,999% Verfügbarkeit zu bieten, ist das schlicht falsch! Hier kann nur eine Analyse helfen, und je gründlicher diese ist, desto besser können Sie später Ihre Anforderungen in einem Service Level Agreement formulieren. Ein detailliertes Verkehrsprofil hilft aber nicht nur dabei, denn wenn Sie das ganze Netzwerk mit einbeziehen, können Sie auch wichtige Erkenntnisse für den vielleicht geplanten Einsatz von Quality-of-Service, Policy-Services usw. erhalten – oder einfach nur Ihr Netzwerk etwas anders strukturieren oder segmentieren. Solch eine Analyse ist nicht trivial. Es gilt eine gewaltige Datenflut zu sammeln, auszuwerten und so aufzubereiten, so dass man daraus entsprechende Maßnahmen ableiten kann. Es müssen sowohl zeitliche Abhängigkeiten als auch Abhängigkeiten von Protokollen und Applikationen ermittelt werden. Sie müssen die Frage beantworten können, welche Applikationen zu welchen Zeiten über ein WAN welche Art von Datenverkehr erzeugen. Sie können, als Vorgriff auf eine später vorzunehmende Priorisierung, die Datenströme hier bereits in verschiedene Klassen einteilen. Dies gilt sowohl für permanente Verbindungen als auch für den Remote Access über analoge oder digitale Wählverbindungen.
313
10 VPN-Design
Benutzerklasse
Anzahl
Std/Wo
Nah %
Fern %
Int %
Gbyte
Heimbüro
45
1.900
35
65
0
0,9
Außenstelle
10
540
22
78
0
2,1
Außendienst
236
154
34
48
18
1,6
Allgem. Remote Access
400
123
62
26
12
2,7
Tab. 10.1: Ein Beispiel für ein mögliches Remote-Access-Verkehrsprofil
Im Remote-Access-Bereich muss eine solche Analyse nicht unbedingt für alle Verbindungen erfolgen, hier kann man sich einen allgemeinen Überblick verschaffen. Hierbei können Sie, wie Sie in Tabelle 10.1 sehen, für die unterschiedlichen Arten von Benutzern der Remote-Access-Infrastruktur ermitteln, wie das entsprechende Profil aussieht. Das in Einwählumgebungen in der Regel eingesetzte RADIUS-Accounting kann sehr wertvolle Informationen liefern. In Tabelle 10.1 wurde eine Auswertung des Accounting über eine Woche vorgenommen. Da hier kein Personenbezug existiert, dürften solche Auswertungen auch betriebsrechtlich problemlos möglich sein. Verbindungsprofile kann man in diesem Beispiel ebenfalls ermitteln, indem man stichprobenartig ein entsprechendes Monitoring von Verbindungen der verschiedenen Remote-Access-Benutzerklassen durchführt. Weiterhin interessant sind Gesamtauswertungen der Verbindungsanzahl über den Tag hin gesehen, um die benötigte Anzahl virtueller Ports zu ermitteln.
10.3.2
Betriebswirtschaftliche Aspekte
Getätigte Investitionen und Restwerte Je nachdem welches Equipment durch die neuen VPN-Systeme ersetzt werden soll, kann es sein, dass diese Geräte noch einen gewissen Restwert haben. Dies hängt im Wesentlichen vom Beschaffungsdatum und der Abschreibungsdauer ab. Insbesondere wenn relativ neue Router oder Remote-AccessKonzentratoren ersetzt werden sollen, muss dieser Wert in eine entsprechende ehrliche Wirtschaftlichkeitsrechnung mit einfließen. Kosten für Datenverbindungen Die Kosten, also die Bereitstellungsgebühren, regelmäßigen Fixkosten und die volumen- oder zeitabhängigen Tarife des Carriers sind entsprechend aufzunehmen. Es ist sinnvoll, auch eine Unterteilung nach Art der Kosten vorzunehmen, um zu sehen, wie hoch die »Leerlaufkosten«, also die Kosten ohne übertragene Daten, des Netzwerks sind. Denn genau dies ist ein Faktor, den man tunlichst nach unten drücken sollte, damit man möglichst nur für die tat-
314
Die Ist-Aufnahme
sächlich übertragene Datenmenge bezahlt. Ganz weg bekommt man Grundgebühren im Augenblick leider nicht, auch dann nicht, wenn man ein VPN einsetzt, aber man kann den Anteil ruhig so weit reduzieren, wie es nur irgendwie möglich ist. Wartungs- und Betriebskosten Hierbei handelt sich um alle Kosten, die der Betrieb des Netzwerks verursacht, außer den Gebühren für die Datenverbindungen und die Personalkosten. Unter die Betriebskosten fallen also Kosten für Wartungsverträge mit Zulieferern, Carriern und Servicefirmen und eine Schätzung von außergewöhnlichen Kosten, die auf den bisher dafür angefallenen Kosten beruht. Personalkosten Neben den reinen Aufwendungen für Gehälter und Sozialleistungen müssen hier auch die Kosten für Qualifikationsmaßnahmen für die Mitarbeiter mit einbezogen werden. Auch hier gilt: Nicht in die Tasche lügen und den wirklichen Personalaufwand ermitteln. Denn oftmals nehmen manche Personen verschiedene Aufgaben in verschiedenen Bereichen wahr, und man muss daher sehr genau feststellen, welchen tatsächlichen Zeitaufwand der Betrieb zurzeit benötigt. Hier sollte möglichst kein Personenbezug erfolgen, sondern der echte Zeitaufwand für den Netzwerkbetrieb in Manntagen ermittelt werden.
10.3.3
Sicherheit
Datenvertraulichkeit im WAN Die Aufstellung, die hier zu machen ist, soll Auskunft darüber geben, welche WAN-Verbindungen (Standardfestverbindungen, Mietleitungen, Frame Relay, ATM, Wählverbindungen über ISDN, Modem, GSM usw.) verschlüsselt sind. Weiterhin müssen die Stärke der Verschlüsselung, das eingesetzte Verfahren und das Schlüsseltauschprotokoll oder die Qualität der Schlüssel (Lebensdauer usw.) angegeben werden. Authentifizierung Hier müssen alle netzwerkbezogenen Verfahren und Systeme zur Authentifizierung von Benutzern beschrieben werden. Nicht mit einbezogen werden natürlich Anmeldungen an Applikationen oder Betriebssystemen. Besonderes Augenmerk ist dabei naturgemäß auf den Remote Access zu legen.
315
10 VPN-Design
Autorisierung Falls Anwender auf Netzwerkebene, abhängig von ihrer User-ID (oder anderen persönlich zuordenbaren Kennzeichen), der verwendeten Arbeitsstation oder des Orts des Zugriffs, unterschiedliche Benutzerrechte zugewiesen bekommen, müssen diese ebenfalls aufgenommen und beschrieben werden, um später entsprechende Anforderungen ableiten zu können. Allerdings sollten solche Rechte wenn möglich von den Systemen vergeben werden, die diese Ressourcen auch verwalten, zum Beispiel von Netzwerkbetriebssystemen oder Datenbankmanagementsystemen. Zugriffsrechte auf Ressourcen wie Datenbanken, Drucker oder Dateiverzeichnisse von Routern oder Remote-Access-Konzentratoren verwalten zu lassen, ist ein falscher Ansatz. Andere Sicherheitsverfahren Im Fall, dass darüber hinaus noch weitere Sicherheitsverfahren auf Netzwerk- oder Transportebene eingesetzt werden, müssen diese so beschrieben werden, dass daraus die möglichen Berührungspunkte zu den neu einzusetzenden Systemen erkannt und berücksichtigt werden können.
10.4 Der Sollzustand Der Sollzustand beschreibt das Netzwerk so, wie es nach der Einführung der VPN-Lösungen aussehen soll. Mit einer guten, realistischen Planung ist dieser Zustand auch grundsätzlich erreichbar. Einzig das Mengengerüst ist der typische Wackelkandidat in der Planung, denn meist wachsen die Anforderungen an die Anzahl von Netzwerk- oder Remote-Access-Ports und der Durst nach immer mehr Bandbreite doch schneller, als ursprünglich angenommen wurde. Eine zu optimistische Schätzung führt auch meist zu höheren Anfangsinvestitionen, die man in der Regel vermeiden möchte, um das Projekt nicht unnötig zu gefährden.
10.4.1
Der unvermeidliche(?) Bruch
In der Vergangenheit bin ich während verschiedener Workshops und Seminare für Kunden und Partnerfirmen oft mit miteinander unvereinbaren Forderungen konfrontiert worden, die meist darauf hinausliefen, dass bestimmte Protokolle, die im Augenblick (noch) eingesetzt wurden, auch im Sollzustand, also im VPN zu unterstützen seien. Die Forderung, IPX-Pakete mit IPSec zu übertragen, ist ein typischer Fall hierfür. Obwohl dies mittlerweile durch Kombinationen verschiedener Protokolle (allerdings mit einem beträchtlichen Overhead, siehe Kapitel 9) möglich ist, gab es vor zwei Jahren nur recht umständliche Lösungen, meist mit mehreren beteiligten Systemen – oder man musste auf IPX, zumindest im IPSec-VPN-Teil, verzichten.
316
Der Sollzustand
Solche Brüche sind aber nicht selten, genau genommen kommen sie in der Praxis ziemlich oft vor. Insbesondere der »Krieg der Protokolle«, aus dem der Veteran IP als unbestrittener Sieger hervorgegangen ist, hat seine Spuren hinterlassen – kaum ein Hersteller berücksichtigt noch auf der Strecke gebliebene Protokolle wie VinesIP, DECNet oder XNS in seinen Neuentwicklungen, selbst AppleTalk wird immer seltener; und die Internet Engineering Task Force (IETF) hat es noch nicht einmal entfernt in Betracht gezogen, sich bei der Standardisierung von IPSec mit IPX zu beschäftigen. Andere Protokolle, wie NetBEUI oder NetBIOS, haben sich durch ihre LAN-Lastigkeit und mangelnde Skalierbarkeit ihr eigenes Grab geschaufelt und werden nur noch durch die Dominanz von Microsofts Desktop-Betriebssystemen künstlich am Leben gehalten. Die daraus resultierenden, unvermeidlichen Brüche ergeben sich also nicht unbedingt aus einer mangelnden Funktionalität der neuen Systeme, sondern spiegeln eher die Tendenz wider, im Netzwerkbereich eine weit reichende Protokollbereinigung zugunsten von IP vorzunehmen. Das macht auch Sinn. Denn wenn sich die Hersteller, anstatt zwanzig verschiedene Netzwerkprotokolle zu unterstützen, darauf fixieren, nur IP – allerdings mit allen wichtigen und neuen Funktionalitäten wie Sicherheit, Class-of-Service usw. – zu implementieren, bringt das viel mehr an nutzbarer Funktionalität. Viele Unternehmen haben sich sowieso bereits seit einiger Zeit entschlossen, ihren »Protokoll-Zoo« langsam abzubauen und zukünftig nur noch IP einzusetzen. Die Einführung der VPN-Technologie wäre ein guter Zeitpunkt dafür. Andere Brüche sollten so weit wie möglich vermieden werden, um den Betrieb nicht unnötig zu beeinträchtigen. Im Einzelfall sollte man im Vorfeld sehr genau untersuchen, ob der Verzicht auf bestimmte Funktionalitäten zumutbar oder tragbar ist und welche Alternativen zur Verfügung stehen. Setzt ein Unternehmen beispielsweise für den Remote Access bereits Tokensysteme wie SecurID ein und hat es vielleicht schon mehrere Tausend Karten im Einsatz, dann ist ein Verzicht darauf oder eine Ablösung durch ein anderes System in der Regel indiskutabel – hier muss eben eine andere VPN-Technologie eingesetzt werden, die dieses Authentifizierungssystem unterstützt.
10.4.2
Randbedingungen
In die Planung eines VPN fließt eine Vielzahl von Kriterien ein, und es sind verschiedene Randbedingungen und Prämissen zu beachten. Neben den »natürlichen« Anforderungen an ein VPN, auf die in Kapitel 3 ausführlich eingegangen wurde, gibt es eine Reihe anderer Faktoren, die den angestrebten Sollzustand beeinflussen:
317
10 VPN-Design
Andere Netzwerkprojekte Die Einführung der VPN-Technologie ist in der Regel nicht das einzige aktuelle Projekt im Netzwerkbereich eines Unternehmens. Andere Projekte können durchaus einen – natürlich auch wechselseitigen – Einfluss ausüben. Ein Beispiel, auf das aus gutem Grund in diesem Buch bereits mehrfach eingegangen wurde, ist die Einführung von Quality-of-Service, um das Netzwerk effizienter ausnutzen zu können. Hier muss einerseits die VPN-Technologie auf QoS ausgelegt werden, und andererseits müssen die QoS-Planer auch berücksichtigen, dass ihr Unternehmensnetzwerk zukünftig streckenweise das Internet benutzt, mit – je nach Service Provider – möglicherweise eingeschränkter QoS-Funktionalität. Neue Applikationen Moderne netzwerkbasierende verteilte Applikationen üben einen zunehmend stärkeren Einfluss auf das Design von Unternehmensnetzen aus. Neben einem immer größer werdenden Bedarf an Bandbreite sind auch zunehmend Qualitätskriterien wie Verzögerungszeiten und Variationen der Paketverzögerung (Jitter) im Anforderungskatalog an das Netzwerk mit aufgeführt. Insbesondere wenn teure internationale Meetings durch Videokonferenzen ersetzt werden sollen oder wenn über IP-Netze telefoniert wird, wird der Netzwerkplaner mit Anforderungen konfrontiert, die in der reinen Datenwelt bislang unbekannt waren. Neue Standorte Dieser Punkt fließt dergestalt in die Planung des Sollzustands ein, als dass hier genau festgelegt wird, wie zukünftige neue Standorte in das VPN zu integrieren sind. Es müssen alle Informationen bereitgestellt werden, um die notwendigen Schritte, wie Beschaffung der Systeme, Bereitstellung der Internetzugänge usw., schnell und reibungslos durchführen zu können. Neue Geschäftsmodelle (E-Business usw.) Neue Geschäftmodelle können ebenfalls einen starken Einfluss auf den Sollzustand des Netzwerks bzw. des VPNs haben – insbesondere dann, wenn die VPN-Technologie benutzt werden soll, um die geschäftliche Kommunikation mit Dritten zu schützen: der klassische Fall eines Extranet-VPN. Ein anderer Fall wäre beispielsweise der, dass ein größeres Unternehmen Teile seines eigenen Netzes Kunden oder Partnern zur Verfügung stellt, also praktisch selbst zu einem kleinen Service Provider wird. Auf diese Weise können ansonsten brachliegende Ressourcen Gewinn bringend genutzt werden.
318
Der Sollzustand
10.4.3
Technische Aspekte
Wie der Sollzustand aus technischer Sicht im Einzelnen auszusehen hat, richtet sich nach einer Vielzahl von Faktoren. Hier kann auch kein allgemein gültiges Beispiel gegeben werden, denn der Durchdringungsgrad der VPN-Technologie kann sehr unterschiedlich sein und von einem »totalen VPN« bis zum Einsatz einiger weniger Remote-Access-VPN-Clients reichen. Bei der großen Dynamik heutiger Netze kann es sogar sinnvoll sein, überhaupt keinen fixen Sollzustand als solchen zu definieren, sondern nur ganz konkrete Richtlinien aufzustellen, mit welcher Art von Komponenten das Netzwerk zu erweitern ist. In einem solchen Fall stellt man einen Plan auf, wodurch und in welcher Reihenfolge die Altsysteme zu ersetzen sind und welche Systeme für neue Standorte oder neue Dienste einzusetzen sind. Diese Festlegungen müssen eine Reihe von Punkten genau erfassen: 왘 Hardware 왘 Software 왘 Provider und Service Level Agreements 왘 Aktuelle Liste zugelassener Gerätetypen
Hardware Hiermit ist weniger der Gerätetyp eines bestimmten Herstellers gemeint, sondern eine allgemeine Klassifizierung der einzusetzenden VPN-Systeme, unterschieden nach Einsatzgebiet (Remote-Access-, Branch-Office- oder Extranet-VPN) und benötigten Systemressourcen. Diese hängen in BranchOffice-VPNs meist von der Größe der Standorte ab, während im RemoteAccess-VPN die Anzahl der Benutzer und die Bandbreite interessieren, die durch die Art der verwendeten Zugangstechnologie (Modem, ISDN, DSL) benötigt wird. Software Hier ist von speziellen Stand-Alone-VPN-Applikationen die Rede, also beispielsweise von IPSec-Clients für die PCs oder Notebooks von Außendienstmitarbeitern. Hier ist zu beachten, dass die Hardware auch mit der zusätzlichen Verarbeitungsleistung fertig wird, die die Verschlüsselungsprogramme benötigen. Manche IPSec-Clients lassen sich überhaupt nur auf Rechnern installieren, die mindestens einen Pentium-I-Prozessor eingebaut haben. Hier ein wichtiger Tipp für internationale Anwendungen: Nicht alle Staaten erlauben es Privatleuten, ihre Daten- oder Sprachkommunikation beliebig zu verschlüsseln. Bei der ganzen Diskussion um Exportbeschränkungen (vor allem aus den USA) in den letzten Jahren wurde etwas anderes aus den Augen verloren, nämlich dass bestimmte Länder den Betrieb, die Einfuhr
319
10 VPN-Design
oder sogar schon den Besitz von Verschlüsselungssystemen teilweise empfindlich bestrafen. Hier sollte zum Schutz der Mitarbeiter unbedingt im Vorfeld abgeklärt werden, was in dem in Frage kommenden Land zulässig ist und was nicht! Provider und Service Level Agreements (SLA) Eine wichtige Entscheidung ist auch die, welcher oder welche Provider eingesetzt werden darf bzw. dürfen. Man kann sich hier bereits auf bestimmte Unternehmen festlegen, falls es aus bestimmten Gründen sinnvoll erscheint. Man kann aber auch lediglich einen Rahmen vorgeben und es der jeweiligen Organisationseinheit oder Niederlassung überlassen, sich einen Provider auszusuchen, der in das technische Schema passt und im vorgegebenen Preisrahmen liegt. Hierbei sollte jedoch das SLA in den kritischen Teilen bereits bereits vorformuliert und nicht mehr änderbar sein. Integration in das Netzwerkmanagement Hier werden konkrete Vorgaben gemacht, welche Funktionalitäten die Systeme bieten müssen, um in das bestehende oder geplante Netzwerkmanagement integriert werden zu können. Allerdings ist hier zu beachten, dass viele gute VPN-Systeme primär als Security-Gateways konzipiert sind und daher nur eine ganz eingeschränkte SNMP-Funktionalität bieten. Dies resultiert aus der praktisch nicht vorhandenen Sicherheit von SNMP. Aktuelle Liste zugelassener Gerätetypen Es ist in jedem Fall angeraten, eine Liste von Systemen für bestimmte Einsatzgebiete zu pflegen. Das Ganze kann als Tabelle gestaltet werden, die für den Fall eines Remote-Access-VPNs etwa so wie in Tabelle 10.2 aussehen könnte. Hersteller A
Hersteller B
Hersteller C
50 Benutzer
Typ A-1
Kein Produkt
Typ C-1
100 Benutzer
Typ A-1
Kein Produkt
Typ C-2
1000 Benutzer
Typ A-2
Typ B-1
Typ C-3
5000 Benutzer
Typ A-3
Typ B-2
Typ C-4
Tab. 10.2: Eine Liste mit zugelassenen Remote-Access-VPN-Konzentratoren verschiedener Hersteller
In diesem Beispiel wurden verschiedene Produkte verschiedener Hersteller auf ihre Eignung untersucht und optional auch getestet. Bei Beschaffungsmaßnahmen entfällt dadurch viel an administrativem Aufwand. Im Idealfall haben die Finanz- und Einkaufsabteilung im Intranet ebenfalls Zugriff auf die Tabellen, und es kann das kostengünstigste Angebot ausgewählt werden.
320
Der Sollzustand
10.4.4
Betriebswirtschaftliche Aspekte
Die betriebswirtschaftliche Sicht des Sollzustands muss sich durch eine Sache ganz besonders auszeichnen: Die Gesamtkosten müssen bei vergleichbarer Leistung und vergleichbarem Umfang des Netzwerks niedriger sein als die Kosten, die in der Ist-Analyse ermittelt wurden. Ansonsten stimmt etwas nicht in der Berechnung, oder das VPN erfüllt seinen Hauptzweck nicht – nämlich die Betriebskosten zu reduzieren. Falls im Sollzustand Erweiterungen des Netzwerks, neue Dienste, erweiterte Leistungen usw. hinzugekommen sind, sollten diese im Sinne einer möglichst hohen Transparenz getrennt ausgewiesen werden. Es muss in jedem Fall ein direkter Vergleich zwischen den Kosten der Ist-Aufnahmen und vergleichbarer Aufwände im Sollzustand möglich sein. Die Kosten für die Einführung bzw. den Umstieg auf die VPN-Technologie sollten Sie in jedem Fall mit in die Berechnung einbeziehen. Grob kann man zwischen folgenden Arten von Kosten unterscheiden, aus denen sich die tatsächlichen Betriebskosten eines VPNs ergeben: 왘 Einmalige Kosten 왘 Laufende Kosten 왘 Personalkosten
Einmalige Kosten Hier fallen insbesondere die Kosten für die Investitionen in Soft- und Hardware sowie die Kosten für Planung, Consulting und die Aufwände für die Installation des Equipments an. Hinzu kommen die Kosten für die Bereitstellung der notwendigen Verbindungen, also der Leitungen zu den POPs des Service Providers. Laufende Kosten Hier entstehen feste Kosten durch monatliche Gebühren für die bereitgestellten Verbindungen und Aufwendungen für Wartungs- und Serviceverträge für die eingesetzten Systeme. Weiterhin fallen noch variable Kosten für die übertragenen Datenvolumina und verbrauchte Verbindungszeiten an. Personalkosten Die Personalkosten sind ein nicht unbeträchtlicher Faktor. Hier muss man nicht nur die direkten Kosten für das VPN-Management mit einbeziehen, sondern muss auch die durch das VPN verursachten Kosten im Bereich des
321
10 VPN-Design
Benutzerservice (Help Desk) mit in Betracht ziehen. Gerade hier können, speziell im Bereich der Remote-Access-VPNs, durch eine nicht optimale Auswahl der VPN-Clientsoftware schnell sehr hohe Kosten auflaufen.
10.5 Die Übergangsphase Die Übergangsphase ist ein ziemlich kritischer Punkt in einem VPN-Projekt, denn hier müssen über einen bestimmten Zeitraum hinweg verschiedene Systeme für den gleichen Dienst parallel betrieben werden, ohne dass sie sich gegenseitig stören dürfen. Je nach dem Umfang des Unternehmensnetzwerks und des geplanten VPN kann eine solche Übergangs- oder Migrationsphase recht lange dauern. Sie sollte in jedem Fall gut geplant werden, um später die notwendigen Prozesse im Griff zu haben. Ausführliche Tests und Probeläufe oder vielleicht abgegrenzte Pilotinstallationen, in denen man wichtige Erfahrungen für den eigentlichen Umstieg gewinnen und später umsetzen kann, können hier nicht schaden. Wenn man clever ist, kann eine Umstellung auf die VPN-Technologie sogar derart erfolgen, dass die Anwender fast nichts davon mitbekommen und sich in ihrer täglichen Arbeitsweise auch nicht groß umstellen müssen. Im Fall von Branch-Office-VPNs ist dies tatsächlich möglich. Hier kann während eines Wartungsfensters der »alte« Router heruntergefahren werden und anschließend das VPN-Gateway mit den gleichen IP-Adressen in Betrieb genommen werden. Die Benutzer bemerken davon gar nichts. Im Remote-Access-Bereich sieht die Sache etwas anders aus, da hier die Benutzer involviert sind. Auf deren Systemen müssen die VPN-Clients installiert werden, und sie haben sich statt im Firmennetz bei einem Provider einzuwählen. Jedoch kann auch hier viel getan werden, beispielsweise mit automatischer Softwareverteilung und vorkonfigurierten Einwählskripts. Dass die Benutzer auch im VPN ihre alten Benutzer-IDs, Passwörter, PINs oder Token-Karten weiterbenutzen können, versteht sich von selbst.
10.6 Die Sicherheitsstrategie Die Sicherheitsstrategie des Unternehmens hat einen entscheidenden Einfluss auf das Design des VPN. Denn sie legt eindeutig fest, welche Sicherheit für die Pakete, die über ein öffentliches Netz transportiert werden, und für die VPN-Systeme selbst gefordert ist. Nach ihr richten sich die Auswahl der Clientsoftware, der Authentifizierungssysteme und etwaige bauliche Maßnahmen – denn ein VPN-Konzentrator, für den man eine starke Verschlüsselung
322
Die Sicherheitsstrategie
vorschreibt, kann nicht in einem Büro oder Verteilerraum betrieben werden –, sofern die Security Policy konsistent umgesetzt wird. Für die netzwerkseitige Planung eines VPN muss man, je nach den Vorgaben der Sicherheitsstrategie, in der Regel folgende Kriterien berücksichtigen: 왘 Welche Daten müssen geschützt werden? Hier kann im Netzwerkbereich
nicht viel getan werden, da der Inhalt der Daten nicht Gegenstand von Protokollen der OSI-Schichten 1 bis 4 ist. Man sollte jedoch den schlimmsten Fall annehmen, dass extrem sensible Informationen im VPN übertragen werden können – auch wenn die Sicherheitsstrategie dies verbieten sollte. 왘 Wie lange müssen die Daten sicher sein? Man muss sich dagegen schüt-
zen, dass ein Angreifer heute verschlüsselte Daten aufzeichnet, die beispielsweise zehn Jahre vertraulich bleiben müssen, und diese vielleicht erst in fünf Jahren mit der dann zur Verfügung stehenden Technologie entschlüsselt. 왘 Vor wem müssen diese Daten geschützt werden? Die Frage ist, gegen
welche Art von Angreifern man sich schützen muss: Einzelpersonen, Gruppen, Firmen oder größere Organisationen oder im schlimmsten Fall Geheimdienste. Diesen Angreifern stehen unterschiedliche Ressourcen zur Verfügung, also muss man sich entsprechend stark schützen. Leider kann man keine allgemein gültigen Aussagen darüber machen, welche Verschlüsselungsalgorithmen und Schlüssellängen am besten einsetzbar sind. In Tabelle 10.3 und Tabelle 10.4 sehen Sie ein paar konservativ aufgestellte Faustregeln für Schlüssellängen von Public-Key-Verfahren und die korrespondierenden Schlüssellängen von symmetrischen Verfahren. Es sollte immer ein ausgewogenes Verhältnis zwischen beiden Verfahren existieren, da die asymmetrischen Verfahren meist die Schlüssel für symmetrische Verfahren generieren oder austauschen. Es macht keinen Sinn, Daten mit 256-Bit-Schlüsseln zu verschlüsseln, die mit einem 512-Bit-Public-Key-Verfahren erzeugt wurden. Umgekehrt ist es auch ein sinnloser Aufwand, mit einer 2048-BitRSA-Verschlüsselung einen symmetrischen 40-Bit-Schlüssel auszutauschen.
Schutzdauer
Schutz vor Angriffen durch Personen
Schutz vor Angriffen durch Organisationen
Schutz vor Angriffen durch Geheimdienste
5 Jahre
1024 Bit
1280 Bit
1536 Bit
10 Jahre
1280 Bit
1536 Bit
2048 Bit
15 Jahre
1280 Bit
1536 Bit
2048 Bit
20 Jahre
1536 Bit
2048 Bit
2048 Bit
Tab. 10.3: Gebräuchliche Schlüssellängen für Public-Key-Verfahren (RSA)
323
10 VPN-Design
Für die Public-Key-Verfahren, die Sie in Tabelle 10.3 sehen, kommen praktisch keine kleineren Schlüssellängen als 1024 Bit vor. Dies spiegelt den augenblicklichen Stand der Wissenschaft wider, versehen mit einer ordentlichen Sicherheitsreserve, um auch in der Zukunft vor bösen Überraschungen sicher zu sein. Falls es die Performance der eingesetzten Systeme zulässt, kann man auch noch größere Schlüssellängen wählen. Im Gegensatz zu symmetrischen Verfahren kann nämlich nicht so einfach bestimmt werden, mit welchem Aufwand Verfahren wie RSA zu brechen sind. Bei sicheren symmetrischen Verfahren ist der Aufwand eindeutig: Die Zeit, die ein Brute-Force-Angriff benötigt, steht in einem festen Verhältnis von Schlüssellänge und eingesetzten Ressourcen (CPU-Geschwindigkeit, Arbeitsspeicher usw.). Bei Verfahren wie RSA kommt noch ein weiterer Faktor dazu, nämlich die weiteren, nicht vorhersagbaren Entwicklungen in der Zahlentheorie, speziell bei den Forschungen im Bereich Faktorisierung und diskrete Logarithmen. Beim IKE-Protokoll sollte man sich sorgfältig darüber Gedanken machen, in welcher Kombination die Schlüssellängen der eingesetzten Algorithmen Sinn machen. Der IPSec-Standard schreibt vor, dass DES mit 56 Bit Schlüssellänge und Diffie-Hellman mit der Oakley-Gruppe 1 (768 Bit) zu unterstützen sind. Dies müssen also die eingesetzten IPSec-Systeme in jedem Fall unterstützen; die Kombination ist auch sinnvoll. Falls man aber eine höhere Sicherheit benötigt, als der DES-Algorithmus bietet und beispielsweise Triple-DES einsetzt, dann muss auch das IKE-Protokoll entsprechend angepasst werden und wenigstens die Oakley-Gruppe 2 mit einem 1024-Bit-Modulus verwendet werden. Ansonsten wäre plötzlich das Schlüsseltausch-Protokoll das schwache Glied in der Kette. Es nutzt nichts, eine starke Verschlüsselung einzusetzen, wenn die Erzeugung des Schlüssels, von dem ja die ganze Sicherheit abhängt, zu schwach ist. Art der Daten
Schutzdauer
Schlüssellänge
Kurzfristige Vertraulichkeit
mehrere Stunden
56 Bit
Unternehmensergebnisse
mehrere Monate
64 Bit
Langfristige Planungen
mehrere Jahre
80 bis 128 Bit
Wirtschaftsgeheimnisse
10 bis 50 Jahre
128 Bit
Personenbezogene Daten
50 Jahre und mehr
>= 128 Bit
Tab. 10.4: Gebräuchliche Schlüssellängen für symmetrische Verfahren (DES, IDEA, usw.)
In Tabelle 10.4 können Sie erkennen, dass eine symmetrische 128-Bit-Verschlüsselung heutzutage auch für hohe Sicherheitsanforderungen als ausreichend angesehen wird. Sichere symmetrische Verfahren (vgl. Kapitel 4) sind hinsichtlich ihrer Sicherheit relativ einfach zu bewerten. Da man den Aufwand für die schnellstmögliche Kryptoanalyse (Brute-Force-Angriff) genau
324
Auswahl der VPN-Technologie
kennt, kann man sich durch entsprechend lange Schlüssel auch gegen Angriffe von Geheimdiensten zuverlässig schützen. Allgemein gelten Schlüssellängen von 128 Bit bei einem sicheren Verfahren, z.B. Triple-DES, als nicht mehr »knackbar«. Der Rijndael-Algorithmus wird als Advanced Encryption Standard (AES) vermutlich noch im Jahr 2001 als verbindlicher Standard vom NIST verabschiedet und relativ schnell in den IPSec-Standard aufgenommen werden, vermutlich als zusätzlicher obligatorischer Verschlüsselungsalgorithmus. Damit steht ein schneller Algorithmus zur Verfügung, der als 128-Bit-Algorithmus in einer gleichen Systemumgebung schon deutlich schneller als 56Bit-DES ist. Allerdings sollte man sich zum heutigen Zeitpunkt noch nicht ausschließlich auf Rijndael stützen, denn der Algorithmus ist einfach noch zu neu. Eine der großen Stärken von DES und damit auch von Triple-DES ist die Tatsache, dass in den letzten 25 Jahren niemand eine Angriffsmethode gefunden hat, die schneller ist als ein Brute-Force-Angriff. Diesen Beweis muss Rijndael erst noch antreten. Für dieses Verfahren gibt es erst vergleichsweise wenige Kryptoanalysen, so dass man es noch nicht sinnvoll mit Triple-DES vergleichen kann. Nicht ohne Grund hat das NIST als AES-Backup-Algorithmus den Veteranen Triple-DES ausgewählt und keinen neuen Algorithmus.
10.7 Auswahl der VPN-Technologie 10.7.1
VPN-Typ
Die Auswahl der geeigneten VPN-Typen ist wohl der einfachste Teil beim Design eines VPN. Je nachdem in welcher Kombination Remote Access, die Verbindung von Geschäftstellen und der Extranet-Zugriff eingesetzt werden, sind die entsprechenden Arten zu verwenden. Es gibt jedoch auch eine gewisse Grauzone zwischen Branch-Office- und Remote-Access-VPNs. In vielen Fällen macht es wirtschaftlich Sinn, kleinere Zweigstellen durch Wählverbindungen anzubinden, da sich ein Internetanschluss per Festverbindung aufgrund des dafür zu geringen Datenaufkommens nicht lohnt. Man benutzt also Wählverbindungen, um diese kleinen Außenstellen zeitweise mit dem Internet zu verbinden. Technisch gesehen verhalten sich diese Lokationen also wie normale Remote-Access-Benutzer, obwohl in Wirklichkeit ein kleines Netzwerk angebunden wird. Hierbei sind allerdings ein paar Aspekte von Wichtigkeit, die sich dadurch ergeben, dass nicht beide VPN-Gateways eine statische, offizielle IP-Adresse haben:
325
10 VPN-Design
왘 Das VPN-Gateway in der Außenstelle bekommt im Regelfall vom Service
Provider eine dynamische IP-Adresse zugewiesen, die sich bei jeder erneuten Einwahl ändert. Deshalb muss dieses Gateway, falls IPSec verwendet wird, unbedingt den IKE Aggressive Mode unterstützen. Feste Adressen werden nur in Ausnahmefällen, unter Umständen gegen zusätzliche Gebühren, vergeben. 왘 Die Verbindungen können nur von der Außenstelle aus aufgebaut werden.
Eine Einwahl von den POPs der Service Provider in die Außenstelle ist nicht möglich. Die einzige Ausnahme ist, dass die Außenstelle eine feste offizielle IP-Adresse hat und die beteiligten Service Provider ein Dial-OnDemand-Routing für die Außenstellen konfigurieren. Dies dürfte aufgrund des Aufwands jedoch mit etlichen Zusatzkosten verbunden sein, die die Wirtschaftlichkeit einer solchen Lösung in Frage stellen können.
10.7.2
Tunneling-Protokolle
Die Auswahl der Tunneling-Protokolle richtet sich nach verschiedenen Kriterien, die sich leider manchmal gegenseitig ausschließen oder ein partielles ReDesign des Netzwerks notwendig machen. Man muss sich nicht auf ein Protokoll festlegen, sondern kann auch mehrere Protokolle parallel benutzen und diese auch verschachteln. Bei Internet-VPNs, die eine gewisse Sicherheit auf der Netzwerkebene bedingen, gibt es keine Alternative zu IPSec – oder notfalls PPTP. Das gleiche gilt auch, wenn eine PKI existiert, in Planung ist oder extern benutzt werden soll. Auch dann führt an IPSec kein Weg vorbei, da IPSec als einziges Protokoll eine Authentifizierung durch eine digitale Signatur ermöglicht. In Tabelle 10.5 finden Sie eine Übersicht über die für Remote-Access-VPNs interessanten Tunneling-Protokolle. Es wurden dabei nur die für diesen Einsatzbereich wichtigen Eigenschaften berücksichtigt. Da es sich, bis auf IPSEc, um Layer-2-Tunneling-Protokolle handelt, können diese nur über PPP-Wählverbindungen betrieben werden. IPSec kann als Layer-3-Tunneling-Protokoll über alle möglichen LAN- und WAN-Infrastrukturen betrieben werden. Bei Remote-Access-VPNs kann es auch ein wichtiger Punkt sein, ob ein zwangsweises oder ein freiwilliges Tunneling eingesetzt werden soll. Da IPSec fast ausschließlich als Ende-zu-Ende-Modell eingesetzt wird, ist hier nur freiwilliges Tunneling möglich. Beim Vergleich der verschiedenen Protokolle sollte beachtet werden, dass auch Kombinationen (vgl. Kapitel 6) unterschiedlicher Tunneling-Protokolle durchaus sinnvoll sein können, um verschiedene Schwächen einzelner Protokolle auszugleichen.
326
Ermitteln der QoS-Parameter
IPSec
PPTP
L2TP
L2F
Dynamische IP-Adressen
Ja
Ja
Ja
Ja
LAN-Verbindungen
Ja
Ja
Nein
Nein
Wählverbindungen (PPP)
Ja
Ja
Ja
Ja
Wissensbasierende Authentifizierung
Ja
Ja
Ja
Ja
Authentifizierung d. digitale Signatur
Ja
Nein
Nein
Nein
Datenverschlüsselung
Ja
Ja
Nein
Nein
Paket-Authentifizierung
Ja
Nein
Nein
Nein
Paket-Integritätsprüfung
Ja
Nein
Nein
Nein
Schutz vor Replay-Angriffen
Ja
Ja
Nein
Nein
Schutz vor Denial-of-Service-Angriffen
Sehr gut
Schwach Mittel
Schwach
Zwangsweises Tunneling
Nein
Nein
Ja
Ja
Freiwilliges Tunneling
Ja
Ja
Ja
Nein
IP-Tunneling
Ja
Ja
Ja
Ja
IPX-Tunneling
Nein
Ja
Ja
Ja
Tab. 10.5: Tunneling-Protokolle für Remote-Access-VPNs
10.8 Ermitteln der QoS-Parameter Die VPN-Technologie muss die erforderlichen QoS-Merkmale, die die abzulösenden Technologien bieten, so weit zur Verfügung stellen, wie sie auch tatsächlich benötigt werden. Falls bestimmte Applikationen, zum Beispiel Sprache oder interaktives Video, gewisse Mindestwerte unbedingt benötigen, so hat dies in die Planung mit einzufließen. In der Regel spielen folgende Parameter und Kriterien eine Rolle, um festzulegen, welche Qualitätsmerkmale eine VPN-Verbindung aufweisen muss: 왘 Minimale Bandbreite 왘 Maximale Bandbreite (Burst rate) 왘 Maximale Verzögerung (Delay) 왘 Variation der Paketverzögerung (Jitter) 왘 Fehlerrate 왘 Verfügbarkeit 왘 Admission Control 왘 IP-QoS auf Fluss- oder Klassenbasis
327
10 VPN-Design
왘 Schnittstellen zu Layer-2-QoS (ATM-Klassen, IEEE802.q, ....) 왘 Schnittstelle zu Policy-Services
Branch-Office-VPN Ein Branch-Office-VPN ersetzt oder ergänzt Festverbindungen, Frame Relay oder ATM. Nachdem in der Ist-Analyse ermittelt wurde, welches Verkehrsprofil diese Verbindungen aufweisen, und die Planungsvorgaben festlegen, für welche neuen Anforderungen neue Applikationen und Dienste eingesetzt werden sollen, kann man daraus ein Anforderungsprofil ableiten, aufgrund dessen die geeignete VPN-Technologie und der geeignete Service Provider ausgesucht werden können – falls dies überhaupt möglich ist und bestimmte Anforderungen den Einsatz eines Internet-VPN ausschließen. Remote-Access-VPN Das Remote-Access-VPN löst den klassischen Remote Access ab, allerdings nur auf der Einwahlseite. Die Anwender selbst wählen sich nach wie vor ein, nun aber bei einem Service Provider und möglicherweise mit einer zusätzlichen VPN-Clientsoftware. Die Qualitätskriterien hierfür sind leider nicht offensichtlich. Denn eine ISDN-Verbindung ist zwar immer 64-Kbit/s schnell, hat minimale Verzögerungen und praktisch keinen Jitter, jedoch sind das keinesfalls die QoS-Merkmale, die von den Anwendungen gefordert sind. Sie sind einfach nur technologiebedingt vorhanden. In diesem Fall kann eine Ermittlung des Verkehrsprofils und der Anforderungen der Applikationen, die über die Einwählverbindung betrieben werden, weiterhelfen, um einen geeigneten Anforderungskatalog an die Qualität der Dienste aufzustellen. Durch den Einsatz neuer Technologien sind viele Service Provider und Carrier mittlerweile in der Lage, ihren Remote VPN-Service um zahlreiche Dienste, unter anderem auch QoS, zu erweitern. Solche Systeme können aufgrund der Applikationen (Protokoll- und Portnummer) und des Benutzers die übertragenen Pakete entsprechend klassifizieren und behandeln. Eine Umsetzung dieser Serviceklassen auf z.B. ATM-Serviceklassen für den weiteren Transport der Pakete durch den Backbone runden den Leistungsumfang solcher Systeme ab.
10.9 Die Realisierung Da moderne Internet-VPNs fast ausschließlich IPSec einsetzen, bildet dieses Protokoll auch den Schwerpunkt in diesem Kapitel.
328
Die Realisierung
10.9.1
Routing im VPN
Wie Sie in Kapitel 7 gesehen haben, basiert IP Security auf einer Sicherheitsstrategie, der IPSec Security Policy. Diese legt genau fest, welche Adressen oder Netze über welche Sicherheitsassoziation miteinander verbunden werden. Dies kommt allerdings einem statischen Routing gleich. Es ist aus Sicherheitsgründen auch nicht vorgesehen, dass in IPSec Policies und SAs auf irgendeine Art »gelernt« werden können, etwa in der Art, wie es bei IP-Routing-Protokollen der Fall ist. Zudem verarbeiten gute und sichere VPN-Systeme auf ihren öffentlichen Interfaces ohnehin nur Pakete der benötigten TunnelingProtokolle und blockieren jede andere Kommunikation. Das normale Routing kann man selbstverständlich ebenfalls nicht einsetzen, da natürlich keine privaten Netze, womöglich noch mit illegalen IP-Adressen, über das öffentliche Interface eines VPN-Gateways in das Internet eingebunden werden dürfen. Zielnetz
Next Hop Interface
Netz C Netz A Netz B Netz D
Direkt GW-1 GW-1 Router-1
Router 1
LAN Tunnel 1 Tunnel 1 LAN
Netz D
VPN-Gateway GW-3
Routingtabelle Gateway GW-3
VPN-Gateway GW-1
Internet
Netz C
Tunnel 1
Netz A
Tunnel 2
Zielnetz
Next Hop Interface
Netz A Netz B Netz C Netz D
Direkt GW-2 GW-3 GW-3
LAN Tunnel 2 Tunnel 1 Tunnel 1
VPN-Gateway GW-2 Netz B
Zielnetz
Next Hop Interface
RIP-Interface
Netz B Netz A Netz C Netz D
Direkt GW-1 GW-1 GW-1
IPSec-Tunnel mit RIP-Interface
Routingtabelle Gateway GW-2
Routingtabelle Gateway GW-1
LAN Tunnel 2 Tunnel 2 Tunnel 2
Abbildung 10.1: Das VPN-Routing arbeitet nur auf privaten Schnittstellen und Tunnelendpunkten.
In großen Netzen ist dynamisches Routing aber unabdingbar, da ansonsten der Management- und Konfigurationsaufwand nicht mehr zu bewältigen ist. Man muss also in einem großen IPSec-Internet-VPN einen Kompromiss ein-
329
10 VPN-Design
gehen und eine spezielle Art von Routing einführen. Dieses Routing, man nennt es meist VPN-Routing, darf auf gar keinen Fall eine Paketweiterleitung (Forwarding) zwischen privaten und öffentlichen Interfaces oder zwischen Tunnelendpunkten und öffentlichen Interfaces durchführen. Das Forwarding darf nur zwischen privaten Interfaces, zwischen privaten Interfaces und Tunnelendpunkten und zwischen Tunnelendpunkten stattfinden. Das Routingprotokoll läuft auch nur im Intranet und über Tunnelverbindungen, nicht jedoch auf dem öffentlichen Interface. In Abbildung 10.1 sehen Sie, wie insgesamt vier verschiedene IP-Netze an drei Standorten über zwei IPSec-Tunnel miteinander verbunden sind. Das Routing ist dabei nur auf den Tunnelendpunkten und den privaten Interfaces möglich. Die Routing-Updates werden nicht auf dem öffentlichen Interface ausgegeben und empfangen, sondern durch die Tunnel übertragen. Bei kleinen Netzen reicht es auch aus, statisches Routing einzusetzen. Bei größeren oder stark wachsenden VPNs sollte man jedoch darauf achten, dass die VPN-Gateways das VPN-Routing auf Basis von RIP-2 oder, im Fall sehr großer Netze, auch OSPF unterstützen.
10.9.2
Remote Access
Der Remote Access ist einer der wichtigsten Stützpfeiler heutiger VPNs, da hier das größte Ratiopotenzial liegt. Allerdings kann man hier auch sehr viele unnötige Kosten erzeugen. VPN-Konzentrator Der VPN-Konzentrator ersetzt den oder die herkömmlichen Remote-AccessServer, in die sich die Remote-Benutzer per Modem oder ISDN eingewählt haben. Um ein solches System funktionell zu ersetzen, müssen eine Reihe von Kriterien beachtet werden: Anzahl paralleler virtueller Verbindungen Die Anzahl der parallelen Tunnel
muss mindestens der Anzahl der Benutzer entsprechen, die sich gleichzeitig einwählen dürfen. Man sollte diesen Wert aber mit Blick auf die Zukunft nicht zu niedrig ansetzen. In der Regel stellt man weniger gleichzeitige Verbindungen zur Verfügung, als man Benutzer hat; man überbucht das System. Der Grad der Überbuchung ist ein Wert, der ausschließlich vom Einsatzgebiet des Remote-Access-VPN bestimmt wird. Die Bandbreiten reichen in der Praxis von einer 1:10-Überbuchung bis hin zur Garantie einer Verbindung. Es gibt nämlich durchaus VPN-Einsatzgebiete, die eine Überbuchung verbieten, z.B. Online-Reservierungssysteme in Reisebüros, Online-Vertragsabschlüsse usw. Hier erfordert das Geschäftsmodell, dass immer eine Verbindung zustande kommen muss.
330
Die Realisierung
Gesamtdurchsatz Der Gesamtdurchsatz ist ein sehr interessanter Faktor, der zunehmend an Bedeutung gewinnt. Zunehmend deshalb, weil er in Zukunft sehr viel höher sein muss als der eines vergleichbaren Remote-Access-Konzentrators. Der Grund liegt darin, dass zunehmend mit höheren Geschwindigkeiten als den 56 Kbit/s eines Modems oder 64 kBit/s von ISDN gearbeitet wird. Die DSL-Technologie ermöglicht Datenraten von mehreren hundert Kilobit. Ein Remote-Access-Server für 600 Benutzer benötigt im schlimmsten Fall einen Durchsatz von 600 x 64 Kbit/s = 34 Mbit/s, ein Wert, der technisch kein Problem darstellt. Im VPN-Konzentrator sähe der schlimmste Fall jedoch so aus, dass alle Benutzer DSL einsetzen und ingesamt 600 x 768 Kbit/s = 460 Mbit/s an Bandbreite benötigen. Dies ist natürlich nur ein theoretischer Fall. Bleiben wir auf dem Teppich und nehmen wir an, dass nur 10% der Benutzer DSL einsetzen und der Rest ISDN. Angenommen, es würden dabei nur 10% der Bandbreite benutzt, dann betrüge die erforderliche Bandbreite in diesem Beispiel immer noch 8 Mbit/s.
Falls jedoch die Remote-Access-Systeme aus wirtschaftlichen Gründen stark überbucht sind, also für 3000 mögliche Benutzer nur 600 Ports oder Tunnel zur Verfügung stehen, dann muss man davon ausgehen, dass in den Stoßzeiten alle 600 Verbindungen gleichzeitig benutzt werden. Der benötigte Durchsatz in diesem Beispiel würde dann auch in höhere Regionen vorstoßen. Etwa 30 Mbit/s sind dabei als durchaus realistischer Wert anzusehen. Bei den Überlegungen zum Durchsatz sei an dieser Stelle darauf hingewiesen, dass es sich bei einem Internet-VPN dabei natürlich um den Systemdurchsatz mit starker Verschlüsselung (>128 Bit) und IPSec-Komprimierung handeln muss und nicht um einfaches Paketweiterleiten. Anbindung an den Service Provider Die Art der Verbindung zum Service Provider richtet sich nach verschiedenen Gegebenheiten. Zum einen ist es der benötigte Gesamtdurchsatz, denn die Verbindung zum ISP muss sinnvollerweise mindestens die gleiche Bandbreite aufweisen; auf der anderen Seite fließen bestimmte, geforderte Qualitätskriterien mit ein.
Aus der Bandbreite und etwaigen Vereinbarungen in einem Service Level Agreement leiten sich dann meist die eingesetzte Technologie und die Geschwindigkeit ab. Unterstützte Authentifizierungssysteme Je nach geplantem Soll-Zustand
und den durch die Migrationsphase bedingten Anforderungen an einen zeitweisen Parallelbetrieb müssen unter Umständen verschiedene BenutzerAuthentifizierungssysteme unterstützt werden. Praktisch alle ernsthaften Remote-Access-Server arbeiten mit RADIUS. Moderne VPN-Remote-AccessKonzentratoren unterstüzten neben RADIUS auch noch andere Verfahren; insbesondere wird zunehmend LDAP-Support angeboten.
331
10 VPN-Design
Falls die Remote-Access-Benutzer bereits Token-Karten zur Authentifizierung benutzen, muss dieses Verfahren ebenfalls unterstützt werden können. Der Idealzustand ist der, dass die Anwender ihre bisherigen User-IDs, Passwörter und Token-Karten weiter benutzen können. IP-Adressmanagement Beim Remote Access ist es üblich, dass die Rechner der
Benutzer während des Verbindungsaufbaus zum Einwählsystem von diesem eine für die Zeit der Verbindung gültige IP-Adresse zugewiesen bekommen. Üblicherweise erfolgt die Zuweisung über das PPP-Protokoll, das alle heutigen Einwählprogramme, z.B. das Microsoft DFÜ-Netzwerk, unterstützen. In diesem Fall bekommt der Remote-Access-Konzentrator, wie Sie in Abbildung 10.2 sehen, bei einer erfolgreichen Authentifizierung vom RADIUS-Server eine IPAdresse geliefert, die er über IPCP (IP Configuration Protocol, vgl. Kapitel 9) dem Remote-Rechner für die Dauer der Verbindung zuweist. Remote-AccessKonzentrator
RemoteAccess-Client
RADIUSServer
ISDN PSTN PPP-LCP und PPP-Authentifizierung
BenutzerIP-Adresse PPP-NCP (IPCP-Konfiguration)
Abbildung 10.2: IP-Adressvergabe beim Remote Access (PPP)
Im Fall von IPSec liegt der Fall jedoch anders, wie Sie in Abbildung 10.3 sehen. Hier besteht ja bereits eine PPP-Wählverbindung zum Service Provider, und der Rechner des Anwenders hat von diesem bereits eine offizielle IPAdresse zugewiesen bekommen. IPSec (im Tunnelmodus) benötigt aber noch eine zusätzliche private IP-Adresse, die in der Regel über entsprechende Informationsnachrichten des IKE-Protokolls an den IPSec-Client übertragen wird. Diese IP-Adresse entspricht der IP-Adresse, die bisher vom RemoteAccess-Server zugewiesen wurde. Hierfür müssen, je nach Planung, die gleichen Mechanismen unterstützt werden können, die auch ein Remote-AccessServer bietet. Die IP-Adressen können im Allgemeinen aus folgenden Quellen stammen: 왘 Interner IP-Adress-Pool im VPN-Konzentrator 왘 IP-Adressvergabe pro Benutzer im VPN-Konzentrator 왘 IP-Adressvergabe von einem RADIUS-Server, hier auch per User oder aus
einem Pool
332
Die Realisierung
Service Provider RADIUS-Server
RemoteAccess-Client
IPSecGateway
POP ISDN PSTN
Kunden RADIUS-Server
Internet
IPSec- DFÜClient Client
PPP-LCP und PPP-Auth PPP-NCP (IPCP-Konfig.)
BenutzerIP-Adresse
IP-Verbindung IKE Phase 1 IKE-Konfig (Virtuelle IP-Adresse zuweisen)
IKE-Auth IP-Adr.
IKE Phase 2 IPSec-ESP/AH-SA
Abbildung 10.3: Das IKE-Protokoll kann zur Zuweisung einer privaten IP-Adresse benutzt werden.
Optional sollten noch folgende Verfahren unterstützt werden, die in modernen und zukunftssicheren Netzen immer wichtiger werden: 왘 IP-Adressvergabe von einem DHCP-Server 왘 IP-Adressvergabe von einem LDAP-Verzeichnisdienst per User, per Gruppe
oder aus einem Pool Accounting und Logging Da der Remote Access je nach Ausbaustufe ein
beträchtlicher Kostenfaktor ist, gibt es schon seit längerem entsprechende Accounting-Funktionen. Mit den damit aufgezeichneten Daten ist es möglich, die Leistungen und daraus resultierenden Kosten bis auf Benutzerebene auszuweisen. Üblicherweise benutzt man dafür auch RADIUS. Ein brauchbarer VPNKonzentrator erzeugt ebenfalls RADIUS-Accounting-Datensätze und schickt diese zum RADIUS-Accounting-Server. Damit kann man seinen virtuellen Remote Access reibungslos in das bestehende Abrechnungssystem integrieren. Da Remote Access, genau wie ein VPN auch, öffentliche Netze benutzt, wurde in vielen Installationen bereits reger Gebrauch von den Logging-Funktionen gemacht. Logging dient im Gegensatz zum Accounting weniger zu Abrechnungszwecken als zur Kontrolle eines ordnungsgemäßen und vor
333
10 VPN-Design
allem sicheren Betriebs von Remote-Access-Konzentratoren. Beim Logging kann man sowohl kritische Systemzustände als auch mögliche Angriffe erkennen und darauf reagieren. Gute Logging-Implementierungen erlauben es, verschiedene Logs zu führen, entsprechend der Art der Daten, die gesammelt werden sollen: 왘 Security Log – für alle sicherheitsrelevanten Ereignisse 왘 Configuration Log – für alle Konfigurationsänderungen 왘 System Log – für System- und Geräte-Informationen
Viele spezielle VPN- oder Security-Gateways haben einen einfachen, aber wirkungsvollen Schutz gegen eine bestimmte Art von Denial-of-ServiceAngriffen (DoS) eingebaut. Falls man nämlich zu viele Logging-Informationen sammelt, bietet man damit leider auch ein hervorragendes Angriffsziel. Dies wird an einem kleinen Beispiel schnell deutlich: Wenn ein IPSec-System alle abgewiesenen und nicht bearbeiteten (Silent-discard-)Pakete aufzeichnet, dann erfordert dies einen gewissen Aufwand durch die interne Aufzeichnung und das Schreiben auf einen externen Server. Wenn nun ein Angreifer eine Reihe von kleinsten Paketen, die in jedem Fall abgewiesen werden, auf ein VPN-Gateway schickt, dann kann er, ohne große Netzlast auf dem öffentlichen Interface zu erzeugen, das Gateway dazu bringen, nichts mehr zu tun, als Logging-Einträge zu verarbeiten. Also sollte man sein System sorgfältig konfigurieren und dafür Sorge tragen, dass nur wichtige Ereignisse aufgezeichnet werden. Sicherheit Die Sicherheit eines VPN-Remote-Access-Konzentrators kann
man in zwei Teilbereiche untergliedern: die Sicherheit der eingesetzten Tunneling-Protokolle und die Sicherheit des Systems selbst. Echte Sicherheit bieten praktisch nur zwei Tunneling-Protokolle, IPSec und PPTP. Letzteres ist allerdings schon mehrfach Zielscheibe von Angriffen geworden (vgl. Kapitel 6) und bietet auch bei weitem nicht so viele Sicherheitsmechanismen wie die IP-Security-Protokollfamilie. Die Systemsicherheit selbst ist äußerst kritisch. Das wird leider in vielen Fällen völlig unterschätzt. Versetzen wir uns einmal kurz in einen Angreifer, der auf bestimmte Netzressourcen eines Unternehmens illegal zugreifen will. Er wird, um sich selbst zu schützen, möglichst versuchen, nicht physisch in das Unternehmen selbst einzudingen, sondern dies über Remote Access oder das Internet zu tun. Wenn er nun feststellt, dass das Unternehmen in seinem VPN durchgehend IPSec, unter Umständen sogar noch mit starker Verschlüsselung (z.B. Triple-DES), einsetzt, dann wird er es an dieser Stelle erst gar nicht versuchen. Er sucht sich dann einen anderen Schwachpunkt im Netzwerk, und dieser kann im Zugriff auf die IPSec-Gateways liegen, falls hiergegen keine Maßnahmen getroffen werden. Hier gibt es ein paar Dinge, die man unbedingt beachten sollte:
334
Die Realisierung
왘 Kein direkter Out-of-Band-Zugriff: Falls man das Gerät über Modem- oder
ISDN-Verbindungen fernwarten möchte, öffnet man damit die klassische Hintertür. Wenn man unbedingt einen Out-of-Band-Zugriff benötigt, dann muss dieser verschlüsselt (SSL, IPSec) erfolgen und stark authentifiziert werden. 왘 Der lokale Zugriff auf ein VPN-Gateway sollte in jedem Fall verschlüsselt
erfolgen, entweder über SSL oder noch besser gleich über IPSec. Denken Sie daran: Mehr als 80% aller Angriffe auf Rechner und Netzwerke erfolgen innerhalb eines Unternehmens und nicht von außen. 왘 Die Systeme müssen ihrer Sicherheitseinstufung entsprechend in durch
bauliche Maßnahmen sicheren Umgebungen mit einer geeigneten Zugangskontrolle betrieben werden. Administration Beim Thema Administration scheiden sich oft die Geister,
denn hier treffen praktisch zwei »Weltanschauungen« aufeinander: die textbasierende und die grafische Administration. Hier objektiv zu urteilen ist unmöglich, da beide Varianten sowohl Vor- als auch Nachteile aufweisen und auch sehr stark von persönlichen Vorlieben der Administratoren selbst geprägt sind. In der Praxis ist es natürlich eine geschickte Lösung, wenn ein VPN-System beide Varianten unterstützt und der Administrator das auswählt, was es ihm erlaubt, seine Tätigkeit am effizientesten auszuüben. Heute üblich sind grafische Oberflächen auf Basis von Webbrowsern, da hiermit praktisch von jedem Rechner aus auf das VPN-System zugegriffen werden kann. Aber sowohl die grafische als auch die textbasierende Administration kann gut oder schlecht implementiert werden und im letzten Fall erhöhte Personalkosten, oder schlimmer noch, auch Sicherheitsprobleme nach sich ziehen. Hier sollte man auf Übersichtlichkeit, Einfachheit und Konsistenz achten – der Administrator sollte genau wissen, was er tut und was seine Änderungen an der Konfiguration tatsächlich bewirken. Integration in PKI und Verzeichnisdienste Moderne und zukunftssichere Netze setzen zum Teil schon Verzeichnisdienste oder PKIs (Public Key Infrastructure) ein oder planen zumindest, dies in der Zukunft zu tun. Für die Realisierung eines VPN bedeutet dies, dass es die entsprechenden Schnittstellen zu solchen Systemen bereits unterstützen muss.
Im Bereich der Verzeichnisdienste gab es in der Vergangenheit viele herstellereigene Ansätze, die sich aber letztendlich nicht durchsetzen konnten. Beispiele hierfür sind StreetTalk von Banyan und NDS von Novell. Auch Standards, wie z.B. X.500, hielten nur wenig Einzug in praktische Implementierungen, da sie nicht selten etwas überdimensioniert erschienen. Auch LDAP (Lightweight Directory Access Protocol) fristete lange ein Schattendasein, wird aber immer mehr zu dem Standardprotokoll für Verzeichnisdienste. Dies liegt an der
335
10 VPN-Design
zunehmenden Unterstützung durch Hersteller von Betriebssystemen und Netzwerkkomponenten. Sun/Netscape, Microsoft und Novell setzen immer mehr auf dieses Protokoll, und viele Netzwerkdienste wie Policy Services oder die Verwaltung von Systemprofilen basieren auf LDAP. Im Bereich der PKIs setzen sich erst langsam die Standards der IETF durch, dadurch haben die verschiedenen Hersteller lange Zeit ihr eigenen, zu anderen Produkten inkompatiblen Systeme entwickeln können. Es gibt zwar eine Reihe von Standards, zum Beispiel X.509 für das Format von digitalen Zertifikaten, aber die Verteilung und das Management erfolgen meist noch mit proprietären Produkten und Protokollen. Hier muss man sowohl darauf achten, dass die Standards unterstützt werden, als auch auf die im Unternehmen eingesetzten oder noch einzusetzenden Produkte. VPN-Clients Um es vorweg zu nehmen: In einem Remote-Access-VPN entscheidet zu einem maßgeblichen Teil der VPN-Client darüber, ob das VPN Kosten letztendlich einspart oder viel mehr Kosten erzeugt – oder ob es überhaupt in großem Maßstab einsetzbar ist. Das Einsparen von Kosten wurde bereits besprochen. Wodurch kann ein VPN-Client hohe Kosten erzeugen? Ganz einfach: Je größer ein Remote-Access-Einsatz ist, desto mehr Anwender benutzen den VPN-Client und desto mehr multiplizieren sich auch die Probleme, die es damit eventuell gibt. Wenn 100 Clients produktiv eingesetzt werden und ein Problem erzeugen, das eine Hotline pro Woche 30 Stunden kostet und einen Ausfall der Arbeit mit den Clients von 50 Stunden zur Folge hat, dann sind es bei 1000 Systemen schon 300 Stunden Hotline und 500 Stunden Arbeitsausfall. Worauf muss man bei VPN- oder speziell auch IPSec-Clients besonders achten? Die folgende Aufzählung deckt die wichtigsten Punkte ab, die im Folgenden noch ausführlich besprochen werden: 왘 Einfache Installation ohne Eingaben des Benutzers 왘 Keine weitere Konfiguration durch den Benutzer notwendig 왘 Keine Konfigurationsänderung durch den Benutzer möglich 왘 Zentrale Verwaltung und Konfiguration 왘 Split-Tunneling darf nicht durch den Anwender konfigurierbar sein 왘 Integrierte Unterstützung für Token-Authentifizierung 왘 Integrierte Unterstützung für Authentifizierung mit digitalen Signaturen 왘 Benutzertransparentes Zertifikat-Management 왘 Automatischer Backup/Failover-Mechanismus 왘 API oder direkter Aufruf per Kommandozeile oder System-Call
336
Die Realisierung
Die Installation des VPN-Clients kann bereits schon viele Kosten sparen, und zwar dann, wenn der Benutzer dies selbst tun kann und nicht aus diesem Grund zum Benutzerservice muss. Somit sparen sowohl der Benutzer als auch die PC-Administration wertvolle Zeit. Ein gute Installation läuft ohne Abfrage von Parametern durch und kann an die Gegebenheiten eines Unternehmens angepasst werden (Customizing). Der Benutzer braucht im Idealfall gar nichts zu konfigurieren; die Installation ist damit praktisch von jedem durchzuführen, der bereits einen PC benutzt. Clientimplementierungen, bei denen Anwender irgendwelche Systemdateien manuell editieren müssen oder bei denen Parameter abgefragt werden (Beispiel: »Wollen Sie Perfect Forwarding Secrecy [Ja/Nein]?«), mit denen ein Anwender nichts anfangen kann, sollten von vornherein nicht in Betracht gezogen werden. Damit kommen wir auch zum nächsten Punkt, denn bei einer guten VPN-Clientsoftware braucht der Anwender nicht nur nichts zu konfigurieren, sondern er darf es überhaupt nicht können. Denn es ist der Horror eines jeden Sicherheitsverantwortlichen, wenn die Endanwender in der Lage sind, auf ihren IPSec-Clients irgendwelche Konfigurationsänderungen vorzunehmen – zum Beispiel zum Zweck der »Performancesteigerung« die Verschlüsselung abzuschalten. Es gibt zwar die Möglichkeit, dies im VPN-Remote-Access-Konzentrator zu unterbinden und überhaupt keine IPSec-Sicherheitsassoziation aufzubauen, aber dann existiert wieder der Fall, dass vom Benutzer ein Anruf (»Mein Rechner tut’s nicht mehr«) im Help Desk erfolgt. Aber auch andere, nicht sicherheitsrelevante Änderungen, die ein Anwender – vielleicht mit den besten Absichten vornimmt – können Probleme und Kosten nach sich ziehen. Idealerweise werden die VPN-Clients zentral konfiguriert, entweder auf dem Remote-Access-VPN-Konzentrator selbst oder auf einem Directory-Server. Die aktuelle Konfiguration wird dann bei jedem Verbindungsaufbau auf den VPNClient heruntergeladen. Neben der Sicherheit und dem Fehlen der Möglichkeit einer falschen Konfiguration durch den Benutzer ist damit auch eine sehr effiziente Möglichkeit der Administration gegeben, und alle Änderungen sind absolut zeitnah. Änderungen für möglicherweise mehrere Tausend VPN-Clients werden nur einmal vorgenommen, und jeder Client bekommt sein Update beim nächsten Einwählen – einfacher und effizienter geht es kaum noch.
IPSec-Client mit Spit-Tunneling
tftp p, htt
IPSec-RemoteAccess-Konzentrator
IPSec-Tunnel
Internet Abbildung 10.4: Split-Tunneling kann eine Sicherheitslücke erzeugen. 337
10 VPN-Design
Ein Sache, die auf gar keinen Fall durch den Anwender beeinflussbar sein darf, ist das so genannte Split-Tunneling. Split-Tunneling bedeutet, wie Sie in Abbildung 10.4 sehen können, dass sowohl ein sicherer IPSec-Tunnel in das Unternehmensnetz existiert als auch parallel dazu Datenverkehr mit anderen Gegenstellen, z.B. im Internet, möglich ist – ein fatales Sicherheitsloch, denn damit öffnet man das Unternehmensnetz dem Internet. Das möchte man natürlich nicht, also ist Split-Tunneling in aller Regel unerwünscht, und eine gute Clientimplementierung sorgt dafür, dass, sobald sie aktiv ist, Datenverkehr nur noch durch den Tunnel möglich ist. Von dieser Regel gibt es allerdings zwei Ausnahmen, in denen es sinnvoll ist, sowohl durch einen Tunnel als auch mit anderen Systemen zu kommunizieren. Die eine ist ein virtuelles lokales Netzwerk auf IP-Ebene, in dem verschiedene Systeme über IPSec miteinander kommunizieren und andere Systeme nicht. Die andere Ausnahme, die Sie in Abbildung 10.5 sehen, sind kleine Heim- oder Zweigbüros, in denen ein oder mehrere Rechner mit IPSec-Clients sowohl mit dem Unternehmensnetz als auch lokal kommunizieren müssen, zum Beispiel um Daten des zentralen SAP-Systems, mit dem sie über einen IPSec-Tunnel kommunizieren, lokal auf einem Netzwerkdrucker auszugeben. IPSecClient
10.1.1.0/24
IPSecGateway
Router
IPSec-Tunnel
Internet Netzwerkdrucker
Abbildung 10.5: Hier ist sorgfältig konfiguriertes Split-Tunneling sinnvoll.
Gute VPN-Systeme, Konzentratoren und die dazugehörigen Clients, bieten die Möglichkeit, dass der Administrator zentral eine Liste von Netzwerken, Rechneradressen oder Domainnamen pflegt, mit denen bei freigegebenem Split-Tunneling kommuniziert werden darf. In dem Beispiel in Abbildung 10.5 würde der Administrator Split-Tunneling freigeben und als zulässigen IP-Adressbereich das lokale Klasse-C-Netzwerk 10.1.1.0 eintragen, in dem sich der PC befindet. Somit kann keine Kommunikation am IPSec-Tunnel vorbei mit dem Internet stattfinden, innerhalb des lokalen Netzwerks können die Systeme jedoch bei einem aktiven Tunnel miteinander kommunizieren. Die verschiedenen Authentifizierungssysteme sollten im Sinne einer guten Handhabbarkeit durch den Benutzer von der Clientsoftware unterstützt werden. So sollten zum Beispiel bei einer Authentifizierung, beispielsweise mit
338
Die Realisierung
SecurID-Token-Karten, statt eines Passwort-Feldes die beiden Felder für PIN und Token angezeigt werden. Spezielle Funktionen, wie – wenn wir beim Beispiel SecurID bleiben – Next-Token-Modus oder New-PIN-Modus, sollten ebenfalls von der VPN-Clientsoftware erkannt und aktiv unterstützt werden können. Das Gleiche gilt auch für den Umgang mit digitalen Zertifikaten, falls eine Authentifizierung mit digitalen Signaturen eingesetzt werden soll. Das ganze Zertifikat-Management, inklusive der Erzeugung der asymmetrischen Schlüssel und der Certificate-Requests, sollte so weit wie nur irgendwie möglich vom Endanwender abgeschirmt werden können. Es ist einem normalen Anwender, also keinem PC- und Sicherheitsexperten, nicht unbedingt zumutbar, manuelle Zertifikat-Anforderungen zu erzeugen und diese mit Cut-and-Paste per Datei oder E-Mails an eine CA zu übertragen oder erhaltene Zertifikate manuell zu importieren. Leider muss ich an dieser Stelle sagen, dass die Technologie, die heute in Form verfügbarer Produkte vorliegt, dem nur unzureichend Rechnung trägt. Insbesondere die Implementierung der Internetstandards der IETF zum Thema PKIX (Public Key Infrastructure X.509) lässt bei etlichen Herstellern sehr zu wünschen übrig, und zwar sowohl bei den Herstellern der VPN-Systeme als auch bei Herstellern von PKI-Software. Und hier müssen beide Seiten mitspielen. Ganz trübe sieht es dann bei der Unterstützung von Chipkarten aus, da werden im Augenblick leider fast nur proprietäre Lösungen angeboten. Das ist umso schlimmer, als dies die einzige sichere und vernünftige Art des Umgangs mit digitalen Signatur-Zertifikaten ist. Falls der Remote Access über ein VPN eine geschäftskritische Stellung einnimmt, dann sind hier natürlich Maßnahmen zur Ausfallsicherheit erforderlich. Das Ganze sollte natürlich weitgehend automatisch erfolgen, der Benutzer sollte weder irgendwelche Konfigurationen vornehmen müssen noch manuell ein Backup-System anwählen müssen. Auch hier sollte eine zentrale Konfiguration erfolgen, und die VPN-Clients »lernen« ihre Backup-Systeme bereits beim Verbindungsaufbau. Natürlich muss auch die letzte Einstellung gespeichert werden, denn wenn das primäre System nicht verfügbar ist, muss ein Ausweichsystem bekannt sein. Um eine automatische Zuweisung von Backup-Systemen beim Verbindungsaufbau kommt man überhaupt nicht herum, wenn die zentralen VPN-Konzentratoren eine automatische Lastverteilung (Loadbalancing) untereinander durchführen. Denn dann weiß man ja nie im Voraus, auf welchem VPN-Konzentrator die aktuelle IPSec-SA gerade terminiert wird, und kann somit auch keine statischen Backup-Adressen verwenden. Einige, vor allem größere Unternehmen haben spezielle, teilweise eigenentwickelte Oberflächen für den Remote Access ihrer Mitarbeiter. Diese Applikationen pflegen Einwählverzeichnisse, Sicherheits- und Systemeinstellungen
339
10 VPN-Design
und bieten dem Anwender eine einfache, einheitliche und komfortable Anwenderoberfläche. Systemdienste, wie zum Beispiel das Microsoft-DFÜNetzwerk, werden von dieser Applikation automatisch gestartet, ohne dass der Anwender etwas dazu tun muss. Wenn nun zusätzlich zum Einwähldienst noch ein VPN-Client hinzukommt, muss dieser ebenso von der Applikation gestartet werden können. Entweder bietet der Client dafür ein API (Application Programming Interface), also eine Programmierschnittstelle, oder er sollte wenigstens durch einen Kommandozeilenaufruf oder einen Systemaufruf gestartet und mit entsprechenden Parametern, z.B. Zieladresse, User-ID, PIN und Token, versorgt werden können, um dann möglichst im Hintergrund abzulaufen. Client-Rollout und Updates Der Rollout der VPN-Clients ist auch eine heikle Angelegenheit, die entweder sehr einfach oder sehr aufwendig und damit sehr teuer werden kann. Gute Clients sind vom Endbenutzer ohne Spezialkenntnisse zu installieren. Sie bieten die Möglichkeit, dass das Unternehmen, das die Clients einsetzt, diese auch bestimmten Gegebenheiten anpassen kann. Insbesondere Zielverzeichnisse, Zieladressen von VPN-Gateways und andere Konfigurationsparameter, die von Unternehmen zu Unternehmen unterschiedlich sind, sollten in einer entsprechenden Konfigurationsdatei den Installationsvorgang steuern. Die Softwareverteilung kann man sich dann auch sehr einfach machen, indem man den Client auf einen öffentlichen Server legt oder per Datenträger an die Anwender verteilt. Ein Umstieg eines Remote-Access-Benutzers, der Token-Karten zur Authentifizierung benutzt, auf die VPN-Technologie kann bei einem gut geplanten Rollout und einer geeigneten Konfigurationsdatei etwa so aussehen, wie Sie es in Abbildung 10.6 sehen können: 1. Der Remote-Access-Anwender greift per Einwahl auf das Unternehmensnetz zu und lädt sich von einem Webserver das Installationsimage des VPN-Clients herunter. 2. Anschließend startet er die Installation, und der IPSec-Client wird auf seinem Rechner installiert und konfiguriert. Als Teil der Installationsroutine kann optional die Erzeugung eines neuen Eintrags für das Microsoft DFÜNetzwerk erfolgen, um sich damit zu einem Internet Service Provider zu verbinden. 3. Der Anwender startet seinen IPSec-Client, der seinerseits das Microsoft DFÜ-Netzwerk startet und eine Verbindung zum ISP aufbaut, gibt seine User-ID, seine PIN und sein Token ein und kann sich damit sofort am IPSec-VPN-Konzentrator authentifizieren, da dieser, ebenso wie der Remote-Access-Konzentrator auch, mit dem Token-Server kommuniziert.
340
Die Realisierung
Man sieht, dass der Rollout, auch von Tausenden von Clients, relativ schnell und effizient vonstatten gehen kann, vorausgesetzt, die VPN-Clientsoftware ist dementsprechend ausgelegt. Zentrale
ISDN PSTN
RemoteClient
RemoteAccessKonzentrator
1. VPN-Clientimage herunterladen
Webserver mit dem Installationsimage des VPN-Clients
VPNKonzentrator 2. VPN-Client installieren
TokenServer
Internet 3. VPN-Zugriff
Abbildung 10.6: Online-Verteilung der VPN-Clientsoftware
10.9.3
Kleine Außenstellen und Heimbüros
Im Fall von sehr kleinen Außenstellen oder Heimarbeitsplätzen, die man kurz unter dem Oberbegriff SOHO (Small Office Home Office) zusammenfasst, steht man oft vor dem Problem, dass sich aufgrund des geringen Datenaufkommens keine Festverbindungen – oder in unserem Fall keine BranchOffice-VPN-Modelle – rentieren. Man weicht daher auf Wählverbindungen aus, die bei richtigem Einsatz nur dann Kosten erzeugen, wenn auch wirklich Daten übertragen werden. Üblicherweise benutzt man dafür heutzutage spezielle ISDN-Router, die sich in normale Remote-Access-Konzentratoren einwählen. Dabei gilt es, vor allem im Hinblick auf den VPN-Einsatz, zwei grundsätzlich verschiedene Einsatzszenarien zu unterscheiden: 왘 Der ISDN-Router verhält sich gegenüber dem Remote-Access-Konzentra-
tor genau wie ein normaler Benutzer und bekommt insbesondere auch eine dynamische IP-Adresse zugewiesen. Der Router »versteckt« das kleine SOHO-Netzwerk, indem er One-to-Many-NAT einsetzt. Diese Form von NAT (Network Address Translation) setzt dynamisch eine IPAdresse auf mehrere private Adressen um. Hierbei können Verbindungen nur aus dem SOHO-Netz heraus aufgebaut werden.
341
10 VPN-Design
왘 Der ISDN-Router verhält sich wie ein normaler Router. Er hat eine statische
IP-Adresse, und sein lokales SOHO-Netz kann mittels Routing-Updates im Unternehmensnetz verteilt werden. In vielen Fällen wird der RemoteAccess-Konzentrator auch für so genanntes Dial-On-Demand-Routing konfiguriert, er kann also auch eine Verbindung zum ISDN-Router aufbauen. Der erste Fall bereitet mit einem geeigneten IPSec-Gateway keine nennenswerten Probleme. Hier gibt es Systeme, die mit entsprechend starker Sicherheit (z.B. IPSec-ESP mit Triple-DES und SHA-1) ausgestattet sind und durch den IKE Aggressive Mode auch von einem Service Provider bei der Einwahl eine dynamische IP-Adresse zugewiesen bekommen können. Spezielle NATImplementierungen oder die Verwendung virtueller IPSec-Interfaces ersetzen auch die One-to-Many-NAT-Funktionalität normaler ISDN-Router, die mit IPSec nicht kompatibel ist. Im zweiten Fall wird es allerdings problematisch, wenn die Funktionalität vollständig übernommen werden muss. Denn hier muss der Service Provider eine Menge Dinge tun, die er sonst nicht tut und vor allem auch überhaupt nicht mag: 1. Er muss statische IP-Adressen für jedes System reservieren. 2. Er muss seine POPs für Dial-Out konfigurieren. 3. Er muss auf irgendeine Art das Dial-On-Demand-Routing mit den privaten Netzen des Kunden nachbilden. 4. Weiterhin muss das VPN-Gateway des Kunden bereits eine Art »virtuelles Dial-On-Demand-Routing« durchführen. Das sind alles relativ ernste Probleme. Die beiden ersten Punkte sind technisch kein Problem, es dürfte nur einiges kosten. Die beiden letzten Punkte sind allerdings ernster. Hier sind einige technische Klimmzüge notwendig, denn »saubere« Lösungen gibt es hierfür noch nicht. Es kann sich sogar herausstellen, dass hier ein Branch-Office-Modell die billigere und einfachere Alternative ist. Bei Heimbüros ist das allerdings eher zweifelhaft, hier wird man eher seine Infrastruktur etwas umstellen. Oder es ist tatsächlich der Fall eingetreten, in dem es weder technisch noch wirtschaftlich Sinn macht, die VPN-Technologie einzusetzen, und man weiter ISDN-Dial-In verwenden sollte.
10.9.4
Skalierbarkeit
Die Skalierbarkeit ist ein weiterer wichtiger Faktor, da es wichtig ist, die Größe der Systeme, also den Durchsatz und die Anzahl gleichzeitiger Verbindungen, entsprechend den jeweiligen Gegebenheiten anpassen zu können. Es müssen verschiedene Arten von Anwendungen und Standorten versorgt werden können:
342
Die Realisierung
Einsatzbereich
Gerät
Anzahl Tunnel
Durchsatz
Remote Access Client
Clientsoftware
1
56 Kbit/s bis 1 Mbit/s (DSL)
Heimbüro
Client, Gateway 1-5
64 Kbit/s bis 1 Mbit/s
Kleine Außenstelle
Gateway
1-5
64 Kbit/s 2 Mbit/s
Mittlere Niederlassung
Gateway
>10
2 bis 10 Mbit/s
Große Niederlassung, Zen- Gateway trale
10-100
2 bis 34 Mbit/s
Remote-Access-Konzentrator
1000+
34 bis 70 Mbit/s
Gateway
Tab. 10.6: Eine Übersicht über in verschiedenen Einsatzbereichen gebräuchliche VPN-Systeme
In Tabelle 10.6 sehen Sie eine Übersicht über verschieden große VPN-Systeme, abhängig von deren Einsatzbereich. Die Anzahl der Tunnel und der Durchsatz können natürlich je nach Einsatz und Infrastruktur stark schwanken. Die VPN-Remote-Access-Clients können natürlich auch in ganz kleinen Heimbüros eingesetzt werden, vor allem wenn dort nur ein Rechner verwendet wird und die Peripherie direkt am PC angeschlossen ist. Auch die 1000 Tunnel beim Remote Access sind nur ein grober Anhaltspunkt, denn beispielsweise benötigt ein Unternehmen mit nur 500 Mitarbeitern keine 1000 virtuellen Einwählports.
10.9.5
Redundanz und Ausfallsicherheit
Redundanz und Ausfallsicherheit sind Anforderungen, die aus keinem Netzwerk mehr wegzudenken sind. Entsprechend muss auch ein VPN ausgelegt werden, will man keinen Rückschritt machen. Hier setzt man am besten auf altbewährte Methoden und verwendet entweder Systeme, die redundant ausgelegt sind, oder man schafft Redundanz durch mehrere Geräte. Zwei Geräte allein schaffen allerdings noch keine Redundanz, es müssen auch Methoden existieren, um zwischen den beiden Systemen umzuschalten, oder im Netzwerk selbst muss eine entsprechende Intelligenz implementiert sein, die dies im Bedarfsfall tut. Der erste Fall, nämlich entsprechend ausgelegte Systeme mit passiver Backplane und doppelter Auslegung aller Module und Stromversorgungen, ist in aller Regel eine sehr teure Angelegenheit und hat obendrein noch ein immanentes Problem: Dadurch, dass alles in einem Chassis konzentriert ist, kann ein massiver physischer Schaden trotzdem das komplette System lahm legen. Die zweite Lösung, zwei identische Systeme einzusetzen und diese am besten räumlich getrennt zu betreiben – vielleicht noch mit zwei verschiedenen Zuleitungen zu unterschiedlichen POPs, ist eine andere, meist günstigere
343
10 VPN-Design
Lösung. Hierfür gibt es auch einige standardisierte Verfahren, die zwei Geräte zu einem redundanten System vereinigen können. Das VRRP (Virtual Router Redundancy Protocol) zum Beispiel wäre solch ein Verfahren. Hierbei ist ein System der VRRP-Master, und sobald dieser ausfällt, übernimmt das zweite Gerät dessen Funktion und auch dessen Netzwerkadressen. Eine andere Art von Backup bzw. Redundanz ist beim Remote-Access-VPN nötig, da hier noch andere Netze (ISDN, Internet) zwischengeschaltet sind und solche Lösungen (wie VRRP) hier nicht zum Einsatz kommen können. Hier muss zwischen dem IPSec-Client und dem VPN-Gateway ein spezielles Protokoll den Zustand der Verbindung überwachen. Dies ist notwendig, da IPSec ein verbindungsloses Protokoll ist. Da zwischen dem Client und dem Gateway viele Vermittlungssysteme liegen können, können weder der Client noch das Gateway erkennen, dass irgendwo dazwischen ein Knoten ausgefallen ist – außer sie versuchen gerade, Daten zu übertragen. Durch dieses spezielle Protokoll, das ständig so genannte Keep-Alive-Pakete überträgt, kann eine Seite erkennen, dass die Gegenstelle nicht mehr erreichbar ist, auch wenn gerade keine Nutzdaten übertragen werden.
10.9.6
Durchsatz und Quality-of-Service
Bandbreite und Leistung Die VPN-Gateways müssen an die benötigte oder zu erwartende Last angepasst sein. Insbesondere im Fall von IPSec und starker Verschlüsselung benötigt man schon einiges an Systemleistung. Als Faustregel kann man sagen, dass der Systemdurchsatz mindestens so groß sein muss wie die Zugangsleitungen. Wenn also eine Anbindung mit einer E3-Schnittstelle zu einem ISP erfolgt und dieser Durchsatz auch vertraglich garantiert wurde, dann sollte dieses IPSec-Gateway mindestens einen Durchsatz von 34 Mbit/s haben – und das vor allem bei der maximal benötigten Anzahl von Tunneln, mit Triple-DES, SHA1 und IPSec Compression. Falls Sie sich nicht im Klaren darüber sind, wie sehr das VPN im Laufe der Zeit wachsen wird, können Sie auch Systeme einsetzen, die mit weiteren Schnittstellenkarten und Hardwarebeschleunigern aufrüstbar sind. Bandbreitenmanagement Das Bandbreitenmanagement ist eine Methode, um bestimmten virtuellen Verbindungen innerhalb einer physikalischen Verbindung bestimmte Bandbreiten zuzuteilen, beziehungsweise diese zu begrenzen. Damit soll verhindert werden, dass bestimmte Verbindungen anderen Verbindungen benötigte Bandbreite wegnehmen.
344
Die Realisierung
Gutes Bandbreitenmanagement erlaubt die Zuteilung von maximalen Bandbreiten und so genannten Burst Rates, die festlegen, um wie viel dieser Wert überschritten werden darf, wenn die gewünschte Bandbreite zur Verfügung steht. Das Ziel des Ganzen ist es, auf der einen Seite bestimmten Tunneln eine Mindestbandbreite zu garantieren, aber auf der anderen Seite auch möglichst alle verfügbare Bandbreite auszunutzen. Lastverteilung Eine andere Möglichkeit ist die, dass man sich für VPN-Gateways entscheidet, die ein so genanntes Loadbalancing, also eine Lastverteilung zwischen den Systemen, unterstützen. Damit kann man, falls erforderlich, die Systemleistung durch zusätzliche Geräte erhöhen und kommt auch gleichzeitig in den Genuss einer gewissen Redundanz. Admission Control Speziell in Remote-Access-VPNs, die man ja sehr oft überbucht, sollte man Prioritäten für bestimmte Benutzerklassen vergeben können, die festlegen, mit welchem Vorrang sich ein Benutzer am VPN-Konzentrator anmelden darf. Analog zur QoS hinsichtlich der Weiterleitung von Paketen hat man hier ein Merkmal, mit welcher Priorität Anmeldeversuche erfolgen und welche Ressourcen das VPN-System für die verschiedenen Prioritätsklassen bereit stellt. Im Idealfall kann man sogar der höchsten Prioritätsklasse unter gewissen Umständen einen Zugang garantieren. Flussbasierende Qualität (RSVP) In Kapitel 3 wurden bereits die verschiedenen Arten von Quality-of-Service (QoS) angesprochen, so dass wir uns hier auf ihren praktischen Einsatz konzentrieren können. Eine flussbasierende Ende-zu-Ende-Qualität mit RSVP wird meist nicht von Internet-Routern unterstützt, so dass zwischen den beteiligten Systemen Strecken existieren können, die eine Weiterleitung der Pakete nach dem Best-Effort-Prinzip vornehmen. Nichtsdestotrotz bieten manche Hersteller RSVP an, um mindestens im VPNGateway selbst eine entsprechende Priorisierung vorzunehmen. Damit kann man eventuell knappe Bandbeiten differenzierter bestimmten Benutzerklassen zuteilen. Wichtiger ist jedoch der Fokus auf klassenbasierende Qualität. Klassenbasierende Qualität (DiffServ) Differentiated Services (DiffServ) hat sich als Standard für QoS im Internet bzw. an dessen Grenze, also am Schnittpunkt zwischen Provider und Kunde, weitgehend durchgesetzt. Auch im Intranet ist es das QoS-Protokoll der Wahl,
345
10 VPN-Design
und viele LAN-Switches unterstützen bereits DiffServ. Es bietet sich daher an, die eigene QoS-Strategie über die Grenzen der eigenen Intranets hinaus bis in das Internet zu erweitern. Allerdings ist im Fall von IPSec eine Sache zu beachten, und zwar bevor man sich ein VPN-Gateway beschafft: Denn hier muss das VPN-Gateway als DiffServ-Edge-Router die IP-Pakete entsprechend der QoS-Policy markieren, falls das nicht bereits an anderer Stelle im Netzwerk erfolgt ist. Denn nach dem Tunneling und der Verschlüsselung der Daten kann der DiffServ-Edge-Router keine Markierungen mehr aufgrund von Protokoll- oder Portnummern des Originalpakets setzen, da es verschlüsselt ist. Das einzige, was der Provider erkennen kann, ist das DS-Byte im äußeren IP-Header. Und in dieses Byte wurde vor der Verschlüsselung des Originalpakets dessen DS-Byte kopiert.
10.9.7
Sicherheitsstrategie und Firewalls
Sie werden im Folgenden öfter den Ausdruck »dediziertes« oder »echtes« VPN-Gateway lesen. Damit soll ausgedrückt werden, dass ein solches System (vgl. Abbildung 10.7) speziell für den VPN-Einsatz entwickelt wurde und einige wichtige Eigenschaften besitzt: 왘 Es kann keine IP-Pakete, auch nicht gefiltert, zwischen seinem öffentlichen
Interface (Internet) und seinem privaten Interface (Intranet) übertragen. Dieser Zustand kann auch nicht durch Systemeinstellungen geändert werden. 왘 Sein öffentliches Interface ist ein spezieller IP-Stack, der nur Pakete der zu
verarbeitenden Tunneling- oder Security-Protokolle verarbeitet. Diese Eigenschaften sind essenziell, wenn man ein VPN ohne weitere komplexe und damit fehleranfällige Maßnahmen wirklich sicher machen will. Ein dediziertes VPN-Gateway kann somit weder als Router noch als Firewall benutzt werden. Andere, also gewissermaßen »unechte« Arten von VPN-Gateways sind zum Beispiel Router, die durch ein Softwaremodul eine IPSec-Zusatzfunktionalität bekommen haben. Auf diesen Systemen kann über ein öffentliches Interface sowohl normaler Datenverkehr mit allen denkbaren Protokollen als auch IPSec übertragen werden. Ohne weitere spezielle Sicherheitsmaßnahmen auf dem öffentlichen Interface ist solch ein System natürlich eine Sicherheitslücke erster Klasse. Dass normale Paketfilter keinen Schutz vor ernsten Hackerangriffen bieten, ist ja hinlänglich bekannt. Wenn nicht im Router selbst, so muss zumindest zwischen ihm und dem Intranet eine Firewall arbeiten, aber der Router ist dann völlig ungeschützt. Also hat man hier insgesamt einen erheblichen Aufwand zu betreiben und hat trotzdem nicht den Schutz, den ein echtes VPN-Gateway bieten kann.
346
Die Realisierung
VPNGateway Internet
Öffentliches Interface
Privates Interface
Intranet
VPN-Gateway Gehärteter IP-Stack (IPSec) Pass: Protokoll 50/na Protokoll 51/na Protokoll 17/500
Krypto-Modul (IPSec, DES, 3-DES, SHA1, …)
UniversalIP-Stack + Paketfilter
Tunnel-Encapsulation Tunnel-Decapsulation
Bandwidth Management und QoS (DiffServ)
Abbildung 10.7: Ein dediziertes VPN-Gateway
Die Einführung eines VPNs mit seinen VPN-Gateways scheint oft in einem Konflikt zur aktuellen Sicherheitspolitik zu stehen oder einen direkten Einfluss auf den Einsatz oder die Funktion von Firewalls zu haben. Aber das stimmt nicht, hier trügt der Schein. Ein VPN hat grundsätzlich, wenn es als Remote-Access-VPN und/oder Branch-Office-VPN eingesetzt wird, absolut keinen Einfluss auf irgendetwas, das die Firewall eines Unternehmens betrifft. Denn hier wird lediglich eine »alte« Technologie bei gleicher Funktionalität durch eine neue ersetzt – es ändert sich bei guter Migration nichts Sicherheitsrelevantes. Wenn beispielsweise ein Frame-Relay-VPN durch ein IP-VPN ersetzt wird und die neue Technologie, z.B. durch IPSec, eine höhere Sicherheit als vorher garantiert, dann ergibt sich daraus kein Einfluss auf eine Firewall, und man geht weiterhin mit der Sicherheitsstrategie konform. Auch die Theorie, mit einem VPN würde man einen Internetzugang schaffen, ist unsinnig, es sei denn, man setzt die falschen Systeme dafür ein – zum Beispiel eine Firewall. Dann trifft dieser Satz tatsächlich zu. Falls man einen Standardrouter mit IPSec aufrüstet und als IPSec-Security-Gateway missbraucht, trifft dies auch zu. Echte, dedizierte IPSec-Security-Gateways ermöglichen kein direktes Forwarding von IP-Paketen vom Internet ins Intranet – auch nicht durch falsche Konfiguration! Eine Firewall und ein Router tun dies schon, das sollte man sich immer vor Augen halten.
347
10 VPN-Design
Intranet
VPNGateway
Internet
VPNGateway
Intranet
Firewall
Internet
Intranet
Abbildung 10.8: Der kleine Unterschied: Ein VPN-Gateway verbindet private Netze miteinander, eine Firewall verbindet private Netze mit dem Internet.
An dieser Stelle ist ein wichtiger Sicherheitstipp angebracht: Es gibt VPN-Gateways mit speziellen »gehärteten«, sicheren IP-Stacks, auf denen man als Option Firewallsoftware installieren kann, um diese damit gleichzeitig als Firewall nutzen zu können. Allerdings booten diese Systeme anschließend mit neuen Standard-IP-Stacks, und die ganze schöne Sicherheit des Stacks ist dahin und auf eine höhere Ebene, die der Firewall, verlagert. Außerdem haben solche Systeme ohnehin nicht den vollen Funktionsumfang guter Firewalls. Meist reduziert er sich auf zustandsabhängiges Filtern von IP-Paketen (Stateful Packet Inspection). Wichtige Funktionen wie Application Level Gateways fehlen meist. Deshalb kann ich Ihnen nur dringend ans Herz legen, eine Firewall nicht mit einem VPN-Gateway in einem System zu kombinieren. Eine Firewall und ein VPN-Gateway sind zwei völlig unterschiedliche Systeme mit völlig gegensätzlichen Aufgaben. Eine Firewall steuert und kontrolliert den Verkehr zwischen Internet und Intranet. Ein echtes dediziertes VPN-Gateway erlaubt nur den Datenverkehr zwischen den Netzen des Intranets – es gibt keine Verbindung in das Intranet. Deshalb sollten Firewall und VPN immer getrennt werden. Auch wenn es auf den ersten Blick die teurere Lösung zu sein scheint, es ist garantiert die bessere und sicherere Lösung. Wie kombiniert man aber nun ein dediziertes VPN-Gateway mit einer Firewall? Da gibt es verschiedene Ansätze, von denen aber nur einer richtig Sinn macht. Diesen Ansatz sehen Sie in dem Beispiel in Abbildung 10.9. Das VPNGateway ist hier praktisch parallel zur Firewall geschaltet. Damit gibt es vor allem keine Performanceprobleme. Sicherheitstechnisch sieht die Sache zwar auf den ersten Blick nach einer Umgehung der Firewall aus, sie ist aber keine
348
Die Realisierung
Umgehung. Denn das VPN-Gateway kommuniziert ausschließlich über Tunneling-Protokolle, im Fall eines Internet-VPN praktisch ausschließlich über IPSec, mit anderen VPN-Gateways des Unternehmens oder mit VPN-Clients von Mitarbeitern des Unternehmens. Verbindungen in das Internet sind unmöglich. Also liegt vom Standpunkt der Sicherheit auch keine Umgehung der Firewall vor. VPNGateway
ISP-AccessRouter
Internet
Öffentliche Server
Firewall
Intranet
DMZ, Demilitarized Zone
Abbildung 10.9: Die sinnvolle Kombination von VPN-Gateway und Firewall
Die Idee, eine Firewall vor ein IPSec-Gateway zu setzen, kann man auch nach kurzem Nachdenken wieder vergessen. Denn eine Firewall soll ja die Pakete prüfen, die in das Intranet gelangen. Diese Pakte sind aber in einem anderen IP-Paket eingekapselt und verschlüsselt, die Firewall kann weder den Inhalt, die Port- oder Protokollnummer noch die IP-Adressen erkennen. Sie kann einfach nur IPSec-Pakete von und zum Gateway transportieren, ohne eine Prüfung vorzunehmen. Sicherheitstechnisch bringt dies also gar nichts, aber dafür muss der ganze VPN-Verkehr über die Firewall transportiert werden, und diese droht damit zu einem Engpass zu werden. Falls jedoch die Firewall unbedingt vor ein VPN-Gateway gesetzt werden muss, dann muss je nach Tunneling-Protokoll eine Reihe von Ports und Protokollen, die Sie in Tabelle 10.7 aufgelistet sehen, auf der Firewall freigegeben werden. Was überhaupt nicht funktioniert, ist, eine normale Firewall hinter ein echtes VPN-Gateway zu setzen. Denn die Firewall soll ja gerade bestimmten Verkehr wie HTTP, FTP usw. filtern und durchlassen. Allerdings werden alle Pakete solcher Applikationen bedingungslos von einem dedizierten VPN-Gateway im öffentlichen Interface verworfen und gelangen niemals bis zur Firewall. Und »normale« Webserver oder FTP-Sites arbeiten nicht mit IPSec oder anderen Tunneling-Protokollen.
349
10 VPN-Design
Protokoll
Protokoll
Source-Port
Destination-Port
IPSec ESP
50 (ESP)
Nicht benutzt
Nicht benutzt
IPSec AH
51 (AH)
Nicht benutzt
Nicht benutzt
IKE
17 (UDP)
500
500
PPTP Control Connection
6 (TCP)
> 1023
1723
PPTP Data Encapsulation
47 (GRE)
Nicht benutzt
Nicht benutzt
L2TP
17 (UDP)
> 1023
1701
L2F
17 (UDP)
> 1023
1701
Tab. 10.7: Eine Übersicht, welche Protokoll- und Portnummern freizugeben sind, wenn sich eine Firewall vor dem VPN-Gateway befindet
Eine Ausnahme, die Sie in Abbildung 10.10 sehen, ist ein möglicher Einsatz von VPN-Technologie für Extranets. Der Grundansatz eines VPN ist es ja, ein privates Netz zu haben, das lediglich öffentliche Netze als Transportmedium benutzt. Somit müssen in VPN-Gateways genau so wenige oder so viele Zugriffsbeschränkungen auf Benutzerebene existieren wie in normalen Routern oder Remote-Access-Konzentratoren. Die ganze Sicherheitstechnologie in VPN-Systemen dient ausschließlich zur Sicherung der virtuellen Verbindung und gegenseitigen Authentifizierung. VPNGateway Eigene Mitarbeiter
Extranet-Benutzer
ISP-AccessRouter
Internet
Öffentliche Server
Firewall
Intranet
DMZ, Demilitarized Zone
Abbildung 10.10: Im Extranet greifen externe Benutzer des VPN über eine nachfolgende Firewall kontrolliert auf das Intranet zu.
Soll das Ganze auch auf ein Extranet erweitert werden, so ist damit das private Netz auch anderen Personen oder Organisationen zugänglich. Für diese gelten natürlich völlig andere Kriterien als für die eigenen Mitarbeiter. Eine
350
Die Realisierung
brauchbare Lösung für dieses System ist die Kombination der Funktionen eines VPN-Gateways mit einer in den meisten Unternehmen ohnehin vorhandenen Firewall. In dem Beispiel in Abbildung 10.10 greifen die externen Benutzer ebenfalls über sichere IPSec-Tunnel auf das VPN-Gateway zu. Die entkapselten und entschlüsselten IP-Pakete werden jedoch nicht direkt in das Intranet geleitet, sondern zuerst zur Firewall geführt und dort entsprechend den Sicherheitsrichtlinien verarbeitet. Nur die eigenen Mitarbeiter werden direkt mit dem Intranet verbunden. Somit erfolgt auch hier eine konsequente Umsetzung der beiden verschiedenen Zielrichtungen von VPN und Firewall, indem man die VPN-Technologie zum sicheren Transport privater Daten durch öffentliche Netze einsetzt und die Firewall benutzt, um den Verkehr von und zu potenziell unsicheren Gegenstellen zu steuern und zu kontrollieren.
10.9.8
Authentifizierungsverfahren
Bei den Authentifizierungsverfahren muss zwischen der gegenseitigen Authentifizierung zweier Endsysteme (z.B. VPN-Gateways) und der Authentifizierung von Benutzern an einem Zugangskontrollsystem unterschieden werden, obwohl dies manchmal in einem Gerät oder sogar funktionell miteinander kombiniert wird. In Internet-VPNs sind beide Verfahren wichtig, um das VPN-System selbst zu schützen und um im Weiteren ein unerlaubtes Eindringen in das Unternehmensnetz zu verhindern. Benutzer-Authentifizierung Bei der Benutzer-Authentifizierung ist die Sicherheitsstrategie des Unternehmens gefragt, die für den Fernzugriff auf das Unternehmensnetz bestimmte Richtlinien festlegt. Es sollten mindestens die gleichen Verfahren wie im bisherigen Remote Access eingesetzt werden können. Falls dort jedoch eine einfache Passwort-Authentifizierung erfolgt, sollte man überlegen, gleich oder später eventuell stärkere Verfahren einzusetzen, oder zumindest darauf vorbereitet sein. Stärkere Verfahren (vgl. Kapitel 5) sind solche, die zwei oder mehr Verfahren miteinander kombinieren. Beim Remote Access haben sich Token-Karten bisher einer großen Beliebtheit als Werkzeug zur starken Authentifizierung erfreut. Diese sollte man auch im VPN weiter benutzen können. Neuere Authentifizierungsverfahren, die auf digitalen Zertifikaten beruhen, werden oft pauschal als starke Authentifizierung bezeichnet. Das sind sie aber nur, wenn sie auch korrekt eingesetzt werden. Im Fall von digitalen Zertifikaten bedeutet dies, dass der private Signaturschlüssel eines Anwenders nicht auf einem Rechner gespeichert sein darf, sondern nur auf einem externen Medium, das der Benutzer in seine persönliche Verwahrung nehmen
351
10 VPN-Design
kann. Ein solches Medium sind zum Beispiel Chipkarten oder in möglichst zu vermeidenden Ausnahmefällen auch Speicherkarten oder Disketten. System-Authentifizierung IP Security schreibt zwingend nur ein einziges Authentifizierungsverfahren vor: Die Authentifizierung mit einem Pre-Shared Secret. Jedoch sollten auch weitere Verfahren, insbesondere digitale Signaturen unterstützt werden. Allerdings kann man mit guten Pre-Shared Secrets auch einen wirkungsvollen Schutz gegen Wörterbuchangriffe erreichen. Denn bei der Authentifizierung von IPSec-Systemen untereinander ist kein Anwender involviert, der Schwierigkeiten hätte, sich eine hexadezimale Zeichenkette wie etwa »0x02f6ad32ff027ea53b« zu merken. Die meisten vernünftigen IPSec-Gateways erlauben daher die Eingabe sehr langer hexadezimaler Zeichenketten, so dass ein Rateangriff darauf leicht die Komplexität eines Angriffs auf einen 128-Bit-Schlüssel erreichen kann. Wenn ein VPN-Gateway in einer sicheren Umgebung betrieben wird und das Management ebenfalls sicher (verschlüsselt und stark authentifiziert) erfolgt, dann kann ein solches Pre-Shared Secret auch durchaus mehrere Quartale oder sogar Jahre gleich bleiben. Gute IPSec-Systeme erlauben auch noch eine oder mehrere andere Arten der Authentifizierung, die auf Public-Key-Verfahren beruhen, zum Beispiel digitale Signaturen. Hierbei werden für die beteiligten VPN-Gateways von der Certificate Authority (CA) digitale Zertifikate ausgestellt.
10.9.9
Die Auswahl von Service Providern
Das, was viele befürchtet hatten, ist eingetreten: Es gibt Internet Service Provider, die ihren Kunden den Betrieb eines VPN verwehren. Dies tun sie ganz einfach, indem zum Beispiel UPD-Pakete mit der Portnummer 500 blockiert werden, wodurch kein IKE-Protokoll laufen kann. Wenn man die rechtlichen Implikationen durch bestehende Verträge und die Geisteshaltung solcher Provider (manche reden schon von einer regelrechten Zensur, man dürfe nur noch das übertragen, was dem ISP passt) einmal beiseite lässt, ergeben sich hieraus zwei wichtige Punkte, die Sie beachten sollten, wenn Sie einen Provider auswählen und einen entsprechenden Vertrag abschließen: 1. Der Provider muss sich vertraglich festlegen, keine Pakete zu filtern. Da gibt es kein Wenn und kein Aber. 2. Er muss Ihnen garantieren, dass die Pakete ausschließlich in seinem Netz oder anderen Netzen ebenfalls ohne Filterung transportiert werden. Die weiteren Kriterien sind recht unterschiedlich zu bewerten, da gibt es kein allgemein gültiges Rezept. Sie müssen aber die folgenden Punkte klären, um einen Provider zu bewerten:
352
Die Realisierung
왘 Die Größe des Providers 왘 Die Kosten für das VPN, die an den ISP zu entrichten sind 왘 Betreibt der Provider einen eigenen Internet-Backbone? 왘 Welche Übergangspunkte betreibt er national und international? 왘 Mit welchen Providern kooperiert er? 왘 Ist eine weltweite Einwahl möglich? 왘 Betreibt er auch Sprach- oder Mobilnetze? 왘 Wie sehen seine bisherigen Werte (Verfügbarkeit, Bandbreiten usw.) aus?
10.9.10 Service Level Agreements Leider gibt es auch für die Service Level Agreements (SLA) keine allgemein gültigen Vorlagen oder Vorgaben. Diese hängen auch von dem Provider ab. Je nach eingesetzter Technologie, Größe, eigenen Sprach- und Datennetzen können die unterschiedlichsten Leistungen angeboten werden. Ein Provider, der kein eigenes Netz betreibt, hat Probleme, solche Verträge abzuschließen, die Vereinbarungen enthalten, deren Einhaltung einen Zugriff auf das Netzwerk erfordert. Es gibt eine ganze Reihe von Punkten, die in ein SLA einfließen können. Nicht alle passen in jedes Netzkonzept, und es gibt auch mit Sicherheit ein paar Details, die in der folgenden Aufstellung noch fehlen mögen. Verfügbarkeit Bei den Verfügbarkeitswerten wird üblicherweise noch etwas weiter differenziert. Dies spiegelt auch etwas die Art und Qualität der beim Provider eingesetzten Systeme wider. In Backbones werden oft optische Systeme eingesetzt oder digitale Telefonnetze mitbenutzt, die eine extrem hohe Verfügbarkeit aufweisen. Im Access-Bereich hingegen stehen bei den Kunden oft kostengünstige Router als Übergabepunkte zur Verfügung, denen man bereits ansieht, dass sie vermutlich keine Verfügbarkeit von 99,999% garantieren können. Backbone-Verfügbarkeit Hier warten die Service Provider mit den höchsten
Werten auf. Sie bewegen sich dabei im Bereich von 99,7% bis 99,9%. Aus dem Vertrag sollte hervorgehen, was der Provider unter dem Begriff Backbone versteht und welche Ausdehnung der Backbone hat. Einwählverfügbarkeit Hiermit wird die Verfügbarkeit des Einwähldienstes
beschrieben. Sie sollten in jedem Fall klären, ob ein Besetzt-Fall als nicht verfügbar im Sinne des Vertrags anzusehen ist. Ein Besetzt-Fall liegt zum Beispiel
353
10 VPN-Design
dann vor, wenn alle Einwahl-Ports des Providers belegt sind und das Telefonnetz einen besetzten Anschluss signalisiert. Ende-zu-Ende-Verfügbarkeit Das ist die Verfügbarkeit, die in einem Branch-
Office-VPN wirklich zählt. Anzustreben sind auch hier Werte im Bereich von 99,5% und mehr. Dieser Wert scheint auf den ersten Blick hoch zu sein. Hier hilft vielleicht die folgende kleine Rechnung, um diesen Wert ins rechte Licht zu rücken: Ein Jahr hat 365 x 24 = 8760 Stunden. Eine Verfügbarkeit von 99,5% bedeutet, dass an maximal 43,5 Stunden im Jahr die Verbindung nicht zur Verfügung steht. Statistisch gesehen verteilt sich das auf etwa 250 Arbeitstage, so dass sich maximal 29,5 Stunden Ausfall auf die Arbeitstage verteilen. Das kann unter Umständen schon zu viel sein, insbesondere dann, wenn auch nachts Datenverbindungen für irgendwelche Hintergrundverarbeitungen oder Zugriffe aus anderen Zeitzonen erfolgen. Allerdings bedeutet eine Verfügbarkeit von 99,5% nicht, dass das Netz tatsächlich 43,5 Stunden pro Jahr ausfällt, es ist nur ein maximal zulässiger Wert. Oft ist die tatsächliche Verfügbarkeit höher. Maximale Paketverzögerung zwischen Übergabepunkten Dieser Wert kann für bestimmte Applikationen sehr kritisch sein. Insbesondere interaktive Sprache und Video sind da sehr empfindlich, jedoch auch ältere Online-Applikationen oder Netzwerkapplikationen, die offensichtlich nur für LANs entwickelt wurden. Anzustrebende Werte für Sprache und Video sollten unter 100 ms liegen. Insbesondere wenn ein VPN bei einem einzigen Provider betrieben wird, sind solche Werte auch möglich. Bandbreiten Hier wird festgelegt, mit welchen garantierten Bandbreiten der Zugriff auf das Netz des Providers möglich ist. Die Werte liegen maximal bei der Geschwindigkeit der Zugangsverbindung und werden manchmal tatsächlich auch von Providern garantiert. Maximale Fehlerrate Die Höhe des Verhältnisses zwischen korrekt übertragenen und fehlerhaften oder fehlenden IP-Paketen sollte auch festgelegt werden. Ursachen für Paketverluste sind meist Überlastsituationen, in denen ATM- und Frame-RelayNetze anfangen, Pakete zu verwerfen. Das Verhältnis sollte hier wenigstens 99,98% betragen. Mittlere und garantierte Reparaturzeiten Ein Tipp vorweg: Lassen Sie sich nicht auf so genannte »Reaktionszeiten« in einem SLA ein. Es sei denn, der Begriff Reaktion ist im Vertrag genau definiert und bedeutet Reparatur. Denn eine Reaktionszeit von drei Stunden bedeutet
354
Die Realisierung
im für den Kunden schlimmsten Fall, dass er ein Problem meldet und dass drei Stunden später jemand reagiert, indem er zurückruft und fragt, was los ist. Was genau festgelegt werden muss, ist die Zeit, die maximal zwischen Problemmeldung und Problembehebung vergehen darf. Die Zeit richtet sich nach den Anforderungen des Kunden, oft werden vier Stunden vereinbart, ein Wert, mit dem beide Seiten leben können. Mittlere und garantierte Installationszeiten »Ein Netzwerk ist niemals fertig.« Ein VPN auch nicht. Es werden laufend neue Standorte angebunden, zusätzliche Kunden und Partner in Extranets aufgenommen und neue Remote-Access-Benutzer angelegt. Es muss daher vertraglich festgelegt werden, wie lange solche Prozesse maximal dauern dürfen. Die Zeiten richten sich nach verschiedenen Faktoren, wobei sehr kurze Zeiten für Hardware-Installationen bedingen, dass der ISP die Geräte vorhalten muss, wodurch das SLA sehr teuer werden kann. Realistische Werte sind ein bis zwei Monate von der Bestellung bis zur Bereitstellung. Das Anlegen eines Remote-Access-Kontos sollte bei einem ISP maximal einen Tag dauern dürfen. QoS-Klassen und Behandlung der Pakete Falls der Service Provider Quality-of-Service auf IP-Ebene unterstützt, muss man vereinbaren, welche Arten von IP-Paketen in welche Qualitätsklassen des Service Providers gehören. Am einfachsten ist es, wenn die Klassifizierung bereits im Netz des Kunden erfolgt und der ISP nur noch das DS-Byte der IP-Pakete auswerten und umsetzen muss. Dies ist beim Einsatz von IPSec auch gleichzeitig die einzige Möglichkeit. Keine Paketblockierung Legen Sie fest, dass der Provider keine Datenpakete blockieren darf. Am sichersten sind Sie, wenn die Vereinbarung dahin gehend lautet, dass überhaupt keine Filterung stattfindet. Vertragsstrafen bei Nichteinhaltung Das ist der kitzlige Punkt schlechthin. Hier müssen zwei Dinge festgelegt werden: 1. Wann liegt überhaupt eine Nichterfüllung des SLA in welchem Umfang vor? 2. Wie hoch sind die Vertragsstrafen für die jeweiligen Vertragspunkte? Der erste Punkt scheint eigentlich klar zu sein, jedoch gibt es bei genauem Hinsehen eigentlich nur Probleme. Denn die Frage ist, welche Messverfahren von wem eingesetzt werden, wie zuverlässig und aussagekräftig diese sind und ob sie von beiden Seiten anerkannt werden.
355
10 VPN-Design
Der einzige Weg, der Erfolg verspricht, besteht darin, die komplette Messtechnik für alle im SLA spezifizierten Punkte genauestens im Service Level Agreement festzulegen. Zusätzliche Dienste Einige Provider bieten zusätzliche Dienste an, die die Qualität des Internetzugriffs und die Sicherheit beeinflussen können. Dial-In QoS Manche ISPs betreiben bereits Systeme, mit denen Datenpakete im POP (oder einem virtuellen POP) aufgrund der User-ID und der eingesetzten Applikationen für QoS (DiffServ) markiert werden können. Diese Dienste können ebenfalls in einem SLA festgelegt werden. Dial-In Firewall Es ist mit der obigen Technik auch möglich, Benutzerkonten
so zu konfigurieren, dass bestimmte Dienste oder Inhalte, die vom Kunden spezifiziert werden können, in den Datenpaketen herausgefiltert werden. Dial-In Compulsory Tunneling Tunneling-Protokolle wie IPSec sind Vertreter des »freiwilligen Tunneling«. Ein Anwender könnte zum Beispiel seinen IPSec-Client gar nicht benutzen und sein Firmen-Internetkonto bei einem Service Provider benutzen, um per Einwahl über den POP des Providers in das Internet zu gehen. Der Service-Provider kann dem Kunden aber garantieren, dass der Benutzer, sobald er sich in den POP des ISP einwählt, zwangsweise zum Kundennetzwerk getunnelt wird.
10.10 Beispiele 10.10.1 Remote-Access-VPN In Abbildung 10.11 bis Abbildung 10.13 sehen Sie einen stufenweisen Umstieg von einem reinen Remote Access zu einem Remote-Access-VPN. Es wurde dabei eine Netzwerkumgebung aus der echten Welt zugrunde gelegt. Der Remote-Access-Konzentrator kann digitale und analoge Rufe terminieren. Folgende Einwahltechnologien sind mit heute üblichen Standard-RemoteAccess-Konzentratoren möglich: 왘 Analoge Modemeinwahl mit allen üblichen Protokollen bis 56 Kbit/s 왘 Synchrones ISDN 왘 Asynchrones ISDN mit V.120-Protokoll 왘 GSM über analoge Modememulation
356
Beispiele
왘 GSM über ISDN mit V.110-Protokoll 왘 X.75 wird gelegentlich noch angeboten, aber praktisch nicht mehr einge-
setzt. Nicht unterstützt werden so genannte High-Speed-Zugänge per DSL oder Modems für Fernsehbreitbandkabel. RADIUSServer
Homeoffice
Homeoffice ISDN
Zentrale
ISDN
RemoteAccessKonzentrator
Router
ISDN PSTN 8 x S2M
Public Server (www, ftp)
Firewall
DHCP-Server
DMZ NetzwerkManagement
Internet 3 x 2 Mbit/s
Router
Abbildung 10.11: Der Remote Access soll durch VPN-Technologie realisiert werden.
In der Übergangsphase (siehe Abbildung 10.12) werden beide Welten, der Remote Access und das Remote-Access-VPN, parallel betrieben. Die Benutzer installieren nach und nach den IPSec-Client auf ihren Rechnern. Gleichzeitig werden vom Unternehmen bei einem oder mehreren ISPs Benutzerkonten für die User angemeldet. Der Remote-Access-Konzentrator benutzt RADIUS zur Benutzer-Authentifizierung und bezieht seine IP-Adressen, die er den Clients über PPP zuweist, aus einem DHCP-Server. Der VPN-Konzentrator wurde so ausgesucht, dass er die gleichen Verfahren einsetzen kann, dass also kein zusätzlicher Managementaufwand nötig ist und die Benutzer ihre User-ID und Passwörter sowohl für den Remote Access als auch für das VPN einsetzen können.
357
10 VPN-Design
RADIUSServer
Homeoffice
Homeoffice ISDN
Zentrale
ISDN Router
RemoteAccessKonzentrator
ISDN PSTN
4 x S2M VPNKonzentrator Public Server (www, ftp)
Firewall
DMZ
NetzwerkManagement
Internet 34 Mbit/s
DHCP-Server
Router
Abbildung 10.12: In der Übergangsphase werden beide Technologien parallel eingesetzt.
Homeoffice
Homeoffice
ISDN
RADIUSServer
VPNRouter
VPNRouter
ISDN
Router VPNClient
DSL
VPNKonzentrator
VPNClient
Internet
Public Server (www, ftp)
Firewall
VPNClient
DHCP-Server
DMZ
VPNClient
NetzwerkManagement 34 Mbit/s
Router
Abbildung 10.13: Das Remote-Access-VPN
358
Beispiele
In der letzten Phase (siehe Abbildung 10.13) wird der alte Remote-AccessDienst eingestellt und nur noch das VPN benutzt. Zusätzlich können die Anwender auch neue Zugangstechnologien einsetzen, falls die Provider diese anbieten. Insbesondere DSL ermöglicht um ein Vielfaches höhere Datenraten. In manchen Regionen wird auch der Internetzugang über das TV-Kabel mit speziellen Modems angeboten. Auch hierbei sind wesentlich höhere Geschwindigkeiten als mit ISDN möglich.
10.10.2 Branch-Office-VPN Die Umstellung auf ein Branch-Office-VPN fällt noch einfacher aus, da hier keine Umstellungen für die Benutzer notwendig werden. Hier können während eines Wartungsfensters die Systeme schrittweise ausgetauscht werden. In Abbildung 10.14 wird ein Routernetzwerk, das drei Standorte miteinander über Standardfestverbindungen verbindet, durch ein IP-VPN ersetzt. Router-3 Netz C Router-1
Standardfestverbindung
Netz A Standardfestverbindung
Router-2 Netz B
Router-3 Netz C
Internet Router-1 Netz A Tunnel
VPN-Gateway GW-2 Netz B
VPN-Gateway GW-1
VPN-Gateway GW-3
Internet
Netz C
Tunnel
Netz A
Tunnel VPN-Gateway GW-1
VPN-Gateway GW-2
Netz B
Abbildung 10.14: Der schrittweise Aufbau eines Branch-Office-VPN
359
10 VPN-Design
10.10.3 IP-VPN-Service eines ISP Die beiden oben stehenden Beispiele können auch als komplette Dienstleistung von Service Providern zur Verfügung gestellt werden. In den Fallstudien im übernächsten Kapitel finden Sie mehr zu diesem Thema, deshalb ist dieser Teil hier etwas kürzer angelegt. Generell kann man bei den Service Providern zwischen zwei verschiedenen Modellen wählen, die jedoch noch in verschiedene Angebotspakete unterteilt werden können: Internet Access Hier stellt der Provider nur den Zugriff auf das Internet bereit. In der komfortablen Version dieses Angebots installiert und betreibt er auch einen AccessRouter beim Kunden und beschafft und überwacht auch die Zugangsleitungen zu seinem POP. Managed Service Hier geht die Dienstleistung noch einen Schritt weiter: Der ISP betreibt neben dem Internetzugang auch die VPN-Systeme des Kunden. Der Kunde selbst verwaltet nur seine Benutzer- und Gruppenprofile, den Rest macht der Provider.
360
11
Auswahl der VPN-Komponenten
Irgendwann kommt der Punkt, da muss man seine Vorüberlegungen, seine Wünsche und Vorstellungen in einem oder mehreren Produkten wiederfinden. Wie kann man nun an die Auswahl der Komponenten herangehen und alles richtig oder möglichst wenig falsch machen? Ein fertiges Rezept gibt es nicht, da sind die möglichen Rahmenbedingungen zu unterschiedlich, der Markt und die Technologie zu dynamisch. Man kann aber strukturiert an die Sache herangehen, sich über sein Anforderungsprofil im Klaren sein und dann eine Auswahl treffen. Wenn Sie jetzt erwarten, an dieser Stelle die in ähnlichen Büchern oft publizierten Hersteller- und Produktübersichten zu finden, werden Sie vielleicht ein klein wenig enttäuscht sein. Aber dies hat eine Reihe gewichtiger Gründe: 1. In der Zeit, die von der Erstellung des Manuskripts bis zum Erscheinen dieses Buches vergangen ist, haben vermutlich alle Hersteller eine neue Software-Release freigegeben, vielleicht neue Geräte in das Portfolio aufgenommen oder gleich eine neue Firma mit ganz neuen Produkten übernommen. Also wäre die Übersicht überholt. 2. Eine solche Übersicht kann einfach nicht vollständig sein, weder in Hinblick auf die Hersteller noch in Hinblick auf deren Produkte und Leistungsmerkmale. 3. In einer umfangreichen Übersicht kann man nicht alle Angaben der Hersteller überprüfen, sondern muss deren Angaben einfach übernehmen. Und angesichts dessen, was da teilweise behauptet wird, dürfen solche Angaben nicht durch ein Abdrucken in ernsthaften Abhandlungen aufgewertet werden. Es ist viel wichtiger, dass Sie in die Lage versetzt werden, die Angebote und Datenblätter der Hersteller kritisch zu beurteilen und die richtigen Fragen zu stellen. Aus diesem Grund wurde auch in diesem Kapitel nicht vom bisherigen Grundsatz der Herstellerneutralität in diesem Buch abgewichen. Die Erstellung eines Pflichtenhefts ist eine hilfreiche Sache, die man nach seinem VPN-Design, wenn die Struktur, die Mengengerüste, die Performanceanforderungen usw. feststehen, angehen sollte. In dem Pflichtenheft finden sich die Spezifikationen wieder, die die idealen VPN-Systeme aufweisen sollten, am besten nach dem Grad der Wichtigkeit aufgeschlüsselt. Es gibt höchstwahrscheinlich kein Gerät, das alle Kriterien so erfüllt. Sie müssen das oder die Systeme auswählen, die dem am nächsten kommen.
361
11 Auswahl der VPN-Komponenten
11.1 VPN, Feature oder dediziert? Bevor Sie an die Aufstellung eines Pflichtenhefts für die zu beschaffenden VPN-Komponenten gehen, sollten Sie eine grundsätzliche Entscheidung treffen. Setzt man spezielle, dedizierte VPN-Systeme ein, oder rüstet man vorhandenes WAN-Equipment mit VPN-Features aus? Dedizierte VPN-Systeme Dedizierte VPN-Systeme sind Geräte und Software, die ausschließlich zum Betrieb eines VPNs entwickelt wurden. Der Schwerpunkt des Designs liegt bei solchen Produkten im sehr schnellen Verarbeiten von Verschlüsselungsalgorithmen und Tunneling-Protokollen. Um diese Kernfunktionalitäten herum werden dann andere Funktionen wie Management, Quality-of-Service, Routing, Filterung und so weiter gruppiert. Der Vorteil dieses Ansatzes besteht darin, dass die kritischen Funktionen eines VPN mit sehr hoher Performance ausgeführt werden. So finden sich in diesem Segment Geräte wieder, die ohne Hardwarebeschleunigerkarten bei 10.000 gleichzeitigen IPSec-Sicherheitsassoziationen mit starker Triple-DES-Verschlüsselung fast 40 Mbit/s Datendurchsatz erreichen. Als weiterer Pluspunkt sind auch spezielle Implementierungen des Netzwerk-Stacks auf dem öffentlichen Interface möglich. Da ein dediziertes VPNSystem weder als Router noch als Firewall arbeiten muss, besteht auch keine Notwendigkeit, andere Protokolle als zum Beispiel IPSec auf dem öffentlichen Interface eines VPN-Konzentrators zu verarbeiten. Das Resultat ist eine sehr hohe Sicherheit solcher Systeme vor einer Vielzahl von IP-basierenden Angriffen. Access-Systeme mit VPN-Zusatzfunktionen Solche Systeme sind Geräte, deren Kernfunktionalität nicht im Verschlüsseln und Tunneling liegt, also Geräte wie Router, Einwählkonzentratoren oder Firewalls. In solchen Systemen werden die entsprechenden Funktionalitäten nachgerüstet. Das Problem bei diesem Ansatz kann sein, dass das Gerätedesign, sowohl von der Prozessorleistung als auch von der Busarchitektur und der Software her nur eine recht bescheidene Verarbeitungsleistung zulässt. Insbesondere Produkte, die schon vor einigen Jahren entworfen wurden, haben ihre liebe Not mit modernen VPN-Technologien, insbesondere mit starker Verschlüsselung oder Public-Key-Verfahren. Der Grund besteht ganz einfach darin, dass vor fünf Jahren IPSec oder L2TP kein Thema bei der Entwicklung zum Beispiel eines Routers war.
362
Performance
Damit soll keineswegs gesagt werden, dass ein »normaler« Router als VPNGateway ungeeignet ist. Sie dürfen aber auch keine Performancewunder erwarten, vor allem nicht im Vergleich mit reinen VPN-Systemen. Falls aber in bestimmten Fällen eine hohe Performance nicht erforderlich ist und die Geräte schon im Einsatz sind, spricht nichts gegen ihre Verwendung als VPNSystem.
11.2 Performance Je nach Anwendungsgebiet und Applikationen besteht Bedarf an einem bestimmten Datendurchsatz, der, blicken Sie nur einmal auf die letzten fünf Jahre zurück, ständig und stark anwächst. Neue und immer mehr netzwerkzentrierte Anwendungen fordern mehr und mehr Bandbreite und neue Möglichkeiten, verschiedene Dienstklassen mit unterschiedlichen QoS-Parametern zu verarbeiten. Der reine Durchsatz von VPN-Systemen ist ein Schlüsselfaktor, denn wenn er nicht ausreicht, bekommt man Probleme. Selbst die ausgefeilteste Quality-ofService-Technologie kann keine zusätzliche Bandbreite erzeugen, sondern nur die vorhandene verwalten. Worin besteht aber das Problem? In jedem Datenblatt sind doch die Durchsatzwerte angegeben? Das Problem besteht einfach darin, dass meist aus den Datenblättern nicht hervorgeht, um welchen Wert es sich überhaupt handelt! Um eine Angabe über den Datendurchsatz eines VPN-Systems richtig zu interpretieren, müssen Sie eine Reihe von Umständen kennen, die diesen Wert beeinflussen: 왘 Wurde der Wert mit DES, Triple-DES oder vielleicht sogar ohne Verschlüs-
selung ermittelt? 왘 Mit welchen Paketgrößen wurde gemessen? 왘 Wurden Datenmuster verwendet, die sich extrem leicht und schnell kom-
primieren lassen? 왘 Wie viele Tunnel waren gleichzeitig aktiv, und wurde über alle parallel
übertragen? 왘 War der Datenverkehr bidirektional oder unidirektional? 왘 In welcher Konfiguration wurde das Gerät betrieben, also mit welcher
Speichergröße, mit oder ohne Beschleunigerkarten usw.? 왘 Befand sich das System in einem Standardbetriebszustand mit Logging,
Accounting, Filterung usw., oder waren diese Prozesse deaktiviert? Bei geeigneter Auswahl der Testumgebung kann man Messungen in diesem Bereich um Größenordnungen variieren.
363
11 Auswahl der VPN-Komponenten
11.2.1
Eigene Messungen
Eigene Messungen sind entweder praxisfern oder sehr aufwendig, speziell wenn es um größere VPNs geht. Hier benötigt man ein entsprechendes Messinstrumentarium und sehr gute Kenntnisse über die Technik, die man unter die Lupe nehmen will. Einfache Testaufbauten eignen sich nur bedingt. Insbesondere wenn es um hohe Datendurchsätze geht, braucht man leistungsfähige Verkehrsgeneratoren und Software.
11.2.2
Veröffentlichte Testberichte
Veröffentlichte Testberichte muss man in zwei Kategorien unterteilen: solche, die von Herstellern stammen oder von ihnen in Auftrag gegeben wurden, und solche, die von unabhängigen Labors erstellt wurden, die meist im Auftrag von Fachzeitschriften tätig werden. Ein Paradebeispiel für die erste Variante ist der Testbericht eines so genannten unabhängigen Testlabors, in dem vor zwei Jahren zwei VPN-Gateways verschiedener Hersteller miteinander verglichen wurden, eins mit zwei eingebauten Hardwarebeschleunigern und eins ganz ohne. Wer hat da wohl gewonnen, und vom wem wurde dieser Test wohl bezahlt? Tests in Fachzeitschriften sind da schon ernster zu nehmen, allerdings wird dort meist auch nur ein geringer Prozentsatz der am Markt erhältlichen Systeme getestet.
11.2.3
Beurteilungskriterien
Da man nur mit sehr hohem Aufwand eigene Messungen durchführen kann, sind Sie leider letztendlich doch auf Messungen von Herstellern und Fachzeitschriften oder Testlabors angewiesen. Um diese etwas besser beurteilen zu können, werden im Folgenden ein paar Kriterien beschrieben, die einen starken Einfluss auf solche Messungen ausüben. Systemkonfiguration Wurde das System in einem normalen Betriebszustand getestet, oder wurden alle nicht zur jeweiligen Messung benötigten, aber im normalen, produktiven Betrieb aktiven, Prozesse wie Logging, Accounting, Filterung usw. gestoppt? Weiterhin ist es ganz wichtig zu wissen, ob die getesteten Systeme mit Zusatzmodulen zur Beschleunigung von Verschlüsselungsalgorithmen ausgerüstet waren.
364
Performance
Verschlüsselungsalgorithmen Selbstverständlich hat die Art des eingesetzten Verschlüsselungsalgorithmus einen ganz wesentlichen Einfluss auf die Performance. So ist Triple-DES knapp dreifach langsamer als DES mit 56 Bit. Aber Vorsicht, was wirklich zählt, ist nicht der Triple-DES-Durchsatz, sondern die Verarbeitungsgeschwindigkeit der IPSec-Implementierung. Und die ist, als grobe Faustregel, bei IPSec-ESP mit Triple-DES, SHA1 und LZS-Komprimierung etwa um ein Drittel geringer. Ein Testbericht muss ausführlich Auskunft darüber geben, was wirklich gemessen wurde. Eine Aussage wie Datenverschlüsselung bis 100 Mbit sagt überhaupt nichts aus, außer vielleicht über die Informationspolitik des betreffenden Herstellers. Hash-Algorithmen Bei den Hash-Algorithmen sollten Sie wissen, dass SHA1 je nach SoftwareImplementierung um bis zu 50% langsamer als MD5 sein kann. In einigen Hardwarebeschleunigern sind allerdings keine großen Unterschiede mehr vorhanden. Um ein System beurteilen zu können, sollte möglichst zur Messung SHA1 benutzt werden. MD5 ist mit Sicherheit nicht langsamer. CPU-Typ und Taktgeschwindigkeit Es ist klar, dass diese Werte einen direkten Einfluss auf den Systemdurchsatz haben. In einer Messung müssen diese Angaben enthalten sein. Cachegröße und Speicherbus Auch dieser Faktor beeinflusst die Systemperformance: je größer und schneller, desto besser. Auch hier müssen die Angaben im Messprotokoll stehen, damit man auch das zu kaufende Gerät entsprechend ausrüsten kann. Speichergröße Der Speicher ist ein noch wichtigerer Faktor als die CPU und ihre Taktgeschwindigkeit, denn wenn er zu knapp wird, dann wird das System richtig langsam. Es ist deshalb wichtig, dass Sie die Speichergröße während der Messung kennen, allein schon, um das zukünftige System ausreichend dimensionieren zu können. Paket-Overhead Je kleiner die Paketgröße wird, desto größer wird der Paket-Overhead – und damit sinkt unweigerlich die Bandbreite, da das Verhältnis von Nutzdaten zu Overhead immer schlechter wird. Aus diesem Grunde werden die eigenen
365
11 Auswahl der VPN-Komponenten
Systeme gern mit sehr großen Paketen getestet. Gute Messungen verwenden verschiedene Paketgrößen, zum Beispiel 64 Byte, 100 Byte, 300 Byte, 1000 Byte und 1500 Byte, um aussagekräftige Werte zu erhalten. IPSec-Komprimierung Leider messen viele Hersteller gern ohne IPSec-Komprimierung, da sonst ihre schönen Werte dahin sind. Aber diese Funktion ist wichtig: Sie spart Bandbreite und damit Kosten. Und eine Komprimierung nach der Verschlüsselung ist nicht mehr möglich. Also müssen Messungen mit IPSec-Komprimierung (IPComp) vorliegen, ansonsten sind sie unrealistisch.
11.3 Die Herstellerauswahl Nun kommen wir zu einem etwas heiklen Thema, der Auswahl eines oder mehrerer geeigneter Hersteller. An diese Auswahl können Sie auf verschiedene Art und Weise herangehen: Sie können sich zuerst einen oder mehrere Hersteller nach bestimmten Kriterien aussuchen und ermitteln, ob diese die geeigneten Produkte in ihrem Portfolio haben. Oder Sie definieren anhand verschiedener Kriterien, die die VPN-Produkte aufweisen müssen, ein Anforderungsprofil und suchen davon ausgehend Hersteller, die passende Produkte in ihrem Programm haben. Egal auf welche Weise Sie sich an die Sache heranwagen, es werden am Ende meist mehrere in Frage kommende Hersteller übrig bleiben. Jetzt stehen Sie vor der ersten wichtigen Entscheidung: Wählt man für eine Produktfamilie einen oder mehrere, in der Regel zwei, verschiedene Hersteller aus? Dies ist nicht selten eine strategische Entscheidung, die in der Vergangenheit im betroffenen Unternehmen bereits getroffen wurde, zum Beispiel bei der Beschaffung von LAN- oder WAN-Komponenten. In diesem Fall bleibt meist keine Wahl. Im anderen Fall sollten Sie sich sehr genau überlegen, ob Sie gleiche Funktionalitäten in Form von Produkten verschiedener Hersteller beziehen wollen. Das Problem sind hierbei nicht die aktuellen Produkte, sondern deren zukünftige Weiterentwicklung, die weder von der Art der neuen Features noch von deren zeitlicher Verfügbarkeit her bei verschiedenen Herstellern synchron verlaufen wird. Dies kann in der Zukunft dazu führen, dass viele neue Funktionen der Geräte überhaupt nicht genutzt werden können, da sie nicht konsistent im Netzwerk verfügbar sind.
366
Die Herstellerauswahl
Also sollten Sie sich innerhalb einer bestimmten, abgegrenzten Funktionalität, zum Beispiel dem VPN-Remote-Access, für einen einzigen Hersteller entscheiden. Das komplette VPN, bestehend aus Remote-Access-VPN, BranchOffice-VPN, Security- und Managementsystemen kann dabei natürlich auch von verschiedenen Herstellern stammen. Nach welchen Kriterien wählt man den für einen bestimmten VPN-Produktbereich am besten geeigneten Hersteller aus? Die im Folgenden erläuterten Kriterien weisen eine Reihe gegenseitiger Abhängigkeiten auf und sind von Fall zu Fall auch von unterschiedlicher Wertigkeit. Bei einer solchen Herstellerauswahl spielt in der Praxis auch noch eine ganze Reihe anderer Faktoren eine Rolle, zum Beispiel frühere Erfahrungen mit bestimmten Produzenten, firmenpolitische Gegebenheiten oder bestehende Rahmenverträge und vieles andere mehr, was aber hier nicht Gegenstand unserer Betrachtungen sein kann. Größe und Zukunftsaussichten Die Größe eines Unternehmens und seine voraussichtliche zukünftige Entwicklung sind ein wichtiger Faktor bei der Entscheidungsfindung. Ein VPN soll über Jahre hinaus betrieben werden, es muss wachsen können, und aktuelle Entwicklungen in den dazugehörigen Technologien sollen ebenfalls Einzug finden. Dieses Ziel ist mit einer Firma, die Gefahr läuft, in absehbarer Zeit vom Markt zu verschwinden oder die sich aus wirtschaftlichen oder unternehmerischen Gründen von bestimmten Unternehmensbereichen trennt, nicht zu erreichen. Sie brauchen vielmehr eine Firma, die stark genug ist, eine ausreichend lange Zeit zu existieren, um die entsprechenden Produkte herzustellen, weiterzuentwickeln und zu pflegen. Erfahrung im VPN-Umfeld Die Erfahrung im VPN-Geschäft eines Herstellers ist ein weiterer wichtiger Faktor. Ist es ein Newcomer, der noch schnell auf den VPN-Zug aufspringen will, oder ist es ein Profi, der schon seit mehreren Jahren seine Erfahrungen gesammelt und die entsprechenden Mitarbeiter und Technologien hat? Aber Vorsicht, hier muss man sehr genau nachforschen, denn eine Firma, die vielleicht erst ein oder zwei Jahre existiert, kann durchaus in die Kategorie »Profis« fallen, wenn ihre Mitarbeiter die entsprechende jahrelange Erfahrung aus anderen Firmen eingebracht haben. Auch der umgekehrte Fall, dass sich zum Beispiel ein großes Unternehmen einen langjährig erfahrenen VPN-Spezialisten einverleibt hat, sagt noch nichts aus, denn es kann sein, dass ein großer Teil der VPN-erfahrenen Mitarbeiter die Firma wieder verlassen hat.
367
11 Auswahl der VPN-Komponenten
Eingesetzte Technologien Hier ist nicht die Frage, welche Protokolle und Funktionalitäten die Systeme bereitstellen müssen, das wurde ja bereits im Anforderungskatalog definiert. Interessant für eine Entscheidung ist vielmehr, mit welcher Technologie der Hersteller dies umgesetzt hat. Da gibt es eine Reihe von Punkten zu klären: 왘 Wird ein geeignetes Betriebssystem mit einem schlanken, echtzeitfähigen
Kernel eingesetzt? 왘 Erfolgt die Implementierung in Software oder in Hardware, und sind im
ersteren Fall zumindest Hardwarebeschleuniger verfügbar? 왘 Ist die Software modular aufgebaut oder monolithisch? 왘 Ist die Hardware modular aufgebaut und erweiterbar?
VPN-Produktportfolio Das VPN-Produktportfolio ist ein sehr guter Indikator dafür, welchen Stellenwert diese Technologie in dem betreffenden Unternehmen innehat. Ein Idealkandidat hat eine VPN-Produktpalette, die von der Clientsoftware und Small-Office-Systemen bis hin zum Hochverfügbarkeits-Remote-Access-Konzentrator und Branch-Office-Gateway alles bietet, und dies möglichst noch in verschiedenen Leistungsklassen. Bei einem solchen Unternehmen kann man getrost davon ausgehen, dass die VPN-Technologie als Kerngeschäft angesehen wird. Ebenso ist die Wahrscheinlichkeit recht hoch, dass die verschiedenen Systeme untereinander interoperabel sind. Allerdings ist dies keineswegs garantiert – im Gegenteil, selbst Branchengrößen hatten und haben bisweilen Probleme damit, ihre, unter Umständen durch Firmenzukäufe erworbenen, verschiedenen Produktfamilien zu integrieren. Also gilt auch beim Thema Kompatibilität und Interoperabilität der Grundsatz, zuerst nachzufragen und gegebenenfalls testen oder sich die kritischen Punkte wenigstens schriftlich garantieren lassen. Zur Verfügung stehende Service-Organisation Ein VPN ist eine unternehmenskritische Ressource. Dies bedeutet, dass Ausfallzeiten minimal sein müssen, und bedingt eine schnelle Reaktion des Herstellers, Lieferanten oder Serviceunternehmens im Fall von auftretenden Problemen. Service- und Wartungsverträge werden oft nicht direkt mit dem Hersteller geschlossen, da viele Unternehmen ihre Produkte nicht direkt, sondern über Distributoren, Systemhäuser usw. verkaufen. Mit diesen Unternehmen schließt man in der Regel auch einen Wartungsvertrag ab. Aber auch wenn man einen entsprechenden Wartungsvertrag mit genauesten Regelungen und Vertragsstrafen abschließt, sollte man sich vorher vergewissern, ob der Vertragspartner überhaupt in der Lage ist, diesen zu erfüllen. Wenn Sie sich vorher schlau machen, wie viele Servicestützpunkte und Techniker das
368
Die Herstellerauswahl
Unternehmen besitzt, ob die Mitarbeiter qualifiziert sind und ob eine ausreichende Bevorratung mit notwendigen Ersatzteilen und Systemen erfolgt, können Sie sich vor bösen Überraschungen schützen. Anteil am VPN-Markt Man kann wirklich fragen, wen man will, jeder ist Marktführer. Es ist leider recht schwer, die Richtigkeit der vollmundigen Aussagen nachzuprüfen, die zum Thema Marktanteile von den Herstellern gemacht werden. Dieser Punkt gibt auch nur begrenzt Auskunft über die Qualität oder Leistungsfähigkeit eines Produkts. Die jüngere Vergangenheit ist leider voll von Beispielen, in denen bessere Produkte durch schlechtere vom Markt gedrängt wurden. Allerdings besteht bei einem sehr geringen, vielleicht noch sinkenden Marktanteil die Gefahr, dass das Produkt vom Markt genommen wird oder die Firma selbst Probleme bekommt, falls sie sonst keine anderen Technologien in ihrem Portfolio hat. Auch das beste Produkt nützt nichts, wenn es nicht mehr produziert wird. Zertifizierungen des Herstellers und seiner VPN-Produkte Es gibt eine Reihe von Zertifizierungen – z.B. solche zur elektrischen Gerätesicherheit, Strahlungsabschirmung, Qualität oder Systemsicherheit –, die ein Gerät vorweisen sollte. Im Sicherheitsbereich hat sich die IPSec-Zertifizierung der ICSA als Quasistandard durchgesetzt. Allerdings muss man hierbei sehr vorsichtig sein: Bestimmte kritische Faktoren werden von der ICSA nicht getestet oder überprüft, sondern es genügt eine schriftliche Zusicherung der Hersteller. Was mit Hilfe einer Referenzimplementierung jedoch getestet wird, sind die verschiedenen Funktionalitäten und Optionen von IKE und IPSec, so dass man als wichtigste Aussage der ICSA-IPSec-Zertifizierung die Interoperabilität des Produkts ansehen kann. Systeme unterschiedlicher Hersteller sind also, eine entsprechende Konfiguration vorausgesetzt, in der Lage, über das IPSec-Protokoll miteinander zu kommunizieren. Allerdings sollten Sie sich dabei vorher die Anmerkungen und Einschränkungen auf der ICSA-Webseite sehr genau ansehen, um böse Überraschungen zu vermeiden. Und vor allem müssen Sie unbedingt prüfen, welche Version oder Release des VPN-Systems von der ICSA zertifiziert wurde, denn meist hinken die Zertifizierungen den aktuellen Versionsständen um einige Stellen hinterher! Reaktionsgeschwindigkeit auf Markttendenzen und neue Technologien Bei der Auswahl eines geeigneten Herstellers sollten Sie ruhig einmal versuchen herausfinden, wie dieser in der Vergangenheit auf neue Märkte und Entwicklungen reagiert hat. Die entscheidenden Punkte sind hierbei, wann der betreffende Produzent reagiert hat und ob seine Maßnahmen erfolgreich und richtig waren. Dieser Punkt ist deshalb so wichtig, weil man auch in der
369
11 Auswahl der VPN-Komponenten
Zukunft sicher sein will, dass die eingesetzten Produkte zeitnah und sinnvoll weiterentwickelt werden. Insbesondere große Hersteller sind gelegentlich anfällig dafür, auf neue Tendenzen und Entwicklungen mit erheblicher Verspätung zu reagieren, man denke nur daran, wie lange Microsoft das Thema Internet ignoriert hat. Zukünftige Pläne und Visionen Hier geht es sowohl um die konkreten Pläne für die zur Auswahl stehenden Produkte als auch um die langfristige Ausrichtung des Herstellers. Insbesondere ist es interessant zu wissen, welche Bedeutung die jeweilige Kundenklasse, also Mittelstand, Großunternehmen, Service Provider usw., beim Hersteller in Zukunft haben wird. Für einen Mittelständler ergeben sich weniger Perspektiven bei einem Hersteller, der sich in Zukunft ganz auf den ServiceProvider- und Carrier-Markt konzentieren will, als bei einem, der sich auf den Enterprise-Bereich konzentrieren wird. Also ist neben den konkreten Produktplänen auch der Kurs interessant, den ein Unternehmen mittel- und langfristig steuert. Produktabkündigungen kommen für die Endkunden meist aus heiterem Himmel, kein Unternehmen wird damit an die Öffentlichkeit gehen, bevor es sein muss.
11.4 Die Auswahl der VPN-Komponenten Da keine allgemein gültigen Rezepte zur Auswahl der VPN-Systeme gegeben werden können, sind hier, aufbauend auf die vorangegangenen Kapitel dieses Buches, die verschiedenen Teile eines Pflichtenhefts beschrieben. Sie sind ausführlich erläutert und können daher als Grundlage für eigene Ausschreibungen oder Anforderungskataloge benutzt werden.
11.4.1
Das Beispielnetzwerk
Zu Auswahl von VPN-Gateways und VPN-Clients nehmen wir einmal ein Beispielnetzwerk mit dem Mengengerüst in Tabelle 11.1 an. Es soll sich dabei um ein Internet-VPN handeln, das optional auch für Remote-Access-Clients mit PPTP geeignet sein soll. Ansonsten, also in kleinen Außenstellen, Heimbüros und Niederlassungen, wird ausschließlich das IPSec-Protokoll im Tunnelmodus eingesetzt, um auch eine Verkehrsvertraulichkeit zu gewähren. Als Option für spezielle Anwendungen soll auch Remote Access mit L2TP einsetzbar sein. Die Benutzer sollen sich mit Tokenkarten (Response-Only Token) authentifizieren, und ein Umstieg auf die Verwendung von digitalen Zertifikaten ist in naher Zukunft geplant.
370
Die Auswahl der VPN-Komponenten
Der Service Provider unterstützt Class-of-Service und benötigt, da es sich um IPSec handelt, einen bereits dafür markierten äußeren IP-Header. Im Unternehmensnetz soll weiterhin sowohl eine Ende-zu-Ende-Quality-of-Service (RSVP) als auch ein erweitertes Bandbreitenmanagement benutzt werden, um VPN-Tunneln Bandbreiten innerhalb physikalischer Verbindungen zuordnen zu können. Wenn man annimmt, dass niemals alle Schnittstellen mit der vollen Datenrate betrieben werden, kann man in den zentralen Systemen (VPN-Gateway und VPN-Remote-Access-Konzentrator) einen niedrigeren Wert ansetzen. In diesem Beispiel würden zu diesem Zweck zwei E3-Schnittstellen mit 34 Mbit/s eingesetzt werden.
Anwender/Standort Remote Access (ISDN/Modem)
Anzahl Benutzer/ Standorte
Benötigte Bandbreite
2000
128 Mbit/s
200
153 Mbit/s
SOHO (ISDN)
15
0,98 Mbit/s
SOHO (DSL)
40
30 Mbit/s
Niederlassung (128 Kbit/s)
8
1 Mbit/s
Niederlassung (1 Mbit/s)
5
10 Mbit/s
Remote Access (DSL)
Zentrales Branch-Office-Gateway
1
34 Mbit/s
Zentraler VPN-Remote-Access
1
34 Mbit/s
Tab. 11.1: Das Mengengerüst des Beispielnetzwerks
Als Tunneling-Protokoll wird IPSec und optional PPTP eingesetzt. Da ein Umstieg auf Windows 2000 (Win2k) geplant ist, soll auch die Möglichkeit bereitgestellt werden, die Win2k-VPN-Clients zu terminieren, die L2TP mit IPSec im Transportmodus einsetzen. In Tabelle 11.2 bis Tabelle 11.13 finden Sie logisch gruppierte Module eines möglichen Anforderungskatalogs für Geräte in diesem VPN. Für andere Anwendungen gelten natürlich andere Mengengerüste oder Konfigurationen. Was nicht enthalten ist, ist eine Bewertung der einzelnen Punkte, da in diesem Beispiel keine Angaben zu Applikationen, Geschäftsmodell, Wachstum oder Sicherheitsstrategie enthalten sind. In einem tatsächlichen Pflichtenheft sollten die Anforderungen natürlich anhand der tatsächlichen Erfordernisse eines Unternehmens bewertet werden.
371
11 Auswahl der VPN-Komponenten
11.4.2
Allgemein
Die zentralen Systeme werden im Allgemeinen in so genannte 19"-Schränke eingebaut und sollten aus diesem Grund ein entsprechendes Gehäusemaß und ein geeignetes Einbaukit haben. In Niederlassungen kann eventuell auch ein 19"-Einbau möglich sein, in den kleinen Außenstellen und Heimbüros bevorzugt man in der Regel kompakte Bauformen. Als Speichermedium für die Konfigurationsdateien und Profile benutzen die größeren Systeme aufgrund der Datenmengen Festplatten. Für kleine Systeme (SOHO) reicht auch ein nicht flüchtiger Halbleiterspeicher (EEPROM oder Flash-ROM) aus. Kritische Systeme, über die viele Anwender kommunizieren und für die meist Wartungsverträge mit Reparaturzeiten von wenigen Stunden existieren, benötigen ein Bootmedium, mit dem eine so genannte Recovery-Routine den letzten Konfigurationsstand wieder herstellen kann. Meist sind dies Diskettenlaufwerke. Dieses Feature ist im SOHO-Bereich meist nicht erforderlich.
Allgemein
Small Office Home Office
Zentrales VPN-RemoteNiederlassung Branch-Office- AccessGateway Konzentrator
Formfaktor
Tischgerät
Tisch-/19"-Gerät 19"-Gerät
19"-Gerät
Speichermedium
EEPROM
EEPROM/HD
Festplatte
Festplatte
Recovery-Bootmedium
Kein
Kein/Diskette
Diskette
Diskette
Arbeitsspeicher 8-16 Mbyte
32-64 Mbyte
128 Mbyte
256 Mbyte
Speicher erweiterbar?
Nein
Ja
Ja
Ja
Beschleunigeroption
Nein
Nein
Ja
Ja
Erweiterungsslots für Interfacekarten
1
1–2
3+
5+
MTBF
>100.000 Std. >100.000 Std.
>100.000 Std.
>100.000 Std.
Temperatur (Betrieb)
0-40 °C
0-40 °C
0-40 °C
0-40 °C
Betriebsspannung
100-240 VAC
100-240 VAC
100-240 VAC
100-240 VAC
Luftfeuchte (Betrieb)
10-90%
10-90%
10-90%
10-90%
Tab. 11.2: Allgemeine Anforderungen an die VPN-Komponenten
372
Die Auswahl der VPN-Komponenten
Der Arbeitsspeicher sollte nicht zu knapp ausfallen. Hier ist vor allem auch darauf zu achten, dass bei skalierbaren Systemen, die durch weitere Interfaces aufgerüstet werden können, auch eine adäquate Speicheraufrüstung möglich ist. Ebenso sollten in Geräten, die zentral eingesetzt werden, Erweiterungsplätze für weitere Interface-Karten vorhanden sein. Systeme, die mit hohen Bandbreiten Daten ver- und entschlüsseln müssen, sollten sowohl von ihrem Betriebssystem als auch ihren Erweiterungssteckplätzen her auf die Aufnahme von Hardwarebeschleunigern vorbereitet sein. In unserem Beispiel ist dies bei den beiden zentralen Systemen erforderlich. Bei den Umgebungsbedingungen (Temperatur, Feuchte usw.) sind die Systeme mit anderem Netzwerkequipment vergleichbar. Die MTBF (Mean Time Between Failure) sollte mindestens 100.000 Stunden betragen.
11.4.3
Leistung
Die geforderte Leistung ergibt sich aus dem Mengengerüst und einer eventuell vorausgegangenen Verkehrsprofil-Analyse der Datenübertragungen. Im SOHO-Bereich sollte man mittlerweile in jedem Fall mit DSL rechnen und einen Durchsatz von mindestens 1 Mbit/s fordern. Alle Durchsätze beziehen sich auf den »Worst case«, also die jeweils maximale Anzahl von Tunneln, sowie auf IPSec-ESP im Tunnelmodus mit Triple-DES, SHA1 und IPSecDatenkompression.
Performanceanforderungen Max. Anzahl Tunnel
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator 3
25 bis 100
1000
5000
Durchsatz (IPSec, 1 Mbit/s Triple-DES, SHA1, IPComp) 1 Tunnel
2–10 Mbit/s
>34 Mbit/s
> 34 Mbit/s
Durchsatz (IPSec, 1 Mbit/s Triple-DES, SHA1, IPComp) max. Tunnel
2–10 Mbit/s
>34 Mbit/s
> 34 Mbit/s
IKE (Shared Secret)
1 Verb./s
2 Verb./s
>20 Verb./s
1 Verb./s
Tab. 11.3: Die Performanceanforderungen an die verschiedenen VPN-Gateways
373
11 Auswahl der VPN-Komponenten
Performanceanforderungen IKE (Dig. Signatur)
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator nicht nötig
Delay (IPSec-ESP, < 20ms Triple-DES, SHA1, IPComp) max. Tunnel
1 Verb./s
1 Verb./s
>10 Verb./s
< 20ms
< 20ms
< 20ms
Tab. 11.3: Die Performanceanforderungen an die verschiedenen VPN-Gateways
Ein weiterer, vor allem für den VPN-Remote-Access wichtiger Wert ist die Anzahl der IKE-Verbindungen, die pro Zeiteinheit aufgebaut werden können. Diesen Wert werden Sie in den wenigsten Datenblättern finden, da er oft sehr ernüchternd wirkt! Diesen Wert müssen Sie aber, zumindest für VPN-RemoteAccess-Konzentratoren genau wissen, denn es macht einen Unterschied, ob man pro Sekunde 1,5 oder 115 IPSec-Verbindungen aufbauen kann. Im ersten Fall würden alle 2200 Remote-Access-User nämlich fast eine halbe Stunde benötigen, bis alle Verbindungen stehen – und das bei nahezu 100% Systemlast allein für den Verbindungsaufbau. Dieser Wert, 1,5 Sekunden, ist auch nicht aus der Luft gegriffen, sondern beruht auf den Angaben eines Datenblattes zu einem IPSec-Chipsatz. Bei der IKE-Performance spielt es auch eine maßgebliche Rolle, ob mit PreShared Secrets oder digitalen Signaturen authentifiziert wird, und ob außerdem noch PFS (Perfect Forwarding Secrecy) aktiviert ist. Denn davon hängt die Anzahl der verschiedenen Public-Key-Operationen ab, die für die Schlüsselerzeugung und für die Authentifizierung nötig sind. Authentifizierung
Diffie-Hellman
RSA-Signatur
RSA-Verify
Pre-Shared Secret
2
-
-
Pre-Shared Secret mit PFS
4
-
-
Digitale Signatur
2
1
2
Digitale Signatur mit PFS
4
1
2
Tab. 11.4: Die Anzahl der benötigten Public-Key-Operationen für die verschiedenen Formen der Authentifizierung und Schlüsselerzeugung im IKE-Protokoll
Die Paketverzögerung ist ein Wert, der für bestimmte Applikationen von entscheidender Wichtigkeit ist. Hier sollte der Anteil, den ein VPN-System zur Gesamtlaufzeit eines Datenpakets beiträgt, extrem niedrig sein. Dieser Wert hängt neben der notwendigen Verarbeitung von IPSec auch von anderen Gegebenheiten wie der Paketpriorität, der Systemauslastung und der Filterung ab – alles Prozesse, die den Delay noch vergrößern können. 374
Die Auswahl der VPN-Komponenten
11.4.4
Schnittstellen
Das private Interface (siehe Tabelle 11.5) ist die Schnittstelle eines VPN-Gateways, die direkt an das Intranet angeschlossen ist. Die Art und Geschwindigkeit dieses Anschlusses richtet sich zum einen nach dem benötigten Datendurchsatz und zum anderen nach der verwendeten Topologie. Allerdings hat sich die LAN-Welt mittlerweile ausschließlich für Ethernet entschieden, so dass man VPN-Systeme mit einem Token-Ring-Interface lange suchen muss. Als Geschwindigkeiten haben sich üblicherweise 100 Mbit/s oder 10/100Mbit/s-Autonegotiation durchgesetzt; im SOHO-Bereich reichen üblicherweise 10 Mbit/s aus.
Privates Interface
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
Ethernet 10 Mbit Ja
Ja
Ja
Ja
Ethernet 10/100 Mbit
Ja
Ja
Ja
Ja
Ethernet 1000 Mbit
Nein
Nein
Optional
Optional
Hub (Ports)
Optional
Nein
Nein
Nein
10/100 Switch (Ports)
Optional
Nein
Nein
Nein
Tab. 11.5: Die Schnittstellen der unterschiedlichen Systeme
Das öffentliche Interface (siehe Tabelle 11.6) kommuniziert mit dem Internet. Hier werden dann serielle Schnittstellen verwendet, wenn das System direkt an einem Netzwerk-Terminator des Carriers oder Service Providers angeschlossen ist. Falls der ISP bereits einen Router mit LAN-Interface am Standort des Kunden betreibt, kann statt dessen auch ein kostengünstiges Ethernet-Interface eingesetzt werden. Beachten Sie bitte, dass ein 100-Mbit/s-Ethernet-Interface um ein Vielfaches günstiger ist als ein serielles E3-Interface (34 Mbit/s).
Öffentliches Interface
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
Ethernet 10 Mbit Ja
Ja
Ja
Ja
Ethernet 10/100 Mbit
Optional
Ja
Ja
Ja
E1-Seriell, X.21
Optional
Ja
Ja
Ja
Tab. 11.6: Die öffentlichen Interface-Typen der Gateways
375
11 Auswahl der VPN-Komponenten
Öffentliches Interface
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
E3-Seriell, X.21
Optional
Optional
Ja
Ja
Ethernet/PPPoE
Ja
Nein
Nein
Nein
Console-Port, Terminal
Ja
Ja
Ja
Ja
Console-Port, PPP
Optional
Ja
Ja
Ja
Tab. 11.6: Die öffentlichen Interface-Typen der Gateways
Eine serielle Konsolenschnittstelle ist unabdingbar. Hier muss in jedem Fall mit einem Terminal oder Terminalprogramm auf das System zugegriffen werden können. Idealerweise beherrscht das Interface auch das PPP-Protokoll, so dass auch ein grafisches Management und ein sicheres Out-of-Band-Management über IPSec möglich sind.
11.4.5
Tunneling-Protokolle
In Internet-VPNs ist natürlich IPSec das Protokoll der Wahl. Optional können Sie, wenn es notwendig erscheint, auch noch PPTP einsetzen. Sie müssen darauf achten, dass bestimmte Systeme den IKE Aggressive Mode (vgl. Kapitel 8) beherrschen: 1. SOHO-VPN-Systeme bekommen in der Regel vom Service Provider eine dynamische IP-Adresse zugewiesen. Dies erfordert zwingend den IKE Aggressive Mode. 2. Daher muss das zentrale IPSec-Gateway diesen Modus, zumindest als Responder, ebenfalls unterstützen. 3. Der VPN-Remote-Access-Konzentrator terminiert IPSec-Clients, die ebenfalls im IKE Aggressive Mode betrieben werden müssen. Die Systeme in den Niederlassungen bekommen vom Service Provider feste IPAdressen zugewiesen und müssen also nur den IKE Main Mode beherrschen. Als weiteres Tunneling-Protokoll sollte man L2TP fordern, falls bestimmte Dienste wie zwangsweises Tunneling möglich sein sollen. Das L2F-Protokoll hat keine Zukunft mehr. Wenn es noch für alte Anwendungen benötigt wird, kann man es als Feature fordern, ansonsten ist es überflüssig. Davon abgesehen können auch viele L2TP-Implementierungen L2F terminieren.
376
Die Auswahl der VPN-Komponenten
TunnelingProtokolle
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
IPSec-ESP
Ja
IPSec-AH
Ja
Ja
Ja
Ja
IKE Main Mode
Ja
Ja
Ja
Ja
IKE Aggressive Mode
Ja
Nein
Ja
Ja
IKE Pre-Shared Secret
Ja
Ja
Ja
Ja
IKE Digital Signature
Optional
Ja
Ja
Ja
PPTP
Nein
Nein
Nein
Ja
L2TP
Nein
Nein
Nein
Ja
L2F
Nein
Nein
Nein
Nein
L2TP/IPSecTransport
Optional
Optional
Optional
Ja
Ja
Ja
Ja
Tab. 11.7: Die verschieden Tunneling-Protokolle
11.4.6
Sicherheit
Die verschiedenen Sicherheitsfunktionen hängen teilweise von den eingesetzten Tunneling-Protokollen ab. Im Fall von IPSec müssen vom Standard her DES, MD5, SHA1 und Diffie-Hellman mit 768 Bit unterstützt werden. Im Weiteren müssen zur Datenverschlüsselung über das Internet starke Algorithmen verwendet werden: 왘 Triple-DES (168 Bit) ist in jedem Fall aus Gründen höchstmöglicher Inter-
operabilität zu fordern. Es ist auch gleichzeitig der vom NIST bestimmte AES-Backup-Algorithmus. 왘 Der AES ist zwar im Augenblick noch nicht offiziell verabschiedet, aber
Sie sollten Rijndael bereits mit in das Pflichtenheft aufnehmen, und sei es als vom Hersteller zu garantierendes Feature einer späteren SoftwareRelease. 왘 Andere Verfahren wie Twofish, IDEA usw. können optional eingesetzt
werden, aber natürlich nur auf allen beteiligten Systemen gleich. Für PPTP muss ebenfalls eine starke Verschlüsselung eingesetzt werden können, hierfür gibt es die Microsoft Point-to-Point-Encryption (MPPE), die das RC4-Protokoll mit 40 oder 128 Bit benutzt.
377
11 Auswahl der VPN-Komponenten
Sicherheit
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
DES (56 Bit)
Ja
Ja
Ja
Ja
Triple-DES (168 Bit)
Ja
Ja
Ja
Ja
AES (Rijndael) 128 Bit
sobald Stand. sobald Stand.
sobald Stand.
sobald Stand.
IDEA, 128 Bit
Optional
Optional
Optional
Optional
Twofish, 128 Bit
Optional
Optional
Optional
Optional
Oakley-Group 1, 768 Bit
Ja
Ja
Ja
Ja
Oakley-Group 2, 1024 Bit
Ja
Ja
Ja
Ja
Oakley-Group 3, 1536 Bit
Optional
Optional
Optional
Optional
RC4 40 Bit (PPTP) Nein
Nein
Nein
Ja
RC4 128 Bit (PPTP)
Nein
Nein
Nein
Ja
SHA1
Ja
Ja
Ja
Ja
MD5
Ja
Ja
Ja
Ja
SSL (Management)
Nein
Nein
Optional
Optional
IPSec (Management)
Ja
Ja
Ja
Ja
SSL (LDAP)
Nein
Nein
Ja
Ja
X.509v3-Zertifikate
Optional
Ja
Ja
Ja
Nein
Ja
Ja
SSL-Serverzertifi- Nein kate
Tab. 11.8: Die verschiedenen Sicherheitsprotokolle
Das Management sollte ebenfalls verschlüsselt werden können. Bei reinem Web-Management kann dies mit SSL (Secure Socket Layer) geschehen. Falls andere oder zusätzliche Protokolle wie Telnet, FTP usw. eingesetzt werden sollen, empfiehlt es sich, auch für das Management IPSec einzusetzen. Falls ein externer LDAP-Server benutzt wird, muss man hierfür auch ein sicheres Protokoll, meist das SSL-Protokoll, verwenden.
378
Die Auswahl der VPN-Komponenten
11.4.7
Authentifizierung
Authentifizierung
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
IPSec (IKE): PreShared Secret
Ja
Ja
Ja
Ja
IPSec (IKE): digitale Signatur
Nein
Ja
Ja
Ja
Benutzer: Passwort
Nein
Nein
Nein
Ja
Benutzer: Signatur
Nein
Nein
Nein
Ja
MSCHAP Version 1
Nein
Nein
Nein
Ja, für PPTP
MSCHAP Version 2
Nein
Nein
Nein
Ja, für PPTP
Benutzer: Nein Response-Tokenkarte
Nein
Nein
Ja
Benutzer: Challenge-Response-Tokenkarte
Nein
Nein
Nein
Ja
RADUS-Auth.
Nein
Nein
Nein
Ja
Externe LDAPAuth.
Nein
Nein
Ja
Ja
PKI, PXIX-RFC
Nein
Ja
Ja
Ja
PKI, Entrust*
Nein
Ja, optional
Ja, optional
Ja, optional
PKI, Verisign*
Nein
Ja, optional
Ja, optional
Ja, optional
PKI, Baltimore*
Nein
Ja, optional
Ja, optional
Ja, optional
PKI, man. Im/Export
Nein
Ja
Ja
Ja
X.509v3-Zertifikate
Nein
Ja
Ja
Ja
Autom. CRL-Update
Nein
Nein
Ja
Ja
Tab. 11.9: Die verschiedenen Möglichkeiten der Authentifizierung
379
11 Auswahl der VPN-Komponenten
Bei der Authentifizierung muss zwischen der Benutzer- und der SystemAuthentifizierung differenziert werden. Die Authentifizierung im IKE-Protokoll muss in jedem Fall, bedingt durch den Standard, eine Authentifizierung mit Pre-Shared Secrets unterstützen. Weiterhin sollte eine starke Authentifizierung durch digitale Signaturen möglich sein. Hier müssen, obwohl es damit in der Praxis noch sehr schlecht aussieht, die IETF-Standards unterstützt werden und optional noch weitere proprietäre PKI-Architekturen der wichtigsten Marktführer in diesem Bereich (Entrust, Verisign und Baltimore). Im Fall von VPN-Gateways muss nicht unbedingt eine automatische Zertifikatverteilung erfolgen, da diese Systeme von Fachpersonal verwaltet werden und Systemzertifikate in der Regel eine relativ lange Lebensdauer haben. Da IKE keine Authentifizierung mit anderen als den im Standard (vgl. Kapitel 8) beschriebenen Verfahren unterstützt, muss eine Authentifizierung mit Token-Karten oder auch RADIUS speziell implementiert werden, um die Kommunikation unter dem Schutz einer ISAKMP-SA abwickeln zu können. Da für den Remote Access optional auch PPTP eingesetzt werden soll, muss der VPN-Remote-Access-Konzentrator auch die entsprechenden Authentifizierungsverfahren (MSCHAP Version 1 und 2) unterstützen können.
11.4.8
Quality-of-Service und Profile
Im Unternehmensnetz soll teilweise eine Ende-zu-Ende-Quality-of-Service betrieben werden und teilweise auch bereits DiffServ als klassenbasierende QoS-Variante. Für die flussbasierende QoS wird das RSVP-Protokoll eingesetzt. Die beteiligten Systeme, insbesondere auch die Clientsoftware, sollten dieses Protokoll unterstützen. Quality-ofService und Profile
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
RSVP
Nein
Ja, optional
Ja, optional
Ja, optional
DiffServ Marking Nein
Ja
Ja
Ja
Prioritätswarteschlangen
Nein
Ja
Ja
Ja
Admission Control
Nein
Nein
Nein
Ja
Filterprofile
Nein
Nein
Ja
Ja
Filterprofile pro User
Nein
Nein
Nein
Ja
Tab. 11.10: Quality-of-Service und Bandbreiten-Management
380
Die Auswahl der VPN-Komponenten
Quality-ofService und Profile
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
Filterung, Ports
Ja
Ja
Ja
Ja
Filterung, Protokolle
Ja
Ja
Ja
Ja
Filterung, Adressen
Ja
Ja
Ja
Ja
DHCP-Client
Nein
Nein
Nein
Ja
User IP-Pool
Nein
Nein
Nein
Ja
Feste IP-Adresse pro User
Nein
Nein
Nein
Ja
BandbreitenManagement
Nein
Optional
Ja
Ja
Tab. 11.10: Quality-of-Service und Bandbreiten-Management
Mit dem Service Provider wurde ein SLA abgeschlossen, in dem auch die Umsetzung der internen Qualitätsklassen auf die vom Provider unterstützen Klassen definiert wurde. Da IPSec im Tunnelmodus eingesetzt wird, sind die originalen IP-, TCP- und UDP-Header, die der DiffServ-Edge-Router zur Klassifizierung benötigt, leider bereits verschlüsselt. Also müssen die Pakete zum Zeitpunkt der Übergabe an den ISP bereits klassifiziert und markiert sein und das DS-Byte des inneren IP-Headers in den äußeren kopiert werden. Dies tut IPSec bereits. Die Markierungen müssen also entweder bereits im Netzwerk oder, wie hier in unserem Beispiel gefordert, spätestens im VPN-Gateway klassifiziert und markiert werden. Die Gateways in der Zentrale und den Niederlassungen müssen natürlich auch die geeigneten QoS-Funktionen zum Bearbeiten der markierten Pakete bieten, vor allem verschieden priorisierte Warteschlangen. Da der Remote Access im Allgemeinen überbucht wird, muss auch eine Priorisierung des Zugangs (Call Admission Priority) möglich sein. Hier werden Benutzern oder Gruppen verschiedene Prioritäten zugeteilt, die darüber entscheiden, ob bei einer gewissen Auslastung des Systems noch ein Zugang erlaubt ist. Bestimmte Dienste und Protokolle können in guten VPN-Gateways gefiltert werden. Der Sinn und die Art der Filterung hängen von verschiedenen Kriterien und Strategien des Unternehmens ab. Allgemein ist zu fordern, dass es sowohl vorkonfigurierte Standardfilter gibt als auch eine völlige freie Definition von Filterregeln und deren Kombination zu Filtern möglich ist.
381
11 Auswahl der VPN-Komponenten
11.4.9
Management, Accounting, Logging und weitere Funktionen
Je nach Wunsch der Administration oder nach den Unternehmensrichtlinien ist eine grafische, eine textbasierende oder eine Kombination beider Lösungen zur Administration der VPN-Komponenten erforderlich. Die Administration, egal auf welcher Basis, muss auch gesichert möglich sein, da nicht wenige Angriffe auf Netze innerhalb eines Unternehmens gestartet werden. Ideal hierfür ist IPSec, allerdings muss in diesem Fall auch IPSec auf dem privaten Interface unterstützt werden. Falls man nur webbasiertes Management einsetzt, reicht auch eine SSL-Verschlüsselung aus. Eine wichtige Funktion in verzweigten VPNs ist auch die Option, Datenverkehr direkt zwischen Tunnelendpunkten zu ermöglichen. Ein Übergang (Tunnelswitching) zwischen verschiedenen Tunnelmedien, z.B. IPSec auf L2TP, kann in verschiedenen Umgebungen ebenfalls Sinn machen. NAT (Network Address Translation) kann erforderlich sein, falls in den Netzen, die über VPN-Tunnel angebunden werden, gleiche oder überschneidende IP-Bereiche vorhanden sind. Es sollten, wenn möglich, die folgenden verschiedenen NAT-Varianten zur Verfügung stehen: 왘 1-zu-N-Nat 왘 statisches NAT (1-zu-1) 왘 dynamisches NAT (NAT-Pooling)
Die verschiedenen Logging- und Accounting-Funktionen geben einen vorgefilterten Aufschluss über bestimmte Systemereignisse: 왘 Das Security Log enthält Informationen über Anmeldungen, Anmeldever-
suche, Eindringversuche und vermutete Angriffe sowie weitere sicherheitskritische Informationen. 왘 Das Configuration Log schreibt mit, wer an dem System welche Konfigura-
tionsänderungen vornimmt. Dies ist ein wichtiges Feature, wenn Systeme durch verschiedene Administratoren verwaltet werden. 왘 Das System Log enthält Informationen über bestimmte Systemzustände,
die zur Beurteilung der Komponenten notwendig sind. 왘 Das Accounting stellt Datensätze zur Verfügung, die zur Abrechnung der
VPN-Dienste benutzt werden können. Systeme, deren Funktion als kritisch einzustufen ist, müssen bei bestimmten Problemen, Systemzuständen oder Fehlern Meldungen (SNMP-Trap) an eine Netzwerkmanagementstation schicken, damit sofort entsprechende Maßnahmen eingeleitet werden können. Je nach Qualität der Systeme kann man diese Traps, neben einigen Standard-Traps, frei konfigurieren. Gründe für Traps sind zum Beispiel: 382
Die Auswahl der VPN-Komponenten
왘 Stromversorgungsprobleme 왘 Hitzeprobleme 왘 Lüfterausfälle 왘 Eindringversuche 왘 Physischer Zugriff auf das Gerät 왘 CPU-Überlast 왘 Arbeitsspeicherverbrauch über dem Limit 왘 Plattenplatz unter dem Limit 왘 Bandbreitenüberlast 왘 Ausfall bestimmter Systemmodule
Ein NTP (Network Time Protocol) zur netzwerkweiten Zeitsynchronisierung ist oft eine sinnvolle Sache, vor allem, wenn verschiedene Systeme mit zentralen Servern kommunzieren müssen. Funktionen für Backup/Recovery, Standby-Protokolle (VRRP) und Lastverteilung (Loadbalancing) sind in produktiven Umgebungen wichtig, um Ausfälle einzelner Systeme abzufangen. Der VPN-Remote-Access-Konzentrator muss in der Lage sein, seine auf ihn zugeschnittenen Clients zu terminieren und zu administrieren. Die komplette Konfiguration der Clients muss beim Verbindungsaufbau vom Konzentrator auf den Client übertragen werden. Die Konfiguration kann dabei auf dem VPN-Konzentrator selbst oder in einem LDAP-Directory-Server gespeichert werden.
Funktion
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
Tunneling auf Ja dem öffentlichen Interface
Ja
Ja
Ja
Tunneling auf dem privaten Interface
Nein
Ja
Ja
Ja
Tunnel-Switching
Nein
Nein
Ja
Ja
Tab. 11.11: Management-, Accounting- und Logging-Funktionen
383
11 Auswahl der VPN-Komponenten
Funktion
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
Paketfilterung
Ja
Ja
Ja
NAT 1-zu-N
Ja
Nein
Nein
Nein
NAT statisch
Nein
Ja
Ja
Ja
NAT Pool
Nein
Ja
Ja
Ja
Logging
Ja
Ja
Ja
Ja
Ja
Logging (Syslog) Nein
Nein
Ja
Ja
Accounting
Nein
Ja
Ja
Security Logging Ja
Ja
Ja
Ja
SNMP-Traps
Nein
Optional
Ja
Ja
NTP (Network Time Protocol)
Nein
Nein
Ja
Ja
Command Line Management
Ja/Nein
Ja/Nein
Ja/Nein
Ja/Nein
Grafisches Management
Ja/Nein
Ja/Nein
Ja/Nein
Ja/Nein
Loadbalancing
Nein
Nein
Ja
Ja
Backup/Failover
Nein
Nein
Ja
Ja
VRRP
Nein
Nein
Ja
Ja
IPSec-ClientTerminierung
Nein
Nein
Nein
Ja
Nein
Tab. 11.11: Management-, Accounting- und Logging-Funktionen
11.4.10 VPN-Routing In größeren VPNs kommt man mit dem statischen Routing von IPSec nicht weit, hier benötigt man spezielle Implementierungen von Routingprotollen. Diese arbeiten nur auf privaten Schnittstellen und Tunnelendpunkten und übertragen ihre Routingpakete nur im Unternehmensnetz. Auf den öffentlichen Schnittstellen dürfen keine Netze publiziert oder gelernt werden. In kleinen und mittleren Umgebungen reicht meist RIP (Routing Information Protocol) aus, in größeren oder stark wachsenden Netzen sollte man OSPF (Open Shortest Path First) einsetzen. OSPF muss auch mit RIP parallel betrieben und kombiniert werden können, um auch kleinere Lokationen, die möglicherweise kein OSPF unterstützen, integrieren zu können. Da IPSec-Tunnel praktisch statische Routen darstellen, müssen diese von den beiden Routing-Protokollen unterstützt werden.
384
Die Auswahl von VPN-Clientsoftware
VPN-Routing
Zentrales VPN-RemoteSmall Office Niederlassung Branch-Office- AccessHome Office Gateway Konzentrator
Statisch
Ja
Ja
Ja
Ja
RIP-1
Ja
Ja
Ja
Ja
RIP-2
Ja
Ja
Ja
Ja
OSPF
Nein
Optional
Ja
Ja
Nein
Ja
Ja
Tunnel-zu-Tunnel Nein
Tab. 11.12: Die notwendigen VPN-Routing-Protokolle
11.5 Die Auswahl von VPN-Clientsoftware Der VPN-Client ist primär ein Remote-Access-Client, der vom Service Provider bei der Einwahl jeweils andere IP-Adressen zugewiesen bekommt. Aus diesem Grund ist eine Unterstützung des IKE Aggressive Mode unabdingbar. In professionellen Umgebungen setzt man heutzutage aus Gründen eines effizienten, zentralen Managements Clients ein, die nur mit einem speziellen VPN-Remote-Access-Konzentrator betrieben werden. Diese Clients werden zentral konfiguriert, meist auf dem VPN-Konzentrator oder in einem Verzeichnisdienst; und sobald sie eine IPSec-Verbindung aufbauen, werden sie mit der aktuellen Konfiguration versorgt. Diese Konfiguration umfasst unter anderem: 왘 IPSec-Security-Einstellungen, z.B. ESP, Triple-DES, SHA1, IPComp, PFS
und ARS 왘 Private (innere) IP-Adresse 왘 Primäre und sekundäre WINS- und DNS-Adressen 왘 Client-Sicherheitsstrategie (Filter, Bildschirmschoner, ....) 왘 Adressen von Backup-Systemen 왘 Art der Benutzerauthentifizierung 왘 Adressen oder Domainnamen, die den automatischen Start des Clients
auslösen (Autoconnect) Der Anwender darf diese Parameter aus Gründen der Sicherheit natürlich nicht verändern können.
385
11 Auswahl der VPN-Komponenten
IPSec muss voll unterstützt werden. Im Allgemeinen entscheidet der RemoteAccess-VPN-Konzentrator, welcher IKE-Vorschlag (Proposal, vgl. Kapitel 8) angenommen wird. Demnach muss der Client folgende IPSec Protection Suites unterstützen: 왘 ESP mit Verschlüsselung, Integritätsprüfung, Authentifizierung und ARS 왘 ESP mit Verschlüsselung, Integritätsprüfung und Authentifizierung 왘 ESP mit Verschlüsselung und ARS 왘 ESP mit Verschlüsselung 왘 ESP mit Integritätsprüfung, Authentifizierung und ARS 왘 ESP mit Integritätsprüfung und Authentifizierung 왘 AH mit Integritätsprüfung, Authentifizierung und ARS 왘 AH mit Integritätsprüfung und Authentifizierung
Bei der Verschlüsselung sind dabei folgende verschiedene Algorithmen zu unterstützen: 왘 DES (56 Bit), vom Standard zwingend vorgeschrieben 왘 Triple-DES (168 Bit) 왘 In Zukunft AES (128 Bit)
Die beiden Algorithmen zur Paket-Authentifizierung und Integritätsprüfung, die im IPSec-Standard zwingend vorgeschrieben sind, sind dabei ebenfalls frei wählbar: 왘 HMAC-MD5-96 왘 HMAC-SHA1-96
Die Authentifizierungsverfahren sind ebenfalls unterschiedlich: 왘 Pre-Shared Secret, vom Standard zwingend vorgeschrieben 왘 Digitale Signatur (X.509-Zertifikat) 왘 Token-Karten unter dem Schutz einer eigenen ISAKMP-SA
Bei einer sicheren PKI ist es unabdingbar, dass die privaten Signaturschlüssel tatsächlich von den Benutzern verwahrt werden. Eine Speicherung auf den PC der Benutzer ist nicht ausreichend. Üblicherweise wird dies dadurch realisiert, dass der Benutzer eine Chipkarte erhält, in der sein privater Schlüssel gespeichert ist. Signaturen werden in der Karte erzeugt. Der private Schlüssel verlässt also niemals die Karte, die der Benutzer immer mit sich führen kann.
386
Die Auswahl von VPN-Clientsoftware
Gute Clientimplementierungen bieten Unterstützung für Chipkarten oder Datenträger, oder sie unterstützen die Clientsoftware von PKI-Anbietern, die ihrerseits eine Chipkarten-Unterstützung bieten. Da viele Clients über Dial-In-Verbindungen arbeiten, sollte eine gute Implementierung in der Lage sein, den Dialer des Rechners automatisch zu starten. Die PPTP-Funktionalität kann ebenfalls im VPN-Client verankert werden, allerdings bietet das Protokoll nicht die spezielle Clientfunktionalität. Hier kann man auch einfach die PPTP-Client-Implementierung von Microsoft (im Betriebssystem eingebaut) oder anderen Herstellern benutzen. In Tabelle 11.13 sind die Anforderungen an einen VPN-Client zusammengefasst. Funktionalität
VPN-Client
IKE Aggressive Mode
Ja
IKE Pre-Shared-Key-Authentifizierung
Ja
IKE Digital-Signature-Authentifizierung
Ja
IPSec-ESP mit DES und MD5
Ja
IPSec-ESP mit DES und SHA1
Ja
IPSec-ESP mit Triple-DES und MD5
Ja
IPSec-ESP mit Triple-DES und SHA1
Ja
IPSec-ESP mit NULL-Encryption und MD5
Optional
IPSec-ESP mit NULL-Encryption und SHA1
Optional
IPSec-AH mit MD5
Ja
IPSec-AH mit SHA1
Ja
IPSec Compression
Ja
IPSec Anti-Replay Service (ARS)
Ja
Perfect Forwarding Secrecy (PFS)
Ja
Dynamische Zuweisung der privaten, inneren IP-Adresse
Ja
PPTP
Ja
RC4 40 Bit
Ja, für PPTP
RC4 128 Bit
Ja, für PPTP
MSCHAP Version 1
Ja, für PPTP
MSCHAP Version 2
Ja, für PPTP
RADIUS-Schutz durch IPSec-SA
Ja
Konfiguration durch Benutzer nicht möglich
Ja
Tab. 11.13: Die Anforderungen an einen VPN-Client
387
11 Auswahl der VPN-Komponenten
Funktionalität
VPN-Client
Zentrale Konfiguration des Clients bei jeder Einwahl
Ja
Automatischer Backup
Ja
Loadbalancing in Verbindung mit dem VPN-Gateway
Ja
Integrierte Unterstützung für Response-Token-Karten
Ja
Integrierte Unterstützung für Challenge-Response-Token-Karten
Ja
Transparente Unterstützung für PKI (PKIX-RFCs)
Ja
Transparente Unterstützung für PKI (Entrust)
Ja, optional
Transparente Unterstützung für PKI (Verisign)
Ja, optional
Transparente Unterstützung für PKI (Baltimore)
Ja, optional
Unterstützung von Chipkarten zur Zertifikatspeicherung
Ja
Unterstützung von Datenträgern zur Zertifikatspeicherung
Ja
Konfigurierbare Installation
Ja
LAN-Betrieb
Ja, für DSL!
Automatischer Start eines Dialers
Ja
Paketfilterung
Ja
Tab. 11.13: Die Anforderungen an einen VPN-Client
388
12
Fallstudien
In den folgenden Fallstudien werden zwei völlig unterschiedliche Ansätze beleuchtet, ein VPN einzuführen: der Aufbau des VPN durch das Unternehmen selbst und die Möglichkeit, das VPN als Dienst bei einem Service Provider zu mieten. Die ersten beiden Fallstudien beschreiben zwei VPNs, die von den Kunden bzw. den damit beauftragten Systemintegratoren selbst geplant und realisiert wurden. Im dritten Beispiel bekommen Sie einen Überblick über die VPNServices eines Service Providers und einen Einblick in deren technische Realisierung.
12.1 Studie 1: Die Software AG Die Software AG ist ein ideales Beispiel für eine gelungene Integration von IPVPN-Technologie für weltweiten Remote Access und Site-to-Site-Verbindungen in bereits existierende Infrastrukturen.
12.1.1
Zum Unternehmen
Die Software AG, mit Sitz in Darmstadt, ist Europas größter Anbieter von Systemsoftware. Das Unternehmen ist auf die Entwicklungen von Datenbanken und Tools für E-Business-Lösungen spezialisiert. Die Software AG ist auf Globalisierungskurs gegangen und expandiert kräftig, sowohl in Europa, Asien und Australien als auch immer stärker im nordamerikanischen Markt. Das Unternehmen ist bereits seit dem vorletzten Jahr an der Deutsche Börse notiert. Aus der Expansionsstrategie des Unternehmens mit einer Vielzahl von Beteiligungen, Akquisitionen und Kooperationen und dem sich daraus ergebenden, schnellen Wachstum resultieren naturgemäß eine Reihe von Anforderungen an das Netzwerk, denn neue Standorte, Niederlassungen, Außenstellen und Heimbüros müssen schnell und reibungslos integriert werden. Da das Kerngeschäft der Software AG eine hohe Performance und Verfügbarkeit fordert, und die Produkte auf einer Vielzahl verschiedener Plattformen vermarktet werden, leiten sich daraus weitere Anforderungen an eine geeignete, flexible und migrationsfähige Netzinfrastruktur ab.
389
12 Fallstudien
12.1.2
Das Projekt
Innerhalb dieser Randbedingungen startete die SAG 1998 ein Projekt mit dem Ziel, ihren Mitarbeitern einen weltweit mobilen Zugriff auf ihr Unternehmensnetzwerk zu gewähren. Bereits damals erkannten die Projektverantwortlichen der SAG die Möglichkeiten eines Internet-VPN und evaluierten im Sinne einer zukunftssicheren und kostengünstigen Lösung die Vor- und Nachteile dieser Technologie gegenüber einer Einwahl-Lösung. Es stellte sich dabei heraus, dass eine Lösung mit Standard-Einwählsystemen bei einer weltweit operierenden Firma wie der SAG nicht mit einer VPN-Lösung konkurrieren konnte. Somit fiel die Entscheidung auf eine Remote-Access-VPNLösung. In der Folge wurden sowohl verschiedene Hersteller und deren Lösungen evaluiert als mit Verhandlungen mit Internet Service Providern über geeignete Verträge und Service Level Agreements geführt. Bei der Auswahl geeigneter VPN-Konzentratoren musste berücksichtigt werden, dass eine, allerdings immer kleiner werdende, Anzahl von Mitarbeitern noch IPX Verbindungen benötigte. Grundsätzlich hat man sich bei der Software AG jedoch nach gründlicher Prüfung der Sicherheitsaspekte einer VPNLösung für IPSec als Tunneling- und Sicherheits-Protokoll entschieden. Für die IPX Benutzer wurde für eine gewisse Übergangszeit das Point-to-Point Tunneling Protocol als einzige Alternative zu IPSec zugelassen. Die Einführung der VPN-Technologie im Remote-Access-Bereich der Software AG hatte auch einen Einfluss auf deren internationales Weitverkehrsnetzwerk. Denn hier stand man zunehmend vor dem Problem, dass das Frame-Relay-VPN des Unternehmens nicht beliebig ausdehnbar war, da an einigen Standorten die notwendige Infrastruktur überhaupt nicht zur Verfügung stand. Auch hier schaffte die IP-VPN-Technologie Abhilfe, denn Internet-Zugänge gibt es weltweit fast an jedem möglichen Firmenstandort. Die Zugangstechnologie unterscheidet sich war von Fall zu Fall, nicht aber die Netzwerkebene, hier werden IP-Pakete übertragen und eben diese bilden die Basis eines IP-VPNs. Also wurden an einigen Standorten entweder bereits vorhandene Router auf IPSec aufgerüstet oder an anderen Standorten neue, spezielle VPN-Systeme installiert. Das VPN der Software AG ist ein hervorragendes Beispiel dafür, wie man die IP-VPN-Technologie sowohl zum Ablösen oder Umgehen des kostenintensiven Remote Access per Einwahl benutzen, als eine existierende Infrastruktur, hier ein Frame-Relay-VPN, sinnvoll damit ergänzen kann. Durch geeignete Auswahl der Systeme und Integration in die bestehende Infrastruktur, wurde der Mehrwert einer solchen Lösung hier voll ausgeschöpft. Und dies bereits zu einem Zeitpunkt, an dem viele andere in Deutschland sich noch nicht einmal grundsätzlich mit dem Thema VPN auseinandergesetzt hatten.
390
Studie 1: Die Software AG
12.1.3
Projektablauf und Realisierung
Die Implementierung der VPN-Lösungen erfolgte in der Software AG in verschiedenen Schritten, um eine reibungslose Migration ohne Einbrüche in der Produktion zu gewährleisten. Evaluation der einzusetzenden Hard- und Software Bevor sich die Software AG an den Aufbau ihres VPN machte, wurde eine Testinstallation durchgeführt um die wichtigen Parameter und Funktionen des Systems zu evaluieren. In diesem Stadium wurden die ersten Erfahrungen im Umgang mit der neuen Technologie gesammelt. Man konnte sich darüber hinaus entsprechende Konzepte zum Management und zur Softwareverteilung der IPSec Clientsoftware überlegen und testen, bevor das VPN produktiv eingesetzt wurde. Sukzessiver Aufbau des Remote-Access-VPN Der erste Schritt beim Aufbau des VPN war es den ersten produktiv einzusetzenden VPN-Remote-Access-Konzentrator in Betrieb zu nehmen. Es folgte kurz darauf ein zweites Gerät, um sowohl eine gleichmäßige Lastverteilung als auch eine volle Redundanz zu haben. Der von der Software AG eingesetzte VPN-Konzentrator, ein Gerät der Contivity Extranet Switch Serie der Firma Nortel Networks, erlaubt es, Geräte im Loadbalancing-Modus zu betreiben und dabei den Clients die Adressen der aktuellen Backupsysteme bei jedem Verbindungsaufbau neu zuzuweisen. Inzwischen wurde ein dritter Konzentrator installiert, um nunmehr weltweit bis zu 300 Benutzern gleichzeitigen, sicheren Zugriff auf die benötigten Dienste und Ressourcen im Netzwerk der Software AG zu gewähren. Während des Aufbaus des Remote-Access-VPN machten sich die Netzwerker der SAG Gedanken über den Einsatz der IP-VPN-Technologie zum Anbinden von Standorten, an denen kein Frame Relay zur Verfügung stand. Es lag auf der Hand, sich diese Technologie, mit der man zunehmend Erfahrung gesammelt hatte, auch für andere Zwecke zu nutze zu machen. Sukzessiver Aufbau der Branch-Office-VPN-Erweiterungen Nach der Klärung aller Randbedingungen wurde eine eine Pilotinstallation durchgeführt mit dem Ziel, eine Aussage hinsichtlich Verfügbarkeit, Leistung und Wartung einer solchen Lösung zu machen. Dabei wurden zwei Lösungen getestet: Zum einen befanden sich in verschiedenen Standorten bereits Router, die man durch Softwareupgrades auf IPSec aufrüsten wollte um die bereits getätigten Investitionen zu schützen. Und zum anderen galt es, neue Systeme auszusuchen und zu testen, die an neu hinzu gekommenen Standorten installiert werden sollten. Die Frage, die sich hier stellte, war, neben der
391
12 Fallstudien
geforderten Kompatibilität, auch die, ob die Performance der vorhandenen Router ausreichend sein würde. Bei den neuen Geräten fiel die Wahl von vorn herein auf spezielle VPN-Systeme. Büro Warschau
Büro Prag
Büro Seattle
Büro Chicago
VPNGateways
Büro Atlanta
VPNGateways
VPNGateways
Lokale Provider USA
Lokaler Provider Lokaler Provider
Lokale Provider USA
InternetBackbone
Lokale Provider USA
Lokale Provider Deutschland
VPNKonzentrator
VPNKonzentrator
Intranet Darmstadt
Büro Boston
IPSecClients
Intranet San Ramon
Frame Relay
Abbildung 12.1: Das weltweite VPN der Software AG
Nachdem sich alles Tests als erfolgreich erwiesen hatte, begann das Unternehmen mit der schrittweisen Erweiterung ihres Netzwerks, hin zu einem Siteto-Site-VPN das sowohl auf Frame-Relay- als auch auf IP-VPN-Technologie aufbaut.
12.2 Studie 2: Der Blutspendedienst des DRK Diese Studie ist ein sehr gutes Beispiel sowohl für ein Branch-Office-VPN als auch für den Fall, dass sich ein relativ kleines VPN mit nur wenigen Standorten rechnet, sobald diese über mehrere Länder oder Kontinente verteilt sind.
392
Studie 2: Der Blutspendedienst des DRK
12.2.1
Zu den Unternehmen
Der Blutspendedienst des DRK Die Vielfalt der Aufgaben des DRK-Blutspendedienstes reicht von der Motivation der Bevölkerung, freiwillig und unentgeltlich Blut zu spenden, über die Blutentnahme beim Spender und das Untersuchen und Aufbereiten des Spenderblutes bis hin zur Fort- und Weiterbildung von Ärzten und ärztlichem Hilfspersonal im Transfusionswesen; hinzu kommt die Forschung auf dem Gebiet der Transfusionsmedizin. Dabei hat sich die freiwillige und unentgeltliche Blutspende – weltweit vom Roten Kreuz, der Weltgesundheitsorganisation und anderen freien und gemeinnützigen sowie staatlichen Trägern propagiert – als wirksamstes System zur Sicherstellung der Versorgung mit Blut erwiesen. Zwölf überregionale DRK-eigene Blutspendedienste mit 38 Instituten sorgen für eine flächendeckende Versorgung mit Blut und Blutbestandteilen. 170 mobile Entnahmeteams führen jährlich ca. 40.000 Blutspendetermine durch, zu denen insgesamt etwa 3,8 Millionen Blutspender erscheinen. Rund 3.800 qualifizierte hauptberufliche Mitarbeiter kümmern sich als Ärzte, Chemiker, Biologen, Apotheker, Schwestern, Laborkräfte und Angestellte um eine fachgerechte Blutentnahme, um Transport und Lagerung und schließlich um die Bereitstellung von Blutpräparaten in der Klinik. Mehr als 200.000 ehrenamtliche Helferinnen und Helfer der Kreis- und Ortsverbände sowie -Bereitschaften setzen sich alljährlich für die Blutspenderwerbung, die Vorbereitung und Durchführung der Blutspendetermine in ihrer Freizeit ein. Etwa zwei Millionen Bundesbürger spenden zum Teil mehrfach pro Jahr unentgeltlich Blut. Zahlreiche Schulen, Betriebe, militärische Einheiten, Gemeindeverwaltungen, öffentliche und private Einrichtungen und die Medien unterstützen die Aufgaben des Blutspendedienstes durch die kostenlose Bereitstellung von Räumlichkeiten und die Verbreitung von Spendenaufrufen. Das Deutsche Rote Kreuz stellt rund 80% Prozent der Blutversorgung in der Bundesrepublik Deutschland sicher und verfügt über entsprechende Vorräte für Notfälle und Katastrophen. ASAP-COM Als Dienstleistungsunternehmen für Informations- und Telekommunikationssysteme mit Sitz in Heilbronn und Niederlassungen in Köln und Hamburg bietet die ASAP-COM GmbH seit 1999 Beratung, Planung und Service für den Betrieb von Netzwerkstrukturen an. Das Unternehmen hat sich dabei auf die Schwerpunkte LAN, WAN, VPN, Voice over IP und Security spezialisiert. Für andere Bereiche, z.B. PC-Technik, arbeitet ASAP-COM mit anderen, festen Partnern zusammen.
393
12 Fallstudien
Die Mitarbeiter der jungen Firma sind Netzwerkprofis, die langjährige Erfahrung aus verschiedenen Unternehmen der IT-Branche mitbringen. Die Projekte, die ASAP-COM für seine Kunden durchführt, werden meist in enger Zusammenarbeit mit den Weltmarktführern im IT-Bereich, wie Cisco Systems, Lucent Technologies, Hewlett-Packard und Nortel Networks, realisiert, von denen das Unternehmen und seine Mitarbeiter auch entsprechend zertifiziert sind.
12.2.2
Das Projekt
Der Anlass für dieses Projekt war die Anforderung, dass Software-Entwickler in Indien auf Rechnersystemen in Deutschland Software für AS/400-Applikationen entwickeln sollten. Der Blutspendedienst des DRK beauftragte die Firma ASAP-COM mit der Ausarbeitung eines Netz-Konzepts inklusive Service und Wartung, der Netzaufnahme vor Ort, einer Teststellung mit Protokollierung der Messergebnisse und einer Angebotserstellung. Aufgrund der ansonsten hohen Kosten und technischen Probleme mit Festverbindungen, wurde schnell klar, dass insbesondere der Einsatz der VPNTechnologie zu prüfen war. Aus den Anforderungen ergab sich, dass eine Verschlüsselung mit 56-Bit-Schlüsseln ausreichend ist. Ebenso wurden keine Applikationen erkannt, die empfindlich auf Verzögerungen oder Jitter reagieren oder ein spezielles Bandbreitenmanagement benötigen. Nach einer Analyse des VPN-Marktes, wobei Produkte mit den notwendigen Features und einem guten Preis-Leistungs-Verhältnis ausgesucht wurden, wurde ein VPN-Konzept erstellt. Da, um hier zukünftig auch noch weitere Standorte anbinden zu können, in dem deutschen Standort (Breitscheid) auch auf die Skalierbarkeit großer Wert gelegt wurde, hat ASAP-COM hier ein größeres System installiert, das bei 1000 parallelen IPSec-Tunneln und TripleDES-Verschlüsselung eine Bandbreite von über 30 Mbit/s ohne Hardwarebeschleuniger aufweist. Der vorgeschlagene Nortel Networks Contivity Extranet Switch 2600, der maximal 1000 Tunnel terminieren kann, lässt sich mit weiteren Schnittstellenkarten und Hardwarebeschleunigern aufrüsten und in Zukunft auch für VPN-Remote-Access einsetzen. Im indischen Technologie-Park Trivandrum (Kerala), in dem die Programmierer der Softwarefirma IVL arbeiten, wurde ein kleineres VPN-Gateway installiert. Hier ist nur eine Bandbreite von 64 kBit/s gefordert, die bei Bedarf auf 128 Kbit/s erweiterbar sein soll. Das für diesen Standort empfohlene System, ein Nortel Networks Instant Internet 100, kann problemlos die erforderliche Verschlüsselungsleistung bereitstellen.
394
Studie 2: Der Blutspendedienst des DRK
12.2.3
Projektablauf und Realisierung
Nachdem das Konzept stand, wurde es in der Praxis zuerst auf seine Tauglichkeit getestet, bevor mit der Installation und Inbetriebnahme begonnen wurde. Zu diesem Zweck wurde eine Pilotinstallation aufgebaut, um die VPN-Lösung zwischen der Zentrale von ASAP-COM in Heilbronn und IVL-India in Trivandrum unter realen Bedingungen zu testen und entsprechende Messungen zur Ermittlung der Bandbreiten und Verzögerungszeiten durchzuführen. Die Tests sollten neben der grundsätzlichen Funktion auch verschiedene Anbindungsoptionen miteinander vergleichen: 1. ILV-India benutzt zusammen mit anderen Firmen im Technopark einen ISP, der über eine 64-kBit/s-Festverbindung angeschlossen ist. 2. ILV-India benutzt einen exklusiven Internetanschluss für die RemoteApplikationen mit 64 Kbit/s. 3. ILV-India benutzt einen eigenen 64-Kbit/s-Internetanschluss. Diese drei Szenarien hatte ASAP-COM vom 4. bis 6. August 2000 in Heilbronn und Trivandrum in Zusammenarbeit mit den lokalen Internet Service Providern in Indien getestet, und es wurden entsprechende Messprotokolle erstellt. Gemessen und beurteilt wurden im Einzelnen: 왘 Die Paketumlaufzeit (Indien-Deutschland-Indien) 왘 Die mittlere Bandbreite bei Dateitransfers unkomprimierter Dateien 왘 Der subjektive Eindruck von der Benutzbarkeit der Terminalemulation
Im ersten Fall waren die Ergebnisse erwartungsgemäß schwach, sowohl bei den Paketlaufzeiten als auch bei der mittleren Bandbreite. In Trivandrum mit Terminalemulationen in auf einem System in Deutschland zu arbeiten war praktisch nicht möglich.
Paketumlaufzeit
Szenario 1
Szenario 2
Szenario 3
5000 ms
500 ms
2000 ms
Mittlere Bandbreite
2 Kbyte/s
6,2 Kbyte/s
4 Kbyte/s
Subjektiver Eindruck beim Einsatz der Terminalemulation
Mangelhaft
Gut
Ausreichend
Tab. 12.1: Der Vergleich der drei getesteten Einsatzszenarien
395
12 Fallstudien
Der zweite Fall, also ein ausschließlicher Test des VPN für den Zugriff auf die Rechner in Deutschland, wurde geprüft, indem direkt beim indischen Internet Service Provider Satyam Infoway Ltd. die Systeme installiert und getestet wurden. Die Ergebnisse waren erwartungsgemäß gut, vor allem die Paketlaufzeit. Im dritten Szenario waren die Werte und der subjektive Eindruck beim Arbeiten mit der Terminalemulation ebenfalls insgesamt befriedigend. InternetBackbone
ISP Indien
ISP Deutschland
Router
Router
DMZ IPSec Gateway Firewall
DMZ
LAN Breitscheid, Token Ring
AS/400
Intranet Breitscheid
Firewall
IPSec Gateway
LAN IVL-India Ethernet
NT Workstations mit AS/400 Emulation
Intranet IVL-India
Abbildung 12.2: Das VPN des DRK-Blutspendedienstes nach der ersten Projektphase
Nachdem die Tests insgesamt aus technischer Sicht erfolgreich verlaufen waren, empfahl ASAP-COM die Realisierung des VPN über eine direkte Anbindung von IVL-India über den ISP Satyam Infoway. Für eine kurzfristige Anbindung kann auch die vorhandene Infrastruktur übergangsweise eingesetzt werden. Das VPN wurde gemäß Abbildung 12.2 realisiert. Im Standort Breitscheid in Deutschland wurde das zentrale VPN-Gateway mit seinem öffentlichen Interface in der DMZ hinter der Firewall installiert. Das private Interface liegt im LAN Breitscheid. Analog dazu wurde Nortels Instant Internet in Trivandrum ebenfalls zwischen der DMZ und dem Intranet angeordnet. Zur Internetanbindung wurden die bereits vorhandenen Router benutzt. Die Installation wurde am 30. August 2000 produktiv in Betrieb genommen.
396
Studie 2: Der Blutspendedienst des DRK
Aufgrund der guten Erfahrungen wurde die VPN-Thematik weiter verfolgt, und im Dezember 2000 wurden zwei weitere Standorte in Deutschland, Hagen und Münster, in das VPN integriert. Die Zugangsgeschwindigkeiten der beiden neuen Niederlassungen betragen 1 Mbit/s, und der Breitscheider Router ist mit einer E1-Verbindung (2 Mbit/s) angebunden. Der komplette IPVerkehr geht nun über das VPN. Parallel zu dem VPN wird aus technischen Gründen noch ein Frame-RelayNetz betrieben, über das der komplette SNA-Verkehr (SNA over Frame Relay) abgewickelt wird.
Weitere Standorte
LAN IVL-India Ethernet
IPSec Gateway
IPSecClient
Router
In Planung
In Planung
InternetBackbone
ISP Indien
ISP Deutschland 1 Mbit/s Router
Firewall
IPSec Gateway
LAN Münster, Ethernet
1 Mbit/s
2 Mbit/s
Router
Firewall
IPSec Gateway Firewall
LAN Breitscheid, Token Ring
Router IPSec Gateway
LAN Münster, Hagen
Abbildung 12.3: In der zweiten Phase wurden weitere Standorte in Deutschland angebunden; weitere, ebenso wie der VPN-Remote-Access, sind in Planung.
Für weitere Labors und Einzelplatzsysteme sind je nach Einsatz weitere kleine VPN-Gateways oder IPSec-Clients geplant, die auf den dafür ausreichend dimensionierten Gateways terminiert werden können. Die Systeme können pro Gerät bis zu 1000 Tunnel terminieren und erreichen mit einer Beschleunigerkarte über 60 Mbit/s bei maximaler Verschlüsselungsstärke. Für das komplette Netzwerk gibt es in Breitscheid nur einen einzigen Übergang in das Internet, den alle Benutzer in den verschiedenen Standorten benutzen. Somit wird eine konsistente Sicherheitsstrategie ermöglicht.
397
12 Fallstudien
12.3 VPN-Dienste von Service Providern Eine grundsätzliche Alternative beim Aufbau eines VPN besteht darin, dies nicht in Eigenregie zu tun, sondern den VPN-Dienst eines Service Providers zu nutzen. Solche Dienste können in ihrer Struktur und dem Umfang des Angebots von Provider zu Provider recht unterschiedlich sein und reichen vom einfachen Internetzugang bis zum vollständigen Outsourcing des VPN. Generell kann der Kunde zwischen drei verschiedenen Alternativen wählen, die je nach Provider noch verschiedene Zwischenstufen haben können: 1. Der Kunde bekommt vom Service Provider nur einen Internetzugang bereitgestellt und schließt ein für seine VPN-Anforderungen ausreichendes Service Level Agreement (SLA) ab. 2. Der Kunde bekommt vom Service Provider ein Paket mit Internetzugang, VPN-Systemen und ein SLA inklusive Wartung und Betrieb aller Komponenten. Der Benutzer verwaltet jedoch den »privaten Teil« des VPN-Gateways, seine Benutzer und Profile selbst, ohne dass der Service Provider darauf Zugriff hat. 3. Der Kunde kauft einen Vollservice inklusive Benutzermanagement und aller Leistungen. Der Provider ist für den kompletten VPN-Betrieb verantwortlich. Die Abwägung, welches Modell am günstigsten ist, ist immer ein Kompromiss zwischen einer Reihe von Vor- und Nachteilen und richtet sich nicht selten auch nach strategischen Vorgaben des Unternehmens, inwieweit bestimmte Funktionen durch externe Dienstleister wahrgenommen werden sollen oder dürfen. Vorteile für den Kunden
Nachteile für den Kunden
Alternative 1
Keine langfristige Bindung an den Provider, ein Wechsel oder der Einsatz mehrerer Provider ist jederzeit möglich. Volle Kontrolle über das VPN.
Relativ hohe Kosten durch den erforderlichen Personalaufwand und die notwendigen Investitionen.
Alternative 2
Reduzierung der Kosten gegenüber Alternative 1, leicht verminderter Personalaufwand, keine Investitionen.
Längerfristige Bindung an einen Provider nötig. Meist keine Mitsprachemöglichkeit bei der Auswahl der eingesetzten Technologie.
Alternative 3
Niedrige Kosten, fast kein Personalaufwand mehr; keine Investitionen.
Sehr starke Abhängigkeit vom Provider und keine eigene Kontrolle über das VPN.
Tab. 12.2: Die wichtigsten Vor- und Nachteile der verschiedenen Alternativen
398
Studie 3: Die VIAG Interkom
Im folgenden Abschnitt sind, stellvertretend für diese Art von Service-Provider-Diensten und ohne jede Wertung, exemplarisch die VPN-Services der VIAG Interkom aufgeführt. Anhand dieser Aufstellung können Sie sowohl die verschiedenen Möglichkeiten abschätzen, die solche Dienste bieten, als auch sehen, wie die verschiedenen in diesem Buch besprochenen VPN- und Sicherheitstechnologien dafür eingesetzt werden. Um dem Entscheider und dem Netzwerkverwalter einen Überblick über die Möglichkeiten zu geben, die er mit den VPN-Diensten hat, sind diese recht detailliert dargestellt, damit Sie vor allem einen direkten Vergleich zu der Alternative haben, Ihr VPN ohne Mitwirkung eines Service Providers (Internetzugriff natürlich ausgenommen) aufzubauen und zu betreiben. Der technisch Interessierte bekommt zusätzlich einen Einblick in die Interna eines ISP und in den Einsatz der in der Regel nur dort verwendeten Provider-Enterprise- und Intra-Provider-Tunneling-Modelle unter Verwendung von L2TP und BayDVS. Andere Service Provider betreiben selbstverständlich andere Infrastrukturen und bieten auch andere oder unterschiedlich gebündelte Dienstleistungspakete an. Hier muss natürlich im Einzelfall geprüft werden, wie diese in das geplante VPN passen. Auf der anderen Seite ist dieser Markt auch einer sehr großen Dynamik unterworfen, und es werden laufend neue Dienste angeboten. Die sich ändernde Infrastruktur, insbesondere die in Zukunft fast flächendeckende Verfügbarkeit des High-Speed-Internet-Zugriffs über DSL oder andere Breitbandtechniken, bringt auch völlig neue Dienste und Unternehmen wie z.B. die Application Service Provider (ASPs) hervor, die vielleicht in ein VPN integriert werden sollen.
12.4 Studie 3: Die VIAG Interkom Als Beispiel für verschiedene komplette, durch Provider angebotene VPNLösungen, bietet sich die VIAG Interkom mit ihren verschiedenen VPNDiensten an, an denen sich der Einsatz der verschiedenen Tunneling-Technologien gut demonstrieren lässt. Das Unternehmen hat in Deutschland schon eine sehr lange Erfahrung im VPN-Bereich, was man unter anderem auch an der Palette der angebotenen Services ermessen kann. Um zu sehen, wie sich die Endkunden die angebotenen Dienste zunutze machen können, gebe ich Ihnen zuerst mal einen Überblick drüber was alles angeboten wird, um dann einige Beispiele für eine sinnvolle Nutzung und die eingesetzte VPN-Technik zu beschreiben.
12.4.1
Zum Unternehmen
VIAG Interkom (VI) bietet Telekommunikationsdienste in Deutschland an. Als Tochterunternehmen von British Telecom (BT) ist VI mit den drei Kernbereichen Mobile, Fixed Voice und Fixed Data auf dem deutschen Markt vertre-
399
12 Fallstudien
ten. VIAG Interkom betreibt hierzu eigene Mobil- Sprach- und Datennetze, welche dem neusten Stand der Technik entsprechen und ständig weiter ausgebaut werden; eine UTMS-Lizenz wurde ebenfalls ersteigert. An Datennetzen betreibt VI eigene Frame-Relay-, ATM-, Internet- und DialAccess-IP-Strukturen. Durch die Verbindung mit British Telecom ergeben sich hierbei viele Synergieeffekte aufgrund der weltweiten Nutzungsmöglichkeit der BT- und Concert-Datennetze.
12.4.2
Der IP-VPN-Dienst
Das Produkt IP-VPN der VIAG Interkom wird seit Anfang 2000 erfolgreich am deutschen Markt angeboten. Es beinhaltet die Möglichkeit Daten über das Internet mittels der Tunneling-Protokolle 왘 BayDVS (Bay Dial-In VPN-Service) 왘 L2TP (Layer 2 Tunneling Protocol) 왘 IPSec (IP Security)
zu übertragen, wobei lediglich IPSec als sicheres Übertragungsprotokoll angesehen und vermarktet wird. Mit diesen Protokollen und den darauf aufbauenden Diensten können praktisch alle Spielarten heutiger IP-VPNs realisiert werden. IP Security IPSec wird von VIAG Interkom wahlweise mit DES-Verschlüsselung (56 Bit Schlüssellänge) oder Triple-DES-Verschlüsselung (168 Bit Schlüssellänge) angeboten und deckt damit auch hohe Anforderungen hinsichtlich Vertraulichkeit, Authenzität und Integrität der übertragenen Daten ab. Internationale Verbindungen Durch die Nähe zur British Telecom ist es möglich, den IP-VPN-Dienst international auszurichten. Dies umfasst bereits heute den Anschluss von im Ausland befindlichen Standorten durch Festverbindungen. VI betreibt in Deutschland einen eigenen Internet-Backbone, der über entsprechende Peering-Punkte zu anderen Netzbetreibern verfügt und ständig erweitert und ausgebaut wird, um den aktuellen Bedürfnissen gerecht zu werden. Somit kann auch über andere Provider oder einen Anschluss an das Frame-RelayNetz der VIAG Interkom Zugang ihrem IP-Backbone erfolgen. Authentifizierung der Einwählverbindungen Die Einwählverbindungen in die POPs der VIAG Interkom werden mit Hilfe des PPP-Protokolls authentifiziert.
400
Studie 3: Die VIAG Interkom
Hierzu verwendet VI intern das RADIUS-Protokoll. Hierbei wird die Anfrage zuerst zu einem so genannten Frontend-RADIUS-Server geleitet, der den Authentication Request in unterschiedliche Dienste einteilt und ihn anschließend an den VI-VPN-Radius weiterleitet. Dieser ist nun für die Authentifizierung der Benutzer und gegebenenfalls die Zuweisung von Tunneling-Attributen für L2TP oder BayDVS zuständig. Auf Wunsch des Kunden kann dieser einen eigenen RADIUS Service zur User-Authentisierung verwenden. In diesem Fall wird die Anfrage zur Benutzer-Authentifizierung an den RADIUS-Server des Kunden durch einen Tunnel ins Kundennetz geleitet. Somit kann der Kunde seine Benutzer vollständig selbst verwalten. IPSec Authentifizierung Zur Authentifizierung der beiden Gegenstellen einer IPSec-Sicherheitsassoziation verwendet VI derzeit das Pre-Shared-Key-Verfahren. Für den Anwender bedeutet dies im Fall eines Remote-Access-VPNs eine Authentifizierung mit User-ID und Passwort. Optional ist auch eine Authentifizierung mit Tokenkarten möglich, die eingesetzte Clientsoftware unterstützt diese Verfahren. Zugänge VIAG Interkom bietet für ihren IP-VPN-Dienst eine Reihe verschiedener Zugänge an, die von der Art und der benötigten Bandbreite abhängen: 왘 L2TP Dial Access (ISDN und Analog) für Client PCs und Dial-in-Router 왘 IPSec Dial Access (ISDN und Analog) für Client PCs und Dial-in-Router 왘 Leased-Line-Anschluss über Internet von 64 kBit/s bis 34 Mbit/s (E3) 왘 Leased-Line-Anschluss über Frame Relay mit bis zu 512 kBit/s
Hardware Um für die Hardwarewünsche der Kunden offen zu sein, werden bei VIAG Interkom Systeme der beiden Marktführer im Router- und VPN-Bereich, den Firmen Nortel Networks und Cisco Systems, angeboten. Dies umfasst das sogenannte CPE-Equipment (CPE, Customer Premise Equipment, Systeme, die beim Endkunden installiert, aber vom Provider betrieben werden), also die IPSec-Clientsoftware, kleinere Router für Fest- oder Wählverbindungen und die VPN-Gateways. Die von VIAG Interkom eingesetzten VPN-Gateways sind sehr gut skalierbar und unterstützten je nach eingesetztem Modell bis zu 5000 parallele Tunnel
401
12 Fallstudien
pro Gerät. Sie erreichen dabei Durchsatzraten von über 70 Mbit/s mit TripleDES Verschlüsselung. Installation und Inbetriebnahme Wird bei einem Kunden neues Equipment installiert, so greift VIAG Interkom auf die Dienste externer IT-Dienstleister zurück. Diese Service-Unternehmen sind für den Aufbau und den Anschluss der Geräte in den Kundenstandorten zuständig. Des weiteren stellen sie eine gesicherte IPSec-Verbindung zu Customer Service Center der VI her. Von dort aus erfolgt dann zentral die weitere Systemkonfiguration und Einrichtung der Sicherheitsdienste sowie die endgültige, produktive Inbetriebnahme. Redundanz Da viele Kunden ein hoch verfügbares Netzwerkdesign haben möchten, sind alle Netzelemente der VIAG Interkom redundant ausgelegt, oder können auf Wunsch des Kunden für ihn redundant eingerichtet werden. Eine Redundanz ist im Sprachnetz, dem NAS und dem VI-Backbone generell vorhanden. Um den Ausfall einer Festverbindung (Leased Line) oder eines VPN-Gateways beim Kunden entgegenzuwirken, besteht die Möglichkeit auch diese Systeme doppelt auszulegen. Die zweifach vorhandenen Systeme können entweder im so genannten Hot-Standby-Modus (sofortige Funktionsübernahme durch ein im »Wartezustand« befindliches System), oder auf Wunsch auch im so genannten Load-Sharing-Modus verwendet werden, bei dem sich beide Systeme im Normalbetrieb die Netzlast gleichmäßig untereinander aufteilen. Monitoring VIAG Interkom bietet seinen Kunden die Möglichkeit, den VPN-Dienst mit unterschiedlichen Optionen zu kaufen. Unterteilt werden diese Dienste in: 왘 Bundled Service 왘 Semibundled Service 왘 Unbundled Service
Die erste Variante, der Bundled Service, erfreut sich bei den Kunden einer hohen Beliebtheit und wird derzeit fast ausschließlich verkauft. Bundled Service bedeutet, dass die gesamte Infrastruktur (CPE, VI-Backbone, VPN-Gateways usw.) seitens VIAG Interkom zur Verfügung gestellt, konfiguriert und überwacht wird. Der Kunde muss sich hierbei, außer dem Einrichten seiner eventuell vorhandenen PC-Clients und seiner Benutzer um nichts kümmern. Bei Erweiterungen seines Netzes oder bei eventuell auftretenden Problemen hat der Kunde nur noch einzigen Ansprechpartner.
402
Studie 3: Die VIAG Interkom
Beim Semibundled Service ist all dies ebenso, jedoch betreibt der Kunde in der Regel sein eigenes CPE Equipment, für das er dann allerdings auch selbst verantwortlich ist. Auch die Konfiguration dieser Geräte erfolgt durch den Kunden selbst, allerdings nach technischen Anweisungen von VI. Bei dem Unbundled Service nutzt der Kunde lediglich die Internet-Accessund Internet-Struktur der VIAG Interkom. Berechnet werden die Dienste mit einer monatlichen Pauschale für Bereitstellung der Geräte, dem so genannten Monitoring, also der Überwachung des Netzverkehrs hinsichtlich Performance und Fehlern, sowie einem volumenbasierten Anteil. Verfügbarkeit Der VIAG Interkom IP-VPN Dienst wartet mit einer Verfügbarkeit von 99,97% auf, was einer maximalen Ausfallzeit von ein klein wenig mehr als 2,5 Stunden pro Jahr entspricht. Dies gilt natürlich nur für Verkehr innerhalb der Infrastruktur von VI, da nur hier die entsprechenden Systeme eingesetzt und geeignete Maßnahmen getroffen werden können. Sollte dennoch in den Standorten der Kunden an einem VPN- oder AccessSystem ein Hardwaredefekt derart auftreten, dass es ausgetauscht werden muss, dann wird das defekte Gerät durch einen IT-Dienstleister, der über die geeignete Logistik verfügt, innerhalb kurzer Zeit ausgetauscht. Das BCCC (Business Customer Care Center) der VIAG Interkom, das zentral die letzte gültige Konfiguration aller System vorrätig hält, spielt nach dem Austausch des defekten Geräts die letzte Sicherung des betroffen Systems wieder ein. Anschlussvarianten Um die Außenstellen von Firmen anzuschließen, gibt es die Möglichkeit diese per Wähl- oder Festverbindung anzuschließen. In beiden Fällen wird man, da sich in der Außenstelle in der Regel ein kleineres, privates Netz mit nicht registrierten oder sich überschneidenden Adressen verbirgt, NAT (Network Address Translation) verwenden. Die Anschlussbandbreiten fangen hierbei bei einer 64kBit/s Wählverbindung (ISDN) an, und enden bei einem 34 Mbit/s (E3) Anschluß. Des weiteren besteht die Möglichkeit, sich als Außendienstmitarbeiter per ISDN oder analoger Einwahl in das Firmennetz einzuwählen. Da die meisten Kunden neben dem IP-VPN-Dienst auch noch den Dienst IPTransport, also den klassischen Internetzugang kaufen, erfolgt der Anschluss an das Firmennetz über zwei Verbindungen. Das VPN-Gateway übernimmt den Zugang von und zu den Firmenaußenstellen, den Außendienstmitarbeitern und den Benutzern an Heimarbeitsplätzen. Als zweites gibt es eine Verbindung vom Internet in das Firmennetz, über die ein Unternehmen mit der Außenwelt kommuniziert. Die Aufteilung der beiden Leitungen wird durch einen Gateway-Router durchgeführt, der auf seiner anderen Seite die Verbindung zum VI-Netz aufrecht erhält. 403
12 Fallstudien
Selbstverständlich besteht auch die Möglichkeit, zwei per Festverbindung mit dem VI-Backbone verbundene, Firmennetze über VPN-Gateways durch einem IPSec-Tunnel zu verbinden. Die hierbei möglichen Datenraten beginnen bei 64 kBit/s und enden bei einer E3-Verbindung (34 Mbit/s).
12.4.3
Infrastruktur
VIAG Interkom betreibt sowohl eigene Fest- als auch Mobilfunknetze. Den Internet-Backbone, der in Deutschland betrieben wird, sehen Sie in der Abbildung 12.4 skizziert. Alle Knoten sind mindestens zweifach redundant verbunden. Die ständig angepassten Geschwindigkeiten betragen dabei auf den Links 155 Mbit/s, auf einigen wenigen 45 Mbit/s. Natürlich gibt es auch Übergänge zu anderen Providern und NAPs (Network Access Point) in den USA, Europa und Deutschland. In Frankfurt (DECIX) und München (INXS) sind die deutschen Internetübergänge installiert. Hamburg Bremen Berlin Hannover Essen
Level 3
Düsseldorf
Leipzig
Frankfurt DECIX
AT&T New York
Köln LINX London
Frankfurt
Mannheim
Concert
Nürnberg Karlsruhe 155 Mbit/s
Stuttgart
München INXS
45 Mbit/s Interconnect
München
Abbildung 12.4: Der deutsche Internet Backbone der VIAG Interkom, Stand 12/2000
404
Studie 3: Die VIAG Interkom
12.4.4
Remote-Access-VPN
Je nachdem was dem Kunden vorschwebt, kann er aus einer Reihe verschiedener Remote-Access-VPN-Lösungen wählen, oder diese auch miteinander kombinieren. So bietet VIAG Interkom folgende drei verschiedenen Technologien an: Bay-DVS Bay-DVS ist eine herstellerspezifische Kombination von Mobile IP, Generic Routing Encapsulation (GRE) und RADIUS der Firma Nortel Networks. Der Name Bay-DVS (Bay Dial In VPN Service) stammt noch von dem IP-Spezialisten Bay Networks, der von Nortel Networks übernommen wurde. Das Protokoll ist ein Layer-3-Tunneling-Protokoll, dass sowohl IP als auch IPX tunneln kann. Es erfreut sich vor allem bei Service Providern und Carriern großer Beliebtheit. Der große Vorteil für den Kunden besteht darin, dass er keinerlei spezielle VPN-Hard- oder Software kaufen, mieten oder installieren muss. In Abbildung 12.5 sehen Sie wie dieses Protokoll arbeitet. Die Remote-Access-ClientSysteme bauen mit einem Standard-PPP-Dialer eine Wählverbindung zu einem POP (Point of Presence) der VIAG Interkom auf. Dabei benutzen sie eine zweiteilige User-ID mit einem sogenannten Domain-Suffix, z.B. »
[email protected]«. Aufgrund des Suffix erkennt der Remote-Access-Konzentrator dass er einen Tunnel zum Bay-DVS-Gateway aufbauen muss. In diesem Gateway wird der Tunnel auf einen Frame-Relay-PVC »gemappt«, der zum Access-Router des Kunden führt. Die Authentifizierung der Benutzer erfolgt im Kundennetzwerk mit einem RADIUS-Server, der RADIUS-Client residiert im Bay-DVS-Gateway. L2TP Dies ist beim L2TP-Verfahren nicht so, hier müssen der Access-Router oder das VPN-Gateway beim Kunden für dieses Protokoll ausgelegt sein. Es muss also mindestens die entsprechende Software, der L2TP Network Server (LNS), installiert werden. Auf den Einwähl-Clients braucht aber auch hier keine besondere Software installiert zu werden. Das Tunneling erfolgt, wie Sie in Abbildung 12.5 sehen können, analog zu Bay-DVS, allerdings wird der L2TP-Tunnel bis in das Kundennetzwerk geführt. Die Authentifizierung der Benutzer erfolgt meist im Kundennetzwerk mit einem RADIUS-Server.
405
12 Fallstudien
VIAG InterkomNetz
L2TPLNS KundenIntranet
Bay-DVS Gateway KundenFrame Intranet Relay
VPNGateway
L2TPTunnel
Bay-DVS-Tunnel
ISDN PSTN
VIAG Interkom Business Customer Care Center (BCCC)
Control Tunnel
PPPClient
PPPClient
POPs
Virtuelle Verbindung (Tunnel)
Abbildung 12.5: Die Layer-2- und Layer-3-VPN-Dienste der VIAG Interkom mit L2TP und Bay-DVS
IPSec Das IPSec-Protokoll eignet sich auch sehr gut für den Remote-Access. Hier kommt der Anwender, im Gegensatz zu L2TP und Bay-DVS, in den Genuss einer sehr viel höheren Sicherheit. Hier sind jedoch sowohl auf den RemoteAccess-Clients als auch auf dem VPN-Gateway IPSec-Implementierungen vonnöten.
Üblicherweise wird der Tunnel bereits im Endgerät initiert, es wird also zu diesem Zeitpunkz bereits eine IP-Verbindung zwischen dem Remote-AccessSystem und dem IPSec-Gateway vorausgesetzt. Gute IPSec-Clients bieten die Möglichkeit, automatisch die entsprechenden Verbindung zu einem geeigneten POP aufzubauen.
12.4.5
Branch-to-Branch-VPN
Ein weiterer IP-VPN-Dienste ist die Möglichkeit, verschiedene Standorte über das Internet miteinander zu verbinden. Als Tunneling-Protokoll setzt man üblicherweise das IP-Security-Protokoll (IPSec) ein um eine sichere Übertragung zu gewährleisten.
406
Studie 3: Die VIAG Interkom
IPSecKonzentrator KundenIntranet
VIAG InterkomNetz
IPSecKonzentrator KundenIntranet
IPSec Gateway
ISDN PSTN
VIAG Interkom Business Customer Care Center (BCCC)
Control Tunnel
POPs
IPSecClient
IPSecClient
Virtuelle Verbindung (Tunnel)
Abbildung 12.6: VIAG Interkom bietet sichere Remote-Access-VPN-Dienste auf Basis des IPSec-Protokolls an
Die Verbindungen zum Internet-Backbone der VIAG Interkom können mit verschieden schnellen Verbindungen aufgebaut werden, die mit ISDN-Wählverbindungen und 64-Kbit/s-Festverbindungen beginnen und bei E3-Verbindungen (34 Mbit/s) enden. Wählt der Kunde einen Bundled Service, so erfolgt, wie Sie in Abbildung 12.7 sehen, auch die Wartung und Konfiguration zentral vom Business Customer Care Center über spezielle Management-Tunnel. Diese Tunnel sind IPSec-Tunnel, die aufgrund eines vordefinierten, festcodierten Filters nur auf die Management-Adresse des VPN-Gateways zugreifen können. Somit besteht keine Zugriffsmöglichkeit in das Netzwerk des Kunden. Die Konfigurationen und Einstellungen können zentral im BCCC vorgehalten werden um beim Austausch eines Systems sofort wieder den alten Zustand herstellen zu können.
407
12 Fallstudien
VPN Gateway KundenIntranet
VIAG InterkomNetz
VPN Gateway KundenIntranet
VPN Gateway
VPN Gateway
KundenIntranet
Internet
VIAG Interkom Business Customer Care Center (BCCC)
Control Tunnel
Virtuelle Verbindung (Tunnel)
Abbildung 12.7: Auch beim Branch-Office-VPN-Dienst setzt man bei VI aus Sicherheitsgründen IP Security (IPSec) ein
408
Anhang Weiterführende Literatur Im Folgenden finden Sie eine nach Themen geordnete Reihe empfehlenswerter weiterführender Bücher zu verschiedenen, in diesem Buch behandelten Themen. Frame Relay Smith, Philip: Frame Relay. Principles and Applications. Addison-Wesley 1993, ISBN 0-201-62400-1. ATM Wilde, Alexander: SDH in der Praxis. VDE Verlag 1999, ISBN 3-8007-2446-4. DSL Ginsburg, David: Implementing ADSL. Addison-Wesley 1999, ISBN 0-201-65760-0 Starr, Thomas u.a.: xDSL: Eine Einführung. ISDN, HDSL, ADSL und VDSL. Addison-Wesley Verlag 2000. ISBN 3-8273-1574-3. IP Version 6 Huitema, Christian: Ipv6. Architektur und Implementierung. Addison-Wesley Verlag 2000. ISBN 3-8273-420-8. Quality-of-Service, Class-of-Service Huston, Geoff: Internet Performance Survival Guide. QoS Strategies for Multiservice Networks. Wiley & Sons 2000, ISBN 0-471-37808-9. Black, Daryl P.: Building Switched Networks. Multilayer Switching, QoS, IP Multicast, Network Policy and Service Level Agreements. Addison-Wesley 1999, ISBN 0-2013-7953-8 Kryptographie Schneier, Bruce: Angewandte Kryptographie. Protokolle, Algorithmen und Sourcecode in C. Addison-Wesley Verlag 1996, ISBN 3-89319-854-7. Wobst, Reinhard: Abenteuer Kryptologie. Methoden, Risiken und Nutzen der Datenverschlüsselung. 3. Aufl. Addison-Wesley Verlag 2001, ISBN 3-8273-1815-7.
409
Anhang
Ihringer, Thomas: Diskrete Mathematik. Teubner Verlag 1999, ISBN 3-519-12125-5. Datensicherheit Pflegerer, Charles P.: Security in Computing. Prentice Hall 1997, ISBN 0-13-337486-6. Strobel, Stefan: Firewalls für das Netz der Netze. Sicherheit im Internet, Einführung und Praxis. dpunkt Verlag 1997, ISBN 3-920993-31-4. Netzwerksicherheit Stallings, William: Sicherheit im Internet. Anwendungen und Standards. Addison-Wesley Verlag 2001, ISBN 3-8273-1697-9. Kaufman, Charlie, Radia Perlman, Mike Speciner: Network Security. Private Communication in a Public World. Prentice Hall 1995, ISBN 0-13-061466-1. IPSec Doraswamy, Naganand, Dan Harkins: IPSec. Der neue Sicherheitsstandard für das Internet, Intranet und virtuelle private Netze. Addison-Wesley Verlag 2000, ISBN 3-8273-1634-0. Lee, Thomas: Microsoft Windows 2000 TCP/IP Protocols and Services Technical Reference. Kapitel 20 und 21. Microsoft Press Verlag 2000, ISBN 0-7356-0556-4. L2TP Shea, Richard: L2TP. Implementation and Operation. Addison-Wesley 2000, ISBN 0-201-60448-5. PPP Carlson, James D.: PPP. Design and Debugging. Addison-Wesley 1998, ISBN 0-201-18539-3. Digitale Signaturen, Zertifikate, PKI Bitzer, Frank, Klaus M. Brisch: Digitale Signatur. Grundlagen, Funktion und Einsatz. Springer-Verlag 1999, ISBN 3-540-65563-8. Warwick, Ford, Michael S. Baum: Secure Electronic Commerce. Building the InfraStructure for Digital Signatures and Encryption. Prentice Hall 1997, ISBN 0-13-476342-4.
410
Links
Links Die folgenden Links bieten Zugriff auf die im VPN-Bereich wichtigsten Organisationen. Die Links wurden im Januar 2001 geprüft. ICSA Labs URL: http://www.icsalabs.com Die ICSA Labs haben sich unter anderem die Zertifizierung von IPSec-Implementierungen zu einer ihrer Hauptaufgaben gemacht. Hier finden Sie auch weitere Informationen zum Thema Sicherheit, Firewalls und PKI. Virtual Private Network Consortium (VPNC ) URL: http://www.vpnc.org Das Virtual Private Network Consortium (VPNC) ist ein Konsortium, in dem sich der größte Teil aller namhaften VPN-Hersteller zusammengeschlossen hat. Auf den Webseiten des VPNC finden Sie viele Informationen, White Papers und vor allem ein umfassendes Herstellerverzeichnis. Internet Engineering Task Force URL: http://www.ietf.org/html.charters/wg-dir.html IETF IP Security Working Group URL: http://www.ietf.org/html.charters/ipsec-charter.html IETF IP Security Remote Access Working Group URL: http://www.ietf.org/html.charters/ipsra-charter.html IETF Public Key Infrastructure X.509 Working Group (PKIX) URL: http://www.ietf.org/html.charters/pkix-charter.html IETF Differentiated Services Working Group (PKIX) URL: http://www.ietf.org/html.charters/diffserv-charter.html IETF L2TP Extensions Working Group (PKIX) URL: http://www.ietf.org/html.charters/l2tpext-charter.html
411
Stichwortverzeichnis A Access Link 52 Accounting 79, 382 ACT 227 Adaptive-Chosen-PlaintextAngriff 101 Adleman, Leonard 131 Adressmanagement 83 Advanced Encryption Standard 124, 325
Advanced Research Projects Agency 31 AES 124, 325 Geschwindigkeit 127 Hardwareimplementierung 126 Optimierung 128 Smartcards 127 Softwareimplementierung 126 Anti-Clogging-Token 227 ARPA 31 ARS 194 Asynchronous Transfer Mode 22 ATM 22 Service-Klassen 67 Zellen 23 Authentication Header 206 Authentifizierung 80, 145 Benutzer 146 Besitzbasierende 147 Biometrische 148 Kombinationsverfahren 147 Passthrough 159 Schwache 146 Starke 146 Wissensbasierte 146 Authentifizierung-Verfahren 146 B BayDVS 171 Benutzer-Authentifizierung 56, 95 Benutzer-Autorisierung 56
Best-Effort 63 Betriebssicherheit 58 Branch-Office-VPN 328 Brute-Force-Angriff 99, 109, 324 C CA 164 Call Admission Priority 381 CBC 122, 191 CCP 280, 282 Cell Switching 23 Certificate Authority 164 Certificate Revocation List 166 Challenge Handshake Authentication Protocol 155, 280–281 CHAP 155, 280–281, 302 Chiffriermaschinen 97 Chipkarten 147, 160, 339 Chosen-Plaintext-Angriff 101 Cipher Block Chaining 122 Ciphertext Only Angriff 99 CIR 68 Class of Service 66 Collision Domain 48 Commited Information Rate 68 Compression Control Protocol 280, 282 Compulsory Tunneling 178 Configuration Log 382 Cookies 227 CoS 66 CRL 166 D Data Encryption Standard 93, 114 Datenintegrität 55 Datenvertraulichkeit 53, 91 DDoS 57 Decapsulation 170 Dedizierte VPN-Systeme 362 Delay 63 Denial-of-Service 57
413
Stichwortverzeichnis
Denial-of-Service-Angriff 190 Dense Wave Division Multiplexing 33 DES 114, 324 Algorithmus 116 Entschlüsselung 120 Funktion 118 S-Boxen 118 Schlüsseltransformation 117 Teilschlüssel 118 Triple-DES 120 Verschlüsselung 117 DHCP 83 DHCP-Server 83 Dial-On-Demand-Routing 326 Diffentiated Services Code Point 69 Differentiated Services 69, 345 Differentielle Kryptoanalyse 101 Diffie, Whitfield 130 Diffie-Hellman 225, 324 Diffie-Hellman-Merkle-Verfahren 130 Diffie-Hellman-Verfahren 136 DiffServ 69, 345 DiffServ-Service-Klassen 71 Diffusion 101 Digitale Signaturen 150 Digitale Zertifikate 82, 150, 339, 351 Directory Services 84, 160 Direkte Vertrauensbeziehungen 162 Distributed DoS 57 DNS (Domain Name System) 83 DoS 57 DSCP 69 DSL 34, 331 DWDM 33 Dynamic Host Configuration Protocol 83 E ECHELON 96 Edge-Router (DiffServ) 70 Einmal-Code 148 EIR 68 Elektronische Signatur 168 Encapsulating-Security-Payload 209 Encapsulation 169 Ende-zu-Ende-Modell 172 Enigma 97
414
Ethernet 48 Header 50 Eulersche Totientenfunktion 136 EU-Signaturrichtlinie 168 Excess Information Rate 68 Exklusiv-Oder-Verknüpfung 106 Extranet 350 F Falltür-Funktion 130, 132 Federal Information Processing Standard Publication 114 Feistel-Netzwerke 106, 117 Feistel-Zyklus 106 Fermats Theorem 136 FIPS-Pub 114 Firewalls 43, 56, 81, 346 Fortgeschrittene elektronische Signatur 168 Frame Relay 21 G Gefahrenanalyse 88 Generic Routing Encapsulation 176 GRE 176 H Hash-based Message Authentication Code 143, 189 Hashfunktionen 141 HDLC 278 Hellman, Martin 130 Hintertür-Funktion 130 HMAC 143, 189 HMAC-MD5-96 193 HMAC-SHA1-96 193 HTTP 78 Hybrid Link 52 Hyper Text Transfer Protocol 78 I ICSA 85 IETF 33 IKE 221, 244, 324 Aggressive Mode 245, 265 Authentifizierung 254 Hardware-Bescheuniger 273
Stichwortverzeichnis
Main Mode 245, 256 New Group Mode 244 Performance 272, 374 Quick Mode 244, 269 Schlüsselerzeugung 251 Indirekte Vertrauensbeziehungen 152, 162
Initialisierungsvektor 123 Initiator 228 Integrated Services Digital Network 20 Interface-Sicherheit 58 Internet 30 Backbone 30 Verfügbarkeit 34 Internet Engineering Task Force 33 Internet Key Exchange 221 Internet Key Exchange Protokoll 244 Internet Security Asscociation and Key Management Protocol 222 Internet Service Provider 33, 352 Interoperabilität 85 Intra-Provider-Modell 170 Inverse Elemente 136 IP Class of Service 31 CoS 31 Protokoll 31 TCP/IP 31 Version 6 187 VPN 24 IP Control Protocol 280, 282 IP Security 93 IP Security Protokoll 187 IPCP 282 IPSec 176, 187, 326 Adressmanagement 332 Anti Replay Service 194 Anti Replay Window 201 Architektur 196 Attribute 245 Authentication Header 206 Authentifizierung 193 Authenzität 93 Client 177 Datenintegrität 93 Datenverschlüsselung 93, 191
Denial-of-Service-Angriff 94 Encapsulating Security Payload 209 Hardwarebeschleuniger 217 Implementierungen 214 Integritätsprüfung 193 Komprimierung 217 Lifetime 201 Mode 201 Paketauthentifizierung 189 Paketintegrität 188 Paketverarbeitung 205 Paketvertraulichkeit 189 Performance 215 PMTU Parameters 201 Routing 329 SAD 199 Schlüsselmanagement 94 Security Association Database 199 Security Parameter Index 200 Security Poilcy 201 Security Policy Database 202 Selektoren 202 Sequence Number 201 Sequence Number Overflow 201 Sicherheitsassoziation (SA) 199 SPD 202 SPI 200 Standardisierung 196 Standards (RFCs) 197 Transportmodus 203 Tunnel Destination 201 Tunnelmodus 203 Verkehrsflussvertraulichkeit 189 Zukunft 219 IPSec Domain of Interpretation 222 IPSec secured L2TP 305 IPSec-DOI 222 IP-VPN-Service 360 ISAKMP 222 Aggressive Exchange 242 Austauschvorgänge 241 Authentication Method 248 Authentication Only Exchange 242 Authentifizierung 224 Base Exchange 242
415
Stichwortverzeichnis
Certificate Payload 235 Certificate Request Payload 236 Cookie 228 Delete Payload 239 Denial-of-Service-Angriff 226 Encryption Algorithm 248 Field Size 247, 250 Group Attributes 249 Group Order 247, 250 Hash Algorithm 248 Hash Payload 237 Header 228 Identification Payload 235 Identity Protection Exchange 242 Informational Exchange 243 Key Exchange Payload 234 Key Length 247, 250 Man-in-th-Middle-Angriff 227 Nonce Payload 237 Notification Payload 238 Nutzdaten-Header 231 Phase 1 241 Phase 2 241 Phasen 241 Pre-Shared Secret 224 PRF 247, 250 Proposal Payload 233 SA Life Duration 247, 250 SA Life Type 249 SA Payload 232 Schlüsseltausch 225 Sicherheit 223 Sicherheitsassoziationen 222 Signature Payload 237 Transform Payload 233 Vendor ID Payload 240 ISDN 20 ISDN-Router 341 ISP 33 Ist-Aufnahme Technische Sicht 312
416
J Jitter 63 K Kennwort 146 Keyed Hashing 143 Klassifizierer 72 Known Plaintext Angriff 99 Kollision 141 Konfiguration 76 Konfusion 101 Kryptoanalyse 95, 99 Kryptographie 95, 101 Kryptologie 95 L L2F 180 L2TP 178, 277 Access Concentrator 285 Attribute Value Pairs 295 AVP 295 AVP-Verschlüsselung 297 Benutzerauthentifizierung 300 Benutzernamen 287 Call 286 Compulsory Tunneling 292 Control Connection 286 Datenpakete 293 DNIS 288 LAC 285, 289 LNS 285, 289 Network Server 285 Performance 289 PPP-Tunneling 284 Sicherheit 303 Steuerungspakete 293 Tunnel 286 Tunnelaufbau 298 Tunnelauthentifizierung 304 Tunneling-Modelle 292 Virtueller LAC 293 Virtueller Remote Access 285
Stichwortverzeichnis
Voluntary Tunneling 292 L2TP/IPSec 305–306 LADP 160 LAN 48 Switching 48 V-LAN 48 Lastverteilung 383 Lauschangriff 45 Lawineneffekt (Permutation) 105 Layer 2 Forwarding 180 Layer 2 Tunneling Protocol 178, 277 Layer-2-Tunneling 172 Layer-3-Tunneling 173 LCP 280 LCP Re-Negotiation 301 LDAP 84, 335 Lightweight Directory Access Protocol 84, 160, 335 Link Control Protocol 280 Lucifer-Chiffre 106, 115 LZS 282 M Management 76 Management Information Base 76 Massachusettes Institute of Technolgy 131 MD5 142 Mean Time Between Failure 373 MEM 34 Merkle,Ralph 130 Message Digest 5 142 MIB 76 MIB-Variablen 78 Micro Electronic Mirror 34 Microsoft Point-to-Point Encryption 180 Migrationsfähigkeit 75 Migrationsphase 82 MIT 131 Modulare Arithmetik 133 Modulo primitiv 133 MPLS 174 Label Distribution Protocol 175 Label Edge Router 175 Label Switching Router 175
MPLS-Router 174 MPPC 282 MPPE 180 MS-CHAPv2 180 MTBF 373 Multi Protokoll Label Switching 174 N NAT 83, 187, 341, 382 National Bureau of Standards 114 National Institute of Standards and Technology 115 National Security Agency 96, 114 NBS 114 Network Address Translation 83, 187, 341
Network Time Protocol 383 NIST 115, 124 NSA 96 NTP 383 O Oakley 243 Oakley Key Determination Protocol 243 Oakley-Gruppe 2 – 5 244 Oakley-Gruppe-1 243 Öffentlicher Schlüssel 111, 150–151 One-Time-Token 148 OSPF 384 Out-of-Band-Zugriff 335 P Padding 113 Paket-Authentifizierung 55 PAP 155, 281 Password Authentication Protocol 155, 280–281
Passwort 146 P-Box 105 Per Hop Behaviour 69 Perfect Forwarding Secrecy 245 Performance ATM 62 Frame Relay 62 IP-VPN 62 Standard-Festverbindungen 61
417
Stichwortverzeichnis
Wählverbindungen 61 Permanent Virtual Circuit 21 Permutation 104 Expansion 105 Kompression 105 Persönliche IdentifikationsNummer 147 PFS 245 PHB 69 PHB-Router 72 Physische Sicherheit 58 PIN 147 PKI 81, 162, 335 PKIX 339 Point of Presence 41 Point-to-Point Protocol 277 Point-to-Point Tunneling Protocol 180 Policy-Server 73 POP 41 PPP 155, 277 PPTP 180 Pre-Shared Secret 352 Primärmultiplexanschluß 37 Primzahlen 132 Erzeugung 132 Häufigkeit 132 Privater Schlüssel 111, 151 Provider-Enterprise-Modell 171 Pseudo-Zufallszahlen 140 Public Key Infrastrcture 162 Public Key Infrastructure X.509 339 Public-Key-Infrastruktur 81 Public-Key-Kryptographie 129, 131 Public-Key-Verfahren 323 PVC 21 Q QoS 62, 327 ATM 67 Frame Relay 68 IP-Protokoll 69 IP-VPN 74 Standard-Festverbindungen 67 Wählverbindungen 66 Qualität Flussbasierend 65
418
Klassenbasierend 66 Vorherbestimmbar 65 Qualitätsparameter 63 Quality of Service 62 R Rabin-Miller Algorithmus 133 RAC 37, 278 RADIUS 79, 157 Random Function 140 Registration Authority 164 Relativ prim 133 Remote Access 278 Remote Access Concentrator 37, 278 Remote Authentication Dial In User Service 157 Remote-Access Kostenvergleich 25 Remote-Access-VPN 328 Replay Attack 190, 194 Request for Comment 31 Responder 228 Ressource Reservation Protocol 66 RFC 31 Rijndael 128, 325 RIP 384 Rivest, Ronald 131 RND 140 Rollout 340 Rotormaschinen 97 RSA 131, 226, 323 RSA-Verfahren 138 RSVP 66, 345 S S2M 37 SA Authentication Algorithm 246–247 SA Life Duration 246 SA Life Type 246 S-Box 103 Schlüsselmanagement 54, 150–151 Secure Hash Algorithm 143 SecurID 339 Security Log 382 Security Policy 80 Service Level Agreement 30
Stichwortverzeichnis
Service Level Agreements 353 Service Provider 352 SHA 143 Shamir, Adi 131 Shaper 72 Sicherheit Analyse 88 Netzwerkschicht 93 Unternehmensdatennetze 87 VPN 87 Sicherheitsstrategie 80, 322, 346 Sicherheitstechnologie 87 SigG 167 Signaturgesetz 167 Simple Network Management Protocol 76 Skalierbarkeit 75 SLA 30, 353 Backbone-Verfügbarkeit 353 Bandbreite 354 Compulsory Tunneling 356 Dial-In Firewall 356 Dial-In QoS 356 Einwählverfügbarkeit 353 Ende-zu-Ende-Verfügbarkeit 354 Installationszeiten 355 Maximale Fehlerrate 354 Paketblockierung 355 Paketverzögerung 354 QoS-Klassen 355 Reparaturzeiten 354 Verfügbarkeit 353 Vertragsstrafen 355 Small Office Home Office 341 SNMP 76 SNMP-Trap 382 SOHO 341 Spaltentransposition 104 Split-Management 45 Split-Tunneling 338 SSL 77 Startup-Unternehmen 28 Stateful Packet Inspection 348 Substitution 102 Monoalphabetisch 102 Nichtlinear 103
Polyalphabetisch 102 SVC 21 Switched Virtual Circuit 21 Symmetrischen Verfahren 323 System Log 382 T TMS 299 Token-Karten 147–148, 339 TOS 69 Transposition 104 Trap 76, 382 Trap door function 130, 132 Triple-DES 120, 324 Trunk 52 Trust-Center 167 Tunneling 169 Tunneling-Modelle 170 Tunneling-Protokolle 169, 172, 326, 376 Tunnel-Management-System 299 Tunnelswitching 382 Type-of-Service-Byte 69 U Überwachung (Management) 78 V Verfügbarkeit 59 Verkehrsbeziehungen 313 Verkehrsprofil 313 Verschleierung 97 Verschlüsselung 92, 97 Asymmetrische 111 Datenblock 113 Datenstrom 113 Public Key 109 Secret Key 109 Symmetrische 109 Verfahren 108 Verschlüsselungsverfahren Asymmetrische 129 Symmetrische 113 Vertrauensbeziehungen 150–151 Vertrauensmodelle 162 Verzeichnisdienst 160 Verzeichnisdienste 84, 335 Verzögerungszeit 63
419
Stichwortverzeichnis
Virtual Router Redundancy Protocol 344 V-LAN Adressbasierend 50 nach IEEE802.1q 50 Portbasierend 50 Protokollbasierend 48 Voluntary Tunneling 179 VPN Accounting 333 Administration 335 Admission Control 345 Arten 37 Ausfallsicherheit 343 Auswahl 361 Authentifizierung 315, 379 Authentifizierungsverfahren 351 Autorisierung 316 Backup 344 Bandbreite 344 Bandbreitenmanagement 344 Branch-Office 41, 359 Client-Rollout 340 Clients 336 Clientsoftware 385 Datenvertraulichkeit 315 Design 309 Dienste 43 Durchsatz 331 Extranet 42 Hersteller Auswahl 366 Internet-VPN 24 Intranet 47 IP 44 IP-Adressmanagement 332 IP-VPN 24, 30 Ist-Aufnahme 310 Lastverteilung 345 Layer-2 46 Loadbalancing 345 Logging 333
420
Markt 28 Marktentwicklung 30 Migrationsphase 322 Performance 363 QoS 380 Realisierung 328 Redundanz 343 Remote Access 330 Remote-Access 37, 356 Remote-Access-VPN 24 Routing 329, 384 Schnittstellen 375 Sicherheit 315, 334, 377 Site-to-Site 41 Skalierbarkeit 342 Sprach-VPN 19 Systemdurchsatz 344 Typ 325 Übergangsphase 322 Unified-VPN 19 VPN-Gateway 346 VPN-Planung 310 VPN-Zusatzfunktionen 362 VRRP 344, 383 W Web-based-Management 77 X X.25 21 X.509 336 X.509-Zertifikate 153 Z Zertifikate Lebensdauer 165 Sperrlisten 165 Verteilung 165 Zufallszahlen 140 Zugangs-Kontrollsystem 145 Zugriffsschutz 58
Copyright Daten, Texte, Design und Grafiken dieses eBooks, sowie die eventuell angebotenen eBook-Zusatzdaten sind urheberrechtlich geschützt. Dieses eBook stellen wir lediglich als Einzelplatz-Lizenz zur Verfügung! Jede andere Verwendung dieses eBooks oder zugehöriger Materialien und Informationen, einschliesslich der Reproduktion, der Weitergabe, des Weitervertriebs, der Platzierung im Internet, in Intranets, in Extranets anderen Websites, der Veränderung, des Weiterverkaufs und der Veröffentlichung bedarf der schriftlichen Genehmigung des Verlags. Bei Fragen zu diesem Thema wenden Sie sich bitte an: mailto:
[email protected]
Zusatzdaten Möglicherweise liegt dem gedruckten Buch eine CD-ROM mit Zusatzdaten bei. Die Zurverfügungstellung dieser Daten auf der Website ist eine freiwillige Leistung des Verlags. Der Rechtsweg ist ausgeschlossen.
Hinweis Dieses und andere eBooks können Sie rund um die Uhr und legal auf unserer Website
(http://www.informit.de)
herunterladen
