 |
|
|
|
|
||||||||
 |
||||||||||||
|
||||||||||||
 |
||||||||||||
|
|
|
|
|
|||
IPSec: Einheitlicher Standard für den Datentransport Mehr Schutz im virtuellen Netz Private Firmennetze lassen sich auf der Basis einer öffentlichen
Netzinfrastruktur aufbauen. Insbesondere der Einbezug des Internet verspricht hier gegenüber klassischen Netzen eine Kostenreduktion von bis 60 Prozent. Dabei sorgt der Standard IPSec für den behüteten
Datentransport. von Klaus Eppele Die Basis der VPNs ist das Tunneling von Datenpaketen. Beim Tunneling werden die zu übertragenden Datenpakete als
Nutzdaten in ein IP-Paket verpackt, über das Internet übertragen und beim Empfänger wieder ausgepackt. Dazu wird das ursprüngliche Datenpaket mit einem zusätzlichen IP-Header und den Protokollinformationen des
verwendeten Tunneling-Protokolls versehen. Mit dieser Methode kann man virtuelle Standleitungen durch das Internet aufbauen und dafür sorgen, daß die Daten in einer "geschlossenen Röhre" durch das öffentliche
Netz geleitet werden. Die Daten werden somit vor dem Zugriff von unauthorisierten Personen geschützt. Bild 1: Tunneling ist die grundlegende VPN-Technologie Betriebsarten Je nachdem, ob ein Tunnel beim POP (Point of Presence) des ISP (Internet Service Providers)
endet oder bis zum Anwender geführt wird, spricht man von einer Provider-abhängigen bzw. Provider-unabhängigen VPN-Realisierung. Die Provider-abhängige Lösung findet man dort, wo das Thema VPN an einen ISP
outgesourced wird. Die sichere virtuelle Standleitung wird nur im Internet zwischen den Netzknoten des ISP aufgebaut. Der Netzadministrator hat hier den Vorteil, daß keinerlei
Anpassungen an seinen lokalen Systemen notwendig werden. Allerdings begibt er sich in eine gewisse Abhängigkeit zum Provider, muß von ihm die Nutzungs- und Zugangsrechte
verwalten lassen und ist selbst dafür verantwortlich, daß die Letzte Meile zum ISP gesichert wird. Auf der Zugangsstrecke zum ISP sind also wie in klassischen privaten Netzen
Mechanismen wie CLID (Calling Line Identification), Call-Back und PAP/CHAP (Password Authentication Protocol / Challenge Handshake Authentication Protocol) gefordert.
Provider-unabhängige VPN-Realisierungen erlauben dagegen Ende-zu-Ende-Tunnel zwischen den Standorten und die Integration mobiler Clienten. Dazu muß man entweder alle Rechner
VPN-fähig machen oder an jedem Standort ein VPN-Gateway installieren und die Notebooks der mobilen Nutzer mit einer VPN-Client-Software versehen. Dieser Lösung ist der Vorzug zu
gewähren. Sind doch die notwendigen Investitionen durchaus tragbar. Eine VPN-Client-Einzellizenz kostet beispielsweise bei der Security-Firma CONWARE aus Karlsruhe 290 DM. Bild 2: Ende-zu-Ende VPNs erlauben die einfache Integration mobiler Kommunikationspartner
Ebene 2 oder Ebene 3? VPN-Tunneling kann man auf OSI-Schicht 2 oder 3 realisieren. Vertreter des Layer-2-Tunneling sind die Protokolle PPTP (Point to Point Tunneling Protocol), L2F (Layer 2
Forwarding) und L2TP (Layer 2 Tunneling Protocol). Layer-3-Tunneling wird meist mit IPSec realisiert. Beim Layer-2-Tunneling werden Frames der OSI-Schicht 2 in IP-Pakete gepackt.
Auf diese Weise kann man auch Nicht-IP-Protokolle tunneln. Beim Layer-3-Tunneling werden dagegen IP-Pakete als Nutzdaten neuer IP-Pakete verschickt.
PPTP wurde ursprünglich von Microsoft und Ascend (heute Lucent) entwickelt und ist aufgrund seiner Integration in Windows weit verbreitet. Es handelt sich um eine Erweiterung
des Point to Point Protokolls (PPP). PPTP ermöglicht die Protokoll-transparente Übertragung von IP-, IPX- und NetBUI-Paketen. Die einzelnen Pakete werden in eine modifizierte Form des
Generic Routing Encapsulation Protocol Version 2 (GREv2) verpackt und zum Network Access Server (NAS) des ISP transportiert. Die Datenverschlüsselung erfolgt nach dem
RC4-Verfahren von Ronald Rivest mit Schlüssellängen von 40 oder 128 Bit. Eine Paket-Integritätsprüfung ist nicht implementiert. Je Kommunikationspaar kann nur ein Tunnel
aufgebaut werden. Zur Authentisierung beim Verbindungsaufbau dient PAP/CHAP; eine Authentisierung der Tunnelenden ist jedoch nicht vorgesehen. In PPTP sind keine
Key-Management-Protokolle implementiert und PPTP ist nicht standardisiert. Der alte RFC Draft (draft-ietf-pppext-pptp-00) ist inzwischen "expired".
L2F wurde von Cisco, Nortel und Shiva entwickelt. Eine Multiplex-ID und eine Client-ID im L2F-Header erlauben den gleichzeitigen Betrieb mehrerer Tunnel und innerhalb jedes Tunnels
mehrere parallele Verbindungen. Unterstützt werden Punkt-zu-Punkt und Punkt-zu-Mehrpunkt-Verbindungen. Neben PPP kann man mit L2F auch SLIP (Serial Line Internet Protocol) tunneln. Die Authentisierung erfolgt über ein
Challenge-Handshake-Verfahren. Eine Verschlüsselung der Daten ist nicht vorgesehen. L2F kann über unterschiedliche Paketnetze transportiert werden, etwa X.25, Frame Relay oder
ATM. Der zugehörige RFC 2341 hat den Stand "historic". L2TP vereint die Vorteile von PPTP und L2F. Das Protokoll erweitert das PPP-Modell und
erlaubt, daß L2- und PPP-Verbindungen auf verschiedenen Systemen terminieren können, die über ein paketorientiertes Netz miteinander verbunden sind. Der Vorteil: Anstatt eine
Fernverbindung zu einem entfernten Network Access Server (NAS) aufbauen zu müssen, kann man sich auch mit einem lokalen Konzentrator verbinden, der die logische
PPP-Verbindung z.B. via Internet bis zum NAS verlängert. L2TP ist ein Proposed Standard nach IETF RFC 2661. Eine Tunnel-ID im L2TP-Header erlaubt den Betrieb multipler Tunnels.
Außerdem wird NAT (Network Address Translation) unterstützt. IPSec IPSec (IP Security) ist ein Layer-3-Tunneling-Protokoll. Es wird die Layer-2-Protokolle
langfristig als VPN-Standard ablösen, da es ein höheres Maß an Sicherheit bietet. IPSec ist für IPv4 definiert und fester Bestandteil von IPv6. IPSec ist ein Rahmenwerk verschiedener
Normen (RFC 1825-1829, bzw. 2401-2412) das festlegt, mit welchen Ergänzungen das Internet Protokoll die Integrität und die Vertraulichkeit der Daten sowie die Authentizität der
Teilnehmer garantieren kann. Wesentliche Design-Ziele bei der IPSec-Definition waren,
Die Datenintegrität und die Authentisierung des Datenursprungs wird mittels des Authentication Headers (AH) erreicht. Der AH-Header schützt die Daten und einige
Header-Teile des zu übertragenden IP-Pakets vor Verfälschung. Dazu wird mittels bekannter Hash-Funktionen wie MD-5 (Message Digest) oder SHA-1 (Secure Hashing Algorithmus) eine
Prüfsumme aus der IP-Payload gebildet und im AH-Header an den Empfänger übertragen. Wenn dieser dieselbe Prüfsumme aus dem empfangenen Paket errechnet ist sichergestellt,
daß die Nachricht während der Übertragung nicht verändert wurde und nur von dem Absender stammen kann, der den geheimen Schlüssel für das gewählte Authentisierungsverfahren kennt.
Man unterscheidet den AH-Transport- und den AH-Tunnel-Modus. Im Transport-Modus wird der AH-Header zwischen IP-Header und den Headern der Transportschicht eingefügt und
somit die IP-Payload gesichert. Beim Tunnel-Modus wird eine Prüfsumme aus fast dem gesamten ursprünglichen Paket gebildet. Der AH-Header wird in diesem Fall dem
ursprünglichen Paket vorangestellt und mit einem neuen IP-Header versehen. Ausgenommen von der Prüfsummenbildung sind einige Felder, wie TOS (Type of Service), TTL (Time to Live),
Header-Checksum etc.. Im Tunnel-Modus enthält das innere IP-Paket im IP-Header die Source- und Destination-Adressen der miteinander kommunizierenden Rechner. Der äußere
IP-Header enthält die IP-Adressen der Tunnelendpunkte. Bild 3: AH und ESP im Transport- und im Tunnel-Modus
Der AH-Header enthält als wichtigsten Bestandteil die Prüfsumme (Authentication Data). Das Prüfsummenfeld ist von variabler Länge, da je nach verwendetem Prüfsummenverfahren
unterschiedlich lange Prüfsummen gebildet werden. MD-5 erzeugt eine Prüfsumme der Länge 128 Bit, die Prüfsumme bei SHA-1 ist 160 Bit lang. Außerdem kann optional eine
Sequenz-Nummer hinzugefügt werden, die die Datenpakete von 0 bis 232-1 durchnummeriert. Damit kann man Replay-Attacken verhindern. Man kann also erkennen, wenn Datenpakete
kopiert und zu einem späteren Zeitpunkt erneut übertragen werden, mit der Absicht, den Empfänger zu irritieren oder zu einem späteren Zeitpunkt ein falsches Verhalten auszulösen.
Der Security Parameter Index (SPI) ist ein weiterer wesentlicher Bestandteil des AH-Headers. Er beschreibt die ausgehandelten Sicherheitsparameter, wie das aktuell gültige Verfahren zur
Verschlüsselung oder die Gültigkeitsdauer des Schlüssels. Zusammen mit der IP-Adresse definiert der SPI die Security Association (SA), die für jede unidirektionale Verbindung die
zugehörigen Sicherheitsmechanismen beschreibt. Verschlüsselung in IPSec Der Encapsulation Security Payload Header (ESP) sorgt für die Vertraulichkeit der Daten. Er
ist ähnlich dem AH-Header aufgebaut. Neben der Festlegung des Verschlüsselungsalgorithmus kann ESP auch die Authentisierung der Daten übernehmen. ESP kann wie AH im Transport- und im Tunnel-Modus betrieben werden.
Der Transport-Modus hat den Nachteil, daß jede Station im VPN IPSec beherrschen muß. Außerdem kann ein Angreifer erkennen, welche Stationen miteinander kommunizieren. Im
Tunnel-Modus ist dies nicht der Fall. Hier können dedizierte IP-Gateways die Umwandlung in IPSec-Pakete realisieren. Eine Neukonfiguration der verbundenen LANs ist nicht nötig.
Allerdings werden die Pakete im Tunnel-Modus bei gleichzeitiger Anwendung von AH und ESP um über 60 Byte verlängert. Bei großen Paketen ist somit eine Fragmentierung der
Pakete nötig, was zu zusätzlichem Verwaltungsaufwand und Performance-Einbußen führt. Zur Verschlüsselung werden häufig symmetrische Verfahren wie DES (Data Encryption
Standard) verwendet. Mit entsprechenden Chipbausteinen lassen sich nämlich Datenmengen von bis zu 1 Gbit/s symmetrisch verschlüsseln. Asymmetrische Verfahren wie RSA sind
dagegen relativ rechenintensiv und benötigen zudem längere Schlüssel. Aus diesem Grund verwendet man asymmetrische Verfahren selten zur Verschlüsselung von Nutzdaten, sondern
zum Austausch von symmetrischen Schlüsseln oder zur digitalen Unterschrift. IPSec erlaubt auch noch andere Verschlüsselungsalgorithmen wie IDEA (International Data
Encrytion Algorithm) oder Blowfish. Gleich welches Verfahren man einsetzt - wichtig ist, auf eine starke Verschlüsselung mit Schlüssellängen größer 56 Bit zu setzen. Denn 40- oder
56-Bit-Schlüssel lassen sich heute mit dem entsprechenden Rechner-Equipment bereits in kurzer Zeit knacken. Außerdem sollte man sich versichern, daß bei den eingesetzten
VPN-Komponeten keine Mechnismen zur Wiederherstellung von Schlüsseln (key recovery) implementiert sind bzw. keine Schlüsselhinterlegung (key escrow) stattfindet. Bild 4: Beispiel für eine integrierte VPN-Produktfamilie. Das SecuWare VPN-Konzept der
Firma CONWARE aus Karlsruhe beinhaltet VPN-Gateways, VPN-Clients und VPN-Switches Internet Key Exchange IPSec beschreibt auch Verfahren zum gesicherten Austausch von Schlüsseln und Security
Parametern über öffentliche Netze. Die notwendigen Rahmenrichtlinien zum Key Management liefert das Internet Security Association and Key Management Protocol (ISAKMP/Oakley). In
einem zweiphasigen Verbindungsaufbau werden die Security Associations ausgehandelt und die Gegenstellen authentisiert. Phase 1 erzeugt eine sichere Verbindung (ISAKMP-SA) über
die die Sicherheitsparameter ausgehandelt werden können. Dazu werden die Parameter zur Berechnung eines Master-Keys mittels des des Diffie/Hellmann-Algorithmus ausgetauscht
und die Gegenstellen authentisiert. Phase 2 definiert dann allgemein verwendbare SAs zur Übertragung der Nutzdaten. Ausblick
Der Weltmarkt für VPNs wird lt. dem Marktforschungsinstitut Infonetics bis zum Jahre 2004 auf 40 Mrd. US-Dollar anwachsen. Für das Jahr 2000 ist ein VPN-Umsatz von 6,3 Mrd.
US-Dollar prognostiziert. Einen großen Anteil an dieser Entwicklung werden IPSec-Produkte haben, da IPSec bereits die wesentlichen Security-Mechnismen definiert und die IETF
(Internet Engineering Task Force) an weiteren Verbesserung und Ergänzungen arbeitet. So ist beispielsweise derzeit die Arbeitsgruppe "IPSec Remote Access (ipsra)" damit beschäftigt,
die Client-Konfiguration und -Authentisierung zu standardisieren, um eine Verbesserung der Interoperabilität zu erzielen. Autor improve Erschienen in Computerwoche Extra 07/00, Seiten 28 - 30
|
|||
