Sicherere latenzarmeKommunikationswege mit IPsec
Seminarfacharbeitam Ernst-Abbe-Gymnasium Jena
Name: Thomas WalpuskiKurs: 12/IKursleiter: Frau ZöllnerSeminarfachlehrer: Frau SchindlerAußenbetreuer: Christian Kahlo und Lutz DonnerhackeAbgabedatum: 11. Oktober 2002
i
Inhaltsverzeichnis
1 IP und IPsec 1
2 IPsec in der Theorie 12.1 AH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3.1 Phase 1 – Main Mode . . . . . . . . . . . . . . . . . . . . . . . . 32.3.2 Phase 2 – Quick Mode . . . . . . . . . . . . . . . . . . . . . . . 5
3 IPsec im Einsatz 6
4 Freie IPsec-Implementationen 84.1 FreeS/WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.2 OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5 Test und Vergleich kommerzieller IPsec-Lösungen 105.1 Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2 Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1 Windows 2000 und XP nativ . . . . . . . . . . . . . . . . . . . 125.2.2 SSH Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2.3 SoftRemote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2.4 PGPnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6 Ausblick 24
A Literatur 1
B Glossar 5
C PKI 6C.1 OpenSSL-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 6C.2 Aufsetzen der CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7C.3 VPN-Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8C.4 VPN-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9C.5 CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11C.6 OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11C.7 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13C.8 ldap_match_mapped.c.diff . . . . . . . . . . . . . . . . . . . . . . . . . 14
D Konfiguration des VPN-Gateways 16
E Konfiguration der VPN-Clients 17E.1 Windows 2000/XP nativ . . . . . . . . . . . . . . . . . . . . . . . . . . 17E.2 SSH Sentinel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19E.3 SoftRemote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20E.4 PGPnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
ii
Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich die vorliegende Seminarfacharbeit selbständigdurchgeführt und keine anderen als die angegebenen Quellen und Hilfsmittelbenutzt habe.
Thomas WalpuskiJena, den 2. Oktober 2002
iii
Danksagung
Dank geht an meine Seminarfachbetreuer Christian Kahlo und Lutz Donnerhackesowie Urs Traenkner und Clemens Draschl für interessante und geistig anregendeDiskussionen zum Thema.Weiterhin danke ich Timofej Woyzichovski, Florian Adamsky, Timo Bolse, EnricoKern und Christian Ginksi für das Korrekturlesen der Arbeit und nützlicheHinweise.Besonderer Dank gebührt Uros Setina und Timo Ihalempia von SSH für ihrengroßartigen Support.
1
1 IP und IPsec
IP ist das Layer-3-Protokoll, auf dem sowohl das Internet als auch fast alle anderen
Rechnernetze basieren. Als 1981 der Standard für IPv4 [Pos81] verabschiedet wurde,
spielte die Sicherheit des Protokolls wohl nur eine sehr untergeordnete Rolle. So
gewährleistet IPv4 weder Vertraulichkeit (Kennt jemand die Daten, der sie nicht
kennen sollte?) noch Authentizität (Stammen die Daten wirklich vom vermeintlich-
en Sender?) oder gar Integrität (Wurden die Daten verändert?).
Diese sind es jedoch, die den Grundstein für eine vernünftige Form der Kommu-
nikation legen. Man stelle sich derartig Umstände in der direkten zwischenmensch-
lichen Kommunikation vor: Man spricht mit jemandem, kann sich aber nicht sicher
sein, ob die Worte wirklich von ihm kommen und ob die Worte, die man hört, über-
haupt die sind, die gesprochen wurden.
Mit IPsec für IPv4 und IPv6 [DH98], das die Benutzung von IPsec vorsieht, ge-
hören derartige Probleme der Vergangenheit an.
2 IPsec in der Theorie
IPsec [KA98c] ist eine standardisierte Sicherheitsarchitektur für IP. Die wichtigsten
Bestandteile sind die Sicherheitsprotokolle Authentication Header (AH) [KA98a]
und Encapsulating Security Payload (ESP) [KA98b] sowie das Key-Management-
Protokoll Internet Key Exchange (IKE) [HC98].
Ein zentrales Konzept in IPsec ist das der Security Association (SA). SAs sind
durch einen jeweils einzigartigen Security Parameter Index (SPI) zur Identifikati-
on, eine Ziel-IP-Adresse und ein Sicherheitsprotokoll definiert. SAs beschreiben al-
so eine unidirektionale Verbindung, die durch AH oder ESP geschützt werden soll.
Bidirektionale Verbindungen verdoppeln die Anzahl der erforderlichen SAs, eben-
so die Anwendung beider Sicherheitsprotokolle. Derartig zusammengehörige SAs
werden auch als SA-Bundles bezeichnet.
Man unterscheidet zwei Modi für SAs: Transport Mode und Tunnel Mode. Im
Transport Mode wird der Header des Sicherheitsprotokolls nach dem IP-Header
und vor dem Header des nächst höheren Layers eingefügt. Der Transport Mode eig-
2
net sich damit ausschließlich für Verbindungen zwischen zwei Rechnern. Im Tunnel
Mode wird das komplette Original-Paket in einem geschützten IP-Paket getunnelt.
Dem Originalpaket wird also ein IP-Header, gefolgt vom Header eines Sicherheits-
protokolls, vorangestellt. Damit eignet sich der Tunnel Mode auch für die Sicherung
des IP-Traffics zwischen zwei Netzen oder einem Rechner und einem Netz.
SAs bzw. SA-Bundles werden in der Security Association Database (SAD) ge-
speichert. Dort sind sie in der Regel direkt mit dem jeweils benötigten Schlüssel-
material gekoppelt. Die Anwendungsstrategie (Welcher IP-Traffic wird geschützt?
Welcher wird weitergereicht? Welcher wird verworfen? Welche Verschlüsselungs-
und HMAC-Algorithmen [KBC97] kommen zum Einsatz?) ist in der Security Po-
licy Database (SPD) vermerkt. Die Einträge der SPD sind über den SPI mit denen
der SAD verknüpft. Eine standardkonforme Implementation prüft den gesamten
IP-Traffic der Interfaces, für die IPsec aktiviert wurde, gegen die SPD und die SAD
und entscheidet entsprechend wie zu verfahren ist.
2.1 AH
Ein AH-Header besteht aus sechs Feldern: Next Header, Payload Length, einem für
die spätere Verwendung reservierten Feld, SPI, Sequence Number und Authentica-
tion Data.
Next Header spezifiziert an Hand der IP-Protokoll-Nummer das Protokoll des
nächst höheren Layers. Payload Length gibt die Länge des AH-Headers in 32-Bit-
Worten abzüglich 2 an. SPI dient der Identifikation der zu verwendenden SA.
Sequence Number wird beim Erstellen der SA mit 0 initialisiert und mit jedem
versandtem Paket um 1 erhöht. Dem Empfänger wird damit ermöglicht, das wie-
derholte Senden eines Pakets und somit möglicherweise einen Replay-Angriff zu
entdecken.
Authentication Data enthält einen HMAC über alle nicht veränderlichen Felder
des IP-Headers, den AH-Header, wobei Authentication Data auf 0 gesetzt wird, und
die Daten der höheren Protokolle. Mit Hilfe dieses HMAC prüft der Empfänger die
Authentizität und Integrität des Pakets. Deswegen wird in diesem Zusammenhang
auch von einem Integrity Check Value (ICV) gesprochen.
3
2.2 ESP
Ein ESP-Paket besteht dem ESP-Header, gefolgt von den Daten der höheren Pro-
tokolle, denen gegebenenfalls ein Initialisierungsvektor (IV) vorangestellt ist, dem
ESP-Trailer und dem Feld Authentication Data. Die Felder SPI und Sequence Num-
ber bilden den ESP-Header. Ihre Funktionen sind die selben wie im AH-Header
(siehe 2.1, S. 2).
Der ESP-Trailer besteht aus Padding, mit dem die Daten auf eine Länge ge-
bracht werden, die der gewählte Verschlüsselungsalgorithmus verarbeiten kann,
sowie den Feldern Pad Length, in dem die Länge des Paddings in Bytes angege-
ben ist, und Next Header. Der ESP-Trailer und die Daten der höheren Protokolle
sind verschlüsselt und somit vertraulich.
Authentication Data beinhaltet einen HMAC über den ESP-Header, die Daten
der höheren Protokolle und den ESP-Trailer. Damit überprüft der Empfänger deren
Authentizität und Integrität. Auch hier spricht man von einem ICV.
2.3 IKE
IKE ist ein universelles Protokoll zum Austausch und Management von Schlüsseln.
Es bedient sich einiger Elemente von ISAKMP [MSST98], Oakley [Orm98] und SKE-
ME [Kra96]. Die genaue Spezifikation findet sich in [HC98]. Für IPsec ist IKE im
Kontext der IPsec-DOI [Pip98] anzuwenden.
Ein Schlüsselaustausch per IKE verläuft in 2 Phasen. In Phase 1 wird eine „lang-
lebige“ authentifizierte ISAKMP-SA sowie geheimes und authentifiziertes Schlüs-
selmaterial erstellt. Dieses ermöglicht Vertraulichkeit, Authentizität und Integrität
in Phase 2. In dieser werden die IPsec-SAs und das notwendige Schlüsselmaterial
erstellt. IPsec-SAs sind gegenüber ISAKMP-SAs meist recht „kurzlebig“, denn über
eine ISAKMP-SA, deren Erstellung zudem relativ aufwändig ist, lassen sich mehre-
re IPsec-SAs verhandeln.
2.3.1 Phase 1 – Main Mode
Phase 1 läuft entweder im Main Mode oder im Aggressive Mode ab. In der Regel
verwendet man den Main Mode, da er die Identitäten der Kommunikationspartner
4
schützt. Den zusätzlichen Overhead von drei Nachrichten gegenüber dem Aggres-
sive Mode, dessen komplette Durchführung nur drei Nachrichten benötigt, nimmt
man dabei in Kauf. Weiterhin sprechen Gründen der Interoperabilität für den Main
Mode, denn die Implementation des Aggressive Mode ist optional und somit in eini-
gen IKE-Daemons wie z.B. Pluto von FreeS/WAN (siehe 4.1, S. 8) nicht vorhanden.
Daher wird der Aggressive Mode hier außer Acht gelassen.
In den ersten beiden Nachrichten des Main Mode einigen sich die Kommunika-
tionspartner auf die Parameter der ISAKMP-SA und den weiteren Verlauf des Main
Mode, d.h. im Besonderen auf einen Verschlüsselungsalgorithmus, einen Hashal-
gorithmus, eine Authentifizierungsmethode und eine Diffie-Hellman-Gruppe. Zur
Authentifizierung definiert der Standard eine Methode mit pre-shared keys, eine
mit Signaturen und zwei Methoden, die auf der Verschlüsselung mit öffentlichen
Schlüssel basieren. In der Regel verwendet man RSA-Signaturen in Verbindung mit
X.509-Zertifikaten [HFPS99], da diese Lösung relativ gut skaliert und von nahe-
zu allen IKE-Daemons unterstützt wird. Aus diesem Grund bleiben die anderen
Methoden hier außen vor. Die ersten beiden Nachrichten dienen außerdem dem
Austausch der Cookies von Initiator CKY-I und Antwortendem CKY-R, die vor
einem DoS-Angriff, der die Aufwendigkeit der durchzuführenden Berechnungen
ausnutzt, schützen sollen [Sim99].
Der eigentliche Schlüsselaustausch nach Diffie-Hellman [DH76] findet in den
Nachrichten drei und vier statt. Dazu sendet der Initiator seinen öffentlichen Dif-
fie-Hellman-Wert gxi, seine Nonce Ni und optional eine oder mehrere Zertifikats-
anforderungen. Der Antwortende sendet daraufhin entsprechend gxr, Nr und op-
tional eine oder mehrere Zertifikatsanforderungen. Von nun an können die Kom-
munikationspartner den gemeinsamen geheimen Schlüssel gxy berechnen. Mit Hilfe
von gxy, Ni und Nr wird SKEYID = prf(Ni | Nr, gxy) errechnet. Dabei ist prf, so
fern keine spezielle Funktion vereinbart wurde, die HMAC-Variante des ausgehan-
delten Hashalgorithmus. Der erste Parameter spezifiziert den Schlüssel, der zwei-
te die Nachricht. Von SKEYID wiederum werden drei weitere Schlüssel abgeleitet:
SKEYIDd = prf(SKEYID, gxy | CKY-I | CKY-R | 0) zur Ableitung weiter Schlüssel,
SKEYIDa = prf(SKEYID, SKEYIDd | gxy | CKY-I | CKY-R | 1) als Authentifizie-
rungsschlüssel und SKEYIDe = prf(SKEYID, SKEYIDa | gxy | CKY-I | CKY-R | 2)
5
zur Verschlüsselung von Nachrichten.
Die Nachrichten fünf und sechs dienen dem gegenseitigen Identitätsbeweis und
damit der Authentifizierung der ISAKMP-SA und des Schlüsselmaterials. Die Nach-
richten sind mit SKEYIDe verschlüsselt. Die Identitäten der Kommunikationspart-
ner bleiben also vertraulich. Der Initator sendet Informationen zu seiner Identität
IDii, das kann z.B. das Subject eines X.509-Zertifikats sein, gegebenenfalls ein oder
mehrere Zertifikate als Antwort auf eine Zertifikatsanforderung und die Signatur
SIGI über HASHI = prf(SKEYID, gxi | gxr | CKY-I | CKY-R | SAi | IDii). Dabei
ist SAi das Angebot an Parametern für die SA seitens des Initiators. Der Antwor-
tende sendet darauf hin IDir, gegebenenfalls ein oder mehrere Zertifikate und die
Signatur SIGR über HASHR = prf(SKEYID, gxr | gxi | CKY-R | CKY-I | SAi | IDir).
An Hand der Signaturen können die Kommunikationspartner die Identität des Ge-
genüber prüfen. Am Ende des Austauschs liegen eine authentifizierte ISAKMP-SA
sowie authentifiziertes und geheimes Schlüsselmaterial vor.
2.3.2 Phase 2 – Quick Mode
Für Phase 2 ist der Quick Mode vorgesehen. Alle Nachrichten im Quick Mode
sind bis auf den Header mit SKEYIDe verschlüsselt. Authentizität und Integrität
der Nachrichten werden durch die Übertragung von HMAC-Werten, die mit Hilfe
des Schlüssels SKEYIDa generiert wurden, sicher gestellt. Die HMAC-Werte dienen
zudem als Beweis der „Lebendigkeit“ und schützen vor dem unbemerkten wieder-
holten Senden von Nachrichten, das zu DoS-Angriffen missbraucht werden könnte.
Der Quick Mode arbeitet in zwei Varianten. Die Basis-Variante bietet keine Per-
fect Forward Secrecy (PFS) für das erzeugte Schlüsselmaterial. Die erweiterte Va-
riante gewährleistet durch einen zusätzlichen Schlüsselaustausch nach Diffie-Hell-
man PFS. D.h. wird ein Schlüssel kompromittiert, sind ausschließlich die durch ihn
geschützten Daten gefährdet, nicht jedoch weitere Schlüssel.
In der ersten Nachricht sendet der Initiator HASH(1) = prf(SKEYIDa, M-ID |
SA | Ni [ | KE ] [ | IDci | IDcr ]), dabei ist M-ID eine einzigartige Nachrichtenkennung,
welche die Grundlage des Beweis der „Lebendigkeit“ darstellt, einen oder mehre-
re Vorschläge für die Parameter der IPsec-SA SA bzw. des SAs-Bundles SA0, SA1,
... , die Nonce Ni, gegebenenfalls die Identitäten von Initiator IDci und Antworten-
6
dem IDcr und einen öffentlichen Diffie-Hellman-Wert KE, falls PFS gewünscht ist.
Der Antwortende sendet darauf hin HASH(2) = prf(SKEYIDa, M-ID | Ni | SA |
Nr [ | KE ] [ | IDci | IDcr ]), den ausgewählten Vorschlag für die Parameter der IPsec-
SA bzw. des SA-Bundles, Nr, gegebenenfalls IDci und IDcr sowie KE, falls PFS ge-
wünscht ist. In der dritten und letzten Nachricht sendet der Initiator HASH(3) =
prf(SKEYIDa, 0 | M-ID | Ni | Nr). Der Quick Mode ist damit abgeschlossen.
Nach der Durchführung des Quick Modes kann das Schlüsselmaterial erzeugt
werden: KEYMAT = prf(SKEYIDd, [ g(qm)xy | ] protocol | SPI | Ni | Nr), wobei
g(qm)xy der gemeinsame geheime Schlüssel aus dem gegebenenfalls durchgeführ-
tem Diffie-Hellman-Austausch ist. Reicht das Schlüsselmaterial nicht aus, wird es
„gestreckt“: Es werden die Teilschlüssel K1 = prf(SKEYIDe, [ g(qm)xy | ] protocol |
SPI | Ni | Nr), K2 = prf(SKEYIDd, K1 [ | g(qm)xy ] | protocol | SPI | Ni | Nr), ...
erzeugt und zu KEYMAT = K1 | K2 | ... zusammengefügt.
3 IPsec im Einsatz
IPsec ist extrem flexibel. Damit ergibt sich eine Unmenge an Möglichkeit, IPsec ein-
zusetzen.
Mit der zunehmenden Verbreitung von Wireless LANs, die meist kinderleicht
abzuhören sind, wird deren Sicherung mit IPsec immer beliebter. Typischer Weise
wird jeglicher IP-Traffic der angebundenen Rechner untereinander direkt mit IP-
sec gesichert. Der Konfigurationsaufwand für diese Lösung kann in großen Netzen
enorm sein, wenn die eingesetzten IPsec-Implementationen keinerlei Vereinfachung
für dieses Szenario anbieten. Das ist zum Glück nur selten der Fall.
Die momentan beliebteste Anwendung von IPsec ist zweifelsohne das VPN. Ein
VPN ist ein Netzwerk sicherer Verbindungen über ein öffentliches und damit meist
unsicheres Netzwerk wie z.B. das Internet.
Besonders beliebt sind dabei Remote-Access-VPNs. Mit diesen können Road-
warriors, das sind z.B. Mitarbeiter, die sich auf Geschäftsreise befinden oder von
zu Hause arbeiten möchten, sicher an ein Netz, z.B. ein internes Firmennetz, an-
geschlossen werden. Eine Alternative dazu wäre, dass sich der Mitarbeiter direkt
bei seiner Firma und nicht seinem ISP einwählt. Diese Lösung kann man allerdings
7
nicht ernstlich als sicher bezeichnen, denn hierbei werden weder Authentizität und
Integrität noch Vertraulichkeit gewährleistet. Außerdem sind derartige Lösungen
meist mit wesentlich höheren Unkosten verbunden.
Die anderen Varianten der VPNs verbinden zwei Netze miteinander. Je nach an-
gebundenem Netz kann man Intranet- und Extranet-VPNs unterscheiden. Intranet-
VPNs werden meist zur Anbindung von Außen- oder Zweigstellen genutzt. Wenn
man ausschließlich von VPNs spricht, sind in der Regel Intranet-VPNs gemeint.
Über Extranet-VPNs werden z.B. Kunden oder Geschäftspartner an das Firmennetz
angebunden. Der Hauptunterschied zwischen Extranet- und Intranet-VPNs besteht
in der engeren Zugriffsbeschränkung bei Extranet-VPNs.
Die Alternative zu VPNs sind private WANs. VPNs sind diesen in fast allen
Aspekten überlegen, zumindest aber ebenbürtig. Mit IPsec realisierte VPNs sind
grundsätzlich als sicherer einzustufen. Private WANs werden meist über Standlei-
tungen zwischen den zu verbindenden Netzen realisiert. Diese laufen in der Re-
gel, zumindest ein Stück weit, über Telefonleitungen, die über keinen besonderen
Schutz verfügen. Auch wenn der ISP direktes Routing verspricht, um die Daten vor
Fremden zu schützen, so muss man doch dem Betreiber der Leitungen vertrauen.
IPsec ist gerade für den sicheren Transport auch über unsichere Wege ausgelegt.
Ein weiterer Vorteil von VPNs: Sie sind meist preiswerter. Es ist nicht notwendig,
auf teure Standleitungen zurückzugreifen. Eine gewöhnliche Internetanbindung ist
vollkommen ausreichend. Die Standleitung zwischen den Firmensitzen in Breisach
und Mühlhausen kostete die Firma BSK Software 780e/Monat. Bei VPN-Lösungen
mit IPsec hingegen entsteht nur ein geringer Mehrpreis für die Anschaffung von
IPsec-Equipment sowie dessen Konfiguration und Wartung gegenüber der bereits
vorhandenen Internetanbindung.
In der Regel sind VPN-Lösungen bei gleichem oder geringerem Preis auch per-
formanter als private WANs. Der Up- und Downstream der Standleitung zwischen
Breisach und Mühlhausen ist auf 128kBit/s begrenzt. Sie ist also mit einer ISDN-
Kanalbündelung vergleichbar. Die Internetanbindungen der meisten Firmen sind
weitaus performanter. Möchte man nicht, dass das VPN über die normale Interne-
tanbindung läuft, kann man sich für 780e/Monat allemal eine zusätzliche Internet-
verbindung anschaffen. Da mittlerweile sehr leistungsstarke Krypto-Hardware, wie
8
der 8154 HIPP II Security Processor von Hifn, der bis zu 2048MBit/s IPsec schafft,
verfügbar sind, können IPsec-Lösungen auch extremen Performanceansprüchen ge-
recht werden.
Im übrigen: BSK Software hat inzwischen auf eine IPsec-Lösung umgestellt.
4 Freie IPsec-Implementationen
Der beste Standard nützt nichts ohne Umsetzung. Vor allem im Open-Source-Be-
reich existiert eine Vielzahl von IPsec-Implementationen. Die meist genutzten sind
wohl FreeS/WAN für Linux sowie die Implementation in OpenBSD und die des
KAME-Projekts für FreeBSD, NetBSD, OpenBSD, BSD/OS und MacOS X.
Das National Institute of Standards and Technology (NIST) hat eine Referenz-IP-
sec-Implementierung namens NIST Cerberus und einen IKE-Daemon namens NIST
PlutoPlus für Linux 2.2 entwickelt. Diese sind jedoch komplett unbrauchbar: Pluto-
Plus beherrscht momentan nur die Authentifizierung mittels pre-shared keys, DES
[NBS88] als Verschlüsselungsalgorithmus und die Diffie-Hellman-Gruppe 1. Die
Entwicklung von Cerberus und PlutoPlus steht nun schon seit einigen Jahren still,
was darauf hindeutet, dass man beim NIST das Interesse verloren hat.
4.1 FreeS/WAN
FreeS/WAN besteht aus einem Patch, der IPsec-Unterstützung für den Linux-Ker-
nel (KLIPS: Kernel IPsec) bereitstellt und dem IKE-Daemon Pluto. Es ist die momen-
tan wohl am weitesten verbreitete IPsec-Implementation für Linux.
Nicht-Einhaltung von Standards ist eines der zentralen Features in FreeS/WAN.
So wird „nur“ 3DES, nicht aber DES unterstützt, obwohl sich entsprechender Co-
de in den Quellen findet, denn DES gewährleistet keine ausreichende Sicherheit
[EFF98]. Gemäß den Standards muss die Diffie-Hellman-Gruppe 1 implementiert
sein. FreeS/WAN unterstützt „nur“ die Diffie-Hellman-Gruppen 2 und 5, denn die
Sicherheit der Diffie-Hellman-Gruppe 1 ist fragwürdig.
Man will damit den Schaden, den unerfahrene Nutzer und Administratoren an-
richten können, wohl möglichst gering halten. Das mag auf der einen Seite als Vor-
9
teil erscheinen. Andererseits ist dadurch die Interoperabilität mit anderen IPsec-Im-
plementationen gefährdet. Ausführlichere Informationen zu den Gründen finden
sich in [SR02].
Bei Problemen während des IKE können informelle Nachrichten sehr hilfreich
sein. FreeS/WAN sendet ausschließlich informelle Nachrichten, wenn eine SA ge-
löscht wurde. Wird eine informelle Nachricht empfangen, so berücksichtigt Pluto
diese nicht weiter. Auch informelle Nachrichten, die zum Löschen einer SA auffor-
dern, werden verworfen. In der FreeS/WAN-FAQ heißt es zu den Gründen: „they
are not authenticated, so any receiver that trusts them leaves itself open to a de-
nial of service attack“. Das ist nachweislich falsch. Mittlerweile hat man das wohl
festgestellt. In [SR02] ist jedenfalls keine Rede mehr davon.
FreeS/WAN weist eine weitere Besonderheit auf: Neben pre-shared keys wer-
den zwar auch RSA-Signaturen zur Authentifizierung unterstützt, allerdings nicht
in Verbindung mit X.509-Zertifikaten. Das wird sich in nächster Zeit auch nicht än-
dern, denn FreeS/WAN setzt hier auf Opportunistic Encryption [RRS02]. Glückli-
cher Weise kann man Unterstützung für X.509-Zertifikate mit einen Patch nachrüs-
ten (http://www.strongsec.com/freeswan/ ). Mit diesem Patch unterstützt
FreeS/WAN außerdem CRLs [HFPS99] und DHCP over IPsec [PAKG01]. Damit ist
eine transparente Integration der Roadwarriors ins VPN möglich, falls die auf den
Roadwarriors verwendete IPsec-Implementation ebenfalls DHCP over IPsec unter-
stützt.
4.2 OpenBSD
OpenBSD unterstützt IPsec nativ. Die Implementation besticht vor allem durch Fle-
xibilität. So werden neben DES und 3DES auch AES [NIS01], Blowfish [Sch93] und
CAST [Ada97] sowie die Hashalgorithmen MD5 [Riv92], SHA-1 [NIS95], RIPEMD-
160 [DBP96] und deren HMAC-Varianten unterstützt. Der IKE-Daemon isakmpd
beherrscht nicht nur die Diffie-Hellman-Gruppen 1, 2 und 5, sondern auch 3 und 4.
Neben pre-shared keys unterstützt isakmpd natürlich auch RSA- und DSS-Sig-
naturen [NIS94] in Verbindung mit X.509-Zertifikaten zur Authentifizierung. Neue-
re Versionen von isakmpd beinhalten auch die im Rahmen dieser Arbeit entstande-
10
ne Unterstützung für CRLs. Diese ist für den Einsatz als VPN-Gateway in größeren
VPNs wichtig ist. Ein weiteres für VPNs interessantes Feature: isakmpd beherrscht
IKE Mode Config [PAP99] zur transparenten Integration von Roadwarriors.
Neben der Flexibilität und der Eignung für den Einsatz als VPN-Gateway war
für mich die strenge Einhaltung der Standards ein Grund, für die Test der kommer-
ziellen IPsec-Lösungen auf OpenBSD zu setzen. Mit der Entscheidung bin ich nicht
allein: Das VPN Consortium (VPNC) benutzt OpenBSD als VPNC Test Partner zur
Überprüfung anderer Implementationen.
5 Test und Vergleich kommerzieller IPsec-Lösungen
Im Rahmen dieser Arbeit wurden verschiedene kommerzielle IPsec-Lösungen ge-
testet. Dabei wurde im Besonderen darauf geachtet, ob sich die Lösungen für typi-
sche Remote-Access-Szenarien eignen.
5.1 Testverfahren
Das VPN-Gateway basierte auf OpenBSD mit einem leicht modifiziertem isakmpd.
Über Loopback-Devices wurde ein LAN simuliert, das im Test einen Teil des VPNs
bildete. Einzelheiten zur Konfiguration von isakmpd finden sich im Anhang (siehe
D, S. 16).
Als Testbed für die kommerziellen IPsec-Lösungen diente ein Rechner, der unter
Windows XP Professional lief. Da eine Lösung nicht unter Windows XP funktionier-
te, war zudem Windows 98 in einer VMware installiert. Die Grundkonfigurationen
der einzelnen Lösungen sind im Anhang vermerkt (siehe E, S. 17).
Die Lösungen wurden zunächst auf Installierbarkeit und Konfigurierbarkeit ge-
prüft. Dabei wurde besonderer Wert auf die Replizierbarkeit der Konfiguration ge-
legt.
Anschließend wurde die Grundfunktionalität der Lösungen untersucht: wer-
den Verschlüsselungsalgorithmen neben DES unterstützt? Welche Hashalgorithmen
kann man einsetzen? Funktioniert die Authentifizierung mit RSA-Signaturen in Ver-
bindung mit X.509-Zertifikaten? Werden neben der Diffie-Hellman-Gruppe 1 weite-
11
re unterstützt? Bietet die Lösung PFS?
Danach stellte sich die Frage, ob die Standards weitgehend korrekt umgesetzt
wurden. Dazu wurde auf typische Fehler, wie Probleme mit Paketen, die erst durch
die Anwendung von IPsec die MTU überschreiten, geprüft. Außerdem wurde un-
tersucht, ob bei bestehender Verbindung zum VPN-Gateway jeglicher nicht VPN-
relevanter Traffic geblockt wird, d.h. ob eine Segmentierung zwischen dem VPN
und den übrigen Netzen, mit denen der Rechner verbunden ist, stattfindet. Das ist
in den meisten Fällen absolut erwünscht, denn ohne Segmentierung stellt der mit
dem VPN-Gateway verbundene Rechner unter Umständen eine offene Stelle und
somit einen Angriffspunkt des Netzes hinter dem VPN-Gateway dar.
Nachdem die grundlegenden Dinge getestet wurden, interessierte zusätzliche
Funktionalität. Das sind zum einen Möglichkeiten zur transparenten Integration ins
VPN, zum anderen erweiterte Möglichkeiten zur Zertifikatsprüfung. Um diese zu
testen, wurden auf dem dritten Rechner, einem Linux-System, eine modifizierte Ver-
sion des LDAP-Server [WHK97] tinyldap (siehe C.7, S. 13) und der Webserver fnord
installiert. Dort wurden CRLs [BHR99] aufbewahrt, die von den IPsec-Lösungen
entweder per LDAP oder über HTTP an Hand der CRL-Distribution-Points-Exten-
sion bezogen werden konnten. Außerdem lief der OCSP-Responder [MAM+99] des
OpenSSL-Projekts (siehe C.6, S. 11), um den OCSP-Support der Lösungen zu testen.
Für andere Zwecke ist er momentan auch absolut nicht zu gebrauchen. Verwendet
wurde eine Entwicklungsversion von OpenSSL-0.9.7.
Auf dem Linux-System war zudem die CA installiert (siehe C.2, S. 7). Dort wur-
den der Einfachheit halber auch die RSA-Schüssel, X.509-Zertifikate etc. für die Cli-
ents erstellt. Im realen Einsatz sollte man die RSA-Schlüssel unbedingt an ihren Ein-
satzorten, das hieße in diesem Fall auf dem Windows XP-Rechner, erstellen, da zum
einen die Erstellung des RSA-Schlüssels selbst und zum anderen der notwendige
Transport des RSA-Schlüssels die Gefahr einer Kompromittierung erhöhen.
12
5.2 Testergebnisse
5.2.1 Windows 2000 und XP nativ
Sowohl Windows 2000 als auch Windows XP unterstützen IPsec nativ.
Im Gegensatz zu Windows 2000 unterstützt Windows XP von Haus aus starke
Verschlüsselung. D.h. man kann mit Windows XP neben DES auch 3DES als Ver-
schlüsselungsalgorithmus in IKE und ESP einsetzen. Mit dem Windows 2000 Ser-
vice Pack 2 lässt sich starke Verschlüsselung für Windows 2000 nachrüsten. Das
sollte man unbedingt tun, denn DES ist für Lösungen, die Sicherheit gewährleisten
sollen, ungeeignet. Windows 2000 und XP unterstützen weiterhin die Hashalgo-
rithmen MD5, SHA-1, deren HMAC-Varianten sowie die Diffie-Hellman-Gruppen
1 und 2.
Leider existiert in Windows 2000 und XP keine Möglichkeit, RSA-Schlüssel und
Zertifizierungsanforderungen zu erstellen und diese in einer Datei zu speichern.
D.h. man muss entweder zusätzliche Software installieren oder die benötigten RSA-
Schlüssel und Zertifizierungsanforderungen auf einem anderen Rechner, der dazu
in der Lage ist, erstellen. Die letztere der beiden Varianten ist aus Gründen der Si-
cherheit nicht empfehlenswert (siehe 5.1, S. 11).
Windows 2000 und XP unterstützen neben pre-shared keys und RSA-Signatu-
ren auch Kerberos zur Authentifizierung in IKE [KN93, Bru98]. Das kann vor allem
in Windows-Netzen, in denen bereits Kerberos genutzt wird, viel Arbeit ersparen.
Leider ist die Authentifizierung per Kerberos innerhalb von IKE nicht öffentlich do-
kumentiert, geschweige denn standardisiert. Daher existiert neben der Implemen-
tation in Windows 2000 und XP keine weitere. In heterogenen Netzen ist das ganze
also unbrauchbar.
Die Konfiguration und Handhabung der in Windows 2000 und XP so genannten
IP-Sicherheitsrichtlinien kann entweder grafisch per Microsoft Management Console
(MMC) oder über die in den Standardinstallationen nicht vorhandenen Programme
ipsecpol für Windows 2000 bzw. ipseccmd für Windows XP in der Eingabeauf-
forderung geschehen.
Leider ist die Konfiguration an einigen Stellen missverständlich. So muss man
für eine Verbindung im Tunnel Mode zwei IP-Sicherheitsregeln anlegen, während es
13
bei der Konfiguration von Verbindungen im Transport Mode genügt, den zu der IP-
Sicherheitsregel gehörenden IP-Filter durch Aktivieren der Option „Diese Filterangabe
wird auch auf Pakete mit gegenteiliger Quell- und Zieladresse angewendet.“ zu spiegeln
(siehe E.1, S. 18).
Besonders unangenehm verläuft die Konfiguration über die MMC, denn das
Snap-In zur Verwaltung von IP-Sicherheitsrichtlinien ist sehr benutzerunfreundlich
geraten. Die Dialoge sind viel zu klein, so dass einige wichtige Informationen nicht
komplett angezeigt, sondern mit „...“ abgeschnitten werden. Zu allem Übel sind die
Dialoge auch nicht vergrößerbar. Das ist vor allem im Dialog zur Auswahl einer
bestimmten CA unangenehm (siehe E.1, S. 18). Weiterhin ist die Benutzerführung
mehr als mangelhaft. Das wird besonders beim Erstellen einer neuen Filteraktion
deutlich.
Glücklicher Weise kann man die einmal erstellten IP-Sicherheitsrichtlinien relativ
einfach exportieren und importieren. Damit kann man sich bei gleichartiger oder
ähnlicher Konfiguration mehrerer Rechner viel Arbeit sparen und sowohl Hand als
auch Maus schonen. Die IP-Sicherheitsrichtlinien lassen sich jedoch nicht ohne wei-
teres wiederverwenden, denn in der IP-Sicherheitsregel in Rückrichtung muss die
eigene IP-Adresse als Tunnelendpunkt angegeben werden (siehe E.1, S. 19. In ty-
pischen Remote-Access-Szenarien muss der Außendienstmitarbeiter daher, bevor
eine Verbindung zum VPN-Gateway aufgebaut werden kann, die eigene IP-Adres-
se heraus finden und an der richtigen Stelle eintragen. Für den durchschnittlichen
Außendienstmitarbeiter kann schon diese eigentlich triviale Aufgabe eine gewalti-
ge Hürde darstellen. Beschwerden wegen der Umständlichkeit sind jedenfalls zu
erwarten.
Aus diesem Grund und wegen der vielen Unannehmlichkeiten bei der Konfi-
guration hat Marcus Müller wohl sein auf ipsecpol bzw. ipseccmd basierendes
Windows 2000 VPN Tool geschrieben. Mit diesem ist es möglich, Microsofts IPsec-
Implementation über Konfigurationsdateien im Stil von FreeS/WAN (siehe 4.1, S.
8) zu konfigurieren. Das Windows 2000 VPN Tool übernimmt zudem die Aufgabe
des Herausfindens der eigenen IP-Adresse. Nähere Informationen finden sich unter
http://vpn.ebootis.de/ .
Transparente Einbindung von Roadwarriors ins VPN ist nur per L2TP [PPR+99,
14
PAD+01] realisierbar. Dabei wird ein L2TP-Tunnel über eine IPsec-Verbindung im
Transport Mode gefahren. Offenbar ist das auch die von Microsoft favorisierte Me-
thode zur Realisierung von Remote-Access-Szenarien, denn der übliche Weg über
IPsec im Tunnel Mode ist, im Gegensatz zur L2TP-Lösung, nahezu undokumentiert.
Der Einsatz von L2TP hat jedoch einige Nachteile: einen gewaltigen zusätzlichen
Overhead von 28 Byte pro Paket gegenüber einer Lösung mit IPsec im Tunnel Mode
und eine nicht zu unterschätzende Erhöhung des Administrationsaufwand auf dem
VPN-Gateway.
Leider findet bei Microsofts IPsec-Implementation keine Segmentierung zwi-
schen dem VPN und den übrigen Netzen, an die der Roadwarrior angeschlossen
ist, statt. Das sollte man händisch z.B. mit dem in Windows 2000 und XP integrier-
ten Paketfilter durchführen.
Microsofts IPsec-Implementation enthält, wenn auch nicht ganz offensichtlich,
die Möglichkeit zur Zertifikatsprüfung gegen CRLs. Diese ist per Default deakti-
viert. Zur Aktivierung muss man in der Registry unter HKLM\SYSTEM\Current-
ControlSet \Services \PolicyAgent \Oakley einen DWORD-Wert StrongCrl-
Check mit dem Wert 1 oder 2 anlegen. Nach der Modifikation der Registry müssen
die IPSEC-Dienste neu gestartet werden. Das kann entweder per MMC oder net
stop policyagent und anschließendem net start policyagent in der Ein-
gabeaufforderung geschehen.
Hat StrongCrlCheck den Wert 1, so schlägt die Zertifikatsprüfung nur dann fehl,
wenn die Überprüfung gegen eine CRL ergeben hat, dass das jeweilige Zertifikat
widerrufen wurde. Ist StrongCrlCheck auf 2 gesetzt, schlägt die Zertifikatsprüfung
auch dann fehl, wenn anderweitige Fehler aufgetreten sind, wenn z.B. keine CRL
bezogen werden konnte. In den Tests wurde StrongCrlCheck auf 2 gesetzt. Strong-
CrlCheck auf 1 scheidet im realen Einsatz aus Sicherheitsgründen aus, denn ein An-
greifer könnte die Zertifikatsprüfung gegen CRLs mit einem DoS-Angriff z.B. gegen
den Webserver, der die CRLs aufbewahrt, unterlaufen.
Die CRLs werden bei Bedarf an Hand der CRL-Distribution-Points-Extension be-
zogen und in einem Cache abgelegt. In den Tests verhielt sich die Zertifikatsprüfung
gegen CRLs zum großen Teil wie gewünscht. Negativ fällt nur auf, dass keine be-
sondere Benachrichtigung erfolgt, wenn die Überprüfung ergab, dass das Zertifikat
15
der der Gegenstelle widerrufen wurde.
Leider kann man in den IP-Sicherheitsrichtlinien keine Kriterien für das X.509-
Zertifikat der Gegenstelle, wie z.B. ein bestimmtes Subject oder einen bestimmten
Subject Alternative Name, definieren. Zudem müssen die verwendeten Zertifika-
te von eben der CA signiert sein, die auch das Zertifikat der Gegenstelle signierte.
Das birgt in typischen Remote-Access-Szenarien eine gewisse Gefahr. Ein Angrei-
fer, der im Besitz eines von der betreffenden CA signierten Zertifikats und dem
entsprechenden RSA-Schlüssel ist, sei es, weil er einer der Roadwarriors ist oder
weil er einen Roadwarrior kompromittiert hat, kann dem Opfer damit vorspielen,
das VPN-Gateway zu sein. Dadurch eröffnen sich in einigen Szenarien Möglich-
keiten für einen MITM-Angriff. Das Opfer kann diesen Angriff im übrigen bemer-
ken, indem es die Logs liest. Logging ist jedoch per Default deaktiviert. Zur Akti-
vierung muss unterhalb von HKLM\SYSTEM\CurrentControlSet \Services \-
PolicyAgent \Oakley ein DWORD-Wert namens EnableLogging mit dem Wert 1
angelegt werden. Nach dem Neustart der IPSEC-Dienste finden sich die Logs in
%SystemRoot%\Debug\Oakley.log .
Microsofts IPsec-Implementation ist für einige Szenarien durchaus brauchbar,
weist jedoch Mängel auf die den Einsatz in Remote-Access-Szenarien in Frage stel-
len. Aus finanzieller Sicht ist Microsofts IPsec-Implementation bei einer bereits be-
stehenden Installation von Windows 2000 oder XP natürlich sehr vorteilhaft.
5.2.2 SSH Sentinel
Seit geraumer Zeit beschäftigt man sich bei SSH auch mit IPsec. Eines der Ergebnisse
ist SSH Sentinel, eine IPsec-Lösung für Windows, die sich besonders gut für Remote-
Access-Szenarien eignen soll.
SSH Sentinel wird im SSH Online Store für 139,–e bzw. 125,–$ angeboten. Be-
wohner der EU zahlen 169,58e bzw. 152,50$ inklusive 22% Steuern. SSH Sentinel
war zum Zeitpunkt des Tests für nicht kommerzielle Anwendungen und innerhalb
von 30 Tagen zu Evaluationszwecken frei erhältlich.
Einige Firmen lizenzieren SSH Sentinel und verkaufen eigene Lösungen, die auf
SSH Sentinel basieren, wobei meist nur das Logo geändert wird, als Gegenstücke
zu ihren VPN-Gateways. Besonders erwähnenswert ist meiner Ansicht nach, dass
16
BorderWare, deren alter VPN Client auf SoftRemote (siehe 5.2.3, S. 19) basierte, nun
auf SSH Sentinel setzt.
Die Installation von SSH Sentinel verläuft geradlinig und geht relativ schnell
vonstatten. Schon während des Installationsvorgangs wird ein RSA-Schlüssel gene-
riert. Zu diesem kann man per SCEP [LMMN02] oder CMP [AF99] ein X.509-Zerti-
fikat anfordern, eine Zertifikatsanforderung erstellen, die zur späteren Verwendung
in eine Datei gespeichert wird, oder ein selbst signiertes Zertifikat generieren. Das
ist sehr zu begrüßen, denn somit werden die Gefahren, die das Erstellen des RSA-
Schlüssels auf einem anderen Rechner mit sich bringt (siehe 5.1, S. 11), umgangen.
Konfiguriert wird SSH Sentinel über den Policy Editor. Dieser besteht aus zwei
Teilen: Security Policy und Key Management. Im Key Management können sowohl die
zur Authentifizierung benutzten pre-shared keys, RSA-Schlüssel und die zugehö-
rigen X.509-Zertifikate als auch X.509-Zertifikate von Policy Servern, CAs und an-
deren Rechnern verwaltet werden. Weiterhin kann man im Key Management LDAP-
Directories spezifizieren, aus denen bei bei Bedarf CRLs zur Zertifikatsprüfung be-
zogen werden.
Security Policy besteht aus einer Liste von Regeln, die der Reihe nach von oben
nach unten abgearbeitet werden. Über die Regeln Pre-IPSec Filter und Post-IPSec Fil-
ter kann man den in SSH Sentinel integrierten Paketfilter konfigurieren, der Pakete
sowohl vor als auch nach der Anwendung von IPsec filtert. Mit den Regeln VPN
Connections, Secured Connections und Secured Networks kann man auf einfache, na-
hezu intuitive Weise SSH Sentinel für das jeweils passende Szenario konfigurieren.
Für eine normale Roadwarrior-Konfiguration reicht es oft, den DNS-Namen oder
die IP-Adresse des VPN-Gateways anzugeben, das Netz hinter dem VPN-Gateway
zu spezifizieren und einen pre-shared key bzw. ein X.509-Zertifikat auszuwählen.
Das Exportieren von Policies ist in SSH Sentinel nur auf eine meines Erach-
tens sehr unkomfortable Weise möglich. Dazu aktiviert man in den Policy Properties
der zu exportierenden Policy unter Sharing die Option Shared. Von nun an ist die
entsprechende Policy in SPSL [CLZ00] unterhalb des Verzeichnis Programme \SSH
Communications Security \SSH Sentinel \shares zu finden. Das Importie-
ren gestaltet sich wesentlich bequemer. Über Add... in Security Policy kann man Po-
licies aus Dateien importieren oder von einem vertrauenswürdigen Policy-Server
17
beziehen.
Neben der einfachen Konfiguration und Bedienung besticht SSH Sentinel durch
Flexibilität: SSH Sentinel unterstützt nicht nur DES und 3DES, sondern auch die
Verschlüsselungsalgorithmen AES, Blowfish, CAST und Twofish [SKW+98], wei-
terhin die Hashalgorithmen MD5, SHA-1, deren HMAC-Varianten und die Diffie-
Hellman-Gruppen 1, 2 und 5. Derart flexibel war keine andere kommerzielle IPsec-
Implementation im Test.
Die enorme Flexibilität hatte leider lange Zeit zwangsläufig Jumbo-Proposals, in
denen alle möglichen Kombinationen angeboten werden, zur Folge, wenn nicht das
proposal template legacy, das jedoch nur DES und 3DES beinhaltet, gewählt wurde. In
SSH Sentinel 1.3.1 wurde auf Anfrage vieler Nutzer die Option Attach only selected
values to the proposal eingeführt, die dafür sorgen soll, dass nur die jeweils ausge-
wählten Werte angeboten werden. In den Test hat sich jedoch gezeigt, dass sich das
Aktivieren dieser Option nur auf Proposals in Phase 1 auswirkt. Die Quick-Mode-
Proposals behielten ihren immensen Umfangen. Schade ist, dass SSH nicht in der
Lage war diesen Bug, den ich schon in Version 1.3.1 fand und darauf hin berichtete,
in SSH Sentinel 1.3.2 zu fixen.
Ein besonderes Feature in SSH Sentinel ist NAT-T [HSS+02, KHSV02]. NAT-T
löst die Probleme, die bei der Kombination von IPsec und NAT auftreten. Damit
ist es für Remote-Access-Szenarien besonders interessant, da Einsatz von NAT z.B.
bei der Anbindung von Heim-LANs ans Internet immer beliebter wird, NAT jedoch
fast immer „tödlich“ für IPsec ist.
SSH Sentinel ermöglicht die transparente Integration von Roadwarriors mittels
IKE Mode Config (SET/ACK), DHCP over IPsec, L2TP und händischer Konfigura-
tion. Besonders IKE Mode Config und DHCP over IPsec sind hier interessant, da
sie, anders als L2TP, keinen gewaltigen zusätzlichen Overhead pro Paket, sondern
nur einen akzeptablen Overhead währen des IKE erzeugen und, im Gegensatz zur
händischen Konfiguration, gut skalieren. Entscheidet man sich für den Einsatz von
L2TP, sollte man unbedingt SSH Sentinel 1.3.2 benutzen, denn in 1.3.1 existiert ein
Sicherheitsproblem im L2TP Session Handshake.
Konfiguriert man zuerst die Proposals und später die transparente Integration
des Roadwarriors, werden die zuvor gewählten Verschlüsselungsalgorithmen in
18
den Proposals auf den Default-Algorithmus AES gesetzt. Das kann unter Umstän-
den zu dem unangenehmen Effekt führen, dass trotz scheinbar korrekter Konfigu-
ration der Aufbau einer Verbindung zum VPN-Gateway misslingt. Leider gelang es
auch hier SSH nicht, den in Version 1.3.1 entdeckten Bug in 1.3.2 zu fixen.
Einen Pluspunkt kann SSH Sentinel durch seine erweiterten Möglichkeiten zur
Zertifikatsprüfung erzielen. Diese aktiviert man über die Option Issues certificate
revocation list (CRL) in den Certificate Properties des CA-Zertifikat. Weiterer Konfi-
gurationsaufwand ist nur notwendig, wenn die CRLs aus einem LDAP-Directo-
ry geholt werden sollen. Andernfalls, wird aus der CRL-Distribution-Points- und
der Authority-Information-Access-Extension des X.509-Zertifikats des VPN-Gate-
way die nötige Information zum Beziehen der CRL bzw. zur Abfrage des OCSP-
Responders extrahiert.
In den Tests stellte sich heraus, dass sowohl in SSH Sentinel 1.3.1 als auch in 1.3.2
der angepriesene OCSP-Support fehlt. Auf meine Anfrage teilte mir Timo Ihalem-
pia von SSH mit, dass der OCSP-Support in 1.3.2 und in früheren Versionen entfernt
werden musste, da Probleme mit der Unterstützung der Authority-Information-
Access-Extension auftraten. SSH versucht das so schnell wie möglich zu beseitigen.
In SSH Sentinel 1.4, das voraussichtlich im Oktober 2002 veröffentlicht wird, kann
man dann wohl wieder auf OCSP-Support hoffen.
Die Zertifikatsprüfung gegen CRLs, egal ob diese per HTTP an Hand der CRL-
Distribution-Points-Extension oder LDAP bezogen wurden, funktionierte in allen
Tests korrekt. Allerdings wird der Benutzer nicht mit einer gesonderten Nachricht
informiert, falls das Zertifikat der Gegenstelle widerrufen wurde, sondern nur mit
der Standard-Fehlermeldung „Cannot open the VPN connection. Check that the gateway
is online and verify that you are using the correct authentication key.“ abgespeist, die in
keiner Weise auf die außerordentliche Situation hinweist. Auch die Logs sagen nicht
klar aus, dass die Prüfung gegen die entsprechende CRL ergab, dass das Zertifikat
der Gegenstelle widerrufen wurde.
Per Default führt SSH Sentinel keine Segmentierung zwischen VPN und den üb-
rigen Netzen, mit denen der Roadwarrior verbunden ist, durch. Das lässt sich aller-
dings relativ bequem ändern, indem man in Security Policy unter Default Response die
Regel Allow unprotected traffic über Properties... in Deny unprotected IP traffic ändert.
19
Allerdings führt das dazu, dass auch, wenn keine Verbindung zum VPN-Gateway
besteht, sämtlicher nicht VPN-relevanter Traffic geblockt wird. Daher sollte man in
dieser Einstellung den Policy Manager nur dann starten, wenn er wirklich benötigt
wird.
Die von SSH Sentinel generierten Cookies sind sehr auffällig. Bei allen von SSH
Sentinel in den Test generierten Cookies schienen nur die 40 hochwertigsten Bits
„zufällig“. Die restlichen 24 Bits waren offenbar ein Counter, der beim Starten des
Policy Manager auf 0 zurückgesetzt wird. Wie mir Timo Ihalempia später berichtete,
handelt es sich bei den ersten 40 Bits um einen MAC aus den Quell- und Ziel-IP-
Adressen und UDP-Ports, der vor DoS-Attacken schützen soll. Die letzten 24 Bits
sind in der Tat ein Counter, der die Einzigartigkeit der Cookies garantieren soll.
Auch in SSH Sentinel lassen sich keine Kriterien für das X.509-Zertifikat der Ge-
genstelle definieren. Damit ist das gegen Windows 2000 und XP mögliche Angriffss-
zenario (siehe 5.2.1, S. 15) auch gegen SSH Sentinel denkbar. Das Opfer kann den
Angriff entdecken, indem es die Logs liest. In der Regel interessieren sich Außen-
dienstmitarbeiter jedoch nicht für Logs. Timo Ihalempia hat weniger als 12 Stunden,
nachdem ich ihn über das Problem informiert habe, das Development Team benach-
richtigt. Auf eine baldige Besserung ist also zu hoffen.
Alles in allem ist SSH Sentinel eine viel versprechende Lösung. SSH Sentinel
überzeugt durch seine einfache Konfiguration, den gewaltigen Funktionsumfang
und einzigartige Flexibilität. Leider wird dieses Bild von einigen unschönen Bugs
und Problemen getrübt. Mit der Version 1.4 kann man allerdings auf Besserung hof-
fen.
5.2.3 SoftRemote
SoftRemote ist eine IPsec-Lösung für VPN-Clients von SafeNet. Eine Einzellizenz
der aktuellen Version 8.0 kann man für 149,–$ direkt bei SafeNet oder für 179,–e
bei DeltaCom erwerben. SafeNet ermöglicht potentiellen Kunden, innerhalb eines
Evaluationsprogramm SoftRemote zu testen.
SoftRemote selbst wird mit der fragwürdigen Personal Firewall ZoneAlarm aus-
geliefert. Diese wurde während des Test deaktiviert, da sie ein vernünftiges Arbei-
ten am Testsystem unmöglich machte. Wer ZoneAlarm nicht mag, kann alternativ
20
SoftRemote LT erwerben. Dieses entspricht SoftRemote, beinhaltet ZoneAlarm je-
doch nicht. Der Preis ist mit dem vom SoftRemote identisch.
Nach Aussagen von SafeNet ist SoftRemote die momentan am weitesten verbrei-
tete IPsec-Lösung für Remote-Access-Szenarien. Das mag wohl auch daran liegen,
dass nahezu alle Anbieter von IPsec-fähigem Equipment, u.a. Cisco, Nokia und Lu-
cent, SoftRemote lizenziert haben und als Clients für ihre Lösungen anbieten, so z.B.
Cisco den Cisco Secure VPN Client.
Das Erstellen der Security Policies mit dem Security Policy Editor verläuft leider
nicht ganz so spielend einfach wie bei SSH Sentinel. Das liegt daran, dass man die
Policies zwar wie bei SSH Sentinel sehr genau konfigurieren kann, der Do-What-I-
Mean-Modus jedoch fehlt.
Das sollte allerdings keine allzu große Hürde darstellen, da man in der Regel
nur eine Policy erstellt und diese mehrfach wiederverwendet. Als Alternative zum
händischen Import besteht auch die Möglichkeit, die Policies per LDAP von einem
zentralen Policy Server zu holen.
Wie SSH Sentinel bietet SoftRemote die Möglichkeit, RSA-Schlüssel zu erstellen.
Damit kann man entweder direkt per SCEP ein Zertifikat von der CA anfordern
oder die Zertifikatsanforderungen in einer Datei speichern und mit dieser weiter
verfahren. Sind RSA-Schlüssel und X.509-Zertifikat schon vorhanden, kann man
diese z.B. aus einem PKCS#12-Bundle importieren. Dabei wird allerdings das ge-
gebenenfalls enthaltene CA-Zertifikat einfach übergangen, so dass man dieses ge-
sondert importieren muss (siehe E.3, S. 21).
Die Zertifikate können im Windows-Zertifikatsspeicher abgelegt werden, somit
kann man diese gegebenenfalls für andere Zwecke wiederverwenden. Bei der In-
stallation legt SoftRemote im Windows-Zertifikatsspeicher die Verzeichnisse IreMY,
IreOTHER, IrePeer, IreREQUEST, IreSIGNER und OTHER an. Diese werden aller-
dings nicht verwendet, statt dessen speichert SoftRemote die Zertifikate nach Ei-
gene Zertifikate und Vertrauenswürdige Stammzertifizierungsstellen. Zertifikate, die be-
reits im Windows-Zertifikatsspeicher liegen, kann man natürlich auch in SoftRemo-
te weiter benutzen.
SoftRemote kann bei der Zertifikatsprüfung auch CRLs heran ziehen. Dazu ist
es seltsamer Weise zunächst notwendig, die Trust Policy im Certificate Manager auf
21
„Trust all CAs installed on this computer.“ zu ändern. In der Standardeinstellung funk-
tionierte die Zertifikatsprüfung gegen CRLs nicht, denn SoftRemote war scheinbar
nicht in der Lage, die CRL der passenden CA zuzuordnen. Wählt man die Einstel-
lung „Trust all CAs installed on this computer.“, sollte man unbedingt alle ungenutzten
CA-Zertifikate entfernen. Denn sonst vertraut man vielen CAs, deren Zertifikate,
warum auch immer, installiert sind, auch in Sachen IPsec, obgleich man das nicht
will. Außerdem versendet SoftRemote sonst raue Mengen an Zertifikatsanforderun-
gen.
CRLs kann man händisch im Certificate Manager unter CRLs aus einer Datei im-
portieren oder an Hand der CRL-Distribution-Points-Extension holen lassen. Alle
vier Stunden holt SoftRemote alle CRLs, die an Hand der CRL-Distribution-Points-
Extension der installierten Zertifikate geholt werden können. Alternativ dazu kann
man die CRLs in definierbaren regelmäßigen Abständen via LDAP holen lassen. Die
CRLs werden dann im Windows-Zertifikatsspeicher abgelegt. Inwiefern das Holen
in regelmäßigen Intervallen sinnvoll ist, sei dahin gestellt.
Die Zertifikatsprüfung gegen CRLs ist leider fehlerhaft: Abgelaufene CRLs wer-
den ebenso wie aktuelle CRLs behandelt. Ein Angreifer könnte ein Zertifikat kom-
promittieren und seinem Opfer vorgaukeln, das Zertifikat sei gültig, obwohl die
CA in ihrer aktuellen CRL vermerkt hat, dass dieses widerrufen wurde, indem er
ihm eine alte CRL, in der die Seriennummer des kompromittierten Zertifikats nicht
enthalten ist, unterschiebt.
Ansonsten funktioniert die Zertifikatsprüfung gegen CRLs wie gewünscht. Al-
lerdings warnt auch SoftRemote nicht offensichtlich mit einer Nachricht, die diese
außerordentlich Situation verdeutlicht. Genauere Auskunft über das Scheitern ge-
ben die Logs. In diese wird im Fall eines widerrufenen Zertifikats die Nachricht
Certificate verification failed: Certificate is revoked geschrieben.
Auch SoftRemote ermöglicht die transparente Integration der Roadwarrior ins
VPN. Das kann entweder per L2TP oder IKE Mode Config (SET/ACK), getarnt un-
ter dem Namen Virtual Adapter, von statten gehen. Weiterhin unterstützt SoftRemote
wie auch SSH Sentinel NAT-T.
SoftRemote führt standardmäßig keine Segmentierung zwischen VPN und den
übrigen Netzen durch. Abhilfe schafft, Connection Security unter Other Connections
22
von Non-secure auf Block zu setzen. Man sollte die Policy dann allerdings nur ak-
tivieren, wenn man eine Verbindung zum VPN-Gateway will, da auch sonst nicht
VPN-relevanter Traffic geblockt wird.
SoftRemote war die einzige IPsec-Lösung im Test, bei der es möglich war, Kri-
terien für das X.509-Zertifikat der Gegenstelle zu definieren. Der gegen Windows
2000, XP und SSH Sentinel mögliche Angriff ist hier also ausgeschlossen.
SoftRemote ist eine brauchbare IPsec-Lösung. An der Grundfunktionalität ist
nichts auszusetzen. Leider ist die Umsetzung der Zertifikatsprüfung gegen CRLs
überhaupt nicht zufrieden stellend.
5.2.4 PGPnet
PGPnet fällt im Hinblick auf die bisher getesteten Lösungen etwas aus der Reihe,
denn PGPnet ist momentan nicht mehr erhältlich. Zudem läuft PGPnet nicht auf
Windows XP. Getestet wurden die Versionen 7.1 und 7.1.1, die ehemals für 63,–$
erworben werden konnten.
Die Installation geht relativ schnell von statten. Während der Installation kann
ein PGP-Schlüssel-Paar zur späteren Verwendung, auch für IPsec, erzeugt werden.
Die Konfiguration verläuft ebenfalls relativ einfach. An vielen Stellen hilft, wenn
gewünscht, ein Wizard.
Mit PGPnet ist es möglich, Roadwarriors per IKE Mode Config transparent ins
VPN zu integrieren. Dazu muss die Option Acquire virtual identity aktiviert werden.
Aktiviert man zudem Exclusive gateway, findet eine Segmentierung zwischen dem
VPN und den übrigen Netzen, mit denen der Roadwarrior verbunden ist, statt.
Mit PGPnet ist es zwar möglich, Signaturen in Verbindung mit X.509-Zertifikaten
zur Authentifizierung einzusetzen, die Umsetzung lässt jedoch sehr zu wünschen
übrig. PGPnet 7.1.1 prüft ausschließlich, ob die Signatur in Phase 1 zu dem explizit
konfigurierten Zertifikat der Gegenstelle passt. Ob dieses Zertifikat von der aus-
gewählten CA signiert wurde oder ob es vielleicht sogar selbst signiert ist, scheint
egal zu sein. In den Tests jedenfalls lief der IKE immer sauber durch, auch wenn kein
oder ein beliebiges Zertifikat für die CA gewählt wurde. Das Zertifikat der Gegen-
stelle muss auch nicht als vertrauenswürdig eingestuft sein. Außerdem wird nur ge-
prüft, ob das Zertifikat der Gegenstelle noch gültig ist, nicht aber, ob es schon gültig
23
ist. Durch diese seltsame Umsetzung der Authentifizierung mit Signaturen in Ver-
bindung mit X.509-Zertifikaten ist PGPnet 7.1.1 zwar nicht für das gegen Windows
2000, XP und SSH Sentinel mögliche Angriffsszenario (siehe 5.2.1, S. 15) anfällig, der
Sinn des Einsatz von X.509-Zertifikaten wird jedoch komplett untergraben.
Die Umsetzung der Authentifizierung mit Signaturen in Verbindung mit X.509-
Zertifikaten in PGPnet 7.1 ist noch um einiges schlimmer. Wenn die Gegenstelle
einen beliebigen RSA-Schlüssel, dessen Länge von der im Zertifikat vermerkten ab-
weicht, verwendet und das Zertifikat der eigentlichen Gegenstelle überträgt, führt
PGPnet die Authentifizierung fehlerhaft durch und hält die Gegenstelle für die wah-
re. Ein Angreifer müsste also ausschließlich an das Zertifikat des VPN-Gateways
gelangen, um VPN-Clients vorzuspielen er sei dieses.
Die Authentifizierung mit Signaturen in Verbindung mit X.509-Zertifikaten ist
meines Erachtens absolut unbrauchbar. Da diese Form der Authentifizierung in
mittleren bis großen Anwendungsszenarien unumgänglich ist, fällt auch das Ur-
teil für PGPnet ähnlich aus: unbrauchbar. Insofern stellt es auch keinen wirklichen
Verlust dar, dass PGPnet momentan nicht verfügbar ist.
5.3 Fazit
Es ist zunächst erfreulich festzustellen, dass sich alle getesteten Lösungen als inter-
operabel herausgestellt haben ohne das Verrenkungen in irgendeiner Form bei der
Konfiguration des VPN-Gateways nötig gewesen wären.
Bis auf PGPnet, das auf Grund grober Mängel ausscheidet, sind alle Lösungen
als durchaus brauchbar einzustufen. Vom Standpunkt der Sicherheit gibt es leider
keine Lösung, die alle Kriterien komplett erfüllt. Windows 2000, XP und SSH Senti-
nel sind auf Grund der mangelnden Möglichkeiten zur Spezifikation des Zertifikats
der Gegenstelle problematisch. Bei SoftRemote ist die Implementation der Zertifi-
katsprüfung gegen CRLs leider misslungen.
Man muss also abwägen: Möchte man Zertifikatsprüfung gegen CRLs, scheidet
SoftRemote aus, andernfalls ist es meines Erachtens die erste Wahl. Hält man den
Aufwand für die Angriffe gegen Windows 2000, XP und SSH Sentinel für unverhält-
nismäßig gegenüber dem Wert der betroffenen Daten, spricht natürlich auch nichts
24
gegen den Einsatz dieser Lösungen.
Wenn es auf Funktionalität und Flexibilität ankommt, hat SSH Sentinel eindeutig
die Nase vorn. In diesem Punkt eine Rangordnung zwischen SoftRemote und Win-
dows 2000 bzw. XP aufzustellen fällt schwer, denn sie ist stark von den jeweiligen
Anforderungen abhängig. Gewichtet man Features wie IKE Mode Config oder NAT-
T stärker als die Zertifikatsprüfung gegen CRLs, so landet SoftRemote vor Windows
2000 und XP. Bei einer bereits bestehenden Installation von Windows 2000 oder XP
sollte man abwägen, ob ein Mehr an Funktionalität und Flexibilität die zusätzlich
entstehenden Kosten rechtfertigt.
6 Ausblick
Es hat sich gezeigt, dass es schon jetzt möglich ist IPsec sinnvoll einzusetzen. In eini-
gen Bereichen wie der Realisierung von VPNs oder der Sicherung von WaveLANs
erfreut sich IPsec bereits großer Beliebtheit. Von einem großflächigen IPsec-Einsatz
kann allerdings noch überhaupt keine Rede sein.
Ein Mangel an IPsec-Implementierung kann nicht der Grund sein. Es liegt wohl
eher an der mangelnden Sensibilität in Sachen Sicherheit und an der schon mehrfach
kritisierten Komplexität des Protokolls [FS99]. Besonders negativ fällt IKE auf. Die
in vielen Punkten überlegene Alternative Photuris [KS99b, KS99a] konnte sich bis-
her in Ermangelung von Implementierungen neben der in OpenBSD nicht wirklich
durchsetzen. IKEv2 [HKK+02], eine überarbeitete und in vielen Punkten verbesser-
te, d.h. vor allem vereinfachte, Version von IKE, ist momentan in Arbeit und könnte
eine Verbesserung auf diesem Gebiet bedeuten.
Einer weiteren Verbreitung von IPsec stünden dann noch die Probleme einer
einer großflächigen Zertifikatsstruktur im Weg. Doch das wäre ein Thema für eine
andere Seminarfacharbeit.
1
A Literatur
[Ada97] ADAMS, CARLISLE: The CAST-128 Encryption Algorithm. Request forComments 2144, Internet Engineering Task Force, Mai 1997.
[AF99] ADAMS, CARLISLE und STEPHEN FARRELL: Internet X.509 Public KeyInfrastructure Certificate Management Protocols. Request for Comments2510, Internet Engineering Task Force, März 1999.
[BHR99] BOEYEN, SHARON, TIM HOWES und PATRICK RICHARD: Internet X.509Public Key Infrastructure LDAPv2 Schema. Request for Comments 2587,Internet Engineering Task Force, Juni 1999.
[Bru98] BRUNDRETT, PETER: Kerberos authentication in Windows NT 5.0 domains.;login, Mai 1998.
[CLZ00] CONDELL, M., C. LYNN und J. ZAO.: Security Policy SpecificationLanguage. Internet Draft, IETF, 10. März 2000.
[DBP96] DOBBERTIN, H., A. BOSSELAERS und B. PRENEEL: RIPEMD-160: Astrengthened version of RIPEMD. In: Proceedings of the 3rd InternationalWorkshop on Fast Software Encryption, Seiten 71–82, New York, NY, 1996.Springer-Verlag.
[DH76] DIFFIE, WHITFIELD und MARTIN E. HELLMAN: New Directions inCryptography. IEEE Transactions on Information Theory,IT-22(6):644–654, November 1976.
[DH98] DEERING, STEPHEN E. und ROBERT M. HINDEN: Internet Protocol,Version 6 (IPv6) Specification. Request for Comments 2460, InternetEngineering Task Force, Dezember 1998.
[EFF98] EFF (Herausgeber): Cracking DES: Secrets of Encryption Research,Wiretap Politics & Chip Design. O’Reilly, Juli 1998.
[FS99] FERGUSON, NIELS und BRUCE SCHNEIER: A Cryptographic Evaluationof IPsec, Februar 1999.
[HC98] HARKINS, DAN und DAVE CARREL: The Internet Key Exchange (IKE).Request for Comments 2409, Internet Engineering Task Force,November 1998.
[HFPS99] HOUSLEY, RUSSELL, WARWICK FORD, TIM POLK und DAVID SOLO:Internet X.509 Public Key Infrastructure Certificate and CRL Profile.Request for Comments 2459, Internet Engineering Task Force, Januar1999.
[HKK+02] HARKINS, DAN, CHARLIE KAUFMAN, STEVE KENT, TERO KIVINENund RADIA PERLMAN: Proposal for the IKEv2 Protocol. Internet Draft,Internet Engineering Task Force, April 2002.
2
[HSS+02] HUTTUNEN, A., B. SWANDER, M. STENBERG, V. VOLPE undL. DIBURRO: UDP Encapsulation of IPsec Packets. Internet Draft,Internet Engineering Task Force, Juni 2002.
[KA98a] KENT, STEPHEN und RANDALL ATKINSON: IP Authentication Header.Request for Comments 2402, Internet Engineering Task Force,November 1998.
[KA98b] KENT, STEPHEN und RANDALL ATKINSON: IP Encapsulating SecurityPayload (ESP). Request for Comments 2406, Internet Engineering TaskForce, November 1998.
[KA98c] KENT, STEPHEN und RANDALL ATKINSON: Security Architecture for theInternet Protocol. Request for Comments 2401, Internet EngineeringTask Force, November 1998.
[KBC97] KRAWCZYK, HUGO, MIHIR BELLARE und RAN CANETTI: HMAC:Keyed-Hashing for Message Authentication. Request for Comments 2104,Internet Engineering Task Force, Februar 1997.
[KHSV02] KIVINEN, T., A. HUTTUNEN, B. SWANDER und V. VOLPE: Negotiationof NAT-Traversal in the IKE. Internet Draft, Internet Engineering TaskForce IPsec Working Group, 24. Juni 2002.
[KN93] KOHL, JOHN und B. CLIFFORD NEUMAN: The Kerberos NetworkAuthentication Service (V5). Request for Comments 1510, InternetEngineering Task Force, September 1993.
[Kra96] KRAWCZYK, H.: SKEME: A Versatile Secure Key Exchange mechanism forInternet. In: IEEE Proceedings of the 1996 Symposium on Network andDistributed Systems Security, 1996.
[KS99a] KARN, PHIL und WILLIAM ALLEN SIMPSON: Photuris: ExtendedSchemes and Attribute. Request for Comments 2523, InternetEngineering Task Force, März 1999.
[KS99b] KARN, PHIL und WILLIAM ALLEN SIMPSON: Photuris: Session-KeyManagement Protocol. Request for Comments 2522, InternetEngineering Task Force, März 1999.
[LMMN02] LIU, XIAOYI, CHERYL MADSON, DAVID MCGREW und ANDREWNOURSE: Cisco Systems’ Simple Certificate Enrollment Protocol(SCEP).Internet Draft, Internet Engineering Task Force, 15. Mai 2002.
[MAM+99] MYERS, MICHAEL, RICH ANKNEY, AMBARISH MALPANI, SLAVAGALPERIN und CARLISLE ADAMS: X.509 Internet Public KeyInfrastructure Online Certificate Status Protocol - OCSP. Request forComments, Internet Engineering Task Force, Juni 1999.
[MSST98] MAUGHAN, DOUGLAS, MARK SCHERTLER, MARTIN SCHNEIDER undJEFF TURNER: Internet Security Association and Key Management Protocol(ISAKMP). Request for Comments 2408, Internet Engineering TaskForce, November 1998.
3
[NBS88] NBS: Data Encryption Standard (DES). Federal Information ProcessingStandards Publications 46-2, National Bureau of Standards, 22. Januar1988.
[NIS94] NIST: Digital Signature Standard (DSS). Federal Information ProcessingStandards Publications 186, National Institute of Standards andTechnology, 19. May 1994.
[NIS95] NIST: Secure Hash Standard. Federal Information Processing StandardsPublications 180-1, National Institute of Standards and Technology,17. April 1995.
[NIS01] NIST: Advanced Encryption Standard (AES). Federal InformationProcessing Standards Publications 197, National Institute of Standardsand Technology, 26. November 2001.
[Orm98] ORMAN, HILARIE K.: The OAKLEY Key Determination Protocol. Requestfor Comments 2412, Internet Engineering Task Force, November 1998.
[PAD+01] PATEL, BAIJU V., BERNARD ABOBA, WILLIAM DIXON, GLEN ZORNund SKIP BOOTH: Securing L2TP using IPsec. Request for Comments3193, Internet Engineering Task Force, November 2001.
[PAKG01] PATEL, BAIJU, BERNARD ABOBA, SCOTT KELLY und VIPUL GUPTA:DHCPv4 Configuration of IPsec Tunnel Mode. Internet Draft, IETF, Juni2001.
[PAP99] PEREIRA, R., S. ANAND und B. PATEL: The ISAKMP ConfigurationMethod. Internet Draft, Internet Engineering Task Force IPsec WorkingGroup, 17. August 1999.
[Pip98] PIPER, DERRELL: The Internet IP Security Domain of Interpretation forISAKMP. Request for Comments 2407, Internet Engineering TaskForce, November 1998.
[Pos81] POSTEL, JON: Internet Protocol. Request for Comments 791, InternetEngineering Task Force, September 1981.
[PPR+99] PALL, GURDEEP SINGH, BILL PALTER, ALLAN RUBENS, W. MARKTOWNSLEY, ANDREW J. VALENCIA und GLEN ZORN: Layer TwoTunneling Protocol „L2TP“. Request for Comments 2661, InternetEngineering Task Force, August 1999.
[Riv92] RIVEST, RONALD L.: The MD5 Message-Digest Algorithm. Request forComments 1321, Internet Engineering Task Force, April 1992.
[RRS02] RICHARDSON, MICHAEL C., D. HUGH REDELMEIER und HENRYSPENCER: A method for doing opportunistic encryption with The InternetKey Exchange (IKE), April 2002.
[Sch93] SCHNEIER, BRUCE: Description of a New Variable-Length Key, 64-BitBlocko Cipher (Blowfish). In: Fast Software Encryption, Cambridge SecurityWorkshop Proceedings, Seiten 191–204. Springer-Verlag, Dezember 1993.
4
[Sim99] SIMPSON, WILLIAM ALLEN: IKE/ISAKMP considered harmful. ;login,Dezember 1999.
[SKW+98] SCHNEIER, BRUCE, J. KELSEY, D. WHITING, DAVID WAGNER undNIELS FERGUSON: Twofish: A 128-Bit Block Cipher, 15. Juni 1998.
[SR02] SPENCER, HENRY und D. HUGH REDELMEIER: IKE ImplementationIssues. Internet Draft, Network Working Group, 26. Februar 2002.
[WHK97] WAHL, MARK, TIM HOWES und STEVE KILLE: Lightweight DirectoryAccess Protocol (v3). Request for Comments 2251, Internet EngineeringTask Force, Dezember 1997.
5
B Glossar
CA Certification Authority Eine CA ist eine Zertifizierungsstelle, die digitale Zertifi-kate ausstellt und verwaltet.
CRL Certificate Revocation List Eine CRL ist eine Liste, in der die von der CA wider-rufenen X.509-Zertifikaten mit ihrer Seriennummer vermerkt sind.
DHCP Dynamic Host Configuration Protokoll DHCP ist ein Protokoll, das die dyna-mischen Konfiguration von Rechnern in einem Netzwerk ermöglicht. Dabeiwerden verschiedene Parameter wie IP-Adressen und DNS-Server zugewie-sen.
Diffie-Hellman Diffie-Hellman war der erste patentierte Public-Key-Algorithmus.Er beruht auf dem Problem der Berechnung diskreter Logarithmen.
DoS Denial of Service Ein DoS-Angriff zielt darauf ab, legitimen Nutzern einen be-stimmten Dienst vorzuenthalten.
HMAC Keyed-Hash Message Authentication Code HMACs werden zur Überprüfungvon Integrität und Authentizität eingesetzt.
Hashalgorithmus Ein Hashalgorithmus berechnet zu einem String variabler Längeeinen Wert fest definierter Länge.
LDAP Lightweight Directory Access Protocol LDAP ist ein Protokoll für den lesendenund schreibenden Zugriff auf Verzeichnis-Dienste.
MITM Man-in-the-Middle Bei einem Man-in-the-Middle-Angriff gibt sich der An-greifer jeweils als der Gegenüber der beiden Kommunikationspartner aus. Beider Weiterleitung der Daten hat der Angreifer die Möglichkeit, diese mitzu-schneiden und zu modifizieren.
MTU Maximum Transfer Unit Die MTU ist die obere Grenze für die Größe von IP-Pa-keten für ein bestimmtes Interface. Überschreitet ein IP-Paket die MTU, wirdes fragmentiert.
NAT Network Address Translation NAT bezeichnet das Umschreiben von IP-Adres-sen in IP-Paketen.
OCSP Online Certificate Status Protocol OCSP ist ein Protokoll zur Bestimmung desStatus eines X.509-Zertifikats.
RSA Rivest-Shamir-Adleman RSA ist ein Public-Key-Algorithmus, mit dem man ver-schlüsseln und digital signieren kann. Die Sicherheit von RSA beruht auf derSchwierigkeit, große Zahlen zu faktorisieren.
Replay-Angriff Bei einem Replay-Angriff sendet der Angreifer ein Paket, das erzuvor mitgeschnitten hat.
X.509-Zertifikat Ein X.509-Zertifikat bindet eine Identität an einen RSA- oder DSA-Schlüssel.
6
C PKI
C.1 OpenSSL-Konfiguration
In der Testumgebung wurde folgende openssl.cnf auf dem Linux-System undeine leicht modifizierte Variante auf dem VPN-Gateway verwendet:
HOME = /usr/local/sslRANDFILE = $ENV::HOME/.rndCERTFQDN = gateway.asgard
[ ca ]default_ca = CA
[ CA ]dir = /usr/local/ssl/CAcerts = $dir/certscrl_dir = $dir/crldatabase = $dir/index.txtnew_certs_dir = $dir/newcertscertificate = $dir/certs/ca.cert.pemserial = $dir/serialcrl = $crl_dir/crl.pemprivate_key = $dir/private/ca.key.pemRANDFILE = $dir/private/.randx509_extensions = usr_certname_opt = ca_defaultcert_opt = ca_defaultdefault_days = 365default_crl_days= 30default_md = sha1preserve = nopolicy = ca_policy
[ ca_policy ]countryName = suppliedstateOrProvinceName = suppliedlocalityName = suppliedorganizationName = matchorganizationalUnitName = optionalcommonName = suppliedemailAddress = supplied
[ req ]default_bits = 2048default_keyfile = privkey.pemdistinguished_name = req_distinguished_namex509_extensions = v3_castring_mask = pkix
[ req_distinguished_name ]countryName = Landesname (ISO 3166-1)countryName_default = DEcountryName_min = 2countryName_max = 2
stateOrProvinceName = BundeslandstateOrProvinceName_default = Thuringia
localityName = StadtlocalityName_default = Jena
0.organizationName = Organisation (z.B. Firma)0.organizationName_default = Asgard
organizationalUnitName = Organisationseinheit (z.B. Abteilung)
commonName = NamecommonName_max = 64
7
emailAddress = E-Mail-AdresseemailAddress_max = 64
[ usr_cert ]basicConstraints = CA:FALSEsubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuer:alwaysauthorityInfoAccess = OCSP;URI:http://ocsp.ca.asgard:8000/crlDistributionPoints = URI:http://www.ca.asgard/vpn.crl
[ v3_req ]basicConstraints= CA:FALSEkeyUsage = nonRepudiation,digitalSignature,keyEncipherment
[ v3_ca ]basicConstraints = critical,CA:truesubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid:always,issuer:alwayskeyUsage = cRLSign,keyCertSignauthorityInfoAccess = OCSP;URI:http://ocsp.ca.asgard:8000/crlDistributionPoints = URI:http://www.ca.asgard/vpn.crl
[ v3_gateway ]basicConstraints = CA:FALSEsubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuer:alwayssubjectAltName = DNS:$ENV::CERTFQDNauthorityInfoAccess = OCSP;URI:http://ocsp.ca.asgard:8000/crlDistributionPoints = URI:http://www.ca.asgard/vpn.crl
[ v3_client ]basicConstraints = CA:FALSEsubjectKeyIdentifier = hashauthorityKeyIdentifier = keyid,issuer:alwayssubjectAltName = email:copyauthorityInfoAccess = OCSP;URI:http://ocsp.ca.asgard:8000/crlDistributionPoints = URI:http://www.ca.asgard/vpn.crl
[ crl_ext ]issuerAltName = issuer:copyauthorityKeyIdentifier = keyid:always,issuer:always
C.2 Aufsetzen der CA
Zunächst werden wie folgt die notwendigen Verzeichnisse und Dateien angelegt.Dabei ist darauf zu achten, dass private/ besonders geschützt wird:
tyr:/usr/local/ssl# mkdir CAtyr:/usr/local/ssl/CA# mkdir certs crl newcerts privatetyr:/usr/local/ssl/CA# chmod 700 privatetyr:/usr/local/ssl/CA# umask 77 privatetyr:/usr/local/ssl/CA# echo 01 > serialtyr:/usr/local/ssl/CA# touch index.txt
Nachdem die notwendigen Verzeichnisse und Dateien angelegt wurden, emp-fiehlt es sich, den Zufallszahlen-Status zu initialisieren:
tyr:/usr/local/ssl/CA# dd if=/dev/urandom of=private/.rand bs=1024 count=11+0 records in1+0 records out
Anschließend wird ein 2048 Bit langer RSA-Schlüssel erzeugt. Dieser sollte sinn-voller Weise durch starke Verschlüsselung geschützt werden:
tyr:/usr/local/ssl/CA# openssl genrsa -aes256 -out private/ca.key.pem 2048Generating RSA private key, 2048 bit long modulus
8
..........+++
.+++e is 65537 (0x10001)Enter pass phrase for private/ca.key.pem:Verifying - Enter pass phrase for private/ca.key.pem:
Zu diesem RSA-Schlüssel wird nun ein selbst signiertes X.509-Zertifikat erzeugt:
tyr:/usr/local/ssl/CA# openssl req -new -x509 -days 730 -sha1 \> -key private/ca.key.pem -out certs/ca.cert.pemEnter pass phrase for private/ca.key.pem:You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter ’.’, the field will be left blank.-----Landesname (ISO 3166-1) [DE]:Bundesland [Thuringia]:Stadt [Jena]:Organisation (z.B. Firma) [Asgard]:Organisationseinheit (z.B. Abteilung) []:Certification AuthorityName []:Asgard CAE-Mail-Adresse []:ca@asgard
Das X.509-Zertifikat wird nun über seinen Hash-Wert nach certs/ verlinkt:
tyr:/usr/local/ssl/CA# c_rehash certs/Doing certs/ca.cert.pem => 7866bb59.0
C.3 VPN-Gateway
Zunächst wird ein 2048 Bit langer RSA-Schlüssel auf dem VPN-Gateway erstellt.Dieser wird nicht durch Verschlüsselung geschützt, da isakmpd momentan nichtdamit umgehen kann:
heimdal:/etc/isakmpd/private# openssl genrsa -out heimdal.asgard.key.pem 2048Generating RSA private key, 2048 bit long modulus............................................+++.................+++e is 65537 (0x10001)
Zu diesem RSA-Schlüssel wird anschließend eine Zertifizierungsanforderung er-stellt:
heimdal:/etc/isakmpd/private# openssl req -new -key heimdal.asgard.key.pem \> -out heimdal.asgard.req.pemYou are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter ’.’, the field will be left blank.-----Landesname (ISO 3166-1) [DE]:Bundesland [Thuringia]:Stadt [Jena]:Organisation (z.B. Firma) [Asgard]:Organisationseinheit (z.B. Abteilung) []:.Name []:heimdal.asgardE-Mail-Adresse []:[email protected]
9
Die Zertifizierungsanforderung wird der CA überstellt, welche dazu nach ein-gehender Prüfung ein X.509-Zertifikat erstellt:
tyr:/usr/local/ssl/CA# CERTFQDN=heimdal.asgard openssl ca \> -in heimdal.asgard.req.pem -out certs/heimdal.asgard.cert.pem \> -extensions v3_gatewayUsing configuration from /usr/local/ssl/openssl.cnfEnter pass phrase for /usr/local/ssl/CA/private/ca.key.pem:Check that the request matches the signatureSignature okCertificate Details:
Serial Number: 1 (0x1)Validity
Not Before: Jul 3 15:49:11 2002 GMTNot After : Jul 3 15:49:11 2003 GMT
Subject:countryName = DEstateOrProvinceName = ThuringialocalityName = JenaorganizationName = AsgardcommonName = heimdal.asgardemailAddress = [email protected]
X509v3 extensions:X509v3 Basic Constraints:CA:FALSEX509v3 Subject Key Identifier:E6:CA:4F:9C:F1:EB:C0:9F:6D:71:BC:E5:16:82:AA:4D:A2:D7:79:76X509v3 Authority Key Identifier:keyid:C6:0F:D6:6B:57:A1:0E:9D:86:50:2C:73:B2:6E:56:F4:5F:E8:93:86DirName:/C=DE/ST=Thuringia/L=Jena/O=Asgard/OU=Certification
Authority/CN=Asgard CA/emailAddress=ca@asgardserial:00
X509v3 Subject Alternative Name:DNS:heimdal.asgardAuthority Information Access:OCSP - URI:http://ocsp.ca.asgard:8000/
X509v3 CRL Distribution Points:URI:http://www.ca.asgard/vpn.crl
Certificate is to be certified until Jul 3 15:49:11 2003 GMT (365 days)Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]yWrite out database with 1 new entriesData Base Updated
Das X.509-Zertifikat wird nun über seinen Hash-Wert nach certs/ verlinkt:
tyr:/usr/local/ssl/CA# c_rehash certs/Doing certs/ca.cert.pem => 7866bb59.0heimdal.asgard.cert.pem => a711f499.0
C.4 VPN-Clients
Zunächst wird ein 2048 Bit langer RSA-Schlüssel erstellt. Dieser sollte sinnvollerWeise durch starke Verschlüsselung geschützt werden:
tyr:/usr/local/ssl/CA# openssl genrsa -aes256 -out [email protected] 2048...............+++................+++e is 65537 (0x10001)Enter pass phrase for [email protected]:Verifying - Enter pass phrase for [email protected]:
10
Zu diesem RSA-Schlüssel wird anschließend eine Zertifizierungsanforderung er-stellt:
tyr:/usr/local/ssl/CA# openssl req -new -key alice\@asgard.key.pem \> -out alice\@asgard.req.pemEnter pass phrase for [email protected]:You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter ’.’, the field will be left blank.-----Landesname (ISO 3166-1) [DE]:Bundesland [Thuringia]:Stadt [Jena]:Organisation (z.B. Firma) [Asgard]:Organisationseinheit (z.B. Abteilung) []:Sales ForceName []:Alice Q.E-Mail-Adresse []:alice@asgard
Nach eingehender Prüfung erstellt die CA ein X.509-Zertifikat zu der Zertifizie-rungsanforderung:
tyr:/usr/local/ssl/CA# openssl ca -in alice\@asgard.req.pem \> -out certs/[email protected] -extensions v3_clientUsing configuration from /usr/local/ssl/openssl.cnfEnter pass phrase for /usr/local/ssl/CA/private/ca.key.pem:Check that the request matches the signatureSignature okCertificate Details:
Serial Number: 2 (0x2)Validity
Not Before: Jul 3 15:53:38 2002 GMTNot After : Jul 3 15:53:38 2003 GMT
Subject:countryName = DEstateOrProvinceName = ThuringialocalityName = JenaorganizationName = AsgardorganizationalUnitName = Sales ForcecommonName = Alice Q.emailAddress = alice@asgard
X509v3 extensions:X509v3 Basic Constraints:CA:FALSEX509v3 Subject Key Identifier:03:6F:51:9E:94:C0:92:E5:79:FC:0B:77:57:1F:D8:EF:B5:57:48:C7X509v3 Authority Key Identifier:keyid:C6:0F:D6:6B:57:A1:0E:9D:86:50:2C:73:B2:6E:56:F4:5F:E8:93:86DirName:/C=DE/ST=Thuringia/L=Jena/O=Asgard/OU=Certification
Authority/CN=Asgard CA/emailAddress=ca@asgardserial:00
X509v3 Subject Alternative Name:email:alice@asgardAuthority Information Access:OCSP - URI:http://ocsp.ca.asgard:8000/
X509v3 CRL Distribution Points:URI:http://www.ca.asgard/vpn.crl
Certificate is to be certified until Jul 3 15:53:38 2003 GMT (365 days)Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]yWrite out database with 1 new entriesData Base Updated
11
Das X.509-Zertifikat wird nun über seinen Hash-Wert nach certs/ verlinkt:
tyr:/usr/local/ssl/CA# c_rehash certs/Doing certs/ca.cert.pem => 7866bb59.0heimdal.asgard.cert.pem => [email protected] => d44643ca.0
Aus dem RSA-Schlüssel des Clients und den X.509-Zertifikaten des Clients undder CA wird nun ein PKCS#12-Bundle erstellt, das später importiert werden kann:
tyr:/usr/local/ssl/CA# openssl pkcs12 -export \> -in certs/[email protected] -inkey [email protected] \> -certfile certs/ca.cert.pem -out [email protected] pass phrase for [email protected]:Enter Export Password:Verifying - Enter Export Password:
Analog dazu wurde auch ein RSA-Schlüssel und ein X.509-Zertifikat für Mallory,einen Angreifer der möglicher Weise aus den eigenen Reihen stammt, erstellt.
C.5 CRLs
OpenSSL generiert CRLs an Hand der Einträge in index.txt . Ein X.509-Zertifikatwird wie folgt widerrufen:
tyr:/usr/local/ssl/CA# openssl ca -revoke certs/heimdal.asgard.cert.pemUsing configuration from /usr/local/ssl/openssl.cnfEnter pass phrase for /usr/local/ssl/CA/private/ca.key.pem:Revoking Certificate 01.Data Base Updated
Anschließend kann man wie folgt eine CRL erstellen:
tyr:/usr/local/ssl/CA# openssl ca -gencrl -md sha1 -outform der \> -out crl/crl.derUsing configuration from /usr/local/ssl/openssl.cnfEnter pass phrase for /usr/local/ssl/CA/private/ca.key.pem:
C.6 OCSP
Für den OCSP-Responder wird zunächst ein 2048 Bit langer RSA-Schlüssel erstellt.Dieser sollte sinnvoller Weise durch starke Verschlüsselung geschützt werden:
tyr:/usr/local/ssl/CA# openssl genrsa -aes256 -out ocsp.ca.asgard.key.pem 2048Generating RSA private key, 2048 bit long modulus............+++..+++e is 65537 (0x10001)Enter pass phrase for ocsp.ca.asgard.key.pem:Verifying - Enter pass phrase for ocsp.ca.asgard.key.pem:
12
Zu diesem RSA-Schlüssel wird anschließend eine Zertifizierungsanforderung er-stellt:
tyr:/usr/local/ssl/CA# openssl req -new -key ocsp.ca.asgard.key.pem \> -out ocsp.ca.asgard.req.pemEnter pass phrase for ocsp.ca.asgard.key.pem:You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter ’.’, the field will be left blank.-----Landesname (ISO 3166-1) [DE]:Bundesland [Thuringia]:Stadt [Jena]:Organisation (z.B. Firma) [Asgard]:Organisationseinheit (z.B. Abteilung) []:Certification AuthorityName []:OCSP
Nach eingehender Prüfung erstellt die CA ein X.509-Zertifikat zu der Zertifizie-rungsanforderung:
tyr:/usr/local/ssl/CA# openssl ca -in ocsp.ca.asgard.req.pem \> -out certs/ocsp.ca.asgard.cert.pemUsing configuration from /usr/local/ssl/openssl.cnfEnter pass phrase for /usr/local/ssl/CA/private/ca.key.pem:Check that the request matches the signatureSignature okCertificate Details:
Serial Number: 4 (0x4)Validity
Not Before: Sep 28 20:09:21 2002 GMTNot After : Sep 28 20:09:21 2003 GMT
Subject:countryName = DEstateOrProvinceName = ThuringialocalityName = JenaorganizationName = AsgardorganizationalUnitName = Certification AuthoritycommonName = OCSPemailAddress = ca@asgard
X509v3 extensions:X509v3 Basic Constraints:CA:FALSEX509v3 Subject Key Identifier:71:43:12:EF:DF:D3:36:93:9A:15:A7:F0:5D:E0:04:D3:61:20:C3:A6X509v3 Authority Key Identifier:keyid:C6:0F:D6:6B:57:A1:0E:9D:86:50:2C:73:B2:6E:56:F4:5F:E8:93:86DirName:/C=DE/ST=Thuringia/L=Jena/O=Asgard/OU=Certification
Authority/CN=Asgard CA/emailAddress=ca@asgardserial:00
Authority Information Access:OCSP - URI:http://ocsp.ca.asgard:8000/
X509v3 CRL Distribution Points:URI:http://www.ca.asgard/vpn.crl
Certificate is to be certified until Sep 28 20:09:21 2003 GMT (365 days)Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]yWrite out database with 1 new entriesData Base Updated
13
Dem X.509-Zertifikat wird für das Signieren in OCSP vertraut:
tyr:/usr/local/ssl/CA# openssl x509 -addtrust OCSPSigning \> -in certs/ocsp.ca.asgard.cert.pem -out certs/ocsp.ca.asgard.cert.pem
Das X.509-Zertifikat wird nun über seinen Hash-Wert nach certs/ verlinkt:
tyr:/usr/local/ssl/CA# c_rehash certs/ca.cert.pem => 7866bb59.0heimdal.asgard.cert.pem => [email protected] => [email protected] => 1108a2a7.0ocsp.ca.asgard.cert.pem => 752c0375.0Doing certs/
Anschließend kann der OCSP-Responder gestartet werden:
tyr:/usr/local/ssl/CA# openssl ocsp -index index.txt -CA certs/ca.cert.pem \> -rsigner certs/ocsp.ca.asgard.cert.pem -rkey ocsp.ca.asgard.key.pem \> -port 8000Enter pass phrase for ocsp.ca.asgard.key.pem:Waiting for OCSP client connections...
C.7 LDAP
tinyldap setzt libowfat auf. Außerdem empfiehlt es sich, tinyldap gegen die diet libczu linken. Also werden zunächst deren Sourcen aus dem CVS geholt, kompiliertund diet libc und libowfat installiert, bevor man sich tinyldap zuwendet.
thomas@tyr:~/src$ export CVSROOT=:pserver:[email protected]/cvsthomas@tyr:~/src$ cvs loginLogging in to :pserver:[email protected]:2401/cvsCVS password:thomas@tyr:~/src$ cvs co dietlibc[..]thomas@tyr:~/src/dietlibc$ make[..]thomas@tyr:~/src/dietlibc$ sudo make install[..]
thomas@tyr:~/src$ cvs co libowfat[..]thomas@tyr:~/src/libowfat$ make[..]thomas@tyr:~/src/libwofat$ sudo make install[..]
Nach dem diet libc und libowfat installiert sind, werden die tinyldap-Sourcenaus dem CVS geholt. Momentan muss man vor dem Kompilieren einen kleinenPatch anwenden, der Probleme mit unnötig langen BaseObjects in eingehendenSearchRequests beseitigt (siehe C.8, S. 14):
thomas@tyr:~/src$ cvs co tinyldap[..]thomas@tyr:~/src/tinyldap$ patch -p0 < ../ldap_match_mapped.c.diff[..]thomas@tyr:~/src/tinyldap$ make[..]
14
Anschließend wird exp.ldif den jeweiligen Gegebenheiten angepasst. Hin-ter certificaterevocationlist;binary:: steht die Base64-codierte CRL. Siekann sich über mehrere Zeilen erstrecken. Dabei ist zu beachten, dass weitere Zeilenmit einem Leerzeichen beginnen müssen. Weiterhin muss die letzte Zeile eine Leer-zeile sein, da ./parse sonst in einer Endlosschleife hängt. In der Testumgebungsah exp.ldif wie folgt aus:
dn: cn=asgard ca,o=asgard,c=deobjectClass: pkiCAcertificaterevocationlist;binary:: MIIB7jCB1zANBgkqhkiG9w0BAQUFAD
CBkTELMAkGA1UEBhMCREUxEjAQBgNVBAgTCVRodXJpbmdpYTENMAsGA1UEBxMESmVuYTEPMA0GA1UEChMGQXNnYXJkMSAwHgYDVQQLExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTESMBAGA1UEAxMJQXNnYXJkIENBMRgwFgYJKoZIhvcNAQkBFgljYUBhc2dhcmQXDTAyMDgzMDE2MjI1MVoXDTAyMDkyOTE2MjI1MVowFDASAgEBFw0wMjA3MzAwNzM3MjlaMA0GCSqGSIb3DQEBBQUAA4IBAQAC6qFpOYFeXLRfpim/nLRnhvHMVmxjhFf2gZiYJ3ZIQWRs1OlXQLmu/BShdGpWcvOTllq+upbyAX1hisC2mRk9TwPuIKqk3RjZDH67TeD+hQmMmb6M932M/2YcAm2qLdSTICIYVGvSeL3TfZmrB5SwEQDnJNHu3zLdZUUodooxgk06LuSPDHd5Hn9r+ZedJFVkXBVti07M70lod85zsevG1AEtHJDNj00Q2dqutQkWg9pILRAE28PQEnC9msfDOw3pQ5l/gQXt66Toz9M66Q71XvenfHzWaQUWCVXYhvYsrYbZlAo4GiCUJggPhRpduSNYLgqpbd5Rv8sWAZ1VuKIW
Mit ./parse wird die Datei data aus exp.ldif erzeugt. Nun kann tinyldapgestartet werden.
thomas@tyr:~src/tinyldap$ ./parsethomas@tyr:~src/tinyldap$ sudo ./tinyldap_debug[..]
Für den Einsatz außerhalb einer Testumgebung empfiehlt es sich tinyldap mittcpserver in einer daemontools- oder minit-Umgebung zu betreiben.
C.8 ldap_match_mapped.c.diffIndex: ldap_match_mapped.c===================================================================RCS file: /cvs/tinyldap/ldap_match_mapped.c,vretrieving revision 1.9diff -u -r1.9 ldap_match_mapped.c--- ldap_match_mapped.c 2002/08/30 22:36:59 1.9+++ ldap_match_mapped.c 2002/09/24 17:21:03@@ -152,7 +152,7 @@
}
/* return 0 if they didn’t match, otherwise return length in b */-static int match(const char* a,int len,const char* b) {+static unsigned int match(const char* a,int len,const char* b) {
const char* A=a+len;const char* B=b+strlen(b);while (len>0 && A>a && B>b) {
@@ -162,32 +162,28 @@if (tolower(*A) != tolower(*B))
return 0;}
- return strlen(B);+ /* len>0 => b is a substring of a */+ return len?0:strlen(B);
}
/* return non-zero if the record matches the search request */int ldap_match_mapped(uint32 ofs,struct SearchRequest* sr) {
- unsigned int l,i;+ unsigned int l,l2,i;
uint32 k;uint32_unpack(map+ofs+8,&k);
15
l=strlen(map+k);- /* first see if baseObject is a suffix of dn */- if (sr->baseObject.l>l) {-// puts("fail: baseObject longer than dn");- return 0;- }
/* we want "o=foo, o=bar" and "o=FOO,o=baR" to be equal */- if (sr->baseObject.l && !match(sr->baseObject.s,sr->baseObject.l,map+k)) {+ if (sr->baseObject.l && !(l2=match(sr->baseObject.s,sr->baseObject.l,map+k))) {
// puts("fail: not suffix");return 0;
}/* it is. If scope==wholeSubtree, the scope check is also done */switch (sr->scope) {case wholeSubtree: break;
- case baseObject: if (l==sr->baseObject.l) break; return 0;+ case baseObject: if (l==l2) break; return 0;
default:i=str_chr(map+k,’,’);
- if (i+2>=l-sr->baseObject.l) break;+ if (i+2>=l-l2) break;
return 0;}return ldap_matchfilter_mapped(ofs,sr->filter);
16
D Konfiguration des VPN-Gateways
In der Testumgebung wurde folgende isakmpd.conf verwendet:
[General]Listen-on= 10.0.0.1
[X509-certificates]CA-directory= /etc/isakmpd/ca/Cert-directory= /etc/isakmpd/certs/Private-key= /etc/isakmpd/private/heimdal.asgard.key.pem#Private-key= /etc/isakmpd/private/[email protected]#Private-key= /etc/isakmpd/private/fake.key.pem#CRL-directory= /etc/isakmpd/crls/
[Phase 1]Default= ISAKMP-VPN
[ISAKMP-VPN]Phase= 1Configuration= Default-main-modeID= heimdal-id#ID= mallory-idFlags= ikecfg
[heimdal-id]ID-type= FQDNName= heimdal.asgard
[mallory-id]ID-type= USER_FQDNName= mallory@sgard
[Default-main-mode]DOI= IPSECEXCHANGE_TYPE= ID_PROTTransforms= 3DES-SHA-RSA_SIG,BLF-SHA-RSA_SIGGROUP_DESCRIPTION= MODP_1024
[ufqdn/alice@asgard]#Mode= REQAddress= 192.168.1.1Netmask= 255.255.0.0Nameserver= 192.168.0.1
Die Konfigurationsdatei isakmpd.policy sah wie folgt aus:
KeyNote-Version: 2Authorizer: "POLICY"Licensees: "DN:/C=DE/ST=Thuringia/L=Jena/O=Asgard/OU=CertificationAuthority/CN=Asgard CA/emailAddress=ca@asgard"Conditions: app_domain == "IPsec policy" &&
(esp_enc_alg == "3des" || esp_enc_alg == "blowfish") &&local_filter_type == "IPv4 subnet" &&local_filter == "192.168.000.000-192.168.255.255" -> "true";
17
E Konfiguration der VPN-Clients
E.1 Windows 2000/XP nativ
In den Test wurde Windows XP über die MMC konfiguriert. Diese kann über Aus-führen... im Startmenü gestartet werden.
Über Datei/Snap-In hinzufügen/entfernen... gelangt man in die Oberfläche zur Ver-waltung von Snap-Ins. In dieser werden die Snap-Ins IP-Sicherheitsrichtlinienverwal-tung und Zertifikate für den lokalen Computer hinzugefügt.
Es empfiehlt sich nun, die erstellte Konsole über Datei/Speichern zu sichern. Inder Konsole werden zunächst die benötigten X.509-Zertifikate und RSA-Schlüsselaus dem PKCS#12-Bundle importiert. Ein Rechtsklick auf Eigene Zertifikate unterZertifikate (Lokaler Computer) öffnet ein Menü. In diesem wird Importieren... unter Al-le Tasks gewählt. Im darauf hin erscheinenden Zertifikatsimport-Assistent wählt manZertifikatsspeicher automatisch auswählen (auf dem Zertifikatstyp basierend).
Nach einem Rechtsklick auf IP-Sicherheitsrichtlinien auf Lokaler Computer kommtein Menü zum Vorschein, das mögliche Aktionen beinhaltet. Aus diesen wird IP-
18
Sicherheitsrichtlinie erstellen... gewählt. Daraufhin erscheint der IP-Sicherheitsrichtli-nien-Assistent. In diesem wird der IP-Sicherheitsrichtlinie ein kurzer Name zugewie-sen. Die Standardantwortregel wird deaktiviert. Nach der Beendigung des Assisten-ten kann man die Eigenschaften der IP-Sicherheitsrichtlinie bearbeiten.
Dort wird die Option Assistenten verwenden deaktiviert und über Hinzufügen...eine neue IP-Sicherheitsregel erstellt. Dazu wird unter IP-Filterliste über Hinzufügen...ein Filter für den gesamten IP-Traffic von der eigenen IP-Adresse ins Netz hinterdem VPN-Gateway angelegt.
Für diesen Filter wird unter Filteraktion über Hinzufügen... eine neue Filteraktionerstellt. In dem sich öffnenden Dialog werden per Entfernen gegebenenfalls beste-hende Sicherheitsmethoden gelöscht und über Hinzufügen... eine neue erstellt. In demnun erscheinenden Dialog kann unter Benutzerdefiniert über Einstellungen... schließ-lich die Sicherheitsmethode, die dem Proposal für Phase 2 gleich kommt, definiertwerden.
Unter Authentifizierungsmethoden wird Kerberos über Bearbeiten... in Verwenden ei-nes Zertifikats von dieser Zertifizierungsstelle geändert und das X.509-Zertifikat der CAgewählt.
19
Anschließend wird unter Tunneleinstellungen die IP-Adresse des VPN-Gatewayals Tunnel-Endpunkt angegeben.
Nachdem die Erstellung der ersten IP-Sicherheitsregel beendet ist, wird eine wei-tere erstellt. Bei dieser wird ein Filter für den gesamten IP-Traffic vom Netz hinterdem VPN-Gateway zur eigenen IP-Adresse angelegt. Als Tunnelendpunkt wird dieeigene IP-Adresse angegeben. Die übrigen Punkte sind identisch mit denen der ers-ten IP-Sicherheitsregel.
In den Eigenschaft der IP-Sicherheitsrichtlinie können unter Allgemein über Erwei-tert... die Eigenschaften für den Schlüsselaustausch konfiguriert werden. Über Metho-den... wird der Proposal für Phase 1 spezifiziert.
E.2 SSH Sentinel
Zunächst wird der Policy Editor entweder über das Startmenü oder über das SSH-Sentinel-Icon Systemtray gestartet.
Im Key Management werden die X.509-Zertifikate und der RSA-Schlüssel aus demPKCS#12-Bundle importiert. Dazu wird aus dem nach einem Rechtsklick auf MyKeys erscheinendem Menü Import... gewählt.
20
Danach wird in Security Policy eine neue Regel innerhalb der VPN Connectionsangelegt. Ein Rechtsklick auf VPN Connections öffnet ein Menü. Aus diesem wirdAdd Rule... gewählt. In dem nun erscheinenden Dialog wird der DNS-Name oderdie IP-Adresse des VPN-Gateways eingegeben, das Netz hinter dem VPN-Gatewayspezifiziert und ein Schlüssel zur Authentifizierung gewählt.
Über Properties... werden die Rule Properties geöffnet, in diesen kann die Regelweiter bearbeitet werden. Dort werden abschließend die Proposals für Phase 1 undPhase 2 spezifiziert.
E.3 SoftRemote
Zunächst wird der Certificate Manager gestartet. Das kann entweder über das Start-menü oder das SoftRemote-Icon im Systemtray durchgeführt werden. Im CertificateManager werden unter My Certificates mittels Import Certificate... das eigene X.509-Zertifikat und der zugehörige RSA-Schlüssel aus dem PKCS#12-Bundle importiert.
21
Anschließend wird unter Root CA Certificates über Import Certificate... das Zertifi-kat der CA importiert.
Danach wird entweder über das Startmenü oder das SoftRemote-Icon im Sys-temtray der Security Policy Editor gestartet. Ein Rechtsklick auf My Connections öffnetein Menü. Aus diesem wird Connection innerhalb von Add ausgewählt.
Die neu angelegte Verbindung wird dann konfiguriert. Dazu wird das Netz hin-ter dem VPN-Gateway spezifiziert, die Verbindung über ein VPN-Gateway gewähltsowie die Identität des VPN-Gateways und dessen IP-Adresse bzw. DNS-Name an-gegeben.
Anschließend wird die eigene Identität konfiguriert, d.h. ein Zertifikat und ge-wünschte Form der zu übertragenden Identität gewählt.
22
Dannach wird der Mode für Phase 1 gewählt und gegebenenfalls PFS aktiviert.
Im Nächten Schritt wird der Proposal für Phase 1 konfiguriert.
Den Abschluss bildet die Konfiguration des Proposals für Phase 2.
E.4 PGPnet
Zunächst wird PGPkeys über das Startmenü oder das Icon im Systemtray gestartet.Dort werden über Keys/Import... das PKCS#12-Bundle und das X.509-Zertifikat desVPN-Gateway importiert.
23
Anschließend wird PGPnet ebenfalls über das Startmenü oder das Icon im Sys-temtray gestartet. Dort wird über Add... ein neuer Eintrag für das VPN-Gatewayerstellt. Es wird die IP-Adresse des VPN-Gateways angegeben und das zum RSA-Schlüssel der Gegenstelle passende X.509-Zertifikat gewählt.
Danach wird abermals über Add... ein Eintrag für das Netz hinter dem VPN-Gateway angelegt.
Über View/Options... wird ein Dialog geöffnet, der weitere Konfiguration erlaubt.Dort wird unter VPN Authentication per Select Certificate... das eigene X.509-Zertifikatgewählt.
Abschließend werden unter VPN Advanced die Proposals für Phase 1 und Phase2 konfiguriert.
Top Related