IPsec ist der De-facto-Standard für den Aufbau virtueller privater Netze (VPNs). Freeswan integriert dieses Sicherheitsprotokoll in den Linux-Kernel und unterstützt dabei sogar die opportunistische Verschlüsselung. Installation und Konfiguration sind jedoch nicht trivial.

Wer zwei weit voneinander entfernte Netzwerke ohne teure Standleitung sicher miteinander verbinden will, setzt ein virtuelles privates Netz auf. Internet Protocol Security (IPsec) hat sich als Standard etabliert, es ist inzwischen möglich, mit den verschiedensten Hardwareplattformen und Softwarelösungen interoperable VPNs aufzubauen. Unter Linux implementiert das Freeswan-Projekt[1] IPsec mit IPv4 und den Linux-Kerneln 2.2 oder 2.4.

Freeswan bietet zwar alle Funktionen, die für ein VPN nötig sind, das genügt den meisten Anwendern jedoch nicht. Viele Programmierer haben zusätzlichen Code in Form von Patches für Freeswan entwickelt, siehe Kasten “Freeswan-Patches”. Da Freeswan selbst ein Kernel-Patch ist, handelt es sich hier um Patches für das Patch – diese ungewöhnliche Kombination installieren ist oft nicht ganz einfach.

Seit April dieses Jahres ist mit Freeswan 2.0 eine neue Version verfügbar, die erstmals per Default opportunistische Verschlüsselung (siehe zwei Seiten weiter) aktiviert. Hierzu haben die Entwickler neue Policy-Groups zu Freeswan hinzugefügt. Die aktuelle Version 2.01 und ihre wesentlichen Neuerungen sind das Thema dieses Artikels.

Freeswan 2.0 installieren

Um Freeswan zu installieren, bieten sich zwei oder drei verschiedene Methoden an. Möglicherweise liefert die eingesetzte Distribution bereits Freeswan mit (zum Beispiel SuSE, Mandrake, Debian 3.0); deren Versionen sind jedoch häufig veraltet. Weiterhin bleibt die Wahl zwischen RPM-Paketen und einer Installation direkt aus den Quellen.

Für das Installieren aus den Sourcen sind der Quelltext eines aktuellen Kernels, das aktuelle Freeswan-Paket[1] und das zugehörige X.509-Patch[2] erforderlich. Damit das Kompilieren gelingt, verlangt Freeswan, dass der Kernel bereits einmal erfolgreich ohne Freeswan übersetzt wurde. Anschließend patcht der Administrator den Kernel und übersetzt ihn:

cd /usr/local/src
tar xzf freeswan-2.01.tar.gz
tar xzf x509-1.4.2-freeswan-2.01.tar.gz
cd freeswan-2.01
patch -p1 < ../x509-1.4.2-freeswan-2.01/
freeswan.diff > /dev/null
make oldgo KERNELSRC=/usr/src/linux

Wer noch Änderungen an der Konfiguration vornehmen will, sollte statt »make oldgo« besser »make xgo« aufrufen (Abbildung 1). Nach dem erfolgreichen Kompilieren gelingt das Installieren mit dem Befehl »make kinstall« – dieser Aufruf führt unter anderem zu einem »make install« in den Kernelquellen.

Grabungsarbeiten

Ist der neue Kernel gebootet, kann der Admin den VPN-Tunnel konfigurieren. Als Beispielszenario dient ein VPN-Gateway: Der VPN-Client verwendet eine dynamische IP-Adresse, die bei der Konfiguration des Tunnels nicht bekannt ist (Abbildung 2). Diese Clients werden als Roadwarrior bezeichnet, der Netzaufbau heißt Client-to-Site-VPN.

Für die Authentifizierung benötigen bei Freeswan beide Systeme je ein RSA-Schlüsselpaar aus einem privaten und einem öffentlichen Schlüssel. Der Admin kann sie mit dem Befehl »ipsec newhostkey« erzeugen und in der Datei »/etc/ ipsec.secrets« ablegen. Den öffentlichen Schlüssel muss er bei der jeweiligen Gegenseite eintragen. Das Übertragen der öffentlichen Schlüssel ist aufwändig und wird bei vielen VPN-Clients schnell unübersichtlich.

Abbildung 1: Beim Aufruf von »make xgo« in den Freeswan-Quellen sind noch Änderungen an der Kernelkonfiguration möglich.

Abbildung 2: Ein Roadwarrior verbindet sich mit dynamischer IP-Adresse mit dem VPN-Gateway. In seiner Freeswan-Konfiguration ist daher »right=%defaultroute« eingetragen, auf dem VPN-Gateway dagegen »right=%any«.

Einfacher mit Zertifikaten

Zertifikate vereinfachen die Authentifizierung wesentlich, da nun Client und Server ihren öffentlichen Schlüssel beim Verbindungsaufbau selbst zur Gegenseite senden. Damit er das übertragene Zertifikat überprüfen kann, benötigt der Empfänger nur das Zertifikat der ausstellenden CA (Certification Authority). Egal wie viele Roadwarrior unterwegs sind, der VPN-Server muss nur das CA-Zertifikat kennen, um jeden Roadwarrior zu authentifizieren. Das Erzeugen der Zertifikate ist im Kasten “Zertifikate ausstellen” beschrieben.

Das Listing 1 zeigt die Konfigurations-datei des VPN-Gateway. Die beiden Endpunkte des VPNs heißen »left« und »right«; links liegt im Folgenden das VPN-Gateway, der Roadwarrior befindet sich auf der rechten Seite (siehe Abbildung 2).

Die Einträge bei »left« und »right« sind die IP-Adressen der Tunnelendpunkte. Ist die Adresse des fernen Tunnelendpunkts nicht bekannt, setzt der Admin stattdessen das Schlüsselwort »%any« ein. Kennt er seine eigene IP-Adresse nicht, muss er dafür den Wert »%defaultroute« eintragen.

Hinter dem linken Tunnelende liegt ein ganzes Netz

Die Werte »leftsubnet« und »rightsubnet« geben ein hinter dem Tunnelendpunkt liegendes Netzwerk an, das den Tunnel nutzen soll. Im Beispiel liegt links das Netz 192.168.0.0/24. »leftnexthop« und »rightnexthop« definieren (wenn bekannt) den Router, über den der Tunnel aufgebaut wird. »leftid« und »rightid« enthalten die eindeutige Identität der VPN-Rechner, sie muss mit dem Subject des verwendeten Zertifikats übereinstimmen.

Der Administrator kann diesen Wert aus dem Zertifikat extrahieren:

openssl x509 -in Cert-File.pem 
  -subject -noout

OpenSSL antwortet darauf mit dem X.500-konformen Distinguished Name »subject=/C=DE/ST=NRW/L=Steinfurt/O=Spenneberg.com/CN=Heimarbeiter«.

Die Parameter »leftcert« und »rightcert« definieren die Datei, in der das Zertifikat des Rechners liegt, wenn es nicht automatisch beim Tunnelaufbau übertragen wird. Damit Freeswan überhaupt Zertifikate verwendet, muss der Administrator noch »leftrsasigkey=%cert« und »rightrsasigkey=%cert« ergänzen.

Die Konfiguration des Heimarbeiters erfolgt ähnlich, sie ist in Abbildung 3 zu sehen. Zusätzlich zur Konfigurationsdatei »/etc/ipsec.conf« ist auf beiden Systemen eine Datei »/etc/ipsec.secrets« erforderlich. Sie enthält den Verweis auf den privaten Schlüssel und eine eventuell benötigte Passphrase, um diesen Schlüssel zu nutzen. Die folgende Zeile zeigt den Eintrag für das VPN-Gateway:

: RSA vpngateway_key.pem "Passphrase"

Der Administrator startet nun Freeswan mit dem Befehl »ipsec setup start« auf beiden Rechnern. Gibt er den Befehl »ipsec auto –up vpngateway-heimarbeiter« auf dem Roadwarrior ein, startet der Tunnel. Klappt alles ohne Probleme, sorgt die Angabe »auto=start« dafür, dass Freeswan beim Starten den Tunnel automatisch aufbaut.

Opportunistische Verschlüsselung

Freeswan unterstützt seit einiger Zeit experimentell die opportunistische Verschlüsselung (Opportunistic Encryption, OE). Version 2.0 beendete den experimentellen Status und führt das Feature offiziell ein. Die opportunistische Verschlüsselung ermöglicht es dem Administrator, allein durch die Installation von Freeswan automatisch Tunnel zu öffnen. Er muss Freeswan nicht konfigurieren, alle Informationen liegen in den Zonendateien des DNS-Servers.

Version 2.01 modifiziert diese Technik bereits wieder, es ist also keine Rückwärtskompatibilität gewährleistet. Während Freeswan 2.0 TXT- und KEY-Resource-Records nutzte, verwendet Freeswan 2.01 nur noch TXT-RR.

Die opportunistische Verschlüsselung verwendet zur Authentifizierung nur RSA-Schlüssel, keine Zertifikate. Da es die Schlüssel über DNS verbreitet, ist die Authentifizierung nur so sicher wie DNS – bei klassischem DNS also ziemlich unsicher. Ohne Secure DNS schützt OE nur vor passiven Angreifern, nicht vor Man-in-the-Middle-Attacken[13].

OE unterscheidet zwischen Initiator und Responder. Der Initiator muss seinen öffentlichen Schlüssel als TXT-RR bei einer Domäne eintragen. Hierzu wählt er zunächst einen sinnvollen DNS-Namen, beispielsweise »initiator.example.com«, und ruft anschließend »ipsec showhostkey –txt @initiator.example.com« auf. Die Ausgabe dieses Kommandos muss als TXT-RR unter der eigenen Adresse im DNS liegen; der Initiator sollte diesen String vom Administrator des DNS-Servers eintragen lassen.

Der Responder dagegen muss seinen Schlüssel als Reverse-DNS-TXT-Record im DNS-Server veröffentlichen. Er erzeugt die Textversion seines Schlüssel mit dem Befehl »ipsec showhostkey –txt IP-Adresse«.

01 version 2
02 config setup
03     interfaces="ipsec0=eth0"
04     klipsdebug=none
05     plutodebug=none
06 
07 conn vpngateway-heimarbeiter
08     left=3.0.7.51
09     leftsubnet=192.168.0.0/24
10     leftnexthop=3.255.255.254
11     leftrsasigkey=%cert
12     leftcert=vpngateway_cert.pem
13     leftid="/C=DE/ST=NRW/L=Steinfurt/O=Spenneberg.com/CN=VPN-Gateway/Email=ralf@spenneberg.net"
14     right=%any
15     rightrsasigkey=%cert
16     auto=add

01 conn block
02     auto=ignore
03 conn private
04     auto=ignore
05 conn private-or-clear
06     auto=ignore
07 conn clear-or-private
08     auto=ignore
09 conn clear
10     auto=ignore
11 conn packetdefault
12     auto=ignore

Vollständiger Opportunismus

Ist jeder Rechner dazu in der Lage, sowohl Initiator als auch Responder zu sein, spricht man von komplettem Opportunismus (full Opportunism). Hier ist keine weitere Konfiguration erforderlich. Freeswan ermittelt bei der Kommunikation mit einem anderen Rechner selbst die erforderlichen Schlüssel und baut, wenn möglich, automatisch eine verschlüsselte Verbindung auf.

Für den automatischen Aufbau der opportunistischen Verschlüsselung sind die neu eingebauten Policy-Groups und die »packetdefault«-Verbindung zuständig. Fünf Gruppen sind in Freeswan enthalten: »private«, »private-or-clear«, »clear-or-private«, »clear« und »block«. Sie werden durch IP-Adressen oder IP-Adressbereiche konfiguriert, die der Admin in die entsprechenden Dateien »/etc/ipsec.d/policies/ Gruppe« einträgt.

Freeswan wird mit der Gruppe »private« nur verschlüsselt kommunizieren. Bei der Gruppe »private-or-clear« wird es zunächst versuchen eine verschlüsselte Verbindung aufzubauen. Ist dies nicht möglich, weicht es auf eine unverschlüsselte Verbindung aus. Die Gruppe »clear-or-private« wird genau umgekehrt behandelt. Alle Verbindungen zur Gruppe »clear« baut Freeswan unverschlüsselt auf, zur Gruppe »block« verhindert es alle Verbindungen.

/usr/share/ssl/misc/CA -newca

openssl -in demoCA/cacert.pem 
  -out demoCA/cacert2.pem -days 3650 
  -signkey demoCA/private/cakey.pem
mv demoCA/cacert2.pem demoCA/cacert.pem

/usr/share/ssl/misc/CA -newreq
/usr/share/ssl/misc/CA -sign

mv newreq.pem vpngateway_key.pem
mv newcert.pem vpngateway_cert.pem

cp demoCA/cacert.pem /etc/ipsec.d/cacerts
cp vpngateway_key.pem /etc/ipsec.d/private
cp vpngateway_cert.pem /etc/ipsec.d/certs

Gateway ins interne Netz

Zusätzlich zu diesen Gruppen aktiviert Freeswan 2.0 noch die Verbindung »packetdefault«, sie konfiguriert den Host als OE-Gateway für alle dahinter liegenden Rechner.

Die eingebaute opportunistische Verschlüsselung führt oft zu Problemen, wenn sie nicht genutzt wird. Unverschlüsselte Verbindungen an den Tunneln vorbei sind unmöglich beziehungsweise nur mit Verzögerungen nutzbar, außerdem schreibt Freeswan Fehlermeldungen in die Protokolle. Wer die opportunistische Verschlüsselung nicht nutzt, sollte die eingebauten versteckten OE-Verbindungen abschalten. Er muss dazu nur die in dem Listing 2 angegebenen Zeilen in die Konfigurationsdatei »/etc/ ipsec.conf« einfügen.

Wenn sich ein Roadwarrior mit einem VPN-Gateway verbindet, läuft der Kontakt meist übers Internet. Dazu ver-wendet er die IP-Adresse, die er bei der Einwahl von seinem Internet-Provider erhalten hat. Diese IP-Adresse verwendet er auch für die Kommunikation im Tunnel.

Abbildung 3: Der Roadwarrior kennt zwar die Identität des VPN-Gateway (»left=3.0.7.51«), seine eigene IP-Adresse ändert sich aber mit jeder Einwahl. Daher ist »right=%defaultroute« konfiguriert.

Abbildung 4: Im IPsec-Tunnelmodus erhält das Paket einen neuen zusätzlichen IP-Header: Während der Client VPN-intern die Adresse 192.168.0.32 nutzt (oben), sieht das externe Netz nur seine öffentliche Adresse 80.128.95.205 (unten).

DHCP über IPsec

Häufig will der Administrator dem Roadwarrior für die Kommunikation im Tunnel aber eine interne IP-Adresse zuweisen. Die verschlüsselten Pakete werden mit den offiziellen IP-Adressen übertragen, aber innerhalb des Tunnels verwendet der Roadwarrior eine andere, per DHCP zugewiesene IP-Adresse (siehe Abbildung 4).

Das X.509-Patch (siehe Kasten “Freeswan-Patches”) erweitert Freeswan um die Möglichkeit, solche IP-Adressen zuzulassen. Hierzu muss auf dem VPN-Gateway zusätzlich Mario Strassers DHCP-Relay[3] installiert sein, es nimmt die DHCP-Anfragen des Clients entgegen und leitet sie an den internen DHCP-Server des Unternehmens weiter.

Leider ist Freeswan selbst noch nicht in der Lage, DHCP-over-IPsec als Client zu verwenden. Es kann nur als Server arbeiten. Viele Clients unterstützen diese Technik aber, so zum Beispiel der kommerzielle IPsec-Client SSH-Sentinel[6], siehe Abbildung 5.

CRL automatisch beziehen

Erfolgt die Authentifizierung in einem VPN mit X.509-Zertifikaten, entsteht beim Diebstahl eines Laptops ein großes Problem: Das von diesem Laptop verwendete Zertifikat ist nicht mehr vertrauenswürdig, aber weiterhin gültig. Das VPN-Gateway würde dieses Zertifikat erst nach Ablauf seiner Gültigkeitsdauer ablehnen.

Um kompromittierte Zertifikate vor Ablauf dieser Frist für ungültig zu erklären, verwenden Zertifizierungsstellen Rückruflisten (Certificate Revocation Lists, CRLs). Wurde ein Zertifikat kompromittiert, kann die CA mit folgenden Befehlen ein Zertifikat widerrufen:

openssl ca -revoke Zertifikat.pem
openssl ca -gencrl -out ca.crl

In der Vergangenheit musste der VPN-Administrator diese CRL-Listen immer von Hand auf die beteiligten Systeme verteilen. Das X.509-Patch unterstützt nun den automatischen Download der CRLs per FTP, HTTP oder LDAP. Hierzu müssen die CRL-Distributionsquellen im X.509-Zertifikat der CA angegeben sein. Zusätzlich muss der Administrator Curl installieren (für FTP und HTTP) oder beim Kompilieren von Freeswan das LDAP-Protokoll in der Datei »programs /pluto/Makefile« aktivieren.

Abbildung 5: Der SSH-Sentinel (unter Windows) unterstützt DHCP-over-IPsec. In den »Rule Properties« gibt der Benutzer vor, dass er im Tunnel eine virtuelle IP-Adresse nutzen will (links); in den Settings (rechts) wählt er dann aus, dass er diese IP per DHCP beziehen möchte.

Smartcard-Unterstützung

Bisher musste der Freeswan-Anwender den privaten Schlüssel auf der Festplatte speichern. Hat er seinen Schlüssel mit einer Passphrase geschützt, brauchte Freeswan diese in der Datei »/etc/ipsec .secrets« im Klartext, um die Tunnel aufzubauen. Damit war kein echter Schutz der Schlüssel möglich.

Seit Version 1.4.0 kann das X.509-Patch den Schlüssel sowohl auf einer Smartcard als auch einem USB-Crypto-Token speichern. Die Smartcard schützt den Schlüssel wirksam, ein Auslesen ist unmöglich: Die Karte führt alle Signaturoperationen selbst durch. Die Funktionalität im X.509-Patch basiert auf der Open-SC-Bibliothek[8] und auf dem PC/SC-Lite Paket[9]. Beide können als RPM-Pakete für Red Hat Linux von der Homepage des Autors heruntergeladen werden[10].

Für die Smartcard-Unterstützung muss der Administrator vor dem Kompilieren noch folgenden Eintrag in der Datei »programs/pluto/Makefile« anpassen: »SMARTCARD=1«. In der Konfigurationsdatei »/etc/ipsec.conf« gibt er dann nicht mehr die Datei an, in der das Zertifikat abgespeichert ist, sondern die Smartcard:

leftcert=%smartcard

Da die Smartcard die Verwendung des Schlüssels mit einer PIN schützt, muss Freeswan beim Aufbau des Tunnels diese PIN kennen. Der User speichert sie entweder in der Datei »/etc/ipsec. secrets« im Klartext oder Freeswan fordert sie bei Bedarf von ihm an. Die beiden möglichen Varianten sind:

• »PIN %smartcard ” 12345678“«
• »PIN %smartcard %prompt«

Die PIN vom Benutzer anfordern ist die sichere Variante, ein geklauter Server wird nicht zum Sicherheitsproblem. Jedoch verhindert diese Variante, dass Freeswan automatisch neu starten kann.

01 config setup
02     interfaces=%none     # new default is %defaultroute
03     plutoload=%none      # new default is %search
04     plutostart=%none     # new default is %search
05 
06 conn %default
07     uniqueids=no         # new default is yes
08     keyingtries=3        # new default is %forever
09     disablearrivalcheck=yes     # new default is no
10     authby=secret        # new default is rsasig
11     leftrsasigkey=%none  # new default %dnsondemand
12     rightrsasigkey=%none # new default %dnsondeman

Fazit

Freeswan ist mit den neuesten Modifikationen eine sehr mächtige IPsec-Implementierung und enthält nun zusätzlich Funktionen, die sonst nur von kommerziellen Herstellern angeboten werden. Speziell die automatischen CRL-Updates und die Smartcard-Unterstützung erlauben es dem Administrator, Freeswan auch in professionellen Umgebungen einzusetzen. (fjl)