Netzwerk- und Datensicherheit

Transkript

1 Martin Kappes Netzwerk- und Datensicherheit Eine praktische Einführung Zusatz: OpenVPN Martin Kappes Fachhochschule Frankfurt am Main - University of Applied Sciences Fachbereich 2: Informatik und Ingenieurwissenschaften kappes@fb2.fh-frankfurt.de

2

3 Inhaltsverzeichnis 10 Virtual Private Networks v 10.9 OpenVPN v Einführung v Praktisches Beispiel vi Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz- Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

4

5 10 Virtual Private Networks 10.9 OpenVPN Einführung In Abschnitt 10.5 hatten wir OpenVPN [OpenVPN] bereits als eine alternative Methode zum Aufbau einen VPNs kennengelernt. Wir wollen uns nun OpenVPN etwas genauer anschauen. OpenVPN verwendet für die Beförderung der Daten zwischen den Endpunkten der scheinbaren Punkt-zu-Punkt-Verbindung des VPN die Transportschicht. Die Vertraulichkeit und Integrität der Informationen wird durch die Verwendung von SSL/TLS (siehe Abschnitt ) sichergestellt. Der Einsatz von UDP erfordert einen Trick, da SSL/TLS eigentlich ein zuverlässiges Transportprotokoll voraussetzt. Die Verwendung von UDP ist insbesondere sinnvoll, wenn über das VPN Daten übetragen werden sollen, für welche die Flusskontrollmechanismen von TCP zu inakzeptablen Verzögerungen führen, wie etwa Realzeitkommunikation (siehe Kapitel 14). Im Folgenden werden wir uns auf den Einsatz von TCP als Transportprotokoll konzentrieren. In diesem Fall wird also zwischen den beiden Endpunkten eine SSL/TLS-Verbindung über TCP aufgebaut, über welche die Daten dann kryptographisch geschützt übertragen werden. Die Entgegennahme der zu befördernden Daten kann bei OpenVPN sowohl auf der Datenverbindungsschicht als auch auf der Netzwerkschicht erfolgen. Hierbei kommen sogenannte virtuelle Nertzwerkinterfaces zum Einsatz. Nach Aufbau des Tunnels auf der Transportschicht erscheint auf beiden Endpunkten dieses virtuelle Interface, das jeweils als direkte Punkt-zu-Punkt- Endpunkt A Endpunkt B unsicheres Netzwerk virtuelles Interface OpenVPN-Tunnel erscheint als direkte Punkt-zu-Punkt-Verbindung zwischen neuen virtuellen Interfaces virtuelles Interface Abbildung 10.22: Scheinbare Situation nach Aufbau des OpenVPN-Tunnels.

6 vi 10 Virtual Private Networks Endpunkt A Endpunkt B unsicheres Netzwerk OpenVPN OpenVPN virtuelles Interface SSL/TLS-verschlüsselte Transportverbindung virtuelles Interface über das virtuelle Interface geschickte Daten werden von OpenVPN entgegengenommen und über die verschlüsselte Transportverbindung geleitet Abbildung 10.23: Tatsächliche Situation nach Aufbau des OpenVPN-Tunnels. Verbindung zum anderen Endpunkt erscheint. Aus Sicht des Rechners arbeitet dieses virtuelle Interface wie jedes normale Interface auch: Es nimmt Pakete (oder Frames) entgegen und liefert Pakete (oder Frames) an. Die scheinbare Situation ist in Abbildung dargestellt. OpenVPN setzt die VPN-Definition also fast wörtlich um. Tatsächlich jedoch werden beim Abschicken von Paketen (oder Frames) über dieses Interface die Pakete durch OpenVPN entgegengenommen, durch SSL/TLS kryptographisch geschützt über die Transportverbindung zum anderen Endpunkt des Tunnels geleitet. Diese verschlüsselten Pakete verlassen den Rechner natürlich über eines der richtigen Interfaces. Analog kommen über die Transportverbindung vom anderen Endpunkt mit SSL/TLS verschlüsselte Pakete an. Diese werden von OpenVPN wieder entschlüsselt und dann im Klartext über das virtuelle Interface weitergegeben. Dies ist in Abbildung dargestellt. Je nachdem, ob die Daten auf der Datenverbindungsschicht oder der Netzwerkschicht entgegengenommen werden, spricht man von einem tap- oder tun-interface Praktisches Beispiel Wir wollen nun die praktische Verwendung von OpenVPN ausprobieren. Hierzu verwenden wir wiederum das Referenznetzwerk aus Abschnitt 7.4 und werden exakt das gleiche Ziel verfolgen, wie auch bei unserem praktischen Test von IPsec. Ziel ist es also, wie in Abbildung gezeigt, einen VPN-Tunnel zwischen den Intranets /24 und /24 zu betreiben, so dass die Kommunikation zwischen den beiden Netzen über das öffentliche Netz /24 verschlüsselt abläuft. Der Aufbau des Versuchs verläuft zunächst genau wie in Abschnitt dargestellt. Auf betreiben wir wieder unseren Server auf Port 80 und testen zunächst von aus die Verbindung durch Aufruf über einen Webbrowser. Im /24er Netz kann die

7 10.9 OpenVPN vii resultierende TCP-Verbindung wie erwartet unverschlüsselt beobachtet werden. Nun wollen wir OpenVPN aufsetzen und konfigurieren, um einen verschlüsselten Tunnel zwischen den beiden Routern und zu betreiben. Um OpenVPN betreiben zu können, haben wir auf diesen Maschinen die Pakete openvpn und openssl installiert. OpenVPN verfügt über eine Vielzahl von möglichen Optionen und Betriebsmöglichkeiten. Wir werden im Folgenden darstellen, wie man einen Tunnel betreibt, der die Daten auf der Netzwerkschicht entgegennimmt, via SSL/TLS verschlüsselt und über TCP (serverseitig Standardport 1194) befördert. OpenVPN kann ebenso auf der Datenverbindungsschicht arbeiten. OpenVPN basiert auf SSL/TLS. Entsprechend kommen zur Authentifikation der Maschinen Zertifikate zum Einsatz. Wir hatten bereits in Abschnitt betrachtet, wie man mit OpenSSL eine einfache Certificate Authority betreiben und Zertifikate erstellen kann. Genau wie dort skizziert erstellen wir nun private Schlüssel und zugehörige Zertifikate für beide Maschinen. Nach Abschluss der Prozedur haben wir fünf Dateien, die wir im Folgenden benötigen: Name Beschreibung vorhanden auf ca-cert.pem Zertifikat der CA beiden Maschinen cert.pem Zertifikat von priv.pem privater Schlüssel von cert.pem Zertifikat von priv.pem privater Schlüssel von In unserem Beispiel muss eine der Maschinen als Client, die andere als Server auftreten. Wir treffen die willkürliche Festlegung, dass als Server und dass als Client fungiert. Wenden wir uns als Erstes dem Server, also zu. Zunächst wechseln wir in das Verzeichnis /etc/openvpn. In diesem Verzeichnis befinden sich die Konfigurationsdateien für OpenVPN. Wir kopieren ca-cert.pem, cert.pem und priv.pem in dieses Verzeichnis. Auf dem Server benötigen wir noch eine weitere mit OpenSSL zu erstellende Datei, die notwendige Konfigurationsdaten für einen beim Aufbau der Verbindung notwendigen Diffie-Hellman-Exchange beinhaltet. Diese Datei 1024.pem erzeugen wir mit dem Befehl openssl dhparam -out dh1024.pem 1024 Die Ausgabe beim Aufruf des Befehls sieht ungefähr so aus: rout2:/etc/openvpn # openssl dhparam -out dh1024.pem 1024 Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time

8 viii 10 Virtual Private Networks *++*++* rout2: Nun müssen wir noch eine Konfigurationsdatei für OpenVPN erstellen. Diese Datei mit dem Namen server.conf sieht wie folgt aus: dev tun proto tcp-server tls-server ifconfig ca /etc/openvpn/ca-cert.pem cert /etc/openvpn/ cert.pem key /etc/openvpn/ priv.pem dh /etc/openvpn/dh1024.pem Wir wollen uns die einzelnen Einträge kurz näher anschauen. dev tun gibt an, dass OpenVPN die zu befördernden Daten auf der Netzwerkschicht entgegennimmt. Die beiden Zeilen proto tcp-server und tls-server weisen diesem Rechner die Rolle des Servers zu. Auf ifconfig kommen wir gleich noch zurück. Unter ca ist das Zertifikat der verwendeten CA, unter cert das eigene Zertifikat des Rechners und unter key der zugehörige private Schlüssel angegeben. Abschließend steht unter dh, wo sich die gerade erzeugte Datei mit den Parametern für den Diffie-Hellman-Exchange befindet. Auf , dem Client, können wir ganz analog vorgehen. Wir kopieren die notwendigen Schlüssel und Zertifikate in /etc/openvpn und erstellen eine Konfigurationsdatei client.conf wie folgt: dev tun proto tcp-client tls-client remote ifconfig ca /etc/openvpn/ca-cert.pem cert /etc/openvpn/ cert.pem key /etc/openvpn/ priv.pem Die Datei ist analog zu der auf dem Server aufgebaut. remote gibt an, zu welcher anderen Maschine der OpenVPN-Tunnel aufgebaut werden soll. Wir starten nun auf dem Server und dann auf dem Client OpenVPN mit dem Befehl openvpn --config /etc/openvpn/server.conf bzw. openvpn --config /etc/openvpn/client.conf Durch das Starten von OpenVPN entsteht auf beiden Rechnern ein virtuelles Nertzwerkinterface mit dem Namen tun0. Wie ein richtiges Interface hat tun0 ebenfalls eine IP-Adresse, und der Status des Interfaces kann wie gewohnt durch den Befehl ifconfig abgefragt werden. Führen wir dies auf durch, so erhalten wir folgende Ausgabe:

9 10.9 OpenVPN ix / / /24 OpenVPN-Tunnel erscheint als direkte Punkt-zu-Punkt-Verbindung zwischen neuen virtuellen Interfaces Abbildung 10.24: (Scheinbare) Situation nach Aufbau des OpenVPN-Tunnels im praktischen Test. rout2:/etc/openvpn # ifconfig tun0 tun0 Link encap:unspec HWaddr inet addr: P-t-P: Mask: UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Die IP-Adresse des Interfaces ist also Wie man den Ausgaben weiter entnehmen kann, ist dieses Interface eine Punkt-zu-Punkt-Verbindung zu Rechner Es wird Sie wahrscheinlich nicht sonderlich überraschen, dass auf der Maschine das tun-interface die IP-Adresse besitzt und eine direkte Punkt-zu-Punkt-Verbindung zu darstellt. Damit ist also nach Aufbau des Tunnels scheinbar die in Abbildung gezeigte Situation entstanden. Nachdem nun das OpenVPN aktiv ist, wollen wir wiederum auf einen Browser starten, der unseren Server auf kontaktiert, und wir werden wiederum im /24er Netz die Pakete mitlesen. Im Vergleich zur Situation vor dem Start von OpenVPN hat sich jedoch keine Veränderung ergeben. Abermals können wir die gesamte TCP-Verbindung zwischen den beiden Rechnern mitlesen, da die Pakete nach wie vor im Klartext übertragen werden. Doch das ist eigentlich nicht überraschend. Um das Verhalten zu verstehen, müssen wir die Routing-Tabellen auf den beiden Gateways betrachten. Wir hatten uns mit Routing-Tabellen und deren Aufbau schon in Abschnitt befasst. Die Routingtabelle des Routers sieht fast exakt so aus wie in Abbildung 7.15 gezeigt, allerdings mit einem zusätzlichen Eintrag:

10 x 10 Virtual Private Networks rout:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface * UH tun UG eth * U eth * U eth8 loopback * U lo Dieser erste Eintrag besagt, dass alle an gerichteten Pakete (siehe Abschnitt ) über tun0 direkt an diese Maschine geschickt werden. Pakete, die nicht direkt an gerichtet sind, sind von diesem Eintrag nicht betroffen und werden entsprechend nicht über das neue virtuelle Interface übertragen. Nach wie vor werden Pakete in das /24er Netz über eth7 an das Gateway geschickt. Dies gilt auch für die Daten unserer TCP-Verbindung von zu Mit anderen Worten: Die neue virtuelle Punkt-zu-Punkt-Verbindung wird links liegengelassen und das Paket weiterhin direkt (und unverschlüsselt) über das öffentliche Netz geschickt. Dies wollen wir nun ändern, indem wir die Routingeinträge entsprechend ändern. Zunächst löschen wir die bisherige Route in das /24er Netz mit dem Befehl route del -net /24 Dann fügen wir eine neue Route ein. Pakete mit Ziel im /24er Netz werden direkt über die neue virtuelle Verbindung befördert: route add -net /24 gw Hierdurch entsteht folgende Routingtabelle: rout:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface UH tun UG tun U eth U eth U lo Lassen wir zunächst die Routingtabelle auf dem anderen Endpunkt des Tunnels ( ) unverändert und beobachten vom /24er Netz aus, was wir beim Aufruf unseres Servers auf von aus beobachten. Abbildung zeigt einen Screenshot von Wireshark. Es ist zu sehen, dass die Pakete von zu nicht im Klartext zu sehen sind. Diese Pakete werden aufgrund unserer Routenänderung nun durch OpenVPN behandelt und verschlüsselt durch den OpenVPN-Tunnel von nach transportiert. Entsprechende Pakete finden sich auch im Screenshot. Die Pakete in der Rückrichtung zwischen und sind aber nach wie vor im Klartext sichtbar.

11 10.9 OpenVPN xi Abbildung 10.25: Wireshark-Analyse der Verbindung zwischen und von er Netz aus beobachtet. Abbildung 10.26: Wireshark-Analyse der Verbindung zwischen und von er Netz aus beobachtet mit partieller Verschlüsselung. Wahrscheinlich haben Sie nach den Vorbemerkungen dieses Verhalten so auch erwartet und können es sich erklären. Da wir auf die Routingtabelle nicht geändert haben, werden dort nach wie vor alle Pakete vom /24er Netz in das /24er Netz direkt über das /24er Netz verschickt. Entsprechend müssen wir auch dort noch die Routingtabelle analog zum oben gezeigten Vorgehen auf dem anderen Router ändern.

12 xii 10 Virtual Private Networks Danach ergibt sich die in Abbildung gezeigte Situation. Es ist nur noch Verkehr zwischen und zu beobachten. Der Verkehr erscheint als TCP-Verkehr zwischen diesen Maschinen. Da die übertragene Nutzlast dieser Verbindung durch SSL/TLS verschlüsselt und integritätsgeschützt ist, können keinerlei Rückschlüsse auf die Inhalte der Kommunikation gezogen werden. Ebenso ist eine unbemerkte Veränderung der Daten unmöglich. Dies entspricht der Situation, wie wir sie auch nach dem Aufbau des IPsec-Tunnels in Abschnitt vorgefunden haben.

13