IPsec: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(22 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
−
=Einführung=
+
[[Kategorie:IPsec]]
 +
=Allgemein=
 +
*[[IPSEC Begriffserklärung]]
 +
=Verschiedenes=
 +
*[[Diffie Hellman]]
 +
*[[Site-to-Site-VPN-IPSEC]]
 +
*[[IPsec und die Firewall]]
 +
*[http://de.wikipedia.org/wiki/Perfect_Forward_Secrecy PFS]
 +
*[http://einstein.informatik.uni-oldenburg.de/rechnernetze/security_database.htm SPD]
 +
*[http://einstein.informatik.uni-oldenburg.de/rechnernetze/security_association.htm SAD]
  
−
IPsec (Kurzform für Internet Protocol Security) ist eine Protokoll-Suite, die eine gesicherte Kommunikation über potentiell unsichere IP-Netze wie dem Internet ermöglichen soll.
+
*[[IPSEC Vortäge]]
−
 
+
*http://www.unixwiz.net/techtips/iguide-ipsec.html
−
Im Gegensatz zu anderen Verschlüsselungsprotokollen wie etwa SSL, das auf der Transportschicht des TCP/IP-Referenzmodells aufbaut, arbeitet IPsec direkt auf der Internetschicht (Internet layer) des TCP/IP-Protokollstapels. Damit ist es für die Anwendung transparent.
 
−
 
 
−
IPSec kann lokale Netze oder auch einzelne Clients mit privaten Netzwerkadressen über das Internet verbinden. Dazu werden die ursprünglichen IP-Pakete verschlüsselt und in neue Pakete eingepackt. Beim Empfänger werden die Pakete wieder ausgepackt, entschlüsselt, geprüft und weitergeleitet.
 
−
 
 
−
Bevor allerdings eine verschlüsselte Verbindung aufgebaut werden kann, müssen sich die beiden Verbindungspartner sicher sein, dass Ihr Gegenüber auch der ist, für den er sich ausgibt (Authentifizierung). Hierzu gibt es zwei Verfahren. Das eine wird Pre-Shared Key (PSK) oder auch Shared Secret genannt. Hierbei kennen beide Seiten ein gemeinsames Passwort. Bei dem anderen Verfahren wird die so genannte Public-Key Kryptographie eingesetzt.
 
−
 
 
−
=Public-Key=
 
−
 
 
−
Public-Key Kryptographie basiert auf einem mathematischen Verfahren, bei dem ein Schlüsselpaar aus einem geheimen Schlüssel (Private Key) und einem dazugehörigen öffentlichen Schlüssel (Public Key) erzeugt wird. Mit dem Public Key verschlüsselte Nachrichten können nur mit dem dazugehörigen Private Key entschlüsselt werden. Hat jemand nur den Public Key, so kann er nur verschlüsseln, nicht aber entschlüsseln.
 
−
 
 
−
Daher können die Public Keys problemlos auf unsicheren Kanälen (z.B. per E-Mail) ausgetauscht werden.
 
−
 
 
−
Die einzige Gefahr besteht darin, dass ein Angreifer den Schlüssel vertauscht haben könnte (sog. Man-in-the-middle Angriff). Wenn Sie ganz sicher gehen wollen, können daher nach dem Schlüsselaustausch die Signaturen (auch Fingerprint genannt) der Schlüssel z.B. am Telefon verglichen werden.
 
−
 
 
−
=Zertifikate=
 
−
 
 
−
Als Erweiterung zum Konzept von öffentlichen und privaten Schlüsseln gibt es Zertifikate. Dabei wird der öffentliche Schlüssel von einer Zertifizierungsstelle (engl. Certification Authority, abgekürzt CA), digital signiert. Das ermöglicht bei größeren Installationen, dass eine Gegenstelle anhand der digitalen Signatur feststellen kann, ob ein Schlüssel gültig ist, ohne dass der Schlüssel selbst vorher installiert wurde.
 
−
 
 
−
Für den Intranator bringt eine solche Zertifizierungsstelle normalerweise nur wenig Vorteile, dennoch setzt der Intranator konsequent den Zertifikatsstandard X.509 ein. Dieser Standard hat sich in der Praxis anstatt einfachen Public-/Private-Key-Paaren durchgesetzt.
 
−
 
 
−
Um die Bedienung zu vereinfachen, erzeugt der Intranator normalerweise selbstsignierte Zertifikate, bei denen der Inhaber (Subject genannt) auch gleichzeitig der Zertifikatsaussteller (Issuer) ist. Dadurch sind bei der Bedienung keine zusätzlichen Schritte für die Verwendung von Zertifikaten nötig. Selbstverständlich können aber auch externe Zertifizierungsstellen verwendet werden.
 
−
 
 
−
 
 
−
=IPSec Verbindungen=
 
−
 
 
−
Ein IPSec Verbindungsaufbau geschieht mit dem Protokoll Internet Key Exchange (IKE) in zwei Phasen.
 
−
 
 
−
Phase 1: Zuerst wird eine gesicherte Verbindung (ISAKMP SA oder IKE SA genannt) aufgebaut. Diese Verbindung wird über UDP Port 500 aufgebaut. Erkennt das System, dass eine Seite hinter einem NAT-Router steht, wird auf UDP Port 4500 umgeschaltet. Es gibt zwei Modi für den Verbindungsaufbau: den Main Mode und den Aggressive Mode. Der Aggressive Mode beschleunigt den Verbindungsaufbau um einige Zehntelsekunden, kann aber leichter geknackt werden. Der Intranator unterstützt daher nur den sicheren Main Mode.
 
−
 
 
−
Phase 2: Die zuvor aufgebaute gesicherte Verbindung wird nun genutzt, um die eigentlichen Verbindungsdaten und Sitzungsschlüssel auszuhandeln (Quick Mode). Ist dies erfolgreich, wird eine sog. IPSec SA konfiguriert und kann dann genutzt werden, um verschlüsselt Daten zu übertragen.
 
−
 
 
−
Beide Phasen der Verbindung haben aus Sicherheitsgründen nur eine begrenzte Lebensdauer und werden daher regelmäßig aktualisiert.
 
−
 
 
−
Aus Sicherheitsgründen und um das Routing zu vereinfachen überprüft jede Seite der Verbindung, dass nur genau die Pakete durch die Verbindung kommen, die vorher konfiguriert wurden. Daher ist es wichtig, dass auf beiden Seiten identische Werte für Start- und Zielnetz eines Tunnels angegeben wurden.
 
−
 
 
−
Damit die Sicherheitsrichtlinien sehr eng konfiguriert werden können, ist es möglich, zwischen zwei Rechnern beliebig viele verschiedene IPSec Verbindungen aufzubauen.
 
−
 
 
−
=Verbindungsaufbau=
 
−
 
 
−
IPsec verwaltet Verbindungen und kann auf Anforderung hin sowohl Verschlüsselung als auch Datenintegrität garantieren. Dazu verwendet es einen von zwei Modi: Der Transportmodus stellt Punkt-zu-Punkt-Kommunikation zwischen zwei Endpunkten her, während der Tunnelmodus zwei Netze über zwei Router verbindet. Beide Modi sind in Bezug auf die zu erstellenden Security Associations recht ähnlich. Die folgende Darstellung betrachtet nur den Transportmodus.
 
−
 
 
−
Wenn ein IP-Paket versendet werden soll, dann werden zwei lokale Datenbanken verwendet:
 
−
 
 
−
#SPD (security policy database)
 
−
 
 
−
        In der SPD ist beispielsweise hinterlegt, wie die Verbindung zwischen den Kommunikationsendpunkten mit den IP-Adressen 80.16.36.1 und 89.1.26.17 gesichert werden soll. Als Sicherungsverfahren werden dann AH, ESP oder beide eingesetzt. Zum Erstellen der Schlüssel wird meist IKE verwendet. Die SPD ist im Vergleich zur SAD (s. u.) eher von statischer Natur, da ein Eintrag in der SPD „zustandslos“ ist.
 
−
 
 
−
#SAD (security association database)
 
−
 
 
−
        SAs zwischen zwei hosts
 
−
        In der SAD werden Security Associations (SA) verwaltet. Diese besitzen einen Zustand (engl. stateful) und ändern sich im Vergleich zu Einträgen in der SPD recht oft. SA-Einträge enthalten u. a. die Schlüssel für das verwendete Protokoll, und sie haben eine begrenzte Gültigkeit. Für AH und ESP existieren jeweils eigene SA-Einträge in der SAD. Eine SA wird meist über das IKE-Protokoll angelegt und wird nur in eine Richtung verwendet: Beim Sender gibt sie das Verschlüsselungsverfahren und den Schlüssel vor, beim Empfänger das passende Entschlüsselungsverfahren. Das Entschlüsseln erfolgt bei der Verwendung von symmetrischer Verschlüsselung mit demselben Schlüssel, der zur Verschlüsselung verwendet wurde. Wenn zwei Hosts AH und ESP verwenden, dann sind je Host vier SA-Einträge notwendig. Im Bild wird dies veranschaulicht.
 
−
 
 
−
==Internet Key Exchange (IKE)==
 
−
Um eine sichere Verbindung im Internet aufzubauen wird ein gemeinsames Verschlüsselungsverfahren benötigt. Durch IKE wird dieses ausgehandelt und der Symmetrische Schlüssel ausgetauscht (aus Performancegründen erfolgt die Übertragung auf der VPN-Strecke nicht asymmetrisch verschlüsselt).
 
−
IKE ist der Quasi-Standart zum automatischen Schlüsselaustausch im Internet es läuft auf UDP-Port 500 und beschreibt den gesamten Ablauf bis zur Erstellung einer gemeinsamen IPSec-SA (Security Association) und wird in 2 Phasen unterteilt:
 
−
===Main Mode===
 
−
 
 
−
Im Main Mode kommt das Diffie-Hellmann-Verfahren eingesetzt um eine verschlüsselte Verbindung aufzubauen. Über diese Verbindung erfolgt die Authentifizierung, z.B. mittels 'preshared secrets' oder X.509.
 
−
Am Ende des Main Mode besitzen beide Seiten einen gemeinsamen Schlüssel über den die weitere Kommunikation abläuft.
 
−
Die in diesem Stadium bestehende SA wird Internet Security Association and Key Managment Protocol  Security Association oder kurz ISAKMP SA gennant.
 
−
 
 
−
[[Datei:main.jpg]]
 
−
 
 
−
===Quick Mode===
 
−
Nachdem durch den Main Mode die Authentizität und die Vertraulichkeit gewährleist ist, wird die ISAKMP SA genutzt um die eigentliche IPSec Security Association abzuschließen.
 
−
Auch bei bestehenden Verbindungen wird der QuickMode gebraucht um von Zeit zu Zeit die Schlüssel auszuwechseln.
 
−
 
 
−
=Algorithmen=
 
−
 
 
−
Beide Seiten einigen sich beim Verbindungsaufbau über die für Verschlüsselung und Datensignierung zu verwendenden kryptographischen Algorithmen. Die Algorithmen sind für jede Phase separat einstellbar. Im Intranator können im Menü Dienste > VPN > Verschlüsselung Profile mit Algorithmen konfiguriert werden.
 
−
 
 
−
Eine Verschlüsselungsmethode besteht dabei aus je einem Algorithmus für Verschlüsselung, für Hashing (Signatur) und einer Diffie Hellman Gruppe für den Aufbau einer gesicherten Verbindung. Die meisten Algorithmen werden in verschiedenen Längen angeboten. Die Länge wird in Bit angegeben und der Algorithmus ist desto stärker, je mehr Bit verwendet werden. Allerdings steigt mit der Bitzahl auch der nötige Rechenaufwand.
 
−
 
 
−
Für beide Phasen wird nun eine Liste von möglichen Methoden hinterlegt. Diese Liste wird in der eingestellten Reihenfolge der Gegenstelle angeboten, die dann die oberste, von ihr auch unterstütze Methode verwendet.
 
−
 
 
−
Auch die Verwendung von Perfect Forward Secrecy (PFS) in Phase 2 wird im Intranator über die Verschlüsselungsprofile konfiguriert. Ist auf dem Intranator eine PFS-Gruppe vorgegeben, wird diese beim Verbindungsaufbau verwendet. Baut die Gegenseite die Verbindung auf, akzeptiert der Intranator die eingestellte und alle stärkeren Gruppen. Ist die PFS-Gruppe auf Keine gestellt, werden Verbindungen ohne PFS aufgebaut. Baut die Gegenseite die Verbindung auf, werden Verbindungen mit und ohne PFS akzeptiert.
 
−
 
 
−
Alle angebotenen Algorithmen bieten aus heutiger Sicht eine ausreichende Stärke. Nicht mehr empfohlene Algorithmen wie z.B. einfaches DES mit 64 Bit werden vom Intranator gar nicht erst angeboten. Allerdings wurden in letzter Zeit in der kryptographischen Forschung einige mögliche Schwachstellen von vor allem MD5 als auch SHA diskutiert. Wir empfehlen daher, so bald wie möglich auf eine der stärkeren SHA2-Varianten (256, 384 und 512 Bit) umzusteigen.
 
−
 
 
−
=Einschränkungen=
 
−
 
 
−
Bei der Entwicklung von IPSec war Voraussetzung, dass keinerlei Information unverschlüsselt oder an nicht autorisierte Gegenstellen versendet werden darf. Leider bringt dies auch einige Einschränkungen in Verbindung mit dynamischen IP-Adressen mit sich:
 
−
 
 
−
Alle Informationen werden verschlüsselt übertragen, also auch die Kennung einer Station. Da bei dynamischen IPs weder anhand der IP-Adresse noch anhand der Kennung entschieden werden kann, welcher Schlüssel zur Entschlüsselung verwendet werden soll, müssen alle diese Gegenstellen denselben Schlüssel verwenden.
 
−
 
 
−
Zum Glück gilt diese Einschränkung nur für das Pre-Shared Key Verfahren; beim Einsatz von Public Key Verfahren kann jede Gegenstelle einen eigenen Schlüssel haben. Durch die Trennung von Public und Private Key ist dies möglich, ohne dass Daten gefährdet werden. Wir empfehlen daher, ausschließlich das Public Key Verfahren zu verwenden.
 
−
 
 
−
 
 
−
=Kompatibilität mit anderen IPSec-Gegenstellen=
 
−
 
 
−
IPSec ist standardisiert und der Intranator kann grundsätzlich mit allen standardkonformen Gegenstellen Verbindungen aufbauen. Allerdings erlaubt der IPSec-Standard sehr viele Wahlmöglichkeiten und Optionen, die teilweise auf beiden Seiten identisch eingestellt oder implementiert sein müssen. Daher können wir eine Kompatibilität nicht generell garantieren.
 
−
 
 
−
Viele einfachere Geräte (z.B. kleine Router) unterstützen ausschließlich eine Authentifizierung mit Pre-Shared Keys. Wegen den im vorherigen Abschnitt beschriebenen Einschränkungen können wir dazu nur dann raten, wenn beide Seiten über feste IP-Adressen verfügen.
 
−
 
 
−
Sind keine festen IP-Adressen verfügbar, sollten Sie Router verwenden, die Public Key unterstützen. Die Konfiguration einiger dieser Router wird in den folgenden Kapiteln vorgestellt.
 
−
 
 
−
==Die Funktionsweise==
 
−
Ein VPN beruht auf IP-Tunneling, daß heißt, das zu transportierende Paket wird verschlüsselt und in ein neues Paket verpackt. Dieses Paket wird in einem Server des LANs oder des ISPs erzeugt, der den Ausgangspunkt des Tunnels bildet. Das Paket enthält als Quelladresse die Adresse dieses Rechners und als Zieladresse einen Server, der den Endpunkt des Tunnels bildet und das transportierte Paket wieder entpackt, also den Tunnel-Kopf entfernt und es entschlüsselt. Dieses Paket wird dann wie gewohnt im Ziel-LAN seinem Empfänger zugestellt.
 
−
 
 
−
Bevor ein Rechner eine verschüsselte Datenverbindung aufbaut, muß er sich eindeutig authentifizieren. Erst nach dem erfolgreichen Identitätsnachweis leitet das VPN-Gateway die Pakete ins Firmennetz weiter.
 
−
Die Authentifizierung kann entweder über nur den beteiligten Rechnern bekannte Geheimnisse (Pre Shared Secrets) geschehen oder über Public-Key-Mechanismen, wie sie auch für digitale Signaturen zum Einsatz kommen.
 
−
Die Verwendung von Pre-Shared-Secrets ist bei End-to-Site-Verbindungen problematisch. Dabei müssen nämlich alle Außendienstmitarbeiter (sog. Roadwarrior) das selbe Pre-Shared-Secret verwenden.
 
−
 
 
−
[[Datei:esp-header.jpg]]
 
−
 
 
−
 
 
−
=Die Protokolle=
 
−
Bei IPSEC-Verbindungen können 2 unterschiedliche Protokolle zum Einsatz kommen: AH und ESP.
 
−
 
 
−
==Authentication Header (AH)==
 
−
AH, oder IP-Protokoll 51, dient dazu die Integrität eines Paketes sicherzustellen. Hierzu berechnet es auf Basis eines Secret-Keys für jedes Paket, inklusive Header eine Signatur; den sog. hash message authentication code (HMAC).
 
−
Dieser HMAC stellt den größten und wichtigsten Teil des insgesamt 24Byte großen Authentication Header dar. Da in den HMAC auch die Adress-Felder des IP-Kopfes einbezogen werden können Pakete bei AH-Verbindungen nicht ohne weiteres mit NAT behandelt werden. Hierbei würde Signatur ungültig.
 
−
Durch AH werden die Pakete nicht verschlüsselt!
 
−
 
 
−
[[Datei:ah.jpg]]
 
−
 
 
−
==Encapsulated Security Payload (ESP)==
 
−
Im gegensatz zu AH werden bei ESP (IP-Protokoll 50) die Pakete verschlüsselt übertragen. Hierbei wird das komplette IP-Paket inklusive der Headerdaten verschlüsselt und in einem neuen Paket verpackt (encapsulated); zusätzlich wird auch hier die Integrität durch einen HMAC sichergestellt jedoch ist, da sich dieser HMAC auf daß verschlüsselte Paket bezieht bei ESP auch NAT möglich.
 
−
Ein weiterer positiver Aspekt dieses Protokolls stellt die Tatsache dar, daß nach außen nur die Kommunikation zwischen den VPN-Gateways sichtbar ist. Eine Kommunikationsbeziehung der LAN-Clients ist nicht erkennbar – somit können auch keine IP-Adressen für anderweitige Angriffe gewonnen werden.
 
−
 
 
−
Folgende Grafiken verdeutlichen die Encapsulation:
 
−
 
 
−
[[Datei:ip-normal.jpg]]
 
−
 
 
−
So sieht ein normales IP-Paket aus (egal ob TCP oder UDP).
 
−
 
 
−
Ein ESP-Paket würde wie folgt aussehen:
 
−
 
 
−
[[Datei:esp.jpg]]
 
−
 
 
−
 
 
−
 
 
−
 
 
−
Quelle: http://www.intra2net.com/de/support/manual/administrator/vpn-basics-public-key.php
 
−
Quelle: http://de.wikipedia.org/wiki/IPsec
 

Aktuelle Version vom 18. September 2024, 21:17 Uhr

Allgemein

Verschiedenes

Abgerufen von „http://wiki.ixheim.de/index.php?title=IPsec&oldid=56439“