IPsec

Aus wiki@ANOnet
Wechseln zu: Navigation, Suche

IPsec ist eine der besten, im Moment verfügbaren Sicherheitstechnologien. Da es allerdings schwer zu verstehen IST und schwer zu konfigurieren sein KANN, ist es wenig verbreitet, und noch weniger Personen haben wirklich tiefgreifende Kenntnisse.

Inhaltsverzeichnis

Allgemeines:

IPsec wurde 1998 entwickelt, um die Schwächen des Internetprotokolls (IP) zu beheben. Technische Beschreibung: RFC 2401

Funktion: Wenn zwei Hosts eine IPsec-gesicherte Verbindung verwenden, werden zwei Arten von Sicherheitszuordnungen erstellt. In Phase Eins (Main-Mode) wird von den Endpunkten (Router/Computer/…) eine gegenseitige Authentifizierung durchgeführt, um eine Vertrauensstellung zwischen den beiden Hosts einzurichten. In Phase Zwei (Quick-Mode) werden die Einzelheiten der Sicherheitszuordnung ausgehandelt. In dieser Phase wird festgelegt, wie der Netzverkehr verschlüsselt bzw. signiert wird. Während die Signierung der Pakete sicherstellt, dass diese beim Transport nicht verändert werden, verhindert die Verschlüsselung, dass ein eventueller Angreifer die Daten bei der Übertragung lesen kann. Ebenso werden Playback-Angriffe verhindert.



Der Verbindungsaufbau:

Schlüsselaustausch:

X manual keying: hier wird der Schlüssel manuell an beiden Tunnelendpunkten eingegeben. Dadurch ist der Schlüssel statisch, d.h. er wird nicht verändert, was wieder eine Sicherheitslücke darstellt. Daher ist das manual-keying nicht zu empfehlen.
X IKE. Das InternetKeyExchange-Protokoll übernimmt die automatische Schlüsselverwaltung. Es bedient sich des Diffie-Hellman-Verfahrens, um die schlüssel sicher über ein unsicheres Netz auszutauschen. :Die RFC zu IKE ist 2409

IKE definiert, wie Sicherheitsparameter vereinbart und gemeinsame Schlüssel ausgetauscht werden.

Vor der Eigentlichen Verbindung via IPsec müssen sich beide Tunnelendpunkte erst einmal authentifizieren und auf einen gemeinsamen Algorithmus einigen. Hierzu ist IKE gedacht. Zur Authentifizierung wird entweder ein Zertifikat oder ein PSK, ein Pre-Shared-Key verwendet. IKE verwendet standardmäßig UDP500 als Quell- und Zielport. Wird allerdings genattet, stimmt dies nicht mehr. Um die Maskierungsproblematik zu umgehen, wurden verschiedene Lösungsansätze geboren, allerdings erreichte keiner eine Standardisierung. Somit ist IPsec hinter Masquerading-Firewalls immer eine Bastellösung, und ist wenn möglich zu vermeiden..

IKE arbeitet in zwei Phasen:

1. Aushandlung einer SA (Security Association) für ISAKMP entweder über den Aggressive Mode (Aggressiver Modus) oder Main Mode (Hauptmodus) 2. Erzeugung einer SA für IPsec mittels Quick Mode (Schnellmodus)

Eine Security Association (SA) ist eine Vereinbarung zwischen den beiden kommunizierenden Seiten und besteht aus den Punkten:

1. Identifikation (entweder per PSK oder Zertifikate) 2. Festlegung des zu verwendenden Schlüsselalgorithmus für die IPsec Verbindung 3. von welchem (IP-) Netz die IPsec-Verbindung erfolgt 4. zu welchem (IP-) Netz die Verbindung bestehen soll 5. Zeiträume, in denen eine erneute Authentifizierung erforderlich ist 6. Zeitraum, nachdem der IPsec-Schlüssel erneuert werden muss

Die beiden Phasen des Verbindungsaufbaues:

Phase 1, Main Mode Nun genaueres zur Phase 1, der SA-Aushandlung. Diese kann entweder über den Main- oder den Aggressive-mode geschehen, wobei der Main-Mode vorzuziehen ist. Mainmode: Die Verschlüsselungsaushandlung passiert in folgenden Schritten:

1. Der Initiator, also der Endpunkt, der die Verbindung aufbauen will, schickt seine Vorschläge der Authentifizierungs- sowie Verschlüsselungsalgorithmen 2. Der Responder, die Gegenstelle, wählt aus dem Angebotenen den für ihn sichersten, möglichen Algorithmus 3. Der Initiator schickt seinen öffentlichen Teil des Diffie-Hellman-Systems und einen zufälligen Wert (die Nonce) 4. Der Responder antwortet ebenso mit seinem öffentlichen Teil und einem Zufallswert. Dieser Wert dient später, in Schritt 5, der Authentifizierung

Nun, da beide Endpunkte den öffentlichen Teil des DH des anderen haben, wird dieses Verfahren genutzt, um den geheimen Schlüssel zu berechnen. Dieser wird für die Verschlüsselung nach dem in Punkt 2 gewählten Verschlüsselungsverfahren verwendet

5. Der in Punkt 4 errechnete Schlüssel wird ausserdem für die Erzeugung eines Schlüssels für die Authentifizierung verwendet, welche durch zwei Verfahren geschehen kann:

a. Mittels eines vorher vereinbarten Schlüssels, ? PSK (für Pre-Shared-Key)
PSK sollte nur verwendet werden, wenn die Anzahl der IPsec-Teilnehmern überschaubar bleibt, da es einen entscheidenden Nachteil hat: sollte dieser Schlüssel bekannt werden, warum auch immer, müssen unverzüglich auf allen Hosts die Schlüssel getauscht werden. Ebenso sollte dieses Verfahren nicht verwendet werden, wenn erwartet wird, dass das Netzwerk wächst. Der Mehraufwand für die Cert-Auth sollte sich schnell bezahlt machen
b. Zertifikatsbasierend
Hier wird diese Problematik von einer anderen Seite angegangen. Eine CA erstellt ein Zertifikat, welches von einer Root-CA signiert wird, ähnlich den Zerts bei https. Hier hat es sich allerdings durchgesetzt, dass die Zertifikate nicht von öffentlichen CAs ausgestellt werden, sondern dass eine eigene PKI (public-key-infrastructure) eingesetzt wird. Dadurch kann gezielt gesteuert werden, wer auf das VPN zugreifen kann.

Der große Vorteil einer zertbasierenden Lösung ist aber, dass eine CA jederzeit ein ausgestelltes Zertifikat widerrufen kann. So muss im Falle eines Einbruchs ins Netz nicht an allen Hosts der Schlüssel geändert werden, was in großen Netzwerken unendlich Zeit spart.

So unterschiedlich die beiden Verfahren auch ausschauen, die grundsätzliche Vorgangsweise ist die gleiche: Es wird jeweils ein Hashwert über den mittels Diffie-Hellman erzeugten Schlüssels, die Identität, dem ausverhandelten Verschlüsselungsverfahren sowie den bisher versendeten Nachrichten gebildet, verschlüsselt und versendet. Der effektiv verwendete Schlüssel ist also nur der Hash

Aggressive Mode Für die Kommunikation, in der zumindest einer der Partner keine feste IP-Adresse besitzt, wurde das Verfahren Aggressive Mode gefertigt. Während beim Main Mode im Verbindungsaufbau sechs Nachrichten ausgetauscht werden, reduziert sich diese Zahl im Aggressive Mode auf drei. Diese Nachrichten etablieren die Kommunikation durch Authentisierung der Gesprächspartner und Einigung auf eine Verschlüsselungsmethode.


Phase 2, Quick Mode Der Quick Mode kommt in der zweiten Phase von IKE zur Anwendung. Die gesamte Kommunikation in dieser Phase erfolft verschlüsselt. Wiederum wird ein Vorschlag gemacht, der zusammen mit einem Hash und dem Nonce übertragen wird, Dann werden die Schlüssel neu berechnet, wobei keine Informationen aus den zuvor generieren SAs einfließen. Dadurch wird verhindert, dass von vorher generierten Schlüsseln nicht auf die neuen geschlossen werden kann (PFS, Perfect Forward Secrecy) Um dies zu erreichen, findet erneut DH erneut Einsatz. Die Geheimnisse zur Schlüsselbildung werden verworfen, sobald der Austausch vollzogen ist.

Authentication Header (AH)

AH stellt die Authentizität der übertragenen Pakete sicher, und authentifiziert den Sender. Ebenso Schützt AH gegen Replay-Angriffe. Die Nutzdaten werden nicht verschlüsselt

Encapsulating Security Payload (ESP)

ESP soll die Authentifizierung, Integrität und Vertraulichkeit von IP-Paketen sicherstellen. Im Unterschied zum AH wird der Header des IP-Paketes vom ICV (integrity check value, Wert des Integritätstests) nicht berücksichtigt. Jedoch werden die Nutzdaten verschlüsselt übertragen.

Transport/Tunnelmodus

Transportmodus Beim Transport Mode bleibt der ursprüngliche IP-Header erhalten. Es wird lediglich der AH-bzw. ESP-Header nach dem IP-Header eingefügt. In diesem Modus wird nur die Nutzlast des transportierenden Paketes verschlüsselt. Es handelt sich um eine so genannte Kapselung der Datenpakete. Da nur die Nutzdaten verschlüsselt werden, also Source- und Destinationadresse für eventuelle Angreifer sichtbar sind, ist dieser Transportmodus nicht so sicher wie der Tunnelmodus. Der Vorteil dieses Modi ist, dass die Rechenzeit beim ver- und entschlüsseln gering bleibt, was für einen Einsatz in Real-Time-Anwendungen wie VoIP notwendig sein kann.

Tunnelmodus Dieser Modus wird vor allem von Security-Gateways verwendet. Diese Gates verschlüsseln den gesamten Verkehr zwischen zwei Netzen. Der Rechner im LAN schickt ein Paket zum Gateway, welches das Paket verschlüsselt und an das Ziel-Gate durch das Internet schickt, wo das Paket wieder entschlüsselt und dem Empfänger zugestellt wird. Folglich sind hier sind die Nutzdaten das eigentlich zu versendende Datenpaket. Der Vorteil des Tunnel-Mode ist, dass einem eventuellen Angreifer die eigentliche Quelle sowie das eigentliche Ziel verborgen bleiben, und er kann nur die Tunnel-Endpunkte ausfindig machen.

NAT-Problematik

IPsec verwendet unter anderem zwei Protokolle (Authentication Header[AH] & Encapsulating Security Payload [ESP]) die Beschreiben, wie z.b. die Verbindung in einem VPN gehandhabt wird.


Der Authentication Header enthält einen Hash-Wert, der über das gesamte, ursprüngliche IP-Paket gebildet wird, einschliesslich Quell- u. Zieladresse, und zur Identifizierung beim Empfänger dient. Wird auch nur ein Feld des Ur-Paketes, z.b durch NAT bei der Übersetzung der lokalen in eine öffentliche IP, verändert, stimmt der Hash-Wert nicht mehr und das Paket wird abgelehnt. (Ausgenommen ttl u. Prüfsumme, da diese sich bei der Übertrahung ändern, werden sie ausgeschlossen) AH soll so unter anderem verhindern, dass manipulierte IP-Paketen ins System gelangen.

Beim Encapsulating Security Payload ist es etwas komplizierter. Hier wird auch ein Hash-Wert gebildet, allerdings nicht über das gesamte IP-Paket, sondern nur über die Nutzlast (Payload). Bestandteil des Payloads ist u.a. TCP. NAT muss die TCP-Checksumme modifizieren, um die Integrität zu erhalten. Damit stimmt ESP-Hash nicht mehr. Verzichtet man auf die Modifizierung der Checksumme, stimmt die TCP-Integrität nicht mehr. Das Ergebnis ist in beiden fällen gleich: die Pakete werden abgelehnt.

Für dieses Problem gibt es allerdings eine Lösung, wenn beim Empfänger die Checksummenprüfung für TCP ausgeschaltet werden kann. Dann können passieren die Pakete NAT und werden nicht verworfen... ABER...

Das nächste Problem entscheidender Bestandteil von IPsec für die Partner, die eine verschlüsselte Verbindung aufnehmen wollen, ist die Authentifizierung. Das Schlüsselmanagement übernimmt das IKE-Protokoll (Internet Key Exchange). Am meisten verbreitet ist die Verwendung von preshared keys, die im Wesentlichen auf der Quell-IP des Datenpaketes aufbauen. Kommt ein Datenpaket am Router an, übersetzt dieser die ursprüngliche Quell-IP und die Authentifizierung des Paketes scheitert.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Werkzeuge