Virtuelle Private Netzwerke werden hier verstanden als logische Netze, die die VPN-Endpunkte über ein vorhandenes Kommunikationsnetz wie z. B. das Internet miteinander verbinden. Mittels kryptographischer Verfahren wird die Kommunikation der Endgeräte beim Transfer von einem zum anderen VPN-Endpunkt geschützt und von anderen Kommunikationsverbindungen getrennt.

Wie lange schon Virtuelle Private Netzwerke (VPN) aus dem täglichen Routineeinsatz von Unternehmen und Organisationen nicht mehr wegzudenken sind, konnte ich in der Literatur nicht herausfinden. Tatsache ist aber, daß Regierungen, Militär und Wirtschaftsunternehmen, ganz vorne die Banken, ohne diese Technik erheblich verletzlicher und angreifbarer wären. Gerade bei Banken mit ihrem ausgedehnten und oft auch internationalem Filialnetz wird die Kommunikation, sobald das "Kabel" eine Filiale verläßt, chiffriert - das Bild eines kleinen schwarzen Kastens ist hier durchaus angemessen. Nur selten, wenn vielleicht die Filiale in Paris liegt, werden Daten unverschlüsselt übertragen - die wirklich "heißen" Informationen werden jedoch persönlich per Kurier überbracht.

Was also für höchste Sicherheitsanforderungen schon lange als State-of-the-Art angesehen wird, hält auch zunehmend Einzug in andere Anwendungsfelder. Gerade wenn eine leistungsfähige Infrastruktur wie das Deutsche Forschungsnetz genutzt werden soll, um Patientendaten, Verwaltungsvorgänge und andere sensitive Informationen auszutauschen und zu verarbeiten, bieten für die Anwendungen transparente - d. h. nicht wahrnehmbare - VPNs die schnellste Möglichkeit der Absicherung. Ohne "Sicherheit" nachträglich in die Anwendungen einbauen zu müssen, was von vorne herein schwierig und nur lückenhaft machbar ist, wird das VPN quasi als Sicherungsschicht zwischen Anwendung und der verwendeten Kommunikationsinfrastruktur (egal ob über Internet, Telefonnetz, X.25, ... ) eingezogen.

Jedes zweite oder dritte Jahr kommt eine neue Technologie zu denen hinzu, die zum Portfolio eines auf Sicherheit bedachten Administrators oder Managers einfach dazugehören muß. Umso wichtiger ist es daher, sich sowohl die individuellen Vorteile der jeweiligen Technik vor Augen zu führen, als auch zu verstehen, wo diese Technik berechtigt und notwendig eingeführt werden muß bzw. wo diese Technik ihre Grenze findet.

Am einfachsten analysiert man dazu die Lücken etablierter Techniken und den angestrebten Nutzen. Zunächst zu etablierten Techniken und Konzepten:

• Firewalls: Firewalls stellen die Verteidigung nach draußen dar. Die Kommunikation zwischen internem und anderen Netzen wird zwar in Hinblick auf Plausibilität und Berechtigungen überprüft, die Kommunikation selbst bleibt unverändert. [Fußnote 1]
• PGP, SSL: Diese Anwendungen und die verwendeten Protokolle sichern die Kommunikation, allerdings nur für ausgewählte Objekte (z. B. die Email-Nachricht bei PGP) oder Protokolle (z. B. HTTP bei SSL) auf dem Transfer über das Netz. Der Einsatz muß vom Benutzer bewußt initiiert (bei PGP) oder bei vom Anbieter veranlaßt werden (bei SSL).
• TCP-Wrapper: Dieses Systemprogramm protokolliert Zugriffe auf bestimmte Netzwerkdienste und kann bestimmte Kontrollfunktionen anhand der IP-Adressen des Klienten übernehmen. Der Einsatz bleibt für Netzwerkdienste und Klienten unsichtbar.
• COPS, SATAN: Programme wie die beiden genannten unterstützen bei der Suche nach Sicherheitslücken. Der Einsatz muß jeweils vom Administrator initiiert werden und bedarf einer manuellen Auswertung.
• Patches, Backup: Diese grundlegenden Maßnahmen stellen sicher, daß die bekannten Sicherheitslücken im jeweiligen Betriebssystem korrigiert werden sowie die Daten und Konfigurationen oder Programme gesichert werden, so daß diese nach einem Schadensfall wieder restauriert werden können.

Im Sinne des neuen Sicherheitsbewußtseins mit seinen gestiegenen Sicherheitsanforderungen werden allerdings viel weitergehende Maßnahmen benötigt. Dies betrifft insbesondere die Absicherung folgender Anwendungen:

• Voller Internet-Zugang von Zuhause: Der Zugang über das Internet zu internen Systemen eines Arbeitgebers ist heute oft genauso üblich wie der Zugang über einen separaten Access-Server. In beiden Fällen erfolgt die Kommunikation über ein (quasi) öffentliches Netz, über dessen Sicherheit keinerlei Aussagen gemacht werden können. Während die Bedrohungen beim Zugang über das Internet bereits bewußter sind, wird das Telekom-munikationsnetz immer noch als sicher eingeschätzt.

• Anbindung sensitiver Bereiche: Um ein separates Netzwerk mit zusätzlichen Kosten einzusparen, wird immer mehr die Anbindung aller Bereiche - gerade in Unternehmen und Universitäten mit zahlreichen Außenstellen - über das "normale" interne Netz erwogen. Die Zusammenführung vormals disjunkter Netze führt gerade durch den direkten Vergleich zu der Forderung, diese Trennung mittels anderer Techniken wiederherzustellen.

• Kooperation über das Netzwerk: Hierbei handelt es sich im Prinzip um eine Erweiterung des vorhergehenden Falles, nur steht hier der Zusammenschluß zweier rechtlich getrennter Einrichtungen über ein öffentliches Netzwerk im Mittelpunkt, woraus sich anders gelagerte Bedrohungsszenarien ergeben. Attraktiv ist diese Art der Vernetzung insbesondere unter Kostengesichtspunkten und in Hinblick auf die Zusammenführung der verwendeten Kommunikationsplattformen. Auch die Möglichkeit einer Übertragung proprietärer Protokolle oder von Protokollen, die nicht auf TCP/IP basieren, ist hierfür interessant.

Gemeinsam sind allen Anwendungen dabei vor allem die folgenden Faktoren:

• Bisher eingesetzte Anwendungen sind ohne nennenswerte Sicherheit: Aufgrund der Komplexität sind Sicherheitsmechanismen auch nur schwer integrierbar.
• Bisherige Anwendungen sollen weiter unterstützt werden: Dieses stellt eigentlich die Hauptmotivation für die Suche nach einer "Zwischenschicht" dar, auf der die bisherigen Anwendungen unverändert lauffähig sind.
• Lösung soll leicht / zentral administrierbar sein: Änderungen an allen Arbeitsplätzen sind aufwendig und vor allem fehleranfällig. Z. B. die Update-Problematik oder die Abhängigkeit von den Endsystemen sprechen für zentralisierte Lösungen. [Fußnote 2]
• Erweiterungen sollen ohne großen Aufwand integrierbar sein: Da die Einführung geeigneter Lösungen aufwendig ist, sollen zukünftige Erweiterungen integrierbar sein, d. h. nicht mit jeder neuen Anwendung soll eine neue Zwischenschicht, eine neue Sonderlösung notwendig werden.
• Vorhandene "billige" Infrastrukturen sollen genutzt werden: Während die Anwendungen die Schnittstelle nach "oben" vorgeben, sind für die Schnittstelle nach "unten" besonders die günstigen und leistungsfähigen Kommunikationsinfrastrukturen relevant. Mitunter sollen Anwendungen auch (motiviert durch Rationalisierung und Einsparungen) von einem als sicher eingestuften physikalischen (und vom Internet strikt getrennten) Netz auf das Internet übertragen werden, und die Sicherheit soll dann durch eine andere Art der Trennung erreicht werden.

Auf diesen Beobachtungen und dem Spannungsfeld zwischen dem Nutzen der Anwendung und dem Bedarf nach mehr Sicherheit beruht denn auch die Idee der Virtuellen Privaten Netz, die kryptographische Verfahren einsetzen, um eine logischen Trennung der Kommunikationsströme zu erreichen, die auf einem physikalischen Netz zusammen übertragen werden, und um die übertragenen Informationen und Meta-Informationen vor unberechtigten Manipulationen und Lauschangriffen zu schützen.

Eine der grundlegenden Entscheidungen, die die Architektur eines VPNs beeinflußt, ist die Wahl der Ebene, auf der die Verschlüsselung stattfindet. Üblicherweise werden drei verschiedene Ebenen im ISO/OSI-Modell unterschieden:

• Link-Ebene (Schicht 2): Dies eignet sich insbesondere im Inhouse-Bereich oder in Campus-Netzen auf Segmenten, die ohne Routing miteinander kommunizieren.
  Pakete der Schicht 3 werden geschützt, Adressen der Schicht 2 werden verwendet.
• Netzwerk-Ebene (Schicht 3): Dies eignet sich sowohl im LAN- als auch im WAN-Bereich. Routing kann üblicherweise eingesetzt werden.
  Pakete oberhalb der Schicht 3 werden geschützt, Adressen der Schicht 3 werden verwendet.
• Anwendungs-Ebene (Schicht 7): Universell einsetzbar bleibt Routing als Eigenschaft des Netzwerkprotokolls üblicherweise möglich.
  Informationen der Anwendung werden geschützt, Adressen der Schicht 7 werden verwendet.

Je nach dem, welche Daten verschlüsselt werden, kann auf jeder Ebene wieder unterschieden werden, ob:

• Nur die Daten (Payload) werden verschlüsselt: Die Header mit allen Meta-Informationen (z. B. Protokoll der Nutzdaten, Portnummern, etc.) bleiben erhalten, insbesondere die Ziel- und Quelladressen bleiben erhalten.
  Das Routing muß für alle Endgeräte funktionieren. Alle Endgeräte müssen gültige Adressen besitzen. Die Nutzdaten werden geschützt, der Verkehrsfluß selbst und Meta-Informationen bleiben zugänglich.
• Die Pakete werden getunnelt: Auch die Header werden verschlüsselt und das gesamte Paket wird - als Nutzdaten eines neuen Paketes - mit den Adressen der beteiligten VPN-Endpunkte über das verbindende Transportnetz geschickt.
  Das Routing muß nur für die Adressen der VPN-Endpunkte aufgesetzt werden, Meta-Informationen sind nicht mehr zugänglich und auch eine Verkehrsflußanalyse ist nur noch sehr grob möglich. Für die internen Endgeräte können "private" Adressen (z. B. 10.x.x.x) genutzt werden.

Auch nach der Form der Verschlüsselung kann unterschieden werden:

• Stateless Verschlüsselung: Jedes Paket wird als für sich allein stehendes Objekt verschlüsselt. Zwischen zwei aufeinander folgenden Paketen gibt es keinen "kryptographischen" Zusammenhang.
  Diese einfache Form ist unempfindlich gegenüber Paketverluste. Zwei gleiche Pakete werden - ohne daß im Rahmen des Schlüsselmanagements weitergehende Maßnahmen ergriffen werden - genau gleich verschlüsselt. Dies eröffnet sogenannte Dictionary-Angriffe und ermöglicht Replay-Angriffe, bei denen vorher aufgezeichnete Pakete wieder eingespielt werden.
• End-to-End Protokoll: Einzelne Pakete werden nicht isoliert voneinander verarbeitet. Alle Pakete einer Verbindung werden als kontinuierlicher Strom verschlüsselt. Gegen die Auswirkungen von Paketverlusten wird ein eigenes Steuerprotokoll eingesetzt oder es bleibt den Anwendungen überlassen, nach Ausbleiben eines Paketes die "normale" Reaktion zu veranlassen.

Schließlich unterscheiden sich die Lösungen danach, ob sie in Hardware oder Software realisiert sind, wobei aber meistens hinter Hardware-Produkten ebenfalls ein PC mit einem General-Purpose-Betriebssystem und einem speziellen Softwarepaket verborgen ist.

Schlußendlich sind die kryptographischen Algorithmen, die zur Verschlüsselung und eventuell zur Authentisierung eingesetzt werden, wichtige Unterscheidungsmerkmale, die hier jedoch nicht näher betrachtet werden sollen. Auch die Verfahren zum Schlüsselmanagement haben Auswirkungen auf die aufgebaute Architektur, sollen aber ebenfalls nicht an dieser Stelle besprochen werden.

Fazit: Je mehr Daten und Meta-Informationen verschlüsselt werden, desto umfangreicher ist der Schutz. Ebenso steigt der Schutz, wenn die Pakete getunnelt werden, d. h. nur eine kleine Anzahl von Knoten ein Netz aufbauen, über das viele Endgeräte miteinander kommunizieren können.

Ein Hauptproblem bei der Einführung eines VPNs ist oft die Tatsache, daß ein VPN-Endpunkt - auch wenn er der verschlüsselten Kommunikation mit einer kleinen Anzahl weiterer Knoten dient - im strengen Sinne eine Netzanbindung, oder auch Netzöffnung, darstellt. Gibt es eine Lücke in der Sicherheit des VPN-Knotens, wird damit eventuell das gesamte dahinterliegende LAN angreifbar.

Im Sinne einer gesunden Paranoidität ist es daher unvermeidlich, die gleichen Sicherheitsmaßstäbe wie an den (sofern vorhandenen) Firewall anzulegen. Beide Komponenten dienen letztendlich dem gleichen Zweck, Informationen zu schützen und Angriffe abzuwehren, auch wenn unterschiedliche Technologien mit etwas anderen Zielsetzungen eingesetzt werden.

Hier soll vor allem die Fragestellung untersucht werden, welche Vor- und Nachteile mit der Positionierung von Firewall und VPN-Endpunkt verbunden sind. [Fußnote 3]

• Vor dem Firewall: Hierbei wird die Sicherheit des LANs immer noch maßgeblich durch den Firewall bestimmt. Die auf dem Transit durch das WAN geschützten Pakete liegen wieder im Klartext mit den ursprünglichen Adressen vor und diese können für Entscheidungen und Aufzeichnungen des Firewalls genutzt werden. Zwischen dem VPN-Endpunkt und dem Firewall bleiben Angriffe möglich, insbesondere wenn auf dem gleichen Segment Systeme mit niedrigeren Sicherheitsanforderungen (wie z. B. ein öffentliches Informationssystem) angeschlossen ist.
  Die Sicherheit des LANs bleibt autark und - im Rahmen der vorgegebenen Regeln - unabhängig von der Sicherheit der über das VPN angeschlossenen Netze. [Fußnote 4]
• Teil des Firewalls: Im Prinzip ergibt sich die gleiche Situation wie vor einem Firewall, allerdings ist nun die Sicherheit des Firewalls auch direkt an die Sicherheit des VPN-Produktes gebunden.
  Oft wird bei Firewall-Empfehlungen auf den Vorteil mehrerer unabhängiger Implemenationen hingewiesen, die dabei genannten Vorteile sind auch hier gültig.
• Nach dem Firewall: Hier müssen die verschlüsselten Pakete des VPN durch den Firewall gelassen werden, ohne daß mehr als relativ simple Plausibilitätstests durchgeführt werden können, z. B. Kontrolle der Quelladressen. Weitergehende Prüfungen sind nicht möglich, insbesondere sind auch gefälschte Pakete bereits im LAN, bevor der VPN-Endpunkt erreicht wird. Zusammen mit einer Sicherheitslücke in dem VPN-Produkt kann hier das LAN angegriffen werden, ohne daß dies durch den Firewall zu verhindern wäre.
• Neben dem Firewall: Ebenso als wenn der VPN-Endpunkt nach dem Firewall liegen würde, ist auch hier die Sicherheit des LAN zusätzlich zum Firewall vom VPN-Produkt abhängig. Allerdings gibt es für Angreifer nun zwei voneinander unabhängige Angriffspunkte, so daß der schwächste Punkt ausgenutzt werden kann.

Fazit: Ein VPN kann nicht isoliert von dem Firewall-Konzept betrachtet werden, wenn WAN-Verbindungen (d. h. über öffentliche Netze geführte Verbindungen) damit realisiert werden sollen. Prinzipiell müssen beide die gleichen Sicherheitsanforderungen durchsetzen, so darf die eine Komponente nicht erlauben, was die andere verbietet.

Durch das Nacheinanderschalten beider Komponenten ergibt sich ein Stufenkonzept, wobei der Firewall als letzte Komponente (aus Sicht des WANs) die Zugangskontrolle und die Protokollierung sicherstellt. In Prinzip jedoch ist eine parallele Positionierung wünschenswert, da sich hierbei eine Entlastung des Firewalls ergibt. Dazu muß jedoch das VPN-Produkt bis zu einem bestimmten Grad auch eine Firewallfunktionalität beinhalten. Dies betrifft insbesondere die Protokollierung und die Kontrolle von Verbindungen.

Immer sollten alle Möglichkeiten des VPN-Produkts ausgenutzt werden, um Angriffe zu verhindern oder erkennbar zu machen, unabhängig zur Positionierung der VPN-Endpunkte.

Für die Eingangs aufgeführten Anwendungsszenarien sind unterschiedliche Lösungen zu wählen, vor allem aufgrund von Faktoren wie Preis, Flexibilität und Kompatibilität.

Unter der Annahme, daß ein IP-Netzwerk bei allen Szenarien als Übertragungsnetz vorhanden ist, kann die Suche nach einem geeigneten Produkt eingeschränkt werden.

• Voller Internet-Zugang von Zuhause: [Fußnote 5] Für jeden PPP-Zugang eine spezielle Hardware zu beschaffen, wird sich kaum rechnen. Statt dessen ist hier eine Software-Lösung vorzuziehen. Auf der Gegenseite kann die Integration direkt in die Access-Server erfolgen oder es wird ein spezieller Zugangspunkt in Form eines speziellen Servers aufgebaut.
  Bei WindowsNT und Windows95 gibt es kostenfreie Implementationen des Point-to-Point-Tunneling-Protocols (PPTP), das auf PPP aufgesetzt wird. Allerdings ist die Sicherheit mit 40 Bit sehr begrenzt.
  Mit den SecureShell-Klienten können einzelne Verbindungen für die genutzten Anwendungen, ebenfalls auf PPP aufsetzend, realisiert werden. Hier wird mit Public-Key-Verfahren eine starke Authentifizierung auf Benutzerebene und starke Verschlüsselung garantiert.

• Anbindung sensitiver Bereiche: Sofern bestimmte Teilnetze miteinander verbunden werden sollen, kann im Campus- und Inhouse-Bereich die Verschlüsselung auf Link-Ebene (sofern möglich) oder Netzwerk-Ebene erfolgen. Je nach dem, ob durch andere organisatorische Mittel Angriffe auf die verschlüsselten Daten eingeschränkt werden können, braucht keine Tunneling-Lösung gewählt werden. Vorausgesetzt die Verschlüsselung ist stark genug, bleibt nur die Verkehrsflußanalyse als offensichtliches Problem bestehen.
  Die hierzu notwendige Funktion ist in Form von Devices verfügbar, die entweder zusätzlich ins Netz eingesetzt werden und dann weitgehend transparent arbeiten, oder in Form von Komponenten, die eine Standardfunktion (z. B. Bridge) wahrnimmt. Ebenso können Software-Lösungen eingesetzt werden.

• Kooperation über das Netzwerk: Dieser Fall ist der schwierigste, weil hierbei die Verbindung über ein öffentliches Netz geführt wird. Außerdem wird eine Verbindung zu einer weiter entfernten Gegenstelle mit umfangreichen Zugriffsmöglichkeiten aufgebaut, ohne daß dies der eigenen Kontrolle unterliegen würde.
  Es gibt verschiedene Hard- und Software-Lösungen, die hier eingesetzt werden können. Aufgrund der Routing-Anforderungen erfolgt die Verschlüsselung auf der Netzwerk-Ebene. Zur Vermeidung von Verkehrsflußanalysen sollte ein Tunneling-Modus eingesetzt werden.

Fazit: Sofern mehr als ein Szenario unterstützt werden soll, wird sich die Einführung unterschiedlicher Techniken nicht vermeiden lassen. Damit einher gehen zur Zeit noch die Probleme des Managements, das ebenfalls komplexer wird bzw. nicht an einer Stelle zu zentralisieren ist.

Statt überall grundsätzlich die VPN-Technologie einzuführen, sollte Sensitivität und Ausmaß der übertragenen Informationen weitestgehend reduziert werden.

Eine Vereinfachung wird erst mit dem IPv6 Protokoll möglich, wobei es dort bedingt durch die Implementation, auch Vor- und Nachteile gibt, die zumindest eine Abwägung eigener Anforderungen nicht überflüssig machen.

Zusätzlich zu den bereits aufgeführten Anforderungen oder Kriterien, aus denen die individuellen Anforderungen noch abgeleitet werden müssen, gilt es, weitere Anforderungen zu berücksichtigen.

Sicherheitslücken von VPN-Produkten: Es gibt keinen Grund anzunehmen, daß VPN-Produkte weniger Sicherheitslücken enthalten sollen als herkömmliche Produkte. Insbesondere die kryptographischen Verfahren schaffen auch neue Schwachstellen, z. B. ist die Erzeugung von "guten" Zufallszahlen ziemlich schwierig.

Auch, oder gerade dann, wenn General-Purpose-Betriebssysteme als Plattform zum Einsatz kommen, sollte zumindest die Notwendigkeit von Patches hinterfragt werden und der Hersteller sollte relevante Informationen in Bezug auf die Sicherheit seines Produkts anbieten.

Stärke der Verschlüsselung: Nicht nur die Exportbeschränkungen sind hierbei zu berücksichtigen, denn auch etablierte Verfahren müssen inzwischen als unsicher angesehen werden. Eine Verschlüsselung mit den bekannten Verfahren (DES, RC2, RC4, IDEA, ...) und nur 40 Bit vom Benutzer wählbarer Schlüssellänge reicht nicht aus, um auch nur mittelfristig die Informationen zu schützen.

Eine Verschlüsselung mit DES sollte baldmöglichst zugunsten von Verfahren mit einer größeren Schlüssellänge als 56 Bit ersetzt werden, also Triple-DES, IDEA, o. ä.

Schlüsselmanagement: Die Erzeugung und der Einsatz von Schlüsseln zur Sicherstellung der Synchronisation zwischen Sender und Empfänger sowie zur Authentisierung der Kommunikationspartner ist nicht trivial, insbesondere wenn das VPN mehr als einige wenige Knoten besitzt.

Vielfach ist die erste Personalisierung nur direkt am Gerät durchführbar. Dies erzwingt zwar einen Mehraufwand bei der Installation, verschafft aber auch eine gewisse Sicherheit.

Remote Management: Gerade wenn sich das VPN über unterschiedliche Orte und Einrichtungen erstreckt, gibt es die Anforderung an eine schnelle und effiziente Konfiguration bzw. Kontrolle. Dazu gibt es entweder die Möglichkeit, standardisierte Protokolle wie SNMP einzusetzen, oder aber es gibt proprietäre Protokolle oder Schnittstellen, über die Informationen abgerufen werden können. Zusätzlich sind oft auch Konfigurationsmöglichkeiten vorhanden, die die Integration eines neuen VPN-Endpunkts, Erzeugung und Verteilung neuer Schlüssel o. ä. erlauben.

Oft werden diese Möglichkeiten aber nur selten wirklich genutzt oder benötigt, so daß es wünschenswert wäre, wenn diese Möglichkeiten auch individuell abgeschaltet werden können. In jedem Fall muß vor der Nutzung eine starke Authentisierung erfolgen, alle übertragenen Daten müssen stark verschlüsselt sein und die einzelnen Befehle sollten auch revisionssicher protokolliert werden.

Fazit: Über die Fragen der gewählten Lösung und Struktur hinaus, gibt es viele praktische Gesichtspunkte beim Betrieb von VPNs, die die Aufmerksamkeit bereits bei Auswahl des Produktes erfordern.

Ganz klar kann dieser Beitrag keine Empfehlungen für oder gegen ein bestimmtes Produkt geben. Wohl aber können die verschiedenen Überlegungen direkt auf die eigene Anwendungssituation angewandt werden. So wird die Auswahl von Produktvorgaben erleichtert und auch der Vergleich unterschiedlicher Produkte in den genannten Kategorien sollte einen Auswahlprozeß unterstützen.

Ansonsten kann ein eigener Test eines bestimmten Produkts nur empfohlen werden, allerdings ist dies sehr aufwendig, wenn die Anwendungssituation sehr genau nachgebildet werden soll und das Expertenwissen nicht bereits verfügbar ist. Es ist sicherlich in den meisten Fällen nicht möglich oder mit den vorhandenen Ressourcen nicht wünschenswert, mehrere Produkte zu testen. Daher kommt einer möglichst präzisen Vorauswahl noch mehr Bedeutung zu. Mehrere Tests sind unumgänglich, wenn sich das erste Produkt als unzureichend erweist.

Es ist zu wünschen, daß Anwender, die konkrete Erfahrungen mit einzelnen Produkten gemacht haben, diese Erfahrungen anderen zur Verfügung stellen. Bei allen eigenen Anstrengungen muß auch die weitere Entwicklung verfolgt werden, die sicherlich sowohl die Preise günstiger werden lassen als auch neue Möglichkeiten bringen werden.

Andere Maßnahmen zur Sicherung der Kommunikation und der beteiligten Endgeräte werden natürlich nicht überflüssig, allerdings werden sehr viele übliche Angriffe, wie sie im Internet bekannt sind, verhindert oder bleiben unwirksam. Dafür bleiben zwei Angriffsformen übrig, die nicht vernachlässigt werden dürfen:

• Der Zugriff auf die - verschlüsselten - Informationen erlaubt Angriffe mit krypto-analytischen Verfahren.
• Der Zugang zum Netz, dessen Verfügbarkeit und die Kommunikation selbst kann durch Denial-of-Service-Angriffe eingeschränkt bzw. behindert werden.

Gegen die Krypto-Analyse kann nur durch starke Verschlüsselungsverfahren vorgebeugt werden. Eine erfolgreiche Entschlüsselung darf in keinem Fall gelingen, bevor nicht die Informationen wertlos oder überholt sind. [Fußnote 6] Es dürfen also keinerlei Informationen übertragen werden, die langfristig geschützt werden sollen.

Die Denial-of-Service-Angriffe können generell nicht verhindert werden. Hier muß sichergestellt werden, daß es Ausweichrouten gibt und die Endpunkte des VPN sind soweit es geht vor schädigenden Einflüssen zu schützen.

Die letzte Empfehlung richtet sich an Verantwortlichen, die für den Personaleinsatz verantwortlich sind. Wie auch Firewalls sind VPNs hochkomplexe und empfindliche Konstrukte, die kontinuierliche Pflege und Wartung benötigen. In beiden Fällen muß Fachpersonal verfügbar und auf einem guten Ausbildungsstand sein. So sehr auch die Personalkosten abschrecken mögen, sind sie der eigentliche Preis, der für die erfolgreiche Einführung eines funktionierenden Produkts gezahlt werden muß.

Es gibt eine riesige Menge von öffentlich verfügbaren Informationen im Internet, genauso wie einige - abgesehen von Exportbeschränkungen - nutzbare Implementationen.

Die eigentlichen Informationen wie die Verschlüsselungsalgorithmen, die in der aktuellen Version unterstützt werden, und insbesondere natürlich die genauen Preisen (;-) zusammen mit den Rabatten) sind nur von den Herstellern bzw. Resellern verfügbar. Einige Sammlungen mit Referenzen von kommerziellen Anbietern sind über die hier erwähnten Informationsquellen zugänglich. Die Aufstellung hier kann nicht vollständig sein, so gesehen sind Herstellerreferenzen nur als Beispiele anzusehen, die der Illustration des Gesagten dienen sollen.

• Altavista:
  • Tunnel 97
• ASCEND:
  • VPN Resource Guide
  • Ascend Tunnel Management Protocol für ISPs
  • Ascend Tunnel Management Protocol für Carrier
  • Multichannel Protocol Plus FAQ
• Checkpoint:
  • SecuRemote
• CISCO:
  • Point-to-Point Protocol
  • IOS Security Architecture
• Tom Dunigan's VPN Page
  • Virtual Private Networks
• IETF - Requests for Comments und Internet Drafts:
  • Ascend Tunnel Management Protocol ATMP / RFC2107
  • Generic Routing Encapsulation GRE / RFC1701
  • Generic Routing Encapsulation over IPv4 / RFC1702
  • Security Architecture for the Internet Protocol / RFC1825
  • IP Authentication Header / RFC1826
  • IP Encapsulating Security Payload / RFC1827
  • Implementation of Virtual Private Network (VPNs) with IP Secrity (ausgelaufenes Draft von März 1997)
• Microsoft:
  • Virtual Private Networking
  • PPTP
  • Windows 95 PPTP Client
  • Routing and RAS Erweiterung
• Point-to-Point Tunneling Protocol (PPTP):
  • IETF PPTP Draft
  • PPTP FAQ
  • siehe auch unter Microsoft
• SecureShell und Weiterentwicklungen:
  • SSH
  • SSH FAQ
  • F-Secure

1. Zunehmend bieten Firewall-Hersteller Ergänzungsmodule an, die praktisch den Firewall zu einer Endpunkt eines VPNs machen. Dies darf jedoch nicht mit dem eigentlichen Firewall verwechselt werden. Vielmehr muß gerade hier genau verstanden werden, welche Implikationen so eine Kombination für die Gesamtsicherheit hat.
2. Damit soll nicht behauptet werden, die Sicherheit der Endgeräte - und damit der Benutzer - dürfte ignoriert werden. Nur ist aus Sicht des Unternehmens Sicherheit leichter zentral zu überwachen und durchzusetzen, vergleichbar der Entwicklung bei Firewalls.
3. Für eine interessante Diskussion einer eng damit in Zusammenhang stehenden Frage Firewalls und IPv6 sei auf den Artikel von Uwe Ellermann unter http://www.cert.dfn.de/team/ue verwiesen.
4. Allerdings kann ein Angreifer auch Erfolg haben, ohne nun in das LAN eindringen zu müssen. Es reicht ihm unter Umständen vollkommen aus, auf die Informationen, die ja jetzt auch in anderen Einrichtungen vorliegen, zuzugreifen.
5. Die Anbindung vieler Endgeräte ist nicht unbedingt als VPN anzusehen, verfolgt jedoch die gleichen Ziele und basiert auf den gleichen Techniken.
6. Hier muß auch auf Meta-Informationen hingewiesen werden, wie z. B. die Tatsache, daß bestimmte Kommunikationen überhaupt stattgefunden haben, etc. Die "Haltbarkeit" solcher Meta-Informationen ist erheblich länger als die der eigentlichen Informationen.