Grundlagen IPsec

IPsec steht für „Internet Protocol Security“
IPSec ist eigentlich eine Rückportierung von IPv6 zur Absicherung von IPv4. In IPv6 ist IPSec bereits fester Bestandteil. Mit IPSec wird Zugriffskontrolle, Datenintegrität, Verschlüsselung und Authentifizierung gewährleistet. Da IPSec jedoch auf Layer 3 arbeitet, werden diese Dienste nur für IP–Pakete und darüberliegende Protokolle angeboten.

Die IPSec Dienste werden durch eines von zwei Protokollen bereitgestellt, durch den Authentication Header (AH) bzw. durch Encapsulating Security Payload (ESP). Ferner wird Internet Key Exchange (IKE) als Protokoll zum Schlüsseltausch bzw. zur Schlüsselverwaltung gemeinsam mit dem Internet Security Association and Key Management Protocol (ISAKMP) verwendet.

Hier eine Übersicht der entsprechend relevanten RFC:
RFC 2401    Sicherheitsarchitektur für das Internetprotokoll
RFC 2402    Authentication Header
RFC 2406    Encapsulating Security Payload
RFC 2407    IPsec Domain of Interpretation (IPsec DoI)
RFC 2408    Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409    Internet Key Exchange (IKE)

Security Associations (SA)
Das SA–Konzept ist Grundlage für den Einsatz von IPSec. Dort wird definiert, welche Sicherheitsmaßnahmen für ein Paket herangezogen werden. SAs können dynamisch zwischen Sender und Empfänger eingerichtet werden. Eine SA wird durch drei Parameter identifiziert:

• Ziel IP–Adresse: Adresse des Endpunktes der SA
• Security Protocol Identifier: Protokollnummer (AH, ESP)
• Security Parameter Index (SPI): 32 Bit Zahl

Wichtig ist, dass die Source IP–Adresse hier nicht verwendet wird. Dies hat den Grund, da eine SA nur zur Verbindung zweier Stationen und zum Senden der Daten in eine Richtung verwendet wird. Wenn bidirektional Daten gesendet werden sollen, müssen zwei SAs eingerichtet werden.

Einen “IPsec tunnel” gibt es nicht!
Es gibt jedoch zwei unterschiedliche Typen innerhalb der IPsec Spezifikation: Transport mode und Tunnel mode

Eine SA kann grundsätzlich in einem dieser beiden Modi arbeiten. Der Transport Mode wurde entwickelt, um Protokolle höherer Layer zu schützen. Im Tunnel Mode wird das ursprüngliche IP–Paket einfach in ein neues Paket eingepackt. Somit wird das gesamte Paket, inklusive Header, verschlüsselt, womit per Tunnel Mode größere Sicherheit für das ursprüngliche Paket gewährleistet ist.

Beim Transport Mode der ursprüngliche IP–Header modifiziert und ein Security Header wird dahinter platziert. Im Header steht nun, dass nicht sofort die Daten folgen, sondern zuvor noch ein Security Header.

Im Tunnel Mode wird der Header hingegen nicht modifiziert, sondern das gesamte Paket wird die Nutzlast für ein neues IP–Paket, mit neuem Header.

Zusätzlich unterscheiden wir noch die beiden Methoden AH und ESP.

Authenticaticated Header (AH)
AH erlaubt eine Authentifizierung des Pakets. AH verwendet den Authentication Header, um das Paket zu authentifizieren. Dieser Header wird im IP–Paket nach dem IP–Header platziert. Natürlich kann das AH – Protokoll im Transport und im Tunnel Mode eingesetzt werden.

Im Transport Mode wird der ursprüngliche IP–Header der Header des neuen Pakets und dahinter kommt der AH. Der Vorteil ist, dass hier nur wenige zusätzliche Bytes für das Paket benötigt werden. Doch da das ursprüngliche IP–Paket als Header verwendet wird, kann dieser Modus nur zwischen zwei Hosts verwendet werden, da die Source und Destination IP–Adresse nicht geändert werden kann.

Im Tunnel Mode wird ein neuer IP–Header generiert, hinter welchem der AH platziert wird. Das ursprüngliche IP–Paket wird die Nutzlast dieses neuen Pakets. Diese Variante ist somit sicherer, da das gesamte Originalpaket verschlüsselt übertragen wird.

Encapsulated Security Payload (ESP)
Genau wie bei AH werden auch bei ESP–Verwendung zusätzliche Informationen zum IP–Paket hinzugefügt. Doch ESP verwendet nicht nur ein zusätzliches Feld wie AH, sondern es werden drei Teile an verschiedenen Stellen im IP–Header platziert. Diese Teile sind:

• ESP Header: Dieser wird nach einem neuen bzw. nach dem modifizierten IP–Header platziert
• ESP Trailer: Dieser steht am Ende des ursprünglichen IP-Pakets
• ESP Authentication Feld: Dies steht nach dem ESP Trailer

Bei Verwendung vom Transport Mode wird wieder das ursprüngliche IP–Paket modifiziert und dahinter der ESP-Header platziert. Hinter das Paket wird außerdem der ESP-Trailer und das ESP Authentication Feld eingefügt. Falls das ursprüngliche IP–Paket bereits IPSec Security Header (z.B. AH) beinhaltet hat, wird der ESP Header vor diese Header gestellt. Da der Originalheader verwendet wird, kann die Source und Destination IP–Adresse nicht verändert werden. Somit kann auch ESP Transport Mode nur zwischen zwei Hosts verwendet werden.

Bei ESP im Tunnel Mode wird ein neuer IP–Header generiert, hinter welchem der ESP-Header gestellt wird. Danach folgt das ursprüngliche IP–Paket, samt Header, als Nutzlast. Am Ende des Pakets wird der ESP Trailer und das ESP Authentication Feld hinzugefügt. Dieser Modus erlaubt die Verschlüsselung des gesamten Originalpakets, inklusive Header und ist somit sicherer.

Unterschied: AH – ESP
Bei AH wird nur eine Authentifizierung gewährleistet, während ESP zusätzlich zur Authentifizierung auch das Paket verschlüsselt.

Internet Key Exchange (IKE)
IKE ist ein Protokoll zur Schlüsselverwaltung. ESP und AH spezifizieren zwar, wie die Security Dienste den IP–Paketen zugeordnet werden sollen, es wird aber nicht geklärt, wie SAs eingerichtet werden. Hierbei gibt es zwei Möglichkeiten. Die manuelle Konfiguration durch den Administrator, oder die eher bevorzugte dynamische SA–Einrichtung per IKE. Aufgebaut ist IKE auf dem ISAKMP–Framework.

Internet Security Association and Key Management Protocol (ISAKMP)
Hier wird definiert, wie ein Endpunkt authentifiziert wird, wie eine SA erstellt und verwaltet wird, welche Techniken zur Schlüsselerzeugung angewandt werden und wie die Bedrohung durch diverse Angriffe vermindert werden kann. Dies ist wichtig, um eine sichere Verbindung und Kommunikation über das Internet gewährleisten zu können. ISAKMP kann im Zusammenhang mit verschiedenen Protokollen verwendet werden. Zum Schlüsseltausch verwendet ISAKMP das Diffie Hellman Verfahren. Es kann jedoch auch mit einem Shared Key gearbeitet werden.

Mögliche Angriffsszenarien
Oft werde ich gefragt wie IPsec sich bei "replay Attacken" oder "IP Spoofing" verhält.

Replay Attack:
Im Falle eines Replay Angriffs sammelt der Angreifer alte Nachrichten, um diese später gezielt wieder einzuspielen. Die Sequenznummer in den Paketen des ESP und des AH verhindert die Wiedereinspielung von alten Daten, sofern auch die ESP-Pakete durch Authentifizierung geschützt sind, da Pakete mit einer alten Sequenznummer oder ungültigem MAC verworfen werden. Des Weiteren enthalten die Cookies Zeiteinträge, die ebenfalls einen Replay Angriff aufzeigen.

IP Spoofing:
Beim IP Spoofing ändert ein Angreifer seine IP–Adresse, um z.B. an Daten heranzukommen, die nur aus einem internen Firmennetz abrufbar sind. Die Fälschung der IP–Adresse kann mit IPSec durch Verwendung des AH entdeckt und blockiert werden, da der Angreifer nicht im Besitz des entsprechenden Schlüssels ist, um einen gültigen AH zu einem gefälschten Paket zu erzeugen.

Sicherheitslücke in IPsec!
Drei Angriffsmöglichkeiten die herstellerunabhängig auf IPsec Implementierungen angewendet werden können, wurden bisher identifiziert. Wer Encapsulating Security Payload (ESP) im Tunnel mode mit "confidentiality only" nutzt, oder eine Konfiguration unter Verwendung von AH zur Erhaltung der Integrität verwendet, ist anfällig gegen diese Sicherheitslücke im Design von IPsec.

Detailiertere Informationen finden dazu finden Sie hier: NISCC Vulnerability Advisory IPSEC – 004033

Weitere Informationen zum Thema Netzwerverschlüsselung

Was Sie schon immer über TCP/IP wissen wollten
Schützen von Netzwerken mit IPSec
Server- und Domänenisolierung mithilfe von IPSec und Gruppenrichtlinien
Windows Server 2003 Security Guide

Interessanter Hotfix zum Thema

How to simplify the creation and maintenance of Internet Protocol (IPsec) security filters in a Windows Server 2003-based environment
This update removes the requirement for explicit network infrastructure permit filters and for special filters to help secure a subnet. To remove this requirement, this update introduces enhanced behavior for the "fallback to clear" functionality. The fallback to clear functionality is enhanced in the following two ways:

• The fallback to clear time-out value is reduced from 3 seconds to 500 milliseconds (ms).
• Credential and policy mismatch failures are now permitted to use the fallback to clear functionality.
   

cu
//.<