Application Sheet. Für die Umsetzung der VPN-Technologie bieten sich unterschiedliche Protokolle und Standards an. Die bekanntesten sind IPSec,..

Transkript

1 Virtuelle Private Netze (VPN) Eine VPN-Verbindung erlaubt Mitarbeitern den Zugriff auf Ressourcen des Netzwerks eines Unternehmens von beliebigen Endgeräten im Internet. Mit Hilfe dieser Technologie können die Mitglieder, die nicht im unmittelbaren Netzbereich arbeiten aber über eine Internetverbindung verfügen, ihren externen Arbeitsplatz mittels VPN mit dem entfernten Firmennetzwerk verbinden. Authentifizierung und Verschlüsselung gewähren die Datensicherheit. Es können sowohl Nutzer- und Rechner-Authentifizierungsmechanismen, als auch hochwertige kryptografische Verfahren eingesetzt werden. Ein solcher Rechner befindet sich aus Sicht des Nutzers virtuell im Firmennetzwerk, so dass der Begriff Virtuelles Privates Netz gerechtfertigt ist. Im Zusammenhang mit VPN wird immer auch von Tunneltechnologien gesprochen. Der Begriff Tunnel rührt aus dem Übertragungsverfahren heraus. Im Internet werden Daten meist mit Hilfe des TCP/IP Protokolls übertragen. Hierfür werden die Daten in Pakete aufgeteilt. Jedes dieser Pakete erhält einen Header, in dem u.a. die Sender- und Empfängeradresse und die Paketgröße angegeben sind. Jedes dieser Pakete wird einzeln versandt und der Empfänger setzt diese Pakete wieder zu den Ursprungsdaten zusammen. Sollte eines der Pakete verloren gegangen sein, fordert der Empfänger dieses erneut beim Sender an. Bei der Tunneltechnologie nutzt man das vorhandene Medium, das Internet, und überträgt in den IP-Paketen selbst wieder IP-Pakete. Letztere nutzen dann die IP-Adressen aus dem privaten Netz und können verschlüsselt werden. VPN-Protokolle und Standards Für die Umsetzung der VPN-Technologie bieten sich unterschiedliche Protokolle und Standards an. Die bekanntesten sind IPSec,.. IPSecurity Das Protokoll IP Security (IPSec) hat seit über 10 Jahren bestand und gilt allgemein hin als sicher. Mit IPSec ist es möglich, IP-Pakete kryptographisch gesichert über öffentliche Netze zu transportieren. Seite 1 von 13

2 IPSec bietet die Sicherungsarten Authentication Header (AH) und Encapsulation Security Payload (ESP) jeweils in Kombination mit den Betriebsmodi Tunnel oder Transport. Mit AH kann der Anwender nur die Integrität und Echtheit der Daten sicherstellen, indem über jedes verschickte Paket ein HMAC (siehe Glossar) gebildet wird. AH wird nur selten eingesetzt, denn ESP ist die verschlüsselte Variante der Kommunikation. Zusätzlich schützt eine Integritätssicherung vor Manipulationen. Bei ESP fließt etwa die IP-Adresse nicht in die Berechnung des HMAC ein, sodass sich diese manipulieren lässt. Dies erlaubt aber trotzdem kein IP-Spoofing, da eine Authentisierung der Kommunikationspartner beim Tunnelaufbau stattfindet. Üblicherweise kommt die Kombination ESP und Tunnelmode auf VPN-Gateways zum Einsatz, wenn entfernte Subnetze miteinander über ein unsicheres Netz gekoppelt werden. Sollen zwei Rechner miteinander über IPSec im LAN kommunizieren, so wählt man meist den Transport-Mode. Die kryptographischen Funktionen beruhen auf symmetrischen Schlüsseln. Um diese nicht vorab austauschen zu müssen, handelt das Internet-Key-Exchange-Protokoll (IKE) diese beim Aufbau der Verbindung dynamisch aus. Nebenbei erledigt IKE auch noch die Authentifizierung der Teilnehmer und das Aushandeln der Security Associations (SA), in denen die Konfiguration der Verbindung festgehalten wird. Da der IPSec-Standard bereits einige Jahre auf dem Buckel hat, sind dort einige Netzkonfigurationen nicht berücksichtigt. So hat IPSec immense Probleme mit dem heute in vielen Netzen eingesetzten NAT, weil dabei das IPSec-Paket verändert wird. Je nach NAT erhält ein Paket eine neue IP-Adresse und gegebenenfalls noch eine neue Quell-Portnummer. AH, egal ob im Transport- oder Tunnel-Mode, streckt hier sofort die Waffen. Weil der Paket- Header verändert wurde, stimmt der HMAC nicht mehr. Bei ESP ist es etwas komplizierter: Um Ports umzuschreiben, müsste ein NAT-Router den TCP/UDP-Header lesen können. Der Original-Header ist aber verschlüsselt, sodass eine Zuordnung unmöglich ist. Mit ESP im Tunnelmode würde NAT zwar klappen, vorher scheitert aber schon IKE an NAT. Denn IKE kommuniziert fest über den UDP-Quell- und Zielport 500. Wird der verändert, kommt keine Verbindung zu Stande. Einige Router unterstützen deshalb das IPSec-Passthrough-Verfahren, bei dem die IKE-Ports nicht verändert werden. Zudem leitet der Router ESP-Pakete damit richtig weiter. Da die ESP-Pakete nur einer Verbindung zugeordnet werden können, funktioniert Passthrough nur mit einem einzigen Client. Um sich nicht auf den Router verlassen zu müssen, ist das ursprüngliche IPSec daher kaum noch gebräuchlich. Vielmehr setzt man es mit der IPSec-Erweiterung NAT-Traversal ein (RFCs 3947 und 3948). Dabei tauschen beide Seiten über das NAT- Traversal-Protokoll verschiedene Informationen aus. Anschließend werden ESP-Pakete in Seite 2 von 13

3 UDP-Pakete verpackt und über Port 4500 verschickt. Nun können NAT-Router ohne Probleme sowohl IP-Adressen als auch Ports umschreiben. SSL-VPN Neuere Entwicklungen setzen sich gegenüber dem in die Jahre gekommenen IPSec-VPN Zug um Zug mehr durch. SSL-VPN setzt zur Sicherung auf die Standards Secure Socket Layer (SSL) beziehungsweise Transport Layer Security (TLS). Der Begriff SSL-VPN hat derzeit zwei Bedeutungen: Zum einen bezeichnet clientless SSL-VPN den Web-Zugriff von entfernten Anwendern per SSL-Verbindung auf einen Server, die bestimmte Applikationen anbietet, etwa Datenbankzugriffe mittels Webbrowser. Der Vorteil: https ist in jedem Browser eingebaut, ist erprobt und kommt überall durch. Der Nachteil: Um auch mit nicht webbasierenden Anwendungen zu arbeiten, müssen auf Client- und/oder Serverseite Umsetzer mitlaufen, etwa Java-Plug-ins, die deren Daten über die Browserverbindung umleiten. Die zweite Gruppe sind Lösungen wie OpenVPN, die IP-Pakete transparent tunneln und somit unabhängig von der Anwendung sind. SSL und TLS unterscheiden sich kaum: Das ursprünglich von Netscape entwickelte SSL wurde ab Version 3.0 mit einigen kleineren Änderungen übernommen und TLS 1.0 genannt. TLS unterstützt zur Authentisierung der Daten HMAC und erzeugt das Schlüsselmaterial mit einer anderen Funktion als SSL (PRF statt RAND). Bei der Nachrichtenübermittlung gibt sich TLS als SSL-Version 3.1 zu erkennen. Das TLS-Protokoll nutzt zwei Schichten: Den Record Layer und die darauf aufsetzenden Protokolle. Über das TLS-Handshake-Protokoll einigen sich die Peers auf einen individuellen symmetrischen Sitzungsschlüssel, beispielsweise wie auch bei IPSec mit Hilfe von Diffie- Hellman, und mit welchen Algorithmen verschlüsselt und authentisiert werden soll. TLS nutzt insgesamt vier Schlüssel: je einen zum Ver- und Entschlüsseln sowie je einen zur Authentisierung ankommender und abgehender Pakete. Zur Authentifizierung dienen in der Regel Zertifikate. mit bidirektionale Authentifizierung. Nicht nur der Server beglaubigt mit dem SSL-Zertifikat seine Identität, auch der Client authentifiziert sich mit Hilfe des Zertifikates. Die Open-Source-Lösung OpenVPN nutzt ebenfalls TLS, geht aber ein paar Umwege, um statt reiner Anwendungsdaten IP-Pakete und sogar Ethernet-Frames sowie alle darüber liegenden Protokolle zu tunneln. OpenVPN nutzt für die Datenübertragung bevorzugt das zustandlose UDP, das keine Flusskontrolle für den Datenverkehr kennt. Der Grund: Beim Einkapseln des von den meisten Anwendungen benutzten TCP in andere TCP-Pakete Seite 3 von 13

4 entstehen durch die ineinander geschachtelten TCP-Flusskontrollalgorithmen Interferenzen. In der Folge kann es zu hoher Latenz und Verbindungsabbrüchen kommen. Da TLS per Definition nur über TCP funktioniert, muss OpenVPN tricksen und gaukelt TLS einfach einen zuverlässigen TCP-Layer vor. Steht der Tunnel, verschlüsselt OpenVPN alle über sein tun/tap-interface ankommenden Pakete, schreibt einen Initialisierungsvektor davor, authentisiert das Ganze per HMAC und verschickt es über den UDP-Tunnel. Auf der Empfängerseite arbeitet OpenVPN alle Schritte in umgekehrter Reihenfolge ab und leitet das Paket weiter. Bei TLS wird der gesamte Verkehr über einen einzigen UDP-Port abgewickelt. Dazu multiplext der Server sowohl den TLS-Handshake als auch die verschlüsselten Pakete auf eine Verbindung. Da OpenVPN weder die IP-Adresse noch die UDP-Portnummer des Paketes authentisiert, bereiten NAT-Router auf dem Weg zum Empfänger keine Probleme. Auch Road Warrior mit dynamischen IP-Adressen bedient OpenVPN klaglos. Selbst der Server darf eine dynamische IP-Adresse haben. Dem Client reicht beispielsweise die Angabe eines DynDNS-Namens, um den Server zu erreichen. OpenVPN eignet sich obendrein auch zur Kopplung entfernter Netze. Point-to Point Tunneling Protocol Das hauptsächlich unter Windows eingesetzte Point-to-Point Tunneling Protocol (PPTP) ist ein VPN-Verfahren für Remote Access und setzt eine verschlüsselte PPP-Brücke auf. Das Point-to-Point-Protokoll (PPP) dürfte den meisten Anwendern geläufig sein: Es sorgt für den Verbindungsaufbau des heimischen PC und die Datenübertragung über Modem- und ISDN- Wählzugängen zum Internet-Provider. Grundsätzlich kann PPP beliebige Protokolle aus höheren Schichten transportieren, wie etwa IP, IPX, NetBIOS und Appletalk. Bei der Einwahl ins Internet funktioniert die Weiterleitung über den Network Access Server (NAS) aber nur mit IP-Paketen. Um auch andere Protokolle, etwa für Remote Access ins Firmennetz zu transportieren, muss man die PPP-Verbindung quasi über den NAS des Providers zum NAS der eigenen Firma verlängern. Dazu verpackt PPTP die PPP-Pakete über das Tunnel- Verfahren Generic Routing Encapsulation (GRE) in IP-Pakete. Die Signalisierung zum Verbindungsauf- und -abbau erfolgt zwischen dem PPTP-Client und dem Server über eine Control Connection über den TCP-Port Neben Sicherheitsproblemen hat PPTP auch mit NAT zu kämpfen. Manche Router nehmen GRE-Pakete nicht an und verwerfen sie kommentarlos. Zudem gibt es bei GRE keine Ports, sodass die Zuordnung von Ports zu Client-Verbindungen unmöglich ist. Anders als bei IPSec befördert PPTP die zugehörigen Kenndaten unverschlüsselt. Mit PPTP Passthrough sind Seite 4 von 13

5 moderne NAT-Router daher in der Lage, eine Liste der von Clients verwendeten Call IDs zu führen und zuzuordnen. Als Alternative baut Microsoft seit Windos 2000 das Protokoll L2TP over IPSec (Layer 2 Tunneling Protocol) ein, das wie PPP andere Protokolle höherer Schichten transportiert. L2TP hat keine eigenen Funktionen zur Verschlüsselung. Daher wird es zum Schutz der Daten in Kombination mit IPSec eingesetzt, wobei IPSec dann auch die Authentifizierung übernimmt. Fazit IPSec gilt nach wie vor als sichere VPN-Lösung, legt dem Anwender aber einige Steine in den Weg. Unter Windows ist etwa IPSec mit den Bordmitteln nur schwer zu konfigurieren und unter Linux ist erweitertes Expertenwissen notwendig, um die Konfiguration vorzunehmen. Die sichere Überwindung von Firewalls und NAT ist mit erheblichen Aufwand zu gewährleisten. IPSec-VPNs sind relativ ressourcenhungrig und erzeugen viel Overhead, sind aber skalierbar. OpenVPN ist ein echter Star. Aufgrund seiner Flexiblität und der hohen Sicherheit hat OpenVPN sehr viele Anhänger gefunden. Die einfache Installation, Konfiguration und Robustheit machen die Wahl für das Open-Source-VPN leicht. Authentifizierung Der sichere Betrieb von VPNs steht und fällt mit einer guten Authentifizierung. State-of-the- Art sind Zertifikate, öffentliche Schlüssel, die an eine Identität durch eine Certification Authority (CA) beglaubigt sind. Vertraut man dieser CA, kann man sicherstellen, dass nur bekannte Identitäten Zugriff auf das VPN haben. Im Gegenzug können die Teilnehmer verifizieren, ob sie auch wirklich mit dem gewünschten VPN-Server eine Verbindung aufgenommen haben. Eine Identität kann sowohl eine Person als auch ein PC darstellen. Der Einsatz von Zertifikaten bedeutet aber einen höheren Verwaltungsaufwand, da eine Public-Key-Infrastrukur (PKI) notwendig ist., die Zertifikatsanträge bearbeitet, Zertifikate ausstellt und verteilt sowie Listen über ungültige beziehungsweise zurückgezogene Zertifikate Seite 5 von 13

6 führt und zur Verfügung stellt (Certificate Revocation List, CRL). Die Open-Source-Lösung OpenCA baut eine vollständige PKI auf, die viele Schritte automatisiert durchführt. Weniger automatisiert, dafür einfacher in der Installation und Konfiguration ist TinyCA, deren Zertifikatsverwaltung komplett über eine GUI bedient wird. OpenVPN liefert gleich seine eigene CA Easy-RSA mit. Mit simplen Skriptaufrufen erstellt der Nutzer ein CA-Zertifikat und unterschreibt damit Server- und Client-Schlüssel. Bei sehr vielen Teilnehmern kommt diese einfache Lösung aber schnell an ihre Grenzen. VPN-Lösungen können zur Authentifizierung statt eines Zertifikates auch den unsignierten öffentlichen Schlüssel des Gegenübers nutzen. Der muss aber, ähnlich wie bei PSKs, vorher auf einem separaten Weg ausgetauscht werden. Auf den Einsatz von PSK sollte man am besten ganz verzichten oder wenigstens Passwörter wählen, die aus einer Kombination von Groß- und Kleinbuchstaben sowie Zahlen bestehen. OpenVPN Mit Hilfe von OpenVPN lässt sich ein verschlüsselter Tunnel durch das Internet aufbauen. OpenVPN ermöglicht das Verbinden einzelner Rechner über das Internet, wie das Koppeln kompletter Netze oder das Anbinden von einzelnen Rechnern an ein Firmennetzwerk. Die Daten werden über eine sichere Verbindung verschlüsselt übertragen, so dass sich OpenVPN für den professionellen Einsatz eignet.eine hohe Beliebtheit erreicht OpenVPN durch seine übersichtliche Konfigurationsdatei, die die VPN-Lösung durch wenige Parameter konfiguriert. Die Sicherheit von OpenVPN wird durch diese übersichtliche Konfiguration nicht eingeschränkt. OpenVPN benutzt eine TCP- oder UDP-Verbindung zwischen den beteiligten Rechnern. Durch diese einfache Übertragungsstruktur ist die Freigabe durch die Firewall leicht zu erreichen und bei Bedarf kann eine vollwertige Netzwerkverbindung über einen http-proxy hergestellt werden.das Schlüsselmanagement von OpenVPN erlaubt den Zugang für dutzende von Clients und somit ist OpenVPN für den Einsatz innerhalb einer Unternehmensstruktur geeignet. OpenVPN benutzt für die verschlüsselte Kommunikation eigene Netzwerkdevices, als Beispiel 'tun0'. Somit wird das Gerät 'dev/tun0' für Programme angelegt, welche für die Seite 6 von 13

7 Kommunikation Gerätedateien benötigen. Daten, die nach '/dev/tun0' oder 'tun0' geschrieben werden, transportiert OpenVPN zur konfigurierten Gegenstelle und gibt sie dort über das konfigurierte Tunneldevice aus. Der Tunnel funktioniert wie eine virtuelle Netzwerkkarte und bekommt eine entspechende IP-Adresse zugewiesen. Für die Verschlüsselung und Authentifizierung setzt OpenVPN auf Secure Socket Layer (SSL) beziehungsweise dessen Nachfolger Transport Socket Layer (TLS). Diese Dienste werden auch für die Verschlüsselung von https-seiten genutzt. Somit werden für die sicherheitsrelevanten Funtkionen bewährte Protokolle und Bibliotheken wie OpenSSL genutzt. Authentifikation Zur Authentifikation stellt OpenVPN mehrere Methoden zur Verfügung: Preshared Key Bei Austausch eines preshared key (ein statischer Schlüssel/Passwort) werden die Daten mit diesem ver- und entschlüsselt. Das Verfahren ist einfach anzuwenden. Es besteht jedoch der Nachteil, dass der Schlüssel nicht abhanden kommen bzw. kompromittiert werden darf. In diesem Fall muss ein neuer Schlüssel an alle Kommunikationspartner verteilt werden. Daher sollte man einen vertrauenswürdigen Installationsort (z. B. PGP-Disk Container) wählen, damit der Schutz der Schlüssel garantiert ist. Der Schlüssel kann über ein automatisiertes Verfahren durch eine laufende Verbindung hindurch ausgetauscht werden. Username/Passwort Über einen individuellen Benutzernamen und ein Passwort wird der Zugang zu dem Netz beschränkt. Doch derartige statische Pre-Shared Keys sind unsicher. Zertifikatsbasiert Bei der Anwendung einer zertifikatbasierten Authentifizierung über das TLS-Protokoll werden private/öffentliche Schlüsselpaare beziehungsweise X.509 Zertifikate verwendet. Der Server und die jeweiligen Nutzer besitzen je ein eigenes Zertifikat (öffentlich/privat). Der OpenVPN-Server lässt nur Verbindungen zu, die von einer ihm bekannten Seite 7 von 13

8 Zertifizierungsstelle signiert wurden. Die zertifikatbasierte Authentifizierung gilt als die sicherste Form der Anmeldung. Erzeugen der Zertifikate Für die Verschlüsselung und Authentifizierung ist ein digitales Zertifikat (Cert) und ein digitaler Schlüssel (key) notwendig. Um ein Zertifikat erstellen zu können muss auf dem Rechner ein Key erzeugt werden. Mit Hilfe des erzeugten Keys wird im folgenden Schritt eine request-datei (Certificate Sign Request - csr) erstellt. Diese Request-Datei muss an einer Zertifizierungsstelle gesandt werden, bei der mit Hilfe eines Stamm-Zertifikates das Nutzer- Zertifikat (.crt Datei) erstellt wird. Die Nutzer-Zertifikate dienen der Absicherung des virtuellen Netzwerks. Der Vorgang der Zertifikaterstellung kann aber mit OpenVPN vereinfacht werden. Im besonderen entfällt die Notwendigkeit einer externen Zertifizierung durch eine Zertifizierungsstelle. Die Erstellung der notwendigen Zertifikate mit OpenSSL vereinfacht OpenVPN mit Hilfe der Skriptsammlung Easy-RSA. Zu beachten ist hierbei, dass man auf einen Server, der den OpenVPN-Dienst automatisch startet, den geheimen Schlüssel nicht mit einem Passwort versieht. Bei den Clients hingegen empfiehlt es sich, diese durch ein Passwort zu schützen, damit andere Nutzer des Client-Rechners das VPN nicht missbrauchen können. Erzeugen der Zertifikate mit Easy-RSA 1. In das Verzeichnis easy-rsa wechseln 2. falls die Datei vars.bat nicht existiert./init-config ausführen 3. Die Datei vars.bat anpassen - Organization Name, Common Name, Address... anpassen 4. vars.bat ausführen mit dem Befehl source./vars.bat 5. Die Datei./clean-all ausführen. Clean-all löscht alles im Verzeichnis keys und kopiert zwei Dateien in das Unterverzeichnis. Sollte /keys nicht existieren, wird es erzeugt. Die evtl. erscheinende Fehlermeldung kann ignoriert werden. 6. ca.crt erstellen mit./build-ca. Die Meldungen bestätigen, dann werden die Vorgaben aus vars.bat übernommen. Organizational Unit Name und Common Name eintragen, die Namen können auch gleich sein. Jedoch bei weiteren Abfragen müssen sich Organizational Unit Name 2 und Common Name 2 von der ersten Eingabe unterscheiden. 7. dh-file erstellen mit./build-dh 8. Zertifikat für den Server erstellen (key) mit build-key-server ZertifikatName. Die Vorgaben bestätigen und Organizational Unit Name 2 und Common Name 2 eintragen. Die folgenden Abfragen mit yes bestätigen. Seite 8 von 13

9 9. Zertifikate für den Client (key) erstellen mit build-key ZertifikatName. Für jeden Client muss ein gesondertes Zertifikat erstellt werden. Anmerkung: Sollte die Eingabeaufforderung geschlossen werden, muss source./vars.bat erneut geladen werden Notwendige Zertifikat-Files des Servers: dh1024.pem ZertifikatName.crt ZertifikatName.key ca.crt Die Kommunikation mit Hilfe von OpenVPN Der Aufbau einer Verbindung wird vom Client durch den Aufruf von 'openvpn client.conf' initiiert. Das Programm fragt nach dem Passwort für den geheimen Schlüssel. Nach der korrekten Eingabe schickt der Client Daten an den in dem Konfigurationsskript angegebenen Server (SSL-Version und zufällige Daten). Der Server schickt die gleichen Daten und sein Zertifikat zurück. Der Client autorisiert das Zertifikat. Bei beidseitiger Authentifizierung schickt der Client auch sein Zertifikat an den Server. Hat die Überprüfung geklappt, erstellt der Client das pre-master secret und verschlüsselt dies mit dem öffentlichen Schlüssel des Servers. Der Server entschlüsselt die Daten mit seinem privaten Schlüssel und erstellt das master-secret. Mit diesem werden Session-Keys erstellt. Das sind einmalige Schlüssel, mit denen die Daten ver- und entschlüsselt werden. Der Client teilt dem Server mit, dass ab nun alle Daten mit dem Session-Key verschlüsselt werden. Der Server bestätigt dies, der Tunnel ist aufgebaut. Der Client erhält die Meldung Initialization Sequence Completed ausgeben. Damit steht die VPN-Verbindung und der Server sollte mit ping IP-Adresse erreichbar sein. Ist der Ping-Befehl erfolgreich, kann der Datenaustausch mit dem Server erfolgen, falls dies nicht durch eine Firewall oder andere restriktive Konfigurationen unterbunden ist. Nach einer gewissen Zeitspanne ersetzt OpenVPN den Session-Key automatisch. Die IP-Adresse der Clients vergibt der Beispiel-Server dynamisch aus dem Bereich /24, der erste bekommt in der Regel die Man kann die Adresse aus den Statusmeldungen entnehmen; auf dem Server zum Beispiel "MULTI: Learn: ", auf einem Linux-Client /sbin/ifconfig tun0; bei Windows-Clients meldet das GUI die IP- Adresse des Clients. OpenVPN merkt sich diese Zuordnungen, sodass man bei erneuter Einwahl wieder dieselbe Adresse erhält. Alternativ beschreiben die Kommentare in der Datei und das Howto, wie man Clients auch feste IP-Adressen zuweisen kann. Seite 9 von 13

10 Steht "hinter" dem OpenVPN-Server ein privates Netz, das der Client erreichen können soll, kann ihm der Server eine passende Netzwerk-Route übermitteln. Dazu ist in server.conf die Zeile ;push "route " anzupassen und das führende Semikolon zu entfernen. Das funktioniert ohne weitere Tricks allerdings nur unter zwei Voraussetzungen: Erstens darf auf der Client-Seite nicht derselbe Adressbereich zum Einsatz kommen. Und zweitens muss sichergestellt sein, dass die Pakete aus dem LAN den richtigen Weg zum VPN-Client finden. Das passiert automatisch, wenn der OpenVPN-Server auch der Standard-Gateway für die Rechner im Server-LAN ist. Ansonsten muss entweder der Gateway eine passende Route haben, die Pakete für /24 an den OpenVPN-Server weiterleitet, oder diese Route muss auf allen Clients eingetragen werden. OpenVPN kennt darüber hinaus viele weitere Optionen und Zusatzfunktionen, mit denen man sich nur bei Bedarf beschäftigen muss. So kann man Windows-Clients über DHCP-Optionen die Adressen von DNS- und WINS-Servern übermitteln oder die Clients anweisen, alle ausgehenden Pakete durch den VPN-Tunnel zu routen. Die einzelnen Optionen sind in der Beispielkonfiguration und der Dokumentation gut erklärt. Im Folgenden sollen ein paar konkrete Einsatzszenarien und deren spezielle Erfordernisse etwas genauer erläutert werden. Benutzerrechte OpenVPN benötigt unter anderem zum Konfigurieren der Tunnelendpunkte und dem Setzen der Routen Administratorrechte. Wer unter Windows ohne diese arbeitet, kann folglich OpenVPN nicht ohne weiteres starten. Die notwendigen Rechte verschafft eine Verknüpfung auf dem Desktop mit runas /u:administrator openvpn-gui.exe Das fragt dann beim Start zunächst nach dem Administrator-Kennwort. Will man das dem Anwender nicht geben, wird es etwas komplizierter. Denn es ist zwar möglich, OpenVPN als Dienst zu installieren, den der Anwender dann starten und beenden darf, dieser kann dann aber nicht nach dem Passwort für den Schlüssel fragen. Der Autor von OpenVPN GUI empfieht in dieser Situation, den Schlüssel in den MS Certificate Store zu importieren, auf den OpenVPN zugreifen kann (--cryptoapicert). Mit OpenVPN 2.1, das bereits als beta-version erhältlich ist, entfallen diese Klimmzüge. Das TAP-Device können darin auch Nicht-Administratoren ansprechen. Zum Setzen der Routen Seite 10 von 13

11 unter XP Professional genügt ohnehin die Mitgliedschaft in der Gruppe der "Netzwerkkonfigurations-Operatoren". Unter Linux sorgt der sudo-mechanismus für die notwendigen Root-Rechte: /usr/bin/sudo /usr/sbin/openvpn /etc/openvpn/client.conf Damit das ohne Passworteingabe funktioniert, trägt der Administrator über visudo in /etc/sudoers folgende Zeilen ein User_Alias VPN = ju, dab VPN ALL= NOPASSWD: /usr/sbin/openvpn /etc/openvpn/client.conf ersetzt dabei aber die User-Kennungen ju und dab durch die eigenen. Brückenbau In der Standardkonfiguration arbeitet OpenVPN im Routing-Modus. Das heißt, das VPN nutzt ein eigenes Transfernetz per Default /24. Die Tunnelendpunkte haben dabei Adressen aus diesem Netz und alle VPN-Pakete werden durch diesen Tunnel geroutet. Dazu setzt OpenVPN virtuelle TUN-Interfaces ein, die eine Punkt-zu-Punkt-Verbindung auf IP- Ebene erlauben. In manchen Situationen ist dieser Umweg jedoch hinderlich, beispielsweise wenn man OpenVPN zur Fernwartung eines kleinen Firmennetzes einsetzt. Dabei steht der OpenVPN- Server oft hinter einem einfachen Router direkt im Firmennetz, der zwar das notwendige Port- Forwarding beherrscht, aber beispielsweise keine statische Route auf das virtuelle 10er-Netz zum OpenVPN-Server setzen kann. Außerdem wäre es für Diagnosezwecke nützlich, sich quasi direkt im lokalen Netz zu befinden, statt wie in der Standard-Konfiguration nur über geroutete Pakete dorthin zu gelangen. Für solche Zwecke kann OpenVPN auch Netze überbrücken und als Bridge arbeiten. Dazu erzeugt es virtuelle Netzwerkkarten, die so genannten TAP-Devices. Eine Bridge vermittelt zwischen den TAP-Devices und dem LAN-Interface derart, dass es für alle Beteiligten so aussieht, als wäre eine weitere Netzwerkkarte direkt an das Ethernet angeschlossen. Das TAP- Interface bekommt folglich auch eine IP-Adresse aus dem Bereich des Firmennetzes, beispielsweise /24. Das hat eine Reihe von Vorteilen. So kommen beispielsweise alle Broadcasts im Netz auch auf dem VPN-Client an und man kann deshalb Windows- Seite 11 von 13

12 Dateifreigaben auch ohne WINS- oder Samba-Server browsen. Des Weiteren ist es damit möglich, über das VPN auch Nicht-IP-Protokolle wie IPX oder Appletalk einzusetzen. Dafür ist es weniger effizient als das Routing, skaliert nicht so gut und ist zumindest auf der Server- Seite etwas schwieriger aufzusetzen. In einem einfachen Setup reserviert man für die VPN-Clients einen Bereich aus dem Block der Netzwerkadressen im LAN, beispielsweise , die für den lokalen DHCP-Server tabu sind. In server.conf kommentiert man die Einträge für dev tun und server und aktiviert stattdessen dev tap0 und server-bridge: dev tap0 ;dev tun ;server server-bridge Dabei ist die die Adresse des Servers im LAN; den VPN-Clients weist der Server dynamisch Adressen aus seinem Privat-Pool zu. Windows findet das passende TAP- Device selbst, sodass hier nur tap ohne die 0 einzugeben ist. Nun ist noch das Bridging zu aktivieren. Unter Windows XP geht das vergleichsweise einfach, indem man in den Netzwerkverbindungen die Netzwerkkarte und das TAP-Interface auswählt und "Verbindungen überbrücken" ausführt. Unter Linux muss man die Bridge wie in der Dokumentation beschrieben von Hand einrichten. Wer einen c't-debian-server einsetzt, muss lediglich in /etc/networks/interfaces ein weiteres tap-device erstellen und bei br0 unter bridge_ports eintragen. Wichtig ist es, auch in client.conf dev tap zu verwenden, da sich TUN- und TAP-Modus nicht vertragen. Glossar zu den VPN-Verbindungen Der Advanced Encryption Standard (AES) ist der Nachfolgeverschlüsselungsstandard von DES (Data Encryption System). 3DES mit 128 Bit gilt zwar immer noch als sicher, ist aber Seite 12 von 13

13 wegen der Dreifachverschlüsselung um Faktoren langsamer als AES. AES unterstützt 128, 192 und 256 Bit lange Schlüssel. Über das Diffie-Hellman-Key-Exchange-Verfahren (DH) lassen sich kryptographische Schlüssel sicher über unsichere Kanäle aushandeln. Es ist selbst kein Verschlüsselungsverfahren und tauscht auch keine Schlüssel im eigentlichen Sinne aus. Das von Martin Hellman und Whitfield Diffie entwickelte Verfahren beruht auf den Eigenschaften diskreter Logarithmen: zwar ist es einfach, eine Zahl zu potenzieren. Es ist aber nur mit sehr großem Aufwand möglich, den diskreten Logarithmus einer Zahl zu berechnen. Bei der Aushandlung einigen sich die VPN-Peers auf eine Primzahl p und eine Primitivwurzel g mod p. Beide Faktoren dürfen unverschlüsselt übertragen werden. Anschließend erzeugt jede Seite eine geheime Zufallszahl a/b und berechnet daraus den Wert Za= ga mod p beziehungsweise Zb = gb mod p. Za und Zb werden an den Partner übertragen. Daraus kann nun jede Seite den gemeinsamen symmetrischen Schlüssel K berechnen: Zba mod p = Zab mod p = K. Sind die eingesetzten Zahlen hinreichend groß, ist es für einen Angreifer so gut wie unmöglich, den Key zu knacken. Große Zahlen erfordern allerdings mehr Rechenaufwand. Die Größe der Zahlen bestimmt die gewählte DH-Gruppe. Die kleinste DH Gruppe 1 hat 768 Bits und die größte definierte Gruppe 18 besitzt 8192 Bits. Empfohlen wird derzeit der Gebrauch der Gruppe 5 mit 1536 Bits. Über einen Hash-Algorithmus lässt sich aus einem beliebig langen Datensatz eine Prüfsumme fester Länge berechnen. Dieser Hashwert soll möglichst einmalig sein, man spricht dann auch von Kollisionsfreiheit. Damit ist sichergestellt, dass der Datensatz nicht so manipuliert werden kann, dass der Hashwert trotzdem noch derselbe ist. Üblicherweise kommen SHA-1 (Secure Hash Algorithm) mit 160 Bits und MD5 (Message Digest Algorithm) mit 128 Bits zum Einsatz. Bei ESP wird der Hashwert von 128, respektive 160 Bit auf 96 Bit abgeschnitten. Zur Authentisierung von Daten dienen (Keyed-)Hash Message Authentication Codes. HMAC ist eine Sonderform des MAC, bei der zusammen mit einem geheimen Schlüssel ein Hash-Wert etwa über Datenpaket gebildet wird. Bei VPNs benutzt man in der Regel HMAC-MD5 oder HMAC-SHA-1. Unter IKE sorgt die Aktivierung der Funktion Perfect Forward Secrecy (PFS) für frisches Schlüsselmaterial bei der Aushandlung eines Keys für den Quick Mode. Ohne PFS leitet Phase 2 die ESP Schlüssel vom DH-Geheimnis der IKE Phase 1 ab. Wird etwa im IKE Main Mode nur alle 24 Stunden authentisiert, so hängen alle in diesem Zeitraum erstellten IPsec SAs von diesem Master-Schlüssel ab. Knackt ein Angreifer den Schlüssel, so wären alle Sessions eines Tages kompromittiert. Seite 13 von 13