VPN - Virtuelle Private Netzwerke

Vortrag auf dem LinuxTag 2002 (Stuttgart)

Peter Conrad <conrad@unix-ag.uni-kl.de>

Mit dem Vormarsch der elektronischen Kommunikation in praktisch allen Lebensbereichen wächst auch das Bedürfnis der Vernetzung im professionellen Umfeld. VPNs bieten eine preiswerte und flexible Alternative zu Standleitungen oder Frame-Relay-Anbindungen, die auch erhöhten Sicherheitsanforderungen genügt. Der Vortrag bietet einen Überblick über verschiedene Techniken zur Erzeugung eines VPNs und demonstriert eine Möglichkeit, VPNs mit Hilfe von Linux-Rechnern einzurichten.

Was ist ein virtuelles privates Netzwerk?

Zunächst einmal: was ist ein privates Netzwerk? Ein privates Netzwerk ist ein Netzwerk, das nur einer eng eingeschränkten Gruppe von Nutzern zur Verfügung steht, z. B. das interne Rechnernetz einer Firma. Im Gegensatz dazu ist ein öffentliches Netzwerk ein Netzwerk, auf das jeder zugreifen kann, z. B. das Internet. Die Abgrenzung zwischen beiden ist heutzutage nicht mehr ganz einfach, da sehr viele Firmen ihre internen Netzwerke an das Internet angeschlossen haben. Typischerweise verhindert aber in diesen Fällen eine Firewall Zugriffe aus dem Internet auf das interne Netzwerk und umgekehrt, so daß man auch hier von einem 'privaten Netzwerk' sprechen kann.

Wenn man nun zwei oder mehr 'private Netzwerke' verbinden will, gibt es ein Problem: wenn man die Kommunikation zwischen beiden Netzen zuläßt, z. B. indem man die jeweiligen Firewalls öffnet, kann von einem privaten Netzwerk keine Rede mehr sein. Zum einen kann der Datenverkehr zwischen den Netzen von jedem Rechner mitgehört werden, über den die Daten geroutet werden, d. h. die Vertraulichkeit der Kommunikation ist nicht gewährleistet. Das andere große Problem ist die fehlende Authentizität, d. h. es ist nicht gewährleistet, daß der Rechner am anderen Ende einer Datenverbindung auch derjenige ist, für den er sich ausgibt (tatsächlich könnte jeder Rechner, über den die Verbindung geroutet wird, der einen Seite vorgaukeln, er sei die andere Seite).

Der klassische Ausweg liegt darin, eine eigene Leitung von einem Telekommunikationsprovider zu mieten, oder sich z. B. an ein Frame-Relay-Netzwerk eines entsprechenden Anbieters anzuschließen. Zwar sind auch diese Möglichkeiten nicht 100%ig sicher gegen Abhören bzw. Vortäuschen einer falschen Identität, aber das Gefahrenpotential wird i. A. wesentlich niedriger eingeschätzt als bei einem offenen Internetzugang. Insbesondere sind die Provider selbst hier i. d. R. auch bereit, entsprechende Gewährleistung zu bieten. Zu der höheren Sicherheit kommt noch hinzu, daß die Provider auch für Verfügbarkeit und für Bandbreite Garantien bieten, was je nach Anwendungsfall ausschlaggebend sein kann.

Die Nachteile dieser Lösungen liegen zum einen im Preis, der im Vergleich zur (meistens ohnehin schon vorhandenen) Internetanbindung erheblich höher liegt, zum anderen in der geringen Flexibilität. Standleitungen mögen sich zur Vernetzung von Standorten eignen, sie eignen sich aber nicht zur Anbindung von Außendienstmitarbeitern oder Heimarbeitern.

Bei VPNs verfolgt man nun den Ansatz, die flexible und preiswerte Internetanbindung für die vertrauliche und authentische Kommunikation verschiedener Netzwerke zu nutzen. 'Virtuell', weil die Kommunikation zwar über ein öffentliches Netzwerk läuft, aber man trotzdem noch von einem 'privaten', d. h. Vertraulichkeit und Authentizität gewähleistenden Netzwerk sprechen kann.

Die Kryptographie bietet mittels Verschlüsselungstechniken und digitaler Unterschriften Vertraulichkeit und Authentizität, entsprechende Algorithmen gibt es zuhauf. Weniger verbreitet, da noch sehr jung, sind aber Protokolle, die die kryptographischen Algorithmen auf die IP-Datentransportmechanismen anwenden. Im folgenden werden nun einige solche Protokolle und ihre Linux-Implementierungen näher betrachtet.

Sowohl bei VPNs als auch bei echten privaten Netzwerken ist zu beachten, daß das gesamte Netzwerk nicht sicherer ist als jedes der beteiligten Netzwerke! D. h. insbesondere bei VPNs, daß jedes der beteiligten Netze durch eine Firewall vom Internet abgeschottet sein muß, denn sonst kann ein Angreifer über ein nicht abgeschirmtes Teilnetz auf das gesamte VPN zugreifen.

Verschlüsselte Kommunikation im Internet

Verschlüsselte Kommunikation ist im Internet nichts Neues. Beispielsweise können die gängigen Web-Browser ihre Kommunikation mit dem jeweiligen Webserver verschlüsseln, z. B. beim Online-Shopping oder -Banking. Die entsprechenden URLs erkennt man am vorangestellten 'https://', das das übliche 'http://' ersetzt.

https steht dabei für 'http over SSL'. SSL (Secure Sockets Layer) ist ein Protokoll, das von Netscape für ebendiesen Zweck entwickelt wurde. Es unterstützt verschiedene Verschlüsselungsalgorithmen und -stärken, Authentisierung des Servers über eine X.509-Infrastruktur und optional auch Authentisierung der Clients. https-Verbindungen sind zwar die häufigste Anwendung von SSL, aber SSL ist keinesfalls darauf beschränkt. Moderne Mail-Clients können z. B. per spop oder simap Mails von einem Mailserver über eine SSL-Verbindung abrufen.

Für Linux gibt es das Tool stunnel, mit dem man sowohl die Client- als auch die Serverseite einer SSL-Verbindung erzeugen kann. Wie der Name schon sagt, arbeitet das Tool als Tunnel, d. h. an einer Seite verbindet man es mit einer ganz normalen, nicht SSL-fähigen Client- oder Serverapplikation, und die andere Seite 'spricht' SSL mit der Gegenstelle. So kann man z. B. einen nicht SSL-fähigen IMAP-Server problemlos SSL-fähig machen.

Auf ähnliche Art und Weise kann man per SSH (Secure SHell) eine verschlüsselte Verbindung zu einem anderen Recher aufzubauen, und über einen Port-Forwarding-Mechanismus zusätzliche Netzwerkverbindungen verschlüsseln. Das Protokoll ist dabei allerdings nicht standardisiert sondern proprietär.

Diese Lösungen haben mehrere Gemeinsamkeiten: sie müssen für jede einzelne Verbindung bzw. für jeden Dienst einzeln eingerichtet werden. Client- und Serversoftware müssen die Verschlüsselung oder den Tunnel unterstützen. Es werden TCP-Verbindungen verschlüsselt, d. h. UDP-Datagramme (z. B. für NFS oder SMB) oder gar andere Netzwerkprotokolle lassen sich damit nicht verschlüsseln.

Insbesondere müssen die beteiligten Rechner über das Internet direkt miteinander kommunizieren können. Damit kann aber von einem VPN keine Rede mehr sein.

CIPE

CIPE (Cryptographic IP Encapsulation) ist ein Protokoll (samt zugehöriger Software), das von Olaf Titz <olaf@bigred.inka.de> entwickelt wurde. Das Protokoll ist sehr einfach gehalten und auf das Wesentliche beschränkt. Die Konsequenz daraus ist, daß die CIPE-Software bereits seit 1997 recht stabil eingesetzt werden kann. Ebenso ist der Konfigurationsaufwand minimal.

Aus logischer Sicht arbeitet CIPE mit einer Punkt-zu-Punkt Verbindung, ähnlich einem PPP-Link. Als Transportmedium dient dabei aber nicht unmittelbar eine Modem-Wählleitung, wie üblicherweise bei PPP, sondern eine existierende IP-Verbindung, über die UDP-Pakete mit verschlüsseltem Inhalt gesendet werden. Entsprechend den PPP-Devices im Linux-Kernel gibt es bei CIPE für jede solche Punkt-zu-Punkt Verbindung ein CIPE-Device. Es ist problemlos möglich, mehrere solche Devices auf einer Maschine parallel auf verschiedenen UDP-Ports zu aktivieren.

Die Software besteht aus einem Kernel-Modul (2.0.x oder 2.2.x) und einem Daemon-Prozess. Das Kernel-Modul empfängt verschlüsselte Datenpakete aus dem Internet in Form von UDP-Datagrammen, entschlüsselt sie und leitet die entschlüsselten Pakete durch den üblichen Routing-Mechanismus weiter. Umgekehrt nimmt es unverschlüsselte Pakete entgegen, verschlüsselt sie, und leitet sie über entsprechende IP-Routes an die Gegenseite weiter. Der Daemon-Prozess übernimmt dabei die Konfiguration eines CIPE-Devices sowie den Schlüsselaustausch beim Aufbau und während der Verbindung.

CIPE benutzt für jede Punkt-zu-Punkt Verbindung einen Schlüssel (übliche Algorithmen sind IDEA oder Blowfish), der beiden Seiten bekannt ist. Auf der Sicherheit dieses Schlüssels beruht die Sicherheit der zugehörigen CIPE-Verbindung. Sowohl die Vertraulichkeit als auch die Authentizität der empfangenen Nachrichten gilt nur unter der Annahme, daß der Verbindungsschlüssel nur den beiden Gegenstellen bekannt ist.

Mit diesem gemeinsamen Schlüssel werden allerdings nur wenige Daten verschlüsselt. Für das Gros der Kommunikation werden dynamisch erzeugte Schlüssel verwendet. Dabei erzeugt jede Seite zufällig einen Schlüssel, mit dem sie fortan Daten verschlüsseln will. Dieser wird, verschlüsselt mit dem gemeinsamen statischen Schlüssel, an die Gegenseite gesendet, die anschließend den Empfang bestätigt. Sobald die Bestätigung eingegangen ist, wird der neu erzeugte Schlüssel aktiviert, weitere Daten werden nur noch mit dem dynamischen Schlüssel verschlüsselt. Dieser Schlüsselaustausch wird alle 10 Minuten wiederholt, sofern in dieser Zeit Daten gesendet werden.



Das Bild zeigt den Datenfluß zwischen zwei CIPE-Routern beim Aufbau einer Verbindung, der durch ein Datenpaket eines Clients ausgelöst wird. Die Antwort vom Server würde ganz genauso in umgekehrter Richtung gesendet. Für weitere Datenpakete werden dann die bereits ausgehandelten Schlüssel verwendet.

Dadurch, daß jeder Kommunikationspartner die Gegenseite auffordern kann, einen neuen Schlüssel zu erzeugen, ist das Protokoll stabil gegen Abstürze eines der beteiligten Rechner. Sobald er wieder hochgefahren ist, wird die Verbindung für alle Applikationen völlig transparent wieder aufgebaut. Ebenso ist das Protokoll durch die Verwendung von UDP als Transportmittel stabil gegen Ausfälle der Netzwerkverbindung. Natürlich kann während eines Totalausfalls nicht kommuniziert werden, aber nach der Wiederherstellung der Verbindung läuft der Datenaustausch weiter als wäre nichts geschehen.

Die Konfiguration eines CIPE-Devices beschränkt sich i. W. auf fünf Parameter (plus einige optionale), die in einem Device-spezifischen Konfigurationsfile festgelegt werden:

keyDer gemeinsame Schlüssel für diese Verbindung
meIP-Nummer:Portnummer auf der die verschlüsselten UDP-Pakete ankommen
peerIP-Nummer:Portnummer an die die von uns verschlüsselten UDP-Pakete gesendet werden
ipaddrIP-Adresse unseres CIPE-Devices
ptpaddrIP-Adresse des CIPE-Devices auf der Gegenseite

ipaddr und ptpaddr sind auf der Gegenseite vertauscht, ebenso me und peer falls die Rechner festen IP-Nummern haben. Bei dynamisch zugewiesenen IP-Nummern (z. B. Dialup-Verbindung) können me und/oder peer-Nummern auch mit 0.0.0.0 belegt werden.

Das und die oben angesprochene Stabilität gegen Ausfälle machen es sehr einfach, einen Dialup-Rechner mit einem anderen Rechner mit permanenter Internet-Verbindung an ein CIPE-VPN anzubinden: vom Dialup-Rechner aus gesehen spielt es keine Rolle, ob das Transportmedium zwischendurch wechselt oder nicht. Natürlich kann hier die Verbindung nur vom Dialup-Rechner aus aufgebaut werden, da der Rechner mit permanenter Anbindung keine Möglichkeit hat, den Dialup-Rechner anzuwählen.

Ein Beispiel

Das folgende Bild zeigt ein typisches Netzwerksetup in Verbindung mit CIPE. Die Netzwerkinterfaces der Rechner sind mit IP-Nummern versehen. CIPE soll die privaten Netze 10.0.0.0/24 und 10.0.1.0/24 miteinander verbinden.

Auf Router 1 sähe die CIPE-Konfiguration so aus:

# the peer's IP address
ptpaddr         192.168.0.2
# our CIPE device's IP address
ipaddr          192.168.0.1
# my UDP address. Note: if you set port 0 here, the system will pick
# one and tell it to you via the ip-up script. Same holds for IP 0.0.0.0.
me              131.246.89.1:6789
# ...and the UDP address we connect to. Of course no wildcards here.
peer            194.162.122.2:6544
# The static key. Keep this file secret!
# The key is 128 bits in hexadecimal notation.
key             feedfacedeadbeeffeedfacedeadbeef

Auf Router 2 wären me und peer bzw. ipaddr und ptpaddr genau vertauscht:

ptpaddr         192.168.0.1
ipaddr          192.168.0.2
me              194.162.122.2:6544
peer            131.246.89.1:6789
key             feedfacedeadbeeffeedfacedeadbeef

Router 1 hätte folgende Routing-Einträge:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.1.0        192.168.0.2     255.255.255.0   U     0      0        0 cipcb0
0.0.0.0         131.246.88.1    0.0.0.0         UG    0      0        0 ppp0

und bei Router 2 sähe das so aus:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.0.0        192.168.0.1     255.255.255.0   U     0      0        0 cipcb0
0.0.0.0         194.162.122.1   0.0.0.0         UG    0      0        0 ppp0

(Die IP-Adressen 131.246.89.1 bzw. 194.162.122.2 sind frei erfunden, ebenso die Default-Gateways der beiden Router, 131.246.88.1 und 194.162.122.1.)

IPSec

IPSec ist sozusagen die 'offizielle' Art, ein VPN zu erzeugen. IPSec ist ein ganzes Konglomerat von Standards, die in mehreren RFCs von einer Working Group der IETF (Internet Engineering Task Force) festgelegt sind. Für die nächste Version des Internetprotokolls, IP Version 6, ist die Implementierung der IPSec-Paketheader Pflicht. Die Standards sind dabei so formuliert, daß sie sowohl auf IPv4- als auch auf IPv6-Pakete angewendet werden können, d. h. die heute gängigen Implementierungen von IPSec sind i. d. R. auf IPv4-Protokollstacks ausgerichtet.

Überblick
RFC-Nr.Inhalt
2401Security Architecture for the Internet Protocol
2411IP Security Document Roadmap
2402IP Authentication Header
2406IP Encapsulating Security Payload (ESP)
2408Internet Security Association and Key Management Protocol (ISAKMP)
2409The Internet Key Exchange (IKE)

Es ist nicht zu empfehlen, diese RFCs in obiger (oder sonst einer) Reihenfolge durchzulesen um zu verstehen, was IPSec ist. Vielmehr sollte man sich zunächst an allgemeine Beschreibungen (wie z. B. dieses Dokument) halten, um anhand der RFCs speziellen Fragen nachzugehen, so diese auftauchen.

So umfangreich wie die Liste der RFCs ist auch die Liste der Ziele, die diese sich stellen. Unter anderem werden genannt: "access control, connectionless integrity, data origin authentication, protection against replays, confidentiality and limited traffic flow confidentiality". Kurz gesagt: man soll mit IPSec VPNs realisieren können. ;-) Genaugenommen geht IPSec allerdings noch weiter.

Zum Einen wird unterschieden, ob IPSec zwischen Hosts oder zwischen sog. "Security Gateways" angewendet wird (oder zwischen Host und Security Gateway). Ein Security Gateway ist üblicherweise ein Router, der IP-Daten von einem Netzwerk über einen anderen Security Gateway in ein anderes Netzwerk tunnelt, und zwar verschlüsselt und authentisch. Die Situation ist bereits aus dem vorigen Kapitel bekannt. Die Möglichkeit, daß zwei Hosts direkt miteinander "IPSec sprechen" ist im Vergleich mit CIPE dagegen neu. Technisch sieht die Unterscheidung so aus, daß man die Betriebsarten "Tunnel Mode" und "Transport Mode" unterscheidet. Der Unterschied zwischen diesen besteht darin, daß die verschiedenen Protokollarten im Tunnel Mode auf gekapselte IP-Pakete angewendet werden, die mit einem neuen IP-Header versehen werden, während im Transport Mode die ursprünglichen IP-Header unverändert erhalten bleiben.

Zum anderen wird über eine 'Security Policy Database' und eine 'Security Association Database' für jedes Datenpaket ermittelt, welche IPSec-Mechanismen darauf anzuwenden sind. Insbesondere enthalten diese 'Datenbanken' Informationen über die zu verwendenden Algorithmen und Schlüssel. Dies erlaubt eine sehr flexible Konfiguration des IPSec-Systems. Die Flexibilät ist sogar ausreichend für sogenannten 'opportunistische Verschlüsselung', d. h. Systeme können miteinander vertraulich kommunizieren, ohne daß dies jemals explizit vorgesehen wurde. Der Schlüsselaustausch findet dabei mit Public-Key-Alogrithmen statt, die auf einem Protokoll ausgehandelt werden, das oberhalb von OSI-Schicht 4 anzusiedeln ist. Authentisiert werden die Hosts bzw. Gateways dabei z. B. auf Basis von X.509-Zertifikaten. Das ist allerdings zum größten Teil noch in Planung, da dafür (noch) keine globale Infrastruktur existiert.

Struktur von IP-Paketen, Security Policies, Security Associations

Zum Verständnis der folgenden Abschnitte folgt hier zunächst einmal ein grober Überblick über die Struktur von IP-Paketen.

IP-Pakete bestehen aus einzelnen Blöcken unterschiedlicher Länge. Jeder Block (außer evtl. dem letzten) enthält bestimmte Header-Informationen, und ein Byte, das den Typ des folgenden Blocks angibt. Der erste Block eines IP-Pakets ist grundsätzlich ein IP-Headerblock. Er enthält i. W. eine Versionsnummer, grundlegende Adressinformationen (IP-Adressen Absender / Empfänger), die Gesamtlänge des Pakets, und den Typ des folgenden Blocks. Der folgende Block kann z. B. ein TCP- oder UDP-Headerblock sein, die wiederum Portnummern, Nutzdaten usw. enthalten.

IPSec führt nun zwei neue Blocktypen ein, nämlich den Authentication Header (AH) und den Encapsulating Security Payload (ESP) Header. Sie dienen der Sicherung der Authentizität und Vertraulichkeit der übertragenen Nutzdaten. Wichtig ist dabei, das der Nutzdatenteil im Tunnel Mode ein komplettes IP-Paket enthält, d. h. er beginnt wiederum mit einem IP-Header. Im Transport Mode beginnen die Nutzdaten mit einem Protokollheader, also z. B. TCP oder UDP. Im Fall von ESP können die Nutzdaten dabei verschlüsselt sein, also für einen Lauscher unverständlich.

Insbesondere können aber die im AH oder ESP-Header enthaltenen Nutzdaten auch wieder AH- oder ESP-Blöcke sein, d. h. es ist möglich, verschiedene IPSec-Protokolle ineinander zu schachteln.

Die im Folgenden beschriebenen Begriffe "Security Policy", "Security Association" und "Security Parameter Index" sind für ein grobes Verständnis von IPSec nicht so wichtig. Wer die angegebenen RFCs durchlesen möchte, wird allerdings darum nicht herumkommen.

Security Policies geben an, ob und welche IPSec-Methoden auf eingehende und zu versendende Datenpakete anzuwenden sind. Für Pakete, die mit IPSec zu behandeln sind, geben sie die zugehörige Security Association an. Die Security Policy bestimmt praktisch die statische Konfiguration von IPSec-Verbindungen, also z. B. mit welchen Hosts oder Gateways wie zu kommunizieren ist.

Security Associations dienen der Zuordnung von IP-Paketen zu einer zu einem Satz für die Verbindung ausgehandelter Konfigurationsparameter. Der Parameter-Satz gilt nur für eine Datenrichtung, d. h. je nach Konfiguration ist es z. B. möglich, Daten nur in einer Richtung zu verschlüsseln, oder unterschiedliche Verschlüsselungsalgorithmen und -schlüssel zu verwenden. Security Associations enthalten also die flüchtigen Konfigurationsparameter von IPSec-Verbindungen, wie z. B. Sessionkeys.

Policies und Associations werden anhand von Daten aus den betrachteten IP-Paketen ausgewählt, z. B. Ziel-IP-Nummer, Protokolltyp, Security Parameter Index etc. Der Security Parameter Index (SPI) ist eine Nummer, die der eindeutigen Zuordnung einer IPSec-Verbindung zu einem Parameter-Satz dient. Wenn für eine bestimmte Verbindung z. B. ein neuer Sessionkey ausgehandelt wird, wird eine neue Security Association mit einem neuen SPI eingerichtet, die den neuen Schlüssel aufnimmt. Anhand des SPI kann die neue Security Association von der alten unterschieden werden, obwohl alle anderen Parameter gleich geblieben sind.

Authentisierung (AH)

Der Authentication Header (AH) ist ein Protokollheader mit der Protokollnummer 51. Er beinhaltet eine digitale Signatur sowohl der enthaltenen Nutzdaten als auch eines Teils des äußeren IP-Headers. Außerdem enthält er zur Verhinderung von Replay-Attacken eine Sequenznummer. Der Empfängerhost oder -gateway kann anhand der Sequenznummer feststellen, ob das Paket schon einmal empfangen wurde, und es ggfs. fallenlassen.

Da ein Teil des äußeren IP-Headers sich bei der Übertragung zum Gegenüber verändern kann (z. B. Time-To-Live), bezieht sich die Authentisierung nur auf die unveränderlichen Teile desselben sowie den authentication header selbst und die enthaltenen Nutzdaten. Im Tunnel Mode stellen die Nutzdaten wiederum ein komplettes IP-Paket dar. Ebenso können die Nutzdaten auch ein bereits mit ESP verschlüsseltes Datenpaket sein.

Jede IPSec-Implementierung muß mindestens die Authentisierungsalgorithmen HMAC-MD5 und HMAC-SHA-1 unterstützen. Die Algorithmen basieren auf einem gemeinsamen geheimen Schlüssel beider IPSec-Endpunkte in Verbindung mit je einer Hashfunktion.

Verschlüsselung (ESP)

ESP (Encapsulated Security Payload) war ursprünglich nur für die Verschlüsselung von Nutzdaten gedacht. Es hat sich jedoch gezeigt, daß Verschlüsselung ohne Authentisierung Sicherheitsrisiken mit sich bringt. Daher wurde zusätzlich in ESP noch ein Authentisierungsmodus eingebaut. Im Unterschied zur Authentisierung im AH bezieht sich bei ESP die Integritätssicherung nur auf den ESP-Block selbst (inclusive der evtl. verschlüsselten Nutzdaten). Auch der Sequenzzähler als Absicherung gegen Replay wurde in ESP übernommen.

An unterstützten Verschlüsslungsalgorithmen ist für IPSec-Implementierungen nur DES im CBC-Mode vorgeschrieben. Zusätzlich gibt es die gleichen Authentisierungsalgorithmen wie im AH (HMAC-MD5 und HMAC-SHA-1), sowie einen NULL-Verschlüsselungsalgorithmus und einen NULL-Authentisierungsalgorithmus. Von den letztgenannten darf nur jeweils einer in einer Security Association verwendet werden. Ein ESP-Block ohne Verschlüsselung und ohne Authentisierung würde ohnehin nur Overhead verursachen.

Key Management (ISAKMP/IKE)

AH und ESP authentisieren und verschlüsseln Daten mit Hilfe von Schlüsseln. Aber woher kommen diese Schlüssel, bzw. wie einigen sich die beiden Enden einer IPSec-Verbindung auf diese Schlüssel? Wie üblich gibt es da verschiedene Möglichkeiten. ISAKMP (Internet Security Association and Key Management Protocol) spezifiziert dazu ein Framework für Schlüsselaustauschprotokolle. Es sieht zunächst eine erste Phase für die gegenseitige Authentisierung und den Schlüsselaustausch für das ISAKMP-Protokoll an sich vor. In der zweiten Phase können dann beliebig viele Nachrichten sicher und authentisch ausgetauscht werden, i. W. Nachrichten zur Aushandlung und Verwaltung von Security Associations. Die Authentisierung kann entweder über ein gemeinsames Geheimnis erreicht werden, oder über Public-Key-Verfahren, z. B. RSA.

Während ISAKMP nur ein allgemeines Framework für Schlüsselaustauschprotokolle spezifiziert und die konkrete Ausgestaltung weiteren RFCs überläßt, ist IKE, die Internet-Key-Exchange eins von mehreren konkreten Schlüsselaustauschprotokollen. Es kombiniert Techniken der Protokolle Oakley und SKEME mit dem Ziel, die Vorteile beider im ISAKMP-Framework zu vereinen.

IPSec mit Linux: FreeS/WAN

S/WAN steht für 'Secure Wide Area Network', was in etwa das Gleiche bedeutet wie VPN. Free steht für (kosten-)frei. FreeS/WAN ist also eine kostenfreie Implementierung von VPNs, und zwar auf Basis von IPSec.

Derzeit (April 2000) in der Version 1.3 verfügbar ist FreeS/WAN als "Work in Progress" zu betrachten. D. h. einige in IPSec spezifizierte Features sind implementiert, andere aber (noch) nicht. FreeS/WAN verzichtet auf die im RFC vorgeschriebene DES-CBC-Verschlüsselung, da DES nicht mehr zeitgemäß und als unsicher anzusehen ist. Laut Dokumentation hat die IETF aber schon angekündigt, auf DES zugunsten von Triple-DES zu verzichten, so daß mit der nächsten IPSec-Version FreeS/WAN möglicherweise RFC-konform werden kann. Laut der FreeS/WAN-Dokumentation wurde bereits die Kompatibilität zu verschiedenen anderen Produkten z. B. von CISCO erfolgreich getestet. Insofern ist die buchstabengetreue Umsetzung der RFCs in der Praxis von untergeordneter Bedeutung.

Ebenso wie CIPE besteht FreeS/WAN aus einem Kernel-Teil und verschiedenen User-Space-Programmen. Das mitgelieferte Installationsskript modifiziert die in /usr/src/linux vorhandenen Kernel-Sourcen (Version 2.0.38 oder 2.2.14 werden derzeit unterstützt) soweit erforderlich. Man sollte darauf achten, daß man die Sourcen bereits vorher fertig konfiguriert und den resultierenden Kernel getestet hat, das erleichtert später ggfs. die Fehlersuche...

Abgesehen von der nötigen manuellen Installation des Kernels (z. B. über LILO) und der natürlich erforderlichen Anpassung der Konfigurationsdateien läuft das Compilieren und Installieren der Programme völlig automatisch ab, sogar die beim Booten erforderlichen Startup-Skripte werden vom mitgelieferten Makefile erzeugt.

Alles, was zum Betrieb einer sehr einfachen IPSec-Verbindung noch nötig ist, ist die Eingabe der richtigen IP-Nummern in der Konfigurationsdatei /etc/ipsec.conf. Per Default sind bereits geheime Schlüssel für ESP installiert, die allerdings ausschließlich zum Testen verwendet werden dürfen. Für eigene IPSec-Verbindungen sollte man die automatische Schlüsselgenerierung über den Pluto-Daemon verwenden. Pluto implementiert das IKE-Protokoll und kann entweder per RSA-public-key oder über ein gemeinsames Geheimnis sein Gegenüber identifizierung und dann über den authentischen und sicheren Kanal Schlüssel mit der Gegenseite austauschen.

Laut Dokumentation soll es mit der Public-Key-Authentisierung sogar möglich sein, Dialup-Rechner an ein VPN anzuschließen. Bis zur Abgabe dieses Papers ist es dem Autor allerdings nicht gelungen, das nachzuvollziehen.

Die Konfiguration einer IPSec-Verbindung ist dem größeren Funktionsumfang entsprechend etwas aufwendiger. Die Konfigurationsdatei ipsec.conf ist in mehrere Abschnitte untergliedert. Es gibt Abschnitte für Grundeinstellungen, Abschnitte für Defaultwerte bei der Wahl von Algorithmen, und schließlich verbindungsspezifische Abschnitte. Hier ein Beispiel für eine Konfigurationsdatei, die zu dem Netzwerksetup des CIPE-Beispiels (s. o.) paßt.

# basic configuration
config setup
        # THIS SETTING MUST BE CORRECT or almost nothing will work;
        # %defaultroute is okay for most simple cases.
        interfaces=ppp0

# defaults for subsequent connection descriptions
conn %default
        # How persistent to be in (re)keying negotiations (0 means very).
        keyingtries=0

# sample connection
conn sample
        # Left security gateway, subnet behind it, next hop toward it.
        left=131.246.89.1
        leftsubnet=10.0.0.0/24
        leftnexthop=131.246.88.1
        leftrsasigkey=0x01035ab27b9c03a1fc302ac06dd8232292ffb1c1fb46d7b59d2d6ee0a1be1f38405d86cb0635b0c0781e34759b2113ee3f9b22d34fea1de766456e751ec9e1a364fae49a867865c3e1950aa7482563ff7bdf53713edd590cd3e0e7b88f535f8cdf4bc3a7e99f116350d8822df440e6f842a52b10c601f33266138a785431d923e1bf
        # Right security gateway, subnet behind it, next hop toward it.
        right=194.162.122.2
        rightsubnet=10.0.1.0/24
        rightnexthop=194.162.122.1
        rightrsasigkey=0x0103a3671f78c01808daa7940722cca3f487652440e3524476745029d371927f83797324ed0ea35148c87d82ef37bc922406e9ba5a4762b0cadbe6da4cb78bbaff86787df62fae6db9761766f95d638e82fd9ad62735627ea8d54e157b0a6824a6bc45d0b7f0aefc0327640aefa2469d36ea57f4244826b8823614ce0425640735a5
        authby=rsasig
        # Authorize this connection, but don't actually start it, at startup.
        auto=add

Dabei ist es völlig unerheblich, welcher der Rechner die Bezeichnung "left" bzw. "right" bekommt. Entscheidend ist der Parameter "interfaces" - FreeS/WAN ermittelt die IP-Nummern der hier angegebenen Interfaces und stellt dann fest, ob entweder der left- oder der right-Parameter dazu passen. Demzufolge können die verbindungsspezifischen Konfigurationsteile auf beiden Seiten identisch sein, wenn die globalen Parameter (Interfaces) ebenfalls übereinstimmen, kann man die ipsec.conf-Datei einfach vom einen auf den anderen Router übernehmen.

In diesem Beispiel besitzt jeder Rechner ein eigenes RSA-Schlüsselpaar. In der ipsec.conf-Datei stehen die beiden Public-Keys. Die Private Keys sind natürlich nur jeweils einem Rechner bekannt. Sie stehen in der Datei /etc/ipsec.secrets z. B. so drin:

131.246.89.1: rsa {
        Modulus: 0x88715df6a9b48a3a6343bf7d4c05ff3ecdbe70192e710ac397b9602986b18a7d288e2346ad49052936fb0851f2c86ccce476e56c71b34c8ba31860ce1b47dd21
        PublicExponent: 0x03
        # everything after this point is secret
        PrivateExponent: 0x5af63ea4712306d197827fa8dd5954d48929a010c9a0b1d7ba7b957104765c526edf117d8dc348fc0dbfc52585ee6faedaad63bd3dcc0d65749dc232c0f984cb
        Prime1: 0xf1c8138e7b4be586adef78ba9cd368dc155ebf74d36658af0dcd2261d9365f9d
        Prime2: 0x9077757bdd583228746be7df0d0f5c6a8714105bc19adfc4665e9b20209b3655
        Exponent1: 0xa1300d09a787ee59c94a507c688cf092b8e9d4f88ceee5ca09336c413b799513
        Exponent2: 0x604fa3a7e8e576c5a2f29a94b35f92f1af62b5928111ea82eee9bcc015bccee3
        Coefficient: 0x63991dc89eb267966118ecc337f9adb1ee0100ed2752f0a44142c9768fbc489c
        }

Die 131.246.89.1 hier weist dem Pluto-Daemon darauf hin, daß dieser RSA-Schlüssel für eine IPSec-Verbindung in Frage kommt, bei der entweder left oder right die Adresse 131.246.89.1 hat. Da ein Public-Key-Verfahren in der Regel für mehrere IPSec-Verbindungen eines Hosts verwendet werden kann, genügt hier die Angabe der eigenen IP-Nummer. Bei der Verwendung eines gemeinsamen Geheimnisses zur gegenseitigen Authentisierung würden typischerweise die IP-Nummern beider Seiten angegeben.

Die Generierung von Public- und Private Key erfolgt durch einen Aufruf des ipsec-Tools, über das man auch das komplette Setup der Verbindungen steuern kann.

Microsoft PPTP

PPTP (Point-to-Point Tunneling Protocol) ist eine Erweiterung des verbreiteten PPP-Protokolls, die inzwischen (seit Mitte '99) als RFC-2637 standardisiert ist. Die Erweiterung bietet (in diesem Zusammenhang) zunächst nur die Möglichkeit, eine PPP-Verbindung über ein existierendes IP-Netz zu tunneln. Die PPP-Datenpakete werden dabei mittels GRE (Generic Routing Encapsulation) gekapselt und zur Gegenstelle gesendet. Zusätzlich besteht eine TCP-Verbindung für Control-Messages (Verbindungsaufbau, -abbau etc.). Im Gegensatz zu PPP besitzt PPTP eine Client-Server-Struktur, d. h. der Client baut die TCP-Control-Verbindung zum Server auf und bittet um den Aufbau einer PPP-Verbindung.

PPTP an sich beinhaltet weder Verschlüsselung noch Authentisierung. Das wird alles durch das unterliegende PPP-Protokoll geregelt. Die Microsoft-Implementierung verwendet MS-CHAP zur Authentisierung des Clients gegenüber dem Server. Zusätzlich wird über CCP-Messages (eigentlich: Compression Control) die Verschlüsselung ausgehandelt. Microsoft verwendet das Verschlüsselungsprotokoll 'Microsoft Point-to-Point Encryption' (MPPE), das wiederum den RC4-Verschlüsselungsalgorithmus benutzt.

Neben den üblichen Schwächen ('Verstümmelung' der Schlüssellänge auf 40 Bits), die aufgrund der US-Exportbestimmungen zu erwarten waren, hat eine unabhängige Analyse eine ganze Reihe Angriffspunkte sowohl an den von der Windows-Standardimplementierung verwendeten Authentisierungs- und Verschlüsselungsmethoden als auch am Datenhandling an sich aufgedeckt. Die wichtigsten sind:

  1. Das Client-Paßwort wird mit zwei unterschiedlichen Verfahren gehashed, von denen eines besonders leicht einen Wörterbuch-Angriff erlaubt. Beide Hash-Werte stehen dem Angreifer zur Verfügung.
  2. Authentisierung findet nur in einer Richtung statt: der Client weist seine Identität per Paßwort nach, der Server nicht.
  3. Der Datenstrom wird in beiden Richtungen mit demselben Schlüssel und ohne zufälligen Initialisierungsvektor verschlüsselt. Das erlaubt einen XOR-Angriff, bei dem man das XOR der Plaintexts erhält, da beide Datenströme mit dem gleichen Schlüsselstrom verschlüsselt werden.
  4. Der Schlüssel wird nur aus öffentlich bekannten Informationen und dem User-Paßwort bzw. dem Paßworthash gebildet. Damit hat der Schlüssel selbst bei der 128-Bit-Version effektiv nur soviel Entropie wie das Paßwort - also in aller Regel wesentlich weniger als 128 Bit.
  5. Die gesamte Control-Verbindung sowie ein Teil der PPP-Protokollaushandlung bleiben unverschlüsselt.
  6. Die Implementierung des Servers ist so instabil, daß einige falsche Daten an den Control-Port das komplette Windows-NT-System zum Absturz bringen ('Blue Screen').
Nach der Veröffentlichung der Analyse wurde von Microsoft nachgebessert, die Fassung MS-CHAPv2 kann man bei Microsoft downloaden. Eine erneute Analyse bestätigte zwar die Beseitigung mancher Schwachstellen (insbesondere die oben aufgeführten Nummern 1-3 und 6), förderte aber einen bisher unbeachteten Angriff zutage. Bei der 40-Bit-Version von MPPE ist ein Angriff der Komplexität 2^26 auf die Verschlüsselung möglich, d. h. mit einem Standard-PC läßt sich innerhalb von Minuten der richtige Schlüssel finden. Hinzu kommt das Problem, daß die wenigsten Rechner auf MS-CHAPv2 umgestiegen sind, und daher die meisten PPTP-Server in einem Kompatibilitätsmodus laufen, der sowohl die alte als auch die neue Fassung akzeptiert.

Zwar ist die Software sicher die am weitesten verbreitete VPN-Lösung (allein aufgrund der Tatsache, daß es bei Windows-95/98/NT zum Lieferumfang gehört). Aufgrund der Schwächen eignet es sich aber nicht für den professionellen Einsatz.

Fazit

Es gibt eine Reihe von Möglichkeiten, mit Hilfe von Linux-Rechnern VPN-Strukturen aufzubauen. In diesem Vortrag wurden einige wichtige Methoden näher betrachtet. Daneben gibt es aber noch eine Reihe anderer Ansätze, die Auswahl der hier vorgestellten ist dabei relativ willkürlich. Der geneigte Leser mag sich selbst anhand der weiter unten aufgeführten URLs ein Bild davon verschaffen.

Zusammenfassend hier nochmal die Vor- und Nachteile der wichtigsten Methoden:

CIPE ist in einer Linux-Umgebung nicht leicht zu überbieten. Es ist sehr schlank ausgelegt, leicht zu konfigurieren, und erfüllt in den allermeisten Fällen alle wichtigen Anforderungen an eine VPN-Lösung. Die größte Schwäche von CIPE ist sicherlich die Festlegung auf die Plattform Linux bzw. die damit verbundene Inkompatibilität zu anderer gängiger Router-Hard- und Software.

Demgegenüber hat IPSec den Vorteil, ein offizieller Internet-RFC zu sein. Damit einher geht (zwar nicht automatisch, aber in diesem Fall tatsächlich) die Chance, daß Produkte verschiedener Hersteller richtig miteinander "IPSec sprechen" können. Eine weitere wichtige Eigenschaft von IPSec ist, daß es sich um einen sehr umfangreichen Standard handelt, der praktisch keine Wünsche offenläßt und praktisch jedes Problem i. B. auf VPNs löst. Was sich dabei so positiv anhört ist auf der anderen Seite ein großer Nachteil: jede IPSec-konforme Soft- oder Hardware ist entsprechend groß und komplex, ebenso ist die Konfiguration und Administration komplexer als bei CIPE.

Es ergibt sich folgender Vorschlag für eine Einteilung der Lösungen nach Anwendungsfällen:
Kurzfristiger, zeitlich begrenzter sicherer TCP-Zugriff auf einzelne Dienste Tunnel durch SSH oder SSL
Kurz- bis mittelfristiger Bedarf an verschlüsselter IP-Datenkommunikation aller Art über Linux-Infrastruktur CIPE
Langfristiger Bedarf an verschlüsselter IP-Datenkommunikation mit nennenswertem Anteil an nicht-Linux-Produkten IPSec-basierte Lösung

Der entscheidende Vorteil von IPSec, nämlich in RFCs spezifiert zu sein, macht es zum Mittel der Wahl bei langfristigen Lösungen, und bei solchen, bei denen Kompatibilität mit anderen Produkten eine Rolle spielt. CIPE dagegen kann durch seine Einfachheit als schnelle Lösung dort eingesetzt werden, wo die Kompatibilität keine Rolle spielt.

Referenzen / Links