Ein Virtual Private Network (VPN) ist ein geschlossenes Kommunikationsnetz, das über eine bestehende physische Verbindung aufgebaut wird. Der Name ergibt sich daraus, dass diese neue Verbindung nicht physisch existiert und sie meist verschlüsselt wird, somit als privat angesehen werden kann. Grundsätzlich wird ein VPN verwendet, um verschiedene Teilnehmer über ein unsicheres oder mehrere verschiedene Netze in ein gemeinsames Netzwerk zu verknüpfen.
VPNs haben eine Vielzahl an Einsatzmöglichkeiten, wie z.B. die Verbindung von zwei geografisch getrennten Netzwerken. Dies wird oftmals verwendet, um Außenstellen mit einer zentralen Geschäftsstelle zu verbinden. Auch für Telearbeit sind VPNs häufig im Einsatz, um Angestellten einen sicheren Zugriff auf das Unternehmensnetzwerk und dessen Ressourcen zu gestatten. Im Zeitalter der Massenüberwachung werden VPNs auch oft verwendet, um Geoblocking bzw. Zensur zu umgehen, oder aber um die Privatsphäre zu schützen.
Abhängig vom Anwendungsbereich gibt es verschiedene VPN-Lösungen. Eine Hauptunterscheidung zwischen den unterschiedlichen VPN-Implementationen ist die Unterscheidung auf OSI Layer-Ebene.
Auf dem Data Link Layer (2. Layer) ist der Vorteil, dass auch andere Protokolle als das klassische IP gesprochen werden können. Typische Layer 2-VPNs sind Point-to-Point Tunneling Protocol (PPTP, Microsoft) und das Layer 2 Tunneling Protocol (L2TP, Cisco).
IPSec ist der quasi Standard für IP-Kommunikationsverschlüsselung auf dem Network Layer (Layer 3), jedoch handelt es sich hierbei nicht um eine genau definierte Implementation, sondern um eine Ansammlung von Protokollen, Standards und Mechanismen. Kompatibilität zwischen den zahlreichen IPSec-fähigen Geräten muss nicht gegeben sein, da es unzählige angepasste Implementationen gibt.
Mit Software wie Secure Shell (SSH) ist eine VPN-Implementation auf dem Transport Layer (Layer 4) möglich. Alternative Layer 4-VPNs werden häufig über HTTPS und Browser Plug-Ins implementiert.
Im Prinzip lässt sich ein VPN folgendermaßen repräsentieren.
Die Kommunikation findet über ein geteiltes physisches Medium, wie beispielsweise das Internet, statt. Die Ressourcen, die über das VPN für den Client erreichbar sind, können von dem VPN-Server definiert werden. Dies geschieht meist mit der Hilfe von Firewall-Regeln. Der VPN-Client kann auch ein gesamtes Netzwerk tunneln, was auch als Site-to-Site-Verbindung bezeichnet wird. Dies gilt auch für nachfolgende Illustrationen.
OpenVPN
OpenVPN ist eine beliebte, weit verbreitete VPN-Lösung, die sich seit 2001 etabliert hat. Der Hersteller bietet zwei Versionen an, eine kommerzielle Lösung, den OpenVPN Access Server, mit Vorteilen für Unternehmen, wie z.B. das erleichterte Management, dedizierte Client-Software und erweiterte Funktionalität. Die kostenpflichtige Version basiert auf der Community-Version, die frei verfügbar ist und sowohl Server- als auch Client-Funktionalität in einer Applikation vereint.
In diesem Blogartikel wird eine sichere Konfiguration des OpenVPN Community-Servers behandelt. Die Community-Version ist quelloffen und für alle modernen Betriebssysteme verfügbar.
Grundsätzlich besteht ein OpenVPN-Tunnel aus zwei Kanälen: dem Kontroll- und dem Datenkanal. Diese werden jedoch schlussendlich auf Netzwerkebene in eine Verbindung gebündelt, folglich wird auf dem Server und auf dem Client jeweils nur ein Port für die Verbindung benötigt.
OpenVPN verlässt sich für die Netzwerkkommunikation auf TUN/TAP-Adapter, die inzwischen von fast allen modernen Betriebssystemen unterstützt werden. Ein TUN-Adapter basiert auf Layer 3 und erlaubt Kommunikation ausschließlich auf IP-Basis. Ein TAP-Adapter arbeitet auf Layer 2 und erlaubt somit auch andere Protokolle, wie z.B. IPX. Der Betrieb mit TUN-Adaptern wird häufig als Routing Modus bezeichnet, da der Verkehrsfluss mittels Routing bestimmt wird. Im Gegensatz dazu spricht man bei TAP-Adaptern vom Bridging Modus, da diese sich wie eine Netzwerkbrücke verhalten. Weil OpenVPN auf virtuellen Netzwerkadaptern basiert, ist es möglich, jede netzwerkfähige Applikation transparent über das VPN zu betreiben.
Intern sieht eine beispielhafte Kommunikation, vereinfacht dargestellt, folgendermaßen aus:
Der vorhin erwähnte Kontrollkanal wird auch „Reliability Layer“ genannt. Dieser Kanal ist für den Verbindungsaufbau, den Schlüsselaustausch und den Austausch von weiteren Konfigurationsvektoren zuständig. Der Kontrollkanal ist im Normalfall eine TLS-verschlüsselte Verbindung (TLS Mode). Wenn explizit konfiguriert, kann hierfür statt der sichereren TLS Verbindung (Static-Key Mode) ein statischer Schlüssel verwendet werden. Da ein statischer Schlüssel jedoch schwer skalierbar ist, wird der Einsatz nicht empfohlen.
Der Datenkanal wird für die verschlüsselte Übertragung der eigentlichen Nutzdaten verwendet. Dieser Kanal ist mit symmetrischer Verschlüsselung gesichert, wobei der Schlüssel über den Kontrollkanal übertragen wird.
Die Sicherheit eines OpenVPN-Tunnels ist von mehreren Faktoren abhängig, die primär die Konfiguration dieser beiden Kanäle betreffen.
Konfiguration
Die folgenden Konfigurationsempfehlungen betreffen den OpenVPN-Server und müssen je nach Client angepasst werden. Clients müssen die gewählten Optionen ebenso unterstützen. Außerdem muss die Firewall am OpenVPN-Server unbedingt entsprechend konfiguriert werden. Gewünschte Routen und Einschränkungen sind vom jeweiligen Setup abhängig und können nicht allgemein gültig definiert werden. Eine häufige Empfehlung ist es jedoch, den Server als das Standardgateway für die Clients zu definieren und dort dann angemessene Weiterleitungen einzurichten. Man sollte auch nicht vergessen, dass am Client eventuelle DNS-Server vergeben werden sollten, dass diese auch interne DNS-Namen auflösen können.
Die Empfehlungen beziehen sich nur auf die Sicherheit und nehmen keine Rücksicht auf Clientkompatibilität, die von der eingesetzten SSL-Bibliothek und der OpenVPN-Version abhängig ist.
Weiterführende Erklärungen zu den Optionen sind in dem OpenVPN Manual verfügbar.
tls-cipher: Diese Option bestimmt die erlaubten TLS cipher suites für den Kontrollkanal. Hier gelten dieselben Empfehlungen wie in unserem Blog-Eintrag über Sichere SSL/TLS Konfiguration. Auch für eine tiefergehende Erklärung zu den TLS cipher suites lesen Sie diesen Blogeintrag.
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
tls-auth (für OpenVPN < 2.4): Falls OpenVPN Version >= 2.4 zur Verfügung steht, sollte die nachfolgende Option tls-crypt verwendet werden. Diese beiden Optionen schließen sich gegenseitig aus. Die Option tls-auth fügt eine zusätzliche Authentifizierungsschicht ein, die einen statischen Schlüssel verwendet. Beide Kommunikationspartner benötigen denselben Schlüssel, der im Voraus mit OpenVPN generiert werden muss. Die Schlüsselrichtung sollte zwischen Client und Server, zwischen 0 und 1 alternieren; z.B. wird dem Server 0 zugewiesen und allen Clients 1.
tls-auth <statischer-schlüssel> <schlüsselrichtung>
tls-crypt (für OpenVPN >= 2.4): Mit OpenVPN Version 2.4 wurde die tls-crypt Option eingeführt, die Funktion von tls-auth (s. oben) erweitert. Der definierte statische Schlüssel wird neben dem Authentifizieren auch zum Verschlüsseln aller Pakete des Kontrollkanals verwendet. Dies bietet zusätzliche Sicherheit und verbessert die Privatsphäre. Beide Parteien benötigen wieder denselben statischen Schlüssel, aber die Schlüsselrichtung wird mit dieser Option obsolet.
tls-crypt <statischer-schlüssel>
tls-version-min/tls-version-max: (Nach Blogartikel-Update hinzugefügt) Mit diesen Optionen können die TLS Versionen eingeschränkt werden. Es wird empfohlen die TLS Version auf die höchstmögliche einzustellen. Der Standardwert der „max“ Version ist „or-highest“ – also die höchste vom System unterstützte Version, was wünschenswert ist. Die „min“ Version hingegen ist normalerweise 1.0, was als unsicher angesehen werden sollte. Aus diesem Grund sollte die „min“ Version auf 1.2 erhöht werden.
tls-version-min 1.2
cipher: Die Option cipher definiert den für den Datenkanal verwendeten symmetrischen Verschlüsselungsalgorithmus. Bis Version 2.4 war es nur möglich, einen Cipher zu definieren, der bei Server und Client identisch konfiguriert werden musste, seither existiert die Nachfolge-Direkte ncp-ciphers-Option. AES mit einer Schlüssellänge von 256 bit und GCM ist empfohlen.
cipher AES-256-GCM
ncp-ciphers (für OpenVPN >= 2.4): Mit OpenVPN Version 2.4 wurde die Option ncp-cipher eingeführt, um es Client und Server zu erlauben, den eingesetzten Cipher auszuhandeln. Diese Option ist mit der cipher-Option gleichzusetzen, außer dass hier eine Liste (mit Doppelpunkt getrennter Wert) an ciphern definiert werden kann. Dies kann hilfreich bei dem Einsatz von unterschiedlichen Clients sein. Die Aushandlung des eingesetzten ciphers kann explizit mit der Option ncp-disable verhindert werden. Wie bei der Option tls-ciphers wird versucht, einen gemeinsamen cipher zwischen Server und Client zu finden, der dann für die Verbindung verwendet wird.
ncp-ciphers AES-256-GCM:AES-192-GCM:AES-128-GCM
auth: Die auth-Option bestimmt den Algorithmus, der für die Authentifizierung der Pakete des Datenkanals eingesetzt wird. Ist ein Authenticated Encryption with Associated Data (AEAD), wie z.B. GCM, im Einsatz, wird dieser für den Datenkanal ignoriert, aber weiterhin für tls-auth bzw. tls-crypt verwendet. Empfohlen ist der Algorithmus SHA512.
auth SHA512
Zusätzliches:
Die sicherheitskritischsten Optionen betreffen die Verschlüsselungs- und Hashingfunktionen für die beiden Kommunikationskanäle. Davon abgesehen gibt es weitere Optionen, die die Sicherheit des VPNs beeinträchtigen können.
Verwendete TLS-Schlüssel sollten mindestens 2.048 Bit lang sein. Im Normalfall wird für die Generierung dieses Schlüssels das integrierte Tool easy-rsa (/usr/share/easy-rsa) verwendet. Die Schlüssellänge kann auf 4.096 Bit erhöht werden, indem vor der Schlüsselerzeugung in der entsprechenden vars-Datei (z.B. /usr/share/easy-rsa/vars) die Variable KEY_SIZE auf 4.096 geändert wird.
export KEY_SIZE = 4096
Der Standardwert für die Zeit, nach der der Schlüssel für den Datenkanal erneuert wird, beträgt 3.600 Sekunden. Sollte das VPN verwendet werden, um große Datenmengen zu übertragen, kann man alternativ nach einer bestimmten Anzahl an übertragenen Bytes die Schlüssel erneuern. Die Option reneg-bytes kann hierfür verwendet werden (z.B. nach 64 MB).
reneg-bytes 64000000
Die Authentifizierung von Clients geschieht normalerweise über die Clientzertifikate, oder im Fall des nicht empfohlenen Static Key-Modus über den statischen Schlüssel. Falls erwünscht kann zusätzlich eine Benutzernamen- und Passwortabfrage für die Authentifizierung implementiert werden. Dies geschieht mittels Plugins, die die Funktionalität von OpenVPN erweitern. Das Plugin openvpn-plugin-auth-pam.so (unter /usr/lib/openvpn) ist bereits nach der Installation vorhanden und erlaubt die Authentifizierung gegenüber Linux Pluggable Authentication Modules (PAM). Die vom Client eingegebenen Anmeldedaten werden über den TLS-gesicherten Kontrollkanal übertragen. Mit der folgenden Konfiguration kann eine zusätzliche Authentifizierung implementiert werden, die Benutzernamen und Passwort voraussetzt, die auf dem OpenVPN Server geprüft werden.
Server:
plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so
Client:
auth-user-pass
Weitere Optionen, wie die Clientkonnektivität, sind rein von dem Einsatzszenario des VPN abhängig, aber beeinträchtigen möglicherweise die Sicherheit der Clients. Sollen verbundene Clients innerhalb des VPN untereinander kommunizieren können, so kann die folgende Option konfiguriert werden. Ist dies nicht benötigt, ist empfohlen, diese Option nicht zu setzen.
client-to-client
Zusammenfassung
Hauptsächlich ausschlaggebend für die Sicherheit eines OpenVPN-Tunnels sind die Optionen für Verschlüsselung und Hashing des Kontroll- und Datenkanals. Weitere Einstellungen sind stark von den jeweiligen Einsatzszenarien abhängig und sollten mit Sorgfalt gewählt werden. Nachfolgend steht die offizielle OpenVPN-Serverkonfigurationsvorlage, angepasst mit den empfohlenen Verschlüsselungs- und Hashingalgorithmen.
port 1194 proto udp dev tun ca ca.crt cert server.crt key server.key dh dh4096.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt keepalive 10 120 tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 tls-crypt ta.key tls-version-min 1.2 ncp-ciphers AES-256-GCM:AES-192-GCM:AES-128-GCM auth SHA512 persist-key persist-tun status openvpn-status.log verb 3 explicit-exit-notify 1
Vorschau
In naher Zukunft werden wir zwei Tools für den sicheren Einsatz von OpenVPN veröffentlichen. Das erste ist bei der lokalen Sicherheitsanalyse der OpenVPN-Serverkonfiguration behilflich, das zweite erlaubt das dynamische Bewerten einer OpenVPN-Verbindung und bietet Verbesserungshinweise. Seien Sie gespannt!
Nützliche Links
- OpenVPN Manual (2.4)
- OpenVPN Security Übersicht
- OpenVPN Hardening Tipps
- OpenVPN Server Konfigurationsbeispiel
Update: Wir haben vor kurzem das Erste der beiden Tools, zur Sicherheitsanalyse von OpenVPN-Konfigurationsdateien in der Beta Version auf GitHub veröffentlicht: OpenVPN-Review.
Die Analyse mit dem OpenVPN-Review Tool hat auch in der hier angegebenen Konfiguration Verbesserungspotential erkannt und dementsprechend wurde die Konfiguration angepasst. Konkret wurde die Option „tls-version-min 1.2“ hinzugefügt. Lesen Sie mehr zu dem Tool dem Einführungsartikel auf unserem Blog.
