![[externer Link]](../../../../images/link.gif)
www.ietf.org/html.charters/ipsec-charter.html), sind aber noch nicht im "offiziellen" Standardisierungsprozess der IETF angelangt.Die IPSec-Spezifikation der Internet Engineering Task Force (IETF) ist heute anerkannter Protokoll-Standard für den Aufbau von Virtual Private Networks (VPNs) jeder Art. Ursprünglich wurde IPSec jedoch für Site-to-Site-Kommunikationsumgebungen definiert, die durch fest installierte VPN-Gateways und statische IP-Adressen in fest vermaschten Wide Area Networks (WAN) geprägt sind. Das Einbinden mobiler Telearbeitsplätze stellt hingegen abweichende Anforderungen (End-to-Site-VPNs), besonders durch den Einsatz von Wählverbindungen und wechselnde (dynamische) IP-Adressen. Die hierfür erforderlichen Erweiterungen des IPSec-Protokolls liegen zwischenzeitlich als Internet-Drafts auf den Seiten der IPSec-Working-Group vor ( www.ietf.org/html.charters/ipsec-charter.html), sind aber noch nicht im "offiziellen" Standardisierungsprozess der IETF angelangt.
Bevor IPSec Nutzdaten geschützt übertragen kann, erfolgt im Rahmen des Internet Key Exchange (IKE) die Verhandlung aller hierfür notwendigen Sicherheitsparameter: eingesetzter Verschlüsselungsalgorithmus, Schlüsselmanagement (Aushandeln des Session Key) und die Authentifizierung zwischen VPN-Client und -Gateway, die standardmäßig durch Preshared Key oder Zertifikate erfolgt – die Protokollerweiterung XAUTH ermöglicht hier zusätzliche Methoden (u. a. Einmalpasswörter). Andere Erweiterungen für Remote-Access-VPNs betreffen vor allem das IKE-Protokoll ( www.rfc-editor.org/rfc/rfc2409.txt).
Der IKE-Config-Mode ermöglicht die dynamische Zuteilung einer virtuellen IP-Adresse aus dem internen Adressbereich (private IP) eines Unternehmens an den Client. Darüber hinaus können dem Client beispielsweise auch Domain- und Serverdaten für DNS und WINS (Windows Internet Name Server) gesichert zugewiesen werden.
Diese Übertragung erfolgt üblicherweise nach IKE Phase I (s. <kes> 2001#3, S. 41) und ist somit durch die entsprechende Verschlüsselung geschützt. Dabei erfragen entweder die Clients vom Gateway bestimmte erwünschte Parameter (Request/Reply-Mode) oder das Gateway schickt von sich aus vordefinierte Datensätze (Set/Ack-Mode). Ohne IKE Config müsste man diese Konfiguration unmittelbar auf jedem Endgerät vollziehen, was besonders in wechselnden Einsatzumgebungen oder bei Änderungen einer breiten Client-Basis Probleme aufwerfen würde. Bislang unterstützen nur wenige Anbieter den IKE Config Draft.
Eine zusätzliche Schwierigkeit beim Remote Access sind Telearbeitsplätze, die über Netzwerkkomponenten mit Adressumsetzung (Network Address Translation, NAT) Datenverbindungen aufbauen möchten, beispielsweise eine PC hinter einem DSL-Router mit NAT. Nach der IKE-Aushandlung überfordern die verschlüsselten und signierten Datenpakete der Encryption Security Payload (ESP) jedes zwischengeschaltete NAT-System, weil sie keine Ports benutzen. Etliche Netzwerkkomponenten mit NAT haben daher eine "IPSec Passthru"-Option, die aber nur ein einziges, festgelegtes Endgerät hinter der NAT-Linie mit den durchgereichten ESP-Frames versorgen kann. NAT Traversal (NAT-T) soll hier Abhilfe schaffen.
Hierzu definiert NAT-T zunächst eine Methode, um auf dem Weg vom Client zum Gateway aktive NAT-Systeme zu entdecken und abzufragen, ob diese NAT-T-fähig sind. Wenn ja, werden die ESP-Frames zusätzlich in ein UDP-Paket gekapselt, das es der NAT-Komponente ermöglicht, die korrekte Adressumsetzung für das jeweilige Endgerät vorzunehmen. Obwohl noch unklar ist, ob NAT-T zum Internet-Standard aufsteigen wird, unterstützen schon etliche Hersteller die vorliegenden Drafts.
IPSec-Tunnel schützen zwar die VPN-Verbindung auf dem Weg durch unsichere Netze; um den PC und letztlich das Firmennetz gegen Attacken abzuschotten, genügt das aber nicht. Ein wesentliches Bedrohungs-Szenario ist immer dann gegeben, wenn ein mobiler Teleworker neben der VPN-Verbindung zur Firmenzentrale gleichzeitig eine unmittelbare Verbindung zum Internet oder eine zweite VPN-Verbindung zu einem alternativen VPN-Gateway unterhält (sog. Split Tunneling). In derartigen Fällen muss man verhindern, dass Dritte über den Umweg des Endgeräts und durch den VPN-Tunnel Zugriff auf das Firmennetz erhalten.
Hierzu müssen auch die Endgeräte selbst gegen Angriffe besonders geschützt sein, da sie quasi als Bastion des Firmen-LANs exponiert im Internet stehen. Daher sollte der Remote-PC unbedingt nicht nur Virenschutz-Software, sondern auch eine Personal Firewall erhalten, die alle ein- und abgehenden Verbindungen regelt.
Von einigen Anbietern sind auch VPN-Clients mit integrierter Firewall-Komponente verfügbar, was das zentrale Management wesentlich erleichtert. Der mobile Anwender sollte dabei keine Möglichkeit haben, Einstellungsänderungen an der Personal Firewall vorzunehmen – letztlich würde auch eine "durchgeschlüpfte" Malware mit seinen Berechtigungen arbeiten.
Um sich nachhaltig gegenüber Viren aus dem Internet zu schützen, bietet sich das "kontrollierte Surfen" an (vgl. Abb.). Der mobile Anwender kann dann ausschließlich getunnelt über die Firmenzentrale das Internet nutzen. Der Vorteil liegt darin, dass seine Verbindungen über das VPN-Gateway auch von allen zentralen Security-Einrichtungen wie Viren-Scanner und Content-Filter profitieren. Die Alternative diese Funktionen dezentral in jedem PC zu installieren ist nicht nur teuerer, sondern auch nur schwer administrierbar.
![[Beim kontrollierten Surfen ist der direkte Weg vom Client ins Internet gesperrt.]](04-5-045-1.jpg)
Kontrolliertes Surfen lässt mobile Nutzer ausschließlich über den Umweg des VPN und die firmeninternen Sicherheitseinrichtungen surfen.
Das ist allerdings komplexer als es auf den ersten Blick erscheinen mag: Soll beispielsweise ein mobiler Anwender, der an einem Hotspot angemeldet ist, kontrolliert surfen, so könnte man ja seinen VPN-Tunnel erst dann aufbauen, wenn er sich bereits erfolgreich am Access Point angemeldet hat. Diese Anmeldung basiert in der Regel auf HTTP oder HTTPS, diese Ports müssen also an der Personal Firewall freigeschaltet sein, was ein grundsätzliches Sicherheitsrisiko darstellt. Der User könnte schließlich auch direkt, also ohne VPN-Verbindung, im Internet arbeiten. Die Firewall muss also in Abhängigkeit vom Verbindungsstatus dafür sorgen, dass nur die Hotspot-Anmeldung und der VPN-Aufbau erfolgen, aber keine weiteren Programme "direkt" auf das Internet zugreifen können.
Mobile Computing sollte keine Insellösung in der Unternehmenskommunikation darstellen. Der mobile Zugriff auf zentrale Datenbestände und Ressourcen sollte vielmehr Teil einer universellen Remote-Access-Plattform sein. Die wesentlichen Eigenschaften einer ganzheitlichen VPN-Lösung sind:
Als großes Problem vor allem bei größeren VPN-Strukturen stellt sich dabei die Administrierbarkeit aller Remote-Systeme. Hier benötigt man dringend Automatismen, die sowohl den Roll-out als auch den Betrieb mobiler Arbeitsplätze vereinfachen sowie Fehlkonfigurationen und Fehlbedienungen minimieren. Man sollte daher beim Aufbau seines VPN auf entsprechende Angebote für einen "Single-Point-of-Administration" achten, wie sie beispielsweise NCP mit dem Secure Enterprise Management im Programm hat.
Die Defizite des ursprünglichen IPSec-Protokollstandards bezüglich Remote-Access-VPNs sind zwischenzeitlich durch entsprechende Protokollerweiterungen (Drafts) behoben. Mobile Telearbeitsplätze können auf diese Weise grundsätzlich in End-to-Site-VPNs funktionell integriert werden. Die Datenübertragung über Funknetze und das Internet erfordern allerdings darüber hinausgehende Sicherheitsmechanismen, die den Remote-PC und letztlich das Firmennetz vor Attacken schützen: eine integrierte Personal Firewall. Abgerundet wird eine professionelle IPSec-VPN-Lösung durch ein zentrales Management aller Remote-Komponenten.
Andreas Baehre ist Entwicklungsleiter bei der NCP engineering GmbH. s
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004#5, Seite 45
| 