erschienen in LinuxEnterprise 5/2002, Software & Support Verlag, Frankfurt a.M.
Es gibt eine ganze Reihe von freien VPN-Projekten unter Linux. FreeS/WAN ist von ihnen das mit Sicherheit erfolgreichste. Das kommt nicht von ungefähr: FreeS/WAN wird sehr aktiv weiter entwickelt und hält sich eng an den von der IETF definierten IPSec-Standard. Deshalb arbeitet es auch problemlos mit vielen kommerziellen Produkten zusammen. Der professionellen Standortvernetzung oder der sicheren Anbindung mobiler Benutzer steht also nichts im Wege.
Durch die Nähe zum komplexen IPSec-Standard ist leider auch die FreeS/WAN [1]-Konfiguration recht anspruchsvoll und erfordert einige Erfahrung. Ein derart hoher Aufwand ist aber je nach Anforderungen, Netzwerkumgebung und den individuellen Sicherheitsanforderungen nicht immer gerechtfertigt. Für diesen Fall gibt es eine Reihe von freien Alternativen. Die einfachste und schnellste Lösung ist das "Tunneln" von Verbindungen mit Hilfe von OpenSSH[2]. Dabei ist man dank PuTTY [3] nicht unbedingt auf Linux als Client angewiesen. Dieser Aufbau eignet sich nur für wenige, zeitlich begrenzte Verbindungen. Im Gegensatz dazu ist CIPE eine "echte" VPN-Software, die die Standortvernetzung und Anbindung mobiler Benutzer ermöglicht. Sie basiert auf einem vom CIPE-Entwickler Olaf Titz entworfenen Protokoll, das nicht zum IPSec-Standard kompatibel ist. Genau wie CIPE ist auch VPND [4] eine "One-Man-Show". VPND arbeitet als reines Point-to-Point-System, wobei für jede Client-Verbindung ein eigener Port und ein eigener Server-Prozess nötig sind. Die Weiterentwicklung dieses Projekts scheint zum Erliegen gekommen, -eine Version für den Kernel 2.4.X gibt es bisher nicht. Nicht unerwähnt bleiben soll stunnel [5],das auf OpenSSL basiert und genau wie FreeS/WAN mit Zertifikaten umgehen kann. Diese Software eignet sich insbesondere zum Tunneln von Protokollen wie POP, IMAP und LDAP. Die Microsoft- Betriebssysteme besitzen von Hause aus die Fähigkeit, mittels PPTP-Protokoll als VPN-Server oder -Client zuarbeiten. Linux steht dem in nichts nach[6] [7]. Dieser Artikel geht aber wegen der zahlreichen bekannt gewordenen Sicherheitsschwächen des PPTP- Protokolls darauf nicht näher ein.
Das gewichtigste Argument für den Einsatz von FreeS/WAN in Unternehmen ist ohne Zweifel seine Fähigkeit zur Interoperabilität. Auf der IPSec 2001 Conference[8] in Paris wurde demonstriert, wie die freie VPN-Software mit Cisco IOS, PIX, VPN 3000, Nortel Contivity VPN Switch und anderen zusammenarbeitet[9]. Natürlich funktioniert dies auch mit Checkpoints Firewall-1, Windows 2000 Professional und Advanced Server. Für die Clients kann man zwischen den Produkten der Marktführer SSH Sentinel, PGPNet und anderen wählen. Viele der bei kleinen und mittelständischen Unternehmen so beliebten Appliances wie BenHur oder die Astaro Firewall verwenden ohnehin FreeS/WAN für die VPN- Funktionalität.
Hinsichtlich der gebotenen Sicherheit ist FreeS/WAN auf dem aktuellen Stand der Verschlüsselungs- und Authentifizierungstechnik. Es werden 3DES und Diffie-Hellman Group2 (1024-bit) oder Group 5 (1536-bit) eingesetzt. Schwache Verschlüsselung wie DES und Diffie-Hellman mit 768-Bit gibt es bei FreeS/WAN nicht. Für die nahe Zukunft ist die Integration des neuen Verschlüsselungsstandards AES mit seinem Rijndael-Algorithmus geplant. Das FreeS/WAN-Team konzentriert sich nach eigenen Aussagen derzeit auf die Integration von Secure DNS und die Weiterentwicklung der "Opportunistischen Verschlüsselung". Die Entwickler um den Projektleiter John Gilmore bemühen sich darum, dieses Verfahren in den IPSec-Standard einzubringen. Durch Opportunistische Verschlüsselung werden die für die gesicherte Verbindung notwendigen Informationen mit Hilfe von DNS übermittelt. Im Ergebnis können FreeS/WAN-Gateways ohne den Austausch von Schlüsseln oder Public Key Infrastructure (PKI) eine VPN-Verbindung aufbauen.
Die Aussagen der Anwender zum kritischen Faktor Performance sind als beinahe euphorisch zu bezeichnen. Danach wurde auf einer FTP- Verbindung von Host-zu-Host in einem 100MBit-Netz ein Durchsatz von ca. 5 MBit/s erreicht. Den gewollten Flaschenhals in dieser Verbindung bildete ein Pentium P60. In der Beratungspraxis hat sich gezeigt, dass ein Pentium III/1GHz unter FreeS/WAN an einer ausgelasteten 2MBit-Standleitung ohne Probleme weitere Dienste übernehmen kann, ohne jemals an seine Leistungsgrenzen zu stoßen.
Die bereits in den ersten Folgen dieser Artikelserie beschriebenen X.509-Zertifikate sind nur über den kleinen Umweg eines -sehr gut funktionierenden- Patch möglich. Mit seiner Hilfe arbeitet FreeS/WAN fortan auch mit Trust Chains sowie Certificate Revocation Lists (CRLs). Die X.509-Implementierung hält sich eng an die Vorgaben der IETF und FreeS/WAN sollte mit jeder X.509- fähigen Software von anderen Anbietern zusammenarbeiten.
Neben den vielen, für FreeS/WAN sprechenden technischen Argumenten gibt es eine Reihe weiterer Vorteile. Da sind das sehr aktive, achtköpfige Projektteam und seine vielen Helfer. Die qualitativ und quantitativ hervorragende Dokumentation hilft bei der Lösung von Problemen. Rat und Hilfe gibt es zudem in den gut besuchten Mailinglisten.
Seinen besten Platz findet das Gateway in einer demilitarisierten Zone (DMZ). Dazu wird die Firewall mit einer dritten Netzwerkkarte ausgerüstet, an der auch weitere externe Dienste wie ein Webserver betrieben werden können. Zusätzliche Sicherheit bietet idealerweise ein vorgeschalteter Router miteinem eigenem Paketfilter. Eine Sparlösung ist der Betrieb des VPN-Gateways unmittelbar auf der Firewall. Die Konfiguration wird so zwar einfacher,der zusätzliche VPN-Dienst auf der Firewall bietet aber auch eine zusätzliche Angriffsfläche. Nicht nur das Bundesamt für Sicherheit in der Informationstechnik BSI rät deshalb von derartigen Topologien ab. Der schlechteste Platz für das VPN-Gateway liegt jedoch hinter der Firewall. Ein "stateful packetfilter" wie netfilter/iptables analysiert den Inhalt der Datenpakete, um den Zustand einer Verbindung bewerten zu können. Diese Möglichkeit wird ihm durch die Verschlüsselung der Pakete vollkommen genommen. Er kann nicht einmal mehr erkennen, an welchen Host die Pakete eigentlich adressiert sind. Auch der vorsorglich auf dem Mailrelay platzierte Virenscanner untersucht den Paketinhaltnach bekannten Signaturen und verliert bei verschlüsselten Nutzdaten natürlich jede Wirkung. Weitere Probleme bei einer Platzierung hinter der Firewall bereiten auch NAT und Masquerading. Durch diese Verfahren werden die IP-Adressen im TCP- Paket überschrieben. Benutzt das VPN-Gateway das Protokoll Authentication-Header(AH), stimmt die dem Paket hinzugefügte Prüfsumme nicht mehr und das betroffene Paket wird vom VPN-Gateway verworfen. Weitere Informationen zum Thema VPN-Masquerading finden sich im VPN-Masquerading-HOWTO[10].
Besondere Aufmerksamkeit verdienen mobile VPN-Clients. Kommerzielle IPSec-Clients wie SSH Sentinel oder SafenetSoftRemote verfügen zwar über eigene Paketfilter. Trotzdem sollte nneben der sicheren VPN-Verbindung keine weiteren Verbindungen ins Internet erlaubt sein. Viren, Würmern und Trojanern würden Tür und Tor ins Unternehmensnetz geöffnet. Die vom Benutzer gewünschte Transparenz kommt leider auch den Schädlingen zugute. Wenn die mobilen Anwender unbedingt einen Zugang zum Web benötigen, kann dieser über das VPN und den firmeneigenen Proxy eingerichtet werden. In welchem Umfang man den "Road Warriors" neben dem Zugriff auf die persönliche Email und andere, weniger sensible Daten auch noch Zugang zur zentralen Firmendatenbank ermöglicht, ist weitere gründliche Überlegungen wert
FreeS/WAN ist nicht offizieller Bestandteil des Linux-Kernels und muss zusätzlich installiert werden. Die bekannten Distributionen liefern FreeS/WAN in der Regel als Kernelmodul in einem RPM-Paketverpackt mit. Bei SuSE Linux 7.3 ist dies die bereits gepatchte Version 1.91. In jedem Fall sollte man einen Blick auf dieVersionsnummer werfen. Denn leider ist die aktuelle Version 1.94 vollkommen missraten und sollte mit Erscheinen dieses Artikel schon ersetzt worden sein. Bis dahin tut es die Version 1.91 oder der Developer-Snapshot snap2001dec25b. Für Testzwecke ist dies sicher ausreichend. Für den Einsatz in Produktionsumgebungen empfiehlt sich derzeit der Kernel 2.2.20, den auch die Entwicklereinsetzen. Kernel älter als die Version 2.2.19 sollten nicht mehr verwendet werden. Natürlich funktioniert FreeS/WAN auch mit dem"neuen" Kernel 2.4.X. Nostalgiker können sogar noch den Kernel 2.0.39 benutzen.
Um mit der Installation beginnen zu können, müssen neben den Entwicklerwerkzeugen wie gcc oder egcs, make, patch auch die Kernel-Sourcen installiert sein.Für die Verschlüsselungsalgorithmen benötigt FreeS/WAN außerdem die arithmetische GNU GMP-Library, die Bestandteil der meisten Distributionen ist. Ist sienicht installiert, schlägt die Kompilierung später mit einer Fehlermeldung fehl, weil die Header- Datei gmp.h nicht gefunden werden kann. Für die menügesteuerte Kernel-Konfiguration wird zusätzlich die ncurses-Library gebraucht. Der Wunsch nach X.509- oder OpenPGP-Zertifikaten macht den X.509-Patch [11]Version 0.97 und das fswcert-Werkzeug erforderlich. Nach dem Entpacken muss die Patch-Datei freeswan.diff in das FreeS/WAN-Quellverzeichnis kopiert und mit
patch -p1 < freeswan.diff
gepatcht werden. Die eigentliche Installation machen die FreeS/WAN-Entwickler dem gestressten Administrator sehr leicht, indem sie weitgehend durch den make-Befehl automatisiert wurde. Nachdem das tar-Archiv im Verzeichnis /usr/src/ entpackt ist, patcht ein einfaches
make menugo
die Linux-Kernel-Sourcen und ruft die menügesteuerte Kernelkonfiguration auf. Im Menü "Networking Options" findet sich nun die zusätzliche Auswahl "IP Security Protokoll", die FreeS/WAN fest in den Kernel integriert oder wahlweise als Modulübersetzt. Weitere notwendige Optionen wie FreeS/WAN Debugging sind bereits aktiviert und sollten auch nicht verändert werden. Wird die abschließende Frage nach der Speicherung der Konfiguration bejaht, schließt sich unmittelbar die automatische Kompilierung des neuen Kernels an. Ist auch dieser Schritt abgeschlossen, bleibt nur die Übersetzung der Module und die Installation des neuen Kernels, was sich mit make kinstall abkürzen lässt. Der Nachteil dieses recht praktischen Verfahrens ist, dass der Kernel in das Wurzel-Verzeichnis und nicht wie beivielen Distributionen mittlerweile üblich nach /boot kopiert wird. Damit der Bootloader lilo trotzdem den neuen Kernel lädt, wird der Pfad in /etc/lilo.conf entsprechend angepasst und lilo ausgeführt. Beim anschließenden Neustart sollte der neue Kernel geladen werden und eine Meldung über den Start von FreeS/WAN bzw. IPSec erscheinen. Auch für die Installation der Bootskripten sowie das für die spätere Konfiguration notwendige RSA-Schlüsselpaar in /etc/ipsec.secrets hat make menugo bereits gesorgt. Ein
insmod ipsec
oder
ipsec --version
bringt letzte Gewissheit über den Erfolg der Installation oder eine Fehlermeldung...
IPSec ist ein komplexes Protokoll, was sich auch in der Konfiguration widerspiegelt. Für die bereits in der Februar-Ausgabe von LinuxEnterprise beschriebenen Protokolle AH und ESP ist KLIPS (Kernel IPSec) verantwortlich. Das Bootskript startet den IKE-Daemon Pluto, der neben anderen Aufgaben auch die gesicherte Übertragung der SAs (Security Associations) übernimmt. Beim Booten sollte nach erfolgreicher Installation eine entsprechende Meldung angezeigt werden. Voraussetzung für eine IPSec-Verbindung ist in jedem Fall eine funktionierende IP- Verbindung. Die internen Netze zweier Standorte verwenden in derRegel private IP-Adressen nach RFC 1918, die jedoch unterschiedliche Adressbereiche belegen müssen. Auf beiden Gateways wird das IP-Forwarding aktiviert. Nicht nur die IP- Verbindung der Gateways, sondern auch das Routing zwischen den beiden Subnetzen muss einwandfrei funktionieren, bevor mit der eigentlichen IPSec-Konfiguration begonnen werden kann. Für den späteren Verbindungsaufbau müssen sich die Kommunikationspartner gegenseitig durch das RSA-Verfahren authentifizieren. Dazu dient ein bereits während der Installation erzeugtes Schlüsselpaar, das in der Datei /etc/ipsec.secrets gespeichert wurde. Der öffentlicheTeil der Schlüssel muss der Gegenstelle zugänglich gemacht und kann mit
ipsec showhostkey > vpn_public.key
extrahiert werden. Die sicherste Methode ist die persönliche Übergabe. Aber auch der Versand per Email oder Schneckenpost ist möglich. In beiden Fällen muss durch eine digitale Signatur mit PGP oder GnuPG der Absender identifiziert und die Integrität des Schlüssels zweifellos bestätigt werden können. Das manuelle Verfahren ist in der ersten Konfigurationsphase sicher ausreichend. Der vollständige Prozess des Schlüsselaustauschs wird für den Produktionsbetrieb natürlich automatisiert. Diese Aufgabeübernimmt der Pluto-Daemon, der auch für einen periodischen Wechsel der Schlüssel in frei definierbaren Zeitabständen sorgt und so die Sicherheit zusätzlich erhöht.
Mobile VPN-Anwender wählen sich dagegen häufig mit einer dynamisch zugewiesenen und somit nicht vorhersagbaren Adresse über das VPN- Gateway in das Unternehmensnetzwerk ein und verfügen auch über kein Subnet. Für jeden mobilen Anwender ist auf dem VPN-Gatewayein eigener Eintrag in der Konfigurationsdatei /etc/ipsec.conferforderlich, der dies berücksichtigt. Dies klingt in den Ohren vieler Administratoren nach fehlerträchtiger Fleißarbeit, wird in der Praxis aber durch die Default-Sektion erleichtert, die alle gemeinsamen Verbindungsparameter vordefiniert. Für beide Einsatzszenarien finden sich im Installationsverzeichnis doc/examples eine ganze Reihe von anschaulichen Beispielkonfigurationen, die sich leicht an die eigenen Bedürfnisse anpassen lassen. Sehr hilfreich sind auch die Hinweisein der Dokumentation für den Test des VPNs und die Fehlersuche.
Das gepatchte FreeS/WAN überprüft X.509-Zertifikate durch Abfrage einer zentralen Zertifizierungsinstanz (CA), die sich auch über mehrere Hierarchie-Ebenenerstrecken kann. Für die Nutzung von X.509-Zertifikaten im unternehmenseigenen Netzwerk ist man nicht unbedingt auf die Dienste eines kommerziellen Trustcenters angewiesen. Sie lassen sich mit OpenSSL[12] einfach selbst erzeugen.
# rpm -qv openssl
openssl-0.9.6a
Voraussetzung ist das Vorhandensein einer Root-CA, die mit
# cd
# mkdir certs
# cd certs
# sh /usr/share/ssl/misc/CA -newca
erzeugt wird. Unter anderem fragt das Shellskript nach dem CommonName (CN), der ein Alias für den Host sein kann und nach einem Passwort. Das Root-Zertifikat ``nach Hausmacherart'' hat eine Gültigkeit von einem Jahr und befindet sich in der Datei DemoCA/cacert.pem. Damit es FreeS/WAN auch benutzen kann, muss es nur noch in das Verzeichnis /etc/ipsec.d/cacerts/ kopiert werden. Auf dem Root-Zertifikat beruhen die Host-Zertifikate für die Gateways, deren Erstellung sich vereinfachen lässt. Dazu wird in der Datei /usr/share/ssl/openssl.cnf im Abschnitt [user_cert] der Parameter
subject AltName=DNS:your.fully.qualified.dom
hinzugefügt. ``your.fully.qualified.dom'' bezeichnet den vollständigen Hostnamen (FQDN). Dieser Name wird später in der FreeS/WAN-Konfiguration als ID benutzt. Der Befehl
# sh /usr/share/ssl/misc/CA -newreq
erzeugt ein Host-Zertifikat für ein Gateway. Das Skript fragt wieder nach dem Common Name (CN). Hier muss unbedingt der FQDNangegeben werden. Jetzt fehlt dem Host-Zertifikat nur noch die Unterschrift unserer CA:
# sh /usr/share/ssl/misc/CA -signreq
Das Skript fragt nach dem Passwort der CA. Das signierte Zertifikat befindet sich danach in der Datei newcert.pem. Der Parameter subjectAltName=DNS:your.fully.qualified.dom muss nun wieder aus der Datei /usr/share/ssl/openssl.cnf entfernt werden. FreeS/WAN erwartet das Host-Zertifikat im DER-Format im Verzeichnis /etc:
# openssl x509 -in newcert.pem -outform DER -out newcert.der
# mv newcert.der /etc/x509cert.der
Die SuSE-Distribution erzeugt bei der FreeS/WAN-Installation einen privaten Schlüssel in /etc/ipsec.secrets, der nicht benötigt wird:
# mv /etc/ipsec.secrets /etc/ipsec.secrets.orig
Das fswcert-Werkzeug extrahiert die Schlüssel aus der DER-Datei:
# /usr/lib/ipsec/fswcert --key newreq.pem > /etc/ipsec.secrets
Die Frage nach dem Passwort wird nun mit dem während der Erzeugung des Host-Zertifikats angegebenen Passwort beantwortet. Die Datei/etc/ipsec.secrets sollte danach etwa diesen Inhalt haben:
: RSA {
Modulus: 0xE0....
PublicExponent:0x010001
PrivateExponent: 0xD7....
Prime1:0xF8....
Prime2:0xE6....
Exponent1: 0xB0....
Exponent2: 0x55....
Coefficient: 0x8D....
}
Da die Datei auch den privaten Schlüssel enthält, ist sie vor fremden Blicken zu schützen:
# chmod 600 /etc/ipsec.secrets
Die Konfiguration einer Paketfilter-Firewall wie iptables für eine Standortvernetzung mittels VPN-Gateways ist recht einfach. Bei der Konfiguration der Firewall müssen wie üblich die von FreeS/WAN verwendeten Ports und Protokolle berücksichtigt werden. So benutzt der Pluto-Daemon das UDP-Protokoll und den Port 500 für den Schlüsselaustausch mittels IKE und Port 50 für das ESP-Protokoll. Wird auf der Firewall Masquerading eingesetzt, scheidet das ohnehin nicht unbedingt notwendige AH-Protokoll auf Port 51 aus den bereits genannten Gründen aus. Elegant sind die vom Pluto-Daemon aufrufbaren Skripten, die dem Paketfilter die nötigen Filterregeln dynamisch hinzufügen. Die einfachste Lösung ist die Erstellung statischer Firewall-Regeln, die unabhängig von der Nutzung des VPNs aktiviert werden:
# IKE
iptables -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
iptables -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT
# ESP (nur Port, -kein Protokoll!)
iptables -A INPUT -p 50 -j ACCEPT
iptables -A OUTPUT -p 50 -j ACCEPT
Zwar verwirft FreeS/WAN von Hause aus alle Pakete, die von unbekannten Gateways stammen. Die vorsichtige Administratoren- Natur wird aber trotzdem mit Hilfe der Filterregeln nur Verbindungen von bekannten Gateway-Adressen zulassen. Die in Deutschland weit verbreitete SuSE-Distribution enthält die von Marc Heuse entwickelte SuSE-Firewall2 [13], die die iptables-Konfiguration erheblich vereinfacht. Sie muss in der Datei /etc/rc.config.d/firewall2.rc.configmit diesen zusätzlichen Parametern FreeS/WAN-tauglich gemacht werden:
FW_DEV_EXT="eth0 ipsec0"
In diesem Beispiel wird von einem externen Interface eth0 ausgegangen und ipsec0 hinzugefügt. Dies ist notwendig, da die SuSEFirewall anderenfalls den Spoofing-Schutz rp_filter im Kernel aktiviert. FreeS/WAN verweigert dann den Dienst und beschwert sich mit:
ipsec_setup: WARNING: ipsec0 has route filtering turned on, KLIPS may not work
ipsec_setup: (/proc/sys/net/ipv4/conf/ipsec0/rp_filter= `1', should be 0)
ipsec_setup: WARNING:eth0 has route filtering turned on, KLIPS may not work
ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = `1', should be 0)
Abschließend wird die Variable FW_SERVICES_EXT_UDP um den Wert 500 und FW_SERVICES_EXT_IP um 50 ergänzt.
FreeS/WAN steht teuren, kommerziellen Produkten in nichts nach. Ein grafische Benutzeroberfläche gibt es allerdings (noch) nicht. Ob sie zur einfacheren Bedienung oder zum besseren Verständnis der VPN-Technologie und damit zu mehr Sicherheit beiträgt, ist auch sehr fraglich. VPN-Gateways sind ''erklärungsbedürftige Produkte''und mitnichten ohne Vorkenntnisse an einem Nachmittag zu installieren. Wer die Zeit und das Interesse mitbringt, findet dank der hervorragenden Dokumentation einen schnellen Einstieg und realisiert mit FreeS/WAN professionelle Lösungen.
Über den Autor Jörg Frühbrodt ist freiberuflicher Consultant/Trainer. Er war zuletzt Leiter der Berliner Niederlassung der ID-PRO AG und zuvor Senior Consultant für die GE CompuNet AG, Sun Microsystems sowie die Britischen Streitkräfte.
1 http://www.freeswan.org
2
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/openssh.html
3 http://www.chiark.greenend.org.uk/~sgtatham/putty
4 http://sunsite.dk/vpnd/
5 http://stunnel.mirt.net/
6 http://cag.lcs.mit.edu/~cananian/Projects/PPTP/
7 http://poptop.lineo.com/
8 http://www.hsc.fr/ressources/ipsec/ipsec2001/#intro
9 http://www.hsc.fr/ipsec/ipsec2001/
10 http://www.linuxdoc.org/HOWTO/VPN-Masquerade-HOWTO.html
11 http://www.strongsec.com/freeswan
12 http://www.openssl.org
13 http://www.suse.de/~marc