IPSEC nutzt fast jede Firma - doch kaum einer weiss was es damit auf sich hat.
Erklärungen gibt es dazu viele, doch leider auch zu viele unverständliche oder zu ausführliche, die keiner versteht. Das Problem liegt nicht nur an der Komplexität des IPSEC Protokolls, sondern zu allem Übel an den verschiedenartigsten Möglichkeiten, wie man IPSEC konfigurieren kann. Dadurch kann der Eindruck entstehen, verschiedene IPSEC- Erklärungen die man im Internet findet, würden gegensätzliches aussagen - dabei gehen die Erklärungen oft einfach nur von verschiedenen IPSEC Konfigurationsvarianten aus.
Ich will versuchen, die wichtigsten Merkmale und Begrifflichkeiten rund um IPSEC zu erklären ohne zu sehr auf jedes einzelne Detail einzugehen, da IPSEC mit allen Einzelheiten wohl Bände füllen könnte. Da es jedoch selbst für einen Administrator spannenderes gibt als jedes Detail von IPSEC zu verstehen, dürften die unten stehenden Informationen für geschätzte 99,9% aller Administratoren ausreichen, um IPSEC zu VERSTEHEN. Wie man es konfiguriert ist wieder eine Wissenschaft für sich und hängt vom Hersteller ab, auf dessen Gerätschaft man IPSEC konfigurieren soll. Vor dem Konfigurieren kommt aber das Verstehen, und darum geht es in diesem Tutorial.
Falls sich fachliche Fehler eingeschlichen haben sollten oder man das eine oder andere noch einfacher erklären kann freue ich mich über kompetenten Input.
Kommt ganz darauf an! Je nachdem, wie der VPN Server konfiguriert ist, brauchen wir
oder
oder
Auf der sicheren Seite ist man, wenn also die Ports UDP500, UDP4500 und TCP10.000 zwischen den VPN Partnern offen sind.
Erläuterungen zu den Ports und was es mit den einzelnen Varianten auf sich hat - siehe unten!
IPSEC ist eine Protokollsuite die IP-Verbindungen sicherer machen soll. Es wird vor allem für VPN Verbindungen eingesetzt und ist das verbreitetste VPN Protokoll.
IPSEC besteht im wesentlichen aus den Protokollen IKE und ESP.
IKE ist die technische Umsetzung des ISAKMP Frameworks. IKE nutzt UDP Port 500.
IKE Phase 1 baut einen sicheren Verbindungs-Kanal auf. Dabei findet auch die „Authentisierung“ zwischen den VPN Partnern statt, die mit Zertifikaten oder Pre-Shared Keys (Passwörtern) erfolgen kann. Dieser sichere Verbindungskanal wird dann genutzt, um die Parameter aus Phase 2 sicher zwischen den VPN Partnern aushandeln zu können.
IKE Phase 2 handelt die Verschlüsselungs- und Integritätsparameter aus, mit denen die eigentlichen Daten gesichert werden.
Nach Aushandlung der SAs (Security Assotiations) in IKE Phase 2 wird das Protokoll ESP benutzt, um letztendlich die verschlüsselten Daten zu transportieren. ESP hat keinen Port, da es ein OSI Layer 3 Protokoll ist.
Bei Einsatz von NAT-Traversal (auch NAT-Transparency genannt), um auch über PAT-Router ESP Verbindungen aufbauen zu können, braucht man Port UDP4500. Dabei wird ESP in UDP gekapselt, da ESP keine Ports benutzt und dadurch nicht „gepattet“ werden kann.
Bei Einsatz von IPSEC-over-TCP braucht man nur Port TCP10.000. Dabei werden IKE als auch ESP in TCP gekapselt, und über diesen einen Port TCP10.000 geleitet. Geheim-TIP: Man kann den Port am VPN Server auch von TCP10.000 aúf einen anderen ändern (z. B. TCP80), so dass ein IPSEC Tunnel auch von Lokationen aus aufgebaut werden kann, die nur wenige Ports geöffnet haben - z. B. in WLAN Hotspots. Dies funktioniert aber nur, wenn zwischen den VPN Endpunkten keine Firewall auf Applikationsebene die Art des TCP Verkehrs filtert und z. B. „Nicht-HTTP-Traffic“ erkennt und verwirft.
Im IPSEC Tunnelmode werden IP-Pakete in andere IP-Pakete gekapselt (getunnelt). Dadurch kann ein zugreifender Client eine „virtuelle“ IP aus dem IP-Bereich des Firmen-Netzes bekommen und sich netzwerktechnisch mit dem Firmen-Intranet verbinden, als wäre er im Büro.
IKE ist quasi gleichbedeutend mit ISAKMP (Internet Security Association and Key Management Protocol). Es dient zum einen zum sicheren Austausch von Schlüsseln über ein unsiches Netzwerk, wofür der Difi-Hellman Algorithmus verwendet wird. Zum anderen dient IKE zur „Aushandlung“ von Sicherheits Parametern, wie Verschlüsselungs-Variante und Stärke, Hash-Algorithmus (zur Datenintegrität, sprich Gewährleistung dass die Daten nicht auf dem Weg zum Empfänger verändert wurden) sowie Authentisierung (per Zertifikaten oder Preshard Keys / Passwörtern).
Die IKE Phase 1 dient prinzipiell zum Aufbau eines „sicheren“ Kanals zwischen den zwei VPN-Servern, oder zwischen Remote-Benutzer und VPN Server. Dabei wird auf UDP Port 500 mit dem VPN Server kommuniziert. In IKE Phase 1 werden - worauf der Name bereits hinweist - „Schlüssel ausgetauscht“.
Zum Schlüsselaustausch wird der Diffi-Hellman Algorithmus verwendet. Diese geniale Erfindung stellt eine sichere Methode dar, Schlüssel über ein unsicheres Medium zu übertragen und einen symetrischen Schlüssel zu berechnen, der nur für die jeweilige Session gültig ist. Mittels diesen Schlüssels wird die Kommunikation dann verschlüsselt.
Der Lifetime Parameter bestimmt nur dann die Lebenszeit des Administrators, wenn er die Lifetime auf beiden VPN Servern einer Seite-to-site Verbindung UNTERSCHIEDLICH konfiguriert. Die lifetime muss auf beiden identisch sein, da der Tunnel ansonsten in regelmässiger Unregelmässigkeiten abbricht und man sich beim Troubleshooting den Wolf sucht.
In der IKE Phase 2 handeln die VPN Partner aus, welche Verschlüsselungsvariante und -Stärke, mit der die eigentlichen Daten verschlüsselt werden sollen, sowie die „lifetime“ (Lebensdauer des ausgehandelten Schlüssels). Die Aushandlung aus Phase1 betrifft also nur die Parameter zum Aufbau des „sicheren Kanals“.
Die Aushandlung der Parameter in Phase2 betrifft nur die Sicherungs-Parameter für den Datenkanal!
Man könnte die Sache auch so interpretieren, dass die Designer des IPSEC Protokolls recht paranoid waren, dass sie so viel Sicherheit eingebaut haben - zumal dies das Protokoll beliebig kompliziert und damit fehleranfällig und angreifbar macht. Dies zumindest Bruce Schneiers (Sicherheits-Guru) Meinung zu IPSEC - „zu kompliziert um sicher zu sein“. Nichts desto trotz gilt IPSEC als das sicherste VPN Protokoll das man derzeit einsetzen kann - vor allem wenn man AES und SHA1 verwendet, ist der Tunnel an sich, zumindest momentan, quasi nicht zu knacken. In Verbindung mit einer sicheren Authentisierungsmethode (Zertifikate, oder RSA Tokens bei User-Zugriff) ist das Ding als sicher zu betrachten.
Die ausgehandelten Parameter (also Verschlüsselungsvariante- und Stärke, Hash-Algorithmus sowie lifetime) nennt man auch SAs (Security Assoitiation). Die SAs stellen also die „Policy“ dar die die beiden VPN Partner ausgehandelt haben. Die Möglichkeit, dass beide VPN Partner die einzelnen Parameter, die für den IPSEC Tunnel verwendet werden sollen, aushandeln können macht IPSEC recht flexibel, und ermöglicht auch die Zusammenarbeit zwischen VPN Servern verschiedener Hersteller.
Zumindest eines der verfügbaren Varianten (Schlüssel, Hash) müssen also beide VPN Server die zusammen einen VPN Tunnel aufbauen wollen, beherrschen.
Beispiel: Kann VPN Server 1 nur AES, und VPN Server 2 nur 3DES, kann kein VPN Tunnel zwischen beiden Servern aufgebaut werden. Beherrscht VPN Server 1 jedoch AES und DES, der zweite jedoch AES und 3DES, werden sich die beiden VPN Server auf AES „einigen“.
Nach IKE Phase 2 (Aushandlung von SAs) kommt das Protokoll ESP (Encapsulating Security Payload) zum Einsatz, das die Daten verschlüsselt zwischen den VPN Servern transportiert. IPSEC nutzt im Tunnelmode ESP, um die Daten in einem IP-Paket, das in ein anderes IP-Paket „eingekapselt“ bzw. „getunnelt“ wird, zu transportieren und zu verschlüsseln.
ESP nutzt keinen „Port“, da es ein reines Layer 3 Protokoll ist (wie IP oder auch ICMP) und kein Transportprotokoll wie UDP oder TCP (Layer 4), welche prinzipiell Ports nutzen um eine Verbindung aufzubauen.
ESP hat jedoch den Nachteil, dass es bei Netzwerken, die PAT Router (Port Address Translation) benutzen (wie gängige Heim-Router), Einschränkungen unterliegt. Im Grunde kann nur EIN PC im Heimnetz einen VPN Tunnel in die Firma aufbauen - würde es gleichzeitig ein zweiter versuchen, würde dies prinzipbedingt scheitern, da ESP keine Ports benutzt, die man „patten“ könnte.
Aus diesem Grunde wurde NAT-Traversal erfunden. Dabei wird ESP in UDP gekapselt, und auf UDP Port 4500 über den NAT-Router (der aber in Wahrheit allermeist ein PAT-Router ist) gesendet.
Mit NAT hat ESP keine Probleme, das Problem liegt am PAT und an der Port-losigkeit des ESP Protokolls.
Dies hat wiederum jedoch einen Nachteil, da UDP Verbindungen (im Gegensatz zu TCP Verbindungen) eine recht kurze Lebensdauer haben, und der IPSEC Tunnel dadurch - wenn der Benutzer beispielsweise keine Daten über den Tunnel sendet - abrupt abbrechen kann. Um dies zu verhindern, wurden die NAT-Keepalives eingeführt, die regelmässig kleine Datenbrocken über die Leitung senden um den Abbruch des UDP Tunnels zu verhindern.
Aus dieser UDP-NAT-Traversal Problematik heraus (UDP-Tunnel-Abbruch) hat Cisco alternativ IPSEC-over-TCP erfunden, welches wie der Name sagt TCP verwendet, und sowohl IKE Phase1 als auch ESP über TCP Port 10000 zum benachbarten VPN Server schleust. Dies ist die bevorzugte Variante, die man nutzen sollte, wenn der VPN Server es unterstützt.
VPNs (Virtual Private Networks) dienen dazu, zwei Netze miteinander zu verbinden über einen virtuellen Tunnel, der die Daten schützt, und somit sensible Daten auch über „unsichere“ Netze (z. B. Internet) transportieren zu können.
Während man natürlich zwei Netze (zum Beispiel zwei Standorte einer Firma) mit Standleitungen verbinden kann, stellen VPNs eine sichere und weitaus kostengünstigere Methode dar, Firmen-Netze miteinander verbinden zu können. Im Gegensatz zum Remote Access VPN müssen die Client Rechner bei dieser Variante keinen speziellen „VPN Client“ installieren, da der VPN Tunnel zwischen zwei VPN Servern (z. B. Cisco PIX, ASA oder VPN Concentrator, oder in kleineren Firmen auch Draytec oder Netgear) aufgebaut wird, und der Traffic von einem der Standorte zum anderen Standort automatisch über den VPN Tunnel geschleust wird. Der Benutzer merkt im Grunde garnicht, dass seine Daten, die er eventuell zum anderen Standort sendet, über einen VPN Tunnel gesendet werden.
Damit reisende Mitarbeiter oder Homeoffice-Benutzer auf Firmen-Intranet Ressourcen zugreifen können, kann man eine VPN Remote Access Lösung einsetzen. Dazu muss der Benutzer einen VPN Client auf seinem PC installieren, den VPN Client starten und sich authentisieren, um auf die Firmen-Ressourcen zuzugreifen. Wenn der Client den Tunnel aufgebaut hat, hat er in aller Regel eine „virtuelle“ IP-Adresse aus dem Firmen-IP-Bereich, den ihm der VPN Server verpasst (Tunnelmode). Damit ist der PC des Benutzers auf Netzwerkebene in das Firmen-LAN integriert, als wäre er in seinem Büro.
IPSEC ist der defacto Standard in Sachen VPN Protokolle. Man verwendet dieses Protokoll vor allem für Site-to-Site Verbindungen beispielsweise zwischen zwei Niederlassungen einer Firma, oder als Remote-Access Lösung für reisende Mitarbeiter oder Homeoffice-Benutzer, die eine sichere Verbindung ins Firmennetz benötigen. IPSEC wurde eigentlich für Site-to-Site VPNs designt, setzte sich jedoch auch im Remote Access Bereich durch. IPSEC „könnte“ in den nächsten Jahren im Remote Access Bereich durch SSL VPNs abgelöst werden - doch das ist ein anderes Thema.
Wie der Name bereits andeutet, sichert IPSEC Daten auf dem OSI Layer 3 (Network bzw. IP Ebene). Im sogenannten „Tunnelmode“ wird das gesamte IP-Paket in ein anderes IP-Paket gekapselt, daher die Bezeichnung „Tunnel“.
IPSEC ist eine Protokollsuite, die aus einer Vielzahl von Unterprotokollen besteht. Dies macht IPSEC recht kompliziert. Es ist eventuell gar eines der kompliziertesten Netzwerkprotokolle überhaupt.
IPSEC versucht eine Vielzahl von Anforderungen, die man an eine „sichere“ Verbindung über ein unsicheres Netzwerk (Internet) stellt, zu erfüllen. Ferner hat sich IPSEC als sicheres, performantes und stabiles VPN Protokoll durchgesetzt.
Diese Anforderungen die IPSEC erfüllen will:
Die „sensiblen“ Firmen-Daten dürfen nicht für Dritte lesbar sein. Darum werden sie verschlüsselt.
Als derzeit „sicher“ und gleichzeitig „performant“ gilt AES (128, 192 oder 256Bit) Verschlüsselung. Je höher die Bit-Stärke, desto „sicherer“ die Verschlüsselung - doch damit steigt auch die CPU Belastung des VPN Servers. Alternativen zu AES wären 3DES (168Bit) oder DES(56bit). 3DES gilt ebenfalls als sicher, aber langsamer als AES. DES dagegen gilt als unsicher und sollte nicht verwendet werden.
Die Daten dürfen auf dem Weg zwischen Absender und Empfänger nicht verändert werden können. Um die Daten Integrität zu gewährleisten, werden Hash-Algorithmen verwendet. Derzeit gilt SHA1 als (noch halbwegs) sicher, während MD5 zwar schneller, aber weniger sicher ist.
Damit sich bei einer Site-to-Site VPN Verbindung nur autorisierte VPN Server miteinander einen Tunnel aufbauen können, muss eine sichere Authentisierung integriert sein. Hier hat man die Auswahl zwischen Zertifikaten oder so genannten Preshared Keys (Passwörter). Bei Remote Access Verbindungen von Mitarbeitern authentisiert sich der Benutzer meist mit einem Passwort. Sicherer sind Zertifikate oder Einmal-Passwörter (z. B. RSA SecurID Token). Hier muss individuell abgewägt werden was man benötigt, um einen Kompromiss zwischen Sicherheitsbedarf, benutzerfreundlicher Handhabung und Kosten zu finden.