Sicherer Remote Access unter Windows 2000 in einem Industrieunternehmen

Inhaltsverzeichnis

1 Einleitung

2 Grundlagen
2.1 Zugriffsszenarien für Remote Access
2.2 Verschlüsselungsverfahren
2.3 Public Key Infrastructure
2.3.1 Aufbau der Hierarchie
2.4 Kerberos
2.5 Virtual Private Network
2.5.1 Funktionsweise eines Tunnels
2.5.1.1 Transport Modus
2.5.1.2 Tunnel Modus
2.5.2 IPSec (IP Security)
2.5.3 PPTP (Point-to-Point Tunneling Protocol)
2.5.4 L2TP (Layer 2 Tunneling Protocol)
2.5.4.3 L2TP/IPSec (Layer 2 Tunneling Protocol over IPSec)
2.5.5 Vergleich L2TP mit PPTP
2.5.6 Client-to-Client-Kommunikation
2.5.7 Gateway-to-Gateway-Kommunikation
2.5.8 Client-to-Gateway-Kommunikation
2.6 Routing and Remote Access (RRAS)
2.7 Remote Authentication Dial-In User Service (RADIUS)

3 Untersuchung der Funktionalitäten in Windows 2000
3.1 RAS
3.2 VPN
3.3 Active Directory
3.4 PKI

4 Beschreibung der Testumgebung
4.1 Router als VPN-Endpunkt
4.2 Aufbau mit Cisco VPN Concentrator

5 Ergebnis
5.1 Windows 2000.
5.2 VPN mit Cisco/Altiga VPN 3000 Concentrator
5.3 VPN mit Cisco 2600 VPN-Router
5.3.1 Fehlerbeschreibung.
5.3.2 Fehlerdiagnose
5.4 Gesamtergebnis

6 Aufbau eines Prototypen mit Beschreibung der Installation
6.1 Installation des Laptops
6.2 Einrichten von Group Policies für IPSec-Verbindungen
6.3 Einrichten der CA für Server, Client und Cisco-VPN-Router
6.4 Verwendung des Verbindungsmanagers des Servers
6.5 Verwendung des Verbindungsmanagers des Client
6.6 Konfiguration des Altiga/Cisco VPN 3000 Concentrators

7 Weitere Funktionen von Windows 2000 für mobile Benutzer
7.1 Synchronisation von Daten
7.2 Lokale Verschlüsselung
7.3 ACPI

8 Fazit

Literaturverzeichnis

Eidesstattliche Erklärung

1 EINLEITUNG

Vertrauenswürdige Informationen, durch die andere auch profitieren könnten, gilt es besonders zu schützen, da nicht nur wirtschaftlicher Schaden entstehen könnte, sondern auch Prestigeverlust.

Dabei gilt es sowohl die Industriespionage zu verhindern, aber auch Computer- hackern das Handwerk zu legen.

In der heutigen Zeit, in der die Flexibilität des Arbeitnehmers gefordert wird, muss dieser von überall auf seine Daten zugreifen können. Dabei hat der Benutzer zwei Möglichkeiten, um auf den Firmen-Server zu gelangen: zum einen die Einwahl über eine Telefonverbindung per Remote Access und zum anderen über öffentliche Netze, z.B. das Internet durch einen Internet Service Provider (ISP)¹.

Im Internet werden aber auch die Programme² angeboten, durch die das Ausspionieren von IP-Paketen erst möglich wird. Dadurch steigt die Anzahl der möglichen Computerhacker ständig an, da sich jeder Internetbenutzer diese Programme relativ einfach besorgen kann.

Netzwerksicherheit gewinnt für Unternehmen unterschiedlichster Größe zunehmend an Bedeutung.

Um die Datenübertragung zu schützen, benötigt man zum einen eine verschlüsselte Authentifizierung des Anwenders. Realisierte man früher die Anmeldung über einfache Telnetfunktionen, d.h. Login und Passwort wurden im Klartext über die Leitung übertragen, bedient man sich heute anderer Methoden, die das Abfangen der Login-Informationen schwieriger gestalten.

Weiterhin wird zusätzlich noch der Datenverkehr verschlüsselt, d.h. es werden die einzelnen Pakete verschlüsselt und mit einen neuen IP-Rahmen verpackt. Dadurch sind die Pakete vor dem Einsatz von Sniffer-Programmen² geschützt.

Die vorliegende Diplomarbeit mit dem Titel »Sicherer Remote Access mit Windows 2000 in einem Industrieunternehmen« ist Teil eines Windows 2000-Projekts der Degussa-Hüls AG in Frankfurt am Main. Das Gesamtprojekt umfasst zusätzlich noch

u.a. den Aufbau einer Verzeichnisstruktur für den Gesamtkonzern und die Auswahl der zu installierenden Softwarepakete auf den einzelnen Laptops, aber auch den sicheren Verbindungsaufbau der Remote User zu den einzelnen Standorten.

Das Ziel der Diplomarbeit ist die Untersuchung eines Verbindungsaufbaus eines Virtual Private Network (VPN) über ein Wide Area Network (WAN)³ zwischen einem mobilen Windows 2000-Anwender und einem privaten Netzwerk.

Es werden die unter Microsoft Windows 2000 zur Verfügung stehenden Programme, Dienste und Funktionen, die für einen sicheren Verbindungsaufbau sowohl über das Telefonnetz als auch durch öffentliche Netze nötig sind, untersucht. Dabei werden

u.a. die verschiedenen Techniken aufgezeigt, die zur Authentifizierung des Client notwendig sind.

Neben der VPN-Technik wird der Aufbau und die Durchführung einer Certificate Authority (CA) unter Windows 2000 vorgestellt. Nachdem die Theorie abgeschlossen ist, wird das Zusammenspiel aller zur Verschlüsselung entscheidenden Komponenten (Active Directory, Remote Access Service, VPN und CA) in einem dafür speziell aufgebauten Umfeld, das in einem eigenen Kapitel beschrieben wird, getestet.

Während der Diplomarbeit werden die von Windows 2000 für mobile Benutzer gebotenen neuen Möglichkeiten im Einzelnen untersucht und aufgeführt.

2 Grundlagen

2.1 Zugriffsszenarien für Remote Access

Bei dem Einsatz von Remote Access (RAS) macht es keinen Unterschied, ob es sich um einen Mitarbeiter mit einem Laptop in einem Hotelzimmer oder um einen Desktop-Rechner zu Hause handelt. Nur die verwendeten Methoden, die einen Anwender Zugriff auf das Netzwerk ermöglichen, sind zu unterscheiden. Dabei handelte es sich bei RAS ursprünglich um ein proprietäres Protokoll, das von der Firma Microsoft entwickelt wurde.⁴

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: RAS

Dial Internet-Connection/ Direct Dial In

Windows 2000 Professional

Bei RAS wird eine Verbindung zwischen einem Client und einem Server oder Router hergestellt. Dieser Vorgang wird auch als »Native RAS«bezeichnet.

Die Authentifizierung des Client wird mit einer Kombination von Usernamen und Passwort auf dem Endgerät verglichen. Diese Informationen werden im Klartext übertragen, d.h. es findet zu diesem Zeitpunkt keine Verschlüsselung statt. Diese Art der Authentifizierung wird bei Mailboxen oder ISPs verwendet und wird als »Dial-In« bezeichnet.

Werden nach der Authentifizierung des Client noch zusätzlich Zugriffsberechtigungen auf Netzwerkressourcen erteilt, d.h. es findet eine Autorisation des Client statt, bezeichnet man dieses als RAS. Die Authentifizierung und Autorisation des Client kann auch von einem Remote Authentication Dial-In User Service (RADIUS)-Server übernommen werden.

Für den Aufbau eines Virtual Private Networks (VPN) wird eine schon bestehende RAS-Verbindung zwischen dem VPN-Client und dem VPN-Server verlangt, da der Tunnel zwischen den beiden Geräten zusätzlich zu der bestehenden Verbindung erstellt wird.

2.2 Verschlüsselungsverfahren

Kryptographie schützt Benutzer, indem es Funktionalitäten für die Verschlüsselung von Daten und für die Verschlüsselung der Identität anderer Benutzer zur Verfügung stellt. Durch diese Technologie ist der Empfänger einer Nachricht in der Lage, den Absender zu identifizieren, und der Absender kann den Inhalt einer Nachricht vor unberechtigtem Zugriff schützen.

In diesem Abschnitt werden die unterschiedlichen kryptographischen Konzepte von Symmetrischer und Asymmetrischer Verschlüsselung, Hash-Algorithmus, digitaler Unterschrift und Schlüsselaustausch vorgestellt.

Die drei Verschlüsselungsverfahren, die Einweg-Hash-Funktion, der Symmetrische und der Asymmetrische Verschlüsselungsalgorithmus, besitzen unterschiedliche Ansätze.

Bei der Symmetrischen Verschlüsselung wird bei der Ver- und Entschlüsselung derselbe Schlüssel verwendet. Diese Art der Verschlüsselung ist schnell und damit auch geeignet, um ganze Festplatten oder wichtige Dateien auf dem Rechner durch Verschlüsselung zu schützen.

Das bekannteste Symmetrische Verschlüsselungsverfahren ist der Data Encryption Standard (DES)⁵, der schon 1977 als offizieller Standard festgelegt wurde und mit 56-Bit verschlüsselt. Der DES-Code wird in unterschiedlichen Varianten verwendet, wie z.B. als Triple-DES-Code (3DES). 3DES verwendet nacheinander drei 56-Bit- Schlüssel und wurde für Hochsicherheitsumgebungen entwickelt. Die Regierung der Vereinigten Staaten von Amerika lockerte erst zu Beginn des Jahres 2000 das strikte Exportverbot für Software, die diesen Verschlüsselungscode einsetzt.

Ein weiterer bekannter Verschlüsselungscode ist der International Data Encryption Algorithm (IDEA), der doppelt so schnell ver- und entschlüsselt wie der DES- Algorithmus. Es wird dabei ein 128-Bit-Schlüssel verwendet.

Bei der Asymmetrischen Verschlüsselung wird ein Schlüsselpaar eingesetzt, wobei die Schlüssel verschieden sind. Dabei wird ein Schlüssel öffentlich ausgetauscht (Public Key) und der andere sicher aufbewahrt (Private oder Secret Key). Dieses Verfahren wird auch als Public-Key-Verfahren bezeichnet und wird immer dann

verwendet, wenn verschlüsselte Daten ausgetauscht werden sollen und dabei die Gefahr besteht, dass die Daten abgefangen werden können. Beispiele für diese Verschlüsselung sind der RSA⁶ -Algorithmus und der DSA (Digital Signature Algorithm)-Algorithmus. Der DSA kann jedoch nur für digitale Unterschriften, nicht jedoch zum Verschlüsseln von Daten verwendet werden. Auch der Diffie-Hellman- Algorithmus, der nur zum Schlüsselaustausch verwendet wird, gehört zur Gruppe der Asymmetrischen Algorithmen. Wie der DSA-Algorithmus erreicht auch der Diffie-

Hellman-Algorithmus seine Sicherheit durch komplizierte Berechnungen von einzelnen Logarithmen in einem begrenzten Feld.

Die Einweg-Hash-Funktion unterscheidet sich etwas von der schlüsselbasierenden Kryptographie. Der Hash-Wert ist das Ergebnis einer Umwandlung von Daten unbegrenzter Länge in eine nicht umkehrbare Zahl fester Länge bei Anwendung eines Hash-Algorithmus, einer nicht umkehrbaren mathematischen Funktion. Die Länge des resultierenden Hash-Werts ist groß genug, dass es unwahrscheinlich ist, eine Übereinstimmung zwischen zwei unterschiedlichen Daten mit demselben Hash- Wert zu finden. Der Sender generiert einen Hash-Wert von einem Teil der Nachricht, verschlüsselt diesen und verschickt ihn zusammen mit der Nachricht. Der Empfänger entschlüsselt die Nachricht und den Hash-Wert, produziert anschließend einen eigenen Hash-Wert mit der empfangenen Nachricht und vergleicht beide Hash- Werte. Falls beide Hash-Werte identisch sind, besteht eine hohe Wahrscheinlichkeit, dass die Nachricht vollständig übertragen wurde.

Die am häufigsten verwendeten Hash-Funktionen sind MD5 (Message Digest 5) und SHA-1 (Secure Hash Algorithm-1).

MD5 wurde von Ron Rivest konzipiert, einem der Entwickler des RSA-Algorithmus. Die Verwendung von MD5, das einen 128-Bit Hash-Wert produziert, ist in der Praxis rückläufig.

Der SHA-1 wurde ebenfalls, wie der DSA-Algorithmus, von der NSA⁷ entwickelt und

wird gleichermaßen verwendet, um digitale Unterschriften zu erzeugen. Das Resultat von SHA-1 ist ein 160-Bit Hash-Wert.

Auf diesen drei Verschlüsselungsverfahren, Hash-Funktion, Symmetrische und Asymmetrische Algorithmen, baut die gesamte Verschlüsselung auf. Weitere Verfahren sind nur Kombinationen aus diesen dreien, um die Vorteile der einzelnen Verschlüsselungsverfahren zu kombinieren. Ein Beispiel dafür ist die Kombination des Asymmetrischen mit dem Symmetrischen Verschlüsselungsverfahren. Dazu wird der symmetrische Schlüssel vorab mit dem Public Key verschlüsselt und der daraus entstandene Schlüssel ausgetauscht. Danach wird die zu verschlüsselnde Nachricht mit dem symmetrischen Schlüssel verschlüsselt und übertragen. Der Empfänger muss zuerst mit seinem Private Key den Schlüssel auspacken und kann danach mit dem symmetrischen Schlüssel die Nachricht entpacken. Dieses Verfahren wird unter anderem bei PGP® (Pretty Good Privacy) ⁸ verwendet.

2.3 Public Key Infrastructure

PKI (Public Key Infrastructure) werden benötigt, um digitale Zertifikate zu erstellen, zu verteilen und zu verwalten. Es handelt sich dabei um kein physikalisches Objekt oder um einen Softwareprozess, sondern um eine Gruppe von nützlichen Diensten, die durch eine Zusammenstellung von untereinander verbundenen Komponenten unterstützt wird, deren Aufgabe darin besteht, die auf einem Public Key basierenden Sicherheitsdienste Programmen und Benutzern zur Verfügung zu stellen.

Ein Zertifikat ist eine digital unterschriebene Aussage, die aus einem öffentlichen Schlüssel (Public Key) und einem Objekt besteht. Dieses Objekt kann verschiedene Namen besitzen, z.B. kann es sich dabei um Verzeichnisnamen, E-Mail-Namen oder um Domain Name Service (DNS)-Namen handeln. Bei der Unterzeichnung des Zertifikates durch die Zertifizierungsstelle (Certificate Authority, CA) wird der private Schlüssel (Private Key) in Verbindung mit dem im Zertifikat verwendeten öffentlichen Schlüssel überprüft, ob der verwendete Objektname identisch ist mit dem verwendeten Objektnamen des Zertifikates.

Eine CA vergibt an ihr bekannte Benutzer ein Zertifikat, das den öffentlichen Schlüssel enthält. Dieses Zertifikat muss veröffentlicht werden, da der darin enthaltene öffentliche Schlüssel verwendet wird, um Daten zu verschlüsseln, die nur durch den privaten Schlüssel, der sich im Besitz des Empfängers befindet, entschlüsselt und damit wieder sichtbar gemacht werden. Der Benutzer hält diesen

privaten Schlüssel geheim, so dass niemand Zugriff auf diesen hat, da der private Schlüssel auch dazu verwendet werden kann, digitale Unterschriften durch den öffentlichen Schlüssel zu bestätigen.

Digitale Zertifikate sind die Grundlage für eine Vielzahl von Sicherheitsfunktionen im Internet. Dazu gehören S/Mime (Secure Multiporpose Mail Extansions) für sichere E- Mails, die Anmeldung über Smartcards, SSL (Secure Sockets Layer) und die Client- Authentifizierung bei Webservern über SSL/3. Bei Windows 2000 kommen noch weitere Funktionen wie die Signatur von Treibern und anderem Code, IPSec (IP Security; Internetprotokollsicherheit) und das EFS (Encrypting File System) dazu.

Bevor sich ein Unternehmen eine PKI implementiert, sollten mehrere Aspekte bedacht werden. Zum einen ist die Art des Algorithmus zu betrachten. Als der verbreitetste Algorithmus ist sicherlich der RSA zu nennen. Andere unterstützen nur einen Teil der benötigten Funktionen wie der Digital Signature Algorithm (DSA), der nur für digitale Unterschriften brauchbar ist, oder der Diffie-Hellman-Algorithmus, der nur beim geheimen Schlüsselaustausch eingesetzt wird. Jedoch sind einige

Funktionen von Windows 2000, wie z.B. EFS⁹ und IPSec¹⁰, davon nicht betroffen, da

sie ihre eigenen Kerberos-Zertifikate bereitstellen, ohne eine besondere Vorbereitung vonseiten des Netzwerkadministrators zu verlangen.

Weiterhin sollten u.a. die Schlüsselverteilung, der Schlüsselaustausch und die Hierarchie der PKI bedacht werden.

2.3.1 Aufbau der Hierarchie

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: CA Hierarchie

Eine typische Hierarchie, wie in Abbildung 2-2: CA Hierarchie gezeigt, besteht aus einer drei-stufigen Architektur. Dabei wird vorausgesetzt, dass die erste Stufe eine Root CA ist. Die Gültigkeit und die Verschlüsselungsgröße der Root-Zertifikate werden schon während der Installation des »Certificate Services« festgelegt. Um Sicherheitsrisiken minimal zu halten, sollte diese nicht im Netzwerk sein und auf 4096-Bit- Schlüssel festgelegt werden. Gewöhnlich wählt man für diese Root-Zertifikate, obwohl sie mit dieser Schlüssellänge 15-20 Jahre gegen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-3: Brute-Force-Zeiten

»Brute-Force«-Angriffe ¹¹ standhalten könnten, einen Gültigkeitszeitraum von 5 Jahren. Die Abbildung 2-3 soll einen kurzen Überblick über die ungefähren Zeiten geben, wie lange ein Brute-Force-Angriff bei unterschiedlichen Schlüssellängen und unterschiedlicher Hardware benötigt.¹²

Für normale Zertifikate, die gewöhnlich eine viel kürzere Gültigkeit haben als das Root-Zertifikat, reichen 1024-Bit-Schlüssel aus.

Als zweite Stufe der Hierarchie legt man die Intermediate Certificate Authorities an. Diese werden untergeordnete oder dazwischenliegende Zertifizierungsstellen genannt. Die Gültigkeitsdauer der einzelnen Zertifikate beträgt im Regelfall zwei Jahre. Hier werden die Zertifizierungs-Policies von u.a. Domain Controllern, der Internetprotokollsicherheit und dem Enrollment Agent festgelegt. Auch diese sollten nicht im Netz sein. Intermediate CAs können durch andere Intermediate CAs zertifiziert werden, um dadurch eine größere Hierarchie zu generieren.

Bei der dritten Stufe der Hierarchie handelt es sich um die Certificate Authorities, die Zertifikate verwalten, herausgeben und für ungültig erklären können.

Bei der Laufzeit der einzelnen Zertifikate sollte man stets die Überlegung anstellen, dass das Risiko auf einen Angriff von außerhalb immer von dem Sicherheitsstandard des Netzwerkes abhängt, d.h. wie sicher die einzelnen Netzwerkressourcen durch die CA geschützt werden bzw. wie hoch die Kosten für den Start eines Angriffs sind. Dieses soll auch die

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-4: Kosten und Zeit

Abbildung 2-4 ¹³ aufzeigen. Im Allgemeinen bedeutet

das, wenn man einem Rechner oder Benutzer weniger vertraut, vergibt man eine kürzere Schlüsselgültigkeitsdauer, um Gefahren vorzubeugen.

Größere Sicherheit bedeutet gewöhnlich auch höhere Kosten, sowohl durch die Erhöhung der Hardwareanforderung als auch durch längere CPU-Zeiten, die durch die Entschlüsselung entstehen.

2.4 Kerberos

Das Wort Kerberos hat seinen Ursprung in der griechischen Mythologie, in der es als Name für den 3-köpfigen Hund dient, der die Göttin Hades bewacht. Dieser Name wurde gewählt, da das Kerberos-System im Zusammenhang mit dem Projekt Athena im MIT (Massachusetts Institute of Technology) entwickelt worden ist.

Der Ansatz von Kerberos besteht darin, den Datenaustausch zwischen einem Client und einem Service mit einem zufällig gewählten Schlüssel zu verschlüsseln. Der Schlüssel darf nur dem Client und dem Service bekannt sein, man spricht in diesem Fall von einem »shared secret«, und er darf nur eine kurze, zeitlich begrenzte Gültigkeit besitzen. Ausgetauschte Nachrichten zwischen Client und Service sind mit diesem Session-Schlüssel chiffriert.

Da nur der Client und der Service den Session-Schlüssel besitzen, kann kein Angreifer in den Datenaustausch der beiden Parteien eingreifen. Es ist somit auch keinem Angreifer möglich, sich mit einer fremden Identität auszustatten.

Das Kerberos-System besteht im wesentlichen aus einem oder zwei Kerberos- Servern, entweder Authentication Server (AS) oder Kerberos Distribution Center (KDC) und Ticket Granting Server (TGS), die in das offene Netzwerk integriert sind, und von denen ein Client und ein Service den benötigten Session-Schlüssel zur Chiffrierung bzw. Dechiffrierung von ausgetauschten Nachrichten bekommen.

Wichtig für die Sicherheit der Kommunikation zwischen Client und Service ist dabei das Verfahren, mit dem den beiden Parteien dieser Schlüssel über das offene Netzwerk übermittelt wird. Das Kerberos-System bietet zu diesem Zweck zwei verschiedene Protokolle an, die AS-Protokoll und TGS-Protokoll genannt werden, wobei es sich bei dem TGS-Protokoll um eine Erweiterung des AS-Protokolls handelt.

Beim Einsatz von Kerberos müssen Passwörter nicht über das Netzwerk ausgetauscht werden, da dafür »Tickets« eingesetzt werden, die von einem zentralen KDC versendet werden, und die den Zugriff auf Clients und Services freigeben. Auch diese »Tickets«werden verschlüsselt übertragen, so dass auch bei abgefangenen Paketen diese nicht missbraucht werden können. Sie haben nur eine begrenzte Gültigkeit (in der Regel 8 Stunden). Das KDC verwaltet die privaten Schlüssel von allen Clients und Services.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-5: Kerberos-Authentifikations-Protokoll¹⁴

Erläuterung der Abbildung 2-5: Kerberos-Authentifikations-Protokoll :

A. Der Client sendet im Klartext seine eigene Identität, die des Zielservers und eine für dieses eine Mal gültige Nachricht an Kerberos.
B. Dieser generiert einen Session Key. Danach erstellt er ein Ticket, indem die Client-Identität, der Session Key und dessen Start- und Ablaufzeit enthalten ist. Dieses Ticket wird mit dem privaten Schlüssel des Servers verschlüsselt, so dass es gegen Lesen bzw. Veränderung durch Dritte geschützt ist. Kerberos verschlüsselt auch den Session Key, die Serveridentität und die empfangene Nachricht mit dem privaten Schlüssel des Client. Danach sendet er beide Pakete an den Client zurück. Der Client entpackt den Session Key und die Nachricht und überprüft diese auf Originalität. Das verschlüsselte Ticket und der Session Key werden zur späteren Verwendung gespeichert.
C. Der Client überträgt an den TGS einen Authentikator, indem die exakte Zeit gespeichert ist und der zusätzlich durch den Session Key verschlüsselt ist. Die Serveridentität, eine weitere einmal gültige Nachricht, wobei beides im Klartext übertragen wird, und das verschlüsselte Ticket, das er nicht entschlüsseln konnte, werden auch gesendet.
D. Dadurch, dass der Session Key niemals im Klartext übertragen wird, kann der TGS überprüfen, ob der Client den Session Key kennt und die Nachricht auch von diesem kommt, indem er das verschlüsselte Ticket auspackt und mit dem darin enthaltenen Session Key den Authentikator entschlüsselt. Durch Vergleich der aktuellen mit der darin enthaltenen Uhrzeit stellt der TGS noch zusätzlich fest, dass die Leitung nicht belauscht wird und ihm, durch wiederholtes Senden eines alten Paketes, der Session Key entlockt werden soll. Der TGS sendet daraufhin das Ticket für den Server, verschlüsselt mit dessen privatem Schlüssel, den durch den privaten Schlüssel des Client verschlüsselten Client-Server-Session-Key und die empfangene Nachricht, die durch den Session Key verschlüsselt wurde, zurück an den Client.
E. Um sich beim Server zu authentifizieren, überträgt der Client einen neuen Authentikator mit der aktuellen Zeit, verschlüsselt mit dem neuen Session Key und das Ticket. Nach der Entschlüsselung kennt der Server die Identität des Client und kann dadurch Zugriffe steuern, Berechtigungen überprüfen und mit Hilfe des nun beiden bekannten Session Keys verschlüsselte Nachrichten übertragen.

Nähere Informationen über die Funktionsweise von Kerberos können im RFC- Dokument¹⁵ nachgelesen werden.

Kerberos wird seit geraumer Zeit im MIT eingesetzt und hat sich dort als sehr zuverlässig erwiesen. Bis zum jetzigen Zeitpunkt konnte kein »Einbruch« nachgewiesen werden, obwohl einige Angriffspunkte bekannt sind: Während der Authentifizierung wird der private Schlüssel auf dem lokalen Rechner gespeichert. Dieser Schlüssel hat im Gegensatz zu dem Authentikator eine sehr lange Gültigkeit. Aber auch die Gültigkeit des Authentikators bietet einen Angriffspunkt: Falls der Server und der Client nicht exakt zeitsynchron laufen sollten und dadurch die Gültigkeit des Authentikators recht lange eingestellt werden müsste, so wäre durch ein von einem Angreifer abgefangenes Paket, das er dann erneut an den Server sendet, der Zugang zum Server möglich.

2.5 Virtual Private Network

Wenn man heute von verschlüsselter und authentifizierter Kommunikation über öffentliche Netze spricht, so wird damit automatisch Virtual Private Networks (VPN) assoziiert. VPNs sind auf jeden Fall kostengünstiger und technischer einfacher zu handhaben als Standleitungen.

Die Position des VPN-Endpunktes gegenüber der Firewall im Netzwerk bedarf einer genaueren Beobachtung. Wenn der VPN vor der Firewall terminiert wird, so sind die externen Dienste der Firewall nur autorisierten VPN-Benutzern zugänglich. Aus Sicherheitsgründen muss in diesem Fall eine doppelte Authentifizierung des VPN- Client stattfinden.

Befindet sich der VPN-Endpunkt hinter der Firewall, bleiben alle ursprünglichen Dienste erhalten. Bei der Firewallkonfiguration muss jedoch darauf geachtet werden, dass die vom VPN-Endpunkt benötigten Ports offen bleiben. Das würde natürlich ein Sicherheitsrisiko darstellen, da alle verschlüsselten Pakete in das private Netzwerk durchgelassen werden müssten, da die Firewall diese nicht überprüfen kann.

Sollte sich der VPN-Endpunkt logisch gesehen neben der Firewall befinden, bieten beide ihre Dienste vollkommen unabhängig voneinander an. Aus dieser Konfiguration ergeben sich jedoch zwei Zugangswege zum Firmennetzwerk, wodurch sich die Gefahr von Sicherheitsverletzungen erhöht. Normalerweise stellt keiner dieser Dienste eine Umgehung des anderen zur Verfügung, aber mit zwei Verbindungswegen werden die Risiken verdoppelt.

Die unterschiedlichen VPN-Implementierungen können auf verschiedenen Ebenen in die Kommunikation eingreifen. Dieses wird am deutlichsten, wenn man das OSI- Schichtenmodell als Vorlage nimmt¹⁶:

- Anwendungen:

http (Hypertext Transfer Protocol), ftp (File Transfer Protocol), Telnet, SMTP (Simple Mail Transfer Protocol)

- Netzwerkprotokolle:

TCP (Transmission Control Protocol), UDP (User Datagram Protocol)

- Netzwerkverbindungen:

IP (Internet Protocol), ICMP (Internet Control Message Protocol), IGMP (Internet Group Management Protocol)

- Link:

MAC (Media Access Control, Netzwerkadapter), PPP (Point-to-Point Protocol)

Auf jede dieser Schichten des IP-Modells kann ein VPN-Produkt eingreifen, um eine vertrauliche Kommunikation zu gewährleisten.

2.5.1 Funktionsweise eines Tunnels

Ein VPN auf Basis des Netzwerkprotokolls hat bei TCP/IP (um dieses Protokoll dreht es sich vor allem, zumal das Internet darauf basiert) zwei Möglichkeiten: die Verschlüsselung von TCP (bzw. UDP), man spricht dann vom Transportmodus, und den Eingriff direkt auf der IP-Ebene, das heißt dann Komplettverschlüsselung. Dieser Vorgang wird Tunnelmodus genannt. Der Ansatz, VPNs direkt auf der IP-Ebene einzusetzen, hat sich durchgesetzt, da bei der ersten Variante nur TCP- und UDP- Verbindungen geschützt werden, aber der Datenverkehr, z.B. über ICMP, weiterhin unverschlüsselt abgewickelt wird und damit einen Einstiegspunkt für Angreifer darstellt.

2.5.1.1 Transport Modus

Der Transportmodus wird normalerweise zwischen den Endpunkten einer Verbindung eingesetzt. Dies bedeutet eine sichere Kommunikation über den gesamten Verbindungspfad hinweg.

Die Protokolle authentifizieren das gesamte Paket bis auf veränderliche Einträge des IP-Kopfes. Die Verschlüsselungsmechanismen sind nur relevant für die höheren Protokollebenen und den Datenbereich des Paketes. Der ursprüngliche IP-Header bleibt erhalten.

Der Transprot Modus spart im Vergleich zum Tunnel Modus Rechenzeit ein und ist für Verbindungen innerhalb eines sicheren Netzwerkes vorgesehen.

2.5.1.2 Tunnel Modus

Der Tunnel Modus wird eingesetzt, falls zumindest ein Rechner keinen Endpunkt in der Verbindung darstellt. (Sichere Kommunikation zwischen Firewalls, oder entferntes Einwählen in ein LAN, um eine sichere Verbindung bis zum Gateway zu erhalten).

Der Tunnel Modus bietet eine höhere Sicherheit, da das gesamte IP-Paket kodiert wird. Das Paket erhält einen neuen IP-Header, gefolgt von einem AH- bzw. eine ESP-Header, die sowohl die Daten als auch die ursprüngliche Protokollköpfe sichern.

2.5.2 IPSec (IP Security)

Ziel von IPSec ist eine sichere Internet-Kommunikation auf der Vermittlungsschicht. IPSec soll Schutz vor Verfälschung, unberechtigten Einblicken und Attacken durch externe Angreifer bei der TCP/IP-Kommunikation bieten. Mit IPSec können verschiedene Standorte ihren Datenverkehr sichern, wenn die Kommunikation über das öffentliche Internet stattfindet.

Das vorhandene Datenpaket wird komplett verschlüsselt und in ein anderes, gültiges IP-Paket eingepackt. Diese Vorgehensweise nennt man »Tunnelling«. Die IPSec- Spezifikationen machen diesen Vorgang sehr deutlich. Alle IPSec-kompatiblen Implementierungen haben zwei zusätzliche Header für IP-Pakete: Das ist zum einen der Authentication Header, der eine kryptographische Prüfsumme zu Authentifizierungszwecken definiert, und zum anderen den Encapsulating Security Payload Header (ESP), der sich dagegen direkt mit der Verschlüsselung der Nutzdaten befasst.

[...]

---

¹ z.B.: AOL, T-Online oder Internet-by-Call-Anbieter (z.B. Mobilcom)

² z.B. Sniffer-Programme, die IP-Pakete nach speziellen Schlüsselwörtern scannen

³ Fernnetz, das große Entfernungen abdeckt und über Vermittlungseinrichtungen zugänglich ist

⁴ [4], Seite 419

⁵ Funktionsweise des DES unter ftp://ripem.msu.edu/pub/crypt/docs/des-algorithm-details.txt

⁶ RSA steht für Rivest, Shamir und Adleman, die diesen Algorithmus entwickelt haben

⁷ National Security Agency

⁸ PGP ist eine kommerzielle Software, die u.a. zur Verschlüsselung von E-Mails eingesetzt wird

⁹ Encrypted File System, Kapitel 9.2

¹⁰ Internet Protocol Security, Kapitel 2.5.2

¹¹ eine Methode, die Verschlüsselung zu brechen, indem jeder mögliche Schlüssel versucht wird

¹² Grafik aus http://www.sepa.tudelft.nl/modulemateriaal/Voltijd/TB141/Comms/BDCCH17_99/sld011.htm

¹³ Grafik aus http://www.sepa.tudelft.nl/modulemateriaal/Voltijd/TB141/Comms/BDCCH17_99/sld012.htm

¹⁴ [10] Seite 197, Figur 9

¹⁵ http://www.ietf.org RFC 1510

¹⁶ [13], Seite 321