Von: Andreas Baehre
Bei einem Remote-Access-VPN handelt es sich um die Abbildung eines traditionellen Direkteinwahl-Netzes über ein öffentliches IP-Netz. Unternehmen, die ein solches Virtuelles Privates Netz planen, stellen an dieses exakt die gleichen Anforderungen wie beim direkten Zugriff auf die Unternehmenszentrale. Im Wesentlichen sind dabei folgende Anforderungen umzusetzen:
- eine starke, persönliche Authentifizierung jedes Nutzers,
- Unterstützung unterschiedlicher Authentifizierungsmethoden wie Public Key Infrastructure (PKI), X.509.v3-Zertifikaten, Smartcards, User-ID/Password (Radius), Secure ID oder One Time Password (OTP),
- starke Verschlüsselung und sicherer Schlüsselaustausch,
- überschaubarer Aufwand bei Konfiguration und Administration der VPN-Clients und der dazugehörenden Sicherheits-Policy,
- keine Einschränkung der Netztopologie sowie
- Multiprotokollfähigkeit beim Einsatz unterschiedlicher Netzwerkprotokolle.
Die technische Grundlage von Layer-2- und Layer-3-VPNs bildet das Tunneling. Dieses Verfahren ist notwendig, um Daten über ein unsicheres öffentliches Netz zwischen einem zentralen VPN-Gateway und einem Remote-VPN-Client zu transportieren. Ein Tunnel wird aufgebaut, indem jedes Datenpaket einen zusätzlichen IP-Header erhält, außerdem ein oder mehrere spezielle Kopffelder. Der Anfangspunkt des Tunnels ist dort, wo der IP-Header hinzugefügt wird, der Endpunkt, wo dieser wieder entfernt wird. Weil sowohl Authentifizierung als auch Verschlüsselung innerhalb des Tunnels ablaufen, spielen die Endpunkte eine wichtige Rolle. Je nachdem, wo sich die Tunnelendpunkte befinden, spricht man von
- Site-to-Site-VPN,
- End-to-Site-VPN und
- End-to-End-VPN.
Ein Beispiel für ein Site-to-Site-VPN ist ein Tunnel zwischen einem Filial- und einem zentralen VPN-Gateway. Bei einem End-to-Site-VPN wird zwischen einem Einzelplatz-Rechner oder einer Station im LAN (VPN-Client), die sich beispielsweise in einem Filialnetz befindet, und einem zentralen VPN-Gateway ein Tunnel aufgebaut. Dabei ist es nicht erforderlich, dass der Filial-Router VPN-fähig ist. Das End-to-End-VPN funktioniert im Grunde ebenso wie ein End-to-Site-VPN, nur dass das VPN-Gateway im zentralen Applikationsserver integriert ist. Dadurch wird die gesamte Stecke vom Client-Rechner bis zur zentralen Applikation gesichert.
Unternehmen gehen zunehmend dazu über, die Tunnel nicht im Filial-Router, sondern in den einzelnen LAN-Workstations enden zu lassen. Die Vorteile liegen auf der Hand: die persönliche Authentifizierung der Teilnehmer an ihrer Arbeitsstation und zudem die Verschlüsselung der Unternehmensdaten im Filialnetz. Im Remote-Access-Markt zeichnet sich also eine Entwicklung weg von Site-to-Site-VPNs ab. An ihre Stelle treten Virtuelle Private Netze mit End-to-Site- oder End-to-End-Verbindungen.
VPNs auf Grundlage von Layer 2
Zu den bekanntesten Layer-2-Tunneling-Verfahren gehören Layer 2 Forwarding (L2F), das Layer 2 Tunneling Protocol (L2TP) sowie das Point-to-Point Tunneling Protocol (PPTP). Ein Layer-2-Tunnel ist quasi ein "virtuelles Kabel", das sich über jede IP-Plattform hinweg aufbauen lässt. Dabei ist es unerheblich, ob die IP-Router zwischen VPN-Client und Gateway Network Address Translation (NAT) einsetzen. Ein Layer-2-Tunnel ist multiprotokollfähig, das bedeutet, er unterstützt nicht nur IP, sondern auch IPX, SNA oder Netbios. Deshalb ist es bei einem Layer-2-VPN auch dann möglich, über ein öffentliches IP-Netz mit der Unternehmenszentrale zu kommunizieren, wenn andere Protokolle zum Einsatz kommen.
Um in einem Layer-2-VPN einen Tunnel aufzubauen, sind ein spezieller IP-Header, ein UDP- (User Datagram Protocol) oder TCP-Kopffeld (Transport Control Protocol) sowie ein Header erforderlich, der für das Tunneling-Verfahren spezifisch ist. Wie groß dieser "Overhead" pro Paket ist, hängt vom eingesetzten Verfahren ab. Normalerweise beträgt er 40 Byte. So gut sich das Layer-2-Tunneling für den Fernzugriff auf Netze auch eignen mag, so hat es doch einige Schwächen: So gewährleistet dieses Verfahren nur teilweise die Integrität der Daten. Zudem verwendet es mit CHAP/PAP (Challenge Handshake Authentication Protocol/Password Authentication Protocol) ein relativ schwaches Authentifizierungsverfahren. Weiter fehlen wesentliche Sicherheitsfunktionen, wie eine starke Verschlüsselung, die Unterstützung von digitalen Zertifikaten in einer Public Key Infrastructure (PKI) und ein leistungsfähiges Schlüsselmanagement.
Mithilfe einer Erweiterung des Point-to-Point-Protokolls lassen sich Sicherheitsmechanismen und Layer-2-VPN-Tunneling vereinen. Hier sind zwei Ansätze zu unterscheiden:
- die Erweiterung der PPP Authentication Phase (PAP/CHAP) sowie
- des PPP Encryption Control Protocol (ECP).
In beiden Fällen wird die Version 3.0 des Secure-Socket-Layer-Hand-shake-Protokolls (SSL) eingesetzt. Dieses Verfahren ist im Request for Comment (RFC) 2716 "PPP EAP TLS Authentication Protocol" beschrieben, den Microsoft eingereicht hat. Es unterstützt Zertifikate; das heißt, es erlaubt eine "starke" Authentifizierung und einen sicheren Schlüsselaustausch. Das VPN ist somit "PKI enabled".
Sobald die Kommunikationspartner die SSL-Informationen ausgetauscht haben, werden alle Daten verschlüsselt, die über eine PPP-Verbindung laufen: die Netzwerkprotokolle IP/IPX sowie der letzte Teil des PPP-Handshake - die Zuweisung der privaten IP-Adresse und von DNS- beziehungsweise WINS-Servern an den Client.
Layer-2-Tunneling mit den oben beschriebenen Sicherheitsmechanismen wird auch "SSL over L2TP" genannt. Es erlaubt den Aufbau eines hochsicheren Remote-Access-VPN, das jede Infrastruktur unterstützt. Bereits vorhandene Netzwerkkomponenten lassen sich daher weiter verwenden. Es ist unerheblich, ob ein Client den Tunnel zum VPN-Gateway in der Firmenzentrale über einen Provider, einen dazwischenliegenden Filial-Router oder einen Network Access Server (NAS) aufbaut. Jedem Remote-User werden bei "seiner" PPP-Session immer dieselben Attribute zugewiesen: IP-Adresse, Datenkompression, DNS-Adresse, et cetera.
Layer-3-VPN mit IPSec
Im Gegensatz zur Layer-2-Variante ist ein Virtuelles Privates Netz, das auf OSI-Schicht 3 aufsetzt, nicht multiprotokollfähig. Es bezieht sich immer auf ein bestimmtes Netzwerkprotokoll; im Fall von IPSec handelt es sich um das Internetprotokoll. Die RFCs 2401 bis 2409 beschreiben, wie sich mit IPSec ein VPN mit vorgegebener Security für IP aufbauen lässt. IPSec wurde mit dem Ziel definiert, die Interoperabilität zwischen Komponenten unterschiedlicher Hersteller zu garantieren. Es steht ein komplettes Rahmenwerk zur Verfügung, das sowohl (Layer 3-) Tunneling als auch eine starke Authentifizierung, Schlüsselaustausch und Verschlüsselung umfasst.
IP Security und Fernzugriff
Die Grundlage der Sicherheitsmechanismen bildet die so genannte IKE-Phase-1-Verhandlung (Internet Key Exchange). Sie kann in zwei Hauptmodi erfolgen: dem Main und dem Aggressive Mode. Im Main Mode oder Identity Protection Mode werden sechs Nachrichten ausgetauscht und die dabei übermittelten IDs oder Zertifikate verschlüsselt. Im Aggressive-Mode hingegen werden nur drei Nachrichten übermittelt. IDs und Zertifikate bleiben unverschlüsselt.
Unabhängig vom Handshake-Verfahren sind mehrere bidirektionale Authentifizierungsverfahren zu unterscheiden. Am häufigsten werden folgende eingesetzt: Preshared Key, bei dem der Client und das VPN-Gateway jeweils dieselben vorkonfigurierten Schlüssel besitzen, sowie RSA Signatures, die digitale Zertifikate unterstützen.
IPSec weist im Zusammenspiel mit Remote Access eine Reihe von Schwachpunkten auf:
1. Wenn Preshared Key, Main Mode und dynamische IP-Adressen genutzt werden, muss der Preshared Key für alle IPSec-Clients gleich sein.
2. IPSec unterstützt nicht die traditionell beim Fernzugriff eingesetzten unidirektionalen Authentifizierungsmethoden Radius (PAP/CHAP), Secure ID oder OTP.
3. Die IP-, DNS- und WINS-Adresszuweisung vom VPN-Gateway zum Client ist innerhalb des IKE-Protokolls nicht spezifiziert. Die privaten IP-, DNS- und WINS-Adressen müssten danach in jedem IPSec-Client fest konfiguriert werden.
4. Bei größeren Remote-Access-Netzen mit mehr als 300 Teilnehmern können Ressourcen-Probleme im Gateway auftreten. Die IPSec-Clients unterbrechen immer wieder ihre Layer-2-(PPP-)Verbindung zum Provider und löschen unter Umständen ihre eigenen Security Associations (SA), die nach wie vor im VPN-Gateway existieren.
5. Zwischen IPSec-Client und VPN-Gateway darf kein IP-NAT-Verfahren eingesetzt werden, weil der IPSec-ESP-Header nicht über genügend Informationen verfügt. Setzt beispielsweise ein Filial-Router IP-NAT bei der Einwahl zum Provider ein, muss sich der Tunnelendpunkt im Router befinden. Das heißt, es findet nur eine Authentifizierung des LAN statt, jedoch keine persönliche Authentifizierung der Teilnehmer am Arbeitsplatzrechner. Vor allem beim Einsatz von digitalen Zertifikaten (PKI) muss aber der Tunnelendpunkt im Rechner in der Außenstelle liegen.
6. In großen Remote-Access-Installationen ist die Konfiguration und Administration der SPD-Einträge (Security Policy Database) sowohl auf Clientseite als auch im Zentralsystem sehr aufwändig.
Mittlerweile gibt es Ansätze, die diese Unzulänglichkeiten beseitigen sollen. So hat Cisco im Draft "XAUTH" (Extended Authentication) eine Lösung für die ersten beiden Punkte vorgeschlagen. Sie setzt jedoch voraus, dass das IKE-Protokoll erweitert wird. Ein vergleichbarer Draft für das Zuweisen von IP-, DNS- und WINS-Adressen (Punkt 3) liegt noch nicht vor. Um das in Punkt 4 dargestellte Problem zu lösen, gibt es einen Vorschlag, keinen Draft, der eine Art Polling beschreibt. Mithilfe dieses Verfahrens soll signalisiert werden, dass eine Security Association nicht mehr aktiv ist. Polling wird allerdings zu einem Problem, wenn der Client im Shorthold-Modus arbeitet, weil die Layer-2-(PPP-)Verbindung zum Provider immer bestehen bleibt.
Das Problem mit dem Übersetzen der Netzwerkadressen zwischen IPSec-Client und VPN-Gateway (Punkt 5) soll der neue Draft "NAT Traversal 28/2-2001" der Firma SSH lösen. Damit Geräte, die Network Address Translation einsetzen, kommunizieren können, wird jedes IPSec-Paket zusätzlich in einen IP- und UDP- Header verpackt. Der sechste Punkt ist davon abhängig, wie ein Hersteller die Verwaltung der Security-Policy-Datenbanken implementiert.
Der wohl interessanteste Ansatz, um die in den Punkten 1 bis 5 aufgezeigten Probleme zu lösen, ist im Informational RFC 2888 "IPSec over L2TP (Secure Remote Access with L2TP)" beschrieben. IPSec over L2TP verlangt keine Änderungen an den Requests for Comment 2401 bis2409 und dürfte deshalb die Zustimmung der IPSec- und IPSRA-Arbeitsgruppen finden.
RFC 2888 sieht vor, dass zunächst ein Layer-2-Tunnel zwischen VPN-Client und VPN-Gateway aufgebaut wird, anschließend eine Standard-PPP-Verbindung, sprich eine ohne erweiterte Sicherheitsfunktionen wie bei PPP-EAP-TLS. Über sie werden die IKE-Verhandlung (Handshake) und die IPSec-Datenpakete übertragen (Punkte 1 bis 3). Trennt der Client die Layer-2-Verbindung zum Provider, wird der Tunnel automatisch abgebaut und die IPSec-SAs können gelöscht werden (Punkt 4). Mit Punkt 5 (IP-NAT) gibt es, wie eingangs beschrieben, bei einem L2TP-Tunnel sowieso keine Probleme.
Die Lösung: IPSec über L2TP
Doch auch RFC 2888 weist einige Nachteile auf. Einer ist der Overhead, also der L2TP- und IPSec-Haeader, ein weiterer die Komplexität, die auf die Kombination von Layer-2-Tunneling und IPSec zurückzuführen ist. Ein dritter Punkt ist, dass die privaten IP-Adressen unverschlüsselt übermittelt werden, weil IPSec erst nach Aufbau des Tunnels und dem anschließenden PPP-Handshake aktiv wird. In der Praxis hat sich jedoch gezeigt, dass der Overhead bei IPSec over L2TP entweder durch PPP-Kompression oder IP-Kompression (IPCOMP) auf IPSec-Ebene begrenzt werden kann. Wie komplex die Implementierung ausfällt, hängt davon ab, über welches Know-how ein Hersteller in Bezug auf die Layer-2-Technik verfügt. Und ob die privaten IP-Adressen unverschlüsselt über das Netz laufen sollen, muss der Betreiber eines VPNs entscheiden.
IPSec ist ein Standard mit ausgezeichneten Sicherheitsmechanismen. Er eignet sich vor allem für VPN-Szenarien, in denen mit festen IP-Adressen gearbeitet wird, etwa im Business-to-Business-Bereich oder in Extranets. In diesen Fällen lassen sich durchaus VPN-Gateways verschiedener Hersteller einsetzen. Allerdings können Probleme beim Einsatz von digitalen Zertifikaten auftreten.
Fazit: IPSec nur bedingt tauglich für Remote Access
Im Bereich Remote Access weist IPSec jedoch erhebliche Mängel auf, die leider von Anbietern und Consultants nur selten angesprochen werden. Andererseits müssen Unternehmen, die in ein Remote-Access-VPN investieren wollen, diese Schwächen kennen. Zweifellos hat IPSec auch im Remote-Access-Umfeld seine Berechtigung. Allerdings müssten sich die Netzwerk-hersteller zunächst einmal auf ein einheitliches Verfahren einigen, etwa IPSec over L2TP. Doch solange immer wieder neue Drafts eingereicht werden oder sogar mehrere Drafts existieren, die das gleiche Problem zu lösen versuchen, ist es schwer, von einem Standard zu sprechen. (re)
Zur Person
Andreas Baehre
ist Leiter der Abteilung Re-search & Development bei der NCP Engineering GmbH in Nürnberg.