Freitag, 10. Februar 2012

News

präsentiert von: entwickler.com
Donnerstag, 1. März 2007

About Security #95: Virtuelle Private Netze — IPsec anschaulich

Um IPsec nutzen zu können, muss, nachdem wie in About Security #94 beschrieben mit IKEv2 eine Sicherheitsassoziation ausgehandelt wurde, ggf. die Security Policy Database (SPD) angepasst werden. Dies ist (wie in About Security #92 erwähnt) nicht die Aufgabe von IKE, sondern eigener Protokolle. IKE-Implementierungen können es jedoch trotzdem übernehmen. Die in den Traffic Selectors übertragenen Informationen können dann zur Aktualisierung der SPD verwendet werden, ansonsten erlauben sie die Kontrolle der Übereinstimmung der SPD-Einträge. Im Folgenden wird davon ausgegangen, dass die in der SPD gespeicherten Security Policies korrekt sind. Ob mit oder ohne Anpassung ist dabei unerheblich. Damit können alle in Zukunft übertragenen Pakete bei Bedarf durch IPsec-Protokolle geschützt werden.

Da zwei Gateways miteinander verbunden sind, wird IPsec im Tunnelmodus betrieben. Die Kommunikationspartner prüfen bei jedem ein- und ausgehenden Paket anhand von Quell- und Zieladresse und Protokoll, wie mit dem Paket zu verfahren ist. Enthält der zuständige SPD-Eintrag die Anweisung 'PROTECT' wird das Paket entsprechend der zugehörigen SA behandelt.

ESP im Tunnelmodus

Zuerst soll der Einsatz des Encapsulating Security Payload (ESP) Protokolls im Tunnelmodus betrachtet werden: Die angenommene SA legt dann fest, dass für die betreffenden Pakete das IPsec-Protokoll ESP verwendet werden soll. Als Krypto-Algorithmen soll AES-128 für die Verschlüsselung und SHA1 für die Authentifizierung verwendet werden. Die ebenfalls in der SA gespeicherten Schlüssel dafür wurden aus den mit IKEv2 ausgetauschten öffentlichen Diffie-Hellman- und Zufallswerten berechnet. Damit ergeben sich für die unter dieser SA zu übertragenen Pakete folgende Anpassungen:

Ursprüngliches IPv4-Paket:
Version
(4 Bit)
Headerlänge
(4 Bit)
Servicetype
(8 Bit)
Gesamtlänge in Bytes
(16 Bit)
Identifikation
(16 Bit)
Flags
(3 Bit)
Fragment-Offset
(13 Bit)
Time to Live
(8 Bit)
Protokoll
(8 Bit)
Header-Prüfsumme
(16 Bit)
Quell-IP-Adresse
(32 Bit)
Ziel-IP-Adresse
(32 Bit)
IP-Optionen und Füllzeichen
(insgesamt 32 Bit)


Daten: TCP-Header + TCP-Payload



IPv4-Paket mit ESP im Tunnelmodus:
Version
(4 Bit)
Headerlänge
(4 Bit)
Servicetype
(8 Bit)
Gesamtlänge in Bytes
(16 Bit)
Identifikation
(16 Bit)
Flags
(3 Bit)
Fragment-Offset
(13 Bit)
Time to Live
(8 Bit)
Next Header = ESP (*)
(8 Bit)
Header-Prüfsumme
(16 Bit)
Quell-IP-Adresse
(32 Bit)
Ziel-IP-Adresse
(32 Bit)
IP-Optionen und Füllzeichen
(insgesamt 32 Bit)
(*) Security Parameter Index (SPI)
(32 Bit)
Sequenznummer
(32 Bit)
 
(**) ursprünglicher IP-Header,
TCP-Header und -Payload
 
 
Padding
 
                             
Padding Length
(8 Bit)
Next Header = IP (**)
(8 Bit)

Integrity Check Value (ICV)
mit SHA1 über die gelb markierten Feldern berechnete Authentifizierungsdaten


Im Protokollfeld des neuen IP-Headers wird als 'Next Header' ESP eingetragen und damit auf das transportierte ESP-Paket (grau markiert) verwiesen (siehe die (*)-Markierungen). Der ursprüngliche IP-Header sowie TCP-Header und -Payload werden mit AES-128 verschlüsselt in den Datenbereich des ESP-Pakets kopiert. Im 'Next Header'-Feld des ESP-Headers wird IP eingetragen und damit auf das in ESP transportierte IP-Paket verwiesen (siehe die (**)-Markierungen).

Schutzmaßnahmen: Der ursprüngliche IP-Header, TCP-Header und -Payload, Padding, 'Padding Length'- und 'Next Header'-Feld werden mit AES-128 verschlüsselt (blau markiert), die verschlüsselten Daten sowie das SPI- und Sequenznummer-Feld danach durch mit SHA1 berechnete Authentifizierungsdaten vor unerkannten Änderungen geschützt (gelb markiert).

AH im Tunnelmodus

Statt ESP soll nur AH mit SHA1 als Authentifizierungsalgorithmus verwendet werden, da eine Verschlüsselung nicht notwendig ist:

IPv4-Paket mit AH im Tunnelmodus:
Version
(4 Bit)
Headerlänge (4 Bit) Servicetype
(8 Bit)
Gesamtlänge in Bytes
(16 Bit)
Identifikation
(16 Bit)
Flags
(3 Bit)
Fragment-Offset
(13 Bit)
Time to Live
(8 Bit)
Protokoll = AH
(8 Bit)
Header-Prüfsumme
(16 Bit)
Quell-IP-Adresse
(32 Bit)
Ziel-IP-Adresse
(32 Bit)
IP-Optionen und Füllzeichen
(insgesamt 32 Bit)
Next Header = IP
(8 Bit)
Payload-Length
(8 Bit)
Reserviert
(16 Bit)
Security Parameter Index (SPI)
(32 Bit)
Sequenznummer
(32 Bit)
Integrity Check Value (ICV):
mit SHA1 über alle gelb markierten Feldern berechnete Authentifizierungsdaten
Version
(4 Bit)
Headerlänge
(4 Bit)
Servicetype
(8 Bit)
Gesamtlänge in Bytes
(16 Bit)
Identifikation
(16 Bit)
Flags
(3 Bit)
Fragment-Offset
(13 Bit)
Time to Live
(8 Bit)
Protokoll = TCP
(8 Bit)
Header-Prüfsumme
(16 Bit)
Quell-IP-Adresse
(32 Bit)
Ziel-IP-Adresse
(32 Bit)
IP-Optionen und Füllzeichen
(insgesamt 32 Bit)


Daten: TCP-Header + TCP-Payload


Im Protokollfeld des neuen IP-Headers wird als Protokoll AH eingetragen und damit auf das transportierte AH-Paket (grau markiert) verwiesen. Der ursprüngliche IP-Header sowie TCP-Header und -Payload werden unverändert in den Datenbereich des AH-Pakets kopiert. Im 'Next Header'-Feld des AH-Headers wird IP eingetragen und damit auf das im AH-Paket transportierte IP-Paket verwiesen.

Schutzmaßnahmen: Alle außer den weiß markierten Feldern werden durch mit SHA1 berechnete Authentifizierungsdaten vor unerkannten Änderungen geschützt (gelb markiert).

Transport- statt Tunnelmodus

Wird IPsec statt im Tunnel- im Transportmodus betrieben, z.B. weil es sich um ein Host-to-Host-VPN handelt, entfallen die ursprünglichen IP-Header im ESP- bzw. AH-Paket und in den 'Next Header'-Feldern wird statt auf den IP- auf den TCP-Header verwiesen.

In der nächsten Folge wird ein weiteres VPN-Protokoll vorgestellt: PPTP, das 'Point-to-Point Tunneling Protocol'.

Wenn Sie Fragen oder Themenvorschläge haben, können Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security - Übersicht zum aktuellen Thema "VPN - Virtuelle Private Netze"

Kommentare

Konferenzen

BASTA! 2012

BASTA! 2012

27.- 2. März 2012
Maritim Hotel Darmstadt

MobileTech Conference

MobileTech Conference

26.-28. März 2012
München

JAX 2012

JAX 2012

16.-20. April 2012
Rheingoldhalle, Mainz

BigData Con 2012

BigData Con 2012

16.-18. April 2012
Rheingoldhalle, Mainz

Business Technology Days

Business Technology Days

17.-19. April 2012
Rheingoldhalle, Mainz

International PHP Conference

International PHP Conference

3.- 6. Juni 2012
Maritim proArte, Berlin

webinale 2012

webinale 2012

4.- 6. Juni 2012
Maritim proArte Berlin

RailswayCon

RailswayCon

4.- 6. Juni 2012
Maritim proArte, Berlin

Werbung
Top-Jobs

Fraunhofer-Institut für Windenergie und Energiesystemtechnik IWES

Informatikerin / Informatiker

Magazine

Entwickler Magazin - Enterprise Technologies & Business Solutions

Entwickler Magazin

Enterprise Technologies & Business Solutions

dot.net magazin - die unabhängige Quelle für .NET-Technologien

dot.net magazin

Die Quelle für .NET-Technologien

Eclipse Magazin

Eclipse Magazin

Weltweit erstes Magazin für Eclipse-Entwickler

Java Magazin - Internet & Enterprise Technology

Java Magazin

Internet & Enterprise Technology

Sharepoint

Sharepoint Magazin

Sharepoint

CREATE OR DIE - Ein Leben für die Kreativität

CREATE OR DIE

Ein Leben für die Kreativität

Business Technology - Management Magazin

Business Technology

Management Magazin

PHP Magazin - Professional PHP Development

PHP Magazin

Professional PHP Development

PHP User - Praktische Referenz für Internetenthusiasten

PHP User

Praktische Referenz für Internetenthusiasten

Bücher




Webhosting mit Host Europe