IPsec versus SSL

23.10.2009
Hohe Bandbreite und ausfallsichere Verbindungen machen VPNs für den Zugriff auf Unternehmensnetze interessant.

So wie sich die Arbeitsumgebung in vielen Berufen in den letzten Jahren gewandelt hat, so hat sich auch die Technik verändert, mit der Anwender auf Unternehmensressourcen zugreifen. Insbesondere der Ausbau des Internets und der Mobilfunknetze in Deutschland sowie die mittlerweile fast flächendeckende Verfügbarkeit von relativ breitbandigen Zugangsmöglichkeiten wie xDSL und UMTS erlauben den Zutritt ins interne Netz mit seinen Daten von fast jedem Ort aus. Früher bedurfte es dazu Wählverbindungen oder paketvermittelnder Netze wie X.25. Hohe Bandbreiten mit guten Verbindungen und wenigen Ausfällen machten IP-basierende VPNs für den gesicherten Zugriff auf Unternehmensnetze attraktiv.

Heute lassen sich auch weit entfernte Mitarbeiter flexibel und relativ kostengünstig an eine Unternehmensinfrastruktur anschließen, sofern an dem entfernten Standort ein Internet-Zugang möglich ist. So ist es durchaus üblich, ein zum Beispiel in China oder Südamerika vorübergehend anzubindendes Büro mittels VPN-Technik so in die Unternehmensinfrastruktur zu integrieren, dass es auf alle Applikationen und Ressourcen genauso zugreifen kann wie die Zentrale. Handelsübliche Home-DSL-Router verfügen über VPN-Funktionen und erlauben so auch dem sicherheitsbewussten Privatanwender oder Freiberufler den Zugriff auf seine heimischen Datenbestände ohne Gefahr, dass private Daten im Internet preisgegeben werden.

VPN-Arten

Grundsätzlich werden zwei Arten von IP-basierenden VPNs unterschieden, das so genannte Site-to-Site-VPN, das zwei interne Netze über eine öffentlich zugängliche Infrastruktur mittels dedizierter Anschlussgeräte verbindet, und das Site-to-End-VPN, das einen – in modernen Betriebssystemen zumeist schon enthaltenen – VPN-Client des Endgeräts zum Zugriff auf einen in der Unternehmenszentrale oder beim Provider installierten VPN-Konzentrator nutzt.

Beiden Arten ist gemein, dass sie unter Beibehaltung interner Adressstrukturen Standorte über das Internet miteinander verbinden, und dies möglichst bei hinreichender Verschlüsselung der zu übertragenden Daten. Sie gestatten somit den transparenten Zugriff auf alle mittels IP abgewickelten Applikationen. Zumeist wird dies über Pseudo-Adapter erreicht, die der VPN-Client auf dem Endgerät oder die dedizierten Anschlussgeräte mittels Software realisieren. Der gesamte Datenverkehr wird über diesen Pseudo-Adapter an die Gegenstelle weitergeleitet, nachdem er verschlüsselt wurde, und auf der Gegenstelle wieder entschlüsselt, bevor die Daten an das jeweilige entfernte Endgerät weitergeleitet werden.

Site-to-Site-VPNs werden zumeist unter Verwendung von VPN-Firewalls oder Routern mit VPN-Funktionen realisiert. Hier können für Authentisierung und Verschlüsselung proprietäre Verfahren zum Einsatz kommen, wobei die zum Aufbau des VPN verwendeten Endgeräte jedoch vom gleichen Hersteller stammen müssen. Zum Teil ist dies auch bei Site-to-End-VPNs der Fall. Dann muss auf dem Endgerät des entfernten Benutzers ein VPN-Client des Herstellers installiert werden, der auch den VPN-Konzentrator rea-lisiert. Wesentlich flexibler ist die Verwendung von Internet-Standards wie Point to Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP) und IPsec. Sie erlauben die herstellerunabhängige Kopplung von verschiedenen Standorten, sofern die zur Authentisierung und Verschlüsselung eingesetzten Verfahren identisch sind.

Zum Beispiel wird PPTP in vielen Betriebssystemen nativ unterstützt (OpenBSD, FreeBSD, Mac OS X, Linux und Windows). Wegen seiner frühen Implementierung in Microsoft-Betriebssystemen wird PPTP auch heute noch häufig genutzt. Die Authentisierung beruht auf dem Microsoft Challenge Access Protocol (MSCHAP), das mittlerweile in der Version 2 verwendet wird, um den in der Version 1 vorhandenen Sicherheitslücken Rechnung zu tragen. Aber auch die MSCHAP-Version 2 ist innerhalb weniger Stunden zu knacken. Das ursprüngliche Verschlüsselungsverfahren ist relativ schwach, da die Schlüssel mittels des Passworts generiert werden und ihre Qualität von der Länge und Komplexität des Passworts abhängt.

Alternative L2TP

L2TP in Verbindung mit IPsec ist ein alternatives Verfahren zur Anbindung entfernter Clients an ein Unternehmensnetz mittels VPN-Technik. Auch hier bieten viele Betriebssysteme eine native Unterstützung, zum Beispiel die von Microsoft seit Windows 2000 und Apples Mac OS X. Mehr oder weniger komplexe Authentisierungsverfahren sorgen dafür, dass die VPN-Verbindungen nur von Endgeräten aufgebaut werden können, die hierzu auch berechtigt sind. Zur Authentisierung können Benutzername und Passwort, RSA SecureID oder Zertifikate genutzt werden. Die Verschlüsselung geschieht ebenfalls über IPsec. Die symmetrischen Schlüssel werden unter Zuhilfenahme des Internet Key Exchange Protocol (IKE) dynamisch kreiert. Die Endpunkte einer IPsec-Verbindung müssen über ein gemeinsames Zertifikat oder einen Pre-shared Key verfügen, damit eine Verbindung zustandekommt.

Zusammengefasst lässt sich nun leicht nachvollziehen, dass neben den für die Authentisierung und Verschlüsselung eingesetzten Verfahren auch zwischen von den VPN-Kommunikationspartnern verwendeten Routern und eventuell vorhandenen Firewalls einige Voraussetzungen erfüllt sein müssen, um erfolgreich ein IP-basierendes VPN zu betreiben.

Auch für Anwender, die mit oben beschriebenen Problemen konfrontiert werden, gibt es Hoffnung. Hierbei wird die VPN-Funktionalität in höhere Schichten des OSI-Referenzmodells verlagert. Jeder Web-Browser unterstützt HTTPS. Genau dies wird bei SSL-VPNs ausgenutzt, um die zuvor geschilderten Probleme zu umgehen. Während bei herkömmlichen HTTPS-Verbindungen nur der Server seine Identität mit SSL-Zertifikaten beglaubigt, beweist der Client bei SSL-VPNs seine Identität gegenüber dem Server ebenfalls mit einem Zertifikat.

Transparenz per Pseudo-Adapter

Akzeptiert der Server das vom Client gelieferte Zertifikat und haben sich Client und Server auf ein gemeinsames Verschlüsselungsverfahren geeinigt, ist der Verbindungsaufbau abgeschlossen, und alle Daten werden zwischen den Kommunikationspartnern verschlüsselt übertragen. Hiermit ist der Zugriff auf interne Web-basierende Anwendungen möglich. Sollen auch andere Applikationen erreichbar sein, versprechen ActiveX oder Java-Applet-basierende Thin Clients Abhilfe. Hierbei wird der Client über die bereits bestehende SSL-Verbindung auf das Endgerät übertragen und führt dort die Funktion eines Proxies aus, der zum Beispiel nicht Web-basierende Applikationen unter Mithilfe des SSL-VPN-Servers erreichbar macht. Reicht dies nicht aus, kann auch ein Pseudo-Adapter auf dem Client installiert werden, der dann einen transparenten IP-Zugriff auf das Unternehmensnetz erlaubt. Das Spektrum der SSL-VPN-Server reicht hier von Web-Server-basierenden Applikationen über dedizierte SSL-VPN-Gateways bis zu SSL-VPN-Blades, die in modulare Switches eingeschoben werden.

Ausblick

Beim Hersteller H3C Networks ist man beispielsweise überzeugt, dass der Security-Markt sich in den nächsten Jahren zweiteilen wird: in netzintegrierte Sicherheitsmechanismen und Client-Server-Security. Die Evolution der Sicherheitslösungen war bisher problemorientiert. Immer wenn eine fundamental neue Sicherheitslücke entstanden war, kreierte ein Hersteller eine spezielle Lösung. Dies hat zu einem inhomogenen Lösungsszenario geführt, das heute kaum noch effizient zu betreuen und betreiben ist. Hieraus resultiert das Problem, dass es nicht möglich ist, übergreifende Regelwerke zu hinterlegen, die auf alle Sicherheitsmechanismen der IT wirken können.

Über das regelgestützte Management, so H3C Networks, sind nun Sicherheitskonzepte und Lösungen sehr komfortabel zu realisieren. Network Access Control (NAC), um nur ein Beispiel zu nennen, ist somit seiner Komplexität beraubt und mit überschaubarem Aufwand für Rollout und Betrieb implementierbar.

PPTP mit EAP

Microsoft hat mit Windows 2000 das Extensible Authentication Protocol (EAP) eingeführt, das die Authentisierung über Zertifikate und MD5-Hashes unterstützt. Ohne EAP gilt PPTP als nicht mehr hinreichend sicher. Darüber hinaus hat es seine Tücken, wenn zwischen den VPN-Kommunikationspartnern eine Network Address Translation (NAT) vorgenommen wird. Somit ist über einen NAT-Router nur die Anbindung eines PPTP-Clients möglich, falls dieser nicht ein Application Layer Gateway für PPTP unterstützt, welches die im PPTP verwendeten Call-IDs verwaltet und für unterschiedliche PPTP-Clients jeweils zuordnet.

IPsec und NAT

Auch IPsec hat Schwierigkeiten im Zusammenhang mit NAT. IKE verwendet sowohl als UDP Source als auch Destination Port den Port 500. Wird dieser durch einen NAT-Router verändert, kommt die IKE-Kommunikation zwischen den VPN-Endgeräten, auf die IPsec angewiesen ist, nicht zustande. Darüber hinaus verwendet IPsec so genannte Encapsulation-Security-Payload-(ESP-)Pakete mit einer festen IP-Nummer. Daher kann nur ein Client über einen NAT-Router arbeiten, wenn dieser IKE- und ESP-Pakete entsprechend weiterleitet. Um unabhängig von dem zwischen den VPN-Partnern eingesetzten NAT-Geräten zu sein, ist IPsec deshalb um NAT Traversal erweitert worden. Darüber tauschen beide Seiten Informationen aus und verpacken anschließend ESP-Pakete in UDP-Pakete mit der Port-Nummer 4500. Auf diese Art und Weise funktioniert IPsec selbst dann, wenn die zwischen den VPN-Partnern liegenden NAT-Geräte IP-Adressen und Ports verändern.