Wer eine VPN-Anbindung zu einem Cisco-Einwahlrouter benötigt, kommt mit der Client-Software des Herstellers am einfachsten zum Ziel. Wir stellen diese Freeswan-Alternative vor.
IPsec-fähige Produkte von Cisco sind heute in vielen Firmen und Unis anzutreffen. Die zentrale Hardwarekomponente der VPN3000-Serie (siehe Abbildung 2) agiert als Verschlüsselungs- und Authentifizierungsgateway für Linux-, Windows- (Abbildung 1) sowie Macintosh-Clients.
Die Clients sind in Software implementiert[1], aktuell ist Revision 4.0. Vielfach sind auch 3.6.3 und 3.7 im Einsatz. Wesentliche Unterschiede sind den Autoren nicht bekannt, die Konfigurationsdateien lassen sich weiterverwenden. Versionen vor 3.6.1 sind wegen einiger Sicherheitsprobleme nicht zu empfehlen.
Proprietäres Kernelmodul
Der Cisco-Client muss unter Linux für den aktuellen Kernel kompiliert werden. Das klingt nach freier Software, ist es aber nicht: Es handelt sich nur um einen Wrapper, der den mitgelieferten Object-Code in den Kernel lädt. In der Datei »interceptor.c« lassen sich einige Anpassungen vornehmen, besonders für das Sperren von Devices nach dem Start des Clients ist das wichtig.
Um das Modul übersetzen zu können, müssen die passenden Kernelquellen installiert sein. Anschließend entpackt der Admin das Tar-Archiv des Clients, dabei entsteht das »vpnclient«-Verzeichnis. Der Befehl »./vpn_install«, aufgerufen im neuen Directory, startet das Übersetzen und Installieren des Moduls.
Zielverzeichnis wählen
Ein Dialog fordert den Admin auf, das Zielverzeichnis für die vier Programme »vpnclient«, »cisco_cert_mgr«, »cvpnd« und »ipseclog« anzugeben und die Autostartoption festzulegen (für das Laden des Kernelmoduls »cisco_ipsec«). Der Dialog fragt auch nach dem Verzeichnis der Kernelquellen. Üblicherweise lassen sich die vorgeschlagenen Einstellungen direkt übernehmen.
Am Ende des Installationsvorgangs ist es dringend zu empfehlen, die Zugriffsrechte für das Verzeichnis »/etc/CiscoSystemsVPNClient« restriktiver zu setzen. Hier liegen nicht nur die Konfigurationsdateien, sondern eventuell die Zertifikate für eine andere Authentifizierung als Username und Passwort. Die Profildateien können Gruppen und deren Passwörter sowie den Benutzernamen und das eigene Passwort enthalten.
Verbindung starten
Der Befehl »/etc/init.d/vpnclient_init start« initialisiert den VPN-Client und lädt das Kernelmodul. Die verschlüsselte Verbindung wird mit dem interaktiven Kommandozeilentool »vpnclient connect VPN-Profil« initiiert. Das VPN-Profil verweist auf eines der Benutzungsprofile, die im Cisco-Konfigurationsverzeichnis unter »Profile/« abgelegte sind.
Sind dort die Credentials zur Authentifizierung (Benutzername und Passwort) eingetragen, kann die Verbindung auch automatisch im Hintergrund aufgebaut werden, beispielsweise nach der DSL-Einwahl im Skript »ip-up.local«. Die typische Profildatei »/etc/CiscoSystemsVPNClient/Profile/ VPN-Profil.pcf« ist in Listing 1 zu sehen.
Profil zeigen
Bei der »Host«-Option muss die Adresse des Cisco-VPN-Servers eingetragen sein. Mit »GroupName« und »GroupPwd« lassen sich mehrere Benutzerkreise unterscheiden, die auf ein Verschlüsselungsgateway zugreifen dürfen. Hinter »Username« steht der eigene Benutzername. Wer will, kann auch die Option »UserPassword« einfügen und sein Passwort im Klartext ablegen. Nach der ersten Verbindung löscht der Cisco-Client dieses Passwort und ersetzt es durch einen verschlüsselten Text, das Gruppenpasswort verbirgt er ebenso.
Die Konfigurationsdatei »vpnclient.ini« legt für alle Profile den Umfang der Log-Informationen fest und bestimmt die Lage der ausführbaren Programme.
Damit sich der Cisco-VPN-Client auf einem Rechner hinter einer Firewall betreiben lässt, muss diese alle für die IPsec-Verbindung erforderlichen Pakete durchlassen. Dazu zählen das Transportprotokoll ESP mit der Protokollnummer 50 und UDP-Pakete auf Port 500. Wird IPsec/UDP verwendet (NAT-Traversal), ist der entsprechende UDP-Port (per Default 10000) freizuschalten.
Listing 1: Ausschnitt einer Profildatei |
01 [main] 02 Description=VPN zu einem Cisco IPsec-Gateway 03 Host=ipsec-gw.meinedomain.org 04 AuthType=1 05 GroupName=Gruppenname 06 GroupPwd=Gruppenpasswort 07 EnableISPConnect=0 08 ISPConnectType=0 09 ISPConnect= 10 ISPCommand= 11 Username=Benutzername 12 UserPassword=RAS-Passwort 13 SaveUserPassword=0 14 EnableBackup=0 15 BackupServer= 16 EnableNat=0 17 CertStore=0 18 CertName= 19 CertPath= 20 CertSubjectName= 21 CertSerialHash=00000000000000000000000000000000 22 DHGroup=2 23 ForceKeepAlives=0 |
Listing 2: Cisco-Client öffnen |
01 *** ../test/vpnclient/interceptor.c 2002-10-22 05:47:21.000000000 +0200
02 --- interceptor.c 2003-03-04 13:39:42.000000000 +0100
03 *************** static int handle_vpnup()
04 *** 315,320 ****
05 --- 315,332 ----
06 if (strcmp(LINUX_VPN_IFNAME, dp->name) == 0) {
07 continue;
08 }
09 +
10 + if ((strcmp("eth1", dp->name) == 0) ||
11 + (strcmp("eth2", dp->name) == 0) ||
12 + (strcmp("ppp0", dp->name) == 0) ||
13 + (strcmp("ppp1", dp->name) == 0) ||
14 + (strcmp("ipsec0", dp->name) == 0) ||
15 + (strcmp("ipsec1", dp->name) == 0) ||
16 + (strcmp("ipsec2", dp->name) == 0)) {
17 + continue;
18 + }
19 +
20 +
21 if (strcmp("lo", dp->name) == 0) {
22 /*bind to loopback so we can inject UDP packets
23 *for IPC, but don't change the xmit function
24 *************** static int recv_ip_packet_handler(struct
25 *** 509,514 ****
26 --- 521,540 ----
27 struct ethhdr ppp_dummy_buf;
28
29
30 +
31 + if ((strcmp("eth1", dev->name) == 0) ||
32 + (strcmp("eth2", dev->name) == 0) ||
33 + (strcmp("ppp0", dev->name) == 0) ||
34 + (strcmp("ppp1", dev->name) == 0) ||
35 + (strcmp("ipsec0", dev->name) == 0) ||
36 + (strcmp("ipsec1", dev->name) == 0) ||
37 + (strcmp("ipsec2", dev->name) == 0))
38 + {
39 + rc2 = original_ip_handler.orig_handler_func(skb, dev, type);
40 + goto exit_gracefully;
41 + }
42 +
43 +
44 if (strcmp("lo", dev->name) == 0) {
45 /* grab the routing entry for loopback packets, in case we need
46 * to send some later*/
|
Linux-Tools erkennen Ciscos Interfaces nicht
Leider ist in den Augen der Autoren die Implementation des Cisco-IPsec nicht besonders schön, die IPsec-Interfaces und die entsprechenden Routing-Einträge lassen sich zum Beispiel nicht mit den üblichen Linux-Tools (»ifconfig«, »netstat«) entdecken. »ip addr« zeigt zwar die von der Cisco-Software eingerichtete Netzwerkschnittstelle:
6: cipsec0:
mtu 1400 qdisc noop qlen 100
link/ether 00:00:00:00:00:00
brd ff:ff:ff:ff:ff:ff
Allerdings ist keine IP-Konfiguration mit ihr verknüpft. Erst »vpnclient stat« zeigt die Adresse, zusammen mit Angaben zur Verschlüsselung und anderen Daten zu den IPsec-Verbindungen.
Ein weiteres Problem ist die Darstellung der Pakete in Ethereal. Die Abbildungen 3 und 4 zeigen, dass der Sniffer in einer Übertragungsrichtung zwar wie erwartet den verschlüsselten Paketstrom liest, in der anderen Richtung liegen die Pakete aber im Klartext vor. Für den Test diente ein einfaches Ping als Datenquelle: »ping -p 0048414C4C4F00 134.76.60.21« ergibt ein Muster von »HALLO«-Texten, das im Datenstrom sofort auffällt.
Die tatsächlich auf dem Netz gesendeten Pakete sind für Dritte jedoch nicht einsehbar, lediglich der lokal gestartete Sniffer sieht die Klartextpakete. Die Ursache ist vermutlich, dass sich das Kernelmodul sehr tief im Protokollstack einklinkt, um bei Bedarf den Datenverkehr über weitere Interfaces zu unterbinden.
Zentrale Steuerung
Ein Vorteil und gleichzeitig ein Nachteil des Cisco-Clients ist seine zentrale Steuerung. Die Benutzer dürfen die in »vpnclient.ini« getroffene Einstellungen nicht überschreiben. Das Verbot eines LAN-Zugriffs und damit implizit das Aufsetzen eines Masquerading-Routers kann sogar zentral vom Verschlüsselungsgateway durchgesetzt werden, je nachdem, wie der zuständige Administrator die Policies einstellt.
Durch das Sperren weiterer Interfaces will der Admin den Zugriff aufs lokale Netz sperren, während der Client in das VPN eingebunden ist. Damit erreicht er eine höhere Sicherheit für das VPN, er verhindert versehentlich offene Hintertüren. Jedoch kann der Benutzer dann zum Beispiel keinen lokalen Netzwerkdrucker mehr verwenden, wenn der Verschlüsselungstunnel aktiv ist. Das mag zwar für spezielle Roadwarrior-Einsätze nicht von Bedeutung sein, es kann aber in anderen Szenarien für enormen Overhead sorgen, wenn der Client alle Daten ausnahmslos über das Gateway leitet. Im Extremfall verdoppelt sich der IP-Traffic im eigenen Netz.
Abbildung 1: Cisco bietet seinen IPsec-Client neben Linux auch für Windows (im Bild: Windows XP) und für Apples Mac OS X an. Diese Versionen administriert der Benutzer per GUI.
Falsch gesperrt
Ein weiteres Problem ergibt sich durch die möglichen Benennungen von Interfaces: Einige Distributionen bezeichnen Funkkarten mit »wlan0«, diese Namen sind dem Client aber nicht bekannt. Damit kann er keine verschlüsselte Verbindung über diese Interfaces durchführen. Abhilfe für beide Probleme schafft ein Blick in den Code. Ob die in Listing 2 vorgeschlagenen Änderungen mit der Cisco-Lizenz vereinbar sind, muss der Anwender jeweils für sich klären.
Die Änderungen in »interceptor.c« ergänzen die Interfaces, die neben dem Cisco-IPsec-Interface noch benutzbar sein sollen. »eth0« ist in diesem Beispiel ausgespart, weil darüber die Verbindung mit dem Cisco-VPN-Client läuft.
Client-Werkzeuge
Das »vpnclient«-Kommando ist das wichtigste Tool der Cisco-VPN-Lösung. Ohne Parameter aufgerufen teilt es dem Benutzer alle Kommandozeilenparameter mit; auch das Linux-typische »–help« funktioniert. Die drei Hauptoptionen sind »vpnclient connect«, »vpnclient disconnect« und »vpnclient stat«. Bei »vpnclient connect« ist zwingend als nächste Option ein Profil anzugeben, das sich als Datei unter »/etc/CiscoSystemsVPNClient/Profiles« befindet. Im Folgenden lautet dieses File »goemobile«.
Wer beim Start nicht nach seinem Benutzernamen und Passwort gefragt werden möchte, sollte nach dem Profil noch seinen Usernamen übergeben. Er kann dem Client zusätzlich auch noch das Passwort mitteilen – das ist aber nicht zu empfehlen, da jeder andere Benutzer auf der Maschine das Passwort leicht ausspionieren kann. Ein einfaches »ps axw | grep vpnclient« genügt, um die geheimen Informationen zu sehen:
2004 pts/1 S 0:00 /usr/local/bin/ vpnclient connect goemobile user awiezer@gwdg pwd Klartext-Passwort
Normalerweise darf der Benutzer seinen Namen und das Passwort in der Profildatei speichern; der Admin kann dies aber Server-seitig unterbinden. Wie sinnvoll das ist, sei dahingestellt – durch das Interceptor-Patch kann jeder Client diese Einschränkung umgehen.
Abbildung 2: Der Cisco-IPsec-Einwahlrouter VPN3000 nimmt die VPN-Verbindung der Software-Clients entgegen. Je nach Ausbaustufe kann er Tausende von Clients gleichzeitig bedienen.
Sicher verbunden
Das Kommando »vpnclient connect Profil user Benutzername« führt zu der Ausgabe in Listing 3. Das Client-Interface erhält die öffentliche Adresse »134 .76.n.n« (Zeile 12), während die Gateway-Adresse wie die Adresse der Funk-LAN-Karte eine private ist (»10.100.0.1«, Zeile 7). Der Cisco-Client führt in diesem Beispiel also Direct-NAT durch.
In Zeile 18 ist außerdem zu sehen, dass »Local LAN« ausgeschaltet wurde. Das geschah allerdings nicht anhand der Profildatei, sondern von Seiten des Administrators der Cisco3000. Diese Einschränkung lässt sich – wie bereits oben gezeigt – durch Anpassen der »interceptor.c« umgehen.
Befindet man sich in einem Netz hinter einer Firewall und kann das VPN-Gateway den Rechner nicht direkt erreichen, kommt NAT-Passthrough (auch NAT-Traversal genannt) ins Spiel. Das Ergebnis sieht wie folgt aus:
IPSec tunnel information. Client address: 134.76.n.n Server address: 134.76.n.n Encryption: 168-bit 3-DES Authentication: HMAC-MD5 IP Compression: None NAT passthrough is active on port UDP 10000 Local LAN Access is enabled
Die »vpnclient disconnect«-Funktion ist schnell erklärt: Sie beendet eine bestehende Verbindung. Einen Überblick über den Zustand (Staus) der Verbindung erhält man mit »vpnclient stat«. Die Ausgabe ist in Listing 4 zu sehen.
Neben dem »vpnclient«-Werkzeug gibt es noch ein interessantes Programm zum Schreiben von Logfiles. Dessen Verwendung ist zwar ungewöhnlich, aber das Prinzip funktioniert – üblicherweise ist unter Unix-Systemen jedoch der »syslogd« für das Logging zuständig.
Listing 3: Start des Clients |
01 Cisco Systems VPN Client Version 3.7 (Rel) 02 Copyright (C) 1998-2002 Cisco Systems, Inc. All Rights Reserved. 03 Client Type(s): Linux 04 Running on: Linux 2.4.19 #8 Sat Nov 9 12:20:38 PST 2002 i586 05 06 Initializing the IPSec link. 07 Contacting the gateway at 10.100.0.1 08 Authenticating user. 09 Your link is secure. 10 11 IPSec tunnel information. 12 Client address: 134.76.n.n 13 Server address: 10.100.n.n 14 Encryption: 168-bit 3-DES 15 Authentication: HMAC-MD5 16 IP Compression: None 17 NAT passthrough is inactive 18 Local LAN Access is disabled |
Listing 4: VPN-Status |
01 IPSec tunnel information. 02 Connection Entry: goemobile 03 Client address: 134.76.n.n 04 Server address: 10.100.n.n 05 Encryption: 168-bit 3-DES 06 Authentication: HMAC-MD5 07 IP Compression: None 08 NAT passthrough is inactive 09 Local LAN Access is enabled 10 11 VPN traffic summary. 12 Time connected: 0 day(s), 00:09.31 13 Bytes in: 84443 14 Bytes out: 115760 15 Packets encrypted: 816 16 Packets decrypted: 671 17 Packets bypassed: 19 18 Packets discarded: 7 19 20 Configured routes. 21 Secured Network Destination Netmask Bytes 22 * 10.100.n.n 255.255.255.255 0 23 * 0.0.0.0 0.0.0.0 157753 24 25 Local Network Destination Netmask 26 10.100.n.n 255.255.0.0 |
Logfiles
Wenn der Admin ein Logfile des Cisco-Clients wünscht, muss er zunächst festlegen, was und wie viel der Client protokollieren soll. Die Einstellungen hierzu nimmt er in der Datei »/etc/CiscoSystemsVPNClient/vpnclient.ini« vor. Die Variable »EnableLog« muss auf den Wert »1« gesetzt sein. Die einzelnen Optionen sind weitgehend selbsterklärend, ein hoher »level« bedeutet ausführliche Mitteilungen des Clients.
Das Schreiben des Logfile startet der Admin mit »ipseclog Logfile &« – das Programm geht nicht automatisch in den Hintergrund. Das Cisco-Format ist zwar eigenartig, nach etwas Eingewöhnung erfüllt es aber seinen Zweck. Wer den Client mit Zertifikaten einsetzen will, kommt am Zertifikat-Manager »cisco _cert_mgr« kaum vorbei. Auf[2] ist dieses komplexe Tool dokumentiert.
Der Cisco-VPN-Router kommt zurzeit häufig in Funk-LANs zum Einsatz, die ja um einiges besser gegen Mitlesen des Datenverkehrs abgesichert werden müssen als drahtgebundene Installationen. Die Sicherungssysteme der üblichen Funk-LANs sind nicht besonders ernst zu nehmen. Diese Lücke lässt sich sehr gut mit IPsec schließen.
Abbildung 3: Ausgehende Pakete verlassen die Maschine scheinbar im Klartext: Ethereal zeigt (unterer Fensterbereich) die »HALLO«-Strings an, die der Absender in den ICMP-Nachrichten eingebettet hat.
Häufige Aufgabe: Funk-LAN absichern
Typischerweise installiert die Firma oder Universität ein offenes privates Netz, über das die Teilnehmer nach dynamischer IP-Zuweisung per DHCP einen Verschlüsselungstunnel über den Cisco-Router aufbauen und erst so in das restliche Netz kommen. Die Maschine bildet den einzigen Übergang und übernimmt neben den Authentifizierungs- auch die Routing-Aufgaben.
Kommunizieren die einzelnen Clients kaum untereinander, dann ist dieses Setup sehr ökonomisch: Es existiert eine einheitliche Software für unterschiedliche Clients, die recht bequem zu benutzen ist. Die Lizenzgebühren sind mit der Anschaffung der Hardware (etwa 16000 Euro) abgedeckt, die Clients können in beliebiger Zahl benutzt werden. Ein ähnliches Szenario ergibt sich durch die Anbindung von Außendienstmitarbeitern über das unsichere Internet: Sie können auf diese Weise direkt in das jeweilige Netzwerk ihrer Abteilung oder Firma transparent eingebunden werden, sie erhalten eine interne Adresse.
Kommen Zertifikate statt der User-basierten Authentifizierung zum Einsatz, arbeitet der Cisco-VPN-Server auch mit Freeswan auf dem Client-System zusammen. Inwieweit sich der höhere Einrichtungsaufwand lohnt, muss jeder für sich entscheiden. Oft ist der Einsatz der Cisco-Software die einfachere Wahl.
Abbildung 4: Die Antwortpakete zeigt Ethereal korrekt in ihrem verschlüsselten Zustand an, eingebettet in UDP-Pakete auf Port 10000 (wegen NAT-Traversal).
Fazit
Der Cisco-VPN-Client nutzt zwar dieselbe Technologie wie Freeswan, die Unterschiede sind jedoch so groß, dass beide nicht interoperabel sind. Sie trennen sich bereits im Authentifizierungsansatz: Freeswan arbeitet mit Host-basierten Schlüsseln, unabhängig vom User. Der Cisco-Client arbeitet mit User-basierten Credentials, die unabhängig von der darunter liegenden Hardware funktionieren.
Im klassischen Roadwarrior-Einsatz spielt dieser Unterschied keine wesentliche Rolle, da auf jeder Maschine nur ein Benutzer arbeitet. Der Cisco-Client eignet sich nur für Roadwarrior-Szenarien oder Rechner im lokalen Netz, die kaum Daten miteinander austauschen, da der gesamte Verkehr jeweils über das Cisco-IPsec-Gateway abgewickelt wird.
Die Konzeption dieser Cisco-Software sieht keine Verschlüsselungstunnel für ganze Netze einzelner Betriebsteile vor. Für diese Aufgabe bietet der Hersteller spezielle Hardware; Linux-Anwender können stattdessen auf GPL-lizenzierte VPN-Software wie Cipe, OpenVPN oder Freeswan zurückgreifen.
Mit anderen Kernel-basierten VPN-Lösungen wie Cipe oder Freeswan hat der Cisco-Client das Problem gemeinsam, dass bei einem Kernelupdate das Modul neu gebaut werden muss. Die bereits stark modifizierten Distributionskernel können auch komplett die Zusammenarbeit mit dem Modul verweigern. Dann hilft oft nur Probieren, um eine geeignete Version zu finden.
Am Ende bleibt die Frage nach der Sicherheit der Cisco-VPN-Lösung. Der entscheidende Code liegt im Binärformat vor und entzieht sich somit einer unabhängigen Beurteilung. Ein weiteres Problem zeigt sich bei Öffnung des Interceptors: Mit ihm kann der Anwender die Vorgaben des VPN-Administrators aushebeln. Zudem verhält sich der Client mit seinen Interfaces aus Administratorensicht ärgerlich, da er seine Standardtools nicht in der gewohnten Weise einsetzen kann. (fjl)
Infos |
|
[1] Einstiegsseite zur VPN-Software: [http://www.cisco.com/en/US/products/sw/secursw/] [2] Zertifikat-Manager: [http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel3_7/cli3_7/certs.htm] |
Die Autoren |
|
Arnim Wiezer studierte Mikrobiologie in Göttingen und arbeitet jetzt im hiesigen Genomlabor an seiner Doktorarbeit über die Analyse mikrobieller Genomdaten mit bioinformatischen Methoden. Wenn er nicht in der Uni ist, guckt er am liebsten James-Bond-DVDs oder joggt durch Göttingen.
Dirk von Suchodoletz betreute einige Jahre lang das Wohnheimnetz des Studentenwerks Göttingen und baute an der dortigen Universität auch einen Linux-basierten Rechnerpool für die Studierenden auf. Gegenwärtig ist er Assistent am Lehrstuhl für Kommunikationssysteme an der Fakultät für Informatik der Universität Freiburg. |
