© mtrebbin,123RF.com

Beim Tunnelgraben mit IPsec hat der Admin mit Racoon, Isakmpd, Open- und Strongswan die Wahl aus vier Implementierungen. Der Artikel beleuchtet die Unterschiede und zeigt, wer in puncto Interoperabilität mit Microsofts und Ciscos IPsec-Varianten das Schnäuzchen vorn hat.

IPsec ist kompliziert und schwer zu durchschauen, so heißt es. Vor allem in heterogenen Netzen scheitere die Konfiguration schon an den verschiedenen Implementierungen der Hersteller. Wer betriebssystemübergreifend tunneln will, müsse mit Engelsgeduld ausgestattet sein und viele Hindernisse aus dem Weg räumen. Ob dem so ist und welche Konfigurationen funktionieren, haben eine Master Thesis am Technikum Wien und dieser Artikel untersucht.

Eigener IPsec-Stack

Seit Kernel 2.6 kommt Linux mit einem eigenen IPsec-Stack daher, im manuellen Verfahren angestoßen vom Programm »setkey«. Optionale Software wie die »ipsec-tools« [1] befüllen die IPsec- Datenbanken Security Association Database (SAD) und Security Policy Database (SPD) mit den notwendigen Daten und sichern anhand dieser Security Policies den Datenverkehr zwischen den definierten Kommunikationspartnern. Um den Austausch der in der Praxis verwendeten Kennwörter (Pre Shared Keys, PSK), digitalen Signaturen oder Zertifikaten sicher zu automatisieren, gibt es das standardisierte Verfahren des Internet-Key-Exchange-Mechanismus (IKE, [2]), das wegen seiner Komplexität in der Vergangenheit immer wieder für Aufregung und Diskussionen sorgte. Für IPsec mit IKE gibt es unter Linux vier Open-Source-Lösungen, von denen eine, Strongswan, auch die neueste, übersichtlichere Version IKEv2 beherrscht [3]. Der erste Kandidat, Racoon [1], war ursprünglich ein Teil des KAME-Projekts, in dem sich Ende der 90er Jahre sechs japanische Unternehmen verbündeten, um einen freien Stack für IPv6 und IPsec zu entwickeln. Er ist direkt in den IPsec-Tools integriert und stellt einen IKE-Daemon zur Verfügung, der alle gängigen Verschlüsselungs- und Datenintegritätsverfahren wie 3DES, Xauth, AES und MD5 beherrscht. An IKEv2 arbeiten die Entwickler des Forks Racoon2 [4].

Mobiler Waschbär

Der Waschbär (Racoon) kann auch Verbindungen mit einem so genannten Roadwarrior herstellen und diesem über das Mode-Configuration-Verfahren Einstellungen übermitteln. Roadwarrior sind Netzwerkelemente, deren IP-Adressen den Gateways anfangs unbekannt sind. Er muss dafür auf fremde Clients reagieren können und prüft deren Identität und Rechte nicht anhand der IP, sondern über X.509-Zertifikate und Kennwörter. Der Laptop eines Außendienstlers, der von Kunde zu Kunde fährt und sich aus deren Netzen in die Zentrale einwählt, ist ein typischer Roadwarrior, wie auch der heimische DSL-Anschluss, der täglich eine neue IP-Adresse erhält. Die Konfiguration von Racoon ähnelt einer C++-Struktur und findet in drei Dateien statt (Listings 1 bis 3). In »racoon.conf« (Listing 1) beschreiben zwei Blöcke zuerst den Kommunikationspartner und dann die zu verwendenden Sicherheitsparameter für die IPsec-Verbindung. Die Security Policies liegen in »setkey.conf« (Listing 2), den Pre-Shared-Key (PSK) speichert in diesem Beispiel die Datei »psk.txt« (Listing 3).

path pre_shared_key "/home/nad/Desktop/psk.txt";
remote 192.168.1.2
{
 exchange_mode main;
 proposal
 {
    encryption_algorithm 3des;
    hash_algorithm md5;
    authentication_method pre_shared_key;
    dh_group modp1024;
  }
}
sainfo address 192.168.1.1 any address 192.168.1.2 any
{
  pfs_group modp768;
  encryption_algorithm 3des;
  authentication_algorithm hmac_md5;
  compression_algorithm deflate;
}
sainfo address 192.168.1.2 any address 192.168.1.1 any
{
 pfs_group modp768;
 encryption_algorithm 3des;
 authentication_algorithm hmac_md5;
 compression_algorithm deflate;
}

#!/usr/sbin/setkey -f
# Leeren der SAD und der SPD
flush;
spdflush;
# Policies für racoon
spdadd 192.168.1.1 192.168.1.2 any -P out ipsec
 esp/transport//require
 ah/transport//require;
spdadd 192.168.1.2 192.168.1.1 any -P in ipsec
 esp/transport//require
 ah/transport//require;

# Passwort für Host A
192.168.1.2     1234

Flexibel

Racoon beherrscht Main, Agressive und Base Mode der IKE-Phase 1, kann Authentifizierung über PSK, X.509-Zertifikate, Kerberos und Xauth einbinden und bietet alle gängigen Verschlüsselungsalgorithmen an (unter anderem DES, 3DES, AES, Blowfish, Twofish, Cast). Für die Integritätsprüfung bringt es MD5, SHA1, SHA2-256, SHA2-385 und SHA2-5 mit, Diffie-Hellman und Perfect Forward Secrecy (PFS) sind auch an Bord. Racoon funktioniert zwischen Linux- Rechnern einfach und unkompliziert, einen erfolgreichen Verbindungsaufbau mit X.509 und Xauth zeigt Abbildung 1. Mit der Cisco-Implementierung ließ sich allerdings im Test keine Verbindung herstellen, sobald Xauth ins Spiel kam. Darüber hinaus machen Versionen vor 0.7.1 Probleme beim Laden der korrekten Security Associations.

Abbildung 1: Erfolgreiche IPsec-Verbindung von Racoon mit X.509-Zertifikaten.

Keine Schwäne

Nur oberflächlich erweisen sich die Linux-IPsec-Entwickler als tierlieb. Mit Schwänen haben Implementierungen, die aus dem eingestellten Freeswan-Projekt hervorgegangen sind, nichts zu tun. Mit Openswan [5] und Strongswan [6] haben sich zwei sehr ähnliche Varianten entwickelt, wobei die Abkürzung SWAN für Secure Wide Area Network steht. Wie Racoon bieten beide Implementierungen einen IKE-Daemon mit allen nötigen Verschlüsselungssystemen und Support für Roadwarrior inklusive Xauth und Mode Configuration an. Die Konfiguration für beide Systeme ähnelt sich sehr stark und unterscheidet sich nur in wenigen Punkten, zum Beispiel bei den Startkommandos und -Parametern des Daemon. Am bedeutendsten ist noch, dass Openswan derzeit noch kein IKE in Version 2 beherrscht. Strongswan hingegen punktet mit der ersten Open-Source-Implementierung von IKEv2, Openswan dafür mit dem Aggressive Mode, der beim Verbindungsaufbau die Protokolldaten verringert und so den Aufbau beschleunigt. Ein detaillierter Vergleich der Features beider Implementierungen findet sich im Wiki der Openswan-Webseite [6]. Auffällig: Openswan läuft auch auf Windows, diversen BSDs, unterstützt Mac OS X und beherrscht Xauth via PAM. Listing 4 zeigt eine typische Openswan-Konfiguration mit in der Datei »ipsec.conf« gespeicherten RSA-Keys. Ob Tunnel- oder Transportmodus, PSK oder Zertifikate, der Admin findet alle Informationen an einem Ort. Das Gleiche gilt für Strongswan: Listing 5 zeigt eine X.509-Konfiguration für einen Roadwarrior. Sowohl Racoon als auch beide Schwäne glänzten unter Linux durch herausragende Interoperabilität und bescherten den Testern erfolgreiche Verbindungen.

# /etc/ipsec.conf - Openswan IPsec
configuration file
# basic configuration
config setup
# Add connections here
conn net-to-net
 left=192.168.1.1
 leftrsasigkey=0sAQOHoLKXZQR+qVtxPp2lLNAB4dqlR0uOR+jRxKBhvSTqh75Y2Y5NtqM50zwxnzjzMDBhbvMlKCMv1PZWDipo77BuadiC4yujWxv++
rB9qoOETgO44AE2j0SMiqpCZZRoJWUPZCHQtx6ZW2Q7sNY19AJx+
lQX2tkFnJ7DkKL8ctfC1cOr0ol3essF1pbHaTKT2o6ZNSiQBaZSp4l3O9ifauC5ScFWjgGnqlez2TtW5Vk0hbydrZFw4y9JvVWgsbZqjaOoW9xIAc6t+
6EJJjnnavNjhJDFHMAha8mRR8m3bc0BTKBMcFHxgRPA5tKy+bO9YrlOQPcPaqL2BGN2NssDWj9+/HDMTY5V53N8IgFAc7FjRTtt
 right=192.168.1.2
 rightrsasigkey=0sAQNwAT/8xuS169fFKTeoaawAw0e+zZx2AD5EakxHHF8Z2wHJ4HWZoQ0xNtU+
xxYSHJDJY0L4dUYamjICdNIJDcjXqCTAGNWtsJlnwWehKlFgH6lK20EeXTuJP5iHzH2SL3DciwrQD7AocnMUmwL5fxdV61iUKFykZY2wINzttbk5+
L2Wb3r5tmDnyI2xFuon9j0SzxzRaG1WnMglutide06prjl2+eno9UWP+r/zEf8OSDjn07SM/hmsxCQP471v908qitmXY/
jit1KMB652zcZihCXxJYtoptxBCdiXHbAVmTnKmYl6sNfiS/Snmp87gTzMz2wH7jz7PjmIublT/rhyZOY61kWyFd95gmvqxXmGjXXJ
 authby=rsasig
 auto=add

# /etc/ipsec.conf - Openswan IPsec configuration file
version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup
 plutodebug=all

# Add connections here
conn roadwarrior
 authby=rsasig
 left=192.168.1.1
 leftrsasigkey=%cert
 leftid="/C=AT/ST=Austria/L=Vienna/O=Langer-Masterthesis/OU=Langer-Masterthesis/CN=HostA"
 leftcert=HostA.public
 right=%defaultroute
 rightrsasigkey=%cert
 rightid="/C=AT/ST=Austria/L=Vienna/O=Langer-Masterarbeit/OU=Langer-Masterarbeit/CN=HostB"
 rightcert=HostB.public
 rightsourceip=%modeconfig
auto=add

Von BSD: Isakmpd

Ursprünglich aus der OpenBSD-Welt kommt Isakmpd [8]. Der IPsec-Daemon aus Berkeley unterscheidet sich schon auf den ersten Blick durch den Stil der Konfiguration. Windows-Administratoren freuen sich, weil die Datei »isakmpd. conf« (Listing 6) stark dem bekannten ».ini«-Format ähnelt, das Microsoft in seinen Betriebssystemen verwendet. Der Sektion »General«, die den Daemon selbst konfiguriert, folgen die Definitionen der Connections, der Clients, des Netzwerks und im Beispiel die Pfade zu den verwendeten X.509-Zertifikaten. Die Datei »isakmpd.policy« (Listing 7) spei- chert die Sicherheitspolicies. In Isakmpd ist IKEv1 voll umgesetzt und funktioniert mit einem geringen Konfigurationsaufwand tadellos. Die IKE-Version 2 beherrscht die aktuelle Version von Isakmpd leider nicht. Ein besonderer Leckerbissen ist dafür sicherlich das Programm »certpatch«, mit dem sich nachträglich Attribute in X.509-Zertifikaten verändern lassen. So kann der Admin einfach IP-basierte Identitätsdaten im Rahmen der X509.V3-Extension »subject Altnames« hinzufügen.

[General]
Listen-on=      192.168.1.1
[Phase 1]
192.168.1.2=    HostB
[Phase 2]
Connections=    test
[HostB]
Phase=          1
Local-address=  192.168.1.1
# Local address
Address=        192.168.1.2
# Peer address
ID=             HostB_ID
[HostB_ID]
ID-type=       IPV4_ADDR
Address=       192.168.1.2
[test]
Phase=         2
ISAKMP-peer=   HostB
Configuration= Default-quick-mode
Local-ID=      HostA_NET
Remote-ID=     HostB_NET
[HostA_NET]
ID-type=       IPV4_ADDR_SUBNET
Network=       192.168.1.0
Netmask=       255.255.255.0
[HostB_NET]
ID-type=             IPV4_ADDR_SUBNET
Network=             192.168.1.0
Netmask=             255.255.255.0
[X509-certificates]
CA-directory=        /etc/isakmpd/ca/
Cert-directory=      /etc/isakmpd/certs/
Private-key=         /etc/isakmpd/private/
HostA_key.pem
[Default-quick-mode]
DOI=                 IPSEC
EXCHANGE_TYPE=       QUICK_MODE
Suites=              QM-ESP-3DES-MD5-PFS-SUITE

KeyNote-Version: 2
Authorizer: "POLICY"
Licensees: "DN:/C=AT/ST=Austria/O=Technikum/OU=MTI/CN=RootCA"
Conditions: app_domain == "IPsec policy" && esp_present == "yes" && esp_enc_alg == "3des" -> "true";

Windows XP

Ähnlich wie Linux beherrscht auch Windows XP das IPsec-Protokoll mit den gängigsten Verschlüsselungen und Datenintegritätsprüfungen. Die Konfiguration des Windows-Stacks ist allerdings wie üblich grafisch gestaltet und wirkt etwas behäbig. Der Zeitaufwand für die Konfiguration ist definitiv höher als bei den Textdateien der Linux-Varianten, vor allem weil neben einem eigenen MMC- Snapin auch eine neue lokale Security Policy definiert sein will. Darüber hinaus empfiehlt es sich, für die Verschlüsselung auf 3DES zu setzen, XP kann nämlich kein AES. Fürs sinnvolle Debuggen muss der Admin noch das standardmäßig deaktivierte Logging der SA-Informationen einschalten. Das geht allerdings nur über die Windows-Registry [8]. Grundsätzlich arbeiten sowohl Isakmpd, Racoon als auch die beiden Schwäne harmonisch mit dem IPsec-Stack von Windows XP zusammen (siehe Abbildung 2). Schnell an die Grenzen stößt jedoch, wer Windows XP mit IKEv2 oder Mode Configuration in Roadwarrior-Szenarien benutzen möchte. Hierfür hat Microsoft aktuell noch keine Lösung integriert

Abbildung 2: Die freien Implementierungen arbeiten problemlos mit Microsofts IPsec-Implementierung auf Windows zusammen. Schwierig wird es allerdings in anspruchsvolleren Setups.

Was Eigenes: Cisco

Noch frickeliger gestaltet sich die Kommunikation mit Geräten von Herstellern wie Cisco. Der Tunnelbau zwischen Linux und beispielsweise einer Cisco Pix ist leider seit Jahren unverändert nur fortgeschrittenen Usern mit spezifischem Netzwerk-Know-how vorbehalten. Die Konfiguration der Cisco-Hardware, speziell in Verbindung mit X.509-Zertifikaten, Xauth und Mode Configuration scheitert oft an Problemen wie der eigenwilligen Identitätsprüfung von Cisco. Wo der Hardwarehersteller mit Group-IDs und IP-Adressen arbeitet, benutzen Racoon und Strongswan die Distinguished Names oder Teile davon. Hier muss sich der hoffentlich geübte Admin einige Tricks einfallen lassen, zum Beispiel einen IP-basierten »Subject Alternative Name« im X.509-Zertifikat einfügen, um eine IP-basierte Authentifizierung auf Cisco-Ebene für Racoon zu ermöglichen.

Nur mit Tricks

Im Gegensatz dazu haben die Schwäne gar keine Option für IP-basierte Zertifikatsidentifizierung. Ciscos IOS interpretiert dagegen den »Organisation Unit Name« (OU) in einem X.509-Zertifikat als Group Name oder ermöglicht über »Certificate Maps« auch eine Authentifizierung auf Basis anderer Felder (Subject Names, Subject Alternative Names, …). Wer Xauth und Mode Configuration verwenden will, erlebt dank der fehlenden Standardisierung Probleme. Racoon macht Probleme mit der Abfrage von optionalen Parametern für Xauth, die Cisco als Standard voraussetzt. Eine Dokumentation oder Lösung hierfür suchten die Autoren vergebens. Im Test funktionierte deshalb nur die Kombination Strongswan/Openswan mit Cisco tadellos (Abbildung 3, Tabelle 1). Zusätzlich zu den Änderungen an den Zertifikaten sind in der Strongswan-Konfiguration dafür nur die Zeilen »authby=xauthrsasig« und »leftsourceip =%modeconfig« anzupassen. Auf dem Cisco-Gerät braucht es einen neuen IP-Pool, aus dem der Server dem Roadwarrior eine Adresse zuweist.

Abbildung 3: Geschafft: Die IPsec-Verbindung zwischen Cisco und einem Strongswan-Roadwarrior steht.

Wer mit wem?

Das gute Ergebnis im Zusammenspiel mit Ciscos Implementierung, dazu die Unterstützung für IKEv2 und die flexible Konfiguration lassen Strongswan als eindeutigen Sieger aus dem Vergleich hervorgehen, auch wenn Openswan und Isakmpd in einer einheitlichen Umgebung die Tunnel schneller aufbauen (Abbildung 4). Wer also nur Tunnel zwischen Linux-Servern und -Clients graben will, wird mit jedem der vier freien Projekte zufrieden sein. Windows-Admins mag die Isakmpd-Kon- figuration im Microsoft-typischen Ini-Stil verlocken, aber auch Racoon und die Schwäne arbeiten hier problemlos. Sobald jedoch die Ansprüche wachsen und die Konfiguration komplexer wird, sind bei ihnen Probleme programmiert. Erfreulich ist, dass alle Linux-Implementierungen gut dokumentiert sind und die Konfigurationen auch in Standardwerken wie Ralf Spennebergs “VPN mit Linux” [10] oder dem IPsec-Howto [8] ausführlich erläutert sind. Enttäuschenderweise finden sich wenige bis gar keine Informationen über Verbindungskonfigurationen zwischen Cisco-Hardware und den Linux-IKE-Implementierungen.

Abbildung 4: Benötigte Zeit für den Verbindungsaufbau mit IKEv1 und X.509-Zertifikaten. Zwei Linux-Rechner mit Racoon brauchen am längsten, am schnellsten sind Openswan und Isakmpd.

Tabelle 1: Kompatibilität zwischen IPsec-Software

Tabelle 2: Softwareversionen