IPsec - Security Architecture for IP
IPsec ist eine Erweiterung des Internet-Protokolls (IP) um Verschlüsselungs- und Authentifizierungsmechanismen. Damit erhält das Internet-Protokoll die Fähigkeit IP-Pakete kryptografisch gesichert über öffentliche unsichere Netze zu transportieren. IPsec wurde von der Internet Engineering Task Force (IETF) als integraler Bestandteil von IPv6 entwickelt. Weil das Internet-Protokoll der Version 4 ursprünglich keine Sicherheitsmechanismen hatte, wurde IPsec für IPv4 nachträglich spezifiziert.
Bestandteile von IPsec-VPNs
- Interoperalitität
- kyptografischer Schutz der übertragenen Daten
- Zugangskontrolle
- Datenintegrität
- Authentisierung des Absenders (Benutzerauthentisierung)
- Verschlüsselung
- Authentifizierung von Schlüsseln
- Verwaltung von Schlüsseln (Schlüsselmanagement)
Hinter diesen Bestandteilen stehen Verfahren, die miteinander kombiniert eine zuverlässige Sicherheit für die Datenübertragung über öffentliche Netze bieten. VPN-Sicherheitslösungen mit hohen Sicherheitsanforderungen setzen generell auf IPsec.
Einsatz-Szenarien
- Site-to-Site-VPN / LAN-to-LAN-VPN / Gateway-to-Gateway-VPN
- End-to-Site-VPN / Host-to-Gateway-VPN / Remote-Access-VPN
- End-to-End-VPN / Host-to-Host-VPN / Remote-Desktop-VPN / Peer-to-Peer-VPN
Prinzipiell eignet sich IPsec für Gateway-zu-Gateway-Szenarien. Also die Verbindung von Netzen über ein unsicheres Netz. Ebenso denkbar ist das Host-zu-Gateway-Szenario, dass dem Remote-Access-Szenario entspricht. Wobei die Komplexität von IPsec und einige Unzulänglichkeiten von TCP/IP hier gelegentlich Probleme bereiten können. Eher untypisch ist das Host-zu-Host-Szenario, aber ebenso möglich.
IPsec hat den Nachteil, dass es nur IP-Pakete tunneln kann. Außerdem ist es ohne zusätzliche Protokolle eher ungeeignet für Remote Access, da die Funktionen zur Konfiguration von IP-Adresse, Subnetzmaske und DNS fehlen. Deshalb macht es Sinn, zur Realisierung eines VPNs außer IPsec auch L2TP (Layer 2 Tunneling Protocol), PPTP (Point-to-Point Tunneling Protocol) oder SSL-VPN in Betracht zu ziehen.
IPsec Vertrauensstellungen - Security Association
Hauptbestandteil von IPsec sind die Vertrauensstellungen (Security Association) zwischen zwei Kommunikationspartnern. Eine Vertrauensstellung muss nicht zwangsläufig zwischen den Endpunkten (Client) einer Übertragungsstrecke liegen. Es reicht aus, wenn z. B. bei der Kopplung zweier Netze die beiden Router über eine Vertrauensstellung verfügen. Selbstverständlich dürfen auch mehrere Vertrauensstellungen für eine Verbindung vorhanden sein.
Die Vertrauensstellungen regeln die Kommunikation von IPsec. Die relativ flexiblen Kombinationen von Vertrauensstellungen erfordern einen sehr hohen Konfigurationsaufwand.
Um eine gesicherte Verbindung zwischen zwei Stationen aufbauen zu können, müssen auf beiden Seiten einige Parameter ausgetauscht werden:
- Art der gesicherten Übertragung (Authentifizierung oder Verschlüsselung)
- Verschlüsselungsalgorithmus
- Schlüssel
- Dauer der Gültigkeit der Schlüssel
Vertrauensstellungen werden durch den Austausch vorab definierter Schlüssel hergestellt. Eine andere Form ist die Vergabe von Zertifikaten durch ein Trust-Center oder einen installierten Zertifikate-Server. Schlüssel und Zertifikate sollen sicherstellen, dass derjenige welcher einen Schlüssel oder ein Zertifikat besitzt, auch derjenige ist, für den er sich ausgibt. Ähnlich wie bei einem Personalausweis, mit dem sich eine Person gegenüber einer anderen Person ausweist.
- Pre-Shared Keys (PSK)
- X.509-Zertifikate
Schlüssel oder Zertifikate, ganz egal, beide Methoden benötigen viel Zeit und Sorgfalt bei der Einrichtung. Die einfachere Variante ist der geheime Schlüssel (Passwort bzw. Passphrase). Wichtig ist, dass die beiden Endpunkte über IP-Adresse, Subnetzmaske, Tunnelname und den geheimen Schlüssel informiert sind. Zusätzlich gibt es Parameter, die die Details der Authentisierung, Verschlüsselung und die Länge des Schlüssels festlegen.
Bei der Authentifizierung mit Pre-Shared Key muss ein Identifier konfiguriert werden. Der Identifier ist zusätzliche Angabe, anhand der sich die Gegenstellen (Gateway und Client) identifizieren können. Häufig werden dafür IP-Adressen, DNS-Namen (FQDN) oder E-Mail-Adressen (FQUN) verwendet.
Tunneling und Verschlüsselung
Die zentralen Funktionen in der IPsec-Architektur sind das AH-Protokoll (Authentification Header), das ESP-Protokoll (Encapsulating Security Payload) und die Schlüsselverwaltung (Key Management). Authentizität, Vertraulichkeit und Integrität erfüllt IPsec durch AH und ESP.
Für den Aufbau eines VPN gibt es in IPsec den Authentication Header (AH) und den Encapsulating Security Payload (ESP). Beide können gemeinsam oder eigenständig genutzt werden. In beiden Verfahren findet eine gesicherte Übertragung statt.
Das AH-Protokoll sorgt für die Authentifizierung der zu übertragenen Daten und Protokollinformationen. Das ESP-Protokoll erhöht die Datensicherheit in Abhängigkeit des gewählten Verschlüsselungsalgorithmus.
IPsec setzt kein bestimmtes Verschlüsselungs- und Authentifizierungsverfahren voraus. Gängige Verfahren sind DES, Triple-DES (3DES) und SHA-1. Weil IPsec-Implementierungen kein bestimmtes Verfahren beherrschen müssen, entstehen häufig Probleme, wenn unterschiedliche VPN-Produkte zusammenarbeiten müssen.
Schlüsselverwaltung mit IKE - Internet Key Exchange Protocol
Es gibt zwei Wege für die Verwaltung und Verteilung der Schlüssel innerhalb eines VPNs. Neben der reinen manuellen Schlüsselverwaltung, kann auch das Internet Key Exchange Protocol (IKE) eingesetzt werden.
Vor der geschützten Kommunikation müssen sich die Kommunikationspartner über die Verschlüsselungsverfahren und Schlüssel einig sein. Diese Parameter sind Teil der Sicherheitsassoziation (Vertrauensstellungen) und werden von IKE/IKEv2 automatisch ausgehandelt und verwaltet.
Das Internet-Key-Exchange-Protokoll dient der automatischen Schlüsselverwaltung für IPsec. Es verwendet das Diffie-Hellman-Verfahren zum sicheren Erzeugen von Schlüsseln über ein unsicheres Netz. Auf Basis dieses Verfahren wurden einige Schlüsselaustauschverfahren entwickelt, die zum Teil die Grundlage für Internet Key Exchange bilden.
IKE basiert auf dem Internet Security Association and Key Management Protocol (ISAKMP). ISAKMP ist ein Regelwerk, das das Verhalten der beteiligten Gegenstellen genau festlegt. Wie das zu erfolgen hat, legt IKE fest. Die Flexibilität von IKE äußert sich in seiner Komplexität. Wenn unterschiedliche IPsec-Systeme keine Sicherheitsassoziationen austauschen können, dann liegt das meistens an einer fehlerhaften IKE-Implementierung oder fehlende Verschlüsselungsverfahren.
Version 2 des Internet-Key-Exchange-Protokolls (IKEv2) vereinfacht die Einrichtung eines VPNs. Es ist wesentlich einfacher, flexibler und weniger fehleranfällig. Insbesondere soll das Mobility and Multihoming Protocol (MOBIKE) dafür sorgen, dass IPSec-Tunnel in mobilen Anwendungen erheblich zuverlässiger funktionieren.
IKEv2 korrigiert einige Schwachstellen bzw. Probleme der Vorgänger-Version. Die Definition wurde in ein Dokument zusammengefasst, der Verbindungsaufbau vereinfacht und viele Verbesserungen hinzugefügt. Insgesamt ist IKEv2 weniger komplex als die Vorgänger-Version. Das erleichtert die Implementierung und erhöht die Sicherheit.
IKEv2 ist allerdings nicht abwärtskompatibel zu IKE. Beide Protokolle werden aber über denselben UDP-Port betrieben.
Im Zusammenhang mit IPsec werden häufig die Begriffe Main Mode und Aggressive Mode verwendet. Es handelt sich dabei um unterschiedliche Verfahren zur Schlüsselaushandlung.
VPN mit IPsec in der Praxis
Die Netzwerkteilnehmer im LAN 1 können auf das LAN 2 zugreifen bzw. umgekehrt die Teilnehmer aus LAN 2 auf das LAN 1. Die Verbindung über das Internet läuft über einen verschlüsselten Tunnel ab.
Die beiden Firewalls müssen beim Verbindungsaufbau ihre Identität eindeutig nachweisen. Somit ist unberechtigter Zugang ausgeschlossen. Die Kommunikation über das Internet erfolgt verschlüsselt. Sollte ein Dritter die Datenpakete protokollieren erhält er nur Datenmüll.
Damit beide Netze eine Verbindung zueinander aufbauen können muss die IP-Adresse des jeweiligen anderen Netzes bekannt sein. Für einen Verbindungsaufbau ist deshalb eine feste IP-Adresse notwendig, sonst wird der Verbindungsaufbau kompliziert. Ändert sich die IP-Adresse eines Netzes, z. B. beim Verbindungsaufbau zum Internet-Provider oder Zugangsnetzbetreiber, dann müssen die Adressen gegen neue ausgetauscht werden. Entweder manuell oder per dynamische DNS-Einträge mit DDNS.
Damit das Routing zwischen den Netzen funktioniert müssen die Adressbereiche innerhalb der Netze unterschiedlich sein. Da die Netze sich nach der Zusammenschaltung wie eines verhalten, dürfen IP-Adressen nicht doppelt vorkommen. Deshalb muss vorab auf beiden Seiten ein eigener Adressbereich, also unterschiedliche Subnetze, konfiguriert werden.
Probleme mit NAT
Ist sichergestellt, dass die VPN-Gegenstellen die gleichen Verschlüsselungsverfahren unterstützen und die IKE-Implementierung fehlerfrei ist, dann kann der Schlüsselaustausch mit IKE noch an den beteiligten NAT-Routern scheitern.
Wenn Netzwerk-Stationen in lokalen Netzen (LAN) private IP-Adressen haben und per NAT-Router ins Internet gehen, dann hat IPsec Probleme mit NAT. Durch NAT erhält ein IPsec-Paket eine neue IP-Adresse und einen anderen Quell-Port. Das Problem dabei, wird ein IPsec-Paket verändert, dann wird es ungültig.
Ein weiteres Problem ist, dass Original-IP-Adressen und TCP-Ports verschlüsselt sind. So kommt der NAT-Router nicht an sie heran. Und so ist eine Zuordnung der IP-Pakete zu einer Netzwerk-Station nicht möglich. Die dafür erforderliche Information wird während des gesicherten Schlüsselaustauschs übertragen. Und da hat der NAT-Router keinen Einblick. Die Information wird im SPI-Wert (Security Parameters Index) mitgegeben. Somit könnte der VPN-Tunnel einem Host zugeordnet werden. Doch wegen der verschlüsselten Übertragung des SPIs kann der NAT-Router diesen Wert nicht mitlesen.
Um beide Probleme zu umgehen, beherrschen manche Router das IPsec-Passthrough-Verfahren, bei dem die Ports nicht verändert werden. Leider funktioniert Passthrough nur mit einem einzigen Client im Netzwerk.
IPsec-Passthrough (veraltet)
Bei IPsec-Passthrough wird die Port-Zuordnung (IKE) nicht verändert. Die IP-Adresse der ESP-Pakete wird dabei für einen Client umgeschrieben. Das bedeutet, die mit ESP behandelten Pakete können nur einer Verbindung und einem Client zugeordnet werden. Deshalb funktioniert IPsec-Passthrough hinter einem NAT-Router nur mit einem einzigen Client.
Weil in der Regel immer mehr als ein Client eine IPsec-Verbindung betreiben möchte, ist IPsec-Passthrough kaum noch in Gebrauch. Man setzt auf die IPsec-Erweiterung NAT-Traversal. Dabei werden die ESP-Pakete in UDP-Pakete verpackt und über den Port 4500 verschickt. Dann können NAT-Router IP-Adressen und Ports umschreiben.
IPsec mit NAT-Traversal
Weil das ursprüngliche IPsec über NAT-Router nicht funktioniert setzt man es in der Regel mit der IPsec-Erweiterung NAT-Traversal ein. In diesem Szenario tauschen beide Kommunikationspartner über das NAT-Traversal-Protokoll verschiedene Informationen aus. Im Anschluss werden die ESP-Pakete in UDP-Pakete verpackt und über Port 4500 verschickt. Dann können die NAT-Router ohne Probleme IP-Adressen und Ports umschreiben.
NAT-Traversal ist im IKE-Protokoll integriert (Negotiation of NAT-Traversal in the IKE). Während des Aufbaus einer IKE Security Association, wird versucht zu erkennen, ob sich ein NAT-Router zwischen den Gegenstellen befindet. Wenn ja, dann wird die Einkapselung der IPsec-Pakete in UDP-Pakete ausgehandelt. Das bedeutet, das zwischen IP-Header und ESP-Header ein UDP-Header eingefügt wird. Die vollständige Bezeichnung dafür ist UDP Encapsulation of IPsec ESP Packets. In der Regel bezeichnet man diesen Vorgang als IPsec-NAT-Traversal.
Damit das funktioniert muss der Responder den Port 4500 (UDP und TCP) geöffnet haben. Der Responder ist derjenige, der auf die Initialisierung der IKE Security Association antwortet.
IPsec wird in der Regel immer mit der Erweiterung NAT-Traversal verwendet. Es funktioniert praktisch mit jedem NAT-Router.
Ablauf zum Aufbau eines VPNs mit IPsec und NAT-Traversal (vereinfacht)
- Zuerst wird ermittelt, ob die Gegenstelle die notwendigen Verfahren überhaupt beherrscht.
- Dann wird versucht die NAT-Router auf dem Übertragungsweg zu erkennen.
- NAT-Keep-Alive wird auf der richtigen Seite aktiviert. Das sorgt dafür, dass die Einträge in der Tabelle der NAT-Router nicht aufgrund von Timeouts gelöscht werden.
- Bei Bedarf, das ist die Regel, wird NAT-Traversal aktiviert.
- Danach beginnt die Aushandlung der Vertrauensstellungen. Dazu generiert das eine Ende von zwei VPN-Endpunkten eine Anfrage an das Zielsystem. Das Zielsystem antwortet und leitet den Schlüsselaustausch per Internet Key Exchange (IKE) ein. Beide Endpunkte handeln dabei Verschlüsselungs- und Authentisierungsverfahren aus. Über einen Schlüssel oder ein Zertifikat, das beide System kennen, wird eine Vertrauensstellung zueinander hergestellt. Für beide Seiten wird dann der digitale Master-Schlüssel erzeugt.
- Beide Seiten legen dann die Verschlüsselungs- und Authentisierungsverfahren für die Datenübertragung fest. Mit dem Master-Schlüssel wird der Schlüssel für die Datenübertragung erzeugt.
- Die Daten werden dann ausgetauscht und die Verbindung hergestellt.
Probleme mit einer Firewall bei NAT-Traversal
Damit IPsec-Verbindungen mit NAT-Traversal möglich sind, müssen die Firewalls auf beiden Seiten die verschlüsselten Datenpakete durchlassen. Die Authentisierung erfolgt über den UDP-Port 500 oder 4500. In der Regel müssen diese Ports in der Firewall geöffnet werden.
Die verschlüsselten Datenpakete werden über das IP-Protokoll 50, dem ESP (Encapsulated Security Payload), oder dem IP-Protokoll 51, AH (Authentication Header), verschickt.
Der sichere Transport von UDP-Paketen wird durch geeignete Maßnahmen im ISAKMP erreicht. So kann man auf das verbindungsorientierte TCP verzichten. Auf diese Weise haben auch viele Angriffsversuche keine Chance.
Wie sicher ist IPsec?
VPNs auf Basis von IPsec gelten als die sichersten VPNs. Allerdings ist IPsec vergleichsweise schwer zu konfigurieren. Der Aufbau eines IPsec-VPNs ist komplex und fehleranfällig. Damit ein IPsec-VPN funktioniert müssen viele Dinge reibungslos zusammenspielen. Wobei es dabei nicht nur um technische, sondern auch um organisatorische Dinge geht. Wenn mal auf der technischen Seite etwas nicht funktioniert kommt man nur sehr schwer hinter das Problem und muss per Trial & Error eine Lösung finden.
IPSec hat seit der Einführung von IKEv2 in der Handhabung und Flexibilität enorm aufgeholt. Ein weiterer Vorteil ist die Standardisierung. Durch spezielle Prozessoren haben VPN-Gateways sehr viel Leistung, können viele parallele Verbindung bedienen, sind dadurch skalierbar und zukunftssicher.
IPsec gilt im Bereich VPN als der Standard, an dem man nicht vorbei kommt. Weil IPsec eine lange Entwicklungszeit hinter sich hat, gilt es als sehr sicher. Vor allem auch deshalb, weil die Sicherheit immer wieder verbessert wurde. Aber, bei IPsec hat man es mit den Produkten unterschiedlicher Hersteller, die trotz Standard untereinander nicht oder nur begrenzt kompatibel sind.
Zudem gelten kommerzielle Implementierungen von IPsec angesichts der Enthüllungen um die NSA-Geheimdienstaktivitäten nicht mehr als vertrauenswürdig. Mit kommerziellen IPsec-Lösungen und -Produkten erwirbt der Kunde eine Black-Box, die er nicht überprüfen kann. So kann er nicht prüfen, ob das Produkt eventuell Hintertüren enthält.
Alternativen zu IPsec: SSL-VPN und OpenVPN
Eine Alternative zu IPsec ist SSL-VPN. Dahinter steckt SSL bzw. TLS. Der wichtigste Vorteil von SSL-VPN ist ein quasi Client-loser Betrieb. Die Verbindung kann mit jedem Browser aufgebaut werden. Wenn jedoch andere Anwendungen diese Verbindung nutzen sollen, dann braucht man eine Art Gateway auf der Client-Seite. Zum Beispiel ein Java- oder ActiveX-Plugin. Beide Browser-Erweiterungen sind häufig auch Einfallstore für Hacker, weil sie Sicherheitslücken enthalten.
Eine weitere Alternative ist OpenVPN. OpenVPN ist eine Open-Source-Lösung und erfreuen sich deshalb immer größerer Beliebtheit. Im Vergleich zu IPsec hat man Zugriff auf den Quellcode. Im Vergleich zu SSL-VPN kann es IP-Pakete tunneln und unabhängig von der Anwendung übertragen. OpenVPN arbeitet auf Basis von OpenSSL und existiert für alle gängigen Betriebssysteme.