Bereits Kunde? Jetzt einloggen.
Lesezeit ca. 10 Min.

Auf sicheren Pfaden


IT Administrator - epaper ⋅ Ausgabe 3/2020 vom 28.02.2020

Ein VPN-Server sichert Verbindungen in das Netzwerk oder die Cloud - umgebung des Unternehmens. Zudem schützt er den Internetverkehr von Laptops und Smartphones, wenn diese in ungesicherten WLANs arbeiten müssen. Mit OpenVPN steht Administratoren eine leicht einzurichtende wie flexible und kostenfreie VPN-Variante zur Verfügung. Wir zeigen, wie das Setup funktioniert.


OpenVPN einrichten

Artikelbild für den Artikel "Auf sicheren Pfaden" aus der Ausgabe 3/2020 von IT Administrator. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Bildquelle: IT Administrator, Ausgabe 3/2020

Virtual Private Networks (VPNs) stellen einen gesicherten Tunnel zwischen Anwender und Intranet her und schützen Zugriffe auf Intranetdienste. Zudem verbirgt ein VPN-Tunnel die komplette Kommunikation zwischen Client und ...

Weiterlesen
epaper-Einzelheft 8,99€
NEWS 14 Tage gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von IT Administrator. Alle Rechte vorbehalten.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 3/2020 von News: Kritische Azure-Schwachstellen. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
News: Kritische Azure-Schwachstellen
Titelbild der Ausgabe 3/2020 von Zwiebelprinzip. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Zwiebelprinzip
Titelbild der Ausgabe 3/2020 von Filter für den Webverkehr. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Filter für den Webverkehr
Titelbild der Ausgabe 3/2020 von Red Hat Forum 2020, Darmstadt, 14. Januar Offene Wege. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Red Hat Forum 2020, Darmstadt, 14. Januar Offene Wege
Titelbild der Ausgabe 3/2020 von Interview: »Im Leben ist Vertrauen unabdingbar, im digitalen Umfeld Risiko Nummer eins«. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Interview: »Im Leben ist Vertrauen unabdingbar, im digitalen Umfeld Risiko Nummer eins«
Titelbild der Ausgabe 3/2020 von McAfee Total Protection for Data Loss Prevention Kontrollierter Datenfluss. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
McAfee Total Protection for Data Loss Prevention Kontrollierter Datenfluss
Vorheriger Artikel
Perfektes Abbild
aus dieser Ausgabe
Nächster Artikel Wegweiser in die digitale Zukunft
aus dieser Ausgabe

... VPN-Server vor dem umgebenden Transportnetzwerk. Wer viel reist, weiß diese Funktion zu schätzen. Viele öffentliche WLANs in Hotels, Flughäfen, Restaurants oder Firmen-Gastnetzwerken arbeiten nach wie vor ohne Verschlüsselung. Auch wenn fast alle Applikationsprotokolle heute mit SSL arbeiten, können Angreifer in einem offenen WLAN immer noch sensible Metadaten anderer Kommunikationsteilnehmer abgreifen: DNS-Abfragen, Zielsysteme mit Ports und abgerufene URLs. Ein VPN verbirgt diese Informationen und alles, was ein Angreifer noch sieht, sind verschlüsselte Pakete zwischen Client und VPN-Endpunkt.

Flexibles OpenVPN

Neben diversen kommerziellen Imple - mentierungen setzen viele Unternehmen und Privatanwender auf das quelloffene OpenVPN [1], das auf den OpenSSL-Bibliotheken basiert. Es gehört zu den am besten dokumentierten und sicheren VPNLösungen, läuft auf nahezu allen Clientund Serverplattformen und lässt sich sehr flexibel konfigurieren. Der OpenVPN-Server für Linux ist bei vielen Linux-Distributionen enthalten oder über das EPELRepository (RHEL und CentOS) verfügbar. OpenVPN und Clientwerkzeuge für Linux sind in allen gängigen Distributionen enthalten, inklusive GUI-Frontend für den NetworkManager. Der OpenVPN-Client für Android lässt sich kostenlos über Google Play installieren.

Vor dem gesicherten VPN-Tunnel steht erst einmal die gesicherte Authentisierung des Clients am Server. OpenVPN beherrscht dabei mehrere Möglichkeiten wie Zertifikate mit Schlüsseln, Zweifaktor- Authentifizierung, Integration in bestehende Single-Sign-on-Lösungen oder einfach nur Passwörter. Der Workshop beschreibt die Methode mit Nutzerzertifikaten, da diese eine einfache Handhabung und gute Sicherheit bietet.

Standardmäßig lauscht der OpenVPNServer auf UDP-Port 1194 auf eingehende Verbindungen. Optional lässt sich aber auch das TCP-Protokoll nutzen und alternative Ports wie 443 verwenden. Eine TCP-Verbindung auf 443 ergibt vor allem für Anwender Sinn, die häufig unverschlüsselte WLANs nutzen. Immer öfter begrenzen die Betreiber offener WLANs die Kommunikation der Clients auf Standard- Ports wie 80, 443, 53 oder 993 und blockieren Nicht-Standard-Portzugriffe, darunter häufig auch UDP 1194. Zudem kommen oft transparente Proxy-Server auf den Ports 80 und 443 zum Einsatz. Die so verriegelten Netzwerke kann eine VPN-Konfiguration mit TCP auf Port 443 meistens überwinden. Auf dem VPNServer bleibt dabei der parallele Betrieb eines https-Servers und des OpenVPNServers möglich. In diesem Fall lauscht der OpenVPN-Server exklusiv auf den Port 443, leitet dann aber allen Nicht- VPN-Traffic über einen anderen Port an den Web-Server weiter.

Brücke oder Tunnel

Ein VPN-Tunnel kann eine Netzwerkverbindung auf Layer 2 (Bridge) oder Layer 3 (Route) aufbauen. Obwohl die Brücke auf den ersten Blick wie die bessere Lösung aussieht, funktioniert die Route deutlich zuverlässiger. Bei einer Bridge bekommt der Client eine Adresse aus dem lokalen Intranet des VPN-Servers. Alle Systeme im Intranet und im VPN erscheinen daher im selben IP-Segment. Allerdings überträgt das private Netzwerk dann auch allen Layer- 2-Paketmüll, der in einem lokalen Netzwerk herumschwirrt, an den Client: Broadcasts, Service-Discovery-Pakete, LLDP und andere Protokolle, die der Client eigentlich nicht braucht. Das alles geht zu Lasten der Tunnelbandbreite. Zudem gestaltet sich eine Bridge-Konfiguration komplexer als die einer Route.

Bild 1: Für unseren Workshop nutzen wir eine einfache Google-Cloud-VM.


Die Route legt einen zusätzlichen virtuellen LAN-Adapter auf dem VPN-Client und -Server mit einem eigenen Transfer-Netzwerksegment an. Der IP-Verkehr zum VPN wird dann über Routing-Regeln gesteuert. Der Anwender entscheidet so, ob jeglicher Client-Traffic das VPN passiert, was die gewünschte Funktion eines Clients in einem unverschlüsselten WLAN wäre. Alternativ sendet der Client ausschließlich das IP-Segment des Intranets, in dem der VPN-Server arbeitet, über den Tunnel. Das wäre der Betriebsmodus für einen Administrator im Home-Office. Den regulären Internet-Traffic sendet der Client wie gehabt über die bestehenden Routen direkt ins Internet und nur die Kommunikation vom und zum Intranet des Unternehmens passiert den VPNTunnel. Was letztendlich über den Tunnel geht, entscheidet ausschließlich das IP-Routing. So lässt sich der VPN-Tunnel ohne besonderen Konfigurationsaufwand für beide Transfermodi nutzen

Umgang mit IPv6-Verkehr

Wenn Sie ein getunneltes VPN via IPv4 aufsetzen, Ihr Rechner aber parallel über eine gültige IPv6-Konfiguration verfügt, kann sich Ihr kompletter Internetverkehr via IPv6 am sicheren Tunnel vorbeimogeln, was natürlich nicht passieren darf. Hier gibt es zwei Optionen: Zum einen lässt sich IPv6 während einer aktiven VPN-Verbindung abschalten, was den kompletten Internet-Traffic auf IPv4 zwingt und durch den Tunnel schickt. Der etwas komplexere, aber korrekte Weg ist natürlich, passende IPv6-Routen auf dem OpenVPN-Server anzulegen und damit den IPv6-Traffic über den VPNTunnel zu senden (6over4-Tunneling).

Beispielumgebung mit Cloudserver

Für unseren Workshop rollen wir eine virtuelle Maschine mit CentOS 7 als VPN-Server auf der Google-Cloud-Plattform aus und richten das VPN via TCPPort 443 ein. Wer in ein bestehendes Unternehmens- oder Heim-LAN tunneln möchte, kann dort eine VM oder einen Server bereitstellen - ein Raspberry PI genügt. Sie müssen dann aber sicherstellen, dass das System entweder über eine feste IP-Adresse oder einen FQDN (etwa mit DynDNS) von außen erreichbar ist. Die entsprechenden IP-Forwarding- und Port-Forwarding-Rules für den VPN-Zugang müssen auf dem Router bestehen.

Für unseren VPN-Server genügt eine günstige "n1-standard"-VM mit 3,75 GByte RAM, einer vCPU und einer 10 GByte Root-Disk. Da wir in unserem Szenario einen eigenen DynDNS-Dienst betreiben, bekommt der Cloudserver einen festen FQDN. Somit funktioniert die VPN-Clientkonfiguration unabhängig von den wechselnden IP-Adressen des Cloudservers. Googles CentOS-7-VMs integrieren von Haus aus das EPEL-Repository. Wer CentOS manuell installiert, muss dies mit yum install epel-release erledigen. Alle benötigten Pakete für den VPN-Server installieren Sie mit

Der Server und der Clouddienst benötigen zunächst passende Firewallregeln, um den VPN-Traffic via Port 443 auf das System zu lassen. Damit das VPN funktioniert, muss der Server zudem IPv4- Forwarding zulassen - eine Funktion, die Google bei Cloudservern per Vorgabe abschaltet. Diese Einstellung finden Sie in der Datei "/etc/sysctl.d/11-gce-networksecurity. conf ". In ihr ändern Sie den Parameter "net.ipv4.ip_forward=0" auf "net.ipv4.ip_forward=1". Bei einem manuell installierten CentOS schreiben Sie den Parameter einfach ans Ende der Datei "/etc/sysctl.d/99-sysctl.conf". Da die Konfiguration erst nach einem Neustart greift, setzen Sie den Parameter interaktiv über das Kommando

Zudem muss die Firewall des Rechners den ausgehenden IP-Traffic des Tunnels maskieren, was das Kommando erledigt, wenn Sie iptables nutzen oder mit Firewalld.

Bild 2: Auch unter Android ist OpenVPN nutzbar.


Zertifikate und Schlüssel erzeugen

Das Toolset "Easy-Rsa" macht es dem Anwender sehr leicht, Zertifikate und Schlüssel zu verwalten. Nach der Installation finden sich die Pakete unter "/usr/share/ easy-rsa/& Versionsnummer &". Legen Sie einen passenden Ordner für Ihre Certificate- Authority-Konfiguration an; wir verwenden dafür einfach "/root/rsa". Kopieren Sie den kompletten Inhalt des "easy-rsa"- Unterverzeichnisses (im Workshop Version 3.0.6) nach "/root/rsa".

Als Erstes benötigt das SSL-VPN eine Zertifizierungsstelle, die Certificate Authority (CA). Die erstellt sich der Anwender einfach selbst, ein "offizielles" Zertifikat ist für das private VPN nicht nötig. Ebenso kann der Anwender auf detaillierte Metadaten seiner CA (Land, OU, Bundesstaat, Ansprechpartner, Ort et cetera) verzichten. Auf die Funktion des VPNs haben diese Informationen keinen Einfluss.

Innerhalb des "/root/rsa"-Verzeichnisses starten Sie jetzt das Kommando ./easyrsa init-pki, das ein "pki"-Verzeichnis und die CA-Konfigurationsdatei in "/root/rsa/ pki" anlegt. Dann erstellen Sie Ihre eigene Root- CA nebst Zertifikat plus passenden Schlüssel mit dem Kommando ./easyrsa buildca. Sichern Sie den CA-Schlüssel mit einem starken Passwort ab. Wer den Zugriff zu Schlüssel und CA erhält, kann jederzeit Clientschlüssel erstellen und signieren.

Im zweiten Schritt bekommt der Open - VPN-Server selbst ein gültiges Serverzertifikat namens "vpnserver" und einen passenden Schlüssel, der dann allerdings ohne Passwort funktionieren muss. Würden Sie ein Serverzertifikat mit Passwort auf dem Schlüssel bauen, müssten Sie bei jedem Start des VPN-Servers dieses Passwort eintippen:

Das Kommando gen-req erstellt dabei zunächst einen Request für das Zertifikat, der im nächsten Schritt von der CA signiert wird:

Details zum Zertifikat und dessen Gültigkeit erhalten Sie mit dem openssl-Tool:

Dabei tragen Sie besser schon einmal im Kalender rot ein, dass die mit den Default-Einstellungen erzeugten Zertifikate 1080 Tage lang gültig sind. In knapp drei Jahren brauchen Sie also neue. Passend zum Server benötigt jeder VPN-Client ein eigenes Zertifikat, das Sie nach demselben Prinzip anfordern und signieren:

Theoretisch erlaubt OpenVPN, dass sich mehrere Clients gleichzeitig mit demselben Zertifikat anmelden. So könnte ein einziges Clientzertifikat für viele Systeme genügen. Davon ist aber dringend abzuraten. Sollte eines Ihrer Engeräte mit installiertem VPN-Clientzertifikat abhandenkommen oder ein Unbefugter ein Clientzertifikat abgreifen, kann OpenVPN auf dem Server einzelne Zertifikate für ungültig erklären und damit den betroffenen Zugang sperren. Dazu würden Sie den entsprechenden Eintrag zurücknehmen

und eine Liste der ungültigen Zertifikate erstellen

Diese "Certificate Revoking List" müssen Sie danach in der OpenVPN-Server-Konfiguration eintragen. Zu den Zertifikaten gesellt sich abschließend ein "Diffie-Hellman"- Schlüssel. In Kombination mit der CA und dem Clientschlüssel errechnet OpenVPN dann die eigentlichen Transfer- Keys für den VPN-Tunnel: ./build-dh. Die benötigten Schlüssel und Zertifikate kopieren Sie in das Konfigurationsverzeichnis des OpenVPN-Servers

Anschließend erstellen Sie die Konfiguration "/etc/openvpn/server/server.conf" für den OpenVPN-Server mit folgendem Inhalt:

Diese Konfiguration legt den Port, das Protokoll und den Modus als Router (dev tun = Tunneling Device) fest.

verweist auf die zu verwendenden Schlüssel. Gesetzt den Fall, Sie müssten ein Zertifikat widerrufen, würden Sie hier zudem den Verweis auf die Certificate Revocation List einfügen:

Tunnel bauen Anschließend legen Sie die Parameter des Tunnels fest. Mit

bestimmen Sie das IP-Netzwerk des Tunnels. Es folgen

Mit den push-Anweisungen überträgt der VPN-Server Kommandos für das IP-Setup an den Client. Mit "redirect-gateway def1" beispielsweise weist der OpenVPN-Server seine Clients an, die Default-IPv4-Route auf den Tunnel zu legen und damit, den gesamten IP-Traffic des Clients über das VPN zu transferieren. Sollen Clients nur den Traffic für das Intranet des VPN-Servers (Beispiel 172.27.0.0/16) in den Tunnel packen, würde die push- An weisung stattdessen "route 172.27.0.0 255.255.0.0" lauten.

Das push-Kommando mit der DHCP-Option "DNS" ändert den zu verwendenden DNS-Server des Clients. Das ist zum einen für Intranets mit eigenem Nameserver wichtig. Zum andern sind die DNS-Servers eines lokalen Netzwerkes (Beispiel offenes WLAN) nur innerhalb des Netzwerks erreichbar und funktionieren daher nicht mehr, wenn der Client seine DNS-Anfragen über den Tunnel versendet. Daher muss hier ein DNS-Server stehen, auf den der VPN-Server zugreifen kann.

Leider funktioniert genau diese wichtige Option bei diversen Clientsetups und Betriebssystemen nicht richtig. Wer einen Client mit einer statischen DNS-Konfiguration (statt DHCP) betreibt, setzt das Kommando nicht um.

Zudem kommt es speziell auf MacOS-Clients immer wieder zu Problemen, da das Betriebssystem dem Nutzer oft nicht gestattet, die globale DNS-Einstellung zu ändern. Hier helfen oft nur Clientskripte, die das "up"-Kommando in der VPN-Client-Konfigurationsdatei starten - zur Not eben mit erhöhten Systemprivilegien. Linux-Clients, die den "NetworkManager" als Dienst verwenden, haben in der Regel keine Probleme.

Die "keepalive"-Direktive prüft regelmäßig, ob die Verbindung zum Client noch besteht. Sollte die Verbindung abbrechen, muss sie der Client neu initiieren. Die "persist"-Anweisungen verhindern dabei, dass der Server das betreffende "tun"-Device (Netzwerktunnel) abschaltet und den aktuellen Transferschlüssel verwirft. Das beschleunigt den Reconnect:

Optional kann der Anwender die Log- Verbosity (Ausführlichkeit) des VPN-Servers konfigurieren und eine eigene Logdatei für den OpenVPN-Dienst erstellen:

Weitere Konfigurationsanweisungen bra ucht der VPN-Server erst einmal nicht und lässt sich dann via

aktivieren und starten.

Der Service heißt übrigens aus dem Grund "…@server.service", weil der Name nach dem "@" auf die Konfigurationsdatei verweist. Somit könnten Anwender bei Bedarf mehrere VPN-Services mit ver - schie denen Konfigurationen parallel auf einem Server laufen lassen. Ein "open vpnserver@second.service" würde seine Konfiguration aus der Da tei "/etc/openvpn/ server/second.conf " beziehen.

Erhalten Sie beim ersten Start die Fehlermeldung, dass der OpenVPN-Server die "server.conf "-Datei oder eines der Zertifikate nicht lesen kann, hat wahrscheinlich SELinux ein Problem mit dem Security Context der Dateien. Abhilfe schafft dann

VPN-Client einrichten

Ein VPN-Client benötigt zunächst sein Zertifikat, den dazu passenden Schlüssel und eine Kopie des CA-Zertifikats. Linux- Clients verwalten die VPN-Konfiguration ganz simpel über das GUI-Tool NetworkManager. Hier muss der Anwender lediglich den Servernamen beziehungsweise die IP-Adresse, den Port und das Protokoll angeben und dem Tool mitteilen, wo die Zertifikate und Schlüssel zu finden sind.

Bild 3: Mit einigen wenigen Angaben ist die VPN-Konfiguration auf dem Client dank NetworkManager erledigt.


Manche OpenVPN-Clients, wie der auf Windows oder Android, bringen aber keine hübsche GUI für die Client-Konfiguration mit. Hier bereiten Sie eine fertige "ovpn"-Konfigurationsdatei mit allen Parametern vor, übertragen sie auf das jeweilige Zielsystem und starten den OpenVPN-Client.

Das verwendete ovpn-Dateiformat stimmt dabei weitgehend mit dem conf-Format des Servers überein. Um die Zertifikate und Schlüssel nicht als separate Dateien einspielen zu müssen, erlaubt das ovpn- Dateiformat, diese Informationen inline einzubinden.

Dazu müssen Sie aus den drei Dateien "ca.crt", "client01.crt" und "client01.key" sämtliche Informationen in den Abschnitten "-----BEGIN CERTIFICATE- ----" und "-----END CERTIFICATE---- -" beziehungsweise "-----BEGIN PRIVATE KEY-----" und "-----END PRIVATE KEY-----" mit einem Texteditor kopieren und dann zusammen mit den Konfigurationsoptionen in eine ovpn- Datei sichern.

Das sieht dann in etwa so aus:

Link-Codes

[1] OpenVPN k3z51

Nun genügt es, den freien OpenVPN-Client auf Windows, Mac, Android oder anderen unterstützten Systemen zu installieren und diesem die ovpn-Datei mitzugeben.

Erweiterte Konfiguration

Die hier gezeigte Konfiguration genügt bereits für ein sicheres VPN, aber natürlich lässt sich das Setup verbessern. Dazu zählt vor allem die TLS-Autorisierung, die zwar den Tunnel selbst nicht sicherer macht, aber den VPN-Server besser vor Unbefugten schützt. Sie erstellen dazu einen symmetrischen Schlüssel, den "ta.key", der auf dem Server und allen VPN-Clients vorhanden sein muss.

Bei aktivierter "TLS-Auth" signiert der OpenVPN-Client alle IPPakete an den VPN-Server mit dem TA-Schlüssel. Der Server reagiert dann nur noch auf signierte Pakete. Das schützt den VPN-Server beispielsweise vor DDoS-Attacken oder Portscans. Das Kommando

erstellt einen solchen Key. Der Server bindet ihn dann via

in die Konfiguration ein. Die "0" steht dabei für "incoming", der Server hört nur noch auf signierte Pakete, signiert selber aber nicht. In der Clientkonfiguration steht dann entsprechend:

wobei die "1" den Client anweist, ausgehende Pakete zu signieren. Wie zuvor bei den Zertifikaten integrieren Sie den TA-Key ebenfalls direkt in das ovpn-File mit "BEGIN/END OpenVPN Static key V1".

Um derweil einen Webserver zusammen mit dem OpenVPNServer auf Port 443 laufen zu lassen, genügt eine Server-Anweisung in der "/etc/openvpn/server/server.conf

OpenVPN leitet dann allen eingehenden Nicht-VPN-Traffic auf Port 4343 um. Dementsprechend müssen Sie dann den Webserver konfigurieren, sodass dieser auf Port 4343 auf eingehenden HTTPS-Verkehr lauscht.

Fazit

VPN-Zugänge insbesondere für mobile Mitarbeiter sind aus dem Unternehmensalltag nicht mehr wegzudenken. So schützen VPNs den Internetverkehr von Endgeräten auch in unsicheren Netzwerken wie etwa öffentlichen WLANs. Open VPN erlaubt es Administratoren, mit relativ wenigen und einfachen Schritten einen gesicherten Zugang zu Netzwerken sowie Clouddiensten einzurichten. OpenSSL als technische Basis des VPNs verspricht eine langlebige und zukunftssichere Lösung. (dr)


Quelle: grafxart - 123RF