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)
Häufig gestellte Fragen
Was ist IPsec und wozu dient es?
IPsec ist ein neuer Sicherheitsstandard, der eine sichere Datenübertragung zwischen zwei Teilnehmern ermöglicht und zur Bildung von VPNs verwendet wird. Es implementiert Sicherheitsmechanismen auf IP-Ebene, wodurch darüberliegende Protokolle und Anwendungen diese Sicherheitsmechanismen nicht bemerken.
Aus welchen Hauptkomponenten besteht IPsec?
IPsec basiert hauptsächlich auf IKE (Internet Key Exchange) und den Protokollen ESP (Encapsulating Security Payload) und AH (Authentication Header). IKE ist für den sicheren Schlüsselaustausch und die Verwaltung der SAs (Security Associations) zuständig. AH und ESP sorgen für die Authentifizierung bzw. Verschlüsselung der übertragenen Daten.
Was ist IKE und welche Phasen beinhaltet es?
IKE (Internet Key Exchange) besteht aus ISAKMP (Internet Security Association and Key Management Protocol) und Teilen von Oakley und Skeme. Es definiert einen Schlüsselaustausch in zwei Phasen: In Phase 1 wird eine SA erstellt, um eine sichere Verbindung zwischen den IKE-Partnern herzustellen. In Phase 2 wird eine weitere protokollabhängige (IPsec) SA gebildet. Phase 1 kann entweder im "Main Mode" oder "Aggressive Mode" implementiert werden, während Phase 2 immer im "Quick Mode" implementiert wird.
Was sind Security Associations (SAs) und wie werden sie identifiziert?
Eine SA (Security Association) definiert, in welchem Modus eine IPsec-Verbindung verwendet wird (Tunnel- oder Transportmodus), welche Sicherheitsalgorithmen verwendet werden und wie lange sie gültig ist. Sie enthält auch die Schlüssel für die Ent- und Verschlüsselung. SAs sind unidirektional, daher benötigt jeder Kommunikationspartner zwei SAs. Eine SA wird durch das Tripel Zieladresse, SPI (Security Parameter Index) und Sicherheitsprotokoll identifiziert.
Was ist der Security Parameter Index (SPI)?
Der SPI (Security Parameter Index) ist eine maximal 32 Bit lange Zeichenfolge, die mit jedem Paket mitgeschickt wird. Sie identifiziert zusammen mit der Zieladresse und dem Sicherheitsprotokoll diejenige SA, die zum Entschlüsseln und/oder Authentifizieren des Pakets verwendet werden muss.
Was sind die Security Association Database (SAD) und Security Policy Database (SPD)?
Die SAD (Security Association Database) speichert die aktuell existierenden SAs. Die SPD (Security Policy Database) ist eine geordnete Liste von Sicherheitsanforderungen (Policy Entries). Jeder Policy Entry (PE) wird ein oder mehreren Selektoren zugeordnet. In einer PE wird beschrieben, was mit ankommenden oder ausgehenden Paketen geschehen soll (discard, bypass oder apply).
Was sind die Unterschiede zwischen AH und ESP?
AH (Authentication Header) stellt die Integrität und den Ursprung der Daten sicher und schützt vor Replay-Attacken. ESP (Encapsulating Security Payload) ermöglicht die Verschlüsselung von Datenpaketen und stellt ebenfalls die Vertrauenswürdigkeit und den Ursprung der übertragenen Daten sicher. ESP kann sowohl Verschlüsselung als auch Authentifizierung bieten, während AH nur Authentifizierung bietet.
Welche IPsec-Modi gibt es und was sind ihre Anwendungsbereiche?
Es gibt im Wesentlichen zwei IPsec-Modi: den Transportmodus und den Tunnelmodus. Im Transportmodus werden die darüberliegenden Protokolldaten (TCP, UDP, …) geschützt, während im Tunnelmodus das gesamte IP-Paket geschützt wird. IPsec wird in verschiedenen Szenarien eingesetzt, darunter End-to-End-Verbindungen (Host-to-Host), Virtual Private Networks (VPNs) und Remote-Host-Zugriffe.
Was ist FreeS/WAN und wozu dient es?
FreeS/WAN ist eine IPsec-Implementierung für Linux. Es ermöglicht die Einrichtung sicherer Verbindungen und VPNs unter Verwendung von IPsec-Protokollen.
Wo finde ich die wichtigsten Konfigurationsdateien für FreeS/WAN?
Die wichtigsten Konfigurationsdateien für FreeS/WAN sind ipsec.conf (hier werden die Parameter für den Verbindungsaufbau festgelegt) und ipsec.secrets (hier wird der Schlüssel für den manuellen Aufbau hinterlegt). Beide Dateien befinden sich normalerweise im Verzeichnis /etc.
- Quote paper
- Benedikt Kiessling (Author), 2000, IP Security - Eine Analyse der FreeS/WAN IPsec - Realisierung, Munich, GRIN Verlag, https://www.hausarbeiten.de/document/96616
