VPN-Gateway auf Basis von Linux und OpenVPN

Transkript

1 VPN-Gateway auf Basis von Linux und OpenVPN Björn Swendrak Fachprüfung gem. 39c DPO02 im Fach Spezielle Gebiete der Softwaretechnik, Fachhochschule Lippe und Höxter Prof. Dr. Stefan Heiss

2 -2- Inhaltsverzeichnis 1 Grundlagen von Virtual Private Networks Die Software OpenVPN Funktionsweise von SSL / TLS OpenVPN im TLS Mode Installation auf einer Linux-Firewall Quellenangabe Glossar... 10

3 -3-1 Grundlagen von Virtual Private Networks Virtual-Private-Networks, kurz VPNs genannt, verbinden sichere private Netze über unsichere öffentliche Netzwerke. Den wohl häufigsten Einsatz finden sie in der Vernetzung von dislozierten Unternehmensstandorten. Hier werden die sehr teuren Standleitungen gegen normale Internetverbindungen ausgetauscht und der Datenverkehr zwischen den Standorten verschlüsselt übertragen. Abbildung 1.1 VPN Prinzip VPNs eignen sich ebenfalls um Firmenangehörigen im Außendienst den sicheren Zugang in das Firmen- Netzwerk zu gewähren, unabhängig von der Art der Internetverbindung. Aufgrund der zur Zeit noch mangelhaften Absicherung von WLANs setzen sich auch hier VPN-Lösungen immer weiter durch. 2 Die Software OpenVPN Die VPN-Lösung OpenVPN ist ein Open-Source-Projekt, dass unter der GPL im Internet zur Verfügung steht. Es ist für die Betriebssysteme Linux, Windows 2000/XP, OpenBSD, FreeBSD, NetBSD, Mac OS X sowie Solaris verfügbar und eigenet sich somit sehr gut zum Einsatz in heterogenen Netzwerken. Zur Verschlüsselung, Authentifizierung und Zertifikatserstellung greift OpenVPN auf die Funktionen der OpenSSL-Library zurück. Chiffrierung kann auch mit sogenannten Pre-Shared-Keys erfolgen. Diese müssen allerdings vorher über einen sicheren Kanal ausgetauscht werden. Zur Authentifizierung wird dann das HMAC-Verfahren genutzt. Die Kommunikation auf dem unsicheren Netz findet mittels UDP-Paketen statt und ist somit sehr schnell. Die Zuverlässigkeit und Fehlerkorrektur wird durch die getunnelte Verbindung hergestellt. 3 Funktionsweise von SSL / TLS Die SSL/TLS Protokolle sind mittlerweile aus dem Internet nicht mehr wegzudenken. Verbindungen zu Web- Shops, Banken und vielen andere Anwendungen werden heute mit SSL/TLS abgesichert. Das SSL/TLS Protokoll führt einen zusätzlichen Layer, genannt Record-Layer, im Netzwerk-Stack zwischen der Transport- und der Sitzungsschicht (Abb. 3.1) ein. Der empfangene Bitstrom wird in sogenannte Records mit einer maximalen Größe von Byte zerlegt. Diese können dann komprimiert werden, erhalten einen Message Authentication Code, in den auch eine Sequenznummer eingeht, um vertauschte oder verlorene Records zu erkennen. Diese Daten werden dann mit dem für die Sitzung gültigen Schlüsseln chiffriert. Abb. 3.1 SSL Stack [WNM] Abbildung 3.2 Aufbau eines SSL Records [SNK]

4 -4- Ein SSL Record ist wie folgt aufgebaut (Abb. 3.2): Das erste Byte enthält den Typ des Records. Die Typnummern sind: 20 0x14 Change Cipher Specs 21 0x15 Alert 22 0x16 Handshake 23 0x17 Application Data Danach folgen zwei Byte für die Versionsnummer, also z.b für die Version 3.1 (TLS). Es schließen sich zwei Byte für die Längeninformation an. Handelt es sich um ein Paket vom Typ 0x16 (Handshake) folgt noch ein Byte für den Nachrichtentyp: 0 0x00 Hello Request 01 0x01 Client Hello 02 0x02 Server Hello 11 0x0b Certificate 12 0x0c Server Key Exchange 13 0x0d Certificate Request 14 0x0e Server Hello Done 15 0x0f Certificate Verify 16 0x10 Client Key Exchange 20 0x14 Finished Nun folgen noch drei Byte Längeninformation, an die sich die Payload des Records anschließt. Abbildung 3.3 SSL Handshake [SNK] Der SSL Handshake (Abb. 3.3) ist ein Schlüsseltausch auf Basis eines Public-Key-Verschlüsselungsverfahrens. Der Server versendet seinen öffentlichen Schlüssel, verpackt in einem SSL-Zertifikat. Der Client chiffriert mit diesem öffentlichen Schlüssel eine Zufallszahl und sendet das Ergebnis an der Server. Mit dieser Zahl werden anschließend die Keys für die symmetrische Verschlüsselung berechnet. Nach dem Handshake, wird der Datenverkehr mit dem im Change Cipher Spec. ausgehandelten symmetrischen Verfahren verschlüsselt.

5 -5-4 OpenVPN im TLS Mode Im Folgenden wird anhand eines mit Ethereal erstellten Mitschnitts die Arbeitsweise von OpenVPN erläutert. Ein VPN-Client stellt dem Rechner eine virtuelle Netzwerkverbindung zur Verfügung auf der der Datenverkehr im Klartext verläuft. Dieser wird verschlüsselt und gekapselt an das echte Netzwerkdevice weitergegeben und dort übertragen. Abbildung 4.1 Prinzip VPN-Client Pakete, die der VPN-Client an das VPN-Gateway sendet, werden im Folgenden orange hinterlegt, Pakete vom VPN-Gateway an den Client gelb. Gezeigt wird hier lediglich die UDP-Payload, da die restlichen Informationen wie Start-Ziel-Ip-Adresse sowie Ports immer wieder gleich sind. Die Bytes 2-9 sind möglicherweise eine Client ID oder ein Hash-Wert, dieser findet sich auch im Bestätigungspaket des Servers. Die folgenden fünf Bytes sind ein Zähler, der pro Paket inkrementiert wird d7 1f 7b 2b 8d f0 ad 9e {+... HANDSH f b c5 be b6.._...[..a CLIENT a 14 b6 18 fb 34 e5 a2 e7 ca f1 04 d2 r HELLO d 3e e9 08 af 9c 00 1d ]> a f /.f c.b.a e.d.` ENDE Der erste SSL-Record ist vom Typ Handshake, sowie Protokoll-Version 3.1. Das Paket ist 95 Byte (0x5f) lang. Der Nachrichtentyp ist Client Hello. Die Länge des Client-Hellos beträgt 91 Byte (0x5b), die Protokoll- Version ist 3.1. Die Bytefolge 0x41 0xc5 0xbe scheint die Session-ID zu sein. Diese wird auch im Server- Hello wiederholt. Die weiß markierten Bytes mit den vorstehenden 0x00 könnten Cipher-Suites sein f b ff 63 d8 c d7 1f.dtk.c... HANDSH b 2b 8d f0 ad 9e a 02 {+...*. SERVER c5 be f c8 1b..&..A..0._&P... HELLO 0030 a6 4a 5e 39 da 00 df b cb b4 be f7 fc 27.J^9...Tr...' c 6f a b 00.o.!D..9...y.. CERT b b d.u..r a d a *.H f7 0d b 31 0b x19 Die Antwort vom Server ist ebenfalls vom Typ Handshake v.3.1. Die Länge beträgt 42 Byte (0x2a). Der Nachrichtentyp ist in diesem Fall Server Hello. Die nächste Nachricht beginnt bereits in diesem Paket. Sie ist wie die Folgenden auch vom Typ Handshake v.3.1, Certificate. Die Länge beträgt 2425 Byte (0x09 79). Dieser Record setzt sich fort bis Paketnummer 0x19. Die weiß markierte Bytefolge müsste die Cipher-Suite sein. Allerdings wird 0x00,0x00 nicht im Client-Hello angeboten d7 1f 7b 2b 8d f0 ad 9e f5 64 (..{+...d b ff 63 d8 c9 tk.c.. Alle Pakete vom VPN-Gateway werden nun vom Client mit obigem Paket bestätigt. Markiert sind die mutmaßlichen ID's bzw. Hash-Werte. Diese ändern sich bei jeder neuen Verbindung. Das erste Byte scheint ein Status-Byte von OpenVPN zu sein. Die Bestätigungspakete haben als erstes Byte immer den Wert 0x28.

6 f b ff 63 d8 c f ec.dtk.c...o c5 e5 de 26 3f ab a4 42 ba...&?..c..r..b f dc fb a4 f5 ab cb a dc ba 37 c4 0e 7b...1e..7..{ b b0 aa f2 24 e1 73 e6 c f0 92 d5 8a dd {...$.s..bf a6 ed 30 1c eb 09 d8 54 5e 8b d3 f '...t^ f f1 9a 8d 88 b8 eb d d...w...HANDSH c d ff e 7f 59 b5...}..e...y.srvkeyx cf.. 0x21 Das nächste Paket mit verwertbaren Informationen ist das Paket 0x19. Hier findet sich das Ende des Zertifikates und der Anfang des Server-Key-Exchanges. Dieser Record ist 781 Byte (0x03 0d) lang und endet im Paket-Nummer 0x21. Vom Client folgen wieder die o.g. Bestätigungen f b ff 63 d8 c ad f2.dtk.c...! d ed af 8a 3f f3 e2 3c 6c ba 2b 88 cd 12 6f 13 =...?..<l.+...o c7 41 7f db e3 84 c be b8 d0 fa c9 60 f4.a...` a c4 0c c c 35 e3 7c 81 c5 0e z..h.,f!.< c 7a 0f af 86 2b 0d f4 75 1a 71 ae b lz...+..u.q... HANDSH af 0d a a0 00 9e CRT.RQ b 31 0b U...DE1 0x Im Paket 0x21 erfolgt nun der Certificate Request. Es ist 175 Byte (0xaf) lang und endet im Paket 0x d7 1f 7b 2b 8d f0 ad 9e {+..." f b ff 63 d8 c #.dtk.c... HANDSH b d b t...p..m CERT b a d x1a a f7 0d b 31.*.H b U...DE a d U...Schaumbur e e 74 g1.0...u...rint c el Der Client überträgt nun das vom Server angeforderte Zertifikat. Die Länge beträgt 2416 Byte (0x09 70). Das Ende findet sich in Paket 0x1a d7 1f 7b 2b 8d f0 ad 9e a 30 1c..{ eb 09 d8 54 5e 8b d3 f4 9f f1 9a 8d...'...T^ b8 eb d w... HANDSH f db 36 1f a7 9d 6e c8 20 5b 1b...3Q.6...n. [. ClKeyX a9 f4 b2 4f a1 2a 0c ef 65 da 2a 47 w...os!e.*..e.*g 0x1c bb bb f0 f0 9d 19 9b df ff 0c 93 a8 5a...Z 0060 d9 c0 9b c9 ff 73 bf 43 4e ac fb ce 77...s.CN..t...w f9 T. Im Paket 0x1a startet der Client-Key-Exchange. Die Länge beträgt 262 Byte (0x10 06) und der Record endet in 0x1c d7 1f 7b 2b 8d f0 ad 9e c {+...W d2 04 c2 86 d4 5c ab fe 6b 65 5b eb a b8...\..ke[...e a a8 64 ff ef d f9 4c.92...d.&8...L fb 50 b9 ae f4 b2 c1 2e 80 4c 8c a 89 i.p...l...j dd bb c2 11 ff a4 64 f3 0f 48 3c ed.bg5...d..h< a3 f4 af 80 3c f 0f d9 f c 32 b...<.(...2 HANDSH 0060 bf d8 a c bd f...Dc.,.y... Crt.Vy x1f Der folgende Record ist 262 Byte (0x01 06) lang, vom Typ Certificate Verify und endet in 0x1f.

7 d7 1f 7b 2b 8d f0 ad 9e f f9 f3..{ c0 4d 38 3a eb 00 5a 1f a9 6c 0f e7 d1 b4 bf 77.M8:..Z..l...w 0020 ba 28 5f b1 f2 c6 d0 c de.(_.f...r...' b 3c 7a cc d3 ab 41 0c f f8 f5.<z...a..&.e$ c4 eb 6e bb 88 d u..n... ChCipS e1 3c c8 f <...d.3e.vf CiS?? c c9 f6 e8 ca ac b4 a2 fc 8f 5c 35 8c 17 de f4...\5... HANDSH fc #. 0x20 Nun folgen zwei Records Change Cipher Spec des Clients, mit einer Länge von einem Byte (0x01) und 48 Byte f b ff 63 d8 c f dtk.c d7 1f 7b 2b 8d f0 ad 9e {+...$.. ChCipS e3 ef 70 9c 3d f1 fe...0..p.=.. CiphS a ac d8 00 7b 48 db dc e8 a (0...{H...9 HANDSH f 18 9e d a b 87 bd 2b 79 e8...e... Q[..+y c8 2c e6 8a 70 e ,..p.' ENDE Dem schließt sich der Server mit seinem Part des Change Cipher Spec an. Die Längen der Records gleichen denen des Clients im vorigen Paket. Der SSL-Handshake ist nun abgeschlossen. Jetzt folgen Pakete mit Applikationsdaten. Anschließend sieht man den Wechsel der Verschlüsselung und die restlichen Datenpakete d7 1f 7b 2b 8d f0 ad 9e f5 64..{+...$.d b ff 63 d8 c tk.c...!... # Ap.Dat 0020 d8 ad 36 f8 d d d e5 3b RM.X.G..; 0030 cc fd f3 5c e5 d9 ba 3d cb 21 8e e3 00 9f \...=.!...8. Ap.Dat d c8 17 ae 89 f6 04 4f 5a a2 6f...g...OZ.o 0x e b1 fd 31 f c9 df e5.0ggx..1.h...r f 9c cb cd a2 bd c 4e ab 63?...%F..N.!.c f e9 f2 ac a b2 1b fc 12.o5...gJ f b ff 63 d8 c dtk.c..." d7 1f 7b 2b 8d f0 ad 9e #..{+...%.. Ap.Dat a fb 78 5c 56 0f 4b bd ff c5 dd.. G&Z.x\V.K dd 58 a0 0a 4f d2 df 90 b7 a c 4e bd 11.X..O...@.,N b6 4b ae d0 01 7b 03 cc 6a 91 a1 94.K...{..j... Ap.Dat 0050 e f 7c e3 1f c1 0a c..$O fa...f.l fd ce 5e ce cd 3a 95 a9 7d 95 ca 1f 9e d1 Ac..^..:..} f 96 4b d6 f8 68 af c7 b8 77 c5 76 ec bc.u..k..h...w.v ad c4.. Anhand dieser Analyse kann man erkennen, wie der im SSL Protokoll definierte Handshake im OpenVPN umgesetzt wurde. Er ist identisch mit dem klassischen SSL-Handshake, der in Abbildung 3.3 gezeigt wird. Die Analyse der weiteren Datenpakete lässt jedoch vermuten, dass OpenVPN nach dem Schlüsseltausch per TLS die getauschten Schlüssel in gleicher Weise einsetzt, wie Pre-Shared-Keys, da nach dem Handshake und wenigen Application-Data-Paketen keine weiteren Pakete dem TLS-Protokoll zugeordnet werden können, wie das folgende Beispiel zeigt f fd 9f 97 fc a4 b9 ce 0b d9 4b 41 ce d2 69 0_...KA..i b a e0 64 4c 66 dd 49 ce ce K..*Rg.dLf.I..cb a 99 c d a8 51 aa 2e...v.@..Y C'.Q eb fe 47 c0 fd a c ef.a..r..g...f ff d5 a8 db af c da cd 8c f1 da d6.w f db df 15 0b bb d2 50 0d bd 99 b5 72 dc...p...r f ec 85 fa f5 5d a9 1f fa a9...]...x a0 a cf 0f b4 76 9f 76 d v.v..y

8 -8-5 Installation auf einer Linux-Firewall OpenVPN für Linux steht als sogenannter Tarball zur Verfügung. Die Datei openvpn<version>.tar.gz kann unter herunter geladen werden. Anschließend wird sie in der Kommandozeile mit dem Befehl tar -xvzf./openvpn<version>.tar.gz in ein Verzeichnis mit gleichem Namen ausgepackt. Das Programm liegt im Quellcode vor und muss vor der Installation übersetzt werden. Da die Linux-Distributionen sich in einigen Dingen unterscheiden, werden davor noch einige Parameter überprüft. Nach dem Entpacken sind also folgende Befehle einzugeben:./configure make make install zum Anpassen der Installation an das System zum Übersetzen/Kompilieren zur Installation des Programms OpenVPN ist so konzipiert, dass es ohne Dateien auskommt, in denen die Konfiguration abgespeichert wird. Es lässt sich also vollständig aus der Kommandozeile starten. Die Angabe einer Konfigurationsdatei ist jedoch wesentlich komfortabler. In diesem Beispiel liegen die Konfigurationsdateien im Ordner /etc/vpn. Ein weiterer Vorteil liegt darin, dass das gleiche Programm abhängig von der Konfiguration sowohl VPN-Gateway als auch VPN-Client sein kann. Das VPN-Gateway wird wie folgt konfiguriert: Mit * gekennzeichnete Befehle müssen bei jedem Neustart ausgeführt werden. mknod /dev/net/tun c modprobe tun* Mit folgende Befehlen werden die o.g. Zertifikate erstellt: konfiguriert sog. Netzdevice-Knoten lädt das TUN-Kernelmodul openssl req -nodes -new -x509 -keyout my-ca.key -out my-ca.crt -days 3650 erstellt ein 10 Jahre gültiges Master-Zertifikat/Privates-Schlüsselpaar openssl req -nodes -new -keyout office.key -out office.csr openssl ca -out office.crt -in office.csr openssl req -nodes -new -keyout home.key -out home.csr openssl ca -out home.crt -in home.csr erstellt Paare aus Zertifikaten und privaten Schlüsseln für das VPN-Gateway (office) und den VPN-Client (home) Die Dateien home.crt, home.key und my-ca.crt müssen nun über einen sicheren Kanal auf den Client kopiert werden. Anschließend wird eine Datei mit Diffie-Hellmann-Parametern auf dem Server erzeugt: openssl dhparam -out dh2048.pem 2048 Die Konfigurationsdatei für den Server sieht wie folgt aus: ### Anfang des Config-Files /etc/vpn/tls.conf dev tun ifconfig up /etc/vpn/tls.up tls-server dh /root/pe_ca/dh2048.pem ca /root/pe_ca/my-ca.crt cert /root/pe_ca/office.crt key /root/pe_ca/office.key port 6010 user nobody group nobody comp-lzo verb 3 # Tunnel-Device wird verwendet # Server-IP und Client-IP für VPN-Tunnel # erstellt Einträge in der Routing-Tabelle # dies ist ein Server # Speicherort der Parameterdatei # Speicherort der CA-Datei # Speicherort des Public-Keys # Speicherort des Private-Keys # Port auf dem kommuniziert wird # User mit dessen Rechten gearbeitet wird # Gruppe mit deren Rechten gearbeitet wird # optionale Echtzeit-Daten-Kompression # sog. Verbosity Level

9 -9- Die Einstellungen in der Konfigurationsdatei des Clients lauten: ### Anfang des Config-Files /etc/vpn/tls.conf dev tun remote vpn.firma.com ifconfig up /etc/vpn/tls.up tls-client ca /root/pe_ca/my-ca.crt cert /root/pe_ca/office.crt key /root/pe_ca/office.key port 6010 user nobody group nobody comp-lzo verb 3 # Tunnel-Device wird verwendet # IP des VPN-Gateways # Client-IP und Server-IP für VPN-Tunnel # erstellt Einträge in der Routing-Tabelle # dies ist ein Client # Speicherort der CA-Datei # Speicherort des Public-Keys # Speicherort des Private-Keys # Port auf dem kommuniziert wird # User mit dessen Rechten gearbeitet wird # Gruppe mit deren Rechten gearbeitet wird # optionale Echtzeit-Daten-Kompression # sog. Verbosity Level Auf dem Server und dem Client müssen nun noch die Firewalls für das VPN konfiguriert werden. Für IP- Tables lautet der Befehl: iptables -A INPUT -i $interface -p udp dport j ACCEPT* Wobei $interface gegen das entsprechende Netzwerkgerät zu ersetzen ist. Für DSL- oder Modem- Verbindungen z.b. ppp0, für Netzwerkkarten z.b. eth0. Da eine Firewall alle Pakete verwerfen sollte, die nicht explizit zugelassen sind, muß natürlich noch der Datenverkehr auf den zukünftigen VPN-Adaptern erlaubt werden: iptables -A INPUT -i tun0 -j ACCEPT* iptables -A OUTPUT -o tun0 -j ACCEPT* Diese Firewall-Regeln können natürlich noch feiner eingerichtet werden und sind nur als Beispiel anzusehen. Um die Weiterleitung von IP-Paketen zwischen Netzwerken auf dem VPN-Gateway zu aktivieren gibt man ein. echo 1 > /proc/sys/net/ipv4/ip_forward* Jetzt können sowohl auf dem Server, als auch auf dem Client die Programme gestartet werden: openvpn config /etc/vpn/tls.conf* Damit der Client in das Netz hinter dem VPN-Gateway gelangen kann, müssen noch folgende Routen eingetragen werden: route add -net netmask gw * OpenVPN ist nun auf dem Client und dem Server gestartet, der VPN-Tunnel steht, der VPN-Client kann auch in das Netz hinter dem Gateway gelangen. Ein Script, dass auf dem VPN-Gateway automatisch OpenVPN startet, könnte wie folgt aussehen: #! /bin/sh modprobe tun echo 1 > /proc/sys/net/ipv4/ip_forward iptables -A INPUT -i ppp0 -p udp dport j ACCEPT iptables -A INPUT -i tun0 -j ACCEPT iptables -A OUTPUT -o tun0 -j ACCEPT openvpn config /etc/vpn/tls.conf sleep 10 route add -net netmask gw

10 -10-6 Quellenangabe [WNM] Sicherheit und Kryptographie im Internet, Jörg Schwenk, Vieweg Verlag Oktober 2002 [SNK] 7 Glossar GPL GNU Public License HMAC Hash Message Authentication Code [RFC 2104] MAC Message Authentication Code NIC Network Interface Card SSL Secure Socket Layer TLS Transport Layer Security UDP User Datagramm Protocoll VPN Virtual Private Network WLAN Wireless Local Area Network