Foto: Charite

Individuelle Firewallregeln und Authentifizierungsmechanismen für jeden VPN-User sind mit OpenVPN kein Problem. Admins der renommierten Berliner Universitätsklinik Charité zeigen wie.

Barmherzigkeit (frz. Charité) ist es sicher nicht, die eine der größten Universitätskliniken Europas, die Charité [1] in Berlin, zu freier Software brachte. Wie in Unternehmen üblich, zählten harte Fakten, und in der Health-Care-Branche sind die Ansprüche an Sicherheit besonders hoch. Sichere Verschlüsselung ist da in vielen Fällen unabdingbar, und hier kommen so genannte virtuelle private Netze (VPNs) ins Spiel.

Das VPN der Charite umfasst über 3000 registrierte User, die ein Server mit Dual-Xeon-Prozessor (3,4 GHz, 2 GByte RAM) versorgt. Die Durchschnittslast dieser Maschine beträgt lediglich 0.02, obwohl meist 50 User angemeldet sind, von denen jeder rund 200 KByte pro Minute Datentraffic verursacht. Die klassischen Lösungen für diese Größenordnung verwenden IPsec und gelten als teuer, unhandlich und vor allem für die Firewall-Administration als sehr kompliziert zu verwalten.

Noch vor wenigen Jahren brauchte es für solche Anforderungen teuere Lösungen mit Geräten von Cisco und entsprechend geschulten und ausgebildeten Admins. Dank der freien VPN-Software OpenVPN [2] von James Yonan hat sich das aber nachhaltig geändert. Das Tool bietet einfache Konfiguration, hohe Sicherheit und flexible Scripting-Hooks.

Die mitgelieferte Sample-Konfiguration lässt sich fast beliebig erweitern. Zertifikate, Passwörter, spezielle Routingvorgaben, IP-Pools stehen ebenso zur Verfügung wie das automatische Zuweisen von Netzwerkeinstellungen via DHCP und Windows-spezifische Netzwerk-Funktionen.

OpenVPN: Skripte

Das Beste aber ist: OpenVPN ist skriptbar. Für jeden Benutzer, der sich mit dem Server verbindet, kann der Admin ein eigenes Programm spezifieren. So gibt er dem Client zum Beispiel bestimmte Rechte, setzt Routen und verbietet oder erlaubt über Firewalls wie IPtables den Zugriff auf interne Server. Mit Hilfe solcher Skripte erstellt der Admin ein komplettes, indivuelles Firewallkonzept für das VPN, auch das Masquerading der Tunnel-IPs ist da kein Problem.

Per-User-Authentifizierung

In der Charité bestand zudem die Anforderung, für die externen Benutzer unterschiedliche Authentifizierungsquellen zu nutzen: LDAP, Kerberos, ADS, Passwort- und eine IMAP-gestützte Authentisierung galt es für die VPN-Benutzer umzusetzen. Weil OpenVPN auch auf die Pluggable Authentication Modules zurückgreifen kann, bietet sich dafür PAM-per-User [3] an. Dieses PAM-Modul delegiert die Authentisierung einfach an andere Module, basierend auf der Datei »/etc/pam_per_user.map«.

Zunächst konfiguriert der Admin OpenVPN so, dass es PAM-per-User verwendet. Die Datei »/etc/pam.d/openvpn« sollte dazu so aussehen:

auth       required     pam_per_user.so.1
account    required     pam_permit.so

In »/etc/pam_per_user.map« trägt er dann die für die Benutzer gewünschten PAM-Module ein:

user1 : openvpn-ldap
user2 : openvpn-krb5
user3 : openvpn-imap

In diesem Beispiel authentifiziert sich »user1» gegen ein LDAP-Verzeichnis, weil PAM die Konfiguration der Datei »/etc/pam.d/openvpn-ldap« heranzieht:

auth       required     pam_env.so
auth       required     pam_ldap.so
account    required     pam_ldap.so

Der »user2« dagegen soll Kerberos verwenden, in »/etc/pam.d/openvpn-krb5« steht deshalb der Verweis auf die Kerberos-Bibliothek »pam_krb5.so«. Die eigentliche, bisweilen komplexe Kerberos-Konfiguration erfolgt via »/etc/krb5.conf«.

auth    requisite pam_krb5.so no_ ccache
account required  pam_permit.so

User3 soll sich über seine IMAP-Identität ausweisen. Daher findet sich in »/etc/pam.d/openvpn-imap«:

auth       required     pam_imap.so conf=/etc/pam.d/pam_imap.conf 
account    required     pam_imap.so conf=U/etc/pam.d/pam_imap.conf

Die Datei »/etc/pam.d/pam_imap.conf« spezifiziert, gegen welchen IMAP-Server PAM die übergebenen Username-Passwort-Kombination prüft:

PAM_PasswordString = Password:CertificateFile /usr/share/ssl/certs/imapd.pem 
PAM_Server0 = imapserver.example.com:143
PAM_BlockList = root, admin, Administrator,apache 
PAM_HashEnable = no
PAM_HashFile = /etc/pam_imap.gdbm
PAM_HashDelta = 20

Damit stehen auch Autentifizierungen gegen proprietäre Mechanismen zur Verfügung, solange es nur einen IMAP-Server im LAN gibt, der diese versteht.

Damit alle User sich wie beschrieben anmelden können, bestimmt der Admin als letzten Schritt in der OpenVPN-Konfiguration das PAM-Plugin. In »/etc/openvpn/server.conf« gibt der Parameter »openvpn« in der Zeile »plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn« an, dass OpenVPN die PAM-Konfigurationsdatei »/etc/pam.d/openvpn« nutzen soll. Auf Clientseite muss in der Konfiguration »auth-user-pass« eingetragen sein, damit der OpenVPN-Client den Benutzer nach Usernamen und Passwort fragt.

Abbildung 1: OpenVPN-graph zeigt den Ein- und Ausgangs-Traffic auf dem VPN-Server detailliert in Tages-, Wochen- oder Monats-Statistiken. .

Individuelle Zertifikate

In der Charité erhält jeder Benutzer immer die gleiche statische IP-Adresse für seinen Tunnel-Endpunkt. Dies realisiert in OpenVPN die Option »client-config-dir«:

server 172.48.0.0 255.255.0.0
client-config-dir ccd

Basierend auf dem CN des durch den Client präsentierten X.509-Zertifikates nimmt OpenVPN die Datei: »/etc/openvpn/ccd/CN« für die individuelle Konfiguration des Clients her:

/etc/openvpn/ccd/# cat user1.charite.de
ifconfig-push 172.48.44.41 172.48.44.42
push "redirect-gateway"

Hier weist der Server dem Client mit dem CN »user1.charite.de« die statische IP Adresse 172.48.44.41 zu. Außerdem übermittelt er die Option »redirect-gateway« an den Client, sodass dessen gesamter Netzwerktraffic ab sofort durch den Tunnel geht. Auch explizite Routen darf der Admin hier setzen und an den Client weitergeben:

ifconfig-push 172.48.44.41 172.48.44.42
push "route 10.10.0.0 255.0.0.0"
push "route 192.168.1.0 255.255.0.0"

Dieses Vorgehen empfiehlt sich auch bei UMTS-Karten am Client, mit denen sich die Defaultroute unter Windows sonst nicht ändern lässt.

Routen-Maximum

Allerdings sollte der Server nicht zuviele Routen an den Client übermitteln, der Push-Buffer hat nämlich nur eine maximale Länge von 1024 Byte.

Findet ein Admin im Logfile von OpenVPN Einträge wie folgende, dann hat er dieses Limit überschritten für den genannten User (hier »user1.charite.de«):

Oct 18 16:43:53 ovpn-server[28631]: user1.charite.de/IP.add.res.se:33359 Maximum length of --push buffer (1024) has been exceeded. 

Wie lässt es sich aber verhindern, dass jemand ein fremdes X.509-Zertifikat nutzt? Ein böswilliger Client könnte das Zertifikat »username1.charite.de« präsentieren, aber zur Authentisierung die Daten von »user2« nutzen.

Der OpenVPN-Server muss also bei der Authentisierung prüfen, ob der CN des Zertifikats mit dem Benutzernamen der Authentifizierungsdaten übereinstimmt, und das übernimmt der Parameter »auth-user-pass-verify« in »/etc/openvpn/server.conf«:

auth-user-pass-verify /usr/local/scripts/ucn.pl via-env 

An dieses Perl-Skript gibt OpenVPN über Environment-Variablen Username und CN des Zertifikates. Eine Übergabe via Datei ist ebenfalls möglich. Das entsprechende Skript in Listing 1 ist eher unspektakulär: beim »split()« verbleibt im »common_name_array« als erstes Element der Username, der ja identisch zu dem in der Umgebungsvariable »username« übergebenen sein muss.

01 #!/usr/bin/perl -t
02 # OpenVPN --auth-user-pass-verify script.
03 # Only authenticate if username equals Ucommon_name.
04 # In OpenVPN config file: auth-user-pass-verify ./ucn.pl via-env
05 $username = $ENV{'username'};
06 $common_name = $ENV{'common_name'};
07 @common_name_array = split(/./, $common_Uname);
08 exit !(length($username) > 0 && Ulength($common_name) > 0 && $username eq U$common_name_array[0]);

Individuelle Firewall-Regeln für jeden Benutzer

Weil jeder User über sein Zertifikat seine eigene statische IP erhält, lassen sich beim Verbindungsaufbau für jeden Client spezifische Firewallregeln applizieren. Auch dafür bringt OpenVPN bereits die Mittel mit. In der »server.conf« geschieht dies über die »learn-address«-Option:

learn-address /usr/local/scripts/ovpnfwconf

OpenVPN ruft dieses Skript mit bis zu drei Parametern auf:

• »Operation«: »add«,
  »delete« oder »update«. »add«
  kommt bei der Zuweisung einer IP zum Einsatz, zum Beispiel wenn der
  User sich einwählt und eine initiale Adresse erhält. In
  der Charite setzt jetzt ein individuelles Skript sofort die
  Firewallregeln. Wenn der User die Verbindung trennt, greift
  »delete«: OpenVPN verwirft die Client-Adresse, ein
  Skript löscht die Firewallregeln. Bei einem Reconnect des
  Clients übergibt OpenVPN »update«, es funktioniert
  ähnlich wie »delete« mit einem folgenden
  »add«.
• »Adresse«: Die IP-Adresse im VPN, also jene Adresse
  die OpenVPN mittels »client-config-dir ccd« statisch
  vergeben hat.
• »Common Name«: Der CN des X.509-Zertifikates.

Das an der Charite verwendete Skript »/usr/local/scripts/ovpnfwconf« ist dabei nur ein Wrapper, der das tatsächliche Skript mit Root-Privilegien aufruft, da IPtables diese benötigt:

#!/bin/sh
/usr/local/bin/bin-id-wrapper /usr/local/scripts/ovpncfg.pl $1 $2 $3 2>&1 | logger -t ovpnfwconf -p daemon.info 

Die eigentliche Arbeit verrichtet »/usr/local/scripts/ovpncfg.pl«, es erzeugt die IPtables-Regeln.

IPtables-Regeln generieren

Das Skript kann beliebig komplex sein, Listing 2 skizziert grob, was beim Anlegen der Regeln passiert, wobei »$IP« die statisch zugewiesene IP des VPN-Clients ist.

01 # Eine eigene Tabelle für den User anlegen
02 iptables -N chain-$IP
03 # In der Forward-Table ist diese das Sprungziel für die Source-IP des Users:
04 iptables -I FORWARD -s $IP -j chain-$IP
05 #ESTABLISHED-Connections einfach ohne weiteres Matching durchlassen:
06 iptables -A chain-$IP -s $IP -m state --state RELATED,ESTABLISHED -j ACCEPT
07 # Nun folgen individuelle Regeln für den Benutzer, beispielsweise den Zugriff auf den Zielrechner $destHost, Port $destPort und das Protokoll $destProto:
10 iptables -A chain-$IP -p $destProto -s $IP -d $destHost --dport $destPort -j ACCEPT
11 # Oder dasselbe mit mehreren Ports mit --dports:
12 iptables -A chain-$IP -m multiport -p $destProto -s $IP -d $destHost --dports $destPort -j ACCEPT
14 # Vollzugriff auf einen Host:
15 iptables -A chain-$IP -s $IP -d $destHost -j ACCEPT
16 # Abschließend den ICMP-Traffic erlauben:
17 iptables -A chain-$IP -p icmp -s $IP -j ACCEPT
18 # und alles weitere verbieten:
19 iptables -A chain-$IP -s $IP -j DROP

Nach der Übergabe der Delete-Operation erfolgt das Löschen der Regeln und der Flush der Tabellen mit Kommandos wie:

iptables -D FORWARD -s $IP -j chain-$IP
iptables -F chain-$IP
iptables -X chain-$IP

Um etwa abschätzen zu können, wie viel Traffic ein User mit seiner Applikation über den VPN-Tunnel schickt, protokolliert OpenVPN beim Verbindungsaufbau die Anzahl der gesendeten und empfangenen Bytes, wenn der Admin noch die folgende Zeile in der Konfigurationsdatei einträgt:

client-disconnect /usrIlocal/scripts/ovpntraffic 

Das hier von OpenVPN bei der Trennung vom Client aufgerufene Disconnect-Skript »ovpntraffic«:

#!/bin/sh
echo $common_name: bytes_sent: $bytes_received bytes_received: $bytes_sent | logger -t ovpncfg.pl -p daemon.info 

protokolliert lediglich die Inhalte der OpenVPN-Umgebungsvariablen »$common_name«, »$bytes_received« und »$bytes_sent« an den Syslog-Daemon.

cryptoapicert "THUMB:0b 58 43 44 3d 45 xx bb e5 55 22 xx 2b 2f 26 ba 56 89 7c 36" 

Traffic Control und Management-Interface

Auf Basis von Mailgraph [4] von David Schweikert haben die Admins der Charite OpenVPNgraph [5] geschrieben, das mittels RRDtool Betriebsdaten wie die Anzahl der gleichzeitig aktiven User, die Menge der gesendeten und empfangenen Daten protokolliert und grafisch darstellt (Abbildung 1). Im Uniklinikum zeigen sich so über die Woche durchschnittlich 45 bis 50 Benutzer simlutan mit einem Datendurchsatz von 15 bis 20 KByte proMinute (vom Client zum Server) und 145 bis 160 KByte proMinute vom Server zum Client. Die verwendeten Bandbreiten sind also sehr niedrig.

OpenVPN bringt auch ein eigenes Management-Interface zur Steuerung und Überwachung mit, das sich auch mit Telnet ansprechen lässt. In der Konfigurationsdatei aktiviert es der Eintrag:

management 127.0.0.1 7505

für lokale Zugriffe auf dem Port 7505. Interessierte Admins greifen mit »telnet localhost 7505« darauf zu und erhalten in der folgenden Shell mit dem Befehl »help« umfangreiche Hilfe.

Als Client für diese Schnittstelle existiert das in Perl geschriebene OpenVPNcontrol [6], das in Tabellenform Source IP, Username, VPN-IP, Datentransfermenge und Loginzeit anzeigt.

Besonders praktisch erweist sich der »Force Logoff«-Knopf, mit dem der Admin ausgewählte Clients vom VPN trennt. Mehr Details zu den umfangreichen Funktionen des Management-Interfaces finden Interessierte in der Online-Dokumentation auf der Projektwebseite [7].

Enterprise-Ready

OpenVPN hat sich im Einsatz in großen Unternehmen und Organisationen bewährt. Wer das nicht glaubt, findet im Kasten “OpenVPN e.V.: Peine und Notare” oder Artikeln des Linux-Magazins [9] und der Linux Technical Review [10] weitere Beispiele.

Dass das freie VPN-Tool einen derart großen Funktionsumfang mit einer simplen Konfiguration bei gleichzeitig hoher Sicherheit kombiniert, scheint wie die Quadratur des Kreises.