Sicherere latenzarme Kommunikationswege mit IPsecdigilib.happy-security.de/files/Sichere_Kommunikation_mit_IPSec.pdf · 2 netsichdamitausschließlichfürVerbindungenzwischenzweiRechnern.ImTunnel

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


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


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:


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


X509v3 Subject Alternative Name:email:alice@asgardAuthority Information Access:OCSP - URI:http://ocsp.ca.asgard:8000/


Certificate is to be certified until Jul 3 15:53:38 2003 GMT (365 days)Sign the certificate? [y/n]:y


11


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


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:


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 Information Access:OCSP - URI:http://ocsp.ca.asgard:8000/


Certificate is to be certified until Sep 28 20:09:21 2003 GMT (365 days)Sign the certificate? [y/n]:y


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


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.

Documents

Sicherere latenzarme Kommunikationswege mit IPsecdigilib.happy-security.de/files/Sichere_Kommunikation_mit_IPSec.pdf · 2 netsichdamitausschließlichfürVerbindungenzwischenzweiRechnern.ImTunnel