Der Einsatz von Virtual private networks (VPN) in einem Small Office/Home Office (SOHO) Umfeld

Inhaltsverzeichnis

Abkürzungsverzeichnis

1 Vorwort

2 IP Security (IPSec)
2.1 Einführung .
2.1.1 Internet
2.1.2 ISO/OSI - Referenzmodell
2.1.3 TCP/IP
2.2 Protokolle und Modi
2.2.1 Transportmode
2.2.2 Tunnelmode
2.2.3 Encapsulating Security Payload (ESP)
2.2.4 Authentication Header (AH)
2.2.5 Security Association (SA)
2.2.6 Security Policy Database (SPD)
2.2.7 Security Association Database (SAD)
2.3 Internet Key Exchange (IKE)
2.3.1 Domain of Interpretation (DOI)
2.3.2 Internet Security Association and Key Management Protocol (ISAKMP)

3 Sicherheitsaspekte
3.1 Bundesamt für Sicherheit in der Informationsverarbeitung (BSI) Empfeh- lungen
3.2 Sicherheitspolitik
3.2.1 Sicherheitspolitik für VPN
3.2.2 Firewall .
3.2.3 IP Adressbereiche RFC 1918
3.3 Internet Provider
3.3.1 Mehrere Beteiligte Provider
3.3.2 Ein Beteiligter Provider
3.4 Aufbau der Einrichtungen
3.5 Risikoabschätzung

4 Ausgangssituation
4.1 Struktur
4.2 Anforderungen
4.3 Kosten
4.4 Erwartungen

5 Produktübersicht
5.1 Kriterien
5.2 Produkte
5.2.1 Software Lösungen
5.2.2 Hardware Lösungen
5.3 Auswertung

6 Kosten
6.1 Einrichtungs- und Anschaffungskosten .
6.1.1 Allgemeine Kosten
6.1.2 DDV-Anbindungen
6.1.3 VPN-Anbindungen
6.2 Laufende Kosten (Betrieb)
6.2.1 Allgemeine laufende Kosten
6.2.2 DDV-Anbindungen
6.2.3 VPN-Anbindungen
6.3 Vergleich der Kosten

7 Zusammenfassung

Quellenverzeichnis

Glossar

Index

A Anhang
A.1 Auflistung der verwendeten Header Kodierungen (RFC 2408)
A.2 Payload Formate (RFC 2408)
A.2.1 Security Association Payload Format
A.2.2 Proposal Payload Format
A.2.3 Transform Payload Format
A.2.4 Key Exchange Payload Format
A.2.5 Identification Payload Format
A.2.6 Certificate Payload Format
A.2.7 Certificate Request Payload Format
A.2.8 Hash Payload Format
A.2.9 Signature Payload Format
A.2.10 Nonce Payload Format
A.2.11 Notification Payload Format
A.2.12 Delete Payload Format
A.2.13 Vendor ID Payload Format
A.3 Beispielkonfiguration
A.3.1 Netscreen 5XP
A.3.2 FortiGate 50
A.3.3 CISCO IOS

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Widmung

Als erstes möchte ich meiner lieben Frau Petra und meiner Tochter Annie, die in den letzten Jahren unter meinem Studium "leiden" mussten, wenn ihr Mann (Vater) mal wieder für sein Studium "nebenbei" die Zeit opferte, anstatt mit ihnen die Freizeit zu genießen.

Euch möchte ich besonders für eure Geduld, Unterstützung und so manches liebe Wort danken, ohne all dieses wäre es vielleicht gar nicht zu diesem Ende gebracht worden.

Außerdem möchte ich mich bei Herrn Professor Dr. Thomas Wilmes für die freundliche und engagierte Unterstützung bei der Ausarbeitung dieser Diplomarbeit und der vorhergehenden Projektarbeit bedanken.

1 Vorwort

Unternehmungen, die verteilt über verschiedene Standorte evtl. sogar bundesweit oder international arbeiten, müssen mit immensen laufenden Kosten für die benötigten Kom- munikationsverbindungen rechnen. Alternativ können durch komplizierte Replikations- verfahren die Daten zu günstigen Zeiten abgeglichen werden, wodurch diese den An- wendungssystemen nicht zeitnah zur Verfügung stehen. Heutige Unternehmen erreichen ihren Erfolg gegenüber dem Mitbewerb zu einem nicht unbeachtlichen Teil dadurch, dass sie Informationen schneller verfügbar haben als der Mitbewerb. Die erwarteten Preis- senkungen durch die Öffnung des Telekommunikationsmarkt haben für die Unterneh- men keinen Durchbruch gebracht. Neue preisgünstige Kommunikationslösungen für Un- ternehmen bergen daher ein beachtliches monatliches Einsparungspotential. So werden durch sog. Internet Service Provider (ISP), Standleitungen ins Internet mit verschiedenen Anschlußtechniken und Bitraten zu günstigen Preisen angeboten. Für die technische Rea- lisierung sollen sog. Virtual Private Networks (VPN) verwendet werden. Diese Lösungen senden Daten in einen sog. "IP-Tunnel"^[1], dieser "Tunnel", der von einem Standort zur Zentrale geführt wird, transportiert die Daten verschlüsselt und damit entsprechend ver- traulich. Für den Aufbau und Betrieb dieses "Tunnels" ist spez. Hard- oder Software notwendig.

Ein Unternehmen das Internetverbindungen als kostengünstige Lösung benutzen mö- chte, muss die daraus entstehenden Gefährdungen beachten und in die Kalkulation mit einbeziehen. Die bisher von einem Anwender bei einem Kommunikationsanbieter ge- bräuchlichen Merkmale bzgl. der Qualität, Sicherheit und der Verfügbarkeit sind durch einen ISP meist nicht zu garantieren, da ein ISP nur eingeschränkte Möglichkeiten hat, außerhalb seines eigenen Internet-Teils auf die oben genannten Merkmale Einfluss zu nehmen. Schon deshalb muss ein Unternehmen, das VPN's betreiben möchte, den sog. Service Level Agreement (SLA)'s der ISP besondere Aufmerksamkeit widmen, und auch mögliche Ausfallszenarien in seinen Betrachtungen mit einfließen lassen.

Ob der Einsatz von VPN für Unternehmen aus dem Bereich SOHO sicher und güns- tig gestaltet werden kann, soll in dieser Diplomarbeit exemplarisch an einem Beispiel ermittelt werden. Als Beispiel für ein Kleinunternehmen, dient uns hier eine real exis- tierende Gesellschaft, die wir im weiteren mit Firma Electronic Data Interchange (EDI) 1Das Transportprotokol im Internet ist Transmission Control Protocol / Internet Protocol (TCP/IP) GmbH2 bezeichnen, dieses Unternehmen beschäftigt zur Zeit 18 Mitarbeiter verteilt an drei Standorten (Essen, Hamburg, Frankfurt). Die Mitarbeiter arbeiten stark teamorien- tiert. Daten werden ausschließlich elektronisch aufbereitet. Über sog. Microsoft - Ter- minalserver Clients arbeiten die Mitarbeiter auf einem zentralem Server in Essen. Die anfallenden Kommunikationsverbindungen wurden bisher mittels Datendirektverbindun- gen (DDV) der Deutsche Telekom AG (DTAG) realisiert.

In diesem Dokument soll nach einer kurzen Einführung in die Technik der TCP/IP Netz- werke eine Vertiefung in das Thema IP Security (IPSec) gegeben werden. Ein Exkurs zum Thema Sicherheit einer solchen Lösung soll Auskunft über evtl. entstehende Gefährdun- gen geben. Ausgehend von der realen Gesellschaft EDI mit einer Problemstellung soll über eine Marktanalyse untersucht werden, ob die sich ergebenden Nutzen, Risiken und Möglichkeiten für VPN Lösungen in Unternehmen aus dem SOHO-Bereich wirtschaftlich zu betreiben sind. ^[2] Da die Kenntnisse über die Strukturen und Sicherheitseinrichtungen des Netzwerkes einen potentiellen Angreifer helfen könnte, habe ich den Namen der realen Gesellschaft anonymisiert.

2 IP Security (IPSec)

VPN sollen dem Anwender eine sichere Kommunikation zwischen entfernten Computern über ein öffentliches Wide Area Network (WAN)^[1], wie z. B. das Internet bieten. So können zwei Local Area Network (LAN)'s , oder ein Benutzer mit einer Wählverbindung in ein LAN^[2] mittels VPN verbunden werden. Bei diesen Verbindungen werden die Datenpake- te ohne VPN meist im Klartext über verschiedene Koppelelemente wie Router, Switch und Sicherheitssysteme geführt. Dabei können die Daten von jeder beteiligten Instituti- on (z. B. Nachrichtendienste, ISP, Austauschknoten, etc.) entlang des Weges unbemerkt vom Absender mitgeschnitten, evtl. können die Daten sogar verfälscht werden. Ebenso können die Verkehrsinformationen Rückschlüsse auf den Benutzer wie z. B. Nutzerver- halten, Neigungen, etc. zulassen. Authentizität des Absenders, Integrität und Vertraulich- keit der Daten können so nicht sichergestellt werden. Diese Schwächen sind schon länger bekannt, aber dem Nutzer des Internet meist nicht bewusst. Sicherlich gibt es auch schon länger Lösungen dafür, doch waren diese in der Vergangenheit meist proprietär und teuer.

In den letzten Jahren wurde deshalb ein Standard entwickelt: "IPSec". Dieser Standard soll ermöglichen, dass vertrauliche Verbindungen im Internet (und anderen WAN) vom Anwender etabliert werden können, bei denen der Anwender sicher sein kann, dass seine Daten von keinem mitgelesen oder manipuliert werden können. Durch die Standardisie- rung des Protokolls wird die Koppelung unterschiedlicher Netze vereinfacht. In den Im- plementierungen ergeben sich jedoch im einzelnen noch Kompatibilitätsprobleme. Meist sind nicht alle Funktionen in allen Geräten umgesetzt, so dass herstellerübergreifend oft nur eingeschränkte Funktionalitäten zur Verfügung stehen.

2.1 Einführung

Zu Beginn der technischen Erläuterungen soll kurz eine gemeinsame Basis geschaffen werden. Deshalb betrachten wir in einem kurzen Abriss die Entstehung des Internet und die Beschaffenheit der unterschiedlichen Protokolle in der TCP/IP-Protokollsuite.

2.1.1 Internet

Als das Internet 1969 entwickelt wurde bestand es gerade mal aus vier Rechnern, 1971 waren es 15 Computer und das Netz hieß damals noch Advanced Research Project Agen- cy Network (ARPANET). Die Teilnehmer waren untereinander alle bekannt, so dass bei der Entwicklung der Protokolle für den Datenaustausch die Vertraulichkeit keine große Rolle gespielt hatte, wohl aber die Ausfallsicherheit^[3]. Mit der Entwicklung des Hyper- text Transfer Protocol (HTTP) explodierte die Anzahl der Teilnehmer am Internet. Die kommerziellen Möglichkeiten des Internet wurden erkannt. Zu diesem Zeitpunkt waren im Internet schon eine sehr große Anzahl von Rechnern verfügbar, bis heute sind es ca. 100 Millionen^[4], Tendenz weiter steigend. Das Internet besteht heute praktisch nur aus ei- nem Zusammenschluss von sehr vielen einzelnen Netzwerken, die alle als gemeinsames Protokoll TCP/IP benutzen. Der Datenaustausch zwischen den einzelnen Netzen wird über die sog. "Peering-Agreements" bestimmt . Dies sind Vereinbarungen mit denen die Betreiber der Netzwerke bestimmen, welche Datenmengen von den Partnern durch ihre Netzwerke geleitet werden dürfen. Im Gegenzug erwarten sie vom Partner, dass sie ih- re Datenkontingente durch die Partnernetzwerke leiten können. Während des Wachstums des Internet haben sich Konzentrationspunkte herausgebildet, an denen sich viele dieser Peering-Partner (in der Regel sog. ISP) treffen, diese Treffpunkte werden als "Peering- Points" bezeichnet. Bekannte Austauschknoten in den USA sind Metropolitan Area Ex- change (MAE)-EAST (Washington D.C), MAE-WEST (San Jose CA) und in Deutschland z. B. Deutscher Commercial Internet Exchange (DE-CIX) (Frankfurt am Main).

Damit ein Firmennetzwerk oder ein Einzelcomputer am Internet teilnehmen kann, muss man einen ISP auswählen. Mit diesem schließt man einen Vertrag über eine be- stimmte Laufzeit, Bandbreite und/oder Datenvolumen, oder eine sog. Flat-Rate. Alter- nativ kann man auch für Einzel-Computer oder kleinere Netzwerke einen Wählzugang (Call by Call) benutzen, der über die Telefongebührenabrechnung verrechnet wird. Doch bevor ein Computer als Teilnehmer in einem Netzwerk Datenpakete loswerden kann, muss in seinem Betriebssystem eine Unterstützung für das in diesem Netzwerk ver- wendete Protokoll vorhanden sein. Das Protokoll, das im Internet verwendet wird nennt

sich TCP/IP-Protokoll. Dieses Protokoll oder genauer diese Sammlung von Protokollen (TCP/IP-Protokollsuite) wird für jeglichen Verkehr im Internet herangezogen. Deshalb werden wir uns im Weiteren nur mit diesem Protokoll auseinandersetzen.

2.1.2 ISO/OSI - Referenzmodell

Bevor ein Computer in einem Netzwerk Daten austauschen kann, muss sein Betriebssys- tem über die Verkehrssprache in diesem Netzwerk informiert sein. Er muss diese sog. Pro- tokolle beherrschen. Sein Betriebssystem stellt einer Anwendung über Schnittstellen den gewünschten Netzwerkdienst zur Verfügung. Anfangs wurden solche Schnittstellentrei- ber in monolithischen Blöcken erstellt. Dies hatte z. B. bei der Änderung der Netzwerk- karte den Nachteil, dass der Treiber für das Betriebssystem neu erstellt werden musste.

Weitere Überlegungen führten dazu, dass man diese Netzwerkfunktionen in einen sog. Protokollstapel mit einzelnen Funktionsblöcken und einzelnen Schnittstellen (sog. Ser- vice Access Points (SAP)) aufteilte. Somit ist jedes einzelne Element im Protokollstapel austauschbar, ohne dass die darüber oder darunterliegenden Funktionsblöcke Veränderun- gen unterliegen (z. B. ist es einer Anwendung egal, ob sie auf einem Token-Ring Netz- werk oder einem Ethernet Netzwerk ihre Daten versendet). In Abb. 2.1 ist das sog. In- ternational Organization for Standardization (ISO)/Open Systems Interconnection (OSI)- Referenzmodell dargestellt. Jede einzelne Schicht hat eine spezielle Funktion, die wir im Anschluss kurz anreißen wollen, entnommen sind diese Angaben: Dr. Holger Taday Grundlagen der Kommunikationstechnik. Hagen: Land Nordrhein-Westfalen, Ministeri- um für Schule, Wissenschaft und Forschung, IfV NRW, 2000, Lerneinheit Informations- und Kommunikationstechniken, vgl. Seite 15.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: ISO/OSI-Referenzmodell

Physikalische Schicht Diese Schicht beschreibt die mechanischen, funktionellen und elektrischen Eigenschaften. Sie koppelt das Systems mit der physikalischen Verbindungs- leitung. Sie sorgt für die Bitübertragung zwischen zwei Systemen. Wesentliche Aufgabe ist auch der Auf- und Abbau von ungesicherten Systemverbindungen. Sicherungsschicht Aufgabe dieser Schicht ist es den ungesicherten Bitstrom aus der Bitübertragungsschicht in eine gesicherte Datenreihe zu verwandeln. Die ankommenden Daten in Datenblöcke sog. frames umwandeln und sequentiell übertragen. Den Nutzda- ten werden Verwaltungsdaten wie Sender- und Empfängeradresse hinzugefügt. Die Siche- rungsfunktion bezieht sich ausschließlich auf Bitübertragungsfehler. Weitere Leistungen sind Wahl des Netzzugriffverfahrens und Vermeidung von Überlastungen.

Vermittlungsschicht Aufbau einer Verbindung zwischen sendenden und empfangenden System. Sowie die Wegewahl, und der Wiederaufbau der Verbindung nach einer Störung. Transportschicht In dieser Schicht wird die logische Verbindung zwischen Sender und Empfänger gesteuert und überwacht. Überwachung, ob die Pakete auch beim Empfänger ankommen.

Kommunikationssteuerungsschicht In der Kommunikationssteuerungsschicht wer- den die notwendigen Mittel bereitgestellt, um die Kommunikation zu organisieren, zu synchronisieren und den Datenaustausch zu regeln. Die Kommunikationssteuerungs- schicht erstellt eine sitzungsbezogene Verbindung (session connection) zwischen den Teilnehmern. Bei mehreren gleichzeitigen Anfragen übernimmt sie das Multiplexing und steuert so die Zuordnung der einzelnen Verbindungen.

Darstellungsschicht Absprache der Kommunikationsteilnehmer über die Darstellung der auszutauschenden Daten. Festlegung der Transfersyntax einschließlich der Zeichen- codewandlung in den Zeichencode des Netzwerks, oder auch Datenkomprimierung und Verschlüsselung. Anwendungsschicht Identifizierung des Kommunikationspartners, Synchronisierung der Anwenderanfragen aus den Anwendungsprozessen.

2.1.3 TCP/IP

Nach dem in Abb. 2.1 auf Seite 5 aufgeführten ISO/OSI Referenzmodell wenden wir uns

nun dem TCP/IP-Stapel in Abb. 2.2 zu. Dieser differenziert nicht nach sieben sondern je

nach Darstellung in der Literatur zwischen vier oder fünf Schichten^[6].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Schichten im TCP/IP-Protokollstapel

Datenübertragungsschicht ...ist verantwortlich für die Übertragung des Paketes über

die physikalischen Medien, also für die Übertragung zwischen zwei Geräten, zwischen denen eine physikalische Verbindung besteht z. B. Ethernet, Token Ring.^[7] Netzwerkschicht ...leistet verbindungslose Dienste. Die Netzwerkschicht ist dafür ver- antwortlich, Pakete zu routen^[8]. Sie befördert die Pakete zu dem bestimmten Ziel und sorgt für die entsprechende Wegewahl. Die Entscheidungen zur Wegewahl müssen nicht von der Datenquelle alleine getroffen werden. Aktive Netzwerkkomponenten wie z. B. Rou- ter unterstützen die Datenquelle auf ihrem Weg zur Datensenke. Die Netzwerkschicht muss über eine Adressierung zur eindeutigen Identifizierung der Netzteilnehmer verfü- gen. Diese Adressierungsmechanismen sind abhängig vom gewählten Netzwerktyp, im Falle eines TCP/IP basierenden Netzwerk muss die Adressierung wie in Kap. 2.1.3.8 auf Seite 14 erläutert, aufgebaut sein.

Transportschicht ...in der TCP/IP-Protokollsuite verfügt über verschiedene Grund-

formen der Datenübertragung. Es sind verbindungsorientierte, verbindungslose oder zu-

verlässige und unzuverlässige Datenübertragungen möglich. Diese Eigenschaften der Transportschicht, können von der Anwendungsschicht in Kombination angefordert wer- den. Näheres zu den einzelnen Protokollarten über das Transmission Control Pro- tocol (TCP) in Kap. 2.1.3.4 auf Seite 11 bzw. User Datagram Protocol (UDP) in Kap. 2.1.3.5 auf Seite 12 und über Internet Control Message Protocol (ICMP) in Kap. 2.1.3.6 auf Seite 12. Jedoch machen einige Kombinationen keinen Sinn, wie z. B. die Kombination verbindungslos und zuverlässig^[9].

Anwendungsschicht ...hat die Aufgabe für die Anwendungen auf einem System die Daten über das Netzwerk zu versenden. Die Anwendungsschicht hat auch die Aufgabe, die Schnittstelle zur Transportschicht zu definieren. Diese Schnittstelle ist Betriebssystem abhängig. Die bekannteste ist das Socket-Interface auf UNIX Betriebsystemen^[10].Im Ver- gleich sieht die Aufteilung nach dem ISO/OSI Referenzmodell detaillierter aus als bei der Darstellung des TCP/IP-Protokollstapels. Dies hat in der Praxis aber keine Konse- quenz, da die Funktionalitäten der entfallenen Schichten in den dargestellten Schichten mit aufgenommen wurden.

2.1.3.1 TCP/IP-Protokollsuite

Wie im Kap. 2.1.3 auf der vorherigen Seite aufgeführt, bietet die Protokollsuite einige Basis-Funktionalitäten, die für eine Netzwerkdatenübertragung benötigt werden. Diese sollen im folgenden näher erläutert werden.

2.1.3.2 Internet Protocol (IP)

Das Internet Protocol (IP)-Protokoll bildet die Basis der Datenübertragung in der TCP/IP- Protokollsuite und ist definiert in Request for Comments (RFC) 79111. Es bietet einen ver- bindungslosen Datenübertragungsdienst in der Netzwerkschicht. Der Einfachheit halber wollen wir hier nur die Internet Protocol Version 4 (IPv4) betrachten, da die zusätzliche Betrachtung der Internet Protocol Version 6 (IPv6) den Umfang der Arbeit verdoppeln würde. Da aber zu diesem Zeitpunkt der Einsatz von IPv6 noch eher selten ist, sollte diese Einschränkung den Nutzen für den Leser nicht schmälern. Der Aufbau des IP-Datenpaket ist in Abb. 2.3 auf der nächsten Seite zu sehen. Da bei der Übertragung von Daten in den IP-Datagrammen Bitfolgen in Bytes und Wortgrößen vorkommen, musste eine Festle- gung über die Reihenfolge der Bytes getroffen werden. Die Darstellung in TCP/IP wurde

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: IP-Header

festgelegt als big-endian. Für die weitere Betrachtung sollen die Felder im IP-Header12 kurz erläutert werden, genaue Details können dem RFC 79113 entnommen werden. Das Feld Version ist bei IPv4 immer mit einer vier vorbelegt. Die Länge enthält bei einem IP-Datagramm die Headerlänge, ohne IP-Optionsfeld ist dies der Wert fünf (5 mal 4 Byte- Worte ergibt eine Länge von 20 Byte ). Die Gesamtlänge enthält die Gesamtlänge des IP-Paketes in Bytes. Identifikation: Mit diesem Feld wird bei der Fragmentierung ei- nes IP-Datagramms die Zuordnung der Datenpakte zum IP-Datagramm hergestellt. Die sog. Flags sind wichtig für die Fragmentierung, durch Setzen des ersten Bit wird signali- siert, dass nicht fragmentiert werden darf. Das zweite Bit dient der Erkennung des letzten fragmentierten Paket. Das dritte Bit ist unbenutzt. Wird ein Paket zerstückelt (fragmen- tiert), dient der Fragmentierungs-Offset dazu die Stückelungsstelle bekannt zugeben.

Der Verfallszähler TTL Time to live wird vom Sender auf einen Wert gesetzt, anschlie- ßend wird er von jedem Router auf dem Weg zum Ziel um einen verringert. Erreicht das Feld TTL den Wert Null, wird das Paket verworfen. Das Protokoll-Feld dient zur Kenn- zeichnung der einzelnen Protokolle aus der TCP/IP-Protokollsuite, und bestimmt damit was für ein Header dem IP-Header folgt. In der Header-Prüfsumme ist die berechnete Prüfsumme des Headers enthalten. Zur Identifikation des sendenden Host wird hier die Quell IP-Adresse transportiert. Damit das Datenpaket sein Ziel erreicht, muss die Ziel IP-Adresse selbstverständlich auch vorhanden sein. Das Feld IP-Optionen hat für diese Betrachtung keine Relevanz und kommt in der Praxis auch selten vor.

2.1.3.3 Fragmentierung

Der Versand von Daten über ein Netzwerk erfolgt nicht als kontinuierlicher Datenstrom, sondern in Datenpaketen einer bestimmten Größe. Diese Größe wird bestimmt durch die physikalische Netzwerkschicht. So hat z. B. Ethernet eine maximale Größe eines Daten- paket von 1526 Bytes. Dies schließt die in der Netzwerkschicht zusätzlich notwendige Adressen-Information mit ein. Daraus folgt, das einem IP-Paket maximal 1480 Bytes für Nutzdaten zur Verfügung stehen. Denn der IP-Kopf hat eine Größe von 20 Bytes und die notwendigen Ethernet-Informationen benötigen weitere 26 Bytes. In einem anderen physikalischen Netzwerk z. B. Token-Ring ist die maximale Größe eines Pakets 4096 By- tes. Sollen nun Pakete von einen Token-Ring in ein Ethernet übertragen werden, muss das Gerät^[14] die Daten vor dem Versand ins Ethernet in Stücke zerlegen. Dies nennt man Fragmentierung. Das empfangende Gerät muss diese Datenpakte anschließend wieder zu einem Paket zusammensetzen und zwar bevor es an die Netzwerkschicht weitergegeben werden kann. Dabei können die Daten zusätzlich noch in der falschen Reihenfolge ein- treffen, da das IP-Protokoll eine verbindungslose (stateless) Übertragung ist.

Maximum Transmission Unit (MTU) Um die Bandbreite der vorhandenen Netzwerke optimal nutzen zu können, hat in einem System jedes Netzwerkinterface eine Eigenschaft, die eine Fragmentierung verhindern soll, diese Eigenschaft nennt sich Maximum Trans- mission Unit (MTU). Sie wird bei der Erzeugung der Datenpakete zur Vermeidung der Fragmentierung herangezogen.

Path Maximum Transmission Unit (PMTU) Auf dem Weg von einem aussendenden Rechner zu einem empfangenden Rechner können die Pakete unterschiedliche Netzwer- ke passieren, diese Netzwerke können alle verschiedener Art sein, und unterschiedlich grosse Datenpakete voraussetzen. Dann würde es auf dem Weg zum Ziel trotzdem zu ei- ner Fragmentierung kommen. Deshalb gibt es eine Möglichkeit die sog. Path Maximum Transmission Unit (PMTU) festzustellen, dies geschieht mit der Unterstützung des Inter- net Control Message Protocol (ICMP)-Protokolls (siehe Kap. 2.1.3.6 auf Seite 12). Die so für den Weg festgestellte Größe muss nun vom Protokollstapel (hier dem IP-Protokoll, Netzwerkschicht) dafür sorgen, dass das ausgesendete Paket diese Größe (incl. aller not- wendigen Netzwerkinformationen) nicht überschreitet, so können die Datenpakete opti- mal bis ans Ziel gebracht werden. Leider wird oft durch falsch eingestellte Firewalls^[15]

die Ermittlung der PMTU verhindert. Dies führt manchmal sogar dazu das zwischen den Geräten dann keine Kommunikation stattfinden kann. Bezogen auf IPSec und die Behand- lung der PMTU ist RFC 2401 ^[16] zu lesen.

2.1.3.4 Transmission Control Protocol (TCP)

Ebenso wichtig in der TCP/IP-Protokollsuite ist das Transmission Control Protocol, es stellt verbindungsorientierte und gesicherte Verbindungen zur Verfügung. Definiert ist das Transmission Control Protocol (TCP)-Protokoll im RFC 793 ^[17]. TCP-Pakete werden im IP-Header im Protokoll-Feld mit dem Wert 6 gekennzeichnet. Die Verbindung ist fullduplexfähig, transparent (aus Sicht des Benutzer sieht die Verbindung wie ein Daten- strom aus), Sicherung der Daten mit Sequenznummern, Prüfsumme und Quittungen. Durch 16 Bit Breite sog. Portnummern, kann ein Rechner bis zu 65.535 verschiedene Verbindungen aufbauen^[18]. Die Verbindung wird mit einem sog. three-way-Handshake aufgebaut. Der Verbindungsaufbau und die verschiedenen Stati einer Verbindung des TCP-Protokolls sind für den interessierten Leser im RFC793 ^[19], oder anderer Literatur nachzulesen, für das weitere Verständnis, jedoch nicht ganz so wichtig. Deshalb wurde auf eine detaillierte Darstellung verzichtet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: TCP Protokollkopf

2.1.3.5 User Datagram Protocol (UDP)

Verbindungslose und ungesicherte Verbindungen werden mittels des User Datagram Pro- tocol (UDP)-Protokolls zur Verfügung gestellt. Der UDP-Protokollkopf besteht nur aus der Sender- und Empfänger Portnummer, der Datagrammlänge und einer Prüfsum- me. Dies macht das UDP-Protokoll zu einem Leichtgewicht, das ohne großen Protokoll- Overhead auskommt. Das UDP-Protokoll verzichtet bewusst auf eine Sicherungsschicht, um im LAN hohe Transferraten zu erreichen. Da die Paketverluste sich in LAN's ge- wöhnlich in Grenzen halten, ist dies auch weiter kein Problem. Einige Multimediadaten- dienste wie z. B. Realaudio benutzen das UDP-Protokoll. Die Sender- und Empfänger- Portnummern haben eine Länge von 16 Bit. Im IP-Header wird im Protokoll-Feld für UDP eine 17 eingetragen. Spezifiziert wird das UDP-Protokoll im RFC 768 ^[20]. Der Aufbau des UDP Protokollkopfs ist in Abb. 2.5 zusehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: UDP Protokollkopf

2.1.3.6 Internet Control Message Protocol (ICMP)

Das ICMP-Protokoll wird von allen aktiven Netzwerkkomponenten benutzt, um Funktio- nen in TCP/IP-Netzwerk zu steuern, Fehler zu melden und zu beheben. Dies wird dadurch erreicht, dass Geräte ICMP-Nachrichten aussenden, wie z. B. "Host not reachable", das von einen Router ausgesendet wird, falls er das adressierte Ziel nicht erreichen kann.

Aber auch einfachere Aufgaben werden mit diesem Protokoll realisiert, wie z. B. eine Überprüfung der Erreichbarkeit, die mit dem Befehl "Ping"^[21] durchgeführt werden kann. Dabei werden ICMP-Echo request Nachrichten ausgesandt. Das Zielsystem antwortet mit einer ICMP-Echo replay Nachricht. Das ICMP-Protokoll gehört zu den wichtigs- ten Grundfunktionen der TCP/IP-Protokollsuite. Der Aufbau eines ICMP-Protokollkopfs ist der Abb. 2.6 zu entnehmen. Es ist im RFC 792 ^[22] definiert und im IP-Header ist ein

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: ICMP Protokollkopf

Benachrichtigung der Geräte, die im RFC 1700 ^[23] spezifiziert sind. Eine weiter Spezifi- zierung der Nachricht kann mit dem Feld Kode erfolgen, das ebenfalls im RFC 1700 ^[24] erläutert wird.

2.1.3.7 Übersicht

Um nun einen Überblick zu bekommen, auf welchen der Schichten die einzelnen Pro-

tokolle angeordnet sind, ist die Zuordnung der Protokolle zu den einzelnen Schichten

des Protokollstapels in Abb. 2.7 dargestellt. Die Darstellung in Abb. 2.7 ist bzgl. des

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: Einordnung der Protokolle nach Ebenen

ICMP-Protokolls nicht ganz eindeutig. In der Literatur wird die Anordnung unterschied- lich dargestellt, mal ist es Bestandteil von IP, ein andermal nicht. Eine Darstellung, auf gleicher "Höhe" mit TCP und UDP trägt meines Erachtens am besten zum Verständnis bei.

2.1.3.8 IP-Adressen

Die Struktur von IP-Adressen ist relativ einfach aufgebaut, eine Adresse besteht aus einer 4 Byte langen Zahl, die der besseren Lesbarkeit wegen, in dezimaler Notation, byteweise dargestellt wird. Die Trennung der einzelnen Bytes erfolgt durch einen Punkt. Als Beispiel wird in Abb. 2.8 eine sog. IP-Adresse sowohl Dezimal, als auch Binär dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: IP-Adresse 192.168.1.1 binär und dezimal

Adressierungsarten In einem IP-Netzwerk werden die drei25 folgenden Adressie- rungsarten unterschieden: Unicast: Darunter versteht man das Adressieren eines spez. Rechners. Broadcast: Darunter versteht man das Adressieren einer Rechnergruppe, die einer gemeinsamen Netzwerkgruppe angehören. Die Broadcastadresse eines Netzwerkes ist die höchste Rechnerkennung in einem Netzwerk.

Multicast: Darunter versteht man das Adressieren einer Rechnergruppe die über ein spezielles Adressierungsschema, den sog. Multicastadressen angehören. Adressklassen Der Adressraum in einem TCP/IP-Netzwerk beginnt bei der niedrigsten IP-Adresse mit 0.0.0.0 und reicht bis 255.255.255.255. Der Adressraum ist eingeteilt in verschiedene Klassen, die durch die Anzahl der adressierbaren Rechner und Netzwerke unterschieden werden. Die verfügbaren Adressklassen sind in Tabelle 2.1 auf der nächs- ten Seite zu sehen.

Eine IP-Adresse beinhaltet jeweils einen Netzwerkteil und einen Teil der sog. Rechner- kennung. Um aus einer IP-Adresse den Netzwerkteil und den Teil der Rechnerkennung zu bestimmen, wird die IP-Adresse mit der sog. Subnetzmaske logisch "UND" verknüpft (Ein Beispiel ist in Abb. 2.9 auf der nächsten Seite zu sehen).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Adressklassen

Die Subnetzmaske wird angegeben in dezimaler Notation je Byte durch Punkt getrennt z. B. 255.255.255.0 für ein Klasse-C-Netzwerk, oder durch Zählung der "gesetzten" Bit z. B. /24 (Classless Inter-Domain Routing (CIDR) Notation, 24 gesetzte Bit, dies ent- spricht einem Klasse-C-Netzwerk). Anhand der IP-Adresse und der Subnetzmaske kann nun ein Rechner an Hand seiner Tabelle für die Wegewahl (routetable) entscheiden, ob dieses Ziel lokal erreicht werden kann. Stellt er fest, dass diese IP-Adresse nicht lokal erreichbar ist, muss der Rechner dieses Paket an ein sog. Default-Gateway weitergeben. Kann der Rechner, der als Default-Gateway angegeben ist, das Ziel nicht erreichen, wird eine ICMP Meldung erzeugt. Sind bei einer IP-Adresse alle Bits der Rechnerkennung 0, ist damit das Netzwerk gekennzeichnet. Sind bei einem Rechnerteil alle Bits gesetzt (255) handelt es sich um die sog. Broadcastadresse des Netzwerkes, beide vorgenannten Adressen sind aufgrund ihrer Funktion reserviert und können nicht für Rechner verwen- det werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: IP-Adresse, Subnetzmaske und Netzwerk

Besonderheiten Reserviert ist das Netzwerk 0 für die sog. Standard-Route, und das Netzwerk 127 für die sog. "Loopback-Adresse". Die Zuteilung von Klasse-A-Adressen ist heute so gut wie ausgeschlossen, da die Netzwerke größtenteils vergeben sind. Sie ma- chen auch nur für sehr grosse Organisationen Sinn. Klasse-B-Adressen, sind heute eben- falls fast nicht mehr zu bekommen. Die Zuteilung von Klasse-C-Netzwerken ist mit einem sorgfältig vorbereiteten Netzwerkplan möglich. Bei Klasse-D-Adressen handelt es sich um sog. Multicast-Adressen, sie werden benutzt um Gruppen von Rechnern gleichzeitig mit Daten zu versorgen. Die Daten werden vom Absender dabei nur einmal ausgesandt.

Klasse-E-Adressen sind sog. Anycast-Adressen, sie sind zur Zeit Forschungsgegenstand und werden hier nicht weiter behandelt. Klasse-F-Adressen sind für spätere Verwendung reserviert.

Adresszuteilung Rechneradressen und Netzwerke die von überall aus dem Internet er- reichbar sein sollen, werden von einer Zentralstelle vergeben. Für Europa liegt diese Aufgabe beim Reseaux IP Europeens (RIPE) in Amsterdam. Dort werden nach einem vom Antragsteller einzureichenden Netzwerkplan IP-Adressen vergeben. Die vorhande- nen IPv4-Adressbereiche sind so gut wie ausgeschöpft. Durch unwirtschaftliche Vergabe in den Anfangszeiten des Internet, sind heute noch große Bereiche von IP-Adressen blo- ckiert. Die Vergabe erfolgte auch nicht nach Kriterien zur Wegewahl, so dass nur ein Bruchteil des maximal möglichen Adressraum genutzt werden konnte. Zentrale Geräte im Internet die für Datenpakete eine Wegewahl durchführen müssen, benötigen deshalb enorm große Tabellen. Um dieses zu verringern wurde das sog. CIDR nach RFC 1817 ^[26] eingeführt. Dabei werden mehrere Netzwerke mit einer sog. "Super"-Netzwerkmaske zu- sammengefasst.

Klassenloses Adressieren Die Aufteilung von LAN in Subnetze wird benötigt, um un- nötigen Verkehr aus dem Netzwerk fernzuhalten, und um LAN's zu strukturieren. Dabei werden in einem Netzwerkplan die benötigte Anzahl Rechner und Netzwerke für jedes Segment festgehalten. Werden Subnetze nur an den Klassen ausgerichtet, entstehen Netzwerke, die sehr groß dimensioniert sind. Da aber die "offiziellen" Adressbereiche im Internet knapp sind, wur- den Wege gesucht, kleinere Subnetze zu definieren. Dazu werden bei der Bestimmung der Subnetzmaske die Bits nach Bedarf weiter nach rechts geschoben. Die Netzwerke die entstehen, richten sich nach der Anzahl der notwendigen Rechner und Netzwerke. So- mit können kleinere Netzwerke, ohne Verschwendung einer großen Anzahl IP-Adressen gebildet werden. Zur Erläuterung sei hier die Aufteilung eines Klasse-C-Netzwerk^[27] ge- zeigt. Diese Art der Erzeugung von Subnetzwerken wird als Variable Length Subnet

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Beispiel mögliche Klasse-C-Subnetze des Netzwerkes.

Masks (VLSM)28 bezeichnet, sie ist für die Bildung von LAN und Routernetzwerken sehr wichtig. Einige UNIX Systeme unterstützen VLSM, offiziell29 erst in aktuellen Versionen z. B. SUN Solaris erst ab der Version 2.6. Hat ein Unternehmen ein Klasse-C-Netzwerk zugeordnet bekommen, kann es mit CI- DR die internen Netzwerksegmente bilden. Datenpakete, die aus dem Internet an das Un- ternehmen gerichtet sind, werden von extern auf die C-Klasse vermittelt, d. h. für externe Teilnehmer sind die internen Aufteilungen nicht zu erkennen. In der Praxis werden häufig bei der Konfiguration gerade hier Fehler gemacht. Diese sind schwer zu finden und haben meist äußerst "wilde" Fehlersymptome.

Deshalb sollte, bevor mit der Einrichtung von IPSec begonnen wird, mit Ping^[30], Tra- ceroute und anderen Tools^[31] der Verbindungsweg geprüft werden. Routing-Tabellen der beteiligten Computer müssen vollständig und fehlerfrei sein.

Ethernetpaket Im Abb. 2.10 ist der Aufbau eines Ethernetpaketes, das einen IP und einen TCP-Protokollkopf enthält, dargestellt. Zu sehen ist hier, dass die Nutzdatenmenge mit der Anzahl der Protokollköpfe abnimmt, da die Größe des Datenpaketes begrenzt ist.Wird nun von dem Server oder Client vor dem Kommunikationsbeginn die PMTU festgestellt, und ist diese geringer, dann wird die Nutzdatenmenge (hier immerhin noch 1460 Bytes) schon beim Versand im Ethernet verringert. Diese kleineren Pakete sind einer Fragmentierung vorzuziehen, da bei Verlust eines fragmentierten Paketes, alle Teilstücke wiederholt werden müssen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.10: Aufbau eines TCP Paketes, für den Versand im Ethernet

2.2 Protokolle und Modi

Im Kapitel 2.1.3 auf Seite 7 haben wir das TCP/IP Protokoll betrachtet, dies ist wichtig, da IPSec darauf basiert. Nun wollen wir uns mit dem Konzept und der Technik von IPSec beschäftigen.

Nachdem ich in einer Zeitschrift einen Bericht über IP Security (IPSec) gelesen hatte, stellten sich mir direkt einige Fragen: Welche Möglichkeiten bietet IPSec? Was ist ei- gentlich IPSec? Ist IPSec ein Protokoll? Oder ist es eine Sammlung von verschiedenen Komponenten, die zusammen ein Sicherheitskonzept ergeben? Und wenn ja, aus welchen Komponenten besteht IPSec? Um es vorwegzunehmen, IPSec ist eine Ansammlung un- terschiedlicher Komponenten, die wie ein Baukasten zusammengesetzt werden können. Jedoch muss die Auswahl der Komponenten sorgfältig getroffen werden, damit die An- ordnung Sinn ergibt und zuverlässig und sicher betrieben werden kann. Hier die Schlag-

worte, die später im Detail erläutert und in Zusammenhang gebracht werden sollen:

Betriebsmodus: Transport Mode, Tunnel Mode, Transformationen, Proposal

Protokolle: Authentication Header (AH)-Protokoll, Encapsulating Security Payload

(ESP)-Protokoll

Policy: Domain of Interpretation (DOI), Security Association Database (SAD), Security

Policy Database (SPD)

Key Management: Internet Key Exchange (IKE), Manual Key, Auto Key, Public key In-

frastructure (PKI)

Tunnel Aufbau: Phase 1, Main Mode, Aggressive Mode, Diffie-Hellmann-Austausch,

Phase 2, Quick Mode, Perfect Forward Secrecy (PFS), Replay-Protection

2.2.1 Transportmode

Im Transportmodus kommunizieren zwei Rechner über IPSec miteinander, Daten wer- den verschlüsselt und/oder authentifiziert ausgetauscht. Dies wird als "Ende-zu-Ende" Sicherheit (End to End (E2E)) bezeichnet. Der Einsatz des Transportmodus ist immer dann sinnvoll, wenn keiner der Kommunikationsendpunkte ein vermittelnder Rechner ist, sondern wenn beide Endpunkte direkt miteinander kommunizieren sollen, dargestellt

in Abb. 2.11 auf der nächsten Seite. Zwischen dem IP-Header (der Original-Header im Klartext) und dem TCP-Header oder UDP-Header werden zwei weitere neue Header ein- gefügt. Dies sind der Authentication Header (AH)-Header und/oder der Encapsulating Security Payload (ESP)-Header. Im Transportmodus kann man kombinieren, ob nur der AH-Modus, oder nur der ESP-Modus, oder eine Kombination von beiden benutzt wer- den soll. Der Aufbau eines Paketes im Transportmodus mit AH und ESP ist in Abb. 2.12

[...]

---

^[1] WAN engl. für Weitverkehrsnetze

^[2] LAN engl. für Lokales Netzwerk

^[3] Das Netz sollte nach einem evtl. Atomschlag weiter funktionieren (man war ja noch im sog. "Kalten Krieg").

^[4] Prof. Dr. Rainer Oechsle Rechnernetze, TCP/IP: Transport und Vermittlung im Internet. Trier: Fernstu- dium Allgemeine Informatik, Fachhoschule Trier, 1999, Lerneinheit Informations- und Kommunikati- onstechniken, vgl. Seite 1.

^[5] Darauf werden wir in Kap. 3.3.1 auf Seite 49 noch zurückkommen.

^[6] Naganad Doraswamy und Dan Harkins IPSEC, Der neue Sicherheitsstandard für das Internet, Intranets

und virtuelle private Netze. 1. Auflage. München: Addison-Wesley Verlag, 2000, vgl. Abb 2.1 auf Seite

36.

^[7] Doraswamy und Harkins, a. a. O., vgl. Seite 38.

^[8] Doraswamy und Harkins, a. a. O., vgl. Seite 38

^[9] Doraswamy und Harkins, a. a. O., vgl. Seite 38

^[10] Doraswamy und Harkins, a. a. O., vgl. Seite 37.

^[11] Jon Postel RFC 791: Internet Protocol. ftp://ftp.isi.edu/in-notes/rfc791.txt ­ besucht am 20.02.2003.

^[12] Header = gemeint sind hier Kopfinformation eines Datenpaketes

^[13] Postel, a. a. O.

^[14] Die Kopplung zweier unterschiedlicher Netzwerke wird im allgemeinen über einen Router erfolgen, dieser übernimmt dabei die Arbeit der Fragmentierung.

^[15] Firewalls = engl. Brandmauern. Sind Sicherheitssysteme die den Zugriff auf Netzwerke durch Regelwer- ke einschränken.

^[16] Randall Atkinson RFC 2401: Security Architecture for the Internet Protocol. ftp://ftp.isi.edu/in-notes/

rfc2401.txt ­ besucht am 20.02.2003, Kap. 6.1.2 Path MTU Discovery.

^[17] Jon Postel RFC 793: Transmission Control Protocol. ftp://ftp.isi.edu/in-notes/rfc793.txt ­ besucht am

20.02.2003.

^[18] Diese Verbindungen (Sessions) werden unterschieden durch die ausgehandelten Portnummern.

^[19] Postel, a. a. O.

^[20] Jon Postel RFC 768: User Datagram Protocol. ftp://ftp.isi.edu/in-notes/rfc768.txt ­ besucht am 20.02.2003.

^[21] Michael-John Muuss The Story of the PING Program. http://ftp.arl.army.mil/mike/ping.html ­ besucht am 22.01.2003.

^[22] Jon Postel RFC 792: Internet Control Message Protocol. ftp://ftp.isi.edu/in-notes/rfc792.txt ­ besucht am 20.02.2003.

^[23] Jon Postel und Joyce K. Reynolds RFC 1700: Assigned Numbers. ftp://ftp.isi.edu/in-notes/rfc1700. txt ­ besucht am 20.02.2003, In RFC 3232 wurde die Auflistung des RFC 1700 durch eine Online Datenbank ersetzt. Die Auflistung der ICMP-Types und Kode's ist soweit vollständig..

^[24] Postel und Reynolds, a. a. O.

^[25] Eine weitere Adressierungsart Anycast befindet sich zur Zeit in der Forschung.

Adress- Start Ende Subnetzmaske Anz. Anz.

^[26] Yakov Rekhter RFC 1817: CIDR and Classful Routing. ftp://ftp.isi.edu/in-notes/rfc1817.txt ­ besucht

am 20.02.2003.

^[27] Anm.: Es sind jeweils abgezogen die Netzwerkadresse, und die Broadcastadresse

Subnetzmaske CIDR Anz. Bits Anz. Anz.

^[28] Rekhter, a. a. O.

^[29] Vorher war es nur als sog. undocumented feature verfügbar, d. h. ohne Support.

^[30] Muuss The Story of the PING Program, a. a. O.

^[31] Auf UNIX Maschinen stehen die Befehle tcpdump und snoop, oder ähnlich zur Verfügung. Damit können Datenpakete aus dem Netzwerk sichtbar gemacht und Fehler schneller erkannt werden, dies setzt einen geübten Umgang mit den oben genannten Tools voraus.