VPN - Virtual Private Networks

Inhaltsverzeichnis

1. Einleitung

2. VPN – Modelle und Standards
2.1. VPN Typen (Remote-access, branch-office, Extranet)
2.2. Tunneling Modelle (intra-provider, provider-enterprise, Ende zu Ende)
2.3. Tunneling Protokolle
2.3.1. IPSec
2.3.2. PPTP (als Microsoft-Herstellerstandard)
2.3.3. L2TP
2.3.4. IPSec secured L2TP

3. VPN Sicherheitsaspekte
3.1. Authentifizierung
3.2. Verschlüsselung
3.3. RFCs 2401-2409
3.3.1. RFC 2401 – IPSec-Sicherheitsassoziationen
3.3.2. RFC 2402 – IP-Authentication Header
3.3.3. RFC 2403 – HMAC MD5
3.3.4. RFC 2404 – HMAC SHA-1
3.3.5. RFC 2406 – ESP
3.3.6. RFC 2408 – ISAKMP
3.3.7. RFC 2409 – IKE
3.4. Zertifikatsmanagement

4. Visualisierungsvorschlag für IPSec mit IKE

5. VPN Unterstützung
5.1. Windows
5.2. Linux
5.3. Hard/Software VPN-Lösung (Cisco)

6. Fazit

7. Anhang
7.1. Fachwörterverzeichnis
7.2. Abbildungsverzeichnis
7.3. Literaturverzeichnis

1. Einleitung

Virtual Private Networks, kurz VPNs, dienen dazu, zwei oder mehrere Rechner(netze) miteinander zu verbinden. Der Unterschied zu herkömmlichen, privaten Netzwerken ist dabei der Transportweg: VPNs nutzen öffentliche Netzwerke als Träger für den privaten Datenaustausch, so dass die Vernetzung von weit entfernten Rechnern(netzen) kein Problem darstellt. So gesehen handelt es sich bei Standfestverbindungen und Mietleitungen (z.B. mittels ISDN, Frame Relay und ATM), die bis heute bei der Verbindung von beispielsweise verteilten Unternehmensnetzen noch eine große Rolle spielen, definitionsgemäß auch um VPNs, da sie öffenliche Netze, wie das Telefonnetz, als Träger nutzen. Dennoch herrscht bei diesen Netzen die Vorstellung vor, es handele sich um private, physisch separate Netze.

Das bekannteste und in Bezug auf VPN-Realisierungen zukunftsträchtigste öffentliche Netzwerk ist das Internet. Daher behandelt diese Arbeit ausschließlich die sogenannten Internet-VPNs, oder auch IP-VPNs.

Die Größe des Internets und die Tatsache, dass praktisch Jedermann Zugriff darauf hat, macht eine Betrachtung der Sicherheit von VPNs nötig. Dabei wird diese Arbeit aufzeigen, dass diese Sicherheit von verschiedenen Faktoren abhängt, die sich durchaus beeinflussen lassen: Unter anderem muss eine Wahl der zu benutzenden Protokolle getroffen werden, wobei sich davon einige zum Standard etabliert haben, andere (noch) herstellereigene Lösungen sind. Weiterhin wird untersucht, inwieweit diese Protokolle in Betriebssystemen implementiert sind, d.h. man wird eine Vorstellung davon bekommen, wie geeignet Betriebssysteme sind, ein VPN aufzubauen. Als Alternative bieten sich Hardwarelösungen an, ein VPN einzurichten. Kapitel 5.3 beleuchtet einen Vertreter der Hardwarelösungen.

2. VPN – Modelle und Standards

In diesem Kapitel werden zunächst die verschiedenen Szenarien erklärt, in denen unterschiedliche VPN Typen zum Einsatz kommen. Danach folgen Tunneling Modelle und Tunneling Protokolle, die auf ihre Eigenschaften wie Sicherheit und Handhabbarkeit untersucht werden.

2.1. VPN Typen (Remote-access, branch-office, Extranet)

Remote-access -VPN

Ein Kerneinsatzgebiet für VPNs stellt der aus der Entfernung stattfindende, temporäre Zugriff auf beispielsweise ein Unternehmensnetz dar. Bei einem Remote-Access handelt es sich genauer gesagt um einzelne Clients, die auf das Unternehmensnetz zugreifen (etwa Mitarbeiter bei der Heimarbeit oder beim Zugriff per Laptop während einer Dienstreise).

Auf der Unternehmensseite kann ein VPN fähiger Router oder eine VPN fähige Firewall eingesetzt werden. Es ist aber auch spezielle VPN Hardware erhältlich, die ihre Vorteile in der Verarbeitungsgeschwindigkeit der VPN-Kommunikation und in der hohen Sicherheit haben. Denn ein so genannter VPN-Konzentrator, wie er in einem Remote-Access VPN eingesetzt würde, implementiert lediglich die zur VPN-Verbindung nötigen Protokolle und ist daher nicht anfällig für Angriffe, die auf Router beispielsweise denkbar sind. Der VPN-Konzentrator ist direkt an einen Internet Service Provider (ISP) angebunden. Die Clients stellen ihrerseits eine Verbindung zu einem (anderen) ISP in ihrer unmittelbaren Nähe her. Mittels spezieller Client Software ist nun die Verbindung vom Client über dessen ISP

und von dort über das Internet zu jenem ISP, an den der firmeneigene VPN-Konzentrator angebunden ist, möglich. Die Software baut einen sogenannten Tunnel zum VPN-Konzentrator auf, eine sichere, private Verbindung über ein unsicheres, öffentliches Netz (hier: das Internet) [DeEr01, 21].

Ein solches System bietet clientseitig alle Einwahlmöglichkeiten, die der angewählte ISP unterstützt. Das Ergebnis ist volle Flexibilität der Zugangswege. Die einzige Überlegung, die gemacht werden muss ist, wie viele Zugänge parallel verfügbar sein sollen, also wie viele Ports der VPN Konzentrator haben soll.

Ein entscheidender Punkt in der Überlegung, ein VPN zu installieren, sind die Kosten:

Anschaffungs- und Betriebskosten eines VPN können oftmals die Kosten einer herkömmlichen Lösung für Remote-Access (das Unternehmensnetz bietet durch einen Remote Access Concentrator (RAC) direkte Einwahlmöglichkeit) bei weitem unterschreiten. Wo man sich im Falle einer Nicht-VPN Realisierung noch im RAC selbst einwählen musste, wählt man nun einen nahen ISP und die restliche Strecke überbrückt dann das Internet.

Das Einsparpotential hängt so im Wesentlichen von der Entfernung zwischen dem Nutzer und dem Firmennetz ab. Es ist leicht nachzuvollziehen, dass dieses Potential sehr schnell sehr groß werden kann, wenn beispielsweise Dienstreisende aus dem Ausland Zugriff wünschen.

Branch-Office-VPN

Das Branch-Office-VPN erfüllt die Funktionalität der bekannten Wide-Area-Networks (WAN). Das bedeutet, es wird eine Verbindung zwischen zwei Netzwerken hergestellt, die räumlich voneinander getrennt sind.

Mit dem Einsatz von VPN-Technologie reduzieren sich auch hier die Verbindungskosten. Je weiter die Netze auseinanderliegen, desto drastischer ist der Unterschied zu einem herkömmlichen WAN. Denn wie zuvor bei den Remote-Access-VPNs, kann auch hier das Internet zur Überbrückung großer Entfernungen dienen. Es ist keine teure Punkt-zu-Punkt Festverbindung mehr nötig, sondern die partizipierenden Teil-Netze wählen sich bei ihrem jeweils nächsten ISP ein.

Im Branch-Office Bereich ist der Einsatz von VPN fähigen Routern oder Firewalls im Hinblick auf Verarbeitungsgeschwindigkeit im Vergleich zu den Remote-Access Netzen eher möglich, da kein häufiger Verbindungsauf-/abbau stattfindet. Die Verbindung zwischen den beiden Branches bleibt über längere Zeit bestehen. Allerdings bleiben die Vorteile der dedizierten VPN-Hardware-Lösungen im Hinblick auf die Sicherheit des virtuellen privaten Netzes bestehen (s. Remote-Access).

Es ist leicht vorstellbar, dass der Branch-Office-VPN-Typ im Zuge der allgemeinen Globalisierung zwangsläufig weiter an Popularität gewinnen wird.

Extranet-VPN

Als Extranet wird die Einrichtung eines speziellen, eingeschränkten und/oder überwachten Zuganges zu einem Firmennetz bezeichnet. Sinnvoll ist dies, um den Teilnehmern, beispielsweise Kunden, Lieferanten, Handelspartnern, etc. einen eingeschränkten, aber für sie genau zugeschnittenen Zugang zu ermöglichen, quasi eine persönliche Sicht auf das Firmennetzwerk. Dabei werden die für den Teilnehmer relevanten Daten und Bereiche freigegeben, andere, inklusive der Firmeninternas, jedoch gesperrt. Eine entsprechende Regulierung der Datenströme übernimmt eine Firewall. Durch die Einteilung in Benutzergruppen kann eine effiziente Kommunikationsstruktur erzeugt werden, wodurch Extranets die zukünftige Netzplattform für B2B und B2C sind [DeEr01, 27].

2.2. Tunneling Modelle (intra-provider, provider-enterprise, Ende zu Ende)

An dieser Stelle ist zu entscheiden, in wessen Aufgabenbereich die Etablierung der Tunnel zum Aufbau eines VPNs fällt. Die drei unterschiedlichen Modelle werden im Folgenden dargestellt.

Intra-Provider-Modell

Wählt man das Intra-Provider-Modell, so hat man sich für komplettes Outsourcing entschlossen. Das bedeutet, dass man ein Angebot eines ISP's annimmt, der dann einzig und allein für den Tunnelbau zuständig ist. Dieser stellt auch die nötigen Gateways zur Verfügung. Folglich ist keine zusätzliche Hard- und/oder Software beim Kunden erforderlich, um ein VPN einzurichten. Ein Remote-Access-Login funktioniert dann beispielsweise über das DFÜ-Netzwerk von Windows. Als Nachteil ist der ungesicherte Datenstrom bis zu den Points of Presence (POP) der ISPs zu sehen, denn nur zwischen diesen werden die Daten getunnelt und sind eventuell (bei entsprechender Vereinbarung) verschlüsselt.

Provider-Enterprise-Modell

Die Gemeinsamkeit mit dem Intra-Provider-Modell findet sich beim Provider-Enterprise-Modell im Einsatzgebiet. Beide Modelle werden vorwiegend für Remote-Access-VPNs verwendet.

Beim Provider-Enterprise-Modell erstreckt sich der Tunnel vom POP des ISP's bis zum Kunden-VPN-Gateway. Im Gegensatz zum Intra-Provider-Modell muss der Endkunde jetzt spezielle Hard- und Software als VPN-Gateway einsetzen. Am anderen Ende wählt sich der externe Rechner beim ISP ein, der den Benutzer an seiner Rufnummer, Benutzer-ID etc. erkennt und automatisch einen Tunnel zum Firmennetz herstellt (Compulsory Tunneling).

Ende-zu-Ende-Modell

Das Ende-zu-Ende-Modell lässt sämtliche Konfigurations- und Einrichtungsoptionen beim Anwender. Der Provider sorgt lediglich für den Transport der Pakete. Bei diesem Modell muss auch der externe Client spezielle VPN-Software installieren, um in der Lage zu sein, einen Tunnel zum Firmennetz zu etablieren.

Auf diese Weise erlangt man maximale Sicherheit, da der Anwender den kompletten VPN Verkehr selbst regelt. Der ISP, der die Daten überträgt, sieht diese nur noch in verschlüsseltem Zustand, wodurch das Restrisiko der ersten beiden Modelle, in dem der Provider theoretisch die Daten einsehen kann, entfällt.

Gleichzeitig ist natürlich mit erhöhtem Aufwand zur Einrichtung und Betrieb des VPNs zu rechnen, wenn alles selbst konfiguriert werden muss.

2.3. Tunneling Protokolle

2.3.1. IPSec

Wie wird nun ein Tunnel aufgebaut?

Im Falle der Anwendung von IPSecurity werden zwei IPSec-Gateways mit offiziell registrierten IP-Adressen als Tunnelendpunkte benötigt. Handelt es sich um ein Remote-Access-VPN, erhält der Client seine IP-Adresse im Moment der Einwahl beim ISP.

Die Gegenseite, das Firmennetz, sollte über einen IPSec-Gateway mit fester IP verfügen, um stete Einlogmöglichkeit zu garantieren.

Kommt es zum Datenverkehr, erzeugt IPSec im so genannten Tunnelmodus für jedes zu übertragende Paket ein neues IP-Paket, in dessen Datenbereich das komplette, ursprüngliche Paket verschlüsselt eingekapselt wird. So können Außenstehende höchstens die Anzahl der übertragenen Pakete ermitteln, aber nicht deren Inhalt.

Erreichen die Pakete unbeschadet das Gateway (den Tunnelendpunkt), wird das eigentliche Datenpaket wieder ausgekapselt und im Intranet des Firmennetzes weitergeleitet.

Im Gegensatz zu dem gerade erwähnten Tunnelmodus findet im Transportmodus von IPSec ebenfalls eine Verschlüsselung der Daten statt, jedoch wird das zu übertragende Paket nicht komplett verschlüsselt und in ein neues IP-Paket gekapselt, sondern der ursprüngliche IP-Header bleibt erhalten. Das hat zur Folge, dass die Kommunikationsendpunkte auch zwingend die Sicherheitsendpunkte sind und der Transportmodus folglich nur für Host-zu-Host Verbindungen ohne zwischengeschaltete Gateways tauglich ist. Und die Tatsache, dass nur die Nutzdaten verschlüsselt werden können und der IP-Header selbst nicht, ermöglicht Außenstehenden Informationen über die Netzstruktur und die benutzten Protokolle zu sammeln.

Die Identifikation der Pakete funktioniert mit Hilfe von HMAC (Hash-based Message Authentication Code). Dieser Code wird vor dem Senden für jedes Paket neu berechnet und in Selbiges eingefügt. Die Berechnungsformel basiert auf einem nur dem Sender und dem Empfänger bekannten Schlüssel. Das bedeutet, dass ein Saboteur nicht unbemerkt einen Paketinhalt verändern kann, da er nicht in der Lage ist, einen zugehörigen, korrekten HMAC neu zu erzeugen - ihm fehlt der Schlüssel. Der Empfänger überprüft bei Ankunft die Richtigkeit der Pakete und deren HMACs. Auf diese Weise ist sowohl sichergestellt, dass es sich bei ankommenden Paketen tatsächlich um solche des Senders handelt als auch, dass sie unterwegs nicht manipuliert wurden.

Eine genauere Beschreibung der Paketauthentifizierung findet sich in den Kapiteln über die Request for Comments 2402-2404 (RFC).

Die Verschlüsselung der Daten findet in verschiedenen Implementierungen von IPSec durch unterschiedliche Algorithmen statt, entsprechend der gewünschten Sicherheitsstufe. Da IPSec aber ein durch RFCs standardisiertes Protokoll ist, wird bei der Verschlüsselung der Data Encryption Standard (DES) vorgeschrieben. Somit ist ein Mindestmaß an Verschlüsselung und Kompatibilität zwischen den VPN-Endpunkten sichergestellt. Je nach Bedarf können andere, bessere Algorithmen, wie Triple DES, IDEA oder Blowfish die Verschlüsselung ergänzen oder ersetzen. Voraussetzung für eine Verbindung ist jedoch, dass Sender und Empfänger den gleichen Algorithmus verwenden, was einerseits logisch zwingend klingt, andererseits bei Nichtbeachtung in der Praxis zu Schwierigkeiten führt [Schm01]. Gemeint sind damit nicht zustande kommende Verbindungen.

Auf die Aushandlung der zu verwendenden Algorithmen, den Schlüsseltausch und auf die Verschlüsselung selbst gehen die Kapitel über die RFCs 2401, 2406 und 2409 näher ein.

IPSecurity bietet optional einen guten Schutz vor Replay Angriffen. Replay Angriffe sind eine Art Denial-of-Service (DoS) Angriff. Ein Angreifer versucht, das VPN lahmzulegen, indem er eine sehr große Datenmasse zum VPN-Gateway schickt. Da aber nur Pakete empfangen und auch verarbeitet werden, die einen inhaltskonformen HMAC haben, hat der Angreifer nur eine Möglichkeit, einen DoS Angriff zu unternehmen. Er dupliziert diese korrekten Pakete und sendet sie erneut, also redundant an das VPN-Gateway (Replay Angriff). Müssten dort diese zusätzlichen Pakete auch verarbeitet werden, würde es einen unter Umständen erheblichen Mehraufwand bedeuten. Doch IPSec kann auf Wunsch mittels einem Anti-Replay Service (ARS) jedes ankommende Paket zu allererst daraufhin prüfen, ob es schon einmal angekommen ist. Wenn ja, wird es verworfen ohne auch nur eine einzige ressourcenbedürftige Operation auszuführen.

Ein Nachteil von IPSec als Layer 3-Protokoll ist die Unfähigkeit, andere Protokolle als das IP zu kapseln. Um diesen Nachteil zu umgehen und bei IPSec-gemäßer Sicherheit auch andere Protokolle zu tunneln, kann sehr gut eine Kombination von IPSec und L2TP eingesetzt werden, welche in einem der nachfolgenden Kapitel vorgestellt wird.

Die Zukunft von IPSec ist gut, da das Protokoll in der Nachfolgeversion von IP Version 4, nämlich in IPv6 schon integriert ist, ja sogar eigentlich für/auf IPv6 entwickelt wurde.

Der Umstieg auf die IPv6 löst dann auch automatisch ein Problem, das bei dem Einsatz von IPSec derzeit noch existiert: Da es sich um ein reines Punkt-zu-Punkt Protokoll handelt, ist es für IPSec Pakete nicht möglich, einen Client stets automatisch zu erreichen, der sich hinter einem NAT-fähigen Gerät befindet. Es existieren Bestrebungen, dieses Problem noch auf IPv4 zu lösen, da NAT sehr häufig eingesetzt wird, um die Knappheit der IPv4-IP-Adressen auszugleichen (siehe dazu Kapitel VPN-Unterstützung). Mit der Ablösung von IPv4 durch IPv6 jedoch entfällt die Notwendigkeit für NAT, da in IPv6 mehr als ausreichend viele IP-Adressen zur Verfügung stehen.

2.3.2. PPTP (als Microsoft-Herstellerstandard)

Das Point to Point Tunneling Protokoll ist eine Entwicklung verschiedener Firmen unter großem Einfluss von Microsoft. Das Protokoll ist nicht standardisiert, es existiert ein informeller Standard (RFC 2637). Dennoch ist PPTP weit verbreitet, da es ab Microsoft Windows 98 zum Lieferumfang gehört (für Windows 95 auch erhältlich) und einfach in der Installationshandhabung und Anwendung ist. Als Haupteinsatzgebiet ist der Dial-In im Ende-zu-Ende Modell zu sehen.

PPTP regelt den Aufbau und Betrieb des Tunnels, durch den dann PPP Verbindungen aufgebaut werden, die für den Datenaustausch zuständig sind. Als Layer 2 Protokoll ist es ihm möglich, verschiedene Protokolle zu tunneln (IP, IPX, NetBEUI).

Allerdings ist diese PPTP-Steuerverbindung selbst ungesichert, so dass Angriffe denkbar sind.

Zur Authentifizierung und Verschlüsselung werden die Verfahren von PPP genutzt, welche ebenfalls kritisch zu sehen sind:

Die (User-)Authentifizierung mittels PAP oder CHAP entspricht lediglich dem Stand der Technik von vor einigen Jahren [Camp03, 161] und die Sicherheit der Datenverschlüsselung mittels RC4 hängt von der Wahl des Benutzerpassworts ab, aus dessen zugehörigem Hashwert der Schlüssel gebildet wird. Eine Paketauthentifizierung/-integritätsprüfung gibt es nicht.

Während Microsoft in Windows 2000 noch eine proprietäre Möglichkeit anbietet, PPTP mit IPSec abzusichern, ohne dabei „leider den vollständigen Standard zu erfüllen“ [Camp03, 161], wird das Protokoll doch zunehmend verdrängt.

[...]