VPN

VPN steht für Virtual Private Network. Das heißt, ein Netz, welches auf irgendeine virtuelle Weise „privat" ist. Virtuell – das sollte man in diesem Zusammenhang einmal wörtlich nehmen: „der Anlage, dem Wesen nach". Nicht zugleich aber ist jedes VPN aktuell auch schon privat. Was die Privatheit ausfüllt, wird durch Sicherheitsanforderungen bestimmt, die an den Datenverkehr über das Netz gestellt werden. Für gewöhnlich versteht man darunter:

Privatheit kann alle drei Punkte umfassen, darf aber auch nur Authentizität erfordern (etwa bei der Anmeldung an einem Server oder einem Dienst). Innerhalb dieser drei Gruppen gibt es weitere Abstufungen im Sicherheitsniveau, z. B. die gewählte Schlüssellänge. Kurzum, ein VPN bezeichnet vorerst irgendeinen Übertragungskanal zwischen zwei Punkten über ein öffentliches (d. h. Dritten zugängliches) Netz, bei dem die Öffentlichkeit vom Zugang zu den Daten mehr oder weniger ausgeschlossen wird. Oft wird – wie beispielsweise in [1] – das VPN allein auf den Tunnel, d. h. die Verbindung zwischen zwei Netzen/Rechnern reduziert. Schon aus Sicherheitsgründen umfasst ein VPN aber alle an dem Datenverkehr beteiligten Komponenten der verbundenen Netze, einschließlich der Firewallregeln, des Routings, lokaler Sicherheitsrichtlinien und einer Technologie, die für die Sicherheit der Daten auf dem öffentlichen Teil der Übertragungsstrecke sorgt. Denn ein Tunnel hat immer zwei offene Enden, durch die man in den Tunnel hineinsehen kann, und das Sicherheitsniveau eines VPNs entspricht immer dem Niveau des unsichersten der beteiligten LANs.

IPsec

Für die Übertragung in Netzwerken müssen die Daten verschiedener Anwendungen in eine Form gebracht werden, die ihre Übertragung über unterschiedliche Medien in ganz andere Softwareumgebungen ermöglicht. Das geschieht über verschiedene Ebenen, jede hat spezielle Aufgaben: eine beschäftigt sich mit der Zeichendarstellung, eine mit Adresszuordnung, eine mit den Besonderheiten des Übertragungsmediums. Diese Modularität stellt sicher, dass die Zeichenketten, welche schließlich übers Netz gehen, vergleichbar sind und auf der anderen Seite auch dann gelesen werden können, wenn dort ein anderes Betriebssystem und andere Anwendungssoftware läuft. Diese Ebenen entsprechen allgemein verbindlichen Standards für den Datenaustausch von Rechnern und sind beschrieben im OSI (Open Systems Interconnection)-Referenzmodell (siehe Abb. 1). Die Anwendungsdaten müssen alle diese Ebenen durchlaufen, bevor sie übertragen werden können. Auf einer dieser Stufen, der Netzwerkschicht des OSI-Modelles, gibt es in einem TCP/IP-Netz nur ein einziges für die Übertragung von Anwenderdaten relevantes Protokoll. Genau genommen kümmert sich dieses Protokoll, das Internet Protokoll (IP), gar nicht um den Inhalt des Datenstromes, den es behandelt. Es ist diese Netzwerkschicht vielmehr wie eine Poststation, die alle Pakete mit den erforderlichen Adressinformationen versieht und die Wege festlegt, über die die Daten beim Empfänger ankommen. Mehr geschieht hier eigentlich nicht, doch es ist klar: Daten von tausenden verschiedener Anwendungen müssen durch diese eine Poststation. Wird hier an den Paketen ein zusätzlicher Sicherungsmechanismus angebracht, ist alles, was auf die Reise geht, seien es Fotos, Datenbankinhalte, Textdateien, unterschiedslos versiegelt. Die Poststation der Netzwerkschicht ist der Flaschenhals, durch den die Mannigfaltigkeit des Internetverkehrs hindurch muss.

Dieser Sicherungsmechanismus, der auf der Netzwerkebene von TCP/IP-Netzen arbeitet, heißt IPsec. IPsec sichert IP-Pakete, es wird diesen quasi eingeimpft und schützt somit nicht einzelne Anwendungen, sondern das ganze Netz. IPsec-Prozessoren gibt es als Hardware- oder Softwarevariante. Die Software wird in den TCP/IP-Protokollstapel des Betriebssystemes integriert und erscheint als zweiter, virtueller Netzwerkadapter, durch den der gesamte Datenverkehr in Richtung Netz hindurch geht, bevor er die Netzwerkkarte erreicht. Umgekehrt laufen alle Daten aus dem Netz von der Netzwerkkarte aus über diesen IPsec-Prozessor. Dieser entscheidet anhand einer Richtliniendatenbank, ob die Daten geblockt werden, ob sie unbehandelt passieren dürfen oder ob sie gesichert werden sollen. Dieser Prozess ist für die Anwendung, über die der Benutzer auf das Netz zugreift, transparent, d. h. sie bekommt davon nichts mit, wie es ihr auch gleichgültig sein kann, welche Netzwerkkarte in dem Rechner steckt, auf dem sie installiert ist.²

Abb. 1: IPsec und SSL/TLS im OSI-Modell

Der IPsec-Standard beschreibt kein einfaches Protokoll, sondern ein Bündel von Komponenten: Sicherheitsprotokolle (Authentication Header, AH bzw. Encapsulating Security Payload, ESP), eine Datenbank mit Sicherheitsrichtlinien (Security Policy Database, SPD), Instanzen, um diese Richtlinien durchzusetzen (Security Associations, SA) und ein Schlüsselmanagement, das für die Erzeugung und den Austausch der für die Authentifizierung und Verschlüsselung jedes einzelnen Paketes benötigten geheimen Schlüssel (session keys) zuständig ist. Leider war es aus Platzgründen nicht möglich, das Kapitel über die IPsec-Komponenten hier mit zu veröffentlichen. Interessenten wenden sich bitte an die im Abstract angegebene Internetadresse.

Aufbau

An der Humboldt-Universität wird VPN-Software getestet mit dem Ziel, ein VPN aufzubauen, über das Benutzer aus Fakultätsverwaltungen auf Daten zugreifen können, die auf Servern im zentralen Verwaltungsnetz hinter einer Firewall liegen. Anwendungssoftware ist HIS-FSVGX. Die Benutzer greifen über einen Terminalserver auf eine Datenbank zu. Da es sich dabei um vertrauliche Daten handelt, ist Verschlüsselung (also ESP) erforderlich. Im Einsatz befindet sich gegenwärtig F-Secure VPN+, installiert auf fünf Plätzen im Universitätsnetz. Schließlich sollen aber auch die Möglichkeiten von Windows 2000-IPsec getestet werden.

Abb. 2: Gegenwärtiger Stand des VPNs

Abbildung 2 zeigt den gegenwärtigen Stand des Test-VPN. Die folgende Erklärung bezieht sich auf diese Grafik. Die gestrichelten Linien A und D bezeichnen verschlüsselte, authentifizierte Kommunikation gemäß dem ESP-Protokoll. Die Verbindungen B, C und E stehen für Klartextkommunikation. Verschlüsselung findet zwischen der Workstation und dem Security-Gateway statt. Zwischen beiden besteht eine Tunnel Mode-SA, wobei die Source-Adresse der Workstation ungeschützt ist.

Bsp. 1: Adressangaben der IP-Header

Die Firewall muss den Verkehr auf UDP Port 500 für die IKE-Pakete⁴ (am Beginn Klartext!) gestatten, ferner natürlich für IP-Pakete mit Protokoll-ID 50 (ESP).

Die SPD für die Workstation enthält außer einer Regel für die Verbindung zum Terminalserver (Zielnetz: 141.20.sss.y/32 – also nur der Terminalserver, Gateway: 141.20.sss.x, Protokoll: ESP) nur eine Discardregel, die auf alle IP-Adressen zutrifft (also alle Pakete blockiert) und deshalb nach der IPsec-Regel stehen muss (da auf ein Paket die erste zutreffende Regel angewendet wird). Dieser Rechner kann also nur mit dem Gateway. Die SPD für das Gateway besteht aus einer IPsec-Regel (das Spiegelbild der Regel für die Workstation), einer Discard-Regel auf den gesamten IP-Verkehr sowie (vor der Discard-Regel!!!) einer IPsec-Regel für die direkte (Transport Mode) Verbindung zu einem Rechner, welcher Policies verwaltet und vertreibt. Das Gateway kann sich also neue Policies (nötig etwa, wenn ein neuer Client eingebunden wird) automatisch bei dem sogenannten VPN-Server abholen. Das Vorhandensein eines expliziten VPN-Servers und die Möglichkeit der Steuerung eines VPN über das Netz sind implementationsabhängig.

Probleme beim Aufbau eines VPNs

Die Probleme lassen sich in drei Gruppen unterteilen, zu denen hier je ein Beispiel aufgeführt wird:

Sicherheit

Die schwächste Komponente bestimmt die Sicherheit des Gesamtsystems! Hier erhellt sich, warum ein VPN mehr ist als nur ein Tunnel. Auf der einen Seite des VPN befindet sich der durch eine Firewall geschützte „Hochsicherheitstrakt" des zentralen Verwaltungsnetzes, auf der anderen Seite ein Rechner, der neben der gesicherten Verbindung eine Vielzahl weiterer TCP/IP-Verbindungen unterhält: Internet, E-Mail, DNS, NT-Domänenmitgliedschaft, IP-Drucker ... So ein Nebeneinander von sicheren und ungesicherten Verbindungen weicht die Sicherheit von IPsec gewaltig auf. Nistet auf einer dieser VPN-Client Maschinen ein Backdoor-Virus oder eine harmlose Fernwartungssoftware, so gibt es eine Datenautobahn direkt aus dem Herzen des zentralen Verwaltungsnetzes hinaus in die weite Welt, da die Virensoftware die Daten, die ja nach dem IPsec-Prozess auf der Workstation wieder im Klartext vorliegen, über eine offene Verbindung verschicken kann. Das wäre, als ob ein Unbefugter dem Sachbearbeiter über die Schulter auf den Bildschirm schaut. Deshalb sieht die Testphase für die daran beteiligten Rechner nur eine sehr rigide Policy vor, die ausschließlich IPsec-Connections gestattet. Nun ist es jetzt schon ohne Probleme möglich, den Nutzer mit einer Policy auszustatten, die ihm das Umschalten zwischen zwei Gruppen von Filterregeln, die sich gegenseitig ausschließen, per Mausklick gestattet: Eine Internetkonfiguration für alle benötigten TCP/IP-Dienste ohne Zugriff auf das Security Gateway und eine sichere Konfiguration, die nur IPsec-Verbindungen erlaubt. Sicher ist dies ein Kompromiss, aber auch dieser erfordert eine genaue Abstimmung der Policy-Inhalte auf das Profil der Anwendungen, die der Nutzer benötigt. Die zentrale Firewall verlagert sich quasi auf die lokale Firewall des VPN-Clients. Und genau da beginnen die Probleme, denn hier prallen unter Umständen UV-Sicherheits-Richtlinie und Fakultäts-Policy aufeinander. Wahrscheinlich werden in der Internet-Policy sämtliche benötigten Dienste wie Datenbankserver, IMAP und SMTP-Server, DNS-Server, Domaincontroller, Netzdrucker usw. per IP-Adresse des Servers aufgeführt werden. Mit Sicherheit aber heißt das (wegen der geschilderten Backdoor-Bedrohung): Internet nur über Proxy! Weitere Einschränkungen bleiben, da z. B. das Durchsuchen der Netzwerkumgebung für NT-Domänenrechner in der Policy einen Bypass auf die Broadcast-Adresse des Netzes erfordert (nicht nur das Browsen nach Ressourcen durch den Nutzer, sondern das gesamte mit dem Computersuchdienst verbundene Prozedere ist betroffen). Schließlich – und da gibt es noch gar keine Erfahrungen – müssen Services im Active Directory erreichbar sein⁵. Und wenn gar eine Fakultät beabsichtigt, ein eigenes VPN mit Windows 2000-IPsec aufzubauen, kann kein IPsec-Dienst einer anderen Firma auf diesen Rechnern laufen. Immerhin war es schon möglich, über IPsec eine Verbindung zwischen Windows 2000-IPsec und F-Secure-VPN+ herzustellen, wenn auch nur mit Preshared Key-Authentifizierung.

Aber gerade diese Schnittstellen zwischen zwei Systemen unterschiedlicher Hersteller, die ja jeweils ihre eigenen Vertriebsmechanismen für Policies besitzen, eröffnen ein weiteres Problemfeld.

IPsec-Struktur

IPsec baut auf der IP-Protokollebene auf. IP (und damit AH bzw. ESP) ist ein verbindungsloses Protokoll, d. h. es gibt keine speziellen Mechanismen für das Aufbauen, Überwachen und Beenden von Verbindungen, wie etwa bei Layer2-Protokollen (PPP, L2TP) oder auf höherer Ebene (TCP). Es wird kein Kanal zwischen den beiden Endpunkten durchgeschaltet, die IP-Pakete tragen alle Informationen bei sich, die benötigt werden, damit sie sich nicht verlaufen. Für unsere IPsec-Protokolle bedeutet dies: Es werden einfach AH oder ESP-Pakete losgeschickt, die mit einer SA (Security Association) matchen oder nicht. Gibt's keine SA, wird versucht, eine einzusetzen und das fortlaufend, solange z. B. ein Ping läuft, wenn nicht die Verbindung auf höherer Ebene abgebrochen wird (etwa durch Timeout des ICA-Clients, der keinen Server findet). Das sind so gesehen relativ „dumme" Protokolle, verglichen mit dem Verfahren beispielsweise beim Aufbau einer DFÜ-Verbindung. Aber das ist noch gar nicht das Problem. Eigentlich sollte es so sein, dass der Nutzer auf ein Anwendungsicon auf seinem Desktop klickt und – angenommen die Anwendung startet eine Netzverbindung, die IPsec erfordert – ein Fenster erscheint, mit der Bitte, man möge doch das Passwort zur Freigabe des verschlüsselten Private Keys eingeben. So etwas ist aber innerhalb der IPsec-Spezifikation nicht vorgesehen. Sowie die Anforderung an eine Verbindung steht, schießt IPsec los – ob der Key nun entschlüsselt ist oder nicht. Der eigentliche Aufbau einer Verbindung läuft auf höheren Ebenen des OSI-Modelles ab, Ebenen, die aber gerade IPsec schon voraussetzen. Arbeitet man bei F-Secure VPN+ z. B. mit Smartcardauthentifizierung, erscheint die Aufforderung zur Eingabe der PIN ausschließlich beim Start des Dienstes (also beim Starten des Betriebsystemes). Verpasst man diese Gelegenheit, ist ein Neustart erforderlich. Ein Verbindungsmanagement außerhalb von IPsec aufzusetzen, ist sicher eine Frage geschickter Implementation in eine VPN-Software. Man kann aber auch überlegen, ob sich – in Ergänzung zur VPN-Software und in Zusammenarbeit mit deren Entwicklern – eine Art Applikationsstarter schreiben lässt. Der Benutzerklick auf das Icon startet dann nicht die Netzwerkapplikation direkt, sondern eine Anwendung, welche die zu startende Software als Parameter übernimmt, anschließend die Funktion des VPN+-Agenten zur Eingabe der PIN für den Schlüssel aufruft, die Meldung über das erfolgreiche Entschlüsseln desselben auffängt und dann die Applikation startet, die nun eine „fertige" IPsec-Umgebung mit gültigen Schlüsseln vorfindet. Da kann man dann mit bequemen nutzerfreundlichen Timeouts rechnen.

PKI

Man kann die Authentifizierung für IPsec-Verbindungen mit Preshared Keys (beiden Seiten im Vorhinein bekannten Geheimwörtern), aber auch mit Public Keys durchführen. Dabei versichert der Sender dem Empfänger über eine signierte Zeichenkette, dass es sich bei ihm um die im Zertifikat angegebene Person handelt, wobei das Zertifikat von einer bestimmten, für diese Verbindung zuständigen CA stammt. Nun kann sich so ein Zertifikat, das ja den öffentlichen Schlüssel einer Person darstellt, jedermann besorgen. Allerdings besitzt nur der Eigentümer des Zertifikates den zugehörigen Privaten Schlüssel, und dieser Schlüssel wird für die Signatur benötigt, die man mit dem Public Key verifizieren kann. So weit, so gut. Das Problem besteht darin, dass bei Windows 2000 z. B. eine RSA-authentifizierte (d. h. mit dem Public Key-Verfahren) Verbindung durch irgendein Zertifikat, das von einer festgelegten Zertifizierungsstelle unterzeichnet wurde, aufgebaut werden kann. Nun wird die Identität einer Person im Zertifikat durch einen so genannten Distinguished Name beschrieben. Dieser enthält neben speziellen Angaben zu dem einzelnen Nutzer auch hierarchisch geordnete Kategorien wie Organisation oder Unterorganisation. Aber die DN-Struktur unserer HU-CA orientiert sich an der Organisationsstruktur der HU, nicht an VPN-Domänen, d. h. es gibt keine organisatorische Einheit (OU) für VPN-Nutzer. So kann es passieren, dass aus Abteilung X sowohl der Herr Y als auch das Fräulein Z eine IPsec-Verbindung herstellen können, weil beide über ein Zertifikat verfügen, das von einer CA unterzeichnet ist, die für diese Verbindung authorisieren darf. Nun kann man – wenigstens bei F-Secure – die OU des berechtigten Benutzers genauer spezifizieren, so dass man nicht mit jedem HU-CA-Zertifikat an die Verbindung kommt. Allein das hat seine Grenzen, weil sowohl der Herr Y als auch das Fräulein Z dieselbe OU, nämlich Abteilung X, in ihrem Zertifikat zu stehen haben, aber eigentlich nur der Herr X authorisiert ist. Hier sollte man auf dem Gateway mit Zugriffslisten unter den Zertifikaten filtern können. Dieses Problem ist übrigens nicht wie das vorangegangene dem IPsec-Standard geschuldet, und [2], S. 200 – 204, beschreibt so eine Möglichkeit bei der Darstellung der Authentifizierungsmodi der IKE (des Schlüsselaustausches für IPsec), bei der das von mir eben beschriebene – bei Windows 2000 und F-Secure VPN+ vorhandene – Verfahren, von einem Verfahren unterschieden wird, wie man es vom E-Mail-Verschlüsseln kennt. Hier werden keine Zertifikate ausgetauscht, sondern das Gateway beispielsweise kann nur antworten, wenn es den öffentlichen Schlüssel des Partners kennt (also einen Speicher mit gültigen Zertifikaten unterhält).

Tunnel haben naturgemäß Ausgänge. Und über die öffnet der Tunnel eine Verbindung zwischen Bereichen, die sonst getrennt wären. Schwappt von diesen Öffnungen aber allenthalben Wasser in den Tunnel, so sind die stärksten Tunnelmauern nutzlos, ja gefährlich, da sich hinter ihnen eine trügerische Sicherheit breit macht. So sind Licht und Schatten an den Tunnelenden mehrdeutig, denn das Licht, das durch den Tunnel fällt, wirft Schatten auf die Sicherheit der Bereiche, die sich ihm anvertrauen.