© Veronika Vasilyuk, 123RF.com

Einfache VPNs reichen Datenschützern oft nicht, sie verlangen die Kombination von Besitz und Wissen als Zugangsberechtigung fürs Unternehmensnetz. Damit dies wie von Geisterhand läuft, bedarf es aber keiner Zauberei, sondern einer geschickten Mischung aus Open VPN und Aladdins E-Tokens.

“Aladin war ein Tunichtgut”, heißt es in “Tausendundeine Nacht”. Er sei “halsstarrig, boshaft und ungehorsam” gewesen, “ein Gassenjunge”, erzählt Scheherazade [1]. Wer würde so einem Bengel die Sicherheit seines Unternehmens anvertrauen? Ohne die bekannte Wendung mit dem Zauberer und dem Geist aus der Wunderlampe, die letztendlich den Jungen zum Sultan macht, hätte der Marktführer bei USB-Kryptosticks sicherlich einen anderen Namen gewählt.

Open VPN und Aladdin

Dabei ist Magie gar nicht nötig, um Aladdins E-Tokens mit Linux und Open VPN zum Laufen zu bekommen. Das freie SSL-VPN ist spätestens seit Version 2.1 kein Exot mehr, sondern taugt auch für Large-Scale-Setups [2]. Trotzdem ist das Anbinden einer USB-Stick-Authentifizierung mit Passwortmanagement und PIN-Eingabe nicht ganz trivial.

Dieser Artikel zeigt, wie ein Unternehmen eine größere Infrastruktur konfiguriert und absichert, wobei er auch die Anbindung der Windows- und Linux-Clients beschreibt. Oben drauf gibt’s individuelle Client-Konfigurationen fürs VPN und ein passendes Startskript für die PIN-Eingabe unter Linux.

Das englische Wort “Token” steht für Beweis, Merkmal, Zeichen und unter dem Namen E-Token für die kryptographischen Zugangsberechtigungen auf USB-Basis der Firma Aladdin [3], deren Sticks den Markt dominieren. So ein E-Token gibt es ab etwa 80 Euro, es ist prinzipiell ein USB-Device, das ein Benutzerzertifikat enthält.

Tokens und Zertifikate

Selbstverständlich findet die Einwahl ins VPN nicht mehr mit einem einfachen PSK (Pre-Shared Key) statt, sondern über sichere, automatisch verfallende und zentral verwaltbare X.509-Zertifikate [4]. Open VPN lässt sich auch mit einfacheren, öffentlichen Zertifikaten betreiben, wie das etwa Strato mit seinem Hidrive-Netzlaufwerk macht [5]. Dafür muss aber das Zertifikat als »clientAuth«-Zertifikat erstellt sein, sonst lässt Open VPN einen Tunnelaufbau nicht zu. Besser fürs Unternehmen sind individuelle Client-Zertifikate und -Schlüssel.

Auch die brauchen Schutz, und dafür sorgt Aladdin mit seiner Soft- und Hardware. Das E-Token lässt sich nur mittels eines Passworts auslesen und erfüllt so die Vorgabe “Besitz und Wissen” der Datenschützer. Zusätzlich verfügt das E-Token über eine eingebaute Intelligenz, die zum Beispiel bei zu häufiger falscher Eingabe des Passworts das Token sperrt.So ist sichergestellt, dass selbst beim Verlust oder Diebstahl des Device ein unbefugter Dritter ohne das Passwort keine Verbindung aufbauen kann. Das Auslesen des gespeicherten Zertifikats erfolgt nach dem PKCS#11-Standard [6].

Schritt für Schritt

Auf einem Ubuntu-Server installiert der Admin zuerst das Paket »openvpn«, das als Abhängigkeiten die Pakete »liblzo2-2«, »libpkcs11-helper1«, »openssl-blacklist« und »openvpn-blacklist« nach sich zieht. Gleich im nächsten Schritt geht’s ans Anlegen der eigenen Public Key Infrastructure (PKI). Für kleine und mittlere Setups liefert Open VPN gleich Software in Form von Easy-RSA mit, die auch fürs Testen absolut ausreicht. Admins größerer PKIs verwenden Tools wie Open CA [7] oder gar externe Dienstleister.

Egal welches Tool zum Einsatz kommt: Nach dem Erstellen der Zertifikate sollte die PKI umziehen, am besten auf ein internes Inselsystem ohne jede Netzanbindung. Bei einem Verlust der PKI (vor allem der Schlüsseldatei »CA.key«) ist die gesamte Unternehmens-IT in Gefahr, deshalb sollte sie auf keinen Fall im Netz erreichbar sein.

Easy-RSA

Die mitgelieferten Easy-RSA-Skripte erledigen den PKI-Aufbau schnell und unkompliziert, sie finden sich im Verzeichnis »/usr/share/doc/openvpn/examples/easy-rsa/2.0«. Zunächst bedarf es dort einiger Änderungen in der Datei »vars«, die im Wesentlichen die weitere Arbeit komfortabler machen, siehe Listing 1. Wer dessen Zeilen editiert, braucht die Details später nicht mehr von Hand einzugeben, sondern kann sie einfach mit [Y] oder [Enter] durchwinken. Danach räumen ein paar Befehle auf, exportieren die soeben editierten Werte und erstellen einen DH-Schlüssel (Diffie-Hellman), der zum sicheren Austausch der Schlüssel (Key-Exchange) nötig ist:

01 # Schlüssellänge
02 export KEY_SIZE=1024
03 
04 # Gültigkeitsdauer der CA (in Tagen)
05 export CA_EXPIRE=3650
06 
07 # Gültigkeitsdauer der Zertifikate (in Tagen)
08 export KEY_EXPIRE=3650
09 
10 # Vordefinierte Zertifikatswerte
11 export KEY_COUNTRY="DE"
12 export KEY_PROVINCE="BY"
13 export KEY_CITY="Muenchen"
14 export KEY_ORG="Linux-Magazin"
15 export KEY_EMAIL="pki@linux-magazin.de"

./clean_all
./vars
./build-dh.sh

Nach einer Weile und ein paar Bildschirmen voller kryptischer Zeilen ist der DH-Schlüssel erstellt und »./build-ca« widmet sich der Erzeugung der eigenen CA. Das Skript führt den Admin durch den Prozess, wobei es die vordefinierten Werte der »vars«-Datei als Default anbietet. Lediglich den »Organizational Unit Name« und den »Common Name« muss der CA-Admin manuell vergeben.

Anschließend lässt sich ein Server-Zertifikat erstellen. Dafür bietet Easy-RSA das Skript »build-key-server«, das als Parameter den Zertifikatsnamen erwartet. Hier sind mehrere Punkte manuell einzugeben: Einerseits braucht es einen »Common Name«, am besten den FQDN des Servers. Ein »challenge password« sollte der Admin hier nicht vergeben, da das Signieren direkt im Anschluss erfolgt. Die beiden folgenden Fragen beantwortet er mit [Y]:

Sign the certificate [y/n]:
1 out of 1 certificate requests certified, 
commit? [y/n]:

Nun kann er noch beliebig viele Benutzerzertifikate ausstellen, auch dafür bietet Easy-RSA ein Skript, namens »build-key«. Er bestätigt die Vorschläge und ergänzt die Angaben zur Person.

Abschließend erzeugt er noch einen TLS-Key, der als Sicherung vor DoS-Angriffen zum Einsatz kommt. Dabei hilft der Befehl

openvpn --genkey --secret tls-auth.key

der den Schlüssel in der Datei »tls-auth.key« hinterlegt.

Was gehört wohin?

Das richtige Verteilen der erstellten Zertifikate sorgt immer wieder für Verwirrung. Abbildung 1 zeigt die korrekten Orte: Auf den Server gehören die Dateien »CA.crt«, »server.crt«, »server.key«, »tls-auth.key«, »dh.key« und »client.crt«, auf den Client (hier ein Laptop) ebenfalls die Dateien »CA.crt« und »tls-auth.key«, während das File »client.pem« auf dem E-Token landet. Der untere Bereich der Abbildung zeigt das Inselsystem des PKI-Managements, aus dem (ganz rechts) die Datei »client.pem« herausfällt.

Abbildung 1: Welches Zertifikat gehört auf welchen Server? Wer braucht welchen privaten Key? Die Grafik zeigt, wohin der Admin im beschriebenen VPN-Setup die einzelnen Dateien kopieren muss.

Abschließend müssen die neuen Benutzerzertifikate noch auf deren E-Tokens landen. Dafür vereint zunächst der Befehl

openssl pkcs12 -export -in Max_Mustermann.
crt -inkey Max_Mustermann.key  -out 
Max_Mustermann.p12

das Zertifikat-Schlüssel-Paar des Clients in einer PKCS#12-Datei, die der Admin mit dem Aladdin-PKI-Management-Tool [8] auf das E-Token überträgt.

Nach dem ersten Start dieser Software initialisiert ein Button in der »Advanced«-Ansicht das E-Token. Der Admin gibt hier ein Benutzer- und ein Administratorpasswort zum Entsperren des E-Token ein. Auch die Anzahl der falschen Versuche, die dem Benutzer bis zur Sperrung erlaubt sind, lässt sich hier definieren. Der Kasten “E-Token entsperren” erläutert die richtige Vorgehensweise zum Reanimieren eines E-Token in Aladdins Software (Abbildung 2).

Abbildung 2: Nicht nur für den Export, sondern auch zum Freischalten eines versehentlich vom Benutzer gesperrten E-Token dient das Management-Tool von Aladdin.

Import undExport

Über die Importfunktion versorgt der Admin das E-Token mit dem Zertifikat. Die anschließende Passwortabfrage erfordert bereits das eben vergebene Benutzerpasswort, gefolgt von einem weiteren Authentifizierungsdialog. Hat der Admin beim Anfertigen des Benutzerzertifikats ein »Challenge Password« vergeben, sollte er es an dieser Stelle eintippen, sonst lässt er das Feld einfach leer. Nun ist das E-Token einsatzbereit.

Open VPN – der Server

Admins großer Umgebungen betreiben Open VPN in der Regel in einer eigenen DMZ, was konzeptionell auch als beste Lösung erscheint, weil so jeder Zugriff über die zentralen Firewallsysteme läuft und steuerbar bleibt. Eine Voraussetzung dafür ist jedoch, dass jeder VPN-Benutzer eine statische IP-Adresse hat, für die auf den Firewallsystemen feste Regeln definiert sind. Schließlich soll eine externe Firma nicht die gleichen Rechte bekommen wie ein interner Mitarbeiter, der gerade zu Hause arbeitet.

Dafür bietet Open VPN seit Version 2.1 den Betrieb im Topology-Subnet-Modus an. Zusammen mit dem handlichen »ccd-exclusive«-Parameter ordnet dieser Zertifikat und Benutzer eine fixe IP zu und sperrt nicht-konfigurierte Benutzer aus. Der Admin erstellt auf dem Server eine Konfigurationsdatei mit der Erweiterung ».conf« unter »/etc/openvpn/« (Listing 2). Damit läuft Open VPN auf dem TCP-Port 443, benutzt fürs Tunneln ein TUN-Device und verwendet als Topologie »subnet«. Bei diesem Modus erhält der Open-VPN-Server die erste Adresse aus dem zugewiesenen Adressenbereich (hier die IP 192.168.1.1). Nach den Pfadangaben der Zertifikate und Keys folgt die »server«-Direktive mit dem IP-Bereich des virtuellen Netzes.

01 port 443
02 dev tun
03 proto tcp
04 topology subnet
05 
06 dh /etc/openvpn/keys/dh1024.pem
07 ca /etc/openvpn/keys/CA.crt
08 cert /etc/openvpn/keys/server.crt
09 key /etc/openvpn/keys/server.key
10 tls-auth /etc/openvpn/keys/tls-auth.key
11 
12 server 192.168.1.0 255.255.255.0
13 
14 keepalive 10 60
15 comp-lzo
16 
17 persist-key
18 persist-tun
19 client-config-dir /etc/openvpn/ccd
20 ccd-exclusive
21 status /var/log/openvpn/status.log
22 log-append /var/log/openvpn/openvpn.log
23 verb 5

Wichtig ist, das Routing auf den entsprechenden Firewallsystemen anzupassen und das private Netz über den Open-VPN-Server zu leiten. Anschließend legt der Keepalive-Parameter fest, dass Open VPN abgerissene Tunnel nach 60 Sekunden automatisch abbaut, und ermöglicht so eine Wiedereinwahl.

Die »comp-lzo«-Direktive aktiviert Kompression, was die Geschwindigkeit beim Arbeiten über den Tunnel gelegentlich deutlich erhöht. »persist-key« und »persist-tun« geben an, dass Open VPN den Tunnel und die Schlüsseldateien bei einem Tunnelneustart nicht neu einliest. Das ist unter anderem sinnvoll, wenn Open VPN seine Benutzerrechte beim Starten abgibt, da nur Root das Tun-Device anlegen und die Schlüsseldatei auslesen darf.

Über »client-config-dir« definiert der Admin den Speicherort der Benutzerkonfiguration (zum Beispiel mit der individuellen IP-Adressen-Zuteilung oder speziellen Routen). Die folgende Direktive »ccd-exclusive« veranlasst Open VPN nur Benutzer zuzulassen, für die auch eine Client-Config-Dir-Konfiguration vorliegt. »status«, »log« und »verb« konfigurieren Logdateien und Geschwätzigkeit.

Push-Konfigurationen

Die Server-seitige Konfiguration für den Benutzer Max Mustermann liegt zum Beispiel in der Datei »/etc/OpenVPN/ccd/Max_Mustermann« und kann wie in Listing 3 aussehen. Wichtig ist: Der Name der Datei muss mit der Subject Line des Client-Zertifikats übereinstimmen, hier ist also schon bei der Konzeption der PKI Weitsicht gefragt. Dem Client weist der Server schon bei der Einwahl die IP 192.168.1.3 zu, außerdem veranlasst »redirect-gateway« ihn dazu, sein Default-Gateway durch den VPN-Tunnel zu legen. Zusätzlich legt Open VPN via »dhcp-option« die DNS-, WINS- und Domain-Einstellungen an. Leider verstehen heute nur Windows-Clients die Direktive »dhcp-option«. Für Linux-Clients hilft das Skript »/etc/openvpn/update-resolv-conf«.

01 # Max Mustermann
02 ifconfig-push 192.168.1.3 255.255.255.0
03 push "topology subnet"
04 push "redirect-gateway"
05 push "dhcp-option DNS 192.168.10.1"
06 push "dhcp-option WINS 192.168.10.1"
07 push "dhcp-option DOMAIN linux-magazin.de"

Selbstverständlich könnte der Admin alle im Ccd-Verzeichnis aufgelisteten Konfigurationen auch auf der Client-Seite vornehmen. Das ist aber sicherheitstechnisch bedenklich, denn die Benutzer können die zugewiesene IP-Adresse ändern und so an höhere Rechte gelangen.

Abschließend sollte der VPN-Server die Weiterleitung von Paketen erlauben, was der Kernelparameter »ip_forward« via »sysctl -w net.ipv4.ip_forward=1« erledigt. Der Artikel [2] zeigt, wie sich an dieser Stelle eine simple, aber sichere Firewall mit individuellen Regeln per Client integrieren lässt.

Windows-Clients fit machen

Die Konfiguration von Open VPN unterscheidet sich bei Linux- und Windows-Clients deutlich. Die passende Windows-Software findet sich auf [9]. Die Autoren des Linux-Magazins empfehlen die Community-Software von Openvpn.net, da die Alternative von Openvpn.se über keinen MS-zertifizierten Treiber verfügt, was bei einigen Windows-Versionen zu Problemen führt. Neben der Open-VPN-Software braucht es noch den Aladdin-E-Token-PKI-Client, den es nach einer Anmeldung unter [8] gibt.

Nach der Installation beider Programme geht’s an die Konfiguration. Zuerst legt der Admin unter »C:Programmeopenvpn« eine Datei »client.conf« mit dem Inhalt wie in Listing 4 an. Achtung, die doppelten Backshlashes dort sind keine Druckfehler, sondern notwendig.

01 remote myopenvpn.exmaple.com 443
02 dev tun
03 proto tcp
04 client
05 tun-mtu 1500
06 ca "C:\programme\openvpn\keys\ca.crt"
07 tls-auth "C:\programme\openvpn\keys\tls-auth.crt"
08 cryptoapicert "THUMB:xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx"
09 
10 cipher BF-CBC
11 comp-lzo

Neben den Zertifikaten, die im Verzeichnis »C:Programmeopenvpnkeys« landen, ist der zentrale Konfigurationspunkt die Direktive »cryptoapicert«. Hier ersetzt der Admin die xx:xx…-Reihe durch den Fingerprint des Zertifikats. Windows-Betriebssysteme verfügen über einen so genannten Certificate Store, der alle temporären und permanenten Zertifikate speichert. Über ein API lässt sich dieser bei E-Tokens auch auslesen, zum Beispiel mit Hilfe der Microsoft Management Console. Nach dem Klick auf »Start | Ausführen« gibt der Admin »mmc« ins Befehlsfenster ein und erhält die Microsoft Management Console, der er das Zertifikats-Snap-in hinzufügt (Abbildung 3).

Abbildung 3: Die Microsoft Management Console mit dem Zertifikats-Snap-in.

Im letzten Schritt wählt er, ob die MMC den Certificate-Store des aktuellen Benutzers, des Dienstkontos oder des Computerkontos öffnen soll. Falls mehr als ein Benutzer auf dem System existiert, sollte der Admin das Computerkonto verwenden, ansonsten das Konto des aktuellen Benutzers.

Nun öffnet der Admin den Crypto-Store und liest unter »Eigene Zertifikate« das eingesteckte Token aus. Über einen Doppelklick auf das Zertifikat erscheint die Übersicht aller Optionen. Jetzt den Fingerprint markieren, kopieren und der »client.conf« hinzufügen. Bevor er die MMC schließt, fügt er noch das CA-Zertifikat »ca.crt« dem Crypto-Store unter »Vertrauenswürdige Stammzertifizierungsstellen« hinzu, damit das E-Token als vertrauenswürdig gilt.

Wer nun das Open-VPN-GUI startet und über einen Rechtsklick auf das Symbol in der Startleiste die Verbindung herstellt, wird vom Aladdin-E-Token-PKI-Client nach dem Passwort des Token gefragt. Kurz nach der korrekten Eingabe steht dann der Tunnel.

Ganz anders: Linux-Clients

Auf Linux-Clients installiert der Admin die Pakete »openvpn«, »pcscd« und den Aladdin-E-Token-PKI-Client von [8]. Danach legt er unter »/etc/openvpn/« eine Datei »client.conf« analog zu Listing 5 an. Die Zertifikate landen unter »/etc/openvpn/keys«. Weil die Linux-Clients die Server-seitige Option »dhcp-option« nicht verstehen, bedarf es des Skripts »update-resolv-conf«, das Open VPN mitliefert. Es übersetzt die Angaben in Linux-konforme Befehle und führt sie beim Auf- und Abbau des Tunnels aus.

01 remote myopenvpn.exmaple.com 443
02 dev tun
03 proto tcp
04 client
05 tun-mtu 1500
06 ca /etc/openvpn/keys/ca.crt
07 tls-auth /etc/openvpn/keys/tls-auth.key
08 
09 up /etc/openvpn/update-resolv-conf
10 down /etc/openvpn/update-resolv-conf
11 
12 pkcs11-providers /usr/lib/libeTPkcs11.so
13 pkcs11-id 'Aladdinx20Knowledgex20Systemsx20Ltdxxx/eToken/0000xxxx/eTokenxxxxxxxxxxxx/xxxx'
14 
15 management 127.0.0.1 4711
16 management-query-passwords
17 
18 cipher BF-CBC
19 comp-lzo
20 verb 3

Die Direktive »pkcs-11-providers« nennt den Speicherort der Aladdin-Library zum Auslesen des E-Token, »pkcs11-id« legt (ähnlich wie der Fingerprint der Windows-Konfiguration) fest, welches E-Token auf dem System zum Einsatz kommt. Den an dieser Stelle einzutragenden String erfährt der Admin bei eingestecktem Stick über den Befehl »openvpn –show-pkcs11-ids /usr/lib/libeTPkcs11.so« (Listing 6). Der Fingerabdruck steht hier im Feld »Serialized id«.

01 The following objects are available for use.
02 Each object shown below may be used as parameter to
03 --pkcs11-id option please remember to use single quote mark.
04 
05 Certificate
06  DN:             /C=DE/ST=BY/L=Muenchen/O=Linux Magazin/OU=TR/CN=Max_Mustermann/emailAddress=mm@exmaple.com
07  Serial:         03
08  Serialized id:  Aladdinx20Knowledgex20Systemsx20Ltdx2E/eToken/xxxxxxxx/eToken/xxxxxxxxxxxxxxxxxx

Mit Telnet aufs Open-VPN-Management-Interface

Da Linux-Systeme über keinen Crypto-Store verfügen, müssen sie die Passwortprüfung des E-Token auf anderem Wege ermöglichen. Dazu helfen die beiden Zeilen »management« und »management-query-password«.

Wer jetzt Open VPN als Root auf der Konsole zum Beispiel mit »openvpn -config /etc/openvpn/client.conf« startet, erhält eine Ausgabe der durchgeführten Schritte. Normalerweise bleibt das Programm dann mit der folgenden Meldung stehen:

openvpn --config /etc/openvpn/client.conf
[...]
Sun Aug 15 15:07:56 2010 Need password(s)
 from management interface, waiting...

Open VPN wartet auf eine Telnet-Verbindung auf dem Localhost über den Port 4711, wo das Managementinterface von Open VPN den Benutzer mit folgender Meldung begrüßt:

telnet 127.0.0.1 4711
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
>INFO:OpenVPN Management Interface Version 
1 -- type 'help' for more info
>

Das Open-VPN-Management-Interface verlangt das Passwort in einer bestimmten Syntax. In der Telnet-Session reicht folgender Befehl:

password 'eToken Max_Mustermann' Geheim

Wobei Geheim das Passwort des E-Token ist. Bei richtiger Eingabe baut Open VPN jetzt den Tunnel auf.

Handliches Einwahlskript

Selbstverständlich ist dies keine zumutbare Vorgehensweise für Endbenutzer. Daher haben die Autoren des Linux-Magazins ein Bash-Skript namens Etovpn geschrieben. Es liegt mittlerweile in der Testversion 0.3 vor, DELUG-Abonnenten finden es auf der DVD, auch paketiert für Debian, Suse oder als Tarball. Zum Download steht es unter [10].

Das Skript baut den VPN-Tunnel im Hintergrund auf und fragt den Benutzer nach dem Passwort. Das übergibt es dann selbstständig übers (lokale) Telnet an Open VPN. Konfigurieren kann es der Admin in der Datei »/etc/etovpn.conf«.

Zeitsteuerung

Mit Hilfe der Client-Config-Directories ist auch eine simple Zeitsteuerung möglich: Mit aktivierter »ccd-exclusive«-Direktive lässt sich die Einwahl eines Nutzers einfach über einen »mv«-Befehl steuern, der die Konfigurationsdatei aus dem Ccd herausschiebt.

Ein Cronjob kann das automatisiert abwickeln – und schon dürfen sich externe Mitarbeiter oder Dienstleister nur noch in bestimmten Zeitfenstern einwählen. Vorsicht ist dabei geboten: Bestehende Tunnel sind von dieser Einschränkung nicht betroffen, die muss der Admin eigens übers Management-Interface auf dem Server killen. (mfe)