Lade Inhalt...

IP Security - Eine Analyse der FreeS/WAN IPsec - Realisierung

Skript 2000 47 Seiten

Informatik - Angewandte Informatik

Leseprobe

Einleitung

An der FH München ist für das 3. Semester ein Praktikum vorgesehen. Ich habe mich für ein Praktikum bei Siemens in der Abteilung ZT IK3 (Zentralabteilung Technik, Fachzentrum Sicherheit) beworben, da ich mich für das Thema Sicherheit im Internet interessiere. Ich wurde dort von Herrn Dr. Pfaff und Herrn Franke mit dem Thema IP Security betraut.

IPsec ist ein neuer Internet Standard, der Sicherheitsmechanismen auf IP – Ebene implementiert. IPsec bietet sowohl ‘End to End‘ – Security als auch Mechanismen für die Bildung von VPNs. Die Stärke von IPsec liegt darin, daß es auf IP – Ebene arbeitet. Das bedeutet, daß darüberliegende Protokolle und Anwendungen von den Sicherheitsmechanismen nichts bemerken.

IPsec basiert hauptsächlich auf zwei Komponenten, IKE und den beiden Protokollen ESP und AH. IKE ist dafür zuständig, daß Schlüssel sicher ausgetauscht werden und verwaltet die SAs, welche die Sicherheitsparameter der Verbindungen beschreiben. Die beiden Protokolle AH und ESP sorgen dafür, daß die Daten authentifiziert bzw. verschlüsselt übertragen werden.

Inhaltsangabe

1. IPsec Übersicht
1.1 IKE
1.2 AH und ESP

2. IKE
2.1 ISAKMP
2.2 OAKLEY (/SKEME)
2.3 Algorithmen
2.4 IKE ISAKMP – HEADER
2.4.1 ISAKMP – Header
2.4.2 ISAKMP – ‘generic – payload – header‘
2.4.3 ISAKMP – Payloads

3. AH und ESP
3.1 Hauptbestandteile
3.1.1 Security Associations
3.1.2 Security Parameter Index
3.1.3 Security Association Database
3.1.4 Security Policy Database
3.2 AH und ESP Header
3.2.1 AH
3.2.2 ESP
3.2.3 AH in Verbindung mit ESP
3.3 IPsec Modi
3.3.1 End to End
3.3.2 VPN
3.3.3 End to End / VPN
3.3.4 Remote Host

4. IPsec – FreeS/WAN Analyse

5. FreeS/WAN
5.1 Codebaum
5.2 Die wichtigsten Bestandteile Klips und Pluto
5.2.1 pluto
5.2.2 klips
5.3 Kernel Integration
5.4 Zufallszahlengenerierung

6. Quellenangaben

7. Glossar

8. Anhang
8.1 FreeS/WAN - Dokumentation / HowTo
8.2 Pluto – Log – Datei

1. IPsec Übersicht

IPsec ist ein neuer Sicherheitsstandard, der eine sichere Datenübertragung zwischen zwei Teilnehmern ermöglicht. Eine gute Informationsquelle ist das Buch „IPsec, The New Security Standard for the Internet, Intranets, and Virtual Private Networks“ von Naganand Doraswamy und Dan Harkins. Für Begriffe aus der Kryptologie möchte ich auf das Buch „Handbook of Applied Cryptography“ von Alfred J. Menezes, Paul C. van Oorschot und Scott A. Vanstone verweisen.

1.1 IKE

Abbildung in dieser Leseprobe nicht enthalten

1.2 AH und ESP

Abbildung in dieser Leseprobe nicht enthalten

2. IKE

Internet Key Exchange

IKE besteht aus ISAKMP und Teilen von Oakley und Skeme

2.1 ISAKMP

Das "Internet Security Association and Key Management Protocol" ist ein flexibles Protokoll, das Mechanismen zur Verfügung stellt, mit denen zwei Hosts SAs (siehe 3.1.1) für Sicherheitsprotokolle bilden können.

2.2 Oakley (/Skeme)

Oakley definiert einen Schlüsselaustausch in zwei Phasen. In Phase 1 wird eine SA erstellt, die dazu verwendet wird, eine sichere Verbindung zwischen den IKE – Partnern herzustellen. In der zweiten Phase wird eine weitere protokollabhängige (von DOI abhängige) SA gebildet. In unserem Fall wird eine IPsec - SA erstellt.

- Phase 1 wird entweder durch den "Main Mode" oder "Aggressive Mode" implementiert.
- Phase 2 wird immer durch den "Quick Mode" implementiert.

Die verschiedenen Daten der Modi (z.B. SA-Vorschlag, Schlüsseldaten, Identität…) werden durch sogenannte Payloads in einer ISAKMP - Nachricht ausgetauscht (siehe 2.4 IKE ISAKMP - Header).

ISAKMP - Phasen

Abbildung in dieser Leseprobe nicht enthalten

2.3 Algorithmen

Abbildung in dieser Leseprobe nicht enthalten

2.4 IKE ISAKMP - Header

Eine ISAKMP – Nachricht beginnt immer mit einem ISAKMP – Header. Danach folgen die Payloads, die jeweils mit einem ISAKMP – ‘generic payload header‘ eingeleitet werden.

2.4.1 ISAKMP - Header

Abbildung in dieser Leseprobe nicht enthalten

2.4.2 ISAKMP – ‘generic payload header‘

Abbildung in dieser Leseprobe nicht enthalten

2.4.3 ISAKMP – Payloads

Alle Payloads, die auf einen ISAKMP - Header folgen, habe den generischen Header. Es gibt 13 verschiedene Payloads:

SA Payload

Festlegung der ‘domain of interpretation‘ (DOI, 1 = IPsec)

Proposal Payload

Anzahl der SA Vorschläge und Transformationen, Security Parameter Index des Senders

Transform Payload

Transformationen (= SA - Attribute), Anzahl und ID der Transformationen.

(beinhaltet zusätzlich noch Attribute Payload)

Key Exchange Payload

Schlüsselmaterial

Identification Payload

Indentifikationsdaten, - Typ, DOI spezifische Daten

Certificate Payload

Zertifikat des Senders

Certificate Request Payload

Fordert Zertifikat der Gegenstelle an

Hash Payload

Integritätsinformationen

Signature Payload

Digitale Unterschrift

Nonce Payload

Zufallsdaten

Notification Payload

DOI, SPI und Nachrichten / Fehlermeldungen

Delete Payload

DOI und SPI(s) zum Löschen von SAs

Vendor ID Payload

Herstellerkennung

3. AH und ESP

3.1 Hauptbestandteile

IPsec stellt Sicherheitsfunktionen auf IP - Ebene zu Verfügung und wird dazu benutzt VPNs zu bilden. Die wichtigsten Bestandteile von IPsec sind die sogenannte "Security Association" und die “Security Policy Database“.

3.1.1 Security Association (SA) :

Nach einem abgeschlossenen "Quick Mode", steht eine IPsec - SA und ein Identifier zur Verfügung.

Eine SA definiert, in welchem Modus eine IPsec - Verbindung verwendet wird (Tunnel oder Transport - Modus), welche Sicherheitsalgorithmen verwendet werden und wie lange sie halten soll. Auch die Schlüssel für die Ent- und Verschlüsselung sind in einer SA enthalten. SAs sind unidirektional, d.h. jeder Kommunikationspartner braucht zwei SAs. Eine SA (SAin) für ankommende IPsec - Pakete und eine SA (SAout) für ausgehende Pakete. Natürlich müssen SAout von Host A und SAin von Host B gleich sein.

Eine SA kann immer nur ein Protokoll unterstützen, entweder AH oder ESP. Wenn beide Protokolle verwendet werden sollen, muß für jedes Protokoll eine eigene SA erstellt werden. Wenn mehrere SAs für eine Verbindung zuständig sind, werden sie zu einer Gruppe zusammengeschlossen.

Eine SA wird durch das Tripel Zieladresse, SPI und Sicherheitsprotokoll identifiziert.

Eine SA umfasst mindestens folgende Parameter. Es werden weitere Parameter hinzugefügt, je nachdem , ob ein ESP- oder AH - Header hinzugefügt wird. Die folgenden Felder werden bei AH und ESP verwendet (‘generic fields‘):

Sequence Number

Die Sequence Number ist ein 32Bit Feld, das mit 0 initialisiert wird und immer dann um 1 erhöht wird, wenn ein IPsec - Paket den Host verläßt. Dadurch können sog. Replay - Attacken erkannt werden. Die maximale Anzahl von Paketen, die mit derselben SA versendet werden dürfen, ist 232.

Sequence Number Overflow

Dieses Feld wird gesetzt, wenn mehr als 232 Pakete gesendet wurden, die SA aber weiterhin genutzt werden soll.

Antireplay Window

Dieses Feld wird für ankommende Pakete verwendet, um Replay - Attacken zu entdecken.

Lifetime

Hier wird festgehalten, wie lange die SA bestehen darf. Die Lebenszeit wird entweder in Zeit oder in Volumen des Datendurchsatzes angegeben.

Mode

Dieses Feld kann auf Tunnelmodus, Transportmodus oder Wildcard gesetzt werden und bestimmt, in welchem Modus IPsec angewendet wird.

Tunnel Destination

Hier wird die Zieladdresse festgehalten, wenn IPsec im Tunnelmodus angewendet wird. (Gemeint ist damit die Zieladresse des äußeren IP - Headers, siehe 3.3 IPsec - Modi).

PMTU Parameters

PMTU Informationen für eventuelle Fragmentierung .

Je nach Sicherheitsalgorithmus und Implementierung werden mindestens noch folgende Felder ergänzt:

Destination Adress

IP – Adresse des Kommunikationspartners

SPI number

Die ID - Nummer des SPIs (max. 32Bit)

Security Protokoll

Hier wird angegeben, ob AH oder ESP verwendet wird

Security Protokoll Algorithm

Angewandte Algorithmen (MD5, 3DES,…)

Replay window

Größe des ‘replay windows‘

Encryption Key

Schlüssel für die Ver- und Entschlüsselung

Authentification Key

Schlüssel für die Authentifizierung

3.1.2 Security Parameter Index (SPI) :

Der SPI ist eine maximal 32Bit lange Zeichenfolge, die mit jedem Paket mitgeschickt wird. Diese Zeichenfolge identifiziert zusammen mit der Zieladdresse und dem Sicherheitsprotokoll diejenige SA, die dazu benutzt werden muß, das Paket zu entschlüsseln und/oder zu authentifizieren.

3.1.3 Security Association Database (SAD) :

In der SAD wird festgehalten, welche SAs zur Zeit existieren. Es müssen immer mindestens zwei SADs pro Netzwerkinterface erstellt werden, eine für ankommende Pakete und eine für ausgehende Pakete.

3.1.4 Security Policy Database (SPD) :

Die SPD ist eine geordnete Liste der Sicherheitsanforderungen (Policy Entries). Jeder Policy Entry (PE) wird ein oder mehrere Selektoren zugeordnet, über die sie dann später identifiziert werden. In einer PE wird beschrieben, was mit ankommenden oder ausgehenden Paketen gemacht werden soll. Es gibt drei Möglichkeiten: ‘discard‘, ‘bypass‘ oder ‘apply‘. Bei ‘discard‘ wird das Paket verworfen, und bei ‘bypass‘ wird das Paket weitergeleitet, ohne daß das Paket geschützt wird. Bei ‘apply‘ werden die Sicherheitskriterien angewandt die in der PE definiert sind. Zuerst wird in der SAD kontrolliert, ob bereits eine SA existiert mit der das Paket entschlüsselt und oder authentisiert werden kann. Ist dies nicht der Fall, wird eine SA nach den Sicherheitsanforderungen, die in der PE festgelegt sind, erstellt und in der SAD eingetragen.

Auch von der SPD werden zwei Versionen benötigt – eine für ankommende und eine für ausgehende Pakete.

3.1.5 Selectors

Über die Selektoren wird die SPD indiziert. Es gibt zumindest folgende Selektoren:

Zieladresse

Die Zieladdresse kann eine Host - Adresse, eine Netzwerkbereich oder eine Wildcard sein.

Quelladresse

Die Quelladresse kann eine Host - Adresse, eine Netzwerkbereich oder eine Wildcard sein.

Name

Benutzername (Email - Adresse oder X.500) oder Systemname (DNS - Name oder X.500).

Transportprotokoll

Gibt an welches (Upper Layer) Protokoll verwendet wird. Wenn ESP verwendet wird ist diese Information wegen der Verschlüsselung nicht zugänglich – dann wird hier eine Wildcard gesetzt.

Quell und Zielports

Portnummern oder Wildcards

3.2 AH und ESP Header

Die beiden Protokolle können jeweils im Transportmodus oder im Tunnelmodus benutzt werden.

Im Transportmodus werden die darüberliegenden Protokolldaten (TCP, UDP, …) geschützt, im Tunnelmodus wird das ganze IP - Paket durch das jeweilige Protokoll geschützt.

3.2.1 Der AH – Header

Der Authentifizierungsheader stellt die Integrität und den Ursprung der Daten sicher und schützt vor Replay - Attacken.

Abbildung in dieser Leseprobe nicht enthalten

3.2.2 ESP – Header

Der ESP ermöglicht die Verschlüsselung von Datenpaketen und stellt die Vertrauenswürdigkeit und den Ursprung der übertragenen Daten sicher.

Abbildung in dieser Leseprobe nicht enthalten

3.2.3 AH in Verbindung mit ESP

Wird ESP und AH zusammen im Transportmodus benutzt, sollte zuerst der ESP – Header und dann der AH eingefügt werden. Dadurch werden alle Felder des Pakets authentifiziert.

Abbildung in dieser Leseprobe nicht enthalten

3.3 IPsec – Modi

Nachfolgend werden die vier Hauptszenarios dargestellt, in denen IPsec eingesetzt wird. Bei einer Host to Host – Verbindung kann sowohl der Transportmodus, als auch der Tunnelmodus verwendet werden. Zwischen zwei Security Gateways ist der Tunnelmodus vorgeschrieben, außer die Gateways agieren als Hosts, d.h. die verschlüsselten Daten sind für sie bestimmt.

Abbildung in dieser Leseprobe nicht enthalten

3.3.1. End to End (Transport oder Tunnel Modus)

Abbildung in dieser Leseprobe nicht enthalten

3.3.2. Virtual Private Network (Tunnel mode)

Abbildung in dieser Leseprobe nicht enthalten

3.3.3. End to End – Security und VPN (Tunnel – und Transport mode)

Abbildung in dieser Leseprobe nicht enthalten

3.3.4. Remote Host (Tunnel und Transport mode)

Abbildung in dieser Leseprobe nicht enthalten

Anmerkung:

Nicht jede Art von Security Gateway erlaubt eine „durchgehende“ IPsec - Verbindung. Für weitere Informationen möchte ich auf die Diplomarbeit von Horst Achim Huber, „Ein Vergleich der Sicherheitsprotokolle IPsec und TLS in Bezug auf Netzübergänge mit Firewalls“, verweisen.

4. IPsec - FreeS/WAN – Analyse

Abbildung in dieser Leseprobe nicht enthalten

5. FreeS/WAN

5.1 Codebaum

(nur die wichtigsten Dateien, also ohne INSTALL, BUGS, …)

/usr/local/freeswan-1.00/

doc/

Dokumentation von FreeS/WAN

gmp/

GNU Multiple Arithmetik Library

klips/

Abbildung in dieser Leseprobe nicht enthalten

lib/

Bibliothek mit allgemeinen Funktionen für FreeS/WAN

libdes/

DES - Bibliothek (von Eric Young)

pluto/

IKE - Implementation

utils/

FreeS/WAN Utilities

5.2 Die wichtigsten Bestandteile und ihre Quelldateien

FreeS/Wan besteht hauptsächlich aus den Quelldateien zweier Verzeichnisse. Zum einen gibt es das Verzeichnis ‘/klips/net/ipsec‘, in dem alle Dateien abgelegt sind, die zu dem Kernel hinzugefügt werden. Zum anderen gibt es das Verzeichnis ‘/pluto‘, in dem die Quelldateien für die IKE – Implementation „Pluto“ zu finden sind.

5.2.1 /pluto/

connections.c

- Neue ‘connection’ initialisieren

- ‘connections’ löschen

- Informationen über ‘connections’ einholen

- Eine ‘connection‘besteht vorwiegend aus:

- Lebenszeit der SAs (ISAKMP, IPsec)
- Interface
- Quell- und Zielhostaddresse, Netmask

constants.c

- Namenvereinbarungen

crypto.c

- Ent- und Verschlüsseln einer IKE - Message mit DES / 3DES
- Allgemeine HMAC - / HASH - Mechanismen

cookie.c

- cookie Erzeugung
- Verifizierung des ‘responder – cookies’

defs.c

- Speicherverwaltung

demux.c

- Definiert ‘State Transition Functions’ (z.B. main_inI1_outR1, quick_inI1_outR1 …)
- Liest ( ‘parsed’) eingehende ISAKMP-Messages und ruft die ‘State Transition Functions’ in IPsec_doi.c auf.

endian.h

- big-endian / little-endian

ipsec_doi.c

- Ruft Funktionen aus spdb.c auf wo die SA-Payloads „geparsed“ werden.
- SKEYIDs, IV, HASHx und Oakley-keys werden erstellt.
- stellt die verschiedenen Oakley – Messages zusammen

kernel.c

- IPsec-SPIs werden erstellt (und nach /dev/ipsec geschrieben), gelöscht
- Ipsec - Connections werden "geroutet"

kernel_comm.c

- „whack communicating routines“

log.c

- Log Routinen

main.c

- Hauptprogramm von Pluto
- Verwaltung der Optionen
- Ruft die einzelnen Routinen auf, um eine IPsec - SA zu erstellen

md5.c

- MD5-Algorithmen der Firma “RSA Data Security”

packet.c

- Definiert den ISAKMP - Header und die verschiedenen Payloads

preshared.c

- Liest die Datei, in der der ‘preshared - key’ hinterlegt ist, und extrahiert Hostadressen und das ‘secret’

rnd.c

- Generiert Zufallszahlen und den ‘resonder - cookie’

server.c

- Initialisiert ‘whack - socket‘
- Initialisiert die Interfaces und ruft bei ankommenden Paketen ‘comm_handle’ aus demux.c auf

sha1.c

- SHA-1 Hash - Routinen

spdb.c

- Definitionen der möglichen Security Associations :

- Oakley (Main Mode) SA Database
- IPsec (Quick Mode) SA Database

- Schlägt SAs bei Oakley Exchange Phase 1 vor

- wertet ISAKMP und IPsec SAs – Vorschläge aus

state.c

- Erstellen der Message IDs (für Quick Mode Exchange).
- Erstellt ‘states’ von SAs.
- Verwaltet ‘state table’.
- Verschiedene Funktionen aus ‘state’-objekte (delete, copy,...).

timer.c

- Verwaltet die ‘events’.

- Ruft je nach ‘event’ die entsprechende Funktion auf (z.B. EVENT_SA_REPLACE

-> IPsecdoi_replace(...) )

whack.c

- ‘options handling‘
- Baut Connections (tcp) auf und gibt Nachrichten an pluto weiter.

5.2.2 /klips/net/ipsec/

ipsec_ah.h

- allgemeine Deklarationen des AH - Headers

ipsec_encap.h

- definiert die Strukturen der (ESP -) Authentifizierungs- und Verschlüsselungsmethoden
- Deklarationen für den ‘encapsulation-mode‘

ipsec_esp.h

- definiert die Strukturen der (ESP -) Authentifizierungs- und Verschlüsselungsmethoden
- allgemeine Deklarationen des ESP - Headers

ipsec_init.c

- holt Informationen über SPIs, eroutes ...usw. ein
- Initialisiert Netzwerkinterfaces über IPsec_netlink

ipsec_md5c.c

- MD5 Algorithmen der Firma “RSA Data Security”

ipsec.netlink.c

- initialisiert Netzwerkinterfaces
- ruft verschiedene Funktionen von ‘radij.c’ auf (IPsec_breakeroute, IPsec_makeroute ...)

ipsec_radij.c

- "interface between the IPSEC code and the radix tree code"
- verschiedene Operationen auf IPsec - Routen

ipsec_rcv.c

- ‘check-reply-window’ Routine

ipsec_sha1.c

- SHA1 Algorithmen

ipsec_tunnel.c

- Code für den IPsec - Tunnelmodus

ipsec_xform.c

- Sucht passenden Tunneldeskriptorblock (tdb) zu SA
- führt der SA entsprechende Tranformationen durch
- Initialisiert, löscht, ... “tdb”

radij.c

- "routines to build and maintain radix trees and routing lookups" ( ‘radix’ ist ein Sortieralgorithmus ; ein ‘radix tree’ ist wahrscheinlich eine Art Binär Baum)

sysctl_net_IPsec.c

- "sysctl interface to the net IPSEC subsystem"

siehe auch:

/klips/doc/func_tree.txt

- Die (Kernel) Funktionen in der Reihenfolge in der sie aufgerufen werden. Die Datei scheint allerdings etwas veraltet zu sein.

5.3 Kernel Integration

in …/freeswan-1.00/klips/patches sind folgende patch – Dateien enthalten :

Documentation.Configure.help

drivers.isdn.isdn_net.c

drivers.net.Space.c

include.linux.in.h

include.linux.proc_fs.h

kernel.patch.gen.sh

net.Config.in

net.Makefile

net.ipv4.af_inet.c

net.ipv4.protocol.c

net.netlink.c

net.netsyms.c

die Kerneldateien aus klips werden in /usr/src/linux/net eingelinkt :

/usr/src/linux/net/ipsec -> /usr/local/freeswan-1.00/klips/net/ipsec

5.4 Zufallzahlengenerierung

FreeS/WAN benutzt die pseudo – random Funktion ‘random‘ aus der ‘stdlib.h‘, bzw. ‘dev/random‘.

6. Quellenangaben

Bücher:

IPsec

The New Security Standard for the Internet, Intranets, and Virtual Private Networks, Naganand Doraswamy, Dan Harkins, Prentice Hall PTR, 1999

Handbook of Applied Cryptography, Alfred J Menezes, Paul C.van Oorschot, Scott A. Vanstone, CRC Press, 1996

Links:

FreeS/WAN

http://www.xs4all.nl/~freeswan

IPsec

http://kepler.informatik.uni-oldenburg.de/lehre/SicherheitVS/IPsec

VPN unter Linux: FreeS/WAN, IPsec

http://www.mazanec.com/vpn

Virtuelle private Netze – weltweite LANs

http://www.rz.uni-karlsruhe.de/~Tobias.Zimmer/vpn/t15_txt.html

IPsec Internet Drafts

(Virtual Private Network Consortium)

http://www.vpnc.org/ids.html

IETF

http://www.ietf.org

RFCs / Drafts:

Abbildung in dieser Leseprobe nicht enthalten

draft-ietf-ipsec-ike-01.txt

draft-ietf-ipsec-pki-req-04.txt

Sonstiges:

Internet Security,

The IETF Proposals on IP Security Protocol, Key Management and Public Key Infrastructure,

Michael Bungert,

Dezember 1997

(Siemensinterner Bericht)

Diplomarbeit TU München,

„Ein Vergleich der Sicherheitsprotokolle IPsec und TLS in Bezug auf Netzübergänge mit Firewalls“,

Horst Achim Huber

15. Dezember 1997

7. Glossar

Abbildung in dieser Leseprobe nicht enthalten

8. Anhang

8.1 FreeS/WAN – Dokumentation / HowTo

Inhalt

0. Allgemeines

1. Voraussetzungen

2. Installation / Start
2.1 Installation
2.2 Starten von IPsec
2.3 Die Dateien

3. Bedienung / Konfiguration
3.1 Die Konfigurationsdateien
3.2 Bedienung

0. Allgemeines

Im Rahmen des 1.praktischen Semesters an der FH München habe ich mich bei Siemens mit dem Thema IP Security beschäftigt. Als praktisches Anschauungsobjekt kam dabei die IPsec – Implementierung FreeS/WAN in der Version 1.00 zum Einsatz.

Diese Dokumentation bezieht sich auf die FreeS/WAN Version 1.0. Während der Erstellung der Dokumentation wurde die Version 1.1 veröffentlicht. Ich beziehe mich in dieser Dokumentation nur auf die Version 1.0, da sich in der neueren Version nichts Grundsätzliches geändert hat. Hauptsächlich wurden Fehler entfernt. Die erwähnenswerteste Neuerung ist vielleicht, daß FreeS/WAN jetzt auch mit dem Kernel 2.2.12 und RedHat 6.0 funktioniert.

1. Voraussetzungen

In der Orginaldokumentation von wird ausdrücklich darauf hingewiesen, daß FreeS/WAN nur unter RedHat 5.2 mit Kernel 2.0.36 getestet wurde. Ältere Kernel 2.0.xx sollen auch gehen, werden aber wegen der geringeren Stabilität nicht empfohlen.

Da bei Siemens eine sternförmige Ethernet-Topologie verwendet wird, habe ich ein lokales Netzwerk aufgebaut, um "mitsniffen" zu können. Zum Einsatz kamen : ein P133, ein 486 (zum sniffen) und ein P166.

Abbildung in dieser Leseprobe nicht enthalten

2. Installation / Start

2.1 Installation

Nachdem RedHat 5.2 installiert ist, besorgt man sich noch den aktuellen 2.0.36-3 Kernel, da bei RedHat 5.2 nur der pre-release Kernel 2.0.36-0.7 enthalten ist, und installiert einen an das System angepaßten Kernel. Zu diesem Zeitpunkt sollte auch getestet werden, daß zwischen den beiden Hosts Daten übertragen werden können.

Das VPN-Tool FreeS/WAN kann man unter ‘http://www.xs4all.nl/~freeswan‘ beziehen.

FreeS/WAN setzt voraus, daß die Kernel - Sourcen unter ‘/usr/src/linux‘ und die Manpages unter ‘/usr/local/man‘ liegen.

Die Software wird normalerweise in einem Unterverzeichnis von ‘/usr/local‘ kopiert und entpackt.

Mit 'make install' im FreeS/WAN - Verzeichnis wird die Software installiert. Danach werden mit 'make menugo' die Kernelquellen gepatched, KLIPS (Kernel IP Security) wird in die Quellen eingefügt und die Kernelkonfiguration aufgerufen.

Unter 'Networking Options' sollten auf jeden Fall 'IP: forwarding - gatewaying', 'IP: tunneling' und 'Kernel/User Network Link Driver' enabled sein (ist voreingestellt). Weiterhin sieht man, daß jetzt auch IPsec in den Einstellungen auftaucht. Auch hier sind die Einstellungen von FreeS/WAN gemacht worden und können so belassen werden.

Nachdem man mit 'save and exit' das Menü verlassen hat, wird auto - matisch der Kernel übersetzt, aber noch nicht installiert. Wenn dann in der letzten Zeile 'utils/errcheck out.kbuild' steht, ist alles gut gegangen. Jetzt muß man nur noch den Kernel von dem root - Verzeichnis aus mit 'make kinstall' installieren und evtl. den Lilo anpassen. Nach 'make kinstall' sollte diesmal 'util/errcheck out.kinstall' in der letzten Zeile stehen.

2.2 Starten von IPSEC / FreeS/WAN

IPsec wird von nun an in den Runlevels 2-5 bzw. mit '/etc/rc.d/init.d/ipsec start' (stop) manuell gestartet (gestopped).

Die FreeS/WAN Utilities befinden sich in /usr/local/lib/ipsec/ und werden entweder von dort oder mit '/usr/local/sbin/ipsec [programm]' gestartet.

2.3 Die Dateien

Dateien in ‘/etc/rc.d/init.d/‘

ipsec [start] [stop]

Die IPsec – Route wird mit dem ‘device ipsec0‘ in die Routingtabelle eingetragen.

Die Utilities in /usr/local/lib/ipsec/ :

look :

Gibt den Status aus, ob eine IPsec - Verbindung besteht, zwischen wem, usw.. Ist in der ipsec.conf 'klipsdebug=all' gesetzt, werden ausführlichere Informationen angezeigt.

setup [start][stop][restart] :

Dadurch wird klips und pluto gestartet, ist also dasselbe wie 'etc/rc.d/init.d/ ipsec <start,stop,restart>.

manual [--up] [--down] <connection> :

Manuelles auf und abbauen einer IPsec - Verbindung.

auto [--add] [--up] [--down] <connection> :

Automatischer Aufbau einer Verbindung (durch Pluto). Dadurch werden alle ‘x‘ Stunden neue ‘keys‘ ausgetauscht. Die Anzahl der Stunden ‘x‘ wird in der Datei ipsec.conf festgelegt.

ranbits :

Zufallsgenerator zum Erstellen von Schlüsselmaterial.

barf :

Listet jede Menge (!!!) Debug - Informationen auf ( von 'netstat -r' bis 'var/log/messages' ).

Die anderen Utilities und Dateien (klipsdebug, pluto, eroute, spi, spigrp, tncfg, whack) werden von den oben genannten Shellscripts genutzt. Für jedes Script gibt es auch eine Manpage. Für genaue Informationen:

.../freeswan-1.00/doc/manpages.html .

Dateien in /etc :

IPsec.conf :

Hier werden die Parameter für den Verbindungsaufbau festgelegt. Dies ist damit die wichtigste Konfigurationsdatei bei FreeS/WAN. Man könnte sagen das ist die SPD von FreeS/WAN.

IPsec.secrets :

Hier wird der Schlüssel für den manuellen Aufbau hinterlegt.

3. Bedienung / Konfiguration

3.1 Die Konfigurationsdateien

Folgende Konfigurationsdateien, kamen bei meiner FreeS/WAN – Analyse auf beiden Rechnern zu Einsatz.

IPsec.conf :

- /etc/IPsec.conf - FreeS/WAN IPSEC configuration file

- basic configuration

config setup

- virtual and physical interfaces for IPSEC, normally a single

- `virtual=physical' pair, or a (quoted!) list of pairs. In the

- simple case, where you only want to run IPSEC on one interface,

- the virtual (IPsec0) shouldn't need changing but the physical

- (eth999) will (to the interface connecting to the public network,

- e.g. eth0 or ppp0 or something like that).

- *This must be right* or almost nothing will work. interfaces="IPsec0=eth0"

- should setup turn IP forwarding on after IPSEC is started, and off

- before it is stopped? forwardcontrol=yes

- KLIPS debugging output. "none" for none, "all" for lots klipsdebug=all

- Pluto debugging output. "none" for none, "all" for lots plutodebug=all

- manually-keyed connections to set up at startup manualstart=

- connections to load into Pluto's internal database at startup plutoload=

- connections for Pluto to try to negotiate at startup plutostart=

- should Pluto wait for each negotiation to finish before proceeding? plutowait=yes

- connection specifications

- sample tunnel (manually or automatically keyed)

- Here we just use ESP for both encryption and authentication, which is

- the simplest and often the best method.

conn sample

type=tunnel

left=139.23.202.107

right=139.23.203.58

- (manual) base for SPI numbering; must end in 0 spibase=0x200

- (manual) encryption/authentication algorithm and parameters to it esp=3des-md5-96

espenckey=0x8da4c959_e1663a75_6b5a2a4f_c9622184_de829409_dc50d902

espauthkey=0xb66c8398_b21becfa_176ddda6_a3a4472f

- (auto) key-exchange type keyexchange=ike

- (auto) key lifetime (before automatic rekeying) keylife=8h

- (auto) how persistent to be in (re)keying negotiations (0 means very) keyingtries=0

IPsec.secrets :

In dieser Datei werden die Schlüssel festgehalten die für die Verbindung von zwei hosts benötigt werden. Der zweite Rechner muß für die gleiche Verbindung auch den gleichen Schlüssel benutzen.

- This file holds shared secrets which are currently the only inter-Pluto

- authentication mechanism. See IPsec_pluto(8) manpage. Each secret is

- (oversimplifying slightly) for one pair of negotiating hosts.

139.23.202.107 139.23.203.58 "0xde121115_38cb9fc7_ee7f7f6c_a6971730_3fd114ef_b4e08416_867cd2b6_307c72d9"

Die 'connection specifications' in der ipsec.conf und ipsec.secrets müssen auf beiden Rechner identisch sein.

3.2 Bedienung

Nachdem IPsec gestartet ist, durch einen Neustart oder explizites Aufrufen ('/etc/rc.d/init.d/IPsec start'), erscheint das ‘device ipsec0‘ beim Aufruf von 'ifconfig'. Zu diesem Zeitpunkt wird der Verkehr noch unverschlüsselt zwischen den beiden hosts übertragen. Als nächstes startet man den Tunnel mit '/usr/local/lib/IPsec/ manual --up sample' (auf beiden Rechnern) . Ab diesem Zeitpunkt sollte eine sichere Verbindung hergestellt sein. Fährt man die Verbindung nur mit

'/usr/local/lib/IPsec/ manual --down sample'

(beide Rechner) wieder herunter, ist keine Verbindung mehr möglich, da die Route immer noch gesetzt ist. Erst nachdem man die Route gelöscht oder IPsec wieder gestoppt hat ist eine ungesicherte Verbindung möglich.

Normalerweise sollte man die Verbindung mit

'/usr/local/lib/IPsec/ auto --add sample'

(auf einem Rechner = Initiator) und

'/usr/local/lib/IPsec/ auto --up sample'

(auf beiden Rechnern) starten.

Dadurch werden automatisch nach einer festgelegten Zeit neue Schlüssel generiert und ausgetauscht. Die Verbindung wird mit

'/usr/local/lib/IPsec/ auto --down sample'

(auf beiden Rechnern) wieder heruntergefahren.

8.2 Pluto – Log - Datei

(/var/log/secure)

Abbildung in dieser Leseprobe nicht enthalten

Details

Seiten
47
Jahr
2000
Dateigröße
456 KB
Sprache
Deutsch
Katalognummer
v96616
Institution / Hochschule
Hochschule München
Note
Schlagworte
Security Eine Analyse FreeS/WAN IPsec Realisierung

Autor

Teilen

Zurück

Titel: IP Security - Eine Analyse der FreeS/WAN IPsec - Realisierung