Netzwerk - Und Datensicherheit - Eine Praktische Einführung

Martin Kappes
Netzwerk- und Datensicherheit
Martin Kappes
Netzwerk- und
Datensicherheit
Eine praktische Einfhrung
Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte bibliografische Daten sind im Internet ber <http://dnb.d-nb.de> abrufbar.
Prof. Dr. Martin Kappes ist Professor fr Informatik, insbesondere Rechnernetze und Betriebssysteme,
an der Fachhochschule Frankfurt am Main. Seine Arbeitsschwerpunkte liegen im Bereich Netzwerkund Systemsicherheit.
1. Auflage 2007
Alle Rechte vorbehalten
B.G. Teubner Verlag / GWV Fachverlage GmbH, Wiesbaden 2007
Lektorat: Ulrich Sandten / Kerstin Hoffmann
Freies Korrektorat: Cornelia Agel
Der B.G. Teubner Verlag ist ein Unternehmen von Springer Science+Business Media.
www.teubner.de
Das Werk einschlielich aller seiner Teile ist urheberrechtlich geschtzt. Jede Verwertung
auerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulssig und strafbar. Das gilt insbesondere fr Vervielfltigungen, bersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen
Systemen.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk
berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne
der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wren und daher von
jedermann benutzt werden drften.
Umschlaggestaltung: Ulrike Weigel, www.CorporateDesignGroup.de
Buchgestaltung: Ivonne Domnick
Druck und buchbinderische Verarbeitung: Strauss Offsetdruck, Mrlenbach
Gedruckt auf surefreiem und chlorfrei gebleichtem Papier.
Printed in Germany
ISBN 978-3-8351-0156-2
Vorwort
IT-Sicherheit ist ein sehr komplexes und umfangreiches Thema, das letztlich jeden Teilbereich
der Informatik mehr oder weniger direkt betrifft. Entsprechend umfangreich ist das Material, aus
dem die Inhalte fr dieses Buch ausgewhlt werden mussten.
Ich habe mich entschlossen, keinen khnen Parforceritt durch das Feld der IT-Sicherheit zu
unternehmen und dabei zu versuchen, mglichst viele Themen mglichst detailliert abzudecken,
sondern ganz bewusst eine Auswahl von Inhalten aus dem Bereich Netzwerk- und Datensicherheit getroffen. Bei deren Behandlung wird ebenfalls gezielt auf viele Details verzichtet, die eigentlich erwhnenswert wren oder vielleicht sogar behandelt werden sollten.
Oft werden Sachverhalte vereinfacht dargestellt. An einigen Stellen schrammen diese Vereinfachungen knapp an einer Trivialisierung komplexer Fragen und Probleme vorbei. Trotzdem sind
diese Vereinfachungen aus meiner Sicht notwendig und sinnvoll. Sie sind notwendig, da jedes
einzelne Kapitel des Buchs ein Thema abdeckt, das fr sich alleine genommen schon gengend
Stoff fr ein Buch bietet, und solche Bcher sind ja auch geschrieben worden.
Die Vereinfachungen sind aber vor allem sinnvoll, denn im Vordergrund dieses Buches steht
nicht das Ziel, mglichst umfassendes Detailwissen zu vermitteln, sondern den Leserinnen und
Lesern in erster Linie eine fundierte Basis zum Thema IT-Sicherheit an die Hand zu geben.
Hierzu zhlt ein grundlegendes Verstndnis fr die Wichtigkeit und die prinzipiellen Probleme
genauso wie die Skizzierung mglicher Lsungen. Das Buch erhebt dabei keinen Anspruch auf
Vollstndigkeit, wohl aber darauf, dass die wichtigsten Methoden und Prinzipien der Netzwerkund Datensicherheit auch exemplarisch an Beispielen vorgestellt wurden.
Soviel Mhe sich ein Autor auch gibt, Lehrbcher werden oft nicht von der ersten bis zur
letzten Seite gelesen. Ich habe versucht, dem Rechnung zu tragen, indem die einzelnen Kapitel,
soweit als mglich, auch eigenstndig gelesen werden knnen:
Das erste Kapitel bietet eine Einfhrung in die Thematik. Es werden grundlegende Begriffe
eingefhrt sowie Ziele von IT-Sicherheit und mgliche Angriffe auf sie dargestellt. Neben einigen organisatorischen Grundlagen werden auch die rechtlichen Rahmenbedingungen in Deutschland skizziert. In Kapitel 2 werden fundamentale kryptographische Prinzipien und Methoden vorgestellt. Kapitel 3 diskutiert die wichtigsten Authentikationsmechanismen. Diese Kapitel sind
grundlegend fr nahezu alle weiteren Kapitel des Buchs und sollten deshalb von Ihnen speziell
dann gelesen werden, wenn Sie hinsichtlich IT-Sicherheit, Kryptographie und Authentikation
keine Vorkenntnisse besitzen.
Hieran schlieen sich drei Kapitel an, die eine logische Einheit bilden und sich mit Systemsicherheit beschftigen. Kapitel 4 befasst sich mit Sicherheit auf der Betriebssystemebene. Kapitel
5 betrachtet die Sicherheit von Anwendungen. Hieran schliet sich in Kapitel 6 eine Darstellung
von Malware, also Viren, Wrmern und anderem Ungeziefer, an.
Danach wenden wir uns der Netzwerksicherheit zu. In Kapitel 7 wird eine knappe Darstellung
der wichtigsten Grundlagen und Protokolle prsentiert, die sich speziell an Leser ohne Vorkennt-
VI
nisse im Bereich Netzwerke richtet, oder an Leserinnen und Leser, die ihre Kenntnisse auffrischen mchten. Hieran schliet sich in Kapitel 8 eine erste Betrachtung von Sicherheitsaspekten
in Netzwerken an, in der wir speziell auf Schwachstellen in den im Internet verwendeten Protokollen eingehen. Die darauffolgenden Kapitel 9 bis 15 beschftigen sich mit Firewalls, Virtual
Private Networks, Netzwerkberwachung, Verfgbarkeit, Netzwerkanwendungen, Realzeitkommunikation und lokalen Netzen. Diese Kapitel gehren logisch zusammen, knnen jedoch auch
einzeln oder in anderer Reihenfolge gelesen werden.
Am Ende betrachten wir in Kapitel 16 praktische Richtlinien fr die IT-Sicherheit in Institutionen.
brigens: Zusatzmaterialien zum Buch wie aktuelle Hinweise, Links und weitere Aufgaben
und Beispiele nden Sie im Internet unter
.
Abschlieend mchte ich mich ganz herzlich bei denen bedanken, die mit ihrem Einsatz zum
Gelingen dieses Buches beigetragen haben. An erster Stelle bei Herrn Ulrich Sandten, dem Cheflektor des Teubner-Verlags, der mit seinen vielen Hinweisen und Vorschlgen ganz entscheidend
zum Gelingen des Werks beigetragen hat, und seinem Team, insbesondere Cornelia Agel, Ivonne Domnick, Kerstin Hoffmann und Ulrike Klein. Carsten Biemann, Frederik Happel, meiner
Frau Sabine Kappes, Christian Kopp, Boban Krsic, Dr. Jens Liebehenschel, Andreas Renner und
Prof. Dr. Peter Wedde gebhrt ebenfalls ein groes Danke. Sie alle haben Vorversionen dieses
Buches gelesen, wofr ihnen schon alleine wegen des relativ unfertigen Zustands der Vorversionen Respekt gezollt werden muss, und mir ausfhrliches Feedback gegeben, das fr die Endversion unverzichtbar war, und von inhaltlichen Anmerkungen und Verbesserungsvorschlgen bis
hin zu Tippfehlern ging.
Ganz am Ende mchte ich mich an Sie, liebe Leserinnen und Leser, wenden und Sie ermutigen,
mir ebenfalls Ihr Feedback zu diesem Buch zukommen zu lassen. Ich bin gespannt darauf, wie
Ihnen das Buch gefllt, und welche Anmerkungen Sie haben.
Frankfurt am Main, im August 2007
Martin Kappes
Inhaltsverzeichnis
Einfhrung
1.1 Warum IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziele von IT-Sicherheit . . . . . . . . . . . . . . . . . . . . . .
1.3 Angriffe auf IT-Sicherheit . . . . . . . . . . . . . . . . . . . . .
1.3.1 Angriffsarten . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Schwachstellen . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Ziele eines Angriffs . . . . . . . . . . . . . . . . . . . .
1.4 Risiken und Unsicherheit . . . . . . . . . . . . . . . . . . . . .
1.5 IT-Sicherheit in der Praxis . . . . . . . . . . . . . . . . . . . .
1.6 Organisatorische Grundlagen der IT-Sicherheit . . . . . . . . .
1.6.1 Rahmenbedingungen . . . . . . . . . . . . . . . . . . .
1.6.2 IT-Sicherheit als Prozess . . . . . . . . . . . . . . . . .
1.7 Rechtliche Grundlagen und Rahmenbedingungen in Deutschland
1.7.1 Bundesdatenschutzgesetz . . . . . . . . . . . . . . . . .
1.7.2 Telekommunikationsgesetz . . . . . . . . . . . . . . . .
1.7.3 Telemediengesetz . . . . . . . . . . . . . . . . . . . . .
1.7.4 Handelsgesetzbuch . . . . . . . . . . . . . . . . . . . .
1.7.5 Bundesamt fr Sicherheit in der Informationstechnik . .
1.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . .
1.9 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . .
1.9.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . .
1.9.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
5
5
6
7
7
9
10
10
10
11
11
12
13
13
13
15
15
15
16
Kryptographische Prinzipien und Methoden

2.1 Grundlagen . . . . . . . . . . . . . . . . . . . . .
2.1.1 Denition . . . . . . . . . . . . . . . . . .
2.1.2 Modell . . . . . . . . . . . . . . . . . . .
2.2 Verschlsselungsverfahren . . . . . . . . . . . . .
2.2.1 Vom Klartext zum Chiffretext . . . . . . .
2.2.2 Sicherheit von Verschlsselungsverfahren .
2.2.2.1 Kryptanalysis . . . . . . . . . .
2.2.2.2 Ein absolut sicheres Verfahren .
2.3 Symmetrische Verfahren und Public-Key-Verfahren
2.3.1 Grundlagen . . . . . . . . . . . . . . . . .
2.3.2 Symmetrische Verfahren . . . . . . . . . .
2.3.3 Public-Key-Verfahren . . . . . . . . . . .
2.3.4 Hybride Verfahren . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
17
18
20
20
21
21
23
25
25
25
27
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
VIII
2.4
2.5
2.6
Inhaltsverzeichnis
Betriebsarten . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Electronic Code Book . . . . . . . . . . . . . . . .
2.4.2 Cipher Block Chaining . . . . . . . . . . . . . . . .
2.4.3 Cipher Feedback Mode und Output Feedback Mode
2.4.4 Counter Mode . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . .
bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . .
2.6.1 Wiederholungsaufgaben . . . . . . . . . . . . . . .
2.6.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
32
33
35
36
37
37
37
Authentikation
3.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Mgliche Faktoren zur Authentikation . . . . . . . . . . . . . . . . . . .
3.3 Passwrter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Gre des Passwortraums . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Sicherheit der Passwortspeicherung beim Anwender und im System
3.3.3 Sicherheit der Passworteingabe und bertragung . . . . . . . . . .
3.3.4 Passwrter Eine Sicherheitslcke? . . . . . . . . . . . . . . . . .
3.4 Tokens und Smart-Cards . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Biometrie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Kryptographische Methoden . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 Authentikation von Benutzern und Maschinen . . . . . . . . . . .
3.6.2 Digitale Signatur . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.3 Infrastrukturen zur Authentikation . . . . . . . . . . . . . . . . .
3.6.3.1 Zertikate und Certicate Authorities . . . . . . . . . . .
3.6.3.2 Zertikate in der Praxis: X.509 . . . . . . . . . . . . . .
3.6.3.3 Beispiel: X.509 Zertikate mit OpenSSL selbst erstellen .
3.6.3.4 Web of Trust . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . . . . . . . .
3.8.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
40
41
41
43
45
46
47
48
50
50
52
54
54
57
59
65
65
66
66
67
Betriebssysteme und ihre Sicherheitsaufgaben

4.1 Aufgaben und Aufbau von Betriebssystemen . . . . . . . . .
4.2 Systemadministratoren . . . . . . . . . . . . . . . . . . . . .
4.3 Rechtevergabe und Zugriffskontrolle am Beispiel Dateisystem
4.4 Trusted Computing . . . . . . . . . . . . . . . . . . . . . . .
4.5 Monitoring und Logging . . . . . . . . . . . . . . . . . . . .
4.6 Absichern des Systems gegen Angriffe . . . . . . . . . . . . .
4.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . .
4.8 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . .
4.8.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . .
4.8.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69
69
71
72
77
78
78
79
80
80
80
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
Anwendungen
5.1 Einfhrung . . . . . . . . . . . . . . .
5.2 Buffer Overows . . . . . . . . . . . .
5.2.1 Das Problem . . . . . . . . . .
5.2.2 Schutzmanahmen . . . . . . .
5.3 Race Conditions . . . . . . . . . . . . .
5.4 Software aus dem Internet . . . . . . .
5.4.1 Downloads . . . . . . . . . . .
5.4.2 Aktive Inhalte . . . . . . . . . .
5.4.2.1 Einfhrung . . . . . .
5.4.2.2 Java und Java-Applets
5.4.2.3 JavaScript . . . . . .
5.4.2.4 ActiveX Control . . .
5.5 Zusammenfassung . . . . . . . . . . .
5.6 bungsaufgaben . . . . . . . . . . . .
5.6.1 Wiederholungsaufgaben . . . .
5.6.2 Weiterfhrende Aufgaben . . .
IX
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
83
84
84
86
86
88
88
88
88
89
91
91
91
92
92
92
Malware
6.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Schaden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Verbreitung und Funktionsweise . . . . . . . . . . . . . . . . . .
6.3.1 Verbreitung . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . .
6.3.2.1 Viren . . . . . . . . . . . . . . . . . . . . . . .
6.3.2.2 Wrmer . . . . . . . . . . . . . . . . . . . . .
6.3.2.3 Backdoors und Root Kits . . . . . . . . . . . .
6.3.2.4 Zombies . . . . . . . . . . . . . . . . . . . . .
6.4 Schutzmanahmen und Entfernung von Malware . . . . . . . . .
6.4.1 Schutzmanahmen . . . . . . . . . . . . . . . . . . . . .
6.4.1.1 Virenscanner . . . . . . . . . . . . . . . . . . .
6.4.1.2 Systemkonguration, Dienste und Einstellungen
6.4.1.3 Patches und Updates . . . . . . . . . . . . . . .
6.4.1.4 Heterogenitt . . . . . . . . . . . . . . . . . .
6.4.1.5 Firewalls und Filtermechanismen . . . . . . . .
6.4.1.6 Vorsichtige Benutzer . . . . . . . . . . . . . . .
6.4.2 Entfernung . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . . .
6.6.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
93
94
95
95
96
96
97
98
98
99
99
99
99
100
100
100
101
101
102
102
102
103
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Netzwerke und Netzwerkprotokolle

105
7.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Inhaltsverzeichnis
7.2
7.3
7.4
7.5
7.6
Das Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Die wichtigsten Netzwerkprotokolle im berblick . . . . . . . . . . . . . . . .
7.3.1 Datenverbindungsschicht: LAN-Technologien . . . . . . . . . . . . . .
7.3.1.1 IEEE 802.3 / Ethernet . . . . . . . . . . . . . . . . . . . . .
7.3.1.2 IEEE 802.11 Wireless Local Area Networks . . . . . . . . .
7.3.1.3 Bridges und Switches . . . . . . . . . . . . . . . . . . . . .
7.3.2 Datenverbindungsschicht: Das Point-to-Point Protocol (PPP) . . . . . .
7.3.3 Netzwerkschicht: Internet Protocol (IP) . . . . . . . . . . . . . . . . .
7.3.3.1 IP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.3.2 IPv4 und IPv6 . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.3.3 Das ICMP-Protokoll . . . . . . . . . . . . . . . . . . . . . .
7.3.3.4 Routing unter IP . . . . . . . . . . . . . . . . . . . . . . . .
7.3.3.5 Automatische Konguration von Rechnern . . . . . . . . . .
7.3.3.6 An der Schnittstelle von IP und Datenverbindungsschicht: Address Resolution Protocol . . . . . . . . . . . . . . . . . . .
7.3.4 Transportschicht: TCP und UDP . . . . . . . . . . . . . . . . . . . . .
7.3.4.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.4.2 User Datagram Protocol (UDP) . . . . . . . . . . . . . . . .
7.3.4.3 Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.5 Applikationsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.5.1 Ein kleiner Spaziergang durch den Zoo der Applikationsprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.5.2 Domain Name Service (DNS) . . . . . . . . . . . . . . . . .
Netzwerke in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1 Referenznetzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.2 Konguration der Rechner und Router . . . . . . . . . . . . . . . . . .
7.4.3 Unser Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.4 Sniffer und Protokollanalysierer . . . . . . . . . . . . . . . . . . . . .
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
106
110
110
110
111
111
112
112
113
114
114
115
117
.
.
.
.
.
.
117
118
118
123
123
125
.
.
.
.
.
.
.
.
.
.
.
125
125
126
126
127
132
134
135
136
136
136
Sicherheit in Netzwerken
137
8.1 Bedrohungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.1.1 Bedrohungssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
8.1.2 Struktur des Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
8.1.3 Mithren in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
8.1.4 Manipulieren von Nachrichten . . . . . . . . . . . . . . . . . . . . . . . 140
8.1.5 Schutzmechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.1.6 Anonymitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.2 Beispiele fr Schwachstellen und Risiken in Netzwerken und Netzwerkprotokollen142
8.2.1 Manipulationen beim Routing . . . . . . . . . . . . . . . . . . . . . . . 142
8.2.2 MAC-Address-Spoong . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Inhaltsverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
143
144
145
147
148
149
151
152
154
155
156
156
156
Firewalls
9.1 Der Grundgedanke von Firewalls . . . . . . . . . . . . . . . . .
9.2 Komponenten von Firewalls . . . . . . . . . . . . . . . . . . .
9.2.1 Paketlter-Firewalls . . . . . . . . . . . . . . . . . . .
9.2.1.1 Einfhrung . . . . . . . . . . . . . . . . . . .
9.2.1.2 Typische Kongurationen von Paketltern . .
9.2.1.3 Statische vs. dynamische Paketlter . . . . . .
9.2.1.4 Probleme und Grenzen von Paketltern . . . .
9.2.1.5 Network Address Translation . . . . . . . . .
9.2.1.6 Paketlter unter Linux . . . . . . . . . . . . .
9.2.2 Applikation-Level-Gateways . . . . . . . . . . . . . . .
9.2.2.1 Einfhrung . . . . . . . . . . . . . . . . . . .
9.2.3 Application-Level-Gateways und Paketlter in der Praxis
9.3 Firewall-Architekturen . . . . . . . . . . . . . . . . . . . . . .
9.3.1 Einfache Firewall . . . . . . . . . . . . . . . . . . . . .
9.3.2 Demilitarized Zone (DMZ) . . . . . . . . . . . . . . . .
9.4 Schwachstellen im Konzept von Firewalls . . . . . . . . . . . .
9.4.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . .
9.4.2 Mobile Rechner . . . . . . . . . . . . . . . . . . . . . .
9.4.3 Tunnel und Verschlsselung . . . . . . . . . . . . . . .
9.5 Personal Firewalls . . . . . . . . . . . . . . . . . . . . . . . . .
9.7 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
157
157
159
159
159
160
161
165
167
171
179
179
182
182
182
183
186
186
186
187
190
190
191
191
192
10 Virtual Private Networks (VPN)

10.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Technische Realisierung eines Remote-Access-VPNs . . . . . . . . . . . . . . .
10.3 VPNs als Ersatz dezidierter Datenleitungen . . . . . . . . . . . . . . . . . . . .
193
193
195
197
8.3
8.4
8.5
8.2.3 ARP-Spoong . . . . . . . . . . . . . . .
8.2.4 IP-Spoong . . . . . . . . . . . . . . . . .
8.2.5 TCP Sequence Number Attack . . . . . . .
8.2.6 DNS-Spoong . . . . . . . . . . . . . . .
Sicherheitsprotokolle im Internet Ein berblick .
8.3.1 Sicherheit auf der Applikationsschicht . . .
8.3.2 Sicherheit auf der Transportschicht . . . .
8.3.3 Sicherheit auf der Netzwerkschicht . . . .
8.3.4 Sicherheit auf der Datenverbindungsschicht
Zusammenfassung . . . . . . . . . . . . . . . . .
bungsaufgaben . . . . . . . . . . . . . . . . . .
8.5.1 Wiederholungsaufgaben . . . . . . . . . .
8.5.2 Weiterfhrende Aufgaben . . . . . . . . .
XI
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
XII
Inhaltsverzeichnis
10.4 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4.2 Das AH-Protokoll . . . . . . . . . . . . . . . . . . . . . .
10.4.3 Das ESP-Protokoll . . . . . . . . . . . . . . . . . . . . . .
10.4.4 Aufbau und Verwaltung von SAs und Schlsselmanagement
10.4.5 Praktisches Beispiel . . . . . . . . . . . . . . . . . . . . .
10.5 VPN-Technologien und Klassikation . . . . . . . . . . . . . . . .
10.6 Risiken bei der Verwendung von VPNs . . . . . . . . . . . . . . .
10.6.1 Split Tunneling . . . . . . . . . . . . . . . . . . . . . . . .
10.6.2 ffentliche Zugangsnetze fr Endsysteme . . . . . . . . . .
10.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . .
10.8 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.8.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . . . .
10.8.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
198
198
200
202
205
208
211
213
213
214
216
217
217
217
11 Netzwerkberwachung
11.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.2 Architektur und Komponenten eines netzwerkbasierten IDS
11.2.3 Netzwerkbasierte IDS und Paketlter . . . . . . . . . . . .
11.2.4 Beispiel fr die Verwendung eines IDS . . . . . . . . . . .
11.3 Scannen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.2 Finden von Gerten im Netz . . . . . . . . . . . . . . . . .
11.3.2.1 Ping-Sweep . . . . . . . . . . . . . . . . . . . .
11.3.2.2 Address Resolution Protocol . . . . . . . . . . .
11.3.2.3 Domain Name Service . . . . . . . . . . . . . . .
11.3.3 Portscanning . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.3.1 Prinzipielle Vorgehensweise . . . . . . . . . . . .
11.3.3.2 TCP-Connect-Scan . . . . . . . . . . . . . . . .
11.3.3.3 TCP-SYN-Scan . . . . . . . . . . . . . . . . . .
11.3.3.4 Weitere TCP-Scans . . . . . . . . . . . . . . . .
11.3.3.5 OS-Fingerprinting . . . . . . . . . . . . . . . . .
11.3.4 Schutz vor Scanning . . . . . . . . . . . . . . . . . . . . .
11.3.5 Scanning zum Schutz des Netzes . . . . . . . . . . . . . . .
11.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . . . .
11.5.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
219
219
220
220
222
224
225
227
227
228
228
229
230
230
230
230
232
232
233
233
234
235
236
236
236
12 Verfgbarkeit
237
12.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
12.2 Denial-of-Service (DoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Inhaltsverzeichnis
12.2.1 Klassikation . . . . . . . . . . . . . . . . . . .
12.2.2 Ausnutzen von Schwachstellen: Ping of Death .
12.2.3 Ausnutzen von Schwachstellen und berlastung
12.2.3.1 SYN-Flood . . . . . . . . . . . . . .
12.2.3.2 Distributed-Denial-of-Service (DDos)
12.2.4 Herbeifhren einer berlastung . . . . . . . . .
12.2.4.1 berlastsituationen . . . . . . . . . .
12.2.4.2 TCP berlastkontrolle . . . . . . . . .
12.2.4.3 Smurf-Angriff . . . . . . . . . . . . .
12.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . .
12.4 bungsaufgaben . . . . . . . . . . . . . . . . . . . . .
12.4.1 Wiederholungsaufgaben . . . . . . . . . . . . .
12.4.2 Weiterfhrende Aufgaben . . . . . . . . . . . .
XIII
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
239
240
240
240
243
244
244
244
245
246
246
246
247
13 Netzwerkanwendungen
13.1 Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.1 Grundlegende Funktionsweise und Architektur von Email . . . . . .
13.1.2 SMTP und POP Eine kurze Darstellung aus Sicherheitsperspektive
13.1.2.1 POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.2.2 SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.3 Email als Ende-zu-Ende-Anwendung . . . . . . . . . . . . . . . . .
13.1.3.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.3.2 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.1.3.3 GPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.2 SSH Port Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.3 Praktisches Beispiel: Zugriff auf einen Server durch eine Firewall . .
13.3 Das World Wide Web (WWW) . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.2 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.3 SSL und TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.4 Client-Authentikation . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.5 Server-Authentikation . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.6 Phishing und Pharming . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.7 Weitere Bedrohungen der Sicherheit durch das WWW . . . . . . . .
13.3.7.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.7.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3.8 Anonymitt, Privatsphre und das WWW . . . . . . . . . . . . . . .
13.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.5.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . .
13.5.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
249
249
249
251
251
252
253
253
255
256
256
256
257
259
262
262
265
266
268
269
270
272
272
273
274
278
279
279
280
XIV
14 Realzeitkommunikation
14.1 Anforderungen, Prinzipien, Protokolle . . . . . . . . . . . . . .
14.1.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . .
14.1.2 Medientransport . . . . . . . . . . . . . . . . . . . . .
14.1.3 Realtime Transport Protocol (RTP) . . . . . . . . . . .
14.1.4 Signalisierung . . . . . . . . . . . . . . . . . . . . . .
14.1.5 Session Initiation Protocol . . . . . . . . . . . . . . . .
14.2 Sicherheit von Realzeitkommunikationsanwendungen . . . . . .
14.2.1 Bedrohungen . . . . . . . . . . . . . . . . . . . . . . .
14.2.2 Gegenwrtige Einsatzformen im institutionellen Umfeld
14.2.3 Gegenwrtige Einsatzformen im privaten Umfeld . . . .
14.3 Protokolle fr sichere Realzeitkommunikation . . . . . . . . . .
14.3.1 Sicherer Medientransport: SRTP . . . . . . . . . . . . .
14.3.2 Sicherheitsaspekte bei der Signalisierung . . . . . . . .
14.3.3 SIP-Sicherheitsfunktionen . . . . . . . . . . . . . . . .
14.5 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . .
Inhaltsverzeichnis
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
281
281
281
282
283
284
284
286
286
288
290
291
291
293
295
296
296
296
297
15 Sicherheit auf der Datenverbindungsschicht und in lokalen Netzen

15.1 Das Extensible Authentication Protocol (EAP) . . . . . . . . . . .
15.1.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . .
15.1.2 Nachrichtenformat . . . . . . . . . . . . . . . . . . . . .
15.1.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . .
15.1.4 Einige EAP-Typen im Detail . . . . . . . . . . . . . . . .
15.1.4.1 EAP-TLS . . . . . . . . . . . . . . . . . . . .
15.1.4.2 EAP-TTLS und PEAP . . . . . . . . . . . . . .
15.1.4.3 EAP-FAST . . . . . . . . . . . . . . . . . . . .
15.2 Zugangskontrolle in LANs . . . . . . . . . . . . . . . . . . . . .
15.2.1 Einfhrung . . . . . . . . . . . . . . . . . . . . . . . . .
15.2.2 Ungesicherte lokale Netze . . . . . . . . . . . . . . . . .
15.2.3 IEEE 802.1X Port-based Access Control . . . . . . . . .
15.2.3.1 Funktionsweise . . . . . . . . . . . . . . . . .
15.2.3.2 Authentikation . . . . . . . . . . . . . . . . .
15.3 Sicherheit in WLANs . . . . . . . . . . . . . . . . . . . . . . . .
15.3.1 Eine kurze Einfhrung in IEEE 802.11 . . . . . . . . . .
15.3.2 Sicherheit drahtloser LANs . . . . . . . . . . . . . . . . .
15.3.3 Schwachstellen im ursprnglichen IEEE 802.11-Standard
15.3.4 IEEE 802.11i . . . . . . . . . . . . . . . . . . . . . . . .
15.3.5 VPN-basierter Zugriff auf drahtlose LANs . . . . . . . .
15.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . .
15.5 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . .
15.5.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
299
299
299
300
302
303
303
304
304
305
305
305
306
306
308
310
310
311
312
313
315
316
317
317
Inhaltsverzeichnis
XV
15.5.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . 317

16 Richtlinien fr die Praxis
16.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2 IT-Sicherheit im institutionellen Umfeld . . . . . . . . . . . . . . . . . .
16.2.1 Organisation und Administration . . . . . . . . . . . . . . . . . .
16.2.2 Leitlinien zur Erstellung und Beibehaltung sicherer IT-Strukturen
16.2.3 Minimalanforderungen . . . . . . . . . . . . . . . . . . . . . . .
16.3 IT Sicherheit im privaten Umfeld . . . . . . . . . . . . . . . . . . . . . .
16.4 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.6 bungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.6.1 Wiederholungsaufgaben . . . . . . . . . . . . . . . . . . . . . .
16.6.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
319
319
319
319
321
322
324
324
325
326
326
326
Anhang
327
A Weiterfhrende Literatur
329
Literaturverzeichnis
331
Sachverzeichnis
339
Kapitel 1
1Einfhrung
Einfhrung
1.1 Warum IT-Sicherheit

Sie, liebe Leserin oder Leser, halten ein Buch ber IT-Sicherheit in der Hand, was zwei Grnde
haben kann: Entweder Sie wollen sich ber dieses Thema nher informieren, oder sie mssen.
Wenn Sie sich mit IT-Sicherheit beschftigen mssen, ist die Frage, warum IT-Sicherheit wichtig
ist, eigentlich subjektiv einfach zu beantworten: Sie ist fr Sie wichtig, weil das Gebiet jemand
anderem wichtig erscheint, beispielsweise den Professoren einer Hochschule, die es in einen Studiengang als Fach aufgenommen haben, oder vielleicht Ihrem Vorgesetzten. Doch ich kann Sie
beruhigen: IT-Sicherheit ist eines der wichtigsten Felder der Informatik berhaupt, und sie betrifft ausnahmslos alle Personen, die mit elektronischer Datenverarbeitung in Kontakt kommen.
In den letzten Jahrzehnten hat die Informationstechnologie (IT) nahezu alle gesellschaftlichen
Bereiche, vom privaten bis hin zu jedem denkbaren geschftlichen, durchdrungen. Durch die
breitbandige Vernetzung von Rechnern sind Strukturen entstanden und Mglichkeiten erwachsen, deren gesellschaftliche, politische und konomische Auswirkungen erst langsam deutlich
werden. Einige Experten erwarten durch die neuen Mglichkeiten und Anwendungsfelder der
IT nachhaltige Vernderungen, die von ihrer Bedeutung einer zweiten industriellen Revolution
gleichkommen, an deren Ende die Transformation unserer derzeitigen Industriegesellschaft in
eine Informationsgesellschaft steht.
Unabhngig davon, ob man diesen berlegungen folgt oder ihnen eher skeptisch gegenbersteht, ist Information unbestreitbar zu einem wichtigen, wenn nicht dem wichtigsten Wirtschaftsfaktor geworden. Der Wert und die Konkurrenzfhigkeit eines Unternehmens ist heute zentral
von dessen Know-How, also Informationen ber Geschftsprozesse, Produktionsprozesse oder
Kundendaten abhngig. Konsequenterweise besitzen diese Informationen einen hohen Wert fr
das Unternehmen, und natrlich wren sie auch fr einen Konkurrenten wertvoll.
Mehr und mehr (wenn nicht mittlerweile alle) der Informationen, die das Know-How eines
Unternehmens ausmachen, liegen in elektronischer Form vor. Die Bedrohungen, denen elektronisch vorliegende Information und Informationssysteme ausgesetzt sind, lassen sich mit den
klassischen Mitteln zum Schutz von Ressourcen wie etwa der Perimetersicherheit, also der Beschrnkung und berwachung des physischen Zugangs, oder einer sorgfltigen Auswahl der Mitarbeiter alleine nicht mehr gewhrleisten. Elektronisch vorliegende Information ist neuen Bedrohungen ausgesetzt. In kurzer Zeit knnen groe Mengen von Informationen ber Datennetzwerke
weltweit bertragen werden. Dies ermglicht Unternehmen zum einen neue Mglichkeiten, birgt
aber zum anderen auch neue Gefahren, insbesondere fr die Sicherheit der Information.
1 Einfhrung
Mit der zunehmenden Bedeutung der IT-Sicherheit ist auch das Bewusstsein hinsichtlich der
mglichen Risiken computergesttzter Anwendungen in den Fokus des Interesses gerckt. Zu
den notwendigen Manahmen zum Schutz der IT zhlt der Schutz von Daten und Anwendungen,
deren Kommunikation und des zum Datenaustausch verwendeten Netzwerks gegen unbeabsichtigte oder unfallbedingte Lschung oder Unterbrechung und gegen unbefugte aktive oder passive
Eingriffe durch Dritte.
Neben Unternehmen und anderen Institutionen nutzen auch Privatpersonen IT-Systeme. Dabei
werden ebenfalls Daten eingegeben, gespeichert, verarbeitet und ber Netzwerke transportiert,
die fr Dritte interessant sein knnen. Dies fngt bei fr Werbezwecke relevanten Informationen an (Einkommen, Vorlieben, Neigungen), und geht hin bis zu Bankinformationen, PINs und
TANs, die es Kriminellen ermglichen knnten, den Benutzer zu schdigen, indem sie etwa Geld
vom Konto des Opfers stehlen.
Unter IT-Sicherheit verstehen wir den Schutz von Informationen und Informationssystemen
gegen unbefugte Zugriffe und Manipulationen sowie die Sicherstellung der Verfgbarkeit der
durch die Systeme bereitgestellten Dienste fr legitime Benutzer, einschlielich aller Manahmen zur Verhinderung, Entdeckung oder Protokollierung von Bedrohungen. Der Schutz vor unbefugtem Zugriff muss stndig gewhrleistet sein, insbesondere whrend der Speicherung, der
Verarbeitung und der bertragung.
1.2 Ziele von IT-Sicherheit

Gem der von einer Gruppe von Staaten, darunter Deutschland und die USA, entwickelten
Gemeinsamen Kriterien fr die Evaluation von IT-Sicherheit (Common Criteria for Information Technology Security Evaluation) [CC-1] geht es bei der IT-Sicherheit vor allem darum,
Vertraulichkeit, Integritt und Verfgbarkeit von Informationen sicherzustellen. Es gibt verschiedene Mglichkeiten, wie man diese Begriffe und auch den Begriff IT-Sicherheit przise fassen
kann, ausfhrliche Erluterungen nden sich in [RFC 2828] und [NSTISSC 4009] (siehe auch
[BSI06]).
1. Vertraulichkeit: Schutz von Information gegenber unbefugten Zugriffen Dritter.
2. Integritt: Schutz von Information gegenber Vernderung durch Unbefugte.
3. Verfgbarkeit: Ressourcen und Dienste stehen legitimen Benutzern tatschlich zur Verfgung.
Neben diesen Zielen gibt es noch eine ganze Reihe weiterer Ziele von IT-Sicherheit. Insbesondere drei weitere werden wir in diesem Buch detailliert betrachten:
4. Authentizitt und Authentikation (synonym: Authentizierung): Eindeutige Identikation
des Absenders von Information bei der Informationsbertragung. Eindeutige Identikation
eines Kommunikationspartners.
5. Verbindlichkeit (Nichtabstreitbarkeit): Mglichkeit, den Inhalt und den Absender von Information gegenber einem an der Kommunikation nicht beteiligten Dritten zu beweisen.
1.2 Ziele von IT-Sicherheit
6. Autorisation: Beschrnkung des Zugriffs auf eine Ressource auf bestimmte (authentizierte) Benutzer.
Intuitiv ist der Unterschied zwischen diesen Begriffen klar. Wenn man sich aber genauer damit befasst, so werden diese Grenzen unscharf und die Begriffe sind teilweise schwierig genau
voneinander abzugrenzen. Mit diesem Problem wollen wir uns aber hier nicht lange aufhalten.
Die Vertraulichkeit und Integritt von Information ist wie oben beschrieben ein sehr wichtiges
Themenfeld. Dies gilt insbesondere, wenn die Information elektronisch bertragen oder gespeichert werden. Wie wir noch sehen werden, ist es fr Bits und Bytes, die durch ein Netzwerk
bertragen oder auf einem Medium gespeichert werden, oft unmglich, zu gewhrleisten, dass
Dritte diese Information nicht lesen oder verndern knnen. Daher wird die Vertraulichkeit oft
durch kryptographische Verfahren sichergestellt, mittels derer die eigentliche zu bertragende
oder zu speichernde Information in Chiffretext umgewandelt wird, der dann durch das Netzwerk
zum Empfnger bertragen oder auf dem Speichermedium abgelegt wird. Die Chiffrierung erfolgt so, dass ein legitimer Benutzer, wie etwa der vorgesehene Empfnger der bertragung oder
der Besitzer verschlsselt abgespeicherter Daten, diesen Chiffretext wieder in die ursprngliche
Information zurckverwandeln kann, whrend ein unbefugter Dritter keine Mglichkeit hat, aus
dem Chiffretext die ursprngliche Information zu extrahieren.
Auch die Integritt von Information lsst sich nur indirekt sicherstellen. Hierzu kommen ebenfalls kryptographische Verfahren zum Einsatz. Diese Verfahren ermglichen es zu berprfen, ob
die ursprnglichen Daten beispielsweise beim Transit durch ein Netzwerk oder nach dem Abspeichern auf dem Medium manipuliert und verndert wurden oder nicht. Dies geschieht wiederum
so, dass ein Dritter keine Mglichkeit hat, die Information unbemerkt zu verndern.
Man kann sich darber streiten, ob Authentikation, Authentizitt und Verbindlichkeit Untereigenschaften von Integritt sind oder nicht. Jedenfalls sind sie allemal wichtig genug, um hier
separat angefhrt zu werden. Wenn wir mittels eines kryptographischen Verfahrens sicherstellen
knnen, dass eine Nachricht, also durch ein Netzwerk bertragene Information, beim Transit
durch das Netzwerk nicht verndert wurde, dann ist dies in den allermeisten Fllen nur dann
sinnvoll, wenn wir auch zweifelsfrei wissen, von wem die Nachricht tatschlich stammt, wenn
wir also den Kommunikationspartner oder den Absender einer Nachricht eindeutig identizieren
knnen. Kurz gesagt: Sie mchten wissen, dass Sie eine unvernderte Nachricht von Ihrer Bank
erhalten haben. Die Information, dass Sie eine unvernderte Nachricht von jemand erhalten haben, der vorgibt, Ihre Bank zu sein, hilft Ihnen nicht wirklich weiter. Auch zur Sicherstellung der
Authentizitt knnen kryptographische Verfahren zum Einsatz kommen.
Verbindlichkeit beinhaltet Authentizitt, umfasst aber noch ein weiteres, entscheidendes Kriterium: Bei Verbindlichkeit muss auch gegenber Dritten eindeutig nachweisbar sein, von wem
eine Nachricht stammt. Dies ist bei Authentizitt nicht unbedingt der Fall. Verbindlichkeit ist insbesondere beim Abschluss von Vertrgen wichtig. Wenn ein Kunde ber das Internet bei seiner
Bank Aktien kauft, die sofort im Anschluss an die Transaktion stark im Wert fallen, so knnte der
Kunde hinterher behaupten, dass er diese Transaktion gar nicht gettigt hat. In diesem Fall ist es
fr die Bank wichtig, dass sie gegenber einem Gericht nachweisen kann, dass die Transaktion
tatschlich durch den betreffenden Kunden angeordnet wurde.
Die Verfgbarkeit von Informationen und Diensten ist ebenfalls ein wichtiges Ziel von ITSicherheit. Der Ausfall eines IT-Systems kann fr Institutionen existenzbedrohend sein, bei-
1 Einfhrung
spielsweise, wenn die Server eines Online-Hndlers ber einen lngeren Zeitraum nicht erreichbar sind.
Betrachten wir nun zur Vertiefung ein Beispiel, an dem wir Vertraulichkeit, Integritt und
Verfgbarkeit illustrieren knnen. Auf einem Rechner des Geschftsfhrers eines kleinen Unternehmens liegt eine Datei mit einer Tabelle, in der das monatliche Gehalt jedes Mitarbeiters
der Firma vermerkt ist. Aus naheliegenden Grnden (Neid, Missgunst, Mobbing, Intrigen) sollen diese Daten ausschlielich dem Geschftsfhrer selbst zugnglich sein. Die Vertraulichkeit
der Daten ist gewahrt, wenn dies tatschlich der Fall ist. Es gibt viele Mglichkeiten, wie die
Vertraulichkeit der Daten gebrochen werden kann:
Ein Hacker bricht ber das Internet in den Rechner ein und gelangt so in den Besitz der
Daten.
Der Rechner wird durch einen Virus inziert, der die Daten ber das Netz an unbefugte
weiterschickt.
Der sehr neugierige Administrator der Firma hat Zugriff auf den Rechner und kopiert die
Daten auf eine Diskette.
Der Geschftsfhrer lsst die Datei geffnet auf dem Bildschirm, whrend er in einer Besprechung ist, ein Mitarbeiter liest die Daten vom Bildschirm ab.
Der Geschftsfhrer kopiert die Daten auf einen Memory-Stick, den er dann verliert oder
gestohlen bekommt.
Der ganze Rechner wird bei einem Einbruch gestohlen.
Der Geschftsfhrer ist unachtsam und schickt die Datei (gehalt.xls) versehentlich anstatt
der Wegbeschreibung fr den anstehenden Betriebsausug (gehoelz.doc) als Anhang einer
Email an alle Mitarbeiter.
Auch die Integritt der Datei mit den Gehaltsdaten kann auf verschiedenste Weise zerstrt
werden:
Ein Hacker bricht ber das Internet in den Rechner ein und verndert die Daten.
Der Rechner wird durch einen Virus inziert, der die Daten verndert.
Der Administrator der Firma hat Zugriff auf den Rechner und verndert die Daten.
Der Geschftsfhrer lsst die Datei geffnet auf dem Bildschirm, whrend er in einer Besprechung ist, ein Mitarbeiter liest und verndert die Daten auf dem Rechner.
Bleiben wir bei diesem Beispiel und betrachten die Verfgbarkeit. Die Verfgbarkeit der Datei kann durch absichtliches oder versehentliches Lschen gestrt werden. Auch die Zerstrung
des Datentrgers, auf dem die Datei gespeichert ist, gefhrdet die Verfgbarkeit. Brennen die
Brogebude der Firma aus, ist auch die Datei verloren - was in diesem Fall vielleicht die kleinste Sorge des Unternehmens wre. Aber es gibt viele Flle, in denen die Vorsorge gegen solche
1.3 Angriffe auf IT-Sicherheit
Katastrophen ein wesentlicher Bestandteil der Vorkehrungen fr IT-Sicherheit sein sollte. Eine Softwarerma, die durch einen Brand den Quellcode ihrer Produkte verliert, hat sicherlich
im Vorfeld groe Fehler begangen. Ob eine Versicherung fr solche Schden aufkommen wrde, ist hchst zweifelhaft, da das Fehlen von Sicherungskopien wichtiger elektronischer Daten
(Backups) wohl zumindest als grob fahrlssig gelten kann.
Eines sollte Ihnen bereits jetzt klar geworden sein: IT-Sicherheit ist ein komplexes Feld. Um
Vertraulichkeit, Integritt und Verfgbarkeit gewhrleisten zu knnen, ist nicht eine einzelne
Manahme ausreichend, sondern es muss ein ganzer Katalog von Manahmen umgesetzt werden. Auerdem ist es unerllich, die IT-Sicherheit stndig zu berprfen, auditieren und gegebenenfalls neuen Bedingungen und Bedrohungen anzupassen.
Der Versuch, IT-Sicherheitsmechanismen vorstzlich auszuhebeln und so eines der Ziele der
IT-Sicherheit zu kompromittieren, wird auch als Angriff bezeichnet. In diesem Buch beschftigen wir uns in erster Linie mit Angriffen auf informationstechnischem Weg und mit IT-basierten
Manahmen, wie man sie verhindern oder zumindest entdecken kann. Im Fokus unserer berlegungen stehen also nicht die Fragen, wie man (etwa durch geeignetes Design von User-Interfaces
oder geeignete Backup-Strategien) das versehentliche Lschen von Informationen verhindern
kann oder wie man den Diebstahl von Datentrgern oder ganzen Rechnern mit vertraulichen Informationen durch geeignete Manahmen in der Gebudesicherheit verhindert (manchmal hilft
sogar schon eine abschliebare Tr jedenfalls, wenn sie abgeschlossen wird). Um keine Missverstndnisse aufkommen zu lassen: Solche Manahmen sind in den meisten Fllen absolut unverzichtbar, um die IT-Sicherheit tatschlich gewhrleisten zu knnen. Wenn man von der Strae
aus direkt in das Rechenzentrum eines Unternehmens marschieren kann, dann hat das Unternehmen ein gravierendes Sicherheitsproblem, das unmittelbar zu einem IT-Sicherheitsrisiko fhrt.
Ein weiterer wichtiger Punkt, auf den wir nur am Rande eingehen werden, ist Social Engineering. Hierunter versteht man das gezielte Ausnutzen und Provozieren von Benutzerfehlern. Dabei
wird das Sicherheitssystem durch menschliches Versagen ausgehebelt, beispielsweise indem ein
legitimer Benutzer einem unbefugten Dritten ein Passwort verrt.
1.3 Angriffe auf IT-Sicherheit

1.3.1 Angriffsarten
Man unterscheidet zwischen zwei grundlegend unterschiedlichen Typen von Angriffen, nmlich
aktiven und passiven Angriffen.
Passive Angriffe: Bei passiven Angriffen gelangt der Angreifer in den Besitz von Informationen, ohne selbst in das Geschehen einzugreifen. Ein typisches Beispiel hierfr ist
das Mithren und Mitschneiden von elektronisch bertragenen Informationen in einem
Computernetzwerk, etwa in einem Local Area Network (LAN). Da der Angreifer selbst
nicht aktiv wird, sind solche Angriffe nur sehr schwierig (wenn berhaupt) zu bemerken.
Daher steht bei der Abwehr passiver Angriffe die Prvention im Vordergrund, etwa durch
technische Manahmen zur Verhinderung des Mithrens oder die Chiffrierung der zu bertragenden Daten.
1 Einfhrung
Aktive Angriffe: Bei aktiven Angriffen tritt der Angreifer selbst in Erscheinung, indem er
beispielsweise Daten, Informationen oder Dienste flscht, modiziert oder lscht bzw. deren Verfgbarkeit sabotiert. Da der Angreifer selbst aktiv wird, kann er dabei auffallen oder
Spuren hinterlassen, die eine Erkennung des Angriffs und vielleicht sogar des Angreifers
ermglichen knnen. Gegen aktive Angriffe sind sowohl prventive als auch detektorische
Manahmen mglich. Aktive Angriffe knnen auch als Vorbereitung fr einen passiven
Angriff dienen, etwa indem ein Datenstrom durch einen aktiven Angriff so umgelenkt
wird, dass der Angreifer dann passiv mithren kann.
1.3.2 Schwachstellen
Ein erfolgreicher Angriff auf die IT-Sicherheit setzt eine Schwachstelle (wir verwenden in diesem Buch synonym auch den Begriff Sicherheitslcke) voraus, die der Angreifer ausnutzen
kann. Schwachstellen knnen in jeder Phase des Entwicklungsprozesses eines Systems aus Hardund/oder Softwarekomponenten entstehen. Konsequenterweise fallen die Schwachstellen in eine
der folgenden Kategorien:
Anforderungsfehler: Die Anforderungen sind in Bezug auf die Sicherheit fehlerhaft oder
unzureichend.
Designfehler: Die Spezikation einer Hard- oder Softwarekomponente gengt nicht den
Anforderungen und enthlt eine Schwachstelle, die ein Angreifer ausnutzen kann.
Implementierungsfehler: Die Implementierung einer Spezikation weicht von der Spezikation ab. Diese Abweichung kann von einem Angreifer ausgenutzt werden.
Installations- und Administrationsfehler: Bei der Installation oder Administration einer
Komponente wurde eine Schwachstelle geschaffen, beispielsweise eine Sicherheitsfunktion ausgeschaltet.
Betrachten wir dazu einige kurze Beispiele. Anforderungsfehler sind einfach zu illustrieren.
Es war noch vor wenigen Jahren in vielen Bereichen nicht blich, Sicherheitsanforderungen bei
der Entwicklung berhaupt zu bercksichtigen. Somit gab es auch keine Mechanismen, die ein
Angreifer berhaupt htte aushebeln mssen.
In lteren Unix-artigen Systemen war es einem Angreifer, der bereits Zugriff auf das System
hatte, aufgrund des Designs mglich, in den Besitz einer Datei zu gelangen, aus der sich durch
geschicktes Raten relativ einfach die Passwrter von anderen Benutzern des Systems ermitteln
lieen. Diese Schwachstelle ist ein Designfehler, der mittlerweile behoben wurde. Es gibt auch
Flle, in denen im Design und in der Architektur Schwachstellen bekannt sind, die sich aber
nicht oder nur sehr schwer eliminieren lassen. Solche intrinsischen Schwachstellen mssen in
manchen Fllen in Kauf genommen werden.
Implementierungsfehler basieren auf der fehlerhaften Umsetzung eines Designs. Eine LoginProzedur, die zwar Username und Passwort abfragt, dann aber (entgegen der Spezikation) dem
Benutzer unabhngig von den eingegebenen Werten Zugriff auf das System gewhrt, ist ein (drastisches) Beispiel hierfr.
1.4 Risiken und Unsicherheit
Der Administrator kann durch Fehler bei Installation oder Administration ebenfalls Schwachstellen schaffen. Legt er beispielsweise zu Testzwecken einen Benutzer Test mit Passwort
Test an und vergisst anschlieend, diesen Zugang zu lschen, so handelt es sich um einen
klaren Administrationsfehler.
Natrlich kann man diese Klassizierung auch als Grundlage fr einen akademischen Diskurs
nehmen und sich trefich darber streiten, ob Administrationsfehler nicht immer auf vorangegangene Designfehler zurckzufhren sind. Schlielich knnte man schwache Passwrter und
Testzugnge ja bereits durch ein geeignetes Design ausschlieen. Wir wollen hier auf solche
eher theoretischen Diskussionen nicht weiter eingehen. Fehler werden leider gemacht und sie
ermglichen es Angreifern, erfolgreiche Angriffe auf die IT-Sicherheit durchzufhren.
1.3.3 Ziele eines Angriffs

Die Ziele eines Angriffs auf die IT-Sicherheit knnen sehr vielfltig sein und hngen letztlich
von den Motiven des Angreifers (oder seines Auftraggebers) ab.
Whrend anfangs Schabernack treibende Studierende, Nerds und Geeks fr Angriffe verantwortlich waren, die hug zwar unangenehm, aber nicht unbedingt mit schwerwiegenden Folgeschden behaftet waren, zeichnet sich in den letzten Jahren eine deutliche Verschiebung hin
zu kriminellen Motiven, einhergehend mit einer Professionalisierung der Tter, ab. Mittlerweile
sind regelrechte Toolkits erhltlich, die es auch technisch wenig versierten Ttern ermglichen,
Angriffe durchzufhren. Das Spektrum reicht dabei vom Ausspionieren von Kontendaten beim
Online-Banking, um Geld vom Konto des Opfers zu stehlen, bis hin zur automatisierten Industriespionage.
Innentter, also Angreifer, die legitimen Zugang zu einem System besitzen und dieses fr
einen Angriff ausnutzen, nden sich im Tterkreis genauso wie auch Auentter, die keinen
legitimen Zugriff auf das System haben und beispielsweise ber ein ffentliches Netz einbrechen.
In der Regel sind Rechnernetze und die IT-Infrastruktur von Institutionen gegen Angriffe von
auen wesentlich besser geschtzt als gegen Attacken von innen. Ein Innentter muss auch nicht
unbedingt einen Angriff auf die IT-Sicherheit durchfhren, um der Institution zu schaden. Es
reicht, wenn ein Spion das weitergibt, worauf er autorisierten Zugriff hat. Zum Schutz vor solchen Vorgngen knnen automatisierte Verfahren eingesetzt werden, die eventuell erste Anhaltspunkte auf verdchtige Aktionen liefern. Um das Problem der Innentter wirksam einzudmmen,
hilft aber letztlich wohl nur eine Kombination aus IT-Sicherheitsmanahmen und anderen, nicht
IT-basierten Manahmen wie eine sorgfltige Auswahl der Mitarbeiter. Schlampige IT-Sicherheit
in einer Institution kann es mglichen Ttern aber sehr viel leichter machen, und zwar sowohl
von innen als auch von auen.
1.4 Risiken und Unsicherheit

Wenn ein IT-System eine Schwachstelle aufweist, muss dies nicht unbedingt fr einen Angriff
ausgenutzt werden. Eine Schwachstelle kann unentdeckt bleiben oder auch einfach nicht missbraucht werden. Es besteht aber ein Risiko, dass eine Schwachstelle tatschlich fr einen Angriff
1 Einfhrung
ausgenutzt wird. Je nach Art und Umfang der Schwachstelle werden die Folgen eines Angriffs
unterschiedlich schwerwiegende Konsequenzen haben.
Ist eine Mglichkeit bekannt, wie die Schwachstelle beseitigt werden kann, so bestehen verschiedene Handlungsalternativen: Zum einen knnte das Risiko eliminiert werden, indem die
Sicherheitslcke geschlossen wird, zum anderen kann das Risiko weiter in Kauf genommen werden. In der Betriebswirschaftslehre ist dieses Problem als Entscheidung bei Risiko oder Unsicherheit bekannt (siehe [W05]).
Sind fr ein Risiko die Eintrittswahrscheinlichkeit und die jeweils entstehenden Eintrittsfolgen im Voraus bestimmbar, so kann fr jede mgliche Handlungsalternative der Erwartungswert
hinsichtlich der Eintrittsfolgen bestimmt werden. Der Erwartungswert einer Handlungsalternative ist die Summe ber die mit den Eintrittswahrscheinlichkeiten gewichteten Eintrittsfolgen.
Ein rationaler Entscheider wird dann diejenige Alternative mit dem optimalen Erwartungswert
hinsichtlich der Eintrittsfolgen whlen.
Die Frage, welche Mglichkeit gewhlt werden sollte, hngt immer vom Zielsystem des Entscheiders ab (siehe [W05]), das bestimmt, wie und mit welchem Ma die Eintrittsfolgen quantiziert werden. In der Regel interessieren sich Unternehmen hauptschlich fr die nanziellen
Auswirkungen der Eintrittsfolgen. Dies muss jedoch nicht notwendigerweise immer so sein.
Betrachten wir ein Beispiel hierzu. Ein Unternehmen nutzt zur Aufnahme von Bestellungen
seiner Kunden einen Webserver. Gerade wurde eine Sicherheitslcke in der auf dem Server verwendeten Software bekannt. Eine sofortige Behebung der Schwachstelle wrde 10.000 Euro kosten. Die Herstellerrma der Software wird in ca. 14 Tagen ein kostenloses Patch fr die Software
bereitstellen, durch das die Schwachstelle geschlossen wird. Falls die Sicherheitslcke ausgenutzt wird, ist mit einem Schaden in Hhe von 60.000 Euro zu rechnen. Die IT-Abteilung schtzt
die Wahrscheinlichkeit, dass die Sicherheitslcke tatschlich in den nchsten 14 Tagen ausgenutzt wird, auf 0,2 (also 20%). Alternativ bestnde auch die Mglichkeit, den Server temporr
abzuschalten und die Bestellungen solange telefonisch entgegenzunehmen. Das Unternehmen
rechnet dabei mit Kosten von 14.000 Euro.
Das Unternehmen verfgt also ber die folgenden drei Handlungsalternativen:
1. Die erste Mglichkeit ist die sofortige Behebung der Schwachstelle. In diesem Fall entstehen Kosten in Hhe von 10.000 Euro.
2. Die zweite Handlungsalternative ist der Weiterbetrieb des Servers ohne Eliminierung der
Schwachstelle fr 14 Tage und das Verwenden des kostenlosen Patches. Mit einer Wahrscheinlichkeit von 0,2 wird ein Angreifer die Lcke innerhalb der 14 Tage ausnutzen. In
diesem Fall entsteht ein Schaden von 60.000 Euro. Dies bedeutet, dass mit einer Wahrscheinlichkeit von 0,8 nichts passieren wird und auch keine Kosten entstehen. Der Erwartungswert der Kosten dieser Mglichkeit entspricht der Summe der ber die Eintrittswahrscheinlichkeit gewichteten Kosten, also 0, 2 60.000 Euro + 0, 8 0 Euro = 12.000 Euro.
3. Die dritte Alternative wre das Abschalten des Servers und die telefonische Entgegennahme von Bestellungen, bis die Lcke geschlossen werden kann, wobei Kosten von 14.000
Euro entstehen.
In diesem Fall ist die erste Alternative mit den geringsten erwarteten Kosten verbunden, nmlich 10.000 Euro, whrend die anderen Alternativen das Unternehmen mit Kosten in Hhe von
1.5 IT-Sicherheit in der Praxis
12.000 bzw. 14.000 Euro belasten wrden. Somit ist die sofortige Behebung der Schwachstelle
die beste der drei Mglichkeiten. Daher sollte das Unternehmen die Schwachstelle sofort beheben lassen.
In der Praxis ist es in den meisten Fllen unmglich, die Eintrittswahrscheinlichkeiten zu
bestimmen. Selbst die Eintrittsfolgen eines Risikos drften kaum eindeutig zu quantizieren
sein. Mit welchem Geldbetrag ist der Imageschaden einer Bank anzusetzen, wenn das OnlineBankingsystem eine Schwachstelle hat, die Angreifer ausnutzen? In vielen Fllen wird daher oft
das Bauchgefhl von Experten fr die Entscheidung herangezogen werden mssen.
Trotzdem lassen sich aus diesen eher betriebswirtschaftlichen Betrachtungen einige interessante Schlussfolgerungen ziehen, die fr IT-Verantwortliche in Institutionen wichtig sind.
Als Erstes bleibt festzuhalten, dass es letztlich aus Sicht einer Institution nicht um eine Eliminierung mglichst aller Schwachstellen in IT-Systemen geht, sondern um die Minimierung des
Risikos hinsichtlich des Zielsystems, also um die Wahl der (wirtschaftlich) vernnftigsten, optimalen Handlungsalternative. Wie in vielen anderen Bereichen auch, knnen nicht alle Risiken im
Bereich der IT-Sicherheit vollstndig ausgeschlossen werden. Ein bestimmtes Restrisiko bleibt
bei Verwendung eines IT-Systems immer bestehen.
Letztlich stellt sich auch die Frage, ob der Nutzen des Einsatzes eines IT-Systems die damit verbundenen Risiken berhaupt rechtfertigt. Das Abschalten des Systems ist eben auch eine
Handlungsalternative. Glcklicherweise fr alle in der IT-Branche ttigen Personen berwiegt
der (wirtschaftliche) Nutzen der Systeme die (wirtschaftlichen) Risiken aber bei weitem.
1.5 IT-Sicherheit in der Praxis

Verlassen wir wieder die betriebswirtschaftliche Ecke und wenden uns dem Alltag eines ITSystemverantwortlichen zu. Eine unbestreitbare Tatsache ist, dass Manahmen zur Verbesserung
der Sicherheit eines IT-Systems hug mit einer Verschlechterung der Verwendbarkeit des Systems aus Benutzersicht einhergehen. Betrachten wir einige Beispiele.
Nicht nur aus Sicherheitsgrnden ist es fr Institutionen auf jeden Fall ratsam, alle PC-Systeme
mit hnlichen Funktionen zu standardisieren und eine einheitliche Systemkonguration zu verwenden, die durch die Benutzer nicht eigenstndig verndert werden kann. Das hat zur Folge,
dass vielleicht die eine oder andere Softwarekomponente, wie ein bestimmtes Email-Programm
oder ein spezieller Webbrowser, nicht zur Verfgung steht, die der Benutzer (vielleicht aus einer
frheren Ttigkeit, dem Studium oder von zu Hause) gewohnt ist.
In Institutionsnetzwerken knnen verschiedene Dienste eingeschrnkt oder abgeschaltet werden, beispielsweise die Nutzung des World Wide Web. Dies hat nicht nur, aber auch mit Sicherheitsfragen zu tun. Wenn ein Benutzer es gewohnt war, tglich von einer bestimmten Seite Informationen abzurufen und dies pltzlich nicht mehr mglich ist, empndet der Benutzer dies als
Zumutung. Einige werden vielleicht der Versuchung nicht widerstehen knnen, diese Manahmen (wie auch immer) zu umgehen, was fr die Sicherheit des Netzes mit sehr schwerwiegenden
Folgen verbunden sein kann. Insofern ist die Benutzerakzeptanz der Sicherheitsmanahmen fr
deren Erfolg sehr wichtig. Die Strkung des Bewusstseins fr IT-Sicherheit bei den Benutzern
und deren Sensibilisierung hinsichtlich mglicher Risiken durch fahrlssiges Verhalten, etwa
10
1 Einfhrung
durch Schulungen und hnliches, ist daher ein zentraler Punkt. Trotzdem sind viele Sicherheitsmanahmen mit einer unmittelbaren Einschrnkung der Benutzbarkeit des Systems verbunden.
1.6 Organisatorische Grundlagen der IT-Sicherheit

1.6.1 Rahmenbedingungen
Der Schwerpunkt dieses Buchs liegt auf technischen Aspekten von IT-Sicherheit. Im Folgenden
wollen wir in aller Krze auf die notwendigen organisatorischen und rechtlichen Rahmenbedingungen eingehen.
Die Gewhrleistung und Aufrechterhaltung der IT-Sicherheit in einer Institution ist eine Aufgabe, die nicht alleine durch Systemadministratoren und technisch Verantwortliche gemeistert
werden kann. IT-Sicherheit muss organisatorisch in der Institution verankert sein. Technische
Manahmen alleine reichen nicht aus. Smtliche Prozesse und Arbeitsablufe mssen auf mgliche IT-Sicherheitsrisiken hin durchleuchtet und gegebenenfalls gendert werden. Dazu ankierend mssen die Mitarbeiter der Institution ber die mglichen Konsequenzen bei vorstzlichen
oder fahrlssigen Gefhrdungen der IT-Sicherheit, etwa durch unachtsamen Umgang mit Passwrtern, aufgeklrt werden. Darber hinaus sind institutionsweit einheitliche Standards erforderlich, denn einem Angreifer gengt manchmal eine einzige Schwachstelle fr einen erfolgreichen
Angriff. Um dies alles konzertiert erreichen zu knnen, ist die Verankerung des Themas ITSicherheit in der Fhrung einer Institution notwendig. Wir werden am Ende des Buchs bei der
Betrachtung von Richtlinien fr die Praxis in Kapitel 16 auf dieses Thema zurckkommen.
1.6.2 IT-Sicherheit als Prozess

Die Schaffung einer sicheren IT-Infrastruktur ist kein singulres, einmaliges Ereignis. Ein Rechner, der gestern noch als sicher galt, kann heute bereits ein Risiko darstellen, beispielsweise da
eine neue Schwachstelle auf einer auf dem System installierten Softwarekomponente bekannt
wurde. Die Geschftsablufe einer Institution unterliegen einem stndigen Wandel, der ebenfalls nderungen der notwendigen Sicherheitsmanahmen implizieren kann. Das Gleiche gilt fr
die Installation neuer oder das Update oder die nderung bestehender Systeme. Daher ist eine
kontinuierliche berwachung und Weiterentwicklung der gesamten IT-Sicherheitsmanahmen
in einer Institution notwendig. Mit anderen Worten: IT-Sicherheit ist ein Prozess.
Ein einfaches Schema des Prozessablaufs ist in Abbildung 1.1 dargestellt. Der Prozess besteht
aus drei Schritten:
berwachung: Unter berwachung verstehen wir sowohl die technische also auch die
organisatorische berwachung der IT-Sicherheit. Dies schliet sowohl das Sammeln und
Auswerten von Daten ber den laufenden Betrieb der Systeme als auch die berwachung
und berprfung der Sicherheitsanforderungen ein, die sich mit der Zeit ebenfalls ndern
knnen.
Analyse und Design: Die bei der berwachung gesammelten Daten werden in dieser Phase
ausgewertet und analysiert. nderungen im Systemdesign bzw. ein neues Design knnen
11
Analyse /
Design
berwachung
Umsetzung
Abbildung 1.1: IT-Sicherheit als Prozess.
erforderlich sein, wenn die bestehenden Sicherheitsanforderungen durch das gegenwrtige

Design nicht eingehalten werden konnten oder wenn sich die Sicherheitsanforderungen
gendert haben.
Umsetzung: Das in der vorangegangenen Phase entwickelte Design wird durch technische
und/oder begleitende organisatorische Manahmen umgesetzt.
Es gibt viele andere Mglichkeiten, wie man den IT-Sicherheitsprozess denieren kann. So
knnten wir beispielsweise die hier vorgestellten drei Phasen auch noch weiter verfeinern und
in vier oder noch mehr Phasen zergliedern. Wir wollen uns hier bewusst auf dieses sehr einfach gehaltene Modell beschrnken, da unser Hauptaugenmerk nicht so sehr auf den konkreten
IT-Sicherheitsprozess gerichtet ist, sondern darauf abzielt, das Prinzip anhand dieser einfachen
Struktur darzustellen.
1.7 Rechtliche Grundlagen und Rahmenbedingungen in

Deutschland
Im Folgenden sollen kurz die wichtigsten rechtlichen Grundlagen fr IT-Sicherheit vorgestellt
werden. Wir prsentieren diese Rechtsgrundlagen nicht aus juristischer Sicht, sondern vor allen
Dingen, um zu unterstreichen, dass die Gewhrleistung und Sicherstellung der IT-Sicherheit in
einer Institution nicht nur aus den vorhin bereits betrachteten wirtschaftlichen berlegungen
notwendig, sondern auch rechtlich geboten und gefordert ist.
1.7.1 Bundesdatenschutzgesetz
Nach 1 regelt das Bundesdatenschutzgesetz [BDSG] die Erhebung, Verarbeitung und Nutzung
personenbezogener Daten durch ffentliche und nicht-ffentliche Institutionen. Zweck des Ge-
12
1 Einfhrung
setzes ist es, den Einzelnen davor zu schtzen, dass er durch den Umgang mit seinen personenbezogenen Daten in seinem Persnlichkeitsrecht beeintrchtigt wird. Personenbezogene Daten sind
laut 3 Abs. 1 Einzelangaben ber persnliche oder sachliche Verhltnisse einer bestimmbaren
natrlichen Person. Das Bundesdatenschutzgesetz zieht der Erhebung, Verarbeitung, Nutzung
und Weitergabe personenbezogener Daten enge Grenzen und legt fest, welche Rechte die Personen haben, um deren Daten es sich handelt. Aus unserem Kontext heraus ist 9 besonders
wichtig. Dort heit es: ffentliche und nicht-ffentliche Stellen, die selbst oder im Auftrag personenbezogene Daten erheben, verarbeiten oder nutzen, haben die technischen und organisatorischen Manahmen zu treffen, die erforderlich sind, um die Ausfhrung der Vorschriften dieses
Gesetzes, insbesondere die in der Anlage zu diesem Gesetz genannten Anforderungen zu gewhrleisten. In der in Satz 1 zu 9 genannten Anlage wird unter anderem die Verhinderung der
Nutzung der Datenverarbeitungssysteme durch Unbefugte gefordert. Wrtlich heit es: Werden
personenbezogene Daten automatisiert verarbeitet oder genutzt, ist die innerbehrdliche oder innerbetriebliche Organisation so zu gestalten, dass sie den besonderen Anforderungen des Datenschutzes gerecht wird. Dabei sind insbesondere Manahmen zu treffen, die je nach der Art der zu
schtzenden personenbezogenen Daten oder Datenkategorieren geeignet sind (...) zu verhindern,
dass Datenverarbeitungssysteme von Unbefugten genutzt werden knnen, (...) zu gewhrleisten,
dass die zur Benutzung eines Datenverarbeitungssystems Berechtigten ausschlielich auf die ihrer Zugriffsberechtigung unterliegenden Daten zugreifen knnen, und dass personenbezogene
Daten bei der Verarbeitung, Nutzung und nach der Speicherung nicht unbefugt gelesen, kopiert,
verndert oder entfernt werden knnen, (...) zu gewhrleisten, dass personenbezogene Daten bei
der elektronischen bertragung oder whrend ihres Transports oder ihrer Speicherung auf Datentrger nicht unbefugt gelesen, kopiert, verndert oder entfernt werden knnen (...).
Da mehr oder weniger jede Institution personenbezogene Daten verarbeitet, angefangen von
den Personaldaten der Mitarbeiter bis hin zu Kundendaten, ergibt sich aus diesem Gesetz eine
wichtige Verpichtung, die IT-Infrastruktur so zu gestalten, dass die Sicherheit der Daten gewhrleistet ist.
1.7.2 Telekommunikationsgesetz
Neben dem Bundesdatenschutzgesetz gibt es besondere Vorschriften fr Telekommunikationsanbieter, die im Telekommunikationsgesetz [TKG] festgehalten sind. Telekommunikationsdienste
wie Telefonie werden in zunehmendem Ma nicht mehr ber separate Netzwerke angeboten,
sondern gemeinsam mit Datendiensten ber ein Netzwerk abgewickelt. Dabei hat sich als Technologieplattform die aus den Datendiensten kommende Netzwerkinfrastruktur auf Basis des IPProtokolls durchgesetzt, bekannt unter dem Stichwort Voice over IP (VoIP) (siehe Kapitel 14).
Fr solche Dienste gilt das Telekommunikationsgesetz genauso wie fr klassische Netzwerkstrukturen.
Der Gesetzgeber weist Telekommunikationsdiensten einen besonderen Status zu. 88 des Telekommunikationsgesetzes beinhaltet das Fernmeldegeheimnis. Nach 88 Abs. 1 des Gesetzes
unterliegen dem Fernmeldegeheimnis der Inhalt der Telekommunikation und ihre nheren Umstnde, insbesondere die Tatsache, ob jemand an einem Telekommunikationsvorgang beteiligt
ist oder war. Das Fernmeldegeheimnis erstreckt sich auch auf die nheren Umstnde erfolgloser
Verbindungsversuche. 88 Abs. 2 verpichtet die Diensteanbieter zur Wahrung des Fernmel-
13
degeheimnisses. Es ist den Anbietern nach Abs. 3 insbesondere untersagt, sich oder anderen
ber das fr die geschftsmige Erbringung der Telekommunikationsdienste einschlielich des
Schutzes ihrer technischen Systeme erforderliche Ma hinaus Kenntnis vom Inhalt oder den
nheren Umstnden der Telekommunikation zu verschaffen. Im Gesetz nden sich darber hinaus noch weitere Vorschriften bezglich Datenschutz und vor allem auch der Speicherung von
Verkehrsdaten (96). Dort ist festgelegt, dass der Diensteanbieter die Verkehrsdaten nach Beendigung der Verbindung unverzglich lschen muss, sofern sie nicht zur Entgeltermittlung (97),
der Erstellung eines Einzelverbindungsnachweises (99), der Ermittlung von Strungen oder
Missbrauch (100, 101) oder anderen gesetzlichen Vorschriften notwendig sind.
1.7.3 Telemediengesetz
Die meisten nicht durch das Telekommunikationsgesetz erfassten elektronischen Informationsund Kommunikationsdienste fallen in den Geltungsbereich des Telemediengesetzes [TMG]. Die
dortigen Regelungen in 13 Abs. 4 verpichten den Diensteanbieter unter anderem dazu, durch
technische und organisatorische Vorkehrungen sicherzustellen, dass der Nutzer Telemedien gegen Kenntnisnahme Dritter geschtzt in Anspruch nehmen kann.
Das Telemediengesetz beinhaltet in 14 Abs. 2 ein kontrovers diskutiertes Auskunftsrecht,
soweit dies fr Zwecke der Strafverfolgung, zur Erfllung der gesetzlichen Aufgaben der Verfassungsschutzbehrden des Bundes und der Lnder, des Bundesnachrichtendienstes oder des
Militrischen Abschirmdienstes oder zur Durchsetzung der Rechte am geistigen Eigentum erforderlich ist. Kontrovers hierbei ist der Auskunftsanspruch von nicht staatlichen Stellen im
Fall von Urheberrechtsverletzungen, die hinsichtlich des Auskunftsanspruchs auf eine Stufe mit
Strafverfolgungsbehrden und Nachrichtendiensten gesetzt wurden.
1.7.4 Handelsgesetzbuch
Das Handelsgesetzbuch [HGB] verpichtet Unternehmen zur Fhrung von Handelsbchern und
erlaubt dabei ausdrcklich das Fhren von Handelsbchern auf Datentrgern. Nach 239 Abs.
4 des HGB ist explizit gefordert, dass die Verfgbarkeit dieser Informationen sichergestellt werden muss: Bei der Fhrung der Handelsbcher und der sonst erforderlichen Aufzeichnungen
auf Datentrgern muss insbesondere sichergestellt sein, dass die Daten whrend der Dauer der
Aufbewahrungsfrist verfgbar sind und jederzeit innerhalb angemessener Frist lesbar gemacht
werden knnen.
1.7.5 Bundesamt fr Sicherheit in der Informationstechnik

Die Folgen mangelhafter IT-Sicherheit knnen unangenehm bis katastrophal sein und umfassende persnliche, wirtschaftliche oder rechtlich relevante Konsequenzen haben. Daher haben
sich auch die Regierungen und Gesetzgeber verschiedener Staaten dieser Fragen angenommen.
In Deutschland wurde 1990 eine spezielle Bundesbehrde, das Bundesamt fr Sicherheit in der
Informationstechnik (BSI) geschaffen. Die Aufgaben des BSI sind in 3 des BSI-Errichtungsgesetzes [BSIG] festgelegt. Sie lauten wrtlich zitiert wie folgt:
14
1 Einfhrung
1. Untersuchung von Sicherheitsrisiken bei Anwendung der Informationstechnik sowie Entwicklung von Sicherheitsvorkehrungen, insbesondere von informationstechnischen Verfahren und Gerten fr die Sicherheit in der Informationstechnik, soweit dies zur Erfllung
von Aufgaben des Bundes erforderlich ist,
2. Entwicklung von Kriterien, Verfahren und Werkzeugen fr die Prfung und Bewertung der
Sicherheit von informationstechnischen Systemen oder Komponenten,
3. Prfung und Bewertung der Sicherheit von informationstechnischen Systemen oder Komponenten und Erteilung von Sicherheitszertikaten,
4. Zulassung von informationstechnischen Systemen oder Komponenten, die fr die Verarbeitung oder bertragung amtlich geheimgehaltener Informationen (Verschlusachen) im
Bereich des Bundes oder bei Unternehmen im Rahmen von Auftrgen des Bundes eingesetzt werden sollen, sowie die Herstellung von Schlsseldaten, die fr den Betrieb zugelassener Verschlsselungsgerte bentigt werden,
5. Untersttzung der fr Sicherheit in der Informationstechnik zustndigen Stellen des Bundes, insbesondere soweit sie Beratungs- oder Kontrollaufgaben wahrnehmen; dies gilt vorrangig fr den Bundesbeauftragten fr den Datenschutz, dessen Untersttzung im Rahmen
der Unabhngigkeit erfolgt, die ihm bei der Erfllung seiner Aufgaben nach dem Bundesdatenschutzgesetz zusteht,
6. Untersttzung a) der Polizeien und Strafverfolgungsbehrden bei der Wahrnehmung ihrer gesetzlichen Aufgaben, b) der Verfassungsschutzbehrden bei der Auswertung und
Bewertung von Informationen, die bei der Beobachtung terroristischer Bestrebungen oder
nachrichtendienstlicher Ttigkeiten im Rahmen der gesetzlichen Befugnisse nach den Verfassungsschutzgesetzen des Bundes und der Lnder anfallen. Die Untersttzung darf nur
gewhrt werden, soweit sie erforderlich ist, um Ttigkeiten zu verhindern oder zu erforschen, die gegen die Sicherheit in der Informationstechnik gerichtet sind oder unter Nutzung der Informationstechnik erfolgen. Die Untersttzungsersuchen sind durch das Bundesamt aktenkundig zu machen,
7. Beratung der Hersteller, Vertreiber und Anwender in Fragen der Sicherheit in der Informationstechnik unter Bercksichtigung der mglichen Folgen fehlender oder unzureichender
Sicherheitsvorkehrungen.
Das BSI hat eine ganze Reihe von Publikationen im Sicherheitsbereich herausgegeben. Besonders erwhnenswert hierbei sind die Aktivitten im Bereich des IT-Grundschutzes, auf den
wir in Abschnitt 16.2 genauer eingehen werden.
Durch seinen Status als Bundesbehrde und den oben wiedergegebenen Auftrag, bestimmte
staatliche Stellen wie Polizeien und Verfassungsschutzbehrden bei ihren gesetzlichen Aufgaben zu untersttzen, kann das BSI zumindest formal nicht als unabhngige Beratungsinstanz
angesehen werden. Daher bleibt abzuwarten, inwieweit das BSI von Herstellern, Vertreibern und
Anwendern letztlich tatschlich als uneingeschrnkt vertrauenswrdiges Kompetenzzentrum angesehen und akzeptiert wird.
1.9 bungsaufgaben
15
Besonders deutlich wird dies bei Themen wie der kontrovers diskutierten Online-Durchsuchung von Rechnern durch staatliche Stellen. Letztlich handelt es sich dabei um das vorstzliche
Schaffen von Sicherheitslcken auf einem System, die dann bei einer Online-Durchsuchung ausgenutzt werden. Im Gegensatz zu einer richtigen Durchsuchung ndet die Online-Durchsuchung
heimlich ohne Wissen der Betroffenen statt und hnelt eigentlich eher einem staatlich legalisierten Hackerangriff. Fr die in den Systemen geschaffenen Hintertren drften sich frher oder
spter auch die Geheimdienste anderer Lnder und Kriminelle interessieren. Vom BSI als Bundesbehrde wird man kaum erwarten drfen, dass es Benutzern Hinweise darauf geben wird,
wie man solche Schwachstellen schlieen kann. hnlich kritische Fragen stellen sich auch in
anderen Bereichen, beispielsweise bei anonymisiertem Zugriff auf Netzwerke.
1.8 Zusammenfassung
Unter IT-Sicherheit verstehen wir den Schutz von Informationen und Informationssystemen gegen unbefugte Zugriffe und Manipulationen und die Sicherstellung der
Verfgbarkeit der durch die Systeme bereitgestellten Dienste fr legitime Benutzer.
Die wichtigsten Ziele von IT-Sicherheit sind Vertraulichkeit, Integritt, Verfgbarkeit, Authentizitt, Authentikation, Verbindlichkeit und Autorisation. Das vorstzliche Aushebeln von IT-Sicherheitsmechanismen bezeichnen wir als Angriff. Dabei
wird zwischen aktiven Angriffen, bei denen der Angreifer selbst ins Geschehen eingreift, und passiven Angriffen, etwa durch Mithren, unterschieden. Schwachstellen,
die Angriffe ermglichen, knnen in jeder Phase des Entwicklungsprozesses eines
Systems auftreten. Die Ziele eines Angriffs knnen sehr unterschiedlich sein. Dabei
treten zunehmend auch kriminelle Motive auf. Manahmen zur Verbesserung der ITSicherheit werden in der Praxis hug nach wirtschaftlichen Kriterien beurteilt. Um
die IT-Sicherheit langfristig aufrecht erhalten zu knnen, muss sie als Prozess in der
Institution verankert sein. Unternehmen und andere Institutionen sind durch gesetzliche Vorschriften dazu verpichtet, organisatorische und administrative Manahmen
zur Sicherung der IT-Strukturen zu ergreifen, beispielsweise durch das Datenschutzgesetz.
1.9 bungsaufgaben
1.9.1 Wiederholungsaufgaben
Aufgabe 1.1:
Denieren Sie den Begriff IT-Sicherheit.
Aufgabe 1.2:
Beschreiben Sie die Ziele von IT-Sicherheit. Erklren Sie die verwendeten Begriffe und geben
Sie jeweils ein Beispiel.
16
1 Einfhrung
Aufgabe 1.3:
Erlutern Sie mgliche Angriffe auf die IT-Sicherheit.
Aufgabe 1.4:
Denieren Sie den Begriff Schwachstelle. Nennen Sie Phasen des Entwicklungsprozesses eines Systems, in der Schwachstellen entstehen knnen und geben Sie jeweils ein Beispiel.
Aufgabe 1.5:
Ein Unternehmen betreibt eine Firewall, fr die gerade eine Schwachstelle bekannt wurde. Es
besteht die Mglichkeit, die Schwachstelle sofort zu schlieen, was mit Kosten in Hhe von
19.000 Euro fr einen externen Berater verbunden wre. In einem Monat wird ein Patch des Herstellers der Firewall verfgbar sein, durch den die Schwachstelle ebenfalls beseitigt wird. Die
IT-Abteilung rechnet damit, dass im Fall eines Ausnutzens der Schwachstelle ein Schaden in
Hhe von 200.000 Euro entstehen wrde. Die Wahrscheinlichkeit dafr, dass die Schwachstelle
innerhalb eines Monats fr einen Angriff genutzt wird, betrage p. Geben Sie an, welche Alternative in Abhngigkeit von p zu whlen ist, um die erwarteten Kosten zu minimieren, und geben
Sie die erwarteten Kosten an.
Aufgabe 1.6:
Nennen und beschreiben Sie die einzelnen Schritte des beschriebenen IT-Sicherheitsprozesses.
Aufgabe 1.7:
Beschreiben Sie kurz die rechtlichen Rahmenbedingungen fr IT-Sicherheit in Deutschland.
1.9.2 Weiterfhrende Aufgaben

Aufgabe 1.8:
Lesen Sie das Bundesdatenschutzgesetz [BDSG] und erlutern Sie die gesetzlich festgelegten
Aufgaben und Befugnisse des Beauftragten fr den Datenschutz in einer Institution und des
Bundesbeauftragten fr den Datenschutz und die Informationsfreiheit.
Kapitel 2
2Kryptographische
Kryptographische Prinzipien und Methoden
Prinzipien und
Methoden
2.1 Grundlagen
2.1.1 Denition
Unter dem Begriff Kryptographie versteht man klassischerweise das Verschlsseln von Nachrichten in einen Geheimcode und das Entschlsseln des Geheimcodes in die ursprngliche Nachricht. Wird eine Nachricht verschlsselt bertragen, so kann sie nur vom gewnschten Empfnger, nicht aber von dritten Personen entschlsselt werden, zumindest dann, wenn das verwendete
kryptographische Verfahren wirklich funktioniert. Heute wird die Denition von Kryptographie
oftmals auch etwas weiter gefasst und bezieht generell alle Verfahren mit ein, die mit Aspekten
der Sicherheit von Informationen verbunden sind, also neben Vertraulichkeit insbesondere auch
Datenintegritt, Nichtabstreitbarkeit und Authentikation von Daten und Kommunikationspartnern (siehe [MOV97]).
Kryptographische Verfahren, um Informationen vor unbefugtem Zugriff zu schtzen, gibt es
schon sehr lange. So wird von Julius Caesar (100-44 v. Chr.) berichtet, er habe die Kommunikation mit seinen Generlen verschlsselt durchgefhrt (siehe bungsaufgabe in Abschnitt 2.6.2).
Wahrscheinlich genauso alt wie kryptographische Verfahren zur Verschlsselung und Entschlsselung von Information sind die Versuche, solche Verfahren zu berlisten und die Geheimcodes
zu brechen, die sogenannte Kryptanalysis. Kryptographie und Kryptanalysis werden unter dem
Begriff Kryptologie zusammengefasst. Dies ist in Abbildung 2.1 dargestellt.
Die Kryptologie hat sich von ihren Anfngen bis heute von einer Kunst in eine mathematische Disziplin verwandelt, und sie ist in vielen Bereichen ein unverzichtbares Hilfsmittel, um
IT-Sicherheit in der Praxis zu realisieren. Wir werden hier die grundlegenden Prinzipien und
Methoden der Kryptographie erlutern, ohne auf die Mathematik hinter den Kulissen nher einKryptologie
Kryptographie
Kryptanalysis
Abbildung 2.1: Beziehungen zwischen Kryptologie, Kryptographie und Kryptanalysis.
18
2 Kryptographische Prinzipien und Methoden
zugehen. Damit sind wir in der Lage, die praktische Benutzung kryptographischer Methoden und
Verfahren zu verstehen und sie anzuwenden. Ein guter Koch ist auf feinste Produkte angewiesen,
die er dann zu einem wohlschmeckenden Gericht veredelt. Trotzdem muss er (in den meisten
Fllen) nicht wissen, warum die Produkte so schmecken, wie sie schmecken, oder wie man sie
herstellt. Ganz analog ist es fr einen IT-Sicherheitsexperten (sofern er sich nicht auf Kryptologie
spezialisiert hat) in den meisten Fllen nicht notwendig, die Mathematik hinter den kryptographischen Verfahren zu kennen. Wohl aber ist er auf funktionierende kryptographische Verfahren
angewiesen. Deshalb muss er wissen, welche Prinzipien ihnen zugrunde liegen und wie man sie
einsetzen kann. Dies wollen wir in diesem Kapitel in aller Krze darstellen.
Wer mehr Details ber kryptographische Verfahren erfahren mchte oder an den mathematischen Grundlagen der Kryptologie nher interessiert ist, dem seien die Bcher [Sch06], [Sti02]
oder [MOV97] empfohlen. Sie bieten auch fr Nicht-Mathematiker eine anschauliche und verstndliche Einfhrung.
Abschlieend noch einige Worte der Warnung: Kryptographische Verfahren sind in vielerlei,
nicht nur in mathematischer Hinsicht ausgeklgelte Konstrukte, die aber im Vergleich zu anderen Techniken nicht besonders robust gegenber nderungen sind. Die Modikation scheinbar
kleiner Details oder geringfgige Abweichungen in der Reihenfolge knnen schwerwiegende
Konsequenzen haben und sichere Verfahren unsicher machen oder vollstndig kompromittieren.
Das ist insbesondere auch dann zu beachten, wenn kryptographische Verfahren implementiert
werden sollen.
2.1.2 Modell
Wenden wir uns zunchst den grundlegendsten kryptographischen Funktionen, nmlich Verschlsselung und Entschlsselung, zu. Wie bereits erwhnt ist es das Ziel, Nachrichten in einen
Geheimcode zu verwandeln, der beispielsweise bei der bertragung ber ein unsicheres Kommunikationsmedium nur vom gewnschten Empfnger, nicht aber von dritten Personen entschlsselt werden kann. Wie die Begriffe Verschlsselung und Entschlsselung bereits vermuten
lassen, basieren die meisten modernen kryptographischen Methoden auf der Verwendung sogenannter Schlssel zum Ver- und Entschlsseln der Nachricht. Bei der Verschlsselung wird
die unverschlsselte Nachricht, der sogenannten Klartext, mittels eines Chiffrierverfahrens in
eine verschlsselte Nachricht, den sogenannten Chiffretext, umgewandelt. Genaugenommen ist
das Chiffrierverfahren ein Algorithmus, der als Eingabe den Klartext und den Chiffrierschlssel
bentigt und als Ausgabe den Chiffretext produziert. Analog wird bei der Entschlsselung der
Chiffretext mittels eines Dechiffrierverfahrens wieder in den Klartext zurckwerwandelt. Auch
das Dechiffrierverfahren ist ein Algorithmus, der als Eingabe den Chiffretext und den Dechiffrierschlssel bentigt. Ausgabe des Dechiffrierverfahrens ist dann wieder der Klartext. Diese
Zusammenhnge sind in Abbildung 2.2 veranschaulicht.
Begriffe wie Text und Schlssel sind natrlich nicht wrtlich zu nehmen. Eingabe und
Schlssel in modernen kryptographischen Verfahren bestehen aus Binrdaten, also Bits und Bytes. Mit solchen Verfahren knnen Programme genauso geschtzt werden wie Textdateien oder
digitalisierte Sprach- und Videodaten.
Ein unbefugter Dritter, der zufllig oder absichtlich in den Besitz des Chiffretextes gelangt, soll
nicht in der Lage sein, diesen wieder in den ursprnglichen Klartext zurckbersetzen zu kn-
2.1 Grundlagen
19
Chiffrierschlssel
Klartext
Chiffrierverfahren
Verschlsselung
Dechiffrierschlssel
Chiffretext
Chiffretext
Dechiffrierverfahren
Klartext
Entschlsselung
Abbildung 2.2: Einfaches Modell.
nen. Wenn er neben dem Chiffretext auch das Dechiffrierverfahren und den Dechiffrierschlssel
kennt, kann er problemlos das Dechiffrierverfahren anwenden und so den Chiffretext wieder in
den Klartext bersetzen. Entsprechend mssen entweder das Dechiffrierverfahren oder der Dechiffrierschlssel oder aber beides geheim sein.
Auf den ersten Blick knnte man annehmen, dass die grtmgliche Sicherheit erreicht wird,
wenn sowohl der Dechiffrieralgorithmus als auch der Dechiffrierschlssel geheimgehalten werden. In der Anfangszeit der Kryptographie waren tatschlich meistens sowohl Verfahren als auch
Schlssel geheim. Einige Methoden verwendeten sogar berhaupt keinen Schlssel, d.h. die Sicherheit des Verfahrens basierte ausschlielich auf dessen Geheimhaltung. Mittlerweile haben
sich aus einer ganzen Reihe von Grnden Methoden durchgesetzt, bei denen die Verfahren zur
Ver- und Entschlsselung nicht geheimgehalten, sondern ffentlich gemacht werden, und nur die
Schlssel (oder zumindest der Dechiffrierschlssel) geheim sind.
Dieses Vorgehen ist bei genauerer berlegung einsichtig und hat sich auch in anderen Bereichen der IT-Sicherheit, etwa bei Sicherheitsprotokollen, durchgesetzt. Wenn ein Verfahren
verffentlicht ist, beschftigen sich viele rechtschaffene Kryptologen damit, die Sicherheit des
Verfahrens zu analysieren und Schwachstellen zu nden. Ihre Zielsetzung besteht dabei aber
nicht darin, diese Schwachstellen in unlauterer Absicht auszunutzen, sondern sie untersuchen es
aus rein wissenschaftlichem Interesse. Entdeckte Schwachstellen wrden sie sofort bekanntgeben und verffentlichen, so dass die Verfahren repariert oder schlimmstenfalls aus dem Verkehr
gezogen werden knnten. Ein geheimgehaltenes Verfahren ist nicht ffentlich zugnglich und
der Versuch, das Verfahren nachzuvollziehen, erfordert gegebenenfalls sogar Manahmen, die
eventuell schon strafbar sein knnten. Konsequenterweise interessieren sich die rechtschaffenen Kryptologen nicht sonderlich fr diese Methoden. Dieses fehlende ffentliche Interesse verschafft Kryptanalysten mit unlauteren Absichten einen Vorteil, denn gefundene Schwachstellen
werden in der Regel wesentlich lnger unentdeckt bleiben, so dass ein Angreifer sie ber einen
greren Zeitraum hinweg ausnutzen kann. Daher ist dieses auch als Security through Obscurity
bekannte Konzept fragwrdig.
Zudem ist es ausgesprochen schwierig, ein Verfahren geheimzuhalten. Die Designer, die Implementierer und eine Zahl weiterer Personen kennen notwendigerweise das Verfahren. Eine einzige Schwachstelle in diesem Personenkreis reicht aus, um interessierten Dritten Informationen
ber das Verfahren zu liefern. Daher sollte unabhngig davon, ob man das Verfahren tatschlich
verffentlicht oder nicht, die Sicherheit eines kryptographischen Verfahren nicht von der Ge-
20
heimhaltung des Verfahrens abhngig sein, sondern ausschlielich auf der Geheimhaltung der
Schlssel basieren. Dies ist das sogenannte Kerckhoffsches Prinzip. Es ist benannt nach dem niederlndischen Mathematiker Ausguste Kerckhoffs (1835-1903), der diese Anforderung als erster
formuliert hat.
Im Folgenden werden wir uns ausschlielich mit Verfahren beschftigen, bei denen Chiffrierund Dechiffrierverfahren ffentlich sind und der Dechiffrierschlssel geheim ist.
Chiffrierverfahren lassen sich hinsichtlich verschiedener Kriterien klassizieren. Dabei gibt
zwei fundamental verschiedene kryptographische Vorgehensweisen, die sich hinsichtlich der
verwendeten Chiffrier- und Dechiffrierschlssel unterscheiden. Wenn die verwendeten Schlssel gleich sind, spricht man von einem symmetrischen Verfahren. Wird zur Verschlsselung ein
Schlsselpaar mit zwei unterschiedlichen Schlsseln zum Ver- und Entschlsseln verwendet,
handelt es sich um ein asymmetrisches Verfahren, meistens Public-Key-Verfahren genannt. In
der Praxis werden hug Verfahren verwendet, die Public-Key- und symmetrische Kryptographie kombinieren, sogenannte hybride Verschlsselungsverfahren. Wir werden diese Verfahren
gleich genauer betrachten.
2.2 Verschlsselungsverfahren
2.2.1 Vom Klartext zum Chiffretext
Die klassische Kryptographie operierte auf den Buchstaben des Alphabets und verwendete zur
Verschlsselung zwei prinzipielle Operationen, nmlich Substitution und Transposition. Substitution und Transposition knnen auch mehrfach und gemeinsam angewendet werden.
Bei der Substitution werden Symbole oder Gruppen von Symbolen durch Symbole oder Gruppen von Symbolen ersetzt (also substituiert), wobei die Reihenfolge der Symbole oder Gruppen
von Symbolen beibehalten wird. Bei der Transposition bleiben die Symbole unverndert, werden
aber umgeordnet und in eine andere Reihenfolge gebracht.
Ein einfaches Beispiel fr eine Substitution ist die sogenannte monoalphabetische Substitution, bei der jedes Symbol des Alphabets durch ein anderes Symbol ersetzt wird. Beispielsweise
wird durch folgende Tabelle
Symbol
Code
A
F
B
Q
C
P
D
B
E
E
F
H
G
O
H
A
I
W
Symbol
Code
R
M
S
Y
T
Z
U
T
V
R
W
N
X
S
Y
I
Z
C
J
K
K
G
L
J
M
V
N
D
O
X
P
L
Q
U
eine monoalphabetische Substitution deniert, in der das Wort DONAUDAMPFSCHIFFAHRT

in das Wort BXDFTBFVLHYPAWHHFAMZ berfhrt wird. Jedes Symbol des ursprnglichen
Wortes des Klartexts wird durch das in der Tabelle angegebene Codesymbol ersetzt.
Ein einfaches Transpositionsverfahren ist es, einen Text zeilenweise in eine Matrix einzutragen
und dann spaltenweise auszulesen, wobei die Reihenfolge der Spalten durch einen Schlssel
vorgegeben ist. So knnte etwa die Nachricht DIES IST EIN EINFACHES BEISPIEL FUER
EINE TRANSPOSITION in eine achtspaltige Matrix eingetragen werden:
21
D
I
H
I
I
P
I
N
E
E
N
O
E
E
S
L
E
S
S
I
B
F
T
I
I
N
E
U
R
T
S
F
I
E
A
I
T
A
S
R
N
O
E
C
P
E
S
N
Der Schlssel gibt an, in welcher Reihenfolge die Spalten nun ausgelesen werden. So wird in
diesem Beispiel die fnfte Spalte (INEURT) zuerst ausgelesen, die erste Spalte (DIHIIP) als
zweites und so weiter. Damit ergibt sich insgesamt als Chiffretext INEURT DIHIIP TASRNO
SFIEAI SIBFTI ECPESN INEENO EESLES.
Transposition und Substitution lassen sich ebenfalls kombinieren (auch Produktchiffre genannt) und mehrfach hintereinander anwenden, so knnte etwa auf den eben aus der Transposition erhaltenen Chiffretext die Substitution aus dem vorangegangenen Beispiel angewendet
werden.
Im Prinzip bilden diese beiden Vorgehensweisen gemeinsam mit einigen anderen Operationen
auch die Basis moderner kryptographischer Verfahren. Dabei operieren sie natrlich nicht mehr
auf der Basis von Buchstaben, sondern auf Bits und Bytes.
2.2.2 Sicherheit von Verschlsselungsverfahren

2.2.2.1 Kryptanalysis
Wenn das Dechiffrierverfahren allgemein bekannt ist, muss der Dechiffrierschlssel geheim bleiben, um die Vertraulichkeit der Nachricht zu gewhrleisten.
Ein wesentlicher Aspekt hierbei ist die Anzahl aller mglichen Dechiffrierschlssel, also die
Gre des sogenannten Schlsselraums. Wenn die Zahl mglicher Schlssel beschrnkt ist (d.h.
endlich und klein im Verhltnis zum Chiffretext), dann kann ein Kryptanalyst einfach alle mglichen Schlssel durchprobieren, bis er den richtigen gefunden hat. Wendet man das Dechiffrierverfahren auf den Chiffretext mit einem falschen Dechiffrierschlssel an, so ist das Resultat mit
an Sicherheit grenzender Wahrscheinlichkeit Buchstabensalat. Sobald man also einen Schlssel gefunden hat, der etwas Sinnvolles erzeugt hat (und wei, was sinnvoll ist), kann man
sehr sicher sein, den richtigen Schlssel gefunden zu haben und damit auch in den Besitz des
ursprnglichen Klartextes gelangt zu sein. Diesen Ansatz bezeichnet man auch als Brute-ForceAngriff. Eine so stupide Aufgabe wie alle mglichen Dechiffrierschlssel durchzuprobieren, kann
man natrlich besonders efzient mit einem Computer durchfhren.
Bei endlichem Schlsselraum und ffentlich bekanntem Dechiffrierverfahren kann man einen
solchen Angriff nicht prinzipiell verhindern. Man kann aber durch die Verwendung eines ausreichend groen endlichen Schlsselraumes dafr sorgen, dass man selbst bei der Verwendung eines
auerordentlich leistungsstarken Rechners zum automatisierten Durchtesten der Schlssel auf
das Resultat sehr lange warten muss, lnger noch als Fook und Lunkwill auf die Antwort auf das
Leben, das Universum und Alles . Nehmen wir an, wir verwendeten ein kryptographisches Ver Douglas
Adams, Per Anhalter durch die Galaxis, Heyne Verlag
22
fahren mit binren Schlsseln, wobei jeder Schlssel des Schlsselraums auch tatschlich zum
Einsatz kommen kann. Hat der binre Schlssel eine Lnge von n Bit, so gibt es dann insgesamt
2n mgliche Schlssel. Bei jedem zustzlichen Bit verdoppelt sich also die Gre des Schlsselraumes. Nehmen wir weiter an, dass ein schneller Rechner derzeit eine Million (1.000.000)
Schlssel pro Sekunde testen kann. Dieser schnelle Rechner bentigt dann zum Durchtesten aller
Schlssel folgende Zeiten:
Binrschlsselgre
Schlsselraumgre
Zeit zum Durchtesten aller Schlssel
16 Bit
32 Bit
64 Bit
128 Bit
256 Bit
65536 6, 6 104
4294967296 4, 3 109
1, 8 1019
3, 4 1038
1, 2 1077
0,07 Sekunden
72 Minuten
584942 Jahre
1, 1 1025 Jahre
3, 7 1063 Jahre
n Bit
2n
2n /(3, 1536 1013 ) Jahre
Bei diesen Zahlen hilft es auch nicht viel, dass man rein mathematisch gesehen erwarten kann,
bereits nach dem Durchtesten der Hlfte aller Schlssel den richtigen gefunden zu haben, sich
also im Mittel die Suchzeit halbiert.
Zum Vergleich: Nach dem derzeitigen wissenschaftlichen Erkenntnisstand ist unser Universum vor ca. 13,7 Milliarden Jahren (= 13, 7 109 Jahre) entstanden und die Erde ungefhr 4,6
Milliarden Jahre (= 4, 6 109 Jahre) alt. Htte der schnelle Rechner seit der Entstehung des Universums mgliche Schlssel eines Schlsselraums der Gre 128 Bit ohne Pause durchprobiert,
so wre dies trotzdem nur ein verschwindend kleiner Bruchteil aller mglichen Schlssel. Bei
Schlsselgren von 128 Bit und mehr sind Brute-Force-Angriffe nach dem derzeitigen Stand
der Technik also praktisch unmglich.
Durch die Leistungsexplosion der zur Verfgung stehenden Computer hat sich allerdings die
Antwort auf die Frage, wie gro ein Schlsselraum denn nun praktisch tatschlich sein muss, um
Brute-Force-Angriffe effektiv zu unterbinden, im Lauf der Zeit bereits gendert und zu greren
Schlsselrumen hin verschoben. Whrend 64-Bit-Schlssel vor einigen Jahrzehnten noch als
sicher galten, erscheinen Brute-Force-Attacken auf Schlsselrume dieser Gre mittlerweile
nicht mehr unrealistisch.
Da jedes zustzliche Bit eines Binrschlssels eine Verdoppelung der Schlsselraumgre
bedeutet, werden selbst bei einer weiteren kontinuierlichen Leistungssteigerung der zur Verfgung stehenden Rechner Schlsselrume mit 2128 oder 2256 Schlsseln noch fr lngere Zeit vor
Brute-Force-Attacken sicher sein.
Ein groer Schlsselraum ist also eine absolute Notwendigkeit, um Brute-Force-Angriffe auszuschlieen. Die Gre des Schlsselraums alleine ist aber nicht ausreichend, um die Sicherheit eines Verfahrens zu garantieren, denn es gibt weitaus subtilere Mglichkeiten, um ein Verschlsselungsverfahren zu brechen, als einfach alle Schlssel durchzuprobieren. Nehmen wir
als Beispiel die monoalphabetische Substitution aus Sektion 2.2.1. Es gibt insgesamt 26! =
403291461126605635584000000 4 1026 solcher Substitutionen. Bei einem Brute-Force-Angriff, bei dem 100 Millionen Mglichkeiten pro Sekunde getestet werden, wrde das Testen aller
Kombinationen 128 Milliarden Jahre dauern. Trotzdem nden sich monoalphabetische Substitu-
23
x
0
0
1
1
y
0
1
0
1
xy
0
1
1
0
Tabelle 2.1: Wertetabelle der XOR-Verknpfung.
tionen ab und an als Rtselaufgabe in der Zeitung, denn sie lassen sich mit etwas Nachdenken
recht einfach lsen.
In der deutschen Sprache treten nmlich wie in anderen natrlichen Sprachen auch die einzelnen Buchstaben mit unterschiedlichen Hugkeiten auf. Die am hugsten und am zweithugsten vorkommenden Buchstaben sind E und N. Da jedes E im Klartext durch das gleiche Symbol
im Chiffretext ersetzt wird, kann man die Hugkeit der Symbole im Chiffretext analysieren und
so auf die ursprnglichen Zeichen im Klartext schlieen. Dabei muss man zwar nicht unbedingt
immer richtig liegen, aber man kann sich auf diese Art schrittweise vortasten und wird relativ
schnell Wrter im Chiffretext richtig erraten und so sukzessive die Verschlsselung vollstndig
brechen knnen.
Dieser Angriff basiert also auf statistischen Merkmalen, die sich vom Klartext auf den Chiffretext bertragen haben. Er ist mglich, wenn dem Angreifer eine ausreichend groe Menge an
Chiffretext vorliegt (sogenannter Ciphertext-Only-Angriff). Noch bessere Mglichkeiten bieten
sich einem Angreifer natrlich dann, wenn er nicht nur den Chiffretext kennt, sondern neben
dem Chiffretext auch bereits einen Teil des Klartextes kennt (Known-Plaintext-Angriff) oder er
sich sogar einen Teil des Klartextes aussuchen konnte, der dann verschlsselt wurde (ChosenPlaintext-Angriff).
Es gibt noch eine ganze Reihe weiterer Angriffsmglichkeiten und -typen, die den Rahmen
dieser Darstellung sprengen wrden. Der Phantasie der Angreifer sind dabei natrlich keine
Grenzen gesetzt.
2.2.2.2 Ein absolut sicheres Verfahren
Es gibt tatschlich Verschlsselungsverfahren, die absolut sicher sind und bei denen es einem
Angreifer vollkommen unmglich ist, den Klartext aus dem Ciphertext herzuleiten, ohne den
Dechiffrierschlssel zu kennen. Ein solches Verfahren ist der sogenannte One-Time-Pad. Wechseln wir zur Illustration dieser Technik von Alphabetssymbolen zu binren Nachrichten. Sender
und Empfnger verfgen ber einen sehr langen Schlssel, den sogenannten One-Time-Pad, der
mindestens so lang ist wie die Nachricht selbst und aus einer zufllig gewhlten Folge von Nullen
und Einsen besteht. Die Verschlsselung erfolgt, indem die zu verschlsselnde Nachricht bitweise mit dem Schlssel XOR-verknpft wird. Die XOR-Verknpfung ist in Tabelle 2.1 dargestellt.
Dabei werden soviele Bits des Pad verbraucht, wie in der Nachricht enthalten sind. Diese verbrauchten Bits knnen nicht nochmals zur Verschlsselung verwendet werden. Betrachten wir
also die Klartextnachricht 0000 1011 und den One-Time-Pad 1011 1000 1010 0010 0001 0101
24
1000 1101 1010 1111. Bei der Verschlsselung werden die acht Bits der Nachricht mit den ersten
acht Bits des Pads jeweils XOR-verknpft. Damit ergibt sich
0
1
1
0
0
0
0
1
1
0
1
1
1
1
0
0
0
0
1
0
1
1
0
1
Klartext
Pad
Chiffretext
Der Chiffretext ist also 1011 0011. Da XOR selbstinvers ist, also a b b = a gilt, kann der
Empfnger den Chiffretext wiederum bitweise mit dem Schlssel verknpfen und erhlt so wieder den Klartext:
1
1
0
0
0
0
1
1
0
1
1
0
0
1
1
0
0
0
1
0
1
1
0
1
Chiffretext
Pad
Klartext
Die vom Schlssel zur Ver- und Entschlsselung verwendeten Symbole drfen nur ein einziges
Mal verwendet werden, die entsprechenden Symbole werden danach gelscht. Damit verbleiben
vom One-Time-Pad noch die Symbole 1010 0010 0001 0101 1000 1101 1010 1111, die zur
Verschlsselung weiterer Nachrichten verwendet werden knnen.
Es gibt fr einen Angreifer keinerlei Ansatzpunkte, wie er ohne den Schlssel, also ohne
Kenntnis des One-Time-Pads, dem Chiffretext den zugrundeliegenden Klartext entlocken kann.
Zu jedem Chiffretext und jedem Klartext gibt es einen One-Time-Pad, der diesen Klartext in den
entsprechenden Chiffretext berfhrt. Damit kann jeder Chiffretext in jeden Klartext berfhrt
werden. Der oben bertragene Chiffretext knnte also im Klartext jeder beliebigen acht-BitKombination entsprechen, dies ist exemplarisch fr 0000 0000 und 1111 1111 dargestellt.
1
0
1
0
1
1
1
0
1
1
0
1
0
1
1
0
1
1
1
0
1
1
0
1
Chiffretext
mglicher Pad
mglicher Klartext
1
1
0
0
0
0
1
1
0
1
1
0
0
0
0
0
0
0
1
1
0
1
1
0
Chiffretext
mglicher Pad
mglicher Klartext
Soweit die Theorie. In der Praxis sind One-Time-Pads nur sehr schwierig anwendbar. Da der
Schlssel so gro ist wie die zu bertragende Nachricht und nicht wiederverwendet werden kann,
eignet sich dieses Verfahren nicht fr Breitbandkommunikation. Auch ist die Frage, wie Sender
und Empfnger den Schlssel miteinander austauschen sollen, ohne dass Dritte in den Besitz des
Schlssels gelangen, nicht einfach zu lsen. Wenn man aber absolute Sicherheit bentigt, kommt
man um den One-Time-Pad nicht herum und muss diese Schwierigkeiten in Kauf nehmen.
Es gibt nur allerdings (fast) keine Anwendungen im IT-Bereich, fr die absolute Sicherheit
wirklich notwendig ist. In den allermeisten Fllen kommt man mit einem weitaus geringeren
Sicherheitsniveau aus. In der Regel ist ein Verfahren ausreichend, dessen Verschlsselung man
zwar prinzipiell brechen knnte, jedoch der zu erwartende wirtschaftliche Aufwand den Wert der
Information bersteigt und das Brechen der Verschlsselung erst zu einem Zeitpunkt zu erwarten
ist, zu dem die in der Nachricht enthaltene Information nicht mehr ntzlich ist.
25
Wenn eine Gruppe engagierter Kryptanalysten durch den Einsatz mehrerer Grorechner und
erheblicher nanzieller Mittel in 100 Jahren ihre verschlsselt bertragenen Kreditkarteninformationen geknackt hat, drfte Sie dies nicht mehr besonders stren.
Die in den kommenden Abschnitten vorgestellten Verfahren fallen allesamt in die Kategorie
nicht absolut sicher, aber eben ausreichend sicher zumindest hofft man das. Absolut sicher
sind die Verfahren schon deshalb nicht, da jedes Verfahren mit endlichem Schlsselraum prinzipiell ber Brute-Force angegriffen werden kann. Ob man aber eines oder mehrere der Verfahren
auch mit einfachem Aufwand aushebeln kann, ist nicht geklrt. Fr keines der im Folgenden
prsentierten Verfahren ist nachgewiesen worden, wie sicher es wirklich ist. Es ist daher nicht
auszuschlieen, dass eines dieser Verfahren pltzlich geknackt wird. Da dies jedoch trotz vieler
Versuche durch brillante Mathematiker bisher noch niemandem gelungen ist, besteht berechtigter
Anlass zur Hoffnung, dass dies auch noch lange so bleiben wird.

2.3.1 Grundlagen
Wie bereits erwhnt gibt es zwei fundamental verschiedene kryptographische Vorgehensweisen,
die sich hinsichtlich der verwendeten Chiffrier- und Dechiffrierschlssel unterscheiden, nmlich
symmetrische Verfahren und Public-Key-Verfahren:
Symmetrische Verfahren: Zur Ver- und Entschlsselung wird derselbe Schlssel verwendet, d.h. Chiffrier- und Dechiffrierschlssel sind gleich.
Public-Key-Verfahren: Zur Ver- und Entschlsselung wird ein Schlsselpaar bestehend aus
zwei verschiedenen Schlsseln, einem ffentlichen und einem privaten Schlssel verwendet, d.h. Chiffrier- und Dechiffrierschlssel sind nicht gleich. Mit dem ffentlichen Schlssel verschlsselte Nachrichten knnen nur mit dem privaten Schlssel wieder entschlsselt
werden.
Normalerweise werden bei Public-Key-Verfahren Nachrichten mit dem ffentlichen Schlssel
verschlsselt und dann mit dem privaten wieder entschlsselt. Die Bezeichnungen ffentlicher
und privater Schlssel erklren sich daraus, dass der ffentliche Schlssel bei solchen Verfahren
nicht geheimgehalten werden muss, sondern im Gegenteil jedem bekanntgegeben werden kann
und soll.
Bei vielen Public-Key-Verfahren funktioniert die Ver- und Entschlsselung auch bei umgekehrter Verwendung der Schlssel, also eine Nachricht kann mit dem privaten Schlssel verschlsselt und mit dem ffentlichen Schlssel entschlsselt werden. Diese Eigenschaft ermglicht den Einsatz solcher Verfahren zur Authentikation von Benutzern und Nachrichten. Wir
werden sie in Abschnitt 3.6 nher erlutern.
2.3.2 Symmetrische Verfahren

Beginnen wir zunchst mit einer Beschreibung symmetrischer Verfahren. Die in Sektion 2.2
vorgestellten Techniken waren allesamt symmetrisch, denn sie verwenden denselben Schlssel
zur Ver- und Entschlsselung.
26

Schlssel (Gre n)
Klartextblock
Chiffrierverfahren
(Gre m)
Chiffretext- Chiffretextblock
block
(Gre m)
Verschlsselung
(Gre m)
Klartextblock
(Gre m)
Entschlsselung
Abbildung 2.3: Symmetrische Kryptographie.
Die in der Informatik tatschlich eingesetzten symmetrischen Verfahren basieren hinsichtlich

der eigentlichen Ver- und Entschlsselung darauf, einen aus einer bestimmten Anzahl von Bits
bestehenden Klartextblock unter Verwendung des Schlssels in einen aus der gleichen Anzahl
von Bits bestehenden Chiffretextblock zu bersetzen, der mittels desselben Schlssels dann wieder in den Klartextblock dechiffriert werden kann. Dies ist in Abbildung 2.3 dargestellt. Nachrichten grerer Lnge oder einzelne Bits knnen durch diese Verfahren ebenfalls verschlsselt
werden. Das genaue Vorgehen dabei wird in Sektion 2.4 dargestellt.
Die Sicherheit eines symmetrischen Verfahrens hngt von vielen verschiedenen Faktoren ab,
unter anderem von der Blockgre und natrlich der Schlssellnge, die auf jeden Fall gro
genug sein muss, um Brute-Force-Attacken faktisch auszuschlieen.
In der Praxis werden heute vor allem zwei symmetrische Verfahren angewendet, nmlich der
Data Encryption Standard (im Folgenden DES) [FIPS 46-3] und der Advanced Encryption Standard (im Folgenden AES) [FIPS 197]. Beide Verfahren sind vom National Institute of Standards
and Technology (NIST), einer US-Behrde, standardisiert und verffentlicht worden. DES wurde
1977 als Standard verffentlicht. DES basiert auf einer Blockgre von 64 Bit und der Verwendung eines 64-Bit-Schlssels, von dem jedoch nur 56 Bit effektiv genutzt werden. Diese Schlsselgre galt sehr bald aufgrund der gestiegenen Rechenleistung als nicht mehr ausreichend. Mit
Triple-DES wurde ein Verfahren eingefhrt, das auf einer dreifachen DES-Verschlsselung mit
zwei Schlsseln basiert und damit eine effektive Schlssellnge von 112 Bit bietet.
2001 wurde AES als neues Verfahren von der NIST eingefhrt und seit 2004 wird empfohlen, DES nicht mehr einzusetzen. Im Prinzip kann der AES zugrundeliegende Algorithmus mit
verschiedenen Blockgren und Schlsselgren arbeiten, standardisiert wurden aber nur drei
Varianten mit einer einheitlichen Blockgre von 128 Bit und Schlsselgren von 128, 192
und 256 Bit. Diese Varianten werden mit AES-128, AES-192 und AES-256 bezeichnet. Einen
berblick gibt Tabelle 2.2.
Sowohl DES als auch AES mischen und verknpfen Eingabe und Schlssel und sind dabei so
konstruiert, dass man sie nicht nur in Software, sondern auch einfach in Hardware implementieren kann. Man kann also leicht einen Chip konstruieren, der die Ver- und Entschlsselungsoperation durchfhrt. Dies ist wichtig, da hierdurch Gerte mit kleinerer Rechenleistung wie etwa
Mobiltelefone oder Adapterkarten DES und AES ebenfalls einsetzen knnen.
27
Verfahren
DES
3-DES
AES-128
AES-192
AES-256
Schlssellnge
Blockgre
56 Bit
64 Bit
112 Bit
64 Bit
128 Bit
128 Bit
192 Bit
128 Bit
256 Bit
128 Bit
Tabelle 2.2: Wichtige symmetrische Verschlsselungsverfahren.
2.3.3 Public-Key-Verfahren
Um eine Verbindung zwischen zwei Kommunikationspartnern, sagen wir die zwischen einem
Online-Hndler und seinem Kunden, ber ein unsicheres Netzwerk wie das Internet mittels symmetrischer kryptographischer Verfahren abzusichern, mssen beide Partner im Besitz eines gemeinsamen geheimen Schlssels sein. Dieser Schlssel, hug auch Session Key genannt, ermglicht es, Nachrichten in beide Richtungen verschlsselt zu bertragen und auf der anderen
Seite wieder zu entschlsseln.
Es stellt sich allerdings die Frage, wie die Partner in den Besitz dieses gemeinsamen geheimen Schlssels gelangen sollen. ber das Netz darf der Schlssel nicht im Klartext bertragen
werden, denn da es unsicher ist, knnte die bertragung von einer dritten Person mit unlauteren
Absichten mitgehrt werden, die sich so Zugang zum Schlssel verschaffen knnte und somit
alle im Weiteren bertragenen Nachrichten ebenfalls entschlsseln knnte. Es ist das typische
Henne-Ei-Problem: Um einen sicheren, verschlsselten Kommunikationkanal aufbauen zu knnen, bentigen beide Kommunikationspartner einen gemeinsamen geheimen Schlssel, der aber
nur ber einen sicheren Kanal bertragen werden darf, den man erst zur Verfgung hat, wenn
beide Seiten ber den Schlssel verfgen.
Natrlich knnten der Online-Hndler und der Kunde den Schlssel auf einem anderen (sicheren) Weg bermitteln, etwa per Post, Fax oder noch besser: Jeweils Teile des Schlssels auf
verschiedenen Wegen, also die Hlfte des Schlssels ber Fax und die andere Hlfte per Post.
Fr einige Anwendungen ist ein solches Vorgehen sicherlich denkbar, aber aufgrund der hierfr
erforderlichen Zeit und des Aufwands wre dies fr sehr viele Anwendungen nicht praktikabel.
Erst 1976 entwickelten W. Dife und M. Hellman eine Lsung, die es den Kommunikationspartnern ermglicht, einen geheimen Schlssel ber einen unsicheren Kanal auszutauschen
[DH76], den sogenannten Dife-Hellman-Exchange. Diese Arbeit war die Geburtsstunde einer
Klasse grundlegend anderer kryptographischer Verfahren, der Public-Key-Kryptographie.
Moderne Public-Key-Verfahren verwenden zur Ver- und Entschlsselung ein Schlsselpaar
bestehend aus einem privaten und einem ffentlichen Schlssel. Mit dem ffentlichen Schlssel
verschlsselte Nachrichten knnen nur mit dem privaten Schlssel wieder entschlsselt werden.
Die Kenntnis des ffentlichen Schlssels erlaubt keine Rckschlsse auf den privaten Schlssel, der geheimgehalten werden muss und niemandem zugnglich gemacht werden darf. Der
ffentliche Schlssel kann also beliebig weitergegeben werden. Jeder kann damit Nachrichten
verschlsseln, aber nur mit dem zugehrigen privaten Schlssel, der geheim ist und an niemanden weitergegeben wird, lassen sie sich wieder entschlsseln. Da der ffentliche Schlssel nicht
geheim ist, kann er ohne Risiko ber einen unsicheren Kanal bertragen werden. Dies ist in
Abbildung 2.4 dargestellt.
28

Sender
Empfnger
h en
ffentlic
einen
s
S
t
k
E schic
se
Schls
S verw
en
zum Ve det ffentlich
en Sch
rschls
l
seln de
r Nach ssel von E
richt an
E
ffentlicher Schlssel
des Empfngers
Klartext
Chiffrierverfahren
Verschlsselung beim
Sender
Chiffretext
Privater Schlssel
des Empfngers
Chiffretext
Klartext
Entschlsselung beim
Empfnger
Abbildung 2.4: Public-Key-Kryptographie.
Somit ist der Schlsselaustausch bei Public-Key-Verfahren kein Problem: Der Online-Hndler
schickt an den Kunden seinen ffentlichen Schlssel. Mit diesem ffentlichen Schlssel kann der
Kunde nun Daten verschlsselt an den Hndler bertragen. Ein Angreifer, der die bertragung
des ffentlichen Schlssels mithrt, kann mit dem ffentlichen Schlssel den Chiffretext nicht
entschlsseln hierzu wrde er den privaten Schlssel des Online-Hndlers bentigen, den dieser aber geheimhlt. Das Schlsselpaar des Online-Hndlers kann nur dazu verwendet werden,
Nachrichten fr den Online-Hndler zu verschlsseln. Mchte der Hndler auch Nachrichten
an den Kunden verschlsselt mittels Public-Key-Kryptographie bertragen, so msste auch der
Kunde im Besitz eines eigenen Schlsselpaares sein und dem Online-Hndler seinen ffentlichen
Schlssel zur Verfgung stellen.
Public-Key-Kryptographie ist damit vergleichbar, jemandem ein geffnetes Schnappschlo zu
geben, welches man durch einfaches Zuklicken abschlieen kann: Die Person kann damit zwar
etwas abschlieen, das Schloss aber nicht wieder ffnen.
Mathematisch gesehen basieren Public-Key-Verfahren auf algorithmisch (zumindest bisher)
schwierig lsbaren Problemen wie diskreten Logarithmen, elliptischen Kurven oder der Faktorisierung von Zahlen. Der private und der ffentliche Schlssel bestehen beispielsweise aus
Zahlenpaaren mit bestimmten Eigenschaften. Da nicht alle Zahlenpaare gltige Schlssel sind
symmetrische
Verfahren
Public-KeyVerfahren
29
Vorteile
Nachteile
+ einfach in Hard- und Software

implementierbar
+ schnell
+ Schlsselaustauch kann ber
unsicheren Kanal erfolgen
- Schlsselaustausch erfordert
abhrsicheren Kanal
- rechenintensiv
- nicht einfach in Hardware umsetzbar
Tabelle 2.3: Vergleich symmetrischer Verfahren und Public-Key-Verfahren.
und ungltige Schlssel von einem Angreifer leicht aussortiert werden knnen, sind bei PublicKey-Verfahren hug deutlich lngere Schlssel zum Erreichen eines vergleichbaren Grades an
Sicherheit notwendig als bei symmetrischen Verfahren. Typische Gren reichen von 1024, 2048
bis zu hin zu 4096 Bit und mehr. Die Verschlsselung und Entschlsselung von Nachrichten ist
verglichen mit symmetrischen Verfahren sehr rechenintensiv und lsst sich nicht direkt in einen
Chip umsetzen.
Einige wichtige Public-Key-Verfahren sind
RSA: Verfahren, das auf der Faktorisierung groer Zahlen, speziell des Produkts zweier
Primzahlen basiert.
ElGamal: Basiert auf der Berechnung diskreter Logarithmen modulo einer Primzahl.
Elliptic Curves: Verwendet elliptische Kurven ber endlichen Krpern.
2.3.4 Hybride Verfahren

Bewertet man symmetrische und Public-Key-Verfahren ausschlielich im Hinblick darauf, mit
ihnen Nachrichten durch Verschlsselung sicher bertragen zu wollen, ist das Urteil eindeutig:
Symmetrische Verfahren sind hinsichtlich Implementierbarkeit, Aufwand und Verwendbarkeit
Public-Key-Verfahren vorzuziehen. Problematisch hingegen ist bei symmetrischen Verfahren der
Austausch des Schlssels (Session Key) zwischen den Kommunikationspartnern, der nur ber
einen sicheren Kanal erfolgen darf. Dies ist in Tabelle 2.3 nochmals dargestellt.
Es ist naheliegend, die Vorteile von symmetrischen und Public-Key-Verfahren gemeinsam zu
nutzen, um die Vorteile beider Methoden zu kombinieren. Hierbei wird zunchst ein Public-KeyVerfahren eingesetzt, um einen Session Key fr ein symmetrisches Verfahren auszutauschen, und
danach das symmetrische Verfahren verwendet. Diese Vorgehensweise wird auch als hybrides
Verfahren bezeichnet. Um dabei eine durch symmetrische Kryptographie gesicherte Verbindung
zwischen Teilnehmer A und Teilnehmer B zu erhalten, treten, wie in Abbildung 2.5 skizziert,
schematisch gesehen folgende Schritte auf:
1. A schickt B seinen ffentlichen Schlssel fr ein Public-Key-Verfahren (unverschlsselt).
30

Teilnehmer A
A schic
kt
Schlss B seinen ffe
n
el fr e
in Publi tlichen
c-Key-V
erfahre
Teilnehmer B
es
etrisch
elt
r symm
Key f sen verschlss
n
io
ss
gt Se
t die
B erzeu und bertrg ahren an A
ren
ey-Verf
Verfah
Public-K
mit dem
Verschlsselung durch symmetrisches

Verfahren mit Session Key als Schlssel
Abbildung 2.5: Schematischer Ablauf hybrider Verfahren.
2. B erzeugt einen (zuflligen) Session Key fr ein symmetrisches Verfahren und schickt
diesen Session Key verschlsselt durch das Public-Key-Verfahren mit dem in Schritt 1
erhaltenen ffentlichen Schlssel an A.
3. A entschlsselt die Nachricht mit seinem privaten Schlssel. Nun sind beide im Besitz
eines geheimen Session Keys fr das symmetrische Verfahren.
4. Beide verwenden das symmetrische Verfahren mit dem Session Key zur bertragung.
Bei hybriden Verfahren wird also Public-Key-Kryptographie nur dazu verwendet, einen Session Key fr ein symmetrisches Verfahren auszutauschen. Ein Angreifer, der diesen Informationsaustausch beobachtet, ist anschlieend nicht in der Lage, die Verschlsselung zu brechen,
da der Session Key verschlsselt bertragen wurde und dem Angreifer der zur Entschlsselung
notwendige private Schlssel von Teilnehmer A nicht zur Verfgung steht.
Um ein hybrides Verfahren zu verwenden, ist es nicht unbedingt notwendig, dass zwischen den
beiden Kommunikationspartnern mehrere Nachrichten ausgetauscht werden, sofern die ffentlichen Schlssel (oder zumindest einer) bereits bekannt sind. Wenn Teilnehmer B eine Nachricht
an Teilnehmer A schicken mchte und B den ffentlichen Schlssel von A bereits kennt, kann er
wie folgt vorgehen:
1. B erzeugt einen Schlssel fr ein symmetrisches kryptographisches Verfahren.
2. B verschlsselt die Nachricht mittels des symmetrischen Schlssels und des symmetrischen Verfahrens.
3. B verschlsselt den symmetrischen Schlssel durch das Public-Key-Verfahren mit dem
ffentlichen Schlssel von A.
4. B bertrgt den so verschlsselten symmetrischen Schlssel und die mit dem symmetrischen Schlssel chiffrierte Nachricht.
2.4 Betriebsarten
31
Klartextblock
Klartextblock
Klartextblock
S
C
Chiffretextblock
Nachricht
S
C
Chiffretextblock
Chiffretextblock
Verschlsselung
Chiffretext
...
Chiffretextblock
Chiffretextblock
S
D
Klartextblock
Chiffretextblock
S
D
Klartextblock
Entschlsselung
Klartextblock
Abbildung 2.6: Electronic Code Book. S bezeichnet den Schlssel, C steht fr Chiffrierverfahren und D fr
Dechiffrierverfahren.
Teilnehmer A kann dann die Nachricht wieder entschlsseln, indem er zunchst mittels seines
privaten Schlssels durch Anwendung des Public-Key-Verfahrens den symmetrischen Schlssel
aus der Nachricht extrahiert und dann das symmetrische Verfahren anwendet.
Dieses Verfahren kommt brigens tatschlich zum Einsatz, nmlich bei der hybriden Ver- und
Entschlsselung von Emails.
2.4 Betriebsarten
2.4.1 Electronic Code Book
Die symmetrischen kryptographischen Verfahren basieren darauf, einen Eingabeblock der Gre
m Bit unter Verwendung des Verschlsselungsverfahrens in einen Chiffretext der gleichen Gre
umzuwandeln. Natrlich sollen mit diesen Verfahren nicht nur Nachrichten der Gre m Bit, sondern auch Eingaben beliebiger Gre verschlsselt werden. Dies ermglichen die sogenannten
Betriebsarten fr (symmetrische) kryptographische Verfahren, auch als Cipher Modes bekannt.
Verschiedene Betriebsarten fr AES und DES, die auch fr andere Blockverfahren Verwendung
nden knnen, sind in [NIST 800-38A] speziziert.
Die naheliegendste Mglichkeit ist es, die Eingabe in Blcke der Gre m Bit aufzuteilen und
jeden dieser Blcke einzeln und unabhngig von den anderen Blcken der Nachricht mittels des
Verfahrens zu behandeln. Diese Betriebsart ist unter dem Namen Electronic Code Book (ECB)
bekannt. Gleiche Klartextblcke werden also in gleiche Chiffretextblcke bersetzt (siehe Abbildung 2.6). Dies ist sehr einfach zu realisieren, bietet jedoch einige gravierende Nachteile und
32
Klartextblock
IV
Klartextblock
+
S
C
Klartextblock
Chiffretextblock
Nachricht
Chiffretextblock
Klartextblock
Chiffretextblock
Chiffretextblock
Verschlsselung
Chiffretext
...
Chiffretextblock
S
D
IV
Chiffretextblock
Chiffretextblock
Chiffretextblock
Klartextblock
Klartextblock
Klartextblock
Klartextblock
Entschlsselung
Abbildung 2.7: Cipher Block Chaining.
Angriffspunkte. Zum einen setzen sich statistische Merkmale der Ausgangsblcke in den Cipherblcken fort, hnlich wie wir dies schon von der monoalphabetischen Substitution her kennen.
Zum anderen bietet diese Betriebsart keinen Schutz gegen Vertauschen, Herausnehmen, Ersetzen oder Duplizieren von Ciphertextblcken. Dechiffriert man diese nmlich, so erhlt man das
gleiche Resultat, als htte man die Klartextblcke vertauscht, herausgenommen, ersetzt oder dupliziert. Damit ist die Integritt einer so verschlsselten Nachricht nicht automatisch durch die
Verschlsselung sichergestellt.
2.4.2 Cipher Block Chaining

Beim Cipher Block Chaining (CBC) wird die Eingabe ebenfalls in Blcke der Gre m aufgeteilt.
Diese Blcke werden jedoch nicht mehr einzeln und unabhngig voneinander behandelt, sondern
vor der Verschlsselung wird der vorangegangene Ciphertextblock mit dem aktuellen Klartextblock bitweise XOR-verknpft (siehe Abbildung 2.7). Zur Entschlsselung wird diese Operation
entsprechend umgekehrt durchgefhrt. Da beim ersten Block noch kein vorangegangener Block
existiert, wird in diesem Schritt statt des vorangegangenen Ciphertextblocks ein (zufllig gewhlter) Initialization Vector (IV) verwendet. Sender und Empfnger muss dieser Wert bekannt sein,
er kann beispielsweise im Klartext bertragen werden oder im ECB-Modus.
Da durch die XOR-Operation nun jeder Cipherblock von den vorangegangenen Blcken abhngt, fhren gleiche Klartextblcke jetzt nicht mehr zu gleichen Ciphertextblcken. Somit ist
auch das Vertauschen, Herausnehmen, Ersetzen oder Duplizieren von Ciphertextblcken nicht
mehr ohne weiteres mglich. Trotzdem sind die Auswirkungen eventueller Fehler bei der bertragung eines Cipherblocks beschrnkt und wirken sich nur bei der Dechiffrierung dieses Blocks
und des nchsten Blocks aus. Danach ist wieder eine fehlerfreie Dechiffrierung mglich.
2.4 Betriebsarten
33
m-Bit Schieberegister
i Bit
i Bit
i Bit
C
Verschlsselung
...
i Bit
Ausgabe
i Bit
Ausgabe
i Bit
i-Bit
Klartextblock
i-Bit
Klartextblock
i-Bit
Chiffretextblock
Ausgabe
i-Bit
Klartextblock
i-Bit
Chiffretextblock
i-Bit
Chiffretextblock
i Bit
i Bit
i Bit
C
Entschlsselung
...
i Bit
Ausgabe
i Bit
+
i-Bit
Chiffretextblock
Ausgabe
+
i-Bit
Chiffretextblock
i-Bit
Klartextblock
i Bit
Ausgabe
+
i-Bit
Chiffretextblock
i-Bit
Klartextblock
i-Bit
Klartextblock
Abbildung 2.8: Cipher Feedback Mode.
2.4.3 Cipher Feedback Mode und Output Feedback Mode

Die bisher vorgestellten Betriebsmodi sind blockorientiert, da sie die Nachricht in Blcke der
durch das verwendete Verfahren vorgegebenen Gre verwandeln. Fr einige Anwendungen sind
diese Blcke aber zu gro, etwa fr Realzeitanwendungen, wo man auch Nachrichten geringerer Gre efzient bertragen und verarbeiten muss. Daher ist es notwendig, auch einzelne Bits
oder Bytes verschlsseln, bertragen und wieder entschlsseln zu knnen. Dies ist mglich durch
die sogenannten stromorientierten Betriebsarten. Hierbei wird das zugrundeliegende kryptographische Verfahren verwendet, um eine pseudozufllige, also zufllig erscheinende Bitfolge durch
das kryptographische Verfahren zu erzeugen und diese dann wie einen One-Time-Pad zu verwenden. Bei einer ursprnglichen Blockgre von m Bit wird ein entsprechend groes Schieberegister mit einem Initialization Vector gefllt und hierauf das Verschlsselungsverfahren angewandt.
34
i Bit
i Bit
i Bit
C
Verschlsselung
...
i Bit
Ausgabe
i Bit
Ausgabe
i Bit
i-Bit
Klartextblock
i-Bit
Klartextblock
i-Bit
Chiffretextblock
Ausgabe
i-Bit
Klartextblock
i-Bit
Chiffretextblock
i-Bit
Chiffretextblock
i Bit
i Bit
i Bit
C
Entschlsselung
...
i Bit
Ausgabe
i Bit
+
i-Bit
Chiffretextblock
Ausgabe
+
i-Bit
Chiffretextblock
i-Bit
Klartextblock
i Bit
Ausgabe
+
i-Bit
Chiffretextblock
i-Bit
Klartextblock
i-Bit
Klartextblock
Abbildung 2.9: Output Feedback Mode.
Die Ausgabe des Verschlsselungsverfahrens besteht aus m Bit. Will man eine Klartextnachricht
von i Bit bertragen, so whlt man aus den m Bits der Ausgabe des Verfahrens die i am weitesten
links stehenden aus und verknpft sie bitweise XOR mit der Nachricht.
Fr die nchste Verschlsselung wird der Wert des Schieberegisters gendert. Dies erfolgt,
indem i Bits aus dem Register geschoben werden und i neue Bits in das Register geschoben
werden. Beim Cipher Feedback Mode (CFB) werden hierfr die tatschlich bertragenen vorangegangenen Bits verwendet, whrend beim Output Feedback Mode (OFB) die i Bits der Ausgabe
des Verfahrens gewhlt werden, die zur Verschlsselung benutzt wurden.
Die Verschlsselung und Entschlsselung ist in den Abbildungen 2.8 und 2.9 schematisch
skizziert. Die Dechiffrierung erfolgt wiederum durch eine XOR-Verknpfung des Chiffretexts
mit derselben pseudozuflligen Bitfolge, die genau wie bei der Verschlsselung erzeugt wird. Es
2.4 Betriebsarten
35
Zhler 1
Zhler 2
Zhler n
S
C
S
C
C
Verschlsselung
...
Ausgabe
Klartextblock
Ausgabe
Klartextblock
Ausgabe
Klartextblock
Chiffretextblock
Chiffretextblock
Chiffretextblock
Zhler 1
Zhler 2
Zhler n
S
C
S
C
C
Entschlsselung
...
Ausgabe
Chiffretextblock
+
Klartextblock
Ausgabe
Chiffretextblock
Ausgabe
Chiffretextblock
Klartextblock
+
Klartextblock
Abbildung 2.10: Counter Mode.
wird also wieder der Verschlsselungsmodus des Verfahrens verwendet, nicht der Entschlsselungsmodus.
CFB und OFB weisen einige Unterschiede auf. Da bei OFB die generierte, zufllig wirkende
Bitfolge nicht von der verschlsselten Nachricht abhngt, ist OFB anflliger fr Angriffe, dafr
wirken sich bertragungsfehler nicht so stark aus wie bei CFB. Wird OFB zweimal mit gleichem
Schlssel und gleichem IV verwendet, so ist die zur Verschlsselung verwendete Bitfolge bei der
XOR-Operation identisch, was einem Angreifer Ansatzpunkte zum Brechen der Verschlsselung
liefert und deshalb dringend unterlassen werden sollte.
2.4.4 Counter Mode

Eine weitere mgliche Betriebsart ist der Counter Mode. Diese Betriebsart ist in Abbildung 2.10
dargestellt. Prinzipiell wird beim Counter Mode der Klartext verschlsselt, indem er wie bei
CFB und OFB mit einer Bitfolge XOR-verknpft wird, die aus dem Verschlsselungsverfahren gewonnen wird. Dies geschieht jetzt aber durch Verwendung eines Zhlers, der nach jeder
Verschlsselung inkrementiert wird. Die Zhlerwerte beginnen mit einem Anfangswert (Initial Vector). Die Inkrementierung kann beispielsweise aus einer Erhhung des Zhlers um jeweils
36
eins bestehen, kann aber auch anders vorgenommen werden. Aus den gleichen Grnden wie oben
genannt sollte der gleiche Zhler mit dem gleichen Schlssel nicht zweimal verwendet werden.
Counter Mode kann als stromorientiertes Verfahren betrieben werden, indem wie bei OFB
und CFB nur Teile der Ausgabe der Verschlsselung beim XOR verwendet werden. Ebenso ist
es mglich, durch sukzessives Erhhen der Zhlerwert und Konkatenation der jeweiligen Ausgaben eine beliebig lange, pseudozufllige Bitfolge zu erhalten. Diese kann dann verwendet werden, um eine beliebig langen Strom zu verschlsseln. Man wendet das Verfahren zur Erzeugung
der fr die Verschlsselung des Klartexts notwendigen Bitsequenz also so oft an, bis man eine
hinreichend lange Bitfolge erzeugt hat. Dabei wird jedesmal der Counter inkrementiert.
2.5 Zusammenfassung
Unter Kryptographie versteht man das Verschlsseln und Entschlsseln von Nachrichten in einen Geheimcode. Dieser Geheimcode kann von nicht autorisierten Dritten nicht entschlsselt werden. Der Begriff Kryptographie schliet Verfahren mit
ein, die Integritt und Verbindlichkeit sicherstellen oder Authentikation ermglichen. Soll eine Nachricht ber ein unsicheres Netz bertragen werden, verwandelt
der Sender den Klartext unter Verwendung eines Chiffrierschlssels durch ein kryptographisches Verfahren in Chiffretext. Der Empfnger kann unter Verwendung eines Dechiffrierschlssels den Chiffretext wieder in den Klartext zurckverwandeln,
whrend dies einem Dritten ohne Kenntnis des Dechiffrierschlssels nicht mglich
ist. Man unterscheidet zwischen symmetrischen Verfahren, bei denen zur Ver- und
Entschlsselung derselbe Schlssel zum Einsatz kommt, und Public-Key-Verfahren,
bei denen ein Schlsselpaar mit unterschiedlichen Chiffrier- und Dechiffrierschlsseln
verwendet wird.
Whrend bei symmetrischen Verfahren der Schlssel geheimgehalten werden muss,
kann bei Public-Key-Verfahren der Chiffrierschlssel ffentlich bekanntgegeben werden. Dadurch sind Public-Key-Verfahren besonders einfach anzuwenden, whrend
symmetrische Verfahren von ihren algorithmischen Eigenschaften her besser einsetzbar sind. Daher kommen in der Praxis meistens hybride Verfahren zum Einsatz, bei
denen zunchst mittels Public-Key-Kryptographie ein Schlssel fr ein symmetrisches
Verschlsselungsverfahren ausgetauscht wird, das dann zur eigentlichen Verschlsselung verwendet wird. Viele kryptographische Verfahren basieren auf blockorientierter Verschlsselung, bei der Blcke von Klartext in Blcke von Chiffretext bersetzt
werden. Hierbei knnen verschiedene Betriebsarten zum Einsatz kommen, die unter
anderem den Einsatz blockorientierter Verfahren zur stromorientierten bertragung
erlauben.
2.6 bungsaufgaben
37
2.6 bungsaufgaben
Aufgabe 2.1:
Skizzieren Sie das Modell eines kryptographischen Systems.
Aufgabe 2.2:
Erlutern Sie die Unterschiede zwischen symmetrischen und Public-Key-Verfahren. Gehen Sie
dabei besonders auf die Vor- und Nachteile der Verfahren ein.
Aufgabe 2.3:
Denieren Sie den Begriff hybrides Verschlsselungsverfahren. Skizzieren Sie schematisch
den Ablauf eines hybriden Verfahrens.
Aufgabe 2.4:
Beschreiben Sie den Begriff Betriebsart. Nennen und skizzieren Sie mindestens zwei verschiedene Betriebsarten. Geben Sie Beispiele, wo diese Betriebsarten sinnvoll eingesetzt werden
knnten.

Aufgabe 2.5:
Unter Caesars Cipher versteht man eine monoalphabetische Substitution, bei denen jeder Buchstabe durch den in alphabetischer Ordnung n Positionen spter auftretenden Buchstaben dargestellt wird, also beispielsweise fr n = 2:
Symbol
Code
A
C
B
D
C
E
D
F
E
G
F
H
G
I
H
J
I
K
Symbol
Code
R
T
S
U
T
V
U
W
V
X
W
Y
X
Z
Y
A
Z
B
J
L
K
M
L
N
M
O
N
P
O
Q
P
R
Q
S
1. Verschlsseln Sie die Nachricht DIES IST NICHT SCHWER mit Caesars Cipher fr n = 4.
2. Bestimmen Sie die Gre des Schlsselraums und diskutieren Sie die Sicherheit des Verfahrens.
3. Dechiffrieren Sie folgende Nachricht: MNM RBGNKZD RDC UHSZD CHRBHLTR
Aufgabe 2.6:
Diskutieren Sie, ob eine 40-fache monoalphabetische Substitution (mit verschiedenen Ersetzungen in jeder Runde) sicherer ist als eine einmal durchgefhrte monoalphabetische Substitution
oder nicht.
Kapitel 3
Authentifikation
3 Authentikation
3.1 Grundlagen
Im vorangegangenen Kapitel haben wir uns im Wesentlichen mit kryptographischen Verfahren
beschftigt, die der Sicherstellung der Vertraulichkeit von Daten dienen. Nun werden wir uns
den Aspekten der Authentizitt und Authentikation von Daten und Kommunikationspartnern
widmen.
Mit den im letzten Kapitel dargestellten Verfahren knnen wir zwar erreichen, dass unsere
Kommunikation mit einem anderen Teilnehmer, sagen wir beispielsweise die bermittlung von
Kreditkarteninformationen ber das Internet an einen Server eines Online-Hndlers, nicht abgehrt werden kann. Womit wir uns noch nicht beschftigt haben, ist die Frage, wie man sicherstellen kann, tatschlich mit dem Server des Online-Hndlers zu kommunizieren und nicht mit einer
anderen Maschine, wie wir also den Partner am anderen Ende der Verbindung authentizieren
knnen.
Blicken wir zunchst einmal in die nicht-elektronische Welt: Authentikation erfolgt dort auf
verschiedenste Arten und Weisen und auf ganz verschiedenen Sicherheitsniveaus. So erkennt
man etwa einen vertrauten Gesprchspartner am Telefon meist an der Stimme. Dieses Verfahren
ist natrlich keinesfalls wirklich sicher, wie diverse mehr oder weniger gelungene Telefonspe in Fernsehsendungen mit fraglichem Unterhaltungsniveau eindrucksvoll unter Beweis stellen.
Wenn Sie eine internationale Grenze passieren, authentizieren Sie sich durch Vorlage eines
Ausweises. Dieser Ausweis ist schwer zu flschen und enthlt biometrische Merkmale, angefangen von Gre, Augenfarbe und einem Lichtbild bis hin zu Fingerabdrcken usw. Durch
Abgleich der im Ausweisdokument gespeicherten Merkmale mit der jeweiligen Person kann ein
Grenzbeamter feststellen, dass es sich bei der kontrollierten Person tatschlich um die im Pass
angegebene handelt.
Ein weiteres wichtiges Feld ist die Sicherstellung der Authentizitt von Nachrichten. Nichtelektronische Vertrge, Briefe und andere Dokumente werden in der Regel durch eine Unterschrift (engl. Signature) authentiziert. Da sich Unterschriften flschen lassen, ist manchmal eine
beglaubigte Unterschrift zu leisten, d.h. die unterschreibende Person wird z.B. durch einen vereidigten Notar vor dem Leisten der Unterschrift authentiziert. Da mehr und mehr rechtswirksame
Vorgnge elektronisch abgewickelt werden, sind Mechanismen notwendig, die entsprechende
Funktionen digital zur Verfgung stellen.
Die Mechanismen zur Authentikation von Benutzern und Maschinen und Sicherstellung der
Authentizitt von Nachrichten sind im Grunde genommen sehr hnlich zu den in der nicht-
40
3 Authentikation
elektronischen Welt verwendeten Verfahren, tragen aber den speziellen Bedrfnissen Rechnung,
die durch die elektronische Informationsverarbeitung notwendig sind. Wenden wir uns zunchst
der Authentikation zu.
3.2 Mgliche Faktoren zur Authentikation

Die Authentikation von Benutzern und anderer handelnder Einheiten spielt fr die IT-Sicherheit
eine zentrale Rolle. Es gibt vielfltige Mglichkeiten, wie ein Benutzer oder ein Rechner authentiziert werden kann. Die dabei verwendeten Verfahren knnen in ganz verschiedenen Szenarien
zum Einsatz kommen, angefangen von der Authentikation beim Einloggen auf Betriebssystemebene bis hin zur Authentikation eines Benutzers durch eine Netzwerkanwendung.
Bei der Authentikation geht es darum, die Identitt eines Benutzers zu berprfen und mit
(grtmglicher) Sicherheit zu verizieren. Wir alle kennen die Notwendigkeit von Authentikationsmechanismen und die entsprechende Vorgehensweise aus Geheimagentenlmen. Der zu
treffende Agent, den man noch nie gesehen hat, trgt als Erkennungszeichen ein rotes Einstecktuch in der Sakkotasche, hat eine Narbe auf der Stirn und antwortet auf die Frage Schner Tag
heute, nicht wahr? mit der Antwort Ja, aber jeder Tag ohne Busfahrt ist ein schner Tag.
woraufhin der andere Agent antworten muss: In Mexiko gibt es Busse mit Klimatisierung, die
sollten Sie vielleicht einmal ausprobieren.
Authentikationsmechanismen basieren also auf Wissen ber Busfahrten in Mexiko, roten
Einstecktchern und einer Narbe auf der Stirn. Ein wenig allgemeiner formuliert basieren sie auf
einem oder mehreren der folgenden sogenannten Faktoren:
Wissen, das nur der zu Authentizierende besitzt: In Computersystemen sind Passwrter ein typischer, weitverbreiteter Vertreter dieser Kategorie. Auch Personal Identication
Numbers (PINs) und Transaction Authentication Numbers (TANs) zhlen hierzu. Wenn
Sie in einem Call-Center anrufen, werden Sie oft ebenfalls ber solches Wissen identiziert. Manchmal wird auch eine kombinierte Abfrage von Wohnadresse, Geburtsdatum,
Geburtsname der Mutter usw. als ausreichend erachtet.
Objekte, die nur der zu Authentizierende besitzt: Typisch sind in dieser Kategorie SmartCards, Tokens oder auch eine Kreditkarte.
Persnliche Merkmale des zu Authentizierenden: Auch unter dem Schlagwort Biometrie bekannt. Beispiele sind der Fingerabdruck, die Gre, Gesichtsmerkmale oder Merkmale der Augen.
Natrlich knnen getreu dem Sprichwort doppelt hlt besser diese Faktoren auch beliebig
miteinander kombiniert werden. So wird beispielsweise bei der Verwendung eines Tokens oftmals zustzlich die Eingabe einer PIN oder eines Passworts verlangt. Durch diese zustzliche
Manahme ist es bei einem Diebstahl nicht mglich, das Token zu missbrauchen, wenn man
nicht das zugehrige Passwort kennt. Solche Verfahren sind unter dem Schlagwort MehrfaktorAuthentikation bekannt.
Im Folgenden werden wir Vor- und Nachteile dieser einzelnen mglichen Faktoren zur Authentikation nher betrachten.
3.3 Passwrter
41
3.3 Passwrter
Als Erstes wenden wir uns der Authentikation durch Passwrter zu. Diese Authentikationsmethode ist derzeit noch am verbreitetsten und kommt in vielfltigen Szenarien zum Einsatz.
Etwas allgemeiner formuliert handelt es sich bei einem Passwort um gemeinsames geheimes
Wissen, das nur der zu Authentizierende und der, bei dem man sich authentiziert, besitzt.
Diese Authentikationsmethode kommt beispielsweise auf Betriebssystemebene zum Einsatz.
Ein Benutzer authentiziert sich durch Eingabe eines Benutzernamens und eines zu diesem Benutzerkonto gehrenden Passworts.
Unterstellt man dem Programm, welches die Authentikation durchfhrt, absolute Fehlerfreiheit und geht davon aus, dass es keine Wege gibt, dieses Programm zu umgehen, so hngt die
Sicherheit dieser Methode von der Geheimhaltung des Passworts ab. Gelangt ein Angreifer wie
auch immer in den Besitz des Passworts, ist die Sicherheit des Verfahrens kompromittiert. Die
Sicherheit passwortbasierter Verfahren hngt daher von folgenden Faktoren ab:
Gre des Passwortraums, Wahl des Passworts und Passwort-Policies,
Sicherheit der Passwortspeicherung beim Anwender und im System und
Sicherheit bei der Passworteingabe und bertragung.
Im Folgenden werden wir diese Faktoren im Einzelnen nher unter die Lupe nehmen.
3.3.1 Gre des Passwortraums

Die Gre des Passwortraums, also die Anzahl aller mglichen Passwrter, ist aus dem gleichen
Grund wichtig wie die Gre des Schlsselraums bei kryptographischen Verfahren in Sektion
2.2.2: Passwrter sollten gegenber Brute-Force-Angriffen sicher sein. Wie gro der Passwortraum ist, hngt von der Lnge des Passworts und der Anzahl der im Passwort erlaubten Zeichen ab. Sind nur Kleinbuchstaben erlaubt (oder sind nur Buchstaben erlaubt und es wird nicht
zwischen Gro- und Kleinschreibung unterschieden), so gibt es pro Zeichen im Passwort 26
verschiedene Mglichkeiten. Bei einer Passwortlnge von 8 gibt es somit 268 = 208827064576
verschiedene mgliche Passwrter. Dies entspricht hinsichtlich der Anzahl an Mglichkeiten
ungefhr der Verwendung eines binren Schlssels mit nur 38 Bit (!). Der Passwortraum wird
signikant grer, wenn bei der Auswertung des Passworts zwischen Gro- und Kleinschreibung unterschieden wird (
also ein anderes Passwort ist als
) und die Verwendung von
Zahlen und Sonderzeichen mglich ist. Tabelle 3.1 gibt eine kurze bersicht.
Einen groen Passwortraum erhlt man also, indem man lange Passwrter zulsst, die ber
einem groen Zeichenvorrat gebildet werden. Doch das alleine garantiert nicht, dass dieser Passwortraum auch vollstndig ausgeschpft wird: Wenn sich der Benutzer das Passwort frei aussuchen kann, muss er nicht alle erlaubten Zeichen verwenden, sondern kann sich auch darauf beschrnken, ein ausschlielich aus Kleinbuchstaben bestehendes Passwort zu verwenden. Wenn
ein Angreifer bei einem Brute-Force-Angriff hierauf spekuliert, steigen seine Erfolgschancen
dramatisch, wie die Zahlen in Tabelle 3.1 eindrucksvoll belegen. Noch schlimmer wird es, wenn
42
Passwortlnge
4
8
8
8
16
16
16
n
3 Authentikation
Erlaubte Zeichen
0-9
a-z
a-z,A-Z,0-9
a-z,A-Z,0-9,28 Sonderz.
a-z
a-z,A-Z,0-9
a-z,A-Z,0-9,28 Sonderz.
Anzahl erlaubter
Zeichen
10
26
62
90
26
62
90
q
Mglichkeiten
104
268
628
908
2616
6216
9016
qn
Entsprechung
in Bit
13,3
37,6
47,6
51,9
75,2
95,3
103,9
log2 (qn )
Tabelle 3.1: Passwortlnge, erlaubte Zeichen, Anzahl der Mglichkeiten (28 Sonderzeichen) und Lnge
eines Binrschlssels mit gleicher Schlsselraumgre.
der Benutzer als Passwort nicht einfach eine beliebige Kombination von acht Alphabetsymbolen wie
whlt, sondern ein Wort, das tatschlich in einer natrlichen Sprache vorkommt wie
. Wenn wir von einer sehr hochgegriffenen Zahl von ca. 1 Million mglicher Wrter in verschiedenen Sprachen der Welt ausgehen, entspricht dies der Gre eines
Schlsselraums, das durch einen Binrschlssel mit 20 Bit erzeugt werden kann. Wrterbcher
fr verschiedenste Sprachen sind im Internet frei zugnglich und leicht zu nden. Alles in allem
paradiesische Zustnde fr Hacker!
In einigen Fllen ist der Passwortraum noch kleiner. Die von Bankkarten bekannten Personal
Identication Numbers (PINs) bestehen nur aus vier Ziffern, somit gibt es nur 10.000 mgliche
PINs. Derart kleine Passwort-Rume sind nur dann vertretbar, wenn effektiv sichergestellt werden kann, dass eine Brute-Force-Attacke unmglich ist. Verhindern lassen sich solche Angriffe,
wenn ein Angreifer den Passwortraum nicht allein im stillen Kmmerlein durchprobieren kann
(ofine), sondern wenn er dies nur in Verbindung mit dem System kann, fr das die Authentikation stattndet und das System nicht unter seiner Kontrolle steht (online).
Muss der Angreifer online operieren, gibt es eine Reihe von Mglichkeiten, Brute-ForceAngriffe zu unterbinden. Eine Option ist es, ein Benutzerkonto nach drei erfolglosen Authentikationsversuchen zu sperren. So wird etwa nach dreimaliger falscher Eingabe der PIN eine
Bankkarte automatisch gesperrt. Ein solches Vorgehen ist natrlich nicht in allen Fllen praktikabel und kann manchmal auch als Grundlage fr andere Arten von Angriffen benutzt werden
(siehe Abschnitt 12.2).
Wenn Sperren eine zu drastische Mglichkeit ist, kann auch eine Wartezeit zwischen zwei erfolglosen Authentikationsversuchen eingefhrt werden. So kann beispielsweise an einem Fernseher oder Digitalreceiver aus Grnden des Jugendschutzes die Eingabe einer PIN erforderlich
sein, um bestimmte Programme sehen zu drfen. Dies hindert einen Junior in pubertierendem Alter nicht daran, in Abwesenheit der Eltern einige PINs durchzuprobieren. Wenn er jedoch nach
den ersten drei Fehlversuchen fnf Minuten, nach einem weiteren Fehlversuch zehn Minuten,
dann zwanzig usw. warten muss, bis er es wieder versuchen kann, ist es unwahrscheinlich, dass
er dabei vor Erreichen der Volljhrigkeit Erfolg hat.
3.3 Passwrter
43
Trotzdem: Ein kleiner Passwortraum ist schlecht fr die Sicherheit. Die Wahrscheinlichkeit,
in drei Versuchen eine vierstellige PIN richtig zu erraten, betrgt 0, 3% das ist alles andere als
eine schlechte Quote fr einen Angreifer.
3.3.2 Sicherheit der Passwortspeicherung beim Anwender und im System

Kommen wir wieder zurck zu Passwrtern und der Frage, wie man die Anwender dazu bringt,
den Passwortraum mglichst voll auszuschpfen. Oft werden Benutzer dazu gezwungen, mindestens einen oder mehrere Grobuchstaben und/oder ein oder mehrere Sonderzeichen in ihr
Passwort einzuarbeiten. Manchmal besitzen die Passwrter auch eine bestimmte Lebensdauer,
nach der ein neues Passwort gewhlt werden muss.
Das Ergebnis solcher Manahmen hinsichtlich einer Verbesserung der Sicherheit ist fragwrdig. Ein neben dem Monitor festgeklebtes, aufgeschriebenes, kompliziertes Passwort, das jeden
Monat gewechselt und neu aufgeschrieben und neben den Bildschirm geklebt wird, ist in einem
Groraumbro nicht unbedingt sicherer als ein nicht aufgeschriebenes, einfaches Passwort. Dies
gilt insbesondere dann, wenn das betreffende Passwort ausschlielich dazu benutzt werden kann,
sich direkt auf einem Rechner innerhalb des Unternehmens einzuloggen und das Passwort nicht
von auerhalb verwendet werden kann. Trotzdem sind viele Institutionen hinsichtlich der Wahl
und nderung von Passwrtern in blanken Aktionismus verfallen, und damit missachten sie oft
eine der grten Bedrohungen passwortbasierter Systeme: Die Geheimhaltung der Passwrter
auf Benutzerseite.
Gelangt ein Angreifer in den Besitz des Passworts, so hat er einen Freifahrtschein zum Einbruch in das System in der Hand. Deshalb, so die Theorie, sollten Passwrter mglichst berhaupt nicht aufgeschrieben werden, sondern der Nutzer sollte sich die Passwrter einprgen und
auswendig lernen. Was bei einem Passwort vielleicht noch funktioniert, schlgt bei fnfzig Passwrtern, vier verschiedenen Benutzernamen und zehn PINs schon mit ziemlicher Sicherheit fehl,
insbesondere dann, wenn alle Passwrter auch noch regelmig gendert werden mssen.
Variationen eines Passworts oder gar dasselbe Passwort fr alle Dienste zu verwenden, ist
aus Sicherheitsgrnden eine sehr schlechte Idee. Wenn ein Benutzer berall dasselbe Passwort
verwendet, reicht eine Sicherheitslcke in einem der Systeme, um sein Benutzerkonto berall
mit diesem Passwort missbrauchen zu knnen. Es gibt technische Vorschlge, das Problem zu
lsen, so dass ein Benutzer einen Benutzernamen und ein Passwort fr mehrere (im Idealfall
alle) notwendigen Authentikationen verwenden kann, ohne dass dabei das gerade skizzierte
Sicherheitsproblem entsteht. Diese als Single-Sign-On bekannte Technologie hat sich bisher aber
noch nicht durchgesetzt und es ist auch nicht zu erwarten, dass sie in naher Zukunft grochig
zum Einsatz kommt.
Es gibt Anwendungsprogramme, mittels derer Passwrter verschlsselt auf einem System abgelegt werden knnen. Um die Passwrter wieder zu entschlsseln, ist ein Masterpasswort notwendig, so dass sich der Benutzer wieder nur eines statt vieler Passwrter merken muss. Wenn
der Benutzer das Masterpasswort vergisst, hat er ein Problem, wenn er es aufschreibt, vielleicht
auch.
Der sorglose Umgang mancher Benutzer mit Passwrtern ist ein weiteres Problem. Wer sein
Benutzerkonto verleiht, also eine andere Person ber das eigene Konto ein System benutzen
lsst und dabei vielleicht sogar noch das Passwort preisgibt, geht ein hohes Risiko ein. Im Falle
44
3 Authentikation
einer missbruchlichen Verwendung, vielleicht sogar dem Begehen einer Straftat ber dieses
Benutzerkonto, knnen unangenehmen Konsequenzen drohen.
Bisher haben wir nur den Benutzer als Sicherheitsrisiko betrachtet. Doch auch auf dem System selbst, wo die Passwrter ja in irgendeiner Form gespeichert sein mssen, drohen Sicherheitsprobleme. Ein Angreifer knnte versuchen, in den Besitz der auf dem System liegenden
Passwrter zu gelangen. Dabei kann es sich bei dem Angreifer auch um einen Insider handeln,
also eine Person, die bereits Zugang zu dem System besitzt. Die Verwendung des Benutzerkontos
des verhassten Kollegen mit dessen auf diese Art gestohlenen Passwort kann fr die betreffende Person schwerwiegende Konsequenzen haben bis hin zum Verlust des Arbeitsplatzes oder
strafrechtlichen Problemen. Selbst wenn er glaubhaft machen kann, zu diesem Zeitpunkt das
Benutzerkonto nicht verwendet zu haben, bleibt der Verdacht, durch Fahrlssigkeit einem Dritten den Missbrauch des Kontos berhaupt mglich gemacht zu haben. Dies macht bereits das
Perde an solchen Angriffen deutlich: Letztendlich kann auf diese Weise nicht nur das System,
sondern mglicherweise ein Benutzer des Systems geschdigt werden, ohne dass dieser sich in
irgendeiner Weise falsch verhalten hat. Dies gilt leider nicht nur fr Passwrter. Viele OnlineHndler speichern die Kreditkartendaten ihrer Kunden auf ihrem System ab, um ihren Kunden
beim nchsten Einkauf die mhsame nochmalige Eingabe der Nummer zu ersparen. Es ist Angreifern bereits bei einigen Systemen gelungen, an solche gespeicherten Daten zu kommen und
sie zu missbrauchen.
Aus diesen Ausfhrungen wird bereits deutlich, dass Passwrter (genau wie andere sensitive
Daten, z.B. die Kreditkarteninformationen von Kunden) nicht in Klartext, sondern verschlsselt
auf einem System abgelegt werden sollten. Wenn die Passwrter (oder andere Informationen)
verschlsselt auf dem System gespeichert sind, so kann die Sicherheit kompromittiert werden,
wenn es einem Angreifer gelingt, sowohl in den Besitz des kryptographischen Dechiffrierschlssels als auch der verschlsselten Daten zu gelangen. Dies liegt einfach daran, dass es einem
befugten Benutzer mglich sein muss, die Daten wieder zu entschlsseln. Doch das ist bei Passwrtern nicht der Fall, und deshalb lassen sie sich auf einem System noch sicherer abspeichern,
nmlich durch die Verwendung kryptographischer Hashfunktionen. Sie werden uns in Abschnitt
3.6.2 im Zusammenhang mit digitalen Signaturen nochmals begegnen. Kurz gesagt wandelt eine
kryptographische Hashfunktion eine Eingabe beliebiger Lnge in eine fr sie charakteristische
Bitfolge fester Lnge um.
Dies kann bei der Sicherheit von Passwrtern wie folgt eingesetzt werden: Anstatt das Passwort selbst zu speichern, wird auf dem System der Hashwert des Passworts abgelegt. Wenn sich
der Benutzer beim System authentizieren will, gibt er sein Passwort ein. Das System berechnet
den Hashwert der Eingabe und vergleicht diesen Wert mit dem abgespeicherten Wert.
Ein Angreifer, der in den Besitz der abgespeicherten Hashwerte kommt, kann daraus keinen
unmittelbaren Nutzen ziehen: Zu den Eigenschaften einer kryptographischen Hashfunktion gehrt es, dass es praktisch unmglich ist, zu einem gegebenen Hashwert eine Eingabe zu ermitteln,
die diesen Hashwert liefert. Somit kann er aus dem erhaltenen Hashwert nicht auf das zur Authentikation notwendige Passwort schlieen.
Doch damit ist die erlangte Information fr einen Angreifer nicht vollstndig uninteressant. Da
das verwendete Hashverfahren ffentlich bekannt ist, kann er mittels einer Brute-Force-Attacke
mgliche Passwrter raten, deren Hashwert berechnen und mit den auf dem System abgespeicherten Hashwerten vergleichen. Bei Gleichheit ist der Angreifer im Besitz des Passworts und
3.3 Passwrter
45
kann es dann missbrauchen. Dies kann er in Ruhe auf einem ihm gehrenden Rechner testen, und
ist der Hacker im Besitz der Hashwerte, gibt es keine Mglichkeit, dies effektiv zu verhindern.
Da der Hashwert eines Passworts immer gleichbleibt, kann der Angreifer auch die zu mglichen Passworten gehrenden Hashes im Vorhinein berechnen und speichern, so dass die Suche
nach einem mglichen Treffer noch efzienter mglich ist. Solche Wrterbuchangriffe (Dictionary Attack) knnen durch Verwendung von Salts erschwert werden. Dabei wird nicht der Hash
des Passworts auf dem System gespeichert, sondern der Hash des Passworts und einer zufllig
erzeugten Bitfolge (des Salts). Der berechnete Hashwert wird zusammen mit der verwendeten
Bitfolge abgespeichert. Bei einem Authentikationsversuch wird der Hashwert des eingegebenen Passworts und der gespeicherten Bitfolge berechnet und mit dem gespeicherten Hashwert
verglichen. Ein Wrterbuchangriff wird fr den Angreifer dadurch sehr viel aufwendiger, denn
er muss wesentlich mehr Hashwerte im Vorhinein berechnen, da ja der Wert auch von der zufllig
gewhlten Bitfolge abhngt.
Einige Leser mgen sich vielleicht gefragt haben, was eigentlich passiert, wenn jemand bei
einem solchen hashbasierten Verfahren statt des eigentlichen Passworts eine andere Eingabe
macht, die zufllig den gleichen Hashwert liefert. Als kleine Randnotiz sei erwhnt, dass man
sich mit dieser Eingabe genauso authentizieren kann wie mit dem richtigen Passwort. Dieses
Verhalten kann aber nicht fr einen Angriff missbraucht werden, da eine Eigenschaft einer kryptographischen Hashfunktion ist, dass es praktisch unmglich ist, zu einem gegebenen Hashwert
eine Eingabe zu ermitteln, die diesen Hashwert liefert.
3.3.3 Sicherheit der Passworteingabe und bertragung

Ein Angreifer muss nicht unbedingt in den Besitz eines aufgeschriebenen Passworts gelangen.
Es kann ihm auch mglich sein, den Anwender dabei zu beobachten, wie er das Passwort auf der
Tastatur eingibt. Selbst wenn der Angreifer dabei nicht das gesamte Passwort fehlerfrei aussphen kann, bietet diese Technik gute Ansatzpunkte fr gezieltes Raten. Auch existieren Schadprogramme, die sich unbemerkt auf einem System einnisten knnen (siehe Kapitel 6) und dann
mitprotokollieren, welche Benutzereingaben auf dem System ber die Tastatur oder anderweitig
erfolgt sind. Diese Keylogger schicken diese Informationen an einen Angreifer weiter, der so
ebenfalls in den Besitz von Benutzerkonten und Passwrtern gelangen kann.
Eine weitere mgliche Schwachstelle ist die unverschlsselte bertragung von Passwrtern
ber ein Netzwerk. Oftmals erfolgen Benutzerauthentizierungen nicht auf dem lokalen Rechner,
sondern der Benutzer kann sich mit einem Benutzerkonto und Passwort auf mehreren Maschinen authentizieren und darber hinaus noch weitere Ressourcen (z.B. ein Netzwerklaufwerk)
verwenden. In diesen Fllen erfolgt die Authentikation nicht lokal, sondern auf einer anderen Maschine. Hierzu ist es notwendig, eine Authentikation ber das Netzwerk durchzufhren.
Da Netzwerke oftmals leicht bis kinderleicht abgehrt werden knnen, ist eine unverschlsselte
bertragung des Passworts ein groes Sicherheitsrisiko. Besser ist es, das Passwort verschlsselt, also nach Aufbau einer kryptographisch abgesicherten Verbindung zu bertragen. Noch
besser ist es allerdings, das Passwort gar nicht zu bertragen, sondern die Authentikation ber
Challenge-Response durchzufhren.
Diese Authentikation folgt dem in Abbildung 3.1 skizzierten Schema. Wenn A sich bei B
authentizieren mchte, schickt B ihm eine zufllig gewhlte Bitfolge x. A wendet auf das Pass-
46
3 Authentikation
Teilnehmer A
Teilnehmer B
Voraussetzung: Beide Teilnehmer haben
ein gemeinsames Passwort vereinbart
Hallo h
ie
n
Berech
r ist A
+Passw
bitte h(x
ort)
B erzeugt zuflliges x
Ergebn
is ist y
OK
B vergleicht y mit eigener

Berechnung von
h(x+Passwort)
Abbildung 3.1: Authentikation mittels eines Passworts und Challenge-Response.
wort und x eine kryptographische Hashfunktion an und sendet diesen Wert y an B. B berprft
den von A bermittelten Wert y mit einer eigenen Berechnung. Der durch die Hashfunktion gebildete Wert ist charakteristisch fr das Passwort und x. Wenn die Werte bereinstimmen, kann
B mit an Sicherheit grenzender Wahrscheinlichkeit davon ausgehen, dass der Partner auf der anderen Seite ebenfalls das Passwort in der Berechnung verwendet hat, es also kennt und es sich
beim Kommunikationspartner somit um A handelt.
Damit ist dieses Verfahren also zu einer bertragung des Passworts quivalent. Allerdings ist
Challenge-Response wesentlich sicherer: Ein Dritter C, der diesen Nachrichtenaustausch mithrt, kann aus dem beobachteten Hashwert das Passwort nicht rekonstruieren. Da B bei der
nchsten Authentikationsanfrage eine andere Bitfolge whlen wird, kann er seine Beobachtungen nicht dazu missbrauchen, sich bei B als A auszugeben.
3.3.4 Passwrter Eine Sicherheitslcke?

Passwrter werden hug von den Benutzern unzureichend geschtzt oder schwach gewhlt.
Bei der Speicherung von Passwrtern auf einem System oder die Verwendung von Passwrtern
bei der Authentikation ber ein Netzwerk knnen ebenfalls Sicherheitsprobleme auftreten. Die
Verwendung passwortbasierter Systeme verlangt sowohl von den Nutzern des Systems als auch
von den Systementwicklern und Administratoren ein hohes Ma an Aufmerksamkeit und Gefahrenbewusstsein.
3.4 Tokens und Smart-Cards
47
3.4 Tokens und Smart-Cards

Die Verwendung von Passwrtern kann also mit einer ganzen Reihe von Schwachstellen behaftet
sein, die ein Angreifer ausnutzen kann. Die vielleicht wichtigsten Probleme sind:
Passwrter sind relativ statisch und ndern sich nur selten oder gar nicht und
der Diebstahl eines Passworts fllt dem betroffenen Anwender nicht sofort oder berhaupt
nicht auf.
Bei einem physischen Objekt, etwa einem Broschlssel oder einer Zugangskarte, wird ein
Verlust sptestens dann bemerkt, wenn man den Schlssel oder die Karte wieder benutzen mchte. Alleine diese Eigenschaft bedeutet bereits einen beachtlichen Sicherheitsgewinn. Es gibt daher auch elektronische Authentikationsmechanismen, die auf der Verwendung eines physikalischen Objekts, eines sogenannten Tokens basieren. Um sich authentizieren zu knnen, muss
der Benutzer im Besitz dieses Objekts sein.
Die Idee zu berprfen, ob ein Benutzer im Besitz eines Tokens ist, wird nicht nur zu Authentikationszwecken eingesetzt. Auch zur Realisierung eines (einfachen) Schutzes gegen die
Verwendung der Kopien von Software werden solche Verfahren benutzt. So gibt es Programme,
deren Benutzung nur mglich ist, wenn das Original-Installationsmedium (CD-Rom, DVD ...)
in den betreffenden Rechner eingelegt ist. Auf dem Installationsmedium wird hierfr an einer
bestimmten Stelle absichtlich ein Hardwaredefekt erzeugt, der durch einen normalen Benutzer nicht ohne weiteres reproduzierbar ist. Daher kann ein Benutzer zwar das Medium kopieren,
nicht aber den absichtlich erzeugten Fehler. Beim Start des Programms wird dann berprft, ob
der absichtlich erzeugte Fehler auf dem Medium vorhanden ist und nur wenn dies der Fall ist,
kann das Programm verwendet werden.
Die Verwandtschaft von Tokens und solchen Kopierschutzmechanismen ist offensichtlich und
leicht zu verstehen: Wenn sich ein Token leicht kopieren lassen wrde, knnte ein Angreifer
ein Token kurzzeitig entwenden, kopieren und wieder zurcklegen, was den oben beschriebenen
Sicherheitsgewinn zunichte machen wrde. Daher drfen Tokens nur sehr schwierig oder am
besten berhaupt nicht reproduzierbar sein. Darber hinaus mssen solche Tokens vor allem
auch dann einsetzbar sein, wenn die zu authentizierende Person das System von einem anderen
Ort aus (ber Netzwerk, Modem, etc.) benutzen mchte. Dieser Zugriff erfolgt oft auch ber
nicht kontrollierbare Systeme. Wenn ein Benutzer sich beispielsweise von einem PC in einem
Internet-Cafe aus authentiziert, ist die Vertrauenswrdigkeit dieses PCs in dem Internet-Cafe
mehr als fragwrdig. Entsprechend sollte die Sicherheit des Verfahrens auch gewhrleistet sein,
wenn diese Maschine unter der Kontrolle eines Angreifers steht.
Aufgrund dieser Anforderungen scheiden viele Mglichkeiten unmittelbar aus. So lsst sich
beispielsweise eine Magnetstreifenkarte in einem Lesegert einfach auslesen und auf eine andere Karte kopieren. Auch Lesefehler knnen ber ein Netzwerk vorgetuscht werden. Diese
berlegungen gelten analog auch fr jedes andere Speichermedium, das einfach kopiert werden
kann. Wird eine solche Methode auf einem unsicheren System verwendet (z.B. ein PC in einem Internet-Cafe), so knnte ein Angreifer dort ein Programm installieren, das die verwendeten
Speichermedien automatisch kopiert. So knnte der Angreifer eine Kopie des benutzten Tokens
herstellen, ohne dass der legitime Benutzer es bemerkt.
48
3 Authentikation
Ein Token darf also nicht leicht kopierbar sein. Deshalb werden in der Regel Tokens eingesetzt,
die nur sehr beschrnkten oder gar keinen direkten Zugriff auf die auf dem Token gespeicherten
Daten erlauben. Das ist auch bei Smart-Cards der Fall. Eine Smart-Card ist im Prinzip ein kleiner Computer mit eigenem Permanentspeicher. Die Smart-Card wird mit einem System durch
ein Lesegert verbunden. Der Zugriff auf die im Speicher vorhandenen Daten kann aber nicht
direkt, sondern nur ber den Prozessor der Smart-Card erfolgen. Deshalb ist es nicht mglich,
den Speicher auf der Smart-Card direkt auszulesen und zu kopieren. Auf einer Smart-Card kann
zu Authentikationszwecken ein kryptographischer Schlssel abgelegt werden. Zur Authentikation wird die Smart-Card in das Lesegert, beispielsweise auf einem PC geschoben. Die Authentikation erfolgt per Challenge-Response wie in Sektion 3.3.3 beschrieben. Die Smart-Card
erhlt die Challenge und berechnet selbst die Response mittels des kryptographischen Schlssels. Der kryptographische Schlssel verlsst die Smart-Card also nicht und kann somit bei einer
Authentikation durch einen Angreifer nicht kopiert werden.
Eine Authentikation mit einem Token kann erfolgen, ohne dass das Token mit einem anderen
System verbunden werden muss. Das Token zeigt eine von der Zeit abhngige, scheinbar zufllige Ziffernfolge an, die sich in regelmigen Abstnden ndert. Diese Ziffernfolge wird ber
eine kryptographische Funktion erzeugt und ist nicht vorhersagbar. Um sich zu authentizieren,
gibt der Anwender die Ziffernfolge auf dem Token ein. Dies erfolgt meistens in Verbindung mit
einem sich nicht verndernden vierstelligen Passwort, um im Falle eines Diebstahls einen zustzlichen Schutz zu haben. Jede Ziffernfolge darf nur einmal zur Authentikation eingesetzt werden.
Ein solches Token ist eine spezielle Form eines Einmalpassworts (auch One-Time-Passwort genannt). Es gibt andere Methoden, wie solche Einmalpasswrter erzeugt werden knnen. Auch
TANs knnen als Einmalpasswrter angesehen werden. Es ist nicht schwer ersichtlich, welche
Vorteile solche Einmalpasswrter gegenber gewhnlichen Passwrtern haben.
3.5 Biometrie
Kommen wir nun zu den persnlichen Merkmalen des zu Authentizierenden, heute unter dem
Schlagwort Biometrie verbreitet.
Jeder Mensch besitzt viele unverwechselbare und schwer oder gar nicht zu ndernde Eigenschaften wie Fingerabdruck, die Gre, Gesichtsmerkmale, Merkmale der Augen (Iris) oder seine individuell einzigartige DNS. Diese Eigenschaften werden bereits jetzt im Rahmen der Personenerkennung und Identizierung (also letztendlich zur Authentikation) von Menschen durch
staatliche Stellen eingesetzt, etwa bei Grenzkontrollen oder zur Strafverfolgung.
Daher liegt es nahe, solche Methoden auch zur Authentikation von Benutzern gegenber
einem elektronischen System zu verwenden, auch wenn es gegenber den oben genannten Einsatzszenarien einige wichtige Unterschiede gibt. So muss die Authentikation in den fr uns
relevanten Anwendungsfllen vollautomatisch erfolgen, und sie muss in zeitlich sehr begrenztem Rahmen (im Sekundenbereich) durchfhrbar sein. Eine DNS-Analyse mit Ergebnis in einer
Woche ist fr uns unbrauchbar.
Aufgrund dieser Beschrnkungen und anderer konomischer und technischer Zwnge (Preis
eines Fingerabdruckscanners, aufwendbare Rechenleistung zum Vergleich des gerade erhaltenen
Abdrucks mit der gespeicherten Referenz), sind derzeit biometrische Merkmale hinsichtlich ihrer
3.5 Biometrie
49
Differenzierungsfhigkeit noch wesentlich schwcher ausgeprgt als Tokens oder Passwrter.

Neben diesen Problemen, die in der Zukunft technisch vielleicht gelst werden knnen, gibt es
noch intrinsische Probleme mit biometrischen Verfahren, die sich nicht durch technische Anstze
lsen lassen.
Bei allen Authentikationsmethoden gibt es zwei Mglichkeiten, dass die Verfahren nicht
den gewnschten Erfolg bringen: Eine Person wird flschlich erfolgreich authentiziert (falsepositive-Authentikation) oder die Authentikation einer Person schlgt flschlicherweise fehl
(false-negative-Authentikation). Beispielsweise knnte ein Angreifer bei passwortgesttzter Authentikation das Passwort eines legitimen Benutzers erfolgreich geraten haben und sich so
durch die false-positive-Authentikation Zugang zum System verschaffen, oder aber ein Benutzer knnte sein Passwort vergessen haben und erhlt deshalb keinen Zugriff auf das System
(false-negative).
Bei biometrischer Authentikation ist ein false-negative-Authentikationsergebnis aus Sicht
eines Betroffenen schlicht nicht plausibel und inakzeptabel. Ein System, das beispielsweise auf
Fingerabdrcken basiert und dabei hug legitime Benutzer nicht authentizieren kann, ist keinesfalls hinnehmbar. Die Verwendung biometrischer Merkmale basiert auf dem Vergleich aktuell gesammelter biometrischer Daten mit gespeicherten biometrischen Referenzdaten der zu
authentizierenden Person. Anders als bei einem Passwort liefert der Vergleich eines gespeicherten biometrischen Referenzwerts mit einem aktuell erhobenen Wert meistens kein eindeutiges Richtig oder Falsch, sondern nur eine bereinstimmungswahrscheinlichkeit. Um falsenegative-Authentikationen zu vermeiden, darf die Schwelle, bis hin zu der ein solcher Vergleich als bereinstimmung und damit positive Authentikation gewertet wird, nicht zu hoch
angesetzt sein. Eine zu niedrige Ansetzung jedoch ffnet die Mglichkeit huger false-positiveAuthentikationen, die ebenfalls vermieden werden mssen.
Es gibt noch ein weiteres Problem, nmlich den Schutz gegen kompromittierte Merkmale.
Gelangt etwa ein Angreifer in den Besitz Ihrer Fingerabdrcke und fertigt sich entsprechende Kopien an, gibt es keine Mglichkeit, wie Sie unter Beibehaltung des Verfahrens diesen
Missbrauch beenden knnen. Eine gewisse Skepsis gegenber biometrischen Verfahren zur Authentikation ist also durchaus angebracht.
In naher Zukunft ist damit zu rechnen, dass staatliche Stellen die automatisierte Erkennung
biometrischer Merkmale und deren Verwendung zur Authentikation bei Grenz- und Polizeikontrollen vorantreiben werden. Wenn man in Presseberichten liest, welche Schwierigkeiten einige Personen in den letzten Jahren alleine aufgrund ihres Namens hatten, weil er dem eines
Terrorismusverdchtigen hnelte, kann man sich unschwer ausmalen, in welche Situation eine
Person kommen knnte, die (zumindest nach dem Urteil eines vollautomatisierten Gesichtserkennungssystems) einem Schwerkriminellen hnelt. Die verstrkte und teilweise automatisierte
Verwendung biometrischer Merkmale durch staatliche Stellen wirft schwerwiegende ethische
Fragen und Probleme auf, die wir hier leider nicht weiter vertiefen knnen.
50
3 Authentikation
Teilnehmer A
Teilnehmer B
Voraussetzung: Gemeinsamer geheimer
Schlssel fr symmetrisches Verfahren
Hallo h
ie
r ist A
B erzeugt zuflliges x
Wert x
l
itte den und Schlsse
b
le
s
s
l
n
h
re
c
h
rs
a
e
rf
V
e
ymm. V
durch s
Ergebn
is ist y
B vergleicht y mit eigener

Berechnung
OK
Abbildung 3.2: Authentikation mittels eines gemeinsamen geheimen Schlssels durch ein symmetrisches
kryptographisches Verfahren.
3.6 Kryptographische Methoden

3.6.1 Authentikation von Benutzern und Maschinen
Nun wenden wir uns Authentikationsmethoden zu, die auf kryptographischen Verfahren basieren. Kryptographische Verfahren knnen hervorragend zur Authentikation verwendet werden.
Die vielleicht einfachste Mglichkeit ist die Verwendung eines vorher vereinbarten symmetrischen kryptographischen Schlssels zur Authentikation. Dieser kann ganz analog zu einem
Passwort eingesetzt werden:
1. Voraussetzung: Kommunikationspartner A und B verfgen ber einen gemeinsamen geheimen Schlssel fr ein symmetrisches kryptographisches Verfahren.
2. A teilt B mit, dass er sich authentizieren mchte.
3. B schickt A eine zufllig gewhlte Bitfolge.
4. A verschlsselt diese zufllige Bitfolge mit dem gemeinsamen Schlssel durch das symmetrische kryptographische Verfahren und schickt das Ergebnis an B.
5. B fhrt diese Operation ebenfalls durch und vergleicht das Ergebnis mit dem von A bermittelten Resultat. Ist es gleich, dann handelt es sich beim Kommunikationspartner tatschlich um A.
Diese Authentikation ist in Abbildung 3.2 skizziert und folgt dem bereits bekannten Challenge-Response-Schema.
51
Ein Dritter C, der diesen Nachrichtenaustausch mithrt, kann hieraus keinen Nutzen ziehen: Er
kann aus der Folge nicht den gemeinsamen Schlssel ableiten. Da B bei der nchsten Authentikationsanfrage eines Nutzers, der vorgibt, A zu sein, mit an Sicherheit grenzender Wahrscheinlichkeit (die Verwendung einer hinreichend langen Bitfolge vorausgesetzt) eine andere zufllige
Bitfolge whlen wird, kann er diese Information ebenfalls nicht verwenden, um sich spter bei
B als A auszugeben.
Verfahren, die auf einem gemeinsamen Geheimnis basieren, sind zwar in einigen Fllen praktikabel, weisen aber auch gravierende Nachteile auf. So muss wie bei symmetrischen Verschlsselungsverfahren (wie auch bei Passwrtern) die Vereinbarung des gemeinsamen Geheimnis ber
einen sicheren Kanal erfolgen und A und B mssten sicher sein, dass sie tatschlich miteinander
kommunizieren sich also irgendwie anderweitig authentizieren. Ein weiteres Problem ist die
Handhabbarkeit. Fr jeden neuen Kommunikationspartner ist es notwendig, sich ein neues gemeinsames Geheimnis zu denieren. Die entsprechenden mit dem Partner vereinbarten Schlssel
mssen sicher gespeichert und verwaltet werden.
Wie schon bei der Vertraulichkeit knnen viele dieser Probleme sehr elegant durch PublicKey-Kryptographie und einige zustzliche Manahmen gelst werden.
Wie bereits bekannt wird bei Public-Key-Verfahren zur Ver- und Entschlsselung ein Schlsselpaar bestehend aus einem privaten und einem ffentlichen Schlssel eingesetzt. Bisher haben wir Anwendungsszenarien betrachtet, in denen Nachrichten mit dem ffentlichen Schlssel verschlsselt und mit dem privaten Schlssel wieder entschlsselt wurden. Bei den meisten
Public-Key-Verfahren kann das Schlsselpaar aber (vereinfacht gesagt) auch umgekehrt verwendet werden: Man kann eine Nachricht mit dem privaten Schlssel verschlsseln und mit dem
ffentlichen Schlssel wieder dechiffrieren!
Eine Nachricht derart zu behandeln bringt nichts hinsichtlich der Vertraulichkeit, schlielich
ist der ffentliche Schlssel nicht geheim und jeder im Besitz dieses Schlssels kann die Nachricht wieder entschlsseln. Diese Verwendungsmethode ermglicht aber die Authentikation des
Teilnehmers: Erhalte ich eine Nachricht, die mit dem ffentlichen Schlssel zu dechiffrieren ist,
so wei ich, dass die Nachricht mit dem privaten Schlssel verschlsselt wurde, der Teilnehmer
auf der anderen Seite also im Besitz des privaten Schlssels des Schlsselpaars ist.
Wenn ich sicher wei, von wem der ffentliche Schlssel ist und auch davon ausgehen kann,
dass der private Schlssel nicht gestohlen wurde, ist hiermit eine sichere Authentikation wie
folgt mglich:
1. Voraussetzung: Kommunikationspartner A verfgt ber ein Public-Key-Schlsselpaar. B
ist im Besitz des ffentlichen Schlssels von A.
2. A teilt B mit, dass er sich authentizieren mchte.
3. B schickt A eine zufllig gewhlte Bitfolge.
4. A verschlsselt diese zufllige Bitfolge mit dem privaten Schlssel durch das kryptographische Verfahren und schickt das Ergebnis an B.
5. B entschlsselt die erhaltene Nachricht mit dem ffentlichen Schlssel und vergleicht das
Ergebnis mit der ursprnglich bermittelten Bitfolge. Ist es gleich, dann handelt es sich
beim Kommunikationspartner tatschlich um A.
52
3 Authentikation
Dieses Verfahren ist auf den ersten Blick sehr hnlich zu der Authentikationsmethode mit
symmetrischen Schlsseln. Public-Key-Verfahren lassen sich aber einfacher realisieren, weil sich
die Voraussetzungen fr die Anwendung des Verfahrens wesentlich einfacher schaffen lassen,
als die Voraussetzungen fr die Anwendung symmetrischer Verfahren zur Authentikation. Wir
werden in Abschnitt 3.6.3 skizzieren, wie dies erfolgen kann.
Dummerweise haben beide skizzierten kryptographischen Verfahren (und auch das fr Passwrter vorgestellte Challenge-Response-Verfahren) eine Schwachstelle: Ein Angreifer C knnte
versuchen, sich bei B als A auszugeben. Er erhlt von B die zufllige Bitfolge geschickt. Wenn es
ihm gelingt, A dazu zu bringen, diese Bitfolge mit dem entsprechenden Schlssel zu verschlsseln, kann C das Resultat dann an B weiterleiten und sich so erfolgreich als A ausgeben. Dies
kann in bestimmten Fllen verhindert werden, indem die zu unterzeichnende Sequenz neben
einem hinreichend langen zuflligen Wert noch weitere Informationen darber beinhaltet, wo
und fr welchen Zweck die Authentikation genau erfolgt. Ganz ausschlieen kann man solche
Angriffe jedoch auch damit nicht.
Authentikations- und Verschlsselungsverfahren sollten generell Schutz gegen Man-in-theMiddle-Angriffe bieten. Mit diesem Begriff bezeichnet man Attacken, bei denen sich ein Angreifer zwischen die beiden Teilnehmer schaltet und deren Kommunikation in irgendeiner Weise
manipuliert, um die Sicherheitsmechanismen auszuhebeln. Es gibt eine ganze Reihe von Beispielen fr Verfahren, die mit diesen Attacken kompromittiert werden konnten.
Sichere Authentikation ist prinzipiell dann mglich, wenn die Authentikation wechselseitig
ist und die zur Authentikation eingesetzten (privaten) Schlssel zustzlich verwendet werden,
um einen Session Key fr die sptere Verschlsselung der Kommunikation auszuhandeln, wenn
also auf jeder Seite die Kenntnis des zur Authentikation eingesetzten Schlssels spter nochmals notwendig ist, um den ausgehandelten Session Key zu berechnen.
Authentikation ohne sptere Mechanismen zur Verschlsselung oder zumindest zum Integrittsschutz sind ohnehin wenig sinnvoll. Es nutzt nichts, zu wissen, dass B tatschlich eine
Verbindung mit A aufgebaut hat, wenn nicht ausgeschlossen werden kann, dass ein Dritter die
dann ausgetauschten Informationen beliebig verndern kann. In der Praxis ermglichen viele
Authentikationsverfahren daher auch die Vereinbarung von Session Keys fr die anschlieende
Verschlsselung der Kommunikation.
Wie wir schon wissen, sind die Erfolgschancen eines Kryptanalysten um so grer, je mehr
Chiffretext er zur Verfgung hat. Daher empehlt es sich, die verwendeten kryptographischen
Schlssel ab und an auszutauschen. Entsprechend sollte ein zur Authentikation verwendetes
gemeinsames Geheimnis nicht selbst zur Verschlsselung eingesetzt werden. In der Regel wird
daher aus diesem auch als Master Secret bezeichneten Geheimnis whrend der Authentikation
ein Session Key abgeleitet, der dann zur Verschlsselung verwendet wird. Beim Aufbau einer
neuen Verbindung wird mit an Sicherheit grenzender Wahrscheinlichkeit ein Session Key zum
Einsatz kommen, der vorher noch nicht verwendet wurde. Einige Protokolle erlauben es sogar,
Session Keys whrend des Betriebs einer Verbindung zu wechseln.
3.6.2 Digitale Signatur

Wenden wir uns nun der Authentizitt von Nachrichten zu. In der nicht-elektronischen Welt
authentizieren wir Briefe, Bestellungen usw. mit unserer Unterschrift.
53
Eine naive, direkte bertragung dieser Vorgehensweise in die digitale Welt scheitert. Betrachten wir ein Verfahren, bei dem wir zur Authentikation einfach unsere eingescannte Unterschrift
verwenden, etwa als jpg-Datei. Abstrakter formuliert verwenden wir also zur Authentikation
irgendeine binre Information, die wir weitergeben und die uns allgemein ausweisen soll. Es ist
naheliegend, warum dieses Verfahren vollkommen unsicher ist: Wenn die bertragung der Information ber eine unsichere Verbindung erfolgt, knnte ein unbefugter Dritter in Besitz der Datei
gelangen und sich damit mhelos in Zukunft fr uns ausgeben. Selbst wenn die bertragung
ber einen sicheren Kanal erfolgt, gelangt zumindest derjenige, bei dem wir uns ausweisen, in
den Besitz der Information und knnte sie dann ebenfalls missbrauchen. Diese Methode funktioniert also nicht, zumindest nicht ganz so einfach.
Mit digitalen Unterschriften wollen wir die gleichen Ziele wie mit einer nicht-digitalen normalen Unterschrift erreichen: Es geht um Authentizitt, Sicherstellung der Integritt und Verbindlichkeit von Nachrichten. Die Daten werden mit einer digitalen Signatur versehen. Sie erlaubt
die eindeutige Authentikation des Signierenden auch gegenber Dritten und
die Sicherstellung der Integritt der Daten.
Der erste Punkt beinhaltet die Nichtabstreitbarkeit, oft auch Verbindlichkeit genannt. Der Signierende darf hinterher nicht bestreiten knnen, die Signatur gettigt zu haben. Anhand der Daten und der Signatur soll auch Dritten (z.B. einem Gericht) gegenber glaubhaft gemacht werden
knnen, dass genau diese Daten digital unterschrieben wurden. Wenn also ein Vertrag elektronisch unterschrieben ist, soll im Nachhinein beweisbar sein, wer was digital unterschrieben hat.
Unter welchen Voraussetzungen und Rahmenbedingungen digitale Signaturen rechtsverbindlich sind, ist in Deutschland im Signaturgesetz geregelt [SigG]. Die strikten Vorschriften in diesem Gesetz haben mit dazu gefhrt, dass digitale Signaturen im privaten Bereich, etwa bei der
Beantragung von Ausweisen oder der Abgabe der Steuererklrung, in Deutschland bis heute
nahezu keine Rolle spielen.
Digitale Signaturen lassen sich einfach mit Public-Key-Verfahren realisieren. Betrachten wir
hierzu das Authentikationsverfahren aus dem vorangegangenen Abschnitt. Die Authentikation erfolgte, indem eine zufllig gewhlte Bitfolge mittels des privaten Schlssels verschlsselt
wurde.
Das gleiche Verfahren kann im Prinzip auch zur digitalen Signatur verwendet werden: Der
Signierende verschlsselt einfach die gesamten zu unterschreibenden Daten mit seinem privaten
Schlssel. Damit sind Integritt und Authentizitt gewhrleistet. Auerdem kann er spter nicht
abstreiten, die Daten unterzeichnet zu haben. Ein Dritter kann die Unterschrift berprfen, da
der ffentliche Schlssel fr jedermann zugnglich ist. Da nur der Unterzeichner im Besitz des
privaten Schlssels ist, kann auch kein anderer die entsprechende Nachricht unterzeichnet haben.
In der Praxis werden digitale Signaturen noch mit einer wichtigen Verbesserung verwendet:
Anstatt die gesamten Daten zu verschlsseln, werden diese zunchst mittels einer kryptographischen Hashfunktion in eine fr die Nachricht charakteristische Bitfolge fester Lnge umgewandelt. Je nach Verfahren betrgt die Lnge 128 bis 256 Bit. Diese Bitfolge ist fr die ursprnglichen Daten so charakteristisch wie ein Fingerabdruck fr einen bestimmten Menschen. Dieser
54
3 Authentikation
Hashwert wird dann wie oben beschrieben mit dem privaten Schlssel verschlsselt. Damit haben die digitalen Signaturen, unabhngig von den zu unterschreibenden Daten, immer eine feste
Lnge. Es gibt auch Verfahren, die in die Berechnung des Hashwertes direkt die kryptographischen Schlssel miteinbeziehen.
Es ist nicht schwer einzusehen, dass die Flschungssicherheit einer so durchgefhrten digitalen
Signatur stark von den Eigenschaften der verwendeten Hashfunktion abhngt: Wrde die Funktion immer dieselbe Bitfolge liefern (unabhngig von den zu unterschreibenden Daten), dann wre
die Signatur alles andere als schwer zu flschen; eine einmal erhaltene Signatur knnte beliebige Daten beigefgt werden. Es gibt eine ganze Reihe von Kriterien, die eine kryptographische
Hashfunktion sinnvollerweise erfllen sollte. Hierzu zhlt etwa, dass es praktisch unmglich sein
sollte, zwei Daten zu nden, die den gleichen Hashwert liefern oder zu einem gegebenen Hashwert eine Eingabe zu ermitteln, die diesen Hashwert liefert.
Es gibt eine ganze Reihe kryptographischer Hashfunktionen. In der Praxis hug angewendete
Verfahren sind MD5 [RFC 1321] mit einer Hashlnge von 128 Bit oder SHA-256 [FIPS 180-2]
mit einer Hashlnge von 256 Bit. An der Sicherheit von MD5 sind in den letzten Jahren ernsthafte
Zweifel aufgetaucht, trotzdem wird das Verfahren derzeit noch in der Praxis angewendet.
Die Anforderung der Nichtabstreitbarkeit schliet im Prinzip die Verwendung von symmetrischen kryptographischen Verfahren aus (sofern keine weitere vertrauenswrdige Stelle hinzugezogen wird). Da beide Kommunikationspartner im Besitz desselben geheimen kryptographischen Schlssels sind, knnte jeder beliebige Nachrichten fabrizieren und anschlieend mit
dem gemeinsamen Schlssel digital unterschreiben. Wenn nur die Integritt der Daten geschtzt
werden soll, knnen statt der Public-Key-Verfahren auch symmetrische Verfahren zum Einsatz
kommen.
3.6.3 Infrastrukturen zur Authentikation

3.6.3.1 Zertikate und Certicate Authorities
Wenn sich A bei B ber ein Public-Key-Verfahren authentizieren mchte, so ist die Voraussetzung fr die Anwendung des im vorangegangenen Abschnitt skizzierten Verfahrens, dass B im
Besitz des ffentlichen Schlssels von A ist, denn B bentigt diesen Schlssel zur berprfung
der von A vorgelegten Authentikationsdaten.
Wenn A und B vorher noch nie miteinander kommuniziert hatten, ist es unwahrscheinlich,
dass B im Besitz des ffentlichen Schlssels von A ist. Da der ffentliche Schlssel des Schlsselpaars von A jedermann verfgbar gemacht werden kann und soll, erscheint die Lsung des
Problems einfach: A knnte vor Beginn der Authentikation seinen ffentlichen Schlssel an B
selbst bertragen. Danach knnte die Authentikation wie beschrieben erfolgen bzw. eine digitale Signatur berprft werden.
Doch bei diesem Vorgehen kann ein Angreifer die erwnschte Authentikation mit einfachsten Mitteln aushebeln: Ein Dritter, C, knnte einfach ein eigenes Schlsselpaar erzeugen und B
den selbst erstellten ffentlichen Schlssel als den ffentlichen Schlssel von A vorlegen. Die anschlieende Authentikation als A bei B wre ein Kinderspiel. Einem unbekannten ffentlichen
Schlssel darf also keinesfalls einfach ohne weitere berprfung vertraut werden. Wir bentigen
demnach ein Verfahren, um unbekannte ffentliche Schlssel verizieren zu knnen.
55
Zertifikat von A
Identitt
CA verifiziert
und signiert
Public Key
Signatur
der CA
Abbildung 3.3: Zertikat.
Eine Methode hierzu sind sogenannte Certicate Authorities (CA). Diese sind vom Arbeitsprinzip her einem Notar hnlich.
Zunchst wird der ffentliche Schlssel zusammen mit wichtigen Informationen ber seinen
Besitzer (oder besser gesagt den Besitzer des zugehrigen privaten Schlssels) in einem sogenannten Certicate Request zusammengefasst. Eine Certicate Authority nimmt entsprechende
Anfragen nach Zertikaten entgegen, berprft vorgelegte Daten auf ihre Richtigkeit und beglaubigt dann die Echtheit durch die Ausstellung eines Zertikats, das durch die Certicate Authority digital signiert ist. Hierbei kommt wiederum ein Public-Key-Verfahren zum Einsatz. Die
CA unterschreibt unter Verwendung ihres privaten Schlssels. Ein Zertikat ist in Abbildung 3.3
dargestellt. Eine CA muss die Aufgabe der berprfung der vorgelegten Informationen nicht
notwendigerweise selbst durchfhren, sondern kann damit eine Registration Authority (RA) beauftragen, welche die Authentizitt der vorgelegten Daten berprft. Dabei wendet die RA von
der CA vorgegebene Kriterien an.
Wird ein unterschriebenes Zertikat prsentiert, kann ein Benutzer die digitale Unterschrift der
CA durch Verwendung deren ffentlichen Schlssels berprfen. Die CA selbst besitzt ebenfalls
ein Zertikat, dem der ffentliche Schlssel entnommen werden kann. Ist also ein Zertikat von
einer CA besttigt worden (und man vertraut der CA), dann wei man also, zu wem der in dem
Zertikat enthaltene ffentliche Schlssel gehrt.
Doch die Sache hat einen kleinen Haken. Das Verfahren funktioniert nur, wenn man dem
Zertikat der CA vertraut. Das Problem hat sich also eigentlich nur von der Frage, ob man dem
Zertikat des Kommunikationspartners vertrauen kann, auf die Frage verlagert, ob man dem
Zertikat der CA vertrauen kann.
Wenn das Zertikat der CA von einer anderen CA unterschrieben ist, dann kann das Problem
zwar von einer auf die nchste Instanz verlagert werden, aber gelst wird es dadurch nicht.
An irgendeiner Stelle muss eine Vertrauensbeziehung bestehen oder einfach angenommen
werden, um dieses Prinzip anwenden zu knnen. In der Praxis gibt es Root-CAs, die ihre Zertikate selbst unterschreiben und denen implizit vertraut wird. Um einem Missbrauch vorzubeugen,
56
3 Authentikation
Root CA
Zertifikat
Root CA
CA Alpha
Zertifikat
CA Alpha
signiert durch:
Root CA
signiert durch:
Root CA
CA Beta
Zertifikat
CA Beta
signiert durch:
Root CA
CA
Gamma
CA Gamma
Zertifikat
signiert durch:
Root CA
CA Gold
Zertifikat
CA Gold
signiert durch:
CA Alpha
User X
Zertifikat
User X
signiert durch:
CA Gold
Abbildung 3.4: Hierarchie von Certicate Authorities.
sind die Zertikate von bekannten Root-CAs bei vielen Anwendungen und Systemen bereits vorinstalliert.
Wird ein Zertikat vorgelegt, das von der Root-CA unterschrieben wurde, so gilt dieses als
vertrauenswrdig. Doch nicht alle Zertikate mssen direkt von der Root-CA unterschrieben
worden sein. Die Root-CA kann auch Zertikate von anderen CAs unterschreiben, diese CAs
knnen wiederum Zertikate weiterer CAs unterschreiben und so weiter. Auf diese Weise entsteht ein Baum, an dessen Wurzel die Root-CA steht. Das Vertrauen in die Root-CA bertrgt
sich transitiv auf alle Knoten und Bltter des Baumes. Dies ist in Abbildung 3.4 gezeigt. Die
Root-CA hat CAs Alpha, Beta und Gamma zertiziert. Alpha hat eine weitere CA Gold zertiziert, die wiederum ein Zertikat fr Benutzer X beglaubigt hat. Bei Vorlage des Zertikats
von X wrde ein Benutzer Y, welcher der Root-CA vertraut, das Zertikat von X ebenfalls als
vertrauenswrdig einstufen. Die Vertrauenswrdigkeit des Zertikats wird dabei berprft, indem die Zertizierungshierarchie solange zurckverfolgt wird, bis Y auf eine CA trifft, die als
vertrauenswrdig gilt, in unserem Fall bis zur Root-CA. Hierzu ist es auch notwendig, die Zertikate der CA Gold und der CA Alpha zu erhalten. Dies ist etwa ber ein Netzwerk mglich.
Das Konzept von CAs und Zertikaten hat eine ganze Reihe von Vorteilen:
Zertikate sind ffentlich und nicht geheim. Daher knnen sie in ffentliche Verzeichnisse
in Netzwerken eingestellt und auf Webseiten bekanntgegeben werden.
Die CA selbst ist bei einer Authentizierung mit einem von ihr ausgestellten Zertikat
57
nicht involviert. Daher muss die CA nicht ber ein Netzwerk oder anderweitig erreichbar
sein. Dies mindert die Wahrscheinlichkeit, dass ein Angreifer die CA kompromittieren
kann und schliet auerdem Angriffe auf deren Verfgbarkeit aus.
Der CA muss bei der Ausstellung eines Zertikats nur der ffentliche, nicht aber der private Schlssel vorgelegt werden. Der private Schlssel bleibt auch gegenber der CA geheim,
so dass die CA keine Informationen hat, die es ihr ermglichen wrden, Verschlsselungen
zu brechen, die mit einem von ihr ausgestellten Zertikat erfolgen.
Ein gewisses Misstrauen gegen dieses Konzept ist aber durchaus auch berechtigt. In vielen
Anwendungen ndet sich eine groe Anzahl an vorinstallierten Zertikaten von Root-CAs, und
es ist sehr unwahrscheinlich, dass alle die gleichen Sicherheitsstandards bei der Ausstellung
von Zertikaten (auch fr weitere CAs) anwenden. Auerdem kann durchaus in Frage gestellt
werden, inwieweit das Signieren eines Zertikats einer anderen CA durch eine Root-CA die Vertrauenswrdigkeit dieser CA und von ihr unterschriebener Zertikate sicherstellt. In der Praxis
scheint dieses Konzept jedoch bisher erstaunlich gut zu funktionieren.
Zertikate werden in der Regel mit einem Datum versehen, bis wann sie gltig sind. Doch knnen Zertikate auch vor diesem Ablaufdatum zurckgezogen werden mssen, etwa da der zum
zertizierten ffentlichen Schlssel gehrende private Schlssel einem Angreifer in die Hnde
gefallen ist oder weil der Mitarbeiter, fr den das Zertikat erstellt wurde, die Institution verlassen hat. Das Zurckziehen einmal erstellter Zertikate ist relativ problematisch. Einem einmal
erstellten gltigen Zertikat sieht man nicht an, ob es zurckgezogen worden ist oder nicht. Daher muss fr jede CA eine Liste zurckgezogener Zertikate erstellt werden, die sogenannte
Certicate Revocation List (CRL). In diese Liste werden alle zurckgezogenen Zertikate eingetragen. Wenn die Gltigkeit eines Zertikats berprft wird, muss ein Abgleich gegen diese
Liste vorgenommen werden.
Fassen wir diese Nachteile kurz zusammen:
Die Vertrauenswrdigkeit eines Zertikats ist nur gegeben, wenn die Root-CA und alle
weiteren am Zertizierungsprozess mittelbar beteiligen CAs vertrauenswrdig sind.
Wird eine CA durch einen Angreifer kompromittiert, ergeben sich schwerwiegende Missbrauchsmglichkeiten.
Das Zurckziehen erstellter Zertikate kann nur ber CRLs erfolgen, was in der Praxis
schwierig ist.
3.6.3.2 Zertikate in der Praxis: X.509
In der Praxis nden sich am hugsten Zertikate nach der ITU-Spezikation X.509 [X.509].
Dieser Standard gibt einen Rahmen vor, der in verschiedenen Anwendungszenarien zum Einsatz
kommen kann, indem fr jedes Einsatzgebiet ein Prol festgelegt wird. Es gibt verschiedene Anwendungsprole fr X.509. Hier werden wir die in [RFC 3280] festgelegte Verwendung solcher
Zertikate im Internet betrachten. Die neueste Version von X.509 ist Version 3.
Ein X.509-Zertikat enthlt Informationen ber das zertizierte Objekt (Person, Rechner ...)
und die Certicate Authority, die das Zertikat ausgestellt hat, sowie deren Unterschrift. Unter
anderem enthlt das Zertikat Felder mit folgenden Informationen:
58
3 Authentikation
Version: Gibt die verwendete X.509-Version an. Der Wert 0 reprsentiert Version 1, Wert 1
reprsentiert Version 2 und Wert 2 reprsentiert Version 3. Ist die Versionsnummer 1 kann
dieses Feld weggelassen werden.
Serial Number: Seriennummer des Zertikats. Mit der Seriennummer kann das Zertikat
bei der ausstellenden Certicate Authority eindeutig identiziert werden.
Signature Algorithm: Speziziert das verwendete kryptographische Verfahren, mit dem
die Certicate Authority das Zertikat unterschrieben hat. Mgliche Verfahren sind in
[RFC 3279] festgelegt. Das Feld hat zwei Teile, in denen zum einen der Algorithmus wie
ebenfalls in [RFC 3279] festgelegt angegeben wird und zum anderen Parameter fr den
Algorithmus.
Issuer: Gibt eindeutig die Certicate Authority an, die das Zertikat ausgestellt hat. Dies
geschieht durch Angabe des sogenannten Distinguished Name der Certicate Authority,
siehe unten.
Validity: Gibt die Gltigkeitsdauer des Zertikats an. Whrend der Gltigkeitsdauer hlt
die ausstellende Certicate Authority Informationen bereit, ob das Zertikat widerrufen
wurde oder nicht. Die Angabe der Gltigkeitsdauer erfolgt durch die Angabe des frhestmglichen Zeitpunkts, zu dem das Zertikat verwendet werden darf (Feld not before) und
des sptestmglichen Verwendungszeitpunkts (Feld not after).
Subject: Name des durch das Zertikat ausgewiesenen Objekts, entweder durch Angabe
eines Distinguished Name (siehe unten) oder durch andere Strukturen.
Subject Public Key Info: Dieses Feld speziziert den zu verwendenden Verschlsselungsalgorithmus und besteht aus zwei Teilen:
Algorithm Identier: Spezizierung des verwendeten Algorithmus wie beim Feld
Signature Algorithm Identier.
Subject Public Key: ffentlicher kryptographischer Schlssel fr das Verfahren.
Extensions (nur Version 3): Folge von Elementen der Form
Extension ID,
Critical,
Extension Value.
[RFC 3280] speziziert eine Reihe von Extensions, auf die wir hier nur sehr knapp eingehen wollen. Unter anderem gibt es eine Extension (Basic Constraints), mit der festgelegt
werden kann, ob das ausgestellte Zertikat zum Ausstellen weiterer Zertikate berechtigt
(also einer CA gehrt). Zudem lsst sich die Lnge von Zertikatsketten einschrnken.
Eine weitere Extension (Key Usage) erlaubt es, den Verwendungszweck des im Zertikat
enthaltenen ffentlichen Schlssels zu beschrnken.
Signature Algorithm: Nochmalige Angabe des kryptographische Verfahren, mit dem die
Certicate Authority das Zertikat unterschrieben hat. Dieser Wert muss mit dem obigen
bereinstimmen.
59
Signature Value: Digitale Signatur ber die vorangegangenen Werte durch die Certicate
Authority.
Die Felder Issuer und Subject geben den Namen der ausstellenden Certicate Authority und
den Namen des Objekts an, fr welches das Zertikat ausgestellt wurde. Stellt eine Certicate
Authority ein Zertikat aus, so muss sie in das Feld Issuer Name dieses Zertikats denselben
Namen eintragen, der sich im Feld Subject Name ihres Zertikats bendet. Die Namen in Zertikaten sind in den meisten Fllen Distinguished Names wie in [X.501] beschrieben. Sie bestehen
aus Attributen und zugehrigen Werten. In Zertikaten mit Distinguished Names nden sich
hug folgende Attribute wie
Country: Land, dem das Objekt zugeordnet ist.
Organization: Institution, der das Objekt zugeordnet ist.
Organizational Unit: Abteilung.
Common Name: Name (Max Maier oder auch Server 524).
Nach [RFC 3280] knnen brigens fr die Objekte, fr welche die Zertikate ausgestellt wurden, anstelle eines Distinguished Names auch andere Namensformate zum Einsatz kommen, wie
beispielsweise Email-Adressen, DNS-Domainnamen, IP-Adressen oder URIs.
3.6.3.3 Beispiel: X.509 Zertikate mit OpenSSL selbst erstellen
Die bisherigen Ausfhrungen klangen etwas theoretisch. Deshalb wollen wir nun ein praktisches
Beispiel der Erstellung eines Zertikats und einer Certicate Authority mit OpenSSL betrachten.
OpenSSL ist eine Open-Source Implementierung der SSL/TLS-Protokollfamilie, die wir in
Abschnitt 13.3.3 noch genauer betrachten werden. Diese Protokolle verwenden X.509-Zertikate. Daher besitzt OpenSSL eine Reihe von Funktionen, die das Erstellen von Zertikaten und
sogar den Betrieb einer Certicate Authority erlauben. Nhere Informationen zu OpenSSL nden
sich unter [OpenSSL-Web].
Im Folgenden skizzieren wir, wie man unter Linux mit OpenSSL per Shell eine einfache Certicate Authority aufbauen und betreiben kann. Wir werden dabei nur auf einige wenige Details
eingehen.
Als Erstes mssen wir fr die Certicate Authority selbst ein Zertikat erstellen. Dies geschieht mit dem Befehl
Dieser Befehl veranlasst die Erstellung eines neuen Zertikats mit einer Gltigkeitsdauer von
30 Tagen (Option
). Fr die Erstellung von Zertikaten gibt es viele weitere Optionen.
Auerdem besitzt OpenSSL Kongurationsdateien, in denen Standardeinstellungen vorgenommen werden knnen. Exemplarisch haben wir hier nur die Option verwendet, die Gltigkeitsdauer des Zertikats auf 30 Tage festzulegen. Nach Eingabe des Befehls werden Informationen ber
den Zertikatsinhaber abgefragt, die sich dann in dem Zertikat wiedernden. Nach Abschluss
wird ein Schlsselpaar erzeugt. Der private Schlssel ndet sich in der Datei
, das
60
3 Authentikation
Zertikat (inklusive des zugehrigen ffentlichen Schlssels) in der Datei

. Der
private Schlssel ist durch ein Passwort geschtzt, das bei der Generierung gewhlt wird und
dann bei jeder Verwendung des privaten Schlssels eingegeben werden muss.
Mit dem Befehl
knnen wir uns das entstandene Zertikat genauer anschauen. Da Sie wahrscheinlich genauso
wenig Interesse haben, Zahlenkolonnen mit der Hand nachzurechnen, wie ich, werden wir die
Schlssel und Signaturen krzen und diese Auslassungen mit (...) kennzeichnen:
Wie man sehen kann, ist dieses Zertikat selbst-signiert, Issuer und Subject stimmen berein.
Dies ist fr unsere Zwecke richtig, da wir es als Root-Zertikat verwenden mchten (ohne es
von einer anderen Certicate Authority verizieren zu lassen).
61
Im Zertikat sind die Felder zu erkennen, die wir oben bereits theoretisch betrachtet hatten.
Auch einige Extensions, auf die wir hier nicht weiter eingehen wollen, sind in dem Zertikat
enthalten.
Nun wollen wir dieses Zertikat benutzen, um eine einfache Certicate Authority zu betreiben
und ein Zertikat fr einen Mitarbeiter der Testrma zu erstellen. Die durch OpenSSL bereitgestellte CA speichert in der Standardeinstellung die fr Erstellung und Management notwendigen
Daten im Verzeichnis
. Wir erstellen zunchst dieses Verzeichnis und legen dort eine leere Datei mit dem Namen
an. In dieser Datei speichert die CA Informationen ber
von ihr signierte Zertikate. Auerdem erstellen wir dort noch eine Datei
. Die CA nummeriert von ihr signierte Zertikate durch und speichert die Nummer des nchsten Zertikats
in dieser Datei. Daher schreiben wir 01 in die Datei. Auerdem legen wir in
noch
ein Verzeichnis mit dem Namen
an. Damit ist die (primitive) Certicate Authority
betriebsbereit.
Nun wollen wir ein Zertikat fr den Mitarbeiter Max Mustermann erstellen. Als Erstes erzeugen wir einen Certicate Request, den die Certicate Authority dann bearbeiten kann:
Dieser Befehl ist hnlich zu dem Befehl, mit dem wir ein selbst-signiertes Zertikat fr die
Certicate Authority erzeugt haben. Er erzeugt ein Schlssepaar mit einem privaten (wiederum
passwortgeschtzten) Schlssel und einem ffentlichen Schlssel, der in das Zertikat eingebettet wird. Nun wollen wir den Certicate Request durch die Certicate Authority signieren lassen.
Hierzu verwenden wir den Befehl
Der Request wird angezeigt und man wird gefragt, ob er signiert werden soll. Zum Signieren wird
der private Schlssel der Certicate Authority verwendet und es ist das entsprechende Passwort
einzugeben. Das entstandene Zertikat ist das erste von der CA erzeugte, daher wird es unter
abgelegt. Wenn man sich das Zertikat mit
anzeigen lsst, so erscheint:
62
3 Authentikation
Issuer des Zertikats ist also die von uns geschaffene Certicate Authority und Subject ist
Max Mustermann. Wiederum sind die aus dem vorangegangenen Abschnitt bekannten Felder
mit entsprechenden Inhalten zu sehen.
Bevor wir uns der Frage zuwenden, was man mit diesem Zertikat anfangen kann, lohnt ein
Blick auf die vorhin bereits erwhnten Datei
und
der Certicate Authority.
In der Datei
steht nun der Wert 02, denn das Zertikat mit der Seriennummer 01 wurde
ja gerade ausgestellt. In der Datei
fhrt die CA Buch ber die bisher ausgestellten
Zertikate. Dort ndet sich nun folgende Zeile fr das gerade ausgestellte Zertikat:
Der Buchstabe V (fr valid) besagt, dass das Zertikat gltig ist. Widerrufene Zertikate werden mit einem R (fr revoked) gekennzeichnet. Der zweite Eintrag gibt das Datum der Ausstellung und gegebenenfalls das Datum des Widerrufs des Zertikats an. Darauf folgt die Seriennummer des Zertikats. Der vierte Eintrag (unknown) wird derzeit nicht verwendet und der
letzte Eintrag enthlt das Subject des Zertikats.
Nun mchte unser Benutzer Max Mustermann das Zertikat verwenden, um es zum Signieren und Verschlsseln von Emails zu verwenden. Hierzu mssen das Zertikat und der private
Schlssel zunchst in ein Format (PKCS #12) gebracht werden, das sich einfach in den verwendeten Email-Agenten, in unserem Fall Mozilla Thunderbird [Moz-Web], integrieren lsst.
OpenSSL bietet hierzu den Befehl
63
Abbildung 3.5: Import eines privaten Schlssels und Zertikat in Thunderbird.
Mit diesem Befehl werden privater Schlssel und das Zertikat in einer Datei zusammengefasst,
die sich in Thunderbird ber den Dialog zum Importieren eigener Zertikate importieren lsst.
Abbildung 3.5 zeigt die Darstellung des Zertikats in Thunderbird.
Wie in der Abbildung zu erkennen ist, meldet Thunderbird Could not verify this certicate
because the issuer is unknown. Das trifft den Nagel auf den Kopf, niemand hat bisher etwas
von unserer Zertizierungsstelle gehrt. Daher wollen wir nun das Zertikat der CA ebenfalls in
Thunderbird importieren. Hierzu konvertieren wir das Zertikat der CA mit
nun in das
DER-Format, welches Thunderbird kennt. Dies geschieht mit dem Befehl
Durch diesen Befehl wird ausschlielich das ffentliche Zertikat der CA umformatiert, die
resultierende Datei enthlt nicht den privaten Schlssel der CA. Importiert man dieses CA als
Zertikat einer Root-CA, erscheint das in Abbildung 3.6 gezeigte Dialogfenster, in dem man
festlegen kann, fr welche Zwecke das Zertikat akzeptiert werden soll.
Wird dieses Zertikat importiert, so verschwindet die zitierte Warnung vor dem Zertikat von
Max Mustermann.
64
3 Authentikation
Abbildung 3.6: Dialog beim Import eines Zertikats in Thunderbird.
Abbildung 3.7: Meldung beim Empfang einer Email mit einem von einer unbekannten Certicate Authority
signierten Zertikat.
Max kann, egal ob er das Zertikat der CA noch importiert oder nicht, das vorher importierte
eigene Zertikat mit dem privaten Schlssel verwenden, um Emails zu signieren und zu verschicken. Hierbei kommt S/MIME zum Einsatz. Details dieses Standards werden in Abschnitt 13.1.3
vorgestellt. Der Empfnger der Email wird ebenfalls gewarnt, dass das Zertikat von einer CA
stammt, welcher er nicht vertraut. Die entsprechende Meldung ist in Abbildung 3.7 gezeigt.
Importiert der Empfnger das Zertikat unserer CA in sein Email-Programm, so verschwindet
diese Warnung und die Signatur wird von Thunderbird anerkannt.
3.7 Zusammenfassung
65
3.6.3.4 Web of Trust

Es gibt noch andere Konzepte, wie Vertrauenswrdigkeit hergestellt werden kann. Eines dieser
Verfahren ist als Web of Trust bekannt. Dessen Konzept basiert nicht auf der Existenz einer vertrauenswrdigen Instanz, von der aus sich das Vertrauen automatisch transitiv ausbreitet, sondern
berlsst die Vertrauensbildung den Benutzern untereinander.
Beim Web of Trust gibt es keine CAs. Jeder Benutzer besitzt nach wie vor einen private Key
und ein ffentliches Zertikat (bleiben wir einfach bei diesem Ausdruck), in dem Informationen ber die Identitt des Benutzers sowie der zum privaten Schlssel gehrende ffentliche
Schlssel gespeichert sind. Dieses Zertikat stellt sich jeder Benutzer selbst aus. Wenn ein
Nutzer ein Zertikat eines anderen Nutzers erhlt und es fr vertrauenswrdig erachtet, kann
er dieses Zertikat mit seinem privaten Schlssel unterschreiben. Ein Zertikat kann von
beliebig vielen anderen Benutzern unterschrieben werden.
Auf diese Weise entsteht ein Web of Trust. Jeder Benutzer kann selbst entscheiden, welchen
vorgelegten Zertikaten er vertraut. Er kann dieses Vertrauen durch Signieren des Zertikats
auch ffentlich machen. Darber hinaus kann ein Benutzer bestimmen, welche anderen Benutzer
(deren Zertikate er kennt) er fr vertrauenswrdig genug erachtet, um deren Unterschrift
unter einem Zertikat als Echtheitsnachweis anzuerkennen. Wenn Sie Paul Maier noch nicht
kennen, er aber ein Zertikat vorlegen kann, das von den Nutzern Hans Mller, Werner Schmidt
und Klaus Schulze unterschrieben ist, die Sie allesamt kennen und denen Sie vertrauen, dann
knnen Sie auch das Zertikat von Paul Maier akzeptieren. Das vorliegende Beispiel verdeutlicht
bereits, dass dieses Konzept sehr viel besser dazu geeignet ist, graduelle Vertrauensbeziehungen
zu modellieren.
Das Konzept des Web of Trust wurde von Phil Zimmerman fr sein Programm Pretty Good
Privacy (PGP) entworfen, das mittlerweile zu OpenPGP [RFC 2440] weiterentwickelt wurde.
Eine Implementierung von OpenPGP ist der GNU Privacy Guard (GPG) [GnuPG-Web].
3.7 Zusammenfassung
Authentizitt und Authentikation, also die eindeutige Identikation des Absenders
von Information bei der Informationsbertragung und die eindeutige Identikation
von Kommunikationspartnern sind wichtige Ziele der IT-Sicherheit.
Ganz allgemein basiert die Authentikation von Benutzern und Maschinen auf einem
oder mehreren der Faktoren Wissen, Objekte oder persnliche Merkmale, das oder die
der zu Authentiziende besitzt.
Hug zum Einsatz bei der Authentikation kommen Passwrter, die im Prinzip hnlich wie ein symmetrischer kryptographischer Schlssel verwendet werden. Die Sicherheit des Einsatzes von Passwrtern hngt von der Gre des Passwortraums, der
Wahl des Passwort, den Policies, der Sicherheit der Passwortspeicherung und der Sicherheit bei Eingabe und bertragung von Passwrtern ab.
66
3 Authentikation
Passwortbasierte Verfahren werden mehr und mehr durch Tokens und Smart-Cards
abgelst, da sie in vielerlei Hinsicht ein hheres Ma an Sicherheit bieten. Auch biometrische Verfahren werden zunehmend eingesetzt, auch wenn diese derzeit noch mit
erheblichen Problemen behaftet sind und daher noch keine ernsthafte Alternative zu
den anderen Verfahren bieten knnen.
Die Authentikation eines Kommunikationspartners ist auch durch kryptographische
Methoden mglich. Durch digitale Signaturen, die im Wesentlichen auf Public-KeyKryptographie basieren, kann die Integritt einer Nachricht berprft und deren Absender verbindlich authentiziert werden. Hierzu ist es notwendig, dass die dabei verwendeten ffentlichen Schlssel eindeutig einem bestimmten Kommunikationspartner zugeordnet werden knnen. Eine Mglichkeit, dies sicherzustellen, ist die Verwendung von Zertikaten, die durch sogenannte Certicate Authorities signiert wurden, denen der die Authentikation durchfhrende Teilnehmer vertraut. Hierarchische
Strukturen sind dabei mglich.
3.8 bungsaufgaben
Aufgabe 3.1:
Erklren Sie die Begriffe Authentikation und Authentizitt. Erlutern Sie mgliche Faktoren bei der Authentikation von Benutzern. Gehen Sie dabei auch auf den Begriff Mehrfaktorauthentikation ein.
Aufgabe 3.2:
Nennen und erlutern Sie, von welchen Punkten die Sicherheit passwortbasierter Verfahren abhngt.
Aufgabe 3.3:
Beurteilen Sie die folgenden Passwrter hinsichtlich ihrer Sicherheit:
Aufgabe 3.4:
Berechnen Sie, welche Passwortlnge bei einem durch die Zeichen a-z gebildeten Passwort erforderlich ist, damit die Anzahl mglicher Passwrter der eines binren Schlssels mit 128 Bit
entspricht.
3.8 bungsaufgaben
67
Aufgabe 3.5:
Beschreiben Sie den Ablauf einer passwortbasierten Challenge-Response-Authentikation und
vergleichen Sie deren Sicherheit mit der bertragung des Passworts selbst ber eine verschlsselte oder unverschlsselte Verbindung.
Aufgabe 3.6:
Erlutern Sie die Begriffe Token, Smart-Card und Biometrie. Erklren Sie deren Verwendung zur Authentikation von Benutzern.
Aufgabe 3.7:
Erlutern Sie, wie kryptographische Verfahren zur Authentikation verwendet werden knnen.
Aufgabe 3.8:
Beschreiben Sie wofr digitale Signaturen eingesetzt werden und wie sie funktionieren. Erlutern
Sie ebenfalls, welche Rolle Hashfunktionen bei digitalen Signaturen spielen.
Aufgabe 3.9:
Beschreiben Sie Aufbau und Funktionsweise von Zertikaten. Gehen Sie dabei insbesondere auf
die Begriffe Certicate Authority, Root-CA und Certicate Revocation ein.
Aufgabe 3.10:
Geben sie die Vor- und Nachteile einer Verwendung von Zertikaten und CAs an.

Aufgabe 3.11:
Informieren Sie sich ber die genaue Funktionsweise von Hashfunktionen. Lesen Sie die Spezikationen von SHA [FIPS 180-2] und MD5 [RFC 1321] und fassen Sie sie zusammen.
Aufgabe 3.12:
Stellen Sie Vor- und Nachteile von Einmalpasswrtern gegenber gewhnlichen Passwrtern
zusammen und vergleichen Sie sie.
Aufgabe 3.13:
Betrachten wir nochmals Abbildung 3.1, welche die Authentikation mittels eines Passworts
ber ein Netzwerk mittels Challenge-Response zeigt. Diskutieren Sie, inwieweit die Verwendung
dieses Verfahrens auch dann mglich ist, wenn statt des (geheimen) Passworts auf dem Server
nur ein (ffentlicher) Hash des Passworts gespeichert ist (analog zu Abschnitt 3.3.2). Analysieren
Sie insbesondere die Sicherheit eines solchen Verfahrens.
68
3 Authentikation
Aufgabe 3.14:
Nehmen Sie an, einem Angreifer gelingt es, einen Webserver zu kompromittieren, der ein Verzeichnis mit Zertikaten bereitstellt. Er hat die Mglichkeit, beliebige Daten zu lschen, zu modizieren oder einzufgen. Diskutieren Sie die mglichen Konsequenzen eines solchen Angriffs.
Erlutern Sie insbesondere, inwieweit dies die Sicherheit der ausgestellten Zertikate beeintrchtigt.
Aufgabe 3.15:
Nehmen Sie an, einem Angreifer gelingt es, vollstndigen Zugriff auf eine CA zu erhalten. Er
kann also schalten und walten, wie er mchte. Diskutieren Sie die mglichen Konsequenzen
eines solchen Angriffs.
Aufgabe 3.16:
Informieren Sie sich ber OpenPGP und erlutern Sie detailliert dessen Funktionsweise.
Aufgabe 3.17:
Eine weitere Mglichkeit fr eine Authentikationsinfrastruktur ist der Betrieb von Key Distribution Centern (KDC). Erlutern Sie deren Arbeitsweise und vergleichen Sie sie mit CAs.
Kapitel 4
Betriebssysteme
4und
Betriebssysteme
und ihre Sicherheitsaufgaben
ihre
Sicherheitsaufgaben
4.1 Aufgaben und Aufbau von Betriebssystemen
Moderne Computersysteme (kurz System) bestehen aus verschiedensten Komponenten wie Prozessoren, Speicher, Festplatten, optischen Laufwerken, Tastatur, Maus, Monitor, Drucker und
Scanner. Fr all diese Komponenten existiert eine groe Auswahl an Produkten verschiedener
Hersteller. Die jeweils verwendete Hard- und Software und die Schnittstellen zu deren Verwendung knnen sich selbst bei Komponenten gleichen Typs stark unterscheiden. Oftmals dienen Komponenten unterschiedlichen Typs, wie etwa Festplatte, optische Laufwerke und USBSpeichersticks dem gleichen Zweck. Wrde man beim Implementieren einer Anwendung Rcksicht auf all diese Unterschiede nehmen mssen, wre es nahezu unmglich, sie in akzeptabler
Zeit und zu vertretbaren Kosten zu erstellen. Jedesmal, wenn eine neue Hardwarekomponente
auf den Markt kme, msste die Anwendung gendert werden und nur diese neue Version wrde
mit der neuen Komponente arbeiten knnen. Betriebssysteme lsen dieses Problem auf elegante
Weise, indem sie zu den Komponenten des Systems abstrakte Schnittstellen wie beispielsweise
ein Dateisystem bereitstellen, so dass Anwendungsprogramme unabhngig von konkreten Hardund Softwaredetails entwickelt und betrieben werden knnen. Die Kapazitt von Grorechnern
und Servern erlaubt es auerdem, dass mehrere Benutzer und/oder mehrere Anwendungen das
System gleichzeitig verwenden knnen. Viele der Ressourcen eines Systems knnen aber zu einem festen Zeitpunkt nur von jeweils einer Anwendung benutzt werden. Die Verwaltung und
Verteilung der Systemressourcen bernimmt ebenfalls das Betriebssystem. Dabei erscheint es
jedem einzelnen Anwender so, als wrde er das System alleine benutzen.
Nach der guten alten DIN-Norm 44330 versteht man unter einem Betriebssystem die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften der Rechenanlage
die Grundlage der mglichen Betriebsarten des digitalen Rechensystems bilden und insbesondere
die Abwicklung von Programmen steuern und berwachen. Hauptaufgaben des Betriebssystems
sind wie oben beschrieben
die Bereitstellung abstrakter Schnittstellen fr Anwendungsprogramme (die sogenannte
erweiterte Maschine) und
das Verwalten der Systemressourcen, d.h. das Aufteilen der Ressourcen auf verschiedene
Anwendungen und Benutzer.
Neben dem eigentlichen Betriebssystem umfassen moderne Betriebssystemdistributionen eine
Vielzahl weiterer Hilfsprogramme und Anwendungen. Diese sind kein Teil des Betriebssystems
im engeren Sinn.
70
4 Betriebssysteme und ihre Sicherheitsaufgaben
In einem Rechner gibt es eine ganze Reihe von Ressourcen, die verwaltet werden mssen. Das
beginnt mit dem Prozessor oder den Prozessoren des Systems, die den verschiedenen Prozessen
zugeordnet werden mssen. Aufgrund des hugen Wechsels zwischen verschiedenen Prozessen
entsteht fr die Benutzer des Systems selbst in einem Einprozessorsystem der Eindruck, dass
mehrere Prozesse gleichzeitig ablaufen. Man spricht daher von Pseudoparallelitt.
Betriebssysteme sind ein fundamentaler Bestandteil heutiger Computersysteme, und es gibt
zahlreiche sehr gute Lehrbcher, die dieses Thema umfassend darstellen, beispielsweise [Tan02],
[Sta03], [Gla06], [Vog01] oder [EKR+ 05].
Es ist bei IT-Systemen letztlich nicht anders als im richtigen Leben auch: Die Verwaltung von
Ressourcen ist immer mit Sicherheitsaspekten verbunden. Ein Hausmeister, der einer ihm unbekannten Person einfach einen Generalschlssel aushndigt, knnte dies spter bitter bereuen. Er
sollte vorher eindeutig feststellen, wer die Person ist und dann prfen, ob diese Person tatschlich befugt ist, einen Generalschlssel zu erhalten. Bei der Verwaltung von Ressourcen stehen
also Authentikation und Autorisation im Vordergrund. Wenn sichergestellt werden kann, dass
nur ein Berechtigter (z.B. ein bestimmter Benutzer) Zugriff auf eine Ressource (z.B. eine Datei)
hat, dann sind Vertraulichkeit und Integritt dieser Ressource gewhrleistet.
Somit muss also in einem Betriebssystem ein Berechtigungskonzept implementiert sein, mit
dem sich festlegen lsst, welcher Benutzer was darf, und das System muss in der Lage sein, die
einzelnen Benutzer zu authentizieren. Die meisten Betriebssysteme tun dies, indem fr jeden
Benutzer zunchst ein Benutzerkonto, hug auch Account genannt, angelegt werden muss. Jedes Benutzerkonto erhlt einen eindeutigen Namen. Bevor der Benutzer das System verwenden
kann, muss er sich einloggen, indem er den Namen seines Benutzerkontos eingibt und sich authentiziert, meistens durch Eingabe eines Passworts. Diese Prozedur bezeichnet man auch als
Login oder Sign-In. Ist der Benutzer mit seinen Ttigkeiten fertig, meldet er sich beim System
wieder ab (Logout oder Logoff).
Das einfachste umzusetzende Berechtigungskonzept ist es jedoch, keine expliziten Berechtigungen zu vergeben und zu verwalten. Jeder, der sich an den Rechner setzt, ist zu allem befugt. So
absurd dies zunchst klingen mag: Viele Betriebssysteme fr Heim-PCs basierten frher auf genau diesem Konzept, und noch heute sind viele Anwender nicht davon zu berzeugen, warum
sie bei Ihrem heimischen PC, den nur sie selbst nutzen, den Zugriff auf das System beschrnken
sollten.
Viele Systeme heute sind auf Mehrbenutzerbetrieb ausgelegt. Dies bedeutet, dass mehrere Benutzer gleichzeitig auf dem System aktiv sein knnen oder verschiedene Benutzer nacheinander
auf dem System arbeiten, etwa an einem PC im Rechnerraum einer Hochschule. Die Ressourcen eines Benutzers mssen in beiden Fllen vor unbefugtem Zugriff durch andere Benutzer
geschtzt werden.
Obwohl wir bisher nur von Benutzern gesprochen haben, muss nicht jede Aktivitt auf einem
System, auch Prozess genannt, durch einen Benutzer direkt angestoen worden sein. Einige Prozesse knnten auch bereits beim Hochfahren des Systems, dem Systemstart initiiert worden und
automatisch gestartet worden sein. Ein Prozess ist vereinfacht ausgedrckt ein Programm zur
Laufzeit, also das Programm mit allen im Verlauf der Programmabwicklung entstandenen Daten und den Attributen des Programms. In einem System sind zu einem Zeitpunkt in der Regel
mehrere Prozesse gleichzeitig aktiv. In Systemen, die auf Mehrbenutzerbetrieb ausgelegt sind,
ist jeder Prozess eindeutig einem Benutzerkonto zugeordnet, auch die automatisch gestarteten
Prozesse.
4.2 Systemadministratoren
71
Manche Betriebssysteme verfgen sogar ber Benutzerkonten, fr die kein realer Benutzer
existiert, sondern die ausschlielich fr bestimmte automatisch gestartete Prozesse verwendet
werden. Das Betriebssystem autorisiert Prozesse gem den Rechten des Benutzerkontos, denen
der Prozess zugeordnet ist. Darf also ein Benutzer auf eine bestimmte Ressource (z.B. eine Datei)
zugreifen (bzw. nicht zugreifen), dann darf ein ihm zugeordneter Prozess dies auch (bzw. auch
nicht).
4.2 Systemadministratoren
In den meisten Betriebssystemen gibt es mehrere Arten von Benutzern: Normale Benutzer und
Benutzer mit Administrationsrechten, die sogenannten Systemadministratoren. In vielen Betriebssystemen, darunter auch dem Unix-artigen Linux und Microsoft Windows [MS-Web], darf
ein Administrator auf dem System schlicht alles machen zumindest aus technischer Sicht. Es
ist ihm nicht nur mglich, auf beliebige auf dem System abgelegte Nutzerdaten lesend zuzugreifen, sondern er kann diese Daten auch verndern, lschen oder kopieren. Auf den ersten Blick
mag diese uneingeschrnkte Allmacht berzogen wirken, leider ist sie aber fr die Erfllung einiger Aufgaben tatschlich notwendig. Um beispielsweise eine Sicherheitskopie (auch Backup
genannt) der Daten eines Mehrbenutzersystems anlegen zu knnen, muss der Administrator die
Mglichkeit haben, auf alle Daten zugreifen zu knnen. Mitarbeiter einer Firma kndigen (oder
werden gekndigt), Studenten schlieen ihr Studium ab in beiden Fllen mssen die Benutzerdaten wieder vom System gelscht werden knnen, und zwar auch dann, wenn die betreffenden
Benutzer sich nicht kooperativ zeigen.
Es gibt also gute Grnde, warum dem Administrator eines Systems (meistens) keine technischen Einschrnkungen in den Weg gestellt werden. Allerdings ist das technisch Mgliche dem
Systemadministrator in vielen Fllen verboten, sei es durch interne Richtlinien der Institution
oder sogar durch den Gesetzgeber. Systemadministratoren, die ihre Rechte missbrauchen, etwa
um Mitarbeiter auszuspionieren oder fremde Emails zu lesen, knnen dadurch ihren Job verlieren
oder sich schlimmstenfalls sogar strafbar machen.
Systemadministratoren gelten mancherorts fast als eine Art Hausmeister fr die IT. Bei der
Wahl des Systemadministrators sollte man aber bercksichtigen, welche Verantwortung er trgt
und welche Missbrauchsmglichkeiten bestehen. Auerdem sollten Systemadministratoren natrlich auch berwacht werden. Ein Systemadministrator sollte nicht in der Lage sein, absichtlich
oder unabsichtlich ein Unternehmen lahmzulegen, indem er ein Passwort ndert oder ein System
unbrauchbar macht. Auch hier ist ein Backup notwendig.
Aufgrund der umfangreichen Rechte und der Missbrauchsmglichkeiten im Falle eines Angriffs sollten Benutzerkonten mit Administratorrechten nur zur Administration des Systems eingesetzt werden. Daher sollte ein Systemadministrator noch ber ein normales Benutzerkonto
ohne Administratorrechte verfgen, das er verwendet, wenn er nicht das System administriert.
Diese einfache Regel wird im institutionellen Bereich meist befolgt, im privaten aber oft strich
vernachlssigt.
72
4.3 Rechtevergabe und Zugriffskontrolle am Beispiel

Dateisystem
Nun wollen wir uns etwas detaillierter mit der Frage beschftigen, welche Formen der Zugriffskontrolle es in Betriebssystemen gibt und wie sie realisiert sind. Wir werden dies am Beispiel
des Dateisystems unter Linux illustrieren. Wir werden uns in diesem Buch immer auf Linux
beziehen. In der Regel gelten die dargestellten Sachverhalte aber auch fr andere Unix-artigen
Betriebssysteme.
Betriebssysteme ermglichen durch die Bereitstellung abstrakter Schnittstellen, Anwendungsprogramme unabhngig von konkreten Details der verwendeten Hard- oder Software zu programmieren und zu verwenden. Die Anwendungen benutzen zum Zugriff auf die vorhandenen
Ressourcen die vom Betriebssystem zur Verfgung gestellte Schnittstelle. Ein direkter Zugriff
auf die Ressourcen des Systems wird durch das Betriebssystem im Zusammenspiel mit dem
Prozessor der Maschine verhindert. Dies ist schon deshalb notwendig, da sonst Anwendungen
die Ressourcenverwaltung und das Sicherheitsmanagement des Betriebssystems umgehen knnten, was natrlich problematisch wre. Der Prozessor untersttzt diese Architektur, indem er
zwischen zwei Ausfhrungsmodi unterscheidet, nmlich dem Kernel-Mode, der ausschlielich
fr das Betriebssystem reserviert ist, und dem User-Mode, in welchem alle anderen Programme
ablaufen. Whrend im Kernel-Mode beliebige Befehle ausgefhrt werden knnen, sind im UserMode bestimmte Operationen eingeschrnkt, so dass die Kontrolle des Betriebssystems nicht
umgangen werden kann.
Hinter dem kompliziert klingenden Begriff abstrakte Schnittstelle verbergen sich im Allgemeinen viele Dinge, die den meisten Computerbenutzern bekannt sein drften, wie etwa das
Dateisystem. Verschiedene Massenspeichergerte wie Festplatten, CD-RWs, USB-Speichersticks
oder Disketten basieren nicht nur auf unterschiedlichsten Technologien, sondern erfordern auch
eine grundlegend andere Hard- und Softwareansteuerung. Das Betriebssystem stellt als abstrakte
Schnittstelle zu allen Massenspeichergerten das Dateisystem zur Verfgung. Die auf dem Speichermedium vorhandenen Speicherblcke werden durch die Anwendungen nicht direkt angesprochen, sondern sie greifen indirekt ber das durch das Betriebssystem realisierte Dateisystem
auf das Gert zu. Das Dateisystem heutiger Betriebssysteme ist oft hierarchisch realisiert, d.h. es
gibt Verzeichnisse, in denen sich Dateien und andere Verzeichnisse benden knnen. Zugriff auf
das Dateisystem und andere abstrakte Schnittstellen erhalten die Anwendungen durch den Aufruf
eines System Calls. Ein System Call ist eine durch das Betriebssystem zur Verfgung gestellte
Funktion, die durch eine Anwendung hnlich wie eine Bibliotheksfunktion aufgerufen werden
kann. Zum ffnen von Dateien zum Lesen oder Schreiben gibt es in Linux beispielsweise den
-Aufruf. Das Betriebssystem bersetzt solche Aufrufe in konkrete Anweisungen, die
dann vom Gertetreiber durch Befehle an den auf dem Massenspeichermedium selbst bendlichen Gertecontroller umgesetzt werden.
Der System Call wird durch das Betriebssystem abgearbeitet und das Resultat an die aufrufende Anwendung zurckbergeben. Bei der Bearbeitung dieser Aufrufe erfolgt auch eine berprfung, inwieweit der aufrufende Benutzer zu der gewnschten Operation berechtigt ist.
Die Frage, wer in einem System was darf, ist oftmals komplex. In einer Firma arbeiten hug
wechselnde Gruppen von Mitarbeitern an verschiedenen Dokumenten, auf die sie Zugriff haben
73
Abbildung 4.1: Zugriffsrechte, Dateibesitzer und Gruppe unter Linux.
sollen. Linux untersttzt ein einfaches Gruppenkonzept, in dem jeder Benutzer einer oder mehreren Gruppen angehren kann. Jede Datei unter Linux ist eindeutig einer Gruppe zugeordnet.
Die Frage, wer was mit einer Datei machen darf, ist in Linux ber Zugriffsrechte geregelt. Die
Zugriffsrechte werden getrennt fr den Besitzer, die Gruppe und andere Benutzer verwaltet. Es
gibt drei verschiedene Rechte:
Lesen (r): Bei Dateien: Berechtigung, die Datei zum Lesen zu ffnen. Vernderungen oder
Lschen der Datei sind nicht erlaubt (wohl aber das Kopieren und anschlieende Verndern
der Kopie). Bei Verzeichnissen: Berechtigung, sich die Dateien im Verzeichnis anzeigen
zu lassen.
Schreiben (w): Bei Dateien: Berechtigung, die Datei durch eine andere mit gleichem Namen zu ersetzen (Speichern einer neuen Version) oder die Datei zu lschen. Bei Verzeichnissen: Berechtigung, Dateien in das Verzeichnis zu schreiben oder es (falls leer) zu lschen.
Ausfhren (x): Bei Dateien: Berechtigung zum Ausfhren der Datei (sinnvoll beispielsweise fr Binrdateien oder Skripte). Bei Verzeichnissen: Berechtigung, in das Verzeichnis zu wechseln. Dies ist notwendig, um irgendetwas mit Dateien oder in dem Verzeichnis
bendlichen Verzeichnissen zu tun.
Diese drei Rechte knnen unabhngig voneinander und getrennt fr Besitzer, Gruppe und
Andere speziziert werden. Will ein Benutzer auf eine Datei oder ein Verzeichnis zugreifen, stellt
Linux fest, in welche dieser Berechtigungsklassen der Benutzer fllt und setzt die entsprechenden
Rechte durch. Beim Besitzer werden die Besitzerrechte angewendet, bei anderen Benutzern aus
der entsprechenden Gruppe die Gruppenrechte und bei Benutzern, die weder der Besitzer noch
in der entsprechenden Gruppe sind, die Rechte fr andere.
74
Abbildung 4.2: Zugriffsrechte unter Windows XP und NTFS-Dateisystem.
Zugriffsrechte, Besitzer und Gruppe einer Datei werden gemeinsam mit weiteren wichtigen
administrativen Informationen, wie beispielsweise in welchen Blcken auf dem Datentrger die
Datei zu nden ist, in einem Datensatz auf dem Datentrger selbst, dem sogenannten i-Node,
gespeichert.
Von einem Kommandozeileninterpreter aus, im Linux-Jargon Shell genannt, knnen mit dem
-Befehl alle in einem Verzeichnis bendlichen Dateien angezeigt werden. Mit der Option
-l werden dabei auch die Zugriffsrechte der Datei, der Besitzer der Datei und die der Datei zugeordnete Gruppe ausgegeben. Eine Beispielausgabe fr drei Dateien ist in Abbildung 4.1 gezeigt.
Wir hatten schon besprochen, dass Prozesse normalerweise dem Benutzerkonto zugeordnet
sind, von dem aus sie gestartet wurden und auch entsprechende Berechtigungen besitzen. Unter
Linux gibt es die Mglichkeit, ber Berechtigungen im Dateisystem zu spezizieren, dass eine
ausfhrbare Datei nicht mit den Berechtigungen des Benutzers, der sie startet, sondern mit denen
des Besitzers der Datei gestartet werden soll. Dieses als setuid bekannte Merkmal ist einerseits
sehr praktisch, weil es beispielsweise normalen Benutzern erlauben kann, bestimmte Programme, bei denen dies ntig ist, mit Administratorrechten auszufhren. Andererseits kann es aber
auch schwerwiegende Sicherheitslcken ffnen, die in der Vergangenheit schon fr Angriffe ausgenutzt wurden.
Auch unter Windows XP besteht die Mglichkeit, Zugriffsrechte fr Dateien und Verzeichnisse auf Benutzer- oder Gruppenbasis zu vergeben. Dies setzt allerdings die Verwendung des
neueren NTFS-Dateisystems anstelle des lteren FAT-Dateisystems voraus. Abbildung 4.2 zeigt
das entsprechende GUI. Durch Rechtsklicken auf eine Datei oder ein Verzeichnis erhlt man
durch Wahl des Menpunktes Eigenschaften das Tab Sicherheit.
Will ein Benutzer eine Datei ffnen, so berprft das Betriebssystem, ob der anfragende Benutzer hierzu berechtigt ist oder nicht, und gewhrt oder verweigert den Zugriff. Im laufenden
75
Betrieb kann ein solches Zugriffsrechtesystem (keine Schwachstellen vorausgesetzt) den unbefugten Zugriff auf Dateien verhindern, etwa durch andere gleichzeitig oder spter auf dem
System aktive Benutzer. Damit ist Zugriffsrechtemanagement ein sehr wichtiger und in vielen
Szenarien unverzichtbarer Bestandteil eines Betriebssystems.
Doch Zugriffsrechte allein bieten keinen ausreichenden Schutz vertraulicher Information. Auf
dem jeweiligen Massenspeichermedium, gehen wir im Folgenden einfach von einer Partition auf
einer Festplatte in einem gewhnlichen PC aus, sind die Daten nmlich im Klartext abgelegt.
Der Schutz durch das Betriebssystem schrnkt den Zugriff auf die Daten nur dann ein, wenn das
Betriebssystem auch tatschlich auf dem Rechner aktiv ist und der Zugriff auf die Daten ber
das Betriebssystem erfolgt. Daher kann ein Angreifer diesen Schutz einfach aushebeln, indem
er den PC mit einem (anderen) Betriebssystem startet, auf dem er Administratorrechte besitzt,
beispielsweise von einer CD-Rom oder einem Speicherstick. Danach kann der Angreifer auf dem
Rechner als Administrator tun, was er will, und sich Zugriff auf das Laufwerk verschaffen.
Um sich vor solchen Angriffen zu schtzen, bietet bei vielen PCs das Basic Input Output
System (BIOS) des Rechners einige Optionen. Das BIOS eines PCs steuert die grundlegendsten
Funktionen des Rechners. Es legt unter anderem fest, von welchem Medium das Betriebssystem
des Rechners geladen wird. Viele Rechner sind so konguriert, dass bei einer einliegenden DVD,
CD oder einem eingesteckten Speicherstick automatisch von diesen Medien und nicht von der
Festplatte gebootet wird. Schaltet man diese Mglichkeiten ab und schtzt das BIOS vor unautorisierten Vernderungen, so kann die gerade skizzierte Attacke abgewehrt werden. Aber davon
muss sich der Angreifer nicht aufhalten lassen. Hat er physischen Zugang zu der Maschine (was
zum Starten des Rechners von einem Medium seiner Wahl hug auch notwendig ist), so ist es
ihm vielleicht mglich, die Festplatte einfach aus dem betreffenden PC auszubauen und in einen
anderen PC einzubauen, auf dem der Angreifer Administratorrechte besitzt. Dann kann er auf
die Festplatte ohne grere Anstrengungen zugreifen und die dort gespeicherten Daten auslesen.
Der Angreifer kann hierfr auch ein anderes Betriebssystem verwenden als das, was auf dem
Opferrechner installiert war, etwa eines, das speziell zur Rettung von Daten auf defekten Datentrgern konzipiert ist und Anwendungen umfangreiche direkte Zugriffsmglichkeiten auf den
Datentrger bietet.
Fassen wir die Erkenntnisse zusammen. Es ist wichtig, Daten auf einem Massenspeichermedium durch Zugriffsschutzmechanismen (ohne andere Schwachstellen) auf Betriebssystemebene
vor unbefugtem Zugriff zu schtzen. Dieser Schutz ist ausreichend, wenn sichergestellt werden
kann, dass ein Angreifer keine Mglichkeit hat, das Betriebssystem zu umgehen und so direkten Zugriff auf den Datentrger zu erlangen. Mglich ist dies beispielsweise durch das Booten
des Rechners mit einem anderen Betriebssystem oder den Betrieb des Speichermediums in einer
anderen Maschine.
In den meisten Szenarien ist es wie schon erwhnt fr einen Angreifer notwendig, sich physisch Zugang zu der betreffenden Maschine zu verschaffen, um einen der oben beschriebenen
Angriffe durchzufhren. Deshalb bietet ein umfassender Zugriffsrechteschutz durch das Betriebssystem eine relativ groe Sicherheit fr Daten auf Massenspeichermedien in einem Serverraum eines groen Unternehmens, der einer strengen physischen Zugangskontrolle unterliegt.
Derselbe Zugriffsschutz auf einem Laptop wre aber vllig unzureichend.
Somit bedarf es anderer Methoden, die Daten zu schtzen. Eine Mglichkeit ist es, durch
Softwarelsungen im Gertecontroller des Mediums selbst einen Zugriffsschutz, etwa durch ein
76
Daten
Daten
Daten
Anwendung/
Benutzer
Verschlsselung/
Entschlsselung
Verschlsselung/
Entschlsselung
Betriebssystem
Verschlsselung/
Entschlsselung
Gert
Abbildung 4.3: Verschlsselung eines Dateisystems durch Benutzer bzw. Anwendung (links), das Betriebssystem (mitte) oder im Gert selbst (rechts).
Passwort, zu realisieren. Da der Controller fest zum Gert selbst gehrt, lsst sich ein solcher
Schutz schwieriger aushebeln als auf Betriebssystemebene. Solche Sicherheitsmechanismen sind
in mobilen Speichergerten wie USB-Speichersticks und externen Festplatten mittlerweile hug
anzutreffen.
Eine weitere Mglichkeit, die wir im Folgenden detaillierter besprechen werden, ist der Schutz
der Daten auf der Festplatte durch Verschlsselung der gespeicherten Daten. Dabei kann die Verschlsselung entweder im Gert selbst erfolgen oder aber ber das Betriebssystem realisiert werden. Diese Mglichkeiten sind in Abbildung 4.3 dargestellt. Vor dem Zugriff auf das Speichermedium (genauer gesagt einer Partition) ist die Eingabe eines Schlssels (oder dessen Aktivierung
durch Eingabe eines Passworts) notwendig, ohne den auf das Dateisystem auf dem Datentrger
nicht zugegriffen werden kann.
Bei der vollstndigen Verschlsselung eines Datentrgers muss bei jedem Schreib- oder Lesezugriff auf den Datentrger eine Ver- bzw. Entschlsselungsoperation durchgefhrt werden. Dies
kann zu einem deutlichen Leistungsverlust fhren, Schreib- oder Leseoperationen dauern lnger.
Insbesondere fr Systeme, in denen nicht alle Daten geschtzt werden mssen, empehlt sich
die Einrichtung spezieller Partitionen oder Bereiche fr kritische Daten, die dann wie oben beschrieben verschlsselt auf dem Datentrger abgelegt werden, whrend unkritische Daten nicht
verschlsselt werden und somit ohne Leistungsverlust verfgbar sind. Allerdings muss dann zustzlich darauf geachtet werden, dass diese vertraulichen Dateien nicht zustzlich in anderen
Bereichen (unverschlsselt) abgelegt werden, beispielsweise in Form einer automatisch durch
ein Programm erstellten temporren Datei.
Der eben beschriebene Schutz eines Datentrgers oder der Partition auf einem Datentrger
ber das Betriebssystem schtzt den gesamten Datentrger mit einem einzigen Schlssel, ber
den in der Regel der Systemadministrator verfgen wird. Der Schlssel wird einmal beim Starten
der Maschine eingegeben. Eine Neueingabe ist nur beim Neustart der Maschine notwendig.
4.4 Trusted Computing
77
Hier wird eine weitere wichtige Frage aufgeworfen, nmlich wie man wieder an die Daten
auf dem Medium kommt, wenn der Administrator den Schlssel vergisst, verliert, oder er gar
entlassen wird. In diesen und in vielen anderen Fllen mssen Vorkehrungen getroffen werden,
dass der Schlssel noch anderweitig hinterlegt ist oder ein zustzlicher Schlssel existiert, mit
dem die Daten ebenfalls wieder zugnglich gemacht werden knnen (und dies am besten mit
technischen Mitteln). Eine Mglichkeit hierzu sind Key Escrows. Dabei wird der Schlssel einem
vertrauenswrdigen Dritten gegeben, der ihn bei Bedarf zur Verfgung stellt. Es ist nicht schwer
sich auszumalen, welche potentiellen Missbrauchsmglichkeiten und Schwachstellen sich durch
einen solchen Service bieten. Das Risiko eines totalen Datenverlusts wird in der Regel aber
schwerer wiegen als solche berlegungen.
Eine weitere Mglichkeit ist die Verschlsselung der Daten auf Anwenderebene: Jeder Benutzer eines Systems verschlsselt seine vertraulichen Dateien selbst, ohne Hilfe des Betriebssystems. Whrend dieses Verfahren Daten auch vor neugierigen Blicken des allmchtigen Administrators schtzen kann, bleiben doch einige Zweifel hinsichtlich der Praktikabilitt dieses
Ansatzes: Viele Benutzer sind schlicht zu bequem.
4.4 Trusted Computing

Wie wir gerade gesehen haben, kann das Betriebssystem keinen vollstndigen Schutz der auf
einem Rechner gespeicherten Informationen gewhrleisten. Selbst wenn man die Daten auf Anwenderebene verschlsselt, so werden die Daten dann, wenn sie verwendet werden, wieder entschlsselt und unverschlsselt auf dem System bearbeitet. Auch der Schlssel zur Entschlsselung der Daten muss irgendwann benutzt werden und knnte dabei abgefangen und kopiert
werden. Einem Angreifer bieten sich in den derzeitigen Rechnern also einige Ansatzpunkte, wie
er an solche Informationen gelangen kann, sei es durch eine Manipulation des Betriebssystems
oder eine Manipulation des Rechners auf Hardwareebene.
In der Trusted Computing Group [TCG-Web] haben sich einige Unternehmen zusammengeschlossen, um einen Industriestandard fr sichere Systemkomponenten und Systeme zu spezizieren, so dass die einzelnen Komponenten zum einen selbst sicher sind und auch die Interaktion
verschiedener Systemkomponenten abgesichert ist.
So sinnvoll ein derartiges Konzept auch scheinen mag, gibt es an den derzeit vorgelegten Konzepten doch einige sehr erstzunehmende Kritikpunkte. Zusammengefasst besteht die Mglichkeit, Trusted Computing so zu verwenden, dass letztlich die Hersteller der Soft- und Hardware
eines Systems und nicht mehr die Kufer und Nutzer des Rechners die Kontrolle ber das System
haben. Beispielsweise lassen sich Funktionen und Programme ber das Netzwerk deaktivieren.
Das Betriebssystem und Systemadministratoren knnen hierauf keinen Einuss nehmen.
Trusted Computing kann ebenfalls dazu verwendet werden, nicht die Systeme vor Angriffen,
sondern urheberrechtlich geschtzte Inhalte wie Musik und Filme vor den legitimen Systembenutzern zu schtzen, damit diese zu keinem Zeitpunkt Zugriff auf die unverschlsselten Daten
erhalten und die Inhalte kopieren knnen. Die Kufer- und Benutzerakzeptanz solcher Lsungen
bleibt abzuwarten.
78

Angreifer
Internet
Dienst mit
Schwachstelle
Angegriffener Rechner
Angreifer kontaktiert einen
Dienst mit Schwachstelle
ber das Netz und nutzt die
Schwachstelle aus
Schwachstelle kann vom Angreifer

genutzt werden, um den gesamten
Rechner unter Kontrolle zu bringen und
beispielweise Administrator-Zugriff zu erlangen
Abbildung 4.4: Ausnutzen von Sicherheitslcken in angebotenen Diensten.
4.5 Monitoring und Logging

Eine der wichtigsten Aufgaben eines Betriebssystems ist es, den laufenden Betrieb des Systems
zu berwachen und ungewhnliche Vorgnge an den Systemadministrator weiterzumelden. Fehlverhalten von Benutzern und Angriffe auf das System zu protokollieren ist wichtig, da zum einen
ohne solche Manahmen Angriffsversuche oder erfolgreiche Angriffe nicht aufgedeckt werden
knnten, zum anderen sind solche Daten wichtig, um nach einem Angriff durch (Computer-)
Forensik die ausgenutzten Schwachstellen analysieren zu knnen und um Anhaltspunkte fr die
Ermittlung von Tatverdchtigen zu haben.
4.6 Absichern des Systems gegen Angriffe

Ein Rechner kann lokal fr Benutzer des Rechners oder ber ein Netzwerk Dienste anbieten,
die dann durch Benutzer oder Prozesse lokal oder von anderen Rechnern aus ber das Netzwerk
kontaktiert und verwendet werden knnen.
Viele solcher Dienste sind Teil von Betriebssystemdistributionen und die Standardeinstellungen mancher Betriebssysteme aktivieren einige dieser Dienste automatisch. Bei jedem Systemstart werden dann Prozesse gestartet, welche die Services zur Verfgung stellen. Beispiele fr
solche Dienste sind
die Verwendbarkeit von Verzeichnissen auf lokal angeschlossenen Datentrgern ber das
Netzwerk etwa durch NFS (siehe NFS-Overview bei [SF-Web]) oder Samba [Samba-Web]
unter Linux oder SMB unter Microsoft Windows [MS-Web],
die Mglichkeit, Kommandozeileninterpreter auf einem Rechner ber das Netzwerk von
einer anderen Maschine aus aufzurufen, etwa durch SSH (siehe Abschnitt 13.2).
Jeder Dienst und jedes Programm kann Schwachstellen und Sicherheitslcken aufweisen, die
ein Angreifer ausnutzen kann, um den Rechner unter seine Kontrolle zu bringen. Abbildung 4.4
4.7 Zusammenfassung
79
veranschaulicht diese Situation fr einen Dienst, der ber das Netzwerk angeboten wird. Prinzipiell knnen auch Programme und Dienste, auf die nur lokaler Zugriff besteht, solche Schwachstellen beinhalten. Das Ausnutzen einer Schwachstelle in Netzwerkdiensten ist fr Angreifer
meistens einfacher zu realisieren, jedoch sind auch lokale Sicherheitslcken sehr gefhrlich. Zum
einen knnen diese durch lokale Benutzer ausgenutzt werden, zum anderen knnte sich ein Angreifer von auen Schritt fr Schritt vorarbeiten, indem er sich zunchst ber das Netzwerk mit
einem geknackten oder aufgeschnappten Usernamen und Passwort Kommandozeilenzugriff auf
einem Rechner verschafft und dann ber diese Shell Sicherheitslcken in einem lokal installierten Programm ausnutzt.
Gerade wenn ein Rechner als Server eingesetzt wird und ber das Internet zugnglich ist,
empehlt es sich dringend, alle nicht bentigten Programme zu entfernen und alle Dienste abzuschalten, die nicht wirklich bentigt werden. Sollte ein Administrationszugriff ber das Netzwerk
auf den Rechner notwendig sein, empehlt es sich, diesen durch eine geeignete Konguration
mglichst nur von bestimmten Rechnern aus zu ermglichen. Das Abschalten nicht unbedingt
notwendiger Programme und Dienste wird mit dem Begriff Hrten bezeichnet und ist fr die
Sicherheit der betreffenden Maschinen von groer Bedeutung.
Jeder Dienst, jedes Programm, das auf einem Rechner nicht vorhanden ist und nicht luft
oder nicht gestartet werden kann, erhht die Sicherheit der Maschine. Sicherheitslcken in nicht
laufenden Diensten knnen durch einen Angreifer nicht ausgenutzt werden. So banal diese Erkenntnis ist, so wichtig ist ihre Umsetzung in die Praxis.
4.7 Zusammenfassung
Das Betriebssystem verwaltet die Ressourcen eines Rechners und stellt sie den Anwendungen und Benutzern ber abstrakte Schnittstellen zur Verfgung. Dabei ist die
Authentikation von Benutzern und eine Autorisation der Ressourcenbenutzung vor
allen Dingen in Mehrbenutzersystemen unabdingbar.
In vielen Betriebssystemen gibt es spezielle Benutzerkonten mit Administrationsrechten, die auf dem System umfangreiche Privilegien haben und nur zur Administration
genutzt werden sollten.
Die Zugriffskontrolle auf Ressourcen kann in einem Betriebssystem auf vielfltige
Weise implementiert sein. Im Linux-Dateisystem ist jede Datei einem Besitzer und
einer Gruppe zugeordnet und es knnen fr Besitzer, Gruppe und andere Benutzer
festgelegt werden, ob sie die Datei lesen, schreiben oder ausfhren drfen.
Der Schutz von Ressourcen durch das Betriebssystem kann ausgehebelt werden, wenn
die Ressource verfgbar gemacht werden kann, ohne dass das Betriebssystem aktiv ist, etwa durch den Start des Systems mit einem anderen Betriebssystem. Wenn
solche Angriffe mglich sind, ist ein zustzlicher Schutz vertraulicher Informationen
beispielsweise durch Verschlsselung, notwendig.
Das Hrten eines Systems durch Abschalten berssiger Dienste und Programme
stellt eine wichtige Sicherheitsmanahme dar, da Schwachstellen in abgeschalteten
Diensten und Programmen durch einen Angreifer nicht ausgenutzt werden knnen.
80
4.8 bungsaufgaben
Aufgabe 4.1:
Nennen Sie die Aufgaben eines Betriebssystems und erlutern Sie, wie diese Aufgaben mit der
Sicherheit eines Systems zusammenhngen.
Aufgabe 4.2:
Erklren Sie folgende Begriffe: Benutzer, Benutzerkonto, Mehrbenutzerbetrieb, SignIn, Systemadministrator.
Aufgabe 4.3:
Erlutern Sie die Zugriffskontrollmechanismen im Linux-Dateisystem.
Aufgabe 4.4:
Die Datei
in einem Linux-System habe die folgenden Berechtigungen:
ist in Gruppe
,
ist nicht in der Gruppe. Geben Sie an, welcher
der drei Benutzer die Datei jeweils lesen, lschen oder ausfhren darf.
Aufgabe 4.5:
Beschreiben Sie, welche Mglichkeiten bestehen, den durch das Betriebssystem realisierten Zugriffsschutz auf Massenspeichermedien auszuhebeln und in welchen Fllen er als ausreichend
erachtet werden kann.
Aufgabe 4.6:
Erklren Sie, was man unter dem Hrten eines Systems versteht und warum diese Manahme die
Sicherheit des Systems erhhen kann.

Aufgabe 4.7:
Kann ein Benutzer eine Datei auf einem Linux-System so ablegen, dass der Systemadministrator
die Daten nicht lesen kann? Falls ja, wie?
Aufgabe 4.8:
Recherchien Sie die genaue Funktionsweise von setuid und setgid unter Linux und geben Sie ein
Beispiel fr deren Verwendung. Testen Sie setuid und setgid auch in der Praxis.
4.8 bungsaufgaben
81
Aufgabe 4.9:
Wir hatten bereits angesprochen, dass es ratsam ist, den Administrationszugriff auf Server im
Internet nur von bestimmten anderen Maschinen aus zu ermglichen. Recherchieren Sie nach
technischen Mglichkeiten, wie dies realisiert werden kann und fassen Sie diese zusammen.
Kapitel 5
5Anwendungen
Anwendungen
5.1 Einfhrung
Die gewhnlichen Nutzer eines Computersystems vergngen sich meistens mit Anwendungsprogrammen. Das Spektrum von Anwendungsprogrammen ist breit gefchert und reicht von Software zur Steuerung und Kontrolle von Unternehmen oder Fabriken, Webservern und Datenbanken bis hin zu Compilern, Editoren, Entwicklungsumgebungen, Textverarbeitungsprogrammen,
Tabellenkalkulationen und Spielen.
Als Anwendung bezeichnen wir hier jedes auf einem Rechner aktive Programm, das nicht
zum Betriebssystem des Rechners gehrt und auf die Ressourcen des Systems ausschlielich
ber die vom Betriebssystem bereitgestellten abstrakten Schnittstellen zugreifen darf, also keinen direkten Zugriff auf diese Ressourcen hat. Diese sehr grobe Denition ist fr unsere Zwecke
ausreichend. Es gibt noch feinere Unterscheidungsmglichkeiten, etwa zwischen echten Anwendungsprogrammen und Systemprogrammen. Das sind Programme, die zwar Anwendungen
darstellen, aber einen engen Bezug zum Betriebssystem aufweisen, etwa weil sie als Teil eines
Gesamtpakets mit dem Betriebssystem zusammen auf dem Rechner installiert wurden.
Die Sicherheit von Anwendungsprogrammen ist ebenso wichtig, wie die Sicherheit des Betriebssystems selbst:
Sicherheit von Anwendungsdaten: Einige Anwendungen, wie etwa eine Datenbank oder
andere Unternehmenssysteme, verwalten vertrauliche Daten, die nicht in die Hnde Unbefugter gelangen drfen. Da die Anwendung selbst die Daten bearbeiten und verwalten
knnen muss, kann der Schutz der Daten nicht alleine durch das Betriebssystem gewhrleistet werden. Verfgt die Anwendung beispielsweise ber eine Mglichkeit, die Daten
ber ein Netzwerk ohne vorherige Authentikation abzurufen, knnten die Daten von beliebigen Personen genutzt werden.
Systemsicherheit: Schwachstellen in Anwendungen knnen es Angreifern ermglichen,
Zugriff auf das System zu erlangen, auf dem die Anwendung luft, und eventuell sogar Administratorrechte auf dem System zu bekommen. Es gab beispielsweise Lcken in einigen
Webservern, die es Angreifern ermglichten, Kommandozeilenbefehle auf dem System
auszufhren.
Diese Liste liee sich noch beliebig erweitern. Der entscheidende Punkt sollte schon klar geworden sein: Die Sicherheit von Anwendungen und des Betriebssystems sind komplementr
zueinander. Um die Sicherheit von Daten und die des Systems zu gewhrleisten, mssen sowohl
84
5 Anwendungen
die Anwendungen als auch das Betriebssystem selbst sicher sein. Wir wollen uns nun mit der
Frage beschftigen, welche Risiken bei Anwendungen drohen und was man dagegen tun kann.
5.2 Buffer Overows

5.2.1 Das Problem
Selbstndige Anwendungsprogramme liegen in Assemblercode vor. Dabei handelt es sich um
Programme in einem hardwarenahen Maschinenbefehlssatz. Die meisten Programme werden
nicht direkt in Assembler entwickelt, sondern in einer fr Menschen besser verstndlichen hheren Programmiersprache wie beispielsweise C oder C++ und dann durch einen Compiler automatisch von der hheren Programmiersprache in ein Assemblerprogramm bersetzt.
Wird ein solches Programm gestartet (und damit zum Prozess), erhlt es vom Betriebssystem
einen Speicherbereich zugeteilt. In diesem Speicherbereich nden sich sowohl whrend des Ablaufs des Programms angefallene Daten und zur weiteren Ausfhrung des Programms notwendige Informationen als auch der Assemblercode des Programms selbst. Das Programm kann alle
Bytes des ihm zugewiesenen Speicherbereichs, des sogenannten virtuellen Adressraums, ansprechen und verndern. Dabei werden nicht die eigentlichen physikalischen Adressen des Speichers
verwendet, sondern sogenannte virtuelle Adressen, die durch den Prozessor und das Betriebssystem erst in echte physikalische Speicheradressen umgerechnet werden. Hierbei wird berprft
und sichergestellt, dass der Prozess ausschlielich in dem ihm zugewiesenen Speichersegment
operiert und nicht auf andere Teile des Speichers zugreifen kann.
Leider ndet bei Zugriffen innerhalb des zugewiesenen Speicherbereichs durch das Betriebssystem im Regelfall keine Kontrolle statt, was dort genau passiert. Dies kann als Ausgangspunkt
fr Angriffe, sogenannte Buffer Overows genutzt werden. Wir wollen die Funktionsweise eines
solchen Angriffs im Folgenden skizzieren, ohne jedoch genau in die Details zu gehen.
In dem Speicherbereich, der dem Prozess zugewiesen wurde, benden sich wie bereits erwhnt
sowohl Daten als auch der Programmcode. Zwischen Daten, Administrationsinformationen und
Programmcode besteht hinsichtlich ihrer Reprsentation auf dem Computersystem keinerlei Unterschied. Letztlich handelt es sich auf einer niedrigen Abstraktionsebene immer um eine Folge
von Bytes. Der Unterschied zwischen Daten und dem Programm besteht darin, dass Bytefolgen,
welche das Programm reprsentieren, sukzessive als Maschinenbefehle interpretiert und auf dem
System ausgefhrt werden, whrend dies mit den Daten (normalerweise) nicht geschieht. Fordert ein Programm eine Eingabe, so kann ein Angreifer anstelle der erwarteten Daten auch ein
Assemblerprogramm unterschieben, das bei Ausfhrung beispielsweise eine Shell aufrufen und
das eigentliche Programm beenden wrde. Wrde dieser Code ausgefhrt, htte der Angreifer
erfolgreich einen Kommandozeileninterpreter fr sich gestartet.
Das Unterschieben des Codes als Eingabe alleine reicht noch nicht, um mit einem solchen
Angriff Erfolg zu haben. Notwendig ist es zudem, das als Daten eingelesene Programm auch
noch zur Ausfhrung zu bringen. Doch leider ist auch dies in einigen Fllen mglich. Um dies
zu verstehen, mssen wir noch ein wenig tiefer in die Ausfhrung eines Programms eintauchen.
Viele Programmiersprachen bieten als Konstrukt Funktionen (oder Prozeduren) an, die sich
gegenseitig aufrufen knnen und deren Aufrufe ineinander verschachtelt und rekursiv sein dr-
5.2 Buffer Overows
85
Speicherbereich fr den Prozess
nach Beendigung
der Funktion
vorgesehener Speicherbereich
fr eine Variable
Abbildung 5.1: Buffer Overow.
fen. Bei einem Aufruf wird die Abarbeitung der bisherigen Funktion unterbrochen und mit der
Bearbeitung der neuen Funktion begonnen. Ist die Bearbeitung der aufgerufenen Funktion abgeschlossen, wird die Bearbeitung wieder an der gleichen Stelle der Funktion fortgesetzt, die vorher
unterbrochen wurde. Auf Assemblerebene wird dies realisiert, indem fr jeden Funktionsaufruf
die notwendigen Verwaltungsinformationen und die lokalen Variablen der aktuellen Funktion
in einem speziellen Teil des Speichers, dem Stack, abgelegt werden. Auf dem Stack wird unter
anderem auch die Rcksprungadresse abgelegt. Das ist die Adresse des nchsten Befehls, der
nach Beendigung der gerade aufgerufenen Funktion ausgefhrt wird. Gelingt es einem Angreifer, diese abgespeicherte Rcksprungadresse gezielt durch die Adresse des von ihm als Eingabe
untergeschobenen Assemblerprogramms zu ersetzen, so wird dieses Programm des Angreifers
nach Beendigung des Funktionsaufrufs ausgefhrt.
Es mag vielleicht so klingen, als wre ein Angreifer auf eine sehr unwahrscheinliche Folge von Zufllen angewiesen, um einen solchen Angriff erfolgreich durchzufhren. Tatschlich
aber sind diese Angriffe relativ hug. Der Grund hierfr liegt in der statischen Allokation fester
Speicherbereiche fr Variablen. Wenn eine Variable in einem Programm deklariert wird, wird fr
diese Variable ein Speicherbereich mit einer bestimmten Gre reserviert. Einige Programmiersprachen und Compiler (speziell fr C) erlauben jedoch Schreibzugriffe auf den Speicher, bei
denen keine berprfung stattndet, ob die bergebenen Daten tatschlich in den vorgesehenen
Speicherbereich passen oder diesen berschreiten. Dies ist insbesondere fr Strings der Fall.
In Abbildung 5.1 ist dargestellt, wie dies von einem Angreifer ausgenutzt werden kann. Im
oberen Teil ist die Situation zu sehen, die durch den Programmablauf unmittelbar vor dem Angriff entstanden ist. Gezeigt sind die durch den letzten Funktionsaufruf auf dem Stack belegten
Bereiche (rechts). Am rechten Ende steht die Rcksprungadresse, also die Adresse des nchsten
auszufhrenden Befehls nach Beendigung der Funktion, der die links oben gezeigte Speicherzelle entspricht. Das Programm hat einen Speicherbereich von drei Zellen fr eine Variable auf dem
86
5 Anwendungen
Stack vorgesehen. Durch einen Angreifer wurde ein Wert eingegeben, der mehr Speicherzellen
bentigt. Wird diese Eingabe nun ohne Kontrolle der fr die Variablen vorgesehenen Grenzen in
den Speicher kopiert, so reicht der fr die Variable vorgesehene Speicherbereich nicht aus und
luft ber (Buffer Overow). Auf diese Weise kann ein Angreifer auch die auf dem Stack abgelegte Rcksprungadresse berschreiben, und zwar mit der Startadresse des von ihm ebenfalls
injizierten Maschinencodes. Beim vermeintlichen Rcksprung nach Beendigung der Funktion gelangt so nicht der eigentliche nchste Befehl, sondern das Programm des Angreifers zur
Ausfhrung.
Overows knnen durch jede Art von Daten enstehen, die ein anflliges Programm verarbeitet.
Hierzu zhlen beispielsweise auch Bilder oder Audiodateien.
5.2.2 Schutzmanahmen
Es ist eigentlich nicht schwer, sich vor Buffer Overows zu schtzen. Durch eine berprfung
zur Laufzeit, ob die fr Variablen vorgesehenen Speicherbereiche eingehalten werden, knnen
solche Angriffe verhindert werden. Insbesondere auf Bibliotheksfunktionen, die beim Kopieren
nicht auf solche Grenzen achten, sollte bei der Programmierung verzichtet werden. Am sinnvollsten wre es natrlich, solche Bibliotheksfunktionen ganz aus dem Verkehr zu ziehen.
Aufgrund der Schwere des Problems und der Hugkeit der Angriffe wurde eine Reihe weiterer Schutzmanahmen entwickelt und umgesetzt, die Buffer Overows verhindern oder zumindest erschweren, beispielsweise:
Vor die jeweilige Rcksprungadresse wird ein zufllig erzeugter Wert (sogenannter Canary) platziert. Dieser Wert wird bei einem Buffer Overow durch den Angreifer ebenfalls
berschrieben, was das Programm zum Abbruch veranlasst. Die notwendigen Routinen
zum Erstellen und berprfen der Canaries werden bei der bersetzung des Programms
in Maschinensprache durch den Compiler erzeugt und eingefgt.
Aufteilung des Speichers in ausfhrbare und nicht ausfhrbare Speicherbereiche durch die
CPU (Execute Disable Bit oder NX Bit). Hierdurch kann die Ausfhrung von in Datenbereiche injiziertem Code unterbunden werden.
Beide Techniken fhren im Falle eines Buffer Overows zu einem Programmabbruch, ohne
dass der injizierte Code des Angreifers auf dem System ausgefhrt wird. Mittlerweile wurden
einige Mglichkeiten aufgezeigt, wie diese Mechanismen ungangen werden knnen. Nach derzeitigem Kenntnisstand bieten sie also keinen hundertprozentigen Schutz.
5.3 Race Conditions

Eine weitere Mglichkeit, wie eine Anwendung in Schwierigkeiten kommen kann, sind Race
Conditions.
Wie wir schon aus Kapitel 4 wissen, laufen auf einem Computersystem in der Regel mehrere
Anwendungen (scheinbar) gleichzeitig ab. Dies wird erreicht, indem das Betriebssystem hug
zwischen der Ausfhrung verschiedener Anwendungen wechselt. Dabei kann jede Anwendung
5.3 Race Conditions

Eigenschaft von
datei1.txt
87
erfllt
nicht erfllt
1. berprfung
OK
der Eigenschaft
Ausfhrung
von 2.
Anwendung A
Vernderung
der Eigenschaft
Code des
Angreifers
Zeit
A wird unterbrochen, Code des
Angreifers ausgefhrt
Ausfhrung von A wird fortgesetzt
Abbildung 5.2: Race Condition.
so programmiert werden, als wrde sie das System alleine benutzen. Dummerweise benutzt die
Anwendung das System aber nicht alleine, sondern sie wird ab und zu unterbrochen, und ein
anderer Prozess gelangt zur Ausfhrung. Hierdurch knnen sich parallel ablaufende Prozesse
gegenseitig stren, wenn sie gleiche Ressourcen benutzen.
Unter einer Race Condition versteht man allgemein formuliert den unkoordinierten Zugriff
mehrerer Prozesse (prziser formuliert: Kontrollsse) auf eine Ressource (beispielsweise eine
Datei), so dass das Ergebnis der Zugriffe von der Reihenfolge ihrer Durchfhrung abhngt, diese
aber nicht genau festgelegt ist.
Solche Race Conditions knnen zum Sicherheitsproblem werden, wenn ein Angreifer gezielt
versucht, sie zu seinen Zwecken zu missbrauchen. Betrachten wir als Beispiel eine Anwendung
A, die nacheinander folgende Instruktionen ausfhrt:
1. Teste, ob die Zugriffsberechtigungen von Datei
eine bestimmte Eigenschaft
erfllen. Wenn die Eigenschaft nicht erfllt ist, bricht das Programm ab, wenn sie erfllt
ist, gelangt 2. zur Ausfhrung.
2. Mache etwas mit Datei
Die implizite Annahme von Anwendung A ist, dass die gerade berprfte Eigenschaft erfllt
ist, wenn die Instruktion 2. zur Ausfhrung gelangt. Dies ist natrlich der Fall, wenn die Anwendung bei der Ausfhrung der Instruktionen 1. und 2. nicht unterbrochen wird.
Wird A aber zwischen der Ausfhrung von 1. und 2. unterbrochen und gelingt es einem Angreifer in dieser Zeit Code auszufhren, der die Zugriffsberechtigungen von
ndert,
so kann die getestete Eigenschaft bereits hinfllig geworden sein. Trotzdem wird A die 2. Instruktion ausfhren, da sich zwischen dem berprfen der Eigenschaft und der Ausfhrung der
Instruktion, die an das Ergebnis der berprfung geknpft sein sollte, die Eigenschaft gendert
hat. Dies ist als TOCTOU (Time-of-Check-Time-of-Use)-Fehler bekannt und in Abbildung 5.2
dargestellt. Um Race Conditions auszunutzen, ist ein Angreifer nicht nur auf Zuflle angewiesen, sondern er kann solche Race Conditions gezielt provozieren.
88
5 Anwendungen
aktiver
Inhalt
Anwendung
aktiver
Inhalt
Server
Internet
Anwendung ldt Programmcode vom Server
aus dem Internet herunter und fhrt den
Code auf dem lokalen Rechner aus
Abbildung 5.3: Aktiver Inhalt.
Generell sollten Race Conditions bei der Programmierung von Anwendungen vermieden werden, beispielsweise durch die Verwendung von Mechanismen zur Interprozesskommunikation
wie Semaphoren oder durch Benutzung atomarer Instruktionen, whrend deren Ausfhrung eine
Unterbrechung nicht mglich ist.
5.4 Software aus dem Internet

5.4.1 Downloads
Das Herunterladen von Software aus dem Internet (Download) erfreut sich zunehmender Beliebtheit. Doch wie wir in den kommenden Kapiteln noch genauer feststellen werden, lauern im
Internet einige Gefahren auf unvorsichtige Anwender. Auch das Herunterladen von Dateien und
das Installieren von Programmen ber das Netzwerk kann gefhrlich sein, denn eine heruntergeladene Datei oder ein solches Programm knnen durch einen Angreifer manipuliert worden sein
oder Malware enthalten (siehe nchstes Kapitel).
Zunchst ein Wort der Warnung. Wenn ein Benutzer eine Datei oder ein Programm aus dem
Internet oder von einem anderen Rechner herunterldt, kann er sich nie ganz sicher sein, ob diese
Dateien oder Programme in irgendeiner Weise von Dritten manipuliert wurden.
Die Integritt von Dateien oder Programmen kann aber durch die aus Abschnitt 3.6 bekannten kryptographischen Mechanismen (zur berprfung der Integritt) sichergestellt werden, also
durch digitale Signaturen und kryptographische Hash-Funktionen. Der Bereitsteller signiert
die Datei bzw. einen Hash der Datei und stellt diese Information zur Verfgung. Ein Empfnger
kann so berprfen, ob die Datei in irgendeiner Art verndert wurde. Groe Softwarehersteller
verwenden diese Methode.
5.4.2 Aktive Inhalte

5.4.2.1 Einfhrung
Neben der Installation von Programmen spielen aktive Inhalte eine wichtige Rolle.
Wie in Abbildung 5.3 gezeigt, versteht man unter diesem Begriff Programmcode, der aus
dem Internet durch eine Anwendung (meistens ber einen Webbrowser, siehe Abschnitt 13.3)
heruntergeladen und dann lokal ausgefhrt wird.
5.4 Software aus dem Internet
89
Abbildung 5.4: Unterschied zwischen normalem Assemblercode (links) und Java Bytecode (rechts).
Der Benutzer kann in den Programmen Einstellungen vornehmen, und beispielsweise spezizieren, von welchen Maschinen er aktive Inhalte akzeptiert und welche Arten von aktiven
Inhalten er zulassen will. Das Herunterladen und Ausfhren der aktiven Inhalte geschieht gem
dieser Einstellungen dann meistens automatisch, so dass sich der Benutzer im Gegensatz zum
eben beschriebenen Herunterladen eines Programms aus dem Internet nicht unbedingt bewusst
ist, dass aus dem Internet heruntergeladener Programmcode ausgefhrt wird.
Einige der Technologien, die typischerweise fr aktive Inhalte verwendet werden, sind JavaApplets, JavaScript und ActiveX Controls.
5.4.2.2 Java und Java-Applets
Java [Java-Web] ist eine vollwertige Programmiersprache, die in den letzten Jahren immer beliebter geworden ist. Dies hat eine ganze Reihe von Grnden. Java ist eine interpretierte Sprache.
Der vom Programmierer generierte Quellcode wird durch einen Java-Compiler in den sogenannten Java Bytecode bersetzt. Dieser Bytecode ist aber kein konkreter Assemblercode fr einen
bestimmten Prozessor und ein bestimmtes Betriebssystem, der direkt auf der entsprechenden
Plattform ablaufen kann, sondern ein abstrakter Assemblercode fr eine nicht real existierende
virtuelle Maschine. Um den Bytecode auf einem Rechner tatschlich ablaufen zu lassen, mssen
die Befehle des Java Bytecodes noch in Befehle der entsprechend verwendeten Hardware- und
Betriebssystemplattform bersetzt werden. Diese Aufgabe bernimmt die Java Virtual Machine
(JVM). Im Prinzip ist die Java Virtual Machine ein Programm, das die Abstrakte Maschine, die
den Bytecode verarbeitet, auf dem jeweiligen Rechner simuliert. Die Java Virtual Machine interpretiert die Bytecode-Befehle. Das bedeutet, jeder Befehl wird einzeln in einen oder mehrere
Assemblerbefehle des eigentlichen Rechners bersetzt. Dabei bernimmt die Java Virtual Machine aber auch noch eine ganze Reihe anderer Aufgaben, etwa die Verwaltung von Ressourcen.
Zum ffnen und Schlieen von Dateien existieren in Java eigene Funktionen, die von der Java
Virtual Machine in System Calls des eigentlichen Betriebssystems der Maschine bersetzt werden. Der Unterschied zwischen normalem Assemblercode und Java Bytecode ist in Abbildung
5.4 graphisch dargestellt.
Das Prinzip einer interpretierten Sprache bietet eine ganze Reihe von Vorteilen gegenber
dem direkten bersetzen in Assemblercode. Als Erstes ist der Bytecode (zumindest theoretisch)
plattformunabhngig. Dies bedeutet, dass er auf jeder Hardware und jedem Betriebssystem laufen kann, fr das eine Java Virtual Machine existiert. Hierdurch ergibt sich eine hohe Portabilitt
90
5 Anwendungen
von Java-Anwendungen. Eine einmal compilierte Anwendung ist auf verschiedenen Plattformen
verwendbar. Darber hinaus kann die plattformbergreifende Verfgbarkeit von Standardbibliotheken (sog. Class Libraries) einfach gewhrleistet werden, die ein hohes Abstraktionsniveau bei
der Programmierung ermglichen.
Aus unserer Perspektive sind natrlich die Implikationen hinsichtlich der Sicherheit von besonderem Interesse. Auch in diesem Bereich ist das Konzept einer Virtual Machine ausgesprochen hilfreich. Die Virtual Machine kann nmlich bei der Ausfhrung des Bytecodes zur Laufzeit
berwachen, was der Bytecode macht, und unerwnschte oder sicherheitsgefhrdende Aktionen unterbinden. Ein Buffer Overow wie im vorangegangenen Abschnitt skizziert kann durch
Laufzeitprfungen der Java Virtual Machine verhindert werden. Doch die Mglichkeiten dieses
Konzepts gehen noch weiter. Die Java Virtual Machine kann bestimmten Arten von Bytecode
die Benutzung bestimmter Funktionen und Standardbibliotheken untersagen. Auf diese Weise
ist es etwa mglich, den Zugriff auf das Dateisystem des Rechners zu unterbinden oder stark
einzuschrnken. Das Gleiche gilt fr Kommunikation ber das Netzwerk und andere Ressourcen
des Rechners. Die Programme laufen also in einer kontrollierten Umgebung ab, in der sie keinen
Schaden anrichten knnen (weil sie daran gehindert werden). Dieses Konzept ist als Sandboxing
bekannt.
In Java kommt diese Technik bei den Java-Applets zum Einsatz. Ein Applet ist ein Programm
in Java Bytecode, das ber das Internet von einem Server heruntergeladen wird und dann lokal
auf dem Rechner, der das Programm heruntergeladen hat, ausgefhrt wird. Meistens erfolgt das
Herunterladen und die Ausfhrung ber einen Webbrowser, dies muss aber nicht unbedingt der
Fall sein.
Das Risiko, ein (unbekanntes) Programm aus dem Netz herunterzuladen und auszufhren, ist
natrlich gro. Da Applets aber in einer Sandbox ablaufen, erscheint das Risiko vielen Benutzern
gering und im Verhltnis vertretbar. Es werden zwei Typen von Applets unterschieden, nmlich
trusted Applets (vertrauenswrdig) und untrusted Applets (nicht vertrauenswrdig). Nicht vertrauenswrdige Applets sind in ihren Funktionen wie folgt beschrnkt:
Sie haben keinen Lese- oder Schreibzugriff auf das Dateisystem,
sie drfen keine Netzwerkverbindungen betreiben auer zu der Adresse, von der sie geladen wurden,
sie drfen keine Bibliotheksfunktionen verwenden,
sie drfen keine Methoden denieren, die direkt mit dem Betriebssystem kommunizieren.
Applets knnen auerdem auf dem Rechner keine weiteren Programme starten. Trusted Applets sind hinsichtlich ihrer Zugriffsmglichkeiten auf Dateien etwas weniger eingeschrnkt. Sie
drfen in vom Benutzer spezizierten Verzeichnissen Lesen und Schreiben. Ein Applet wird zu
einem trusted Applet, wenn der Bytecode des Applets auf dem Rechner selbst installiert ist (also vom Benutzer installiert wurde) oder wenn das Applet kryptographisch von einer Institution
signiert wurde, welcher der Benutzer vertraut.
Die Prinzipien von Applets sind hinsichtlich der Sicherheitsfunktionen durchdacht. Kritisch
wird es allerdings, wenn die Java Virtual Machine Schwachstellen aufweist, die einem Applet
5.5 Zusammenfassung
91
das Ausbrechen aus der Sandbox oder das Ausfhren eigentlich verbotener Kommandos ermglichen. Gelingt dies, ist die Sicherheit des Rechners ernsthaft in Frage gestellt. Weitere Informationen ber die Sicherheit von Applets nden sich unter [Java-Web].
5.4.2.3 JavaScript
JavaScript ist eine von Java unabhngige Skriptsprache. Solche Programmiersprachen waren
ursprnglich fr die Automatisierung kleinerer, wiederkehrender Arbeitsablufe auf Betriebssystemebene gedacht. JavaScript ist als Sprache fr aktive Inhalte, speziell in Verbindung mit
Webbrowsern, konzipiert worden und wird in diesem Umfeld hug eingesetzt. JavaScript ermglicht beispielsweise die Vernderung der Anzeige von Webseiten auf Benutzeraktionen hin.
Die JavaScript-Programme liegen wie fr eine Skriptsprache typisch im Quelltext vor und sind
oft in Webseiten eingebettet. Dieser Quelltext wird ber das Internet heruntergeladen und dann
auf dem lokalen Rechner interpretiert und ausgefhrt (meistens durch den Webbrowser).
Die Sicherheitsvorzge eines interpretierten Programms hatten wir ja bereits gerade herausgestellt. Da JavaScript sogar im Quellcode vorliegt, gibt es prinzipiell hnlich zu Java sehr gute
Mglichkeiten, die Ausfhrung eines JavaScript-Programms zu berwachen und wie oben skizziert in einer Sandbox ablaufen zu lassen. Auch die Sicherheitsmodelle sind hnlich zu Java.
Da jedoch die Ausfhrung der Skripte den Anwendungen selbst berlassen ist, welche die
Skripte herunterladen, ist es in der Praxis zu einer ganzen Reihe von Sicherheitsproblemen mit
JavaScript gekommen. Daher ist besonders bei unbekannten Webseiten Misstrauen angebracht.
Allerdings ist auch bei bekannten Webseiten Vorsicht geboten, denn manchmal ist es Angreifern
mglich, in die Seiten anderer Anbieter ihre boshaften Inhalte einzuschleusen, beispielsweise
ber Cross-Site-Scripting (XSS). Fr einige Webbrowser gibt es Plug-Ins, die vor einigen solcher
Angriffe Schutz bieten.
5.4.2.4 ActiveX Control
Eine weitere Mglichkeit fr aktive Inhalte ist ActiveX Control. Bei diesem Verfahren wird direkt ausfhrbarer Code auf das System geladen und ausgefhrt. Entsprechend ist eine Kontrolle
der Aktivitten solcher ActiveX Controls sehr schwierig. Daher wird das gleiche Prinzip angewendet, was wir schon bei Downloads kennengelernt haben, nmlich eine digitale Signatur des
Codes. Stammt dieser von einer vertrauenswrdigen Quelle, so wird dem Code vertraut.
Eine Signatur bietet zwar einen Schutz vor Vernderung des Codes durch Angreifer, doch
auch unvernderter Code von einer vertrauenswrdigen Quelle kann Fehler erhalten, die von
Angreifern ausgenutzt werden knnen. Entsprechende Angriffe hat es auch tatschlich schon
gegeben.
5.5 Zusammenfassung
Die auf einem System betriebenen Anwendungsprogramme mssen ebenfalls gegen
Angriffe geschtzt sein, einerseits um die Sicherheit der Anwendung und ihrer Daten
selbst zu gewhrleisten, andererseits um nicht durch die Anwendung ein Einfallstor
zur Kompromittierung des Systems zu ffnen.
92
5 Anwendungen
Buffer Overows in Anwendungen knnen es einem Angreifer ermglichen, Code

auf einem System einzuschmuggeln und auszufhren. Auch Race Conditions knnen
von einem Angreifer ausgenutzt werden Die Verhinderung von Buffer Overows und
Race Conditions bei der Programmierung einer Anwendung ist mglich.
Softwaredownloads aus dem Netz knnen riskant sein. Die Ausfhrung von aktiven
Inhalten im Internet ist auf verschiedene Arten mglich. Eine relativ sichere Variante
sind Java Applets, die aufgrund der Struktur von Java als durch die Virtual Machine
interpretierter Sprache und der Einschrnkungen im Funktionsumfang von Applets als
relativ sicher gelten knnen. Weitere Mglichkeiten fr aktive Inhalte sind JavaScript
und ActiveX Control.
5.6 bungsaufgaben
Aufgabe 5.1:
Beschreiben Sie, welcher Stellenwert der Sicherheit eines Anwendungsprogramms zukommt.
Aufgabe 5.2:
Erlutern Sie kurz, was ein Buffer Overow und was eine Race Condition ist und wie man sich
jeweils dagegen schtzen kann.
Aufgabe 5.3:
Erklren Sie, welche Gefahren beim Download von Software ber das Internet bestehen.
Aufgabe 5.4:
Beschreiben Sie kurz die Arbeitsweise von Java-Applets und diskutieren Sie dabei die Frage,
welche Funktionen Java beinhaltet, die die Ausfhrung von Applets im Vergleich zu eigenstndigen Programmen sicherer macht.

Aufgabe 5.5:
Recherchieren Sie die genaue Funktionsweise von JavaScript und das dort verwendete Sicherheitsmodell. Betrachten Sie dabei speziell das Problem des Cross-Site-Scripting.
Aufgabe 5.6:
Recherchieren Sie die genaue Funktionsweise von ActiveX Control und das dort verwendete
Sicherheitsmodell.
Kapitel 6
Malware
6 Malware
6.1 Einfhrung
Auf einem modernen Computersystem laufen zu jedem Zeitpunkt eine Vielzahl von Programmen, die dem Benutzer (oder den Benutzern) des Systems mehr oder weniger ntzliche Funktionen bieten. In diesem Kapitel werden wir uns mit Programmen und Programmcode beschftigen,
die unerwnscht auf dem Rechner laufen und eventuell dem Benutzer oder System Schaden zufgen. Programme und Programmcode, die vorstzlich fr solche Zwecke geschrieben wurden,
werden als Malware oder Schadprogramme bezeichnet. Wir wollen in diesem Kapitel die wichtigsten Arten von Malware beleuchten und uns mit der Frage befassen, wie man sich dagegen
schtzen kann.
Das Spektrum an Malware ist ebenso unbeschrnkt wie die Bandbreite sinnvoller Anwendungsprogramme. Es hat sich eingebrgert, verschiedene Typen von Schadprogrammen zu unterscheiden. Die bergnge zwischen diesen Klassen sind ieend. Im Folgenden listen wir
einige der Typen auf. Alle Typen enthalten in der Regel Code, der dem System oder den Nutzern
schadet. Nach ihrer Verbreitungsmethode unterscheidet man:
(Computer-)Viren: Ein Virus ist ein Programm oder Programmfragment, das sich bei Ausfhrung repliziert, indem es den eigenen Code in andere Programme oder Dokumente injiziert. Werden diese Programme oder Dokumente spter ausgefhrt oder aufgerufen, wird
der Virencode wiederum ausgefhrt, wodurch das Virus Schaden anrichtet und sich weiterverbreitet.
Trojaner: Programme, die scheinbar eine ntzliche Funktion haben, aber im Programm
versteckten Code beinhalten, der dem System oder den Nutzern schadet.
Wrmer: Programm, das sich selbst ber ein Netzwerk (Internet oder Intranet) auf andere
Maschinen repliziert, indem es Schwachstellen in ber das Netzwerk angebotenen Diensten ausnutzt und die befallenen Systeme oder deren Nutzer schdigt.
Nach der Art des angerichteten Schadens unterscheidet man zwischen:
Spyware: Unter diesem Begriff versteht man Programme, die ohne Genehmigung und Wissen des Benutzers Informationen sammeln und diese dann weiterleiten. Hierunter fallen
beispielsweise Keylogger, welche die Maus- und/oder Tastatureingaben eines Benutzers
aufzeichnen. Auf diese Weise knnen vertrauliche Informationen wie beispielsweise Passwrter entwendet werden.
94
6 Malware
Adware: Programme, die dem Benutzer (ungewollt) Anzeigen prsentieren.

(Malware-)Dialer: Eigentlich bezeichnet der Begriff Dialer Programme, die einem Computer ber ein Modem und das Telefonnetz Zugriff auf das Internet ermglichen. Diese
Funktion wird meistens durch das Betriebssystem bereitgestellt. Malware-Dialer berschreiben die Standardeinstellungen fr den Zugriff auf das Internet ber die Telefonverbindung ohne Wissen und Einverstndnis des Benutzers und veranlassen die Einwahl
ber teure Service-Telefonnummern oder Anwahlpunkte im Ausland. Aufgrund der zunehmenden Verbreitung von nicht-telefonbasierten Zugangsmechanismen zum Internet sind
Malware-Dialer etwas aus der Mode gekommen.
Zombie-Malware: Programm, das einen Computer kompromittiert und so in einen Zombie
verwandelt. Darunter versteht man einen Rechner, der durch unbefugte Dritte ferngesteuert
und kontrolliert werden kann, etwa ber ein Bot-Net.
Backdoors (auch Trapdoors genannt): Modikation eines ursprnglich auf einem System
vorhandenen Programms, so dass sich ein Angreifer unter Umgehung der auf dem System
vorhandenen Sicherheitsmechanismen Zugriff auf das System verschaffen kann.
Root Kit: Modikation einer Gruppe von Programmen mit dem Ziel, Aktivitten eines
Angreifers auf einem System fr andere Benutzer des Systems (den Administrator eingeschlossen) unsichtbar zu machen.
Malware kann auf allen Softwareebenen operieren und angreifen. Die Palette reicht von BootSektor-Viren, die unmittelbar beim Systemstart aktiv werden, bevor das Betriebssystem geladen
wird, ber Programme, die Schwachstellen im verwendeten Betriebssystem ausnutzen wie etwa
Wrmer, bis hin zu Malware, die nur in Verbindung mit bestimmten Anwendungsprogrammen
funktioniert wie Email-Viren oder Makroviren.
Wir werden uns nun eingehend mit den unterschiedlichen Typen von Malware und der Frage,
wem sie schadet und wem sie nutzt, befassen.
6.2 Schaden
Der durch Malware angerichtete Schaden kann vielfltig sein. Die Mglichkeiten beinhalten:
Zerstrung der Hard/Software der kompromittierten Maschine: Malware kann Programme
und Daten auf dem betroffenen System lschen, verndern und zerstren. Dies betrifft
nicht nur die Software, sondern auch die Hardware.
Beeintrchtigung der Benutzbarkeit: Aufgrund der Aktivitten der Malware kann die Benutzbarkeit des Rechners oder auch eines Netzwerks stark eingeschrnkt sein.
Datendiebstahl/Datenmissbrauch: Malware kann Daten vom inzierten System, angefangen von einzelnen Dateien bis hin zu Eingaben eines Benutzers per Maus oder Tastatur
an andere Rechner weiterleiten. Auf diese Weise knnen vertrauliche Daten gestohlen und
dann missbraucht werden. Es sollen auch bereits Dateien durch Malware verschlsselt und
Benutzer erpresst worden sein.
6.3 Verbreitung und Funktionsweise
95
Missbrauch des Rechners fr andere Aktivitten: Ein kompromittierter Rechner kann zu

einem Zombie werden, der durch den Angreifer von auen ferngesteuert werden kann.
Ein solcher ferngesteuerter Rechner eignet sich hervorragend zum Absenden von unerwnschten Massenemails, besser bekannt unter dem Namen Spam (siehe Abschnitt 13.1),
als Ausgangspunkt einer Denial-of-Service-Attacke (siehe Kapitel 12) oder eines Angriffs
auf weitere Maschinen, um auch sie in Zombies zu verwandeln.
Kosten des Entfernens: Es ist bereits klar geworden, dass niemand Malware auf seinen
Systemen haben mchte. Daher muss im Fall eines erfolgreichen Angriffs die Malware
mglichst schnell wieder vom System entfernt werden. Falls eine umgehende Beseitigung
nicht mglich ist, mssen Manahmen getroffen werden, die zumindest eine weitere Verbreitung der Malware verhindern. Die Kosten solcher Aktionen knnen je nach Art und
Umfang des betroffenen Netzes sehr hoch sein.

6.3.1 Verbreitung
Die Mglichkeiten, wie Malware auf ein System gelangen kann, sind ausgesprochen vielfltig.
Bei Wrmern reicht zur Inzierung des Systems ein Netzwerkanschluss und eine Schwachstelle
in einem angebotenen Dienst. Bei Viren reicht das Ausfhren oder Aufrufen einer inzierten Datei, die wie auch immer auf den Rechner gelangt sein kann. Bei Trojanern installiert ein argloser
Benutzer das Programm selbst auf seinem System und fhrt es aus. Das Gleiche kann auch bei
Adware, Spyware und Dialern der Fall sein.
Generell wollen wir bei der Verbreitung von Malware im Folgenden zwei Dimensionen unterscheiden:
Aktion eines legitimen Systembenutzers bei der Installation: Unter einer Aktion verstehen wir beispielsweise das Kopieren oder Herunterladen einer Datei oder auch das Einlegen eines Datentrgers, das Ausfhren einer Datei oder ffnen eines Anhangs einer Email.
Keine Aktion in unserem Sinn fhrt der Benutzer dann aus, wenn die Malware ohne spezische Benutzeraktion auf das System gelangt ist. Malware erfordert entweder eine Aktion
eines legitimen Systembenutzers oder nicht, um auf einen Rechner gelangen.
Mechanismus zur Verbreitung der Malware: Malware kann selbstreplizierend oder nichtselbstreplizierend sein.
Tabelle 6.1 zeigt, in welche Klassen einige der bereits vorgestellten Malware-Typen fallen. Viren und Wrmer sind beide selbstreplizierend. Whrend sich ein Wurm ohne Benutzerinteraktion
auf einem System selbstttig einnisten kann, erfordert ein Virus zu seiner Verbreitung meistens
die Aktion eines Benutzers wie das Ausfhren eines Programms oder das ffnen einer Datei.
Nicht-selbstreplizierende Malware gelangt entweder auf ein System, indem ein Benutzer des
Systems Aktionen ausfhrt, beispielsweise die Malware selbst installiert. Nicht-selbstreplizierende Malware kann nur dann ohne Benutzerinteraktion auf ein System gelangen, wenn ein manueller Angriff auf das System ber das Netzwerk oder durch einen Innentter erfolgreich war.
96
6 Malware
mit Benutzeraktion
selbstreplizierend
Virus
ohne Benutzeraktion
Wurm
nicht-selbstreplizierend
Spyware, Adware, Trojaner, Dialer
Backdoor, Platzierung
durch Hackerangriff
Tabelle 6.1: Klassikation von Malware hinsichtlich ihrer Verbreitungsmechanismen.
Wenn der Tter sich Zugriff auf das System verschafft, kann er beliebige Malware installieren,
beispielsweise um spter wieder einfach Zugriff auf das System haben zu knnen.
Fr Malware, die ohne Benutzerinteraktion auf ein System gelangt, ist es charakteristisch, dass
sie entweder automatisch ber das Netzwerk auf das System kommt oder durch einen Angreifer
(Innentter oder ber das Netzwerk) manuell auf dem Rechner platziert wird.
6.3.2 Funktionsweise
6.3.2.1 Viren
Nun wollen wir einige wichtige Klassen von Viren etwas genauer betrachten, insbesondere Viren,
die sich in ausfhrbare Programme einnisten, und Makroviren.
Programmviren Viren, die Programme befallen, bestehen wie ausfhrbare Programme aus
Assemblercode. Assemblercode ist stark von der jeweiligen Hardwareplattform und auch dem
verwendeten Betriebssystem abhngig, da Programme einige Funktionen des Rechners nicht direkt ansprechen drfen, sondern nur durch Verwendung von System Calls des Betriebssystems
(siehe Abschnitt 4.3). Da sich der Virencode in den Programmcode einbetten muss, ist ein Programmvirus meistens auf eine bestimmte Plattform und Betriebssystem als Wirt festgelegt und
kann Systeme mit anderer Plattform oder anderem Betriebssystem nicht inzieren. Der ausfhrbare Code des Virus wird geeignet im Code des ursprnglichen Programms platziert und das
Programm so modiziert, dass beim Programmstart zunchst der Virus aufgerufen wird. Um
lnger unbemerkt zu bleiben, transferieren viele Viren danach die Kontrolle zurck an das ursprngliche Programm, so dass dessen Funktion durch den Virus scheinbar nicht beeintrchtigt
wird. Gelangt das Virus zur Ausfhrung, kann es weitere Programmdateien auf dem Rechner
inzieren und gegebenenfalls weiteren Schadcode ausfhren.
Viren mssen nicht unbedingt nur ausfhrbare Programme inzieren. Einige Viren nisten sich
im Hauptspeicher des Rechners ein und bleiben dort durchgehend aktiv. Solche Viren werden
als speicherresidente Viren bezeichnet. In bestimmten Fllen knnen sich Viren auch ber Dokumente, also eigentlich nicht ausfhrbare Daten, verbreiten. Dies ist unter anderem mglich,
wenn die Anwendungsprogramme, welche die Dokumente aufrufen, Schwachstellen aufweisen,
welche die Ausfhrung des injizierten Code ermglicht (siehe Abschnitt 5.2).
97
Makroviren Unter Makrosprachen versteht man Programmiersprachen, mit denen Programme, sogenannte Makros, geschrieben werden, die nicht eigenstndig, sondern innerhalb eines
anderen Programms, beispielweise einer Textverarbeitung oder einer Tabellenkalkulation, ausgefhrt werden. Mit Makros lassen sich huge, komplexe Arbeitsablufe innerhalb der Anwendung automatisieren. Makros sind oft ein Bestandteil der in Dateien abgespeicherten Anwendungsdaten und knnen sich so leicht verbreiten. Ein bekanntes Beispiel einer Makrosprache
ist Visual Basic for Applications (VBA). Auch wenn Makrosprachen innerhalb eines anderen
Programms ablaufen, so sind sie von ihrem Funktionsumfang her meistens vollwertige Programmiersprachen. Insbesondere besitzen sie Befehle, um Dateien der Anwendung zu ffnen,
zu ndern und wieder abzuspeichern. Konsequenterweise knnen in diesen Sprachen auch Viren geschrieben werden. Wie Programmviren sind Makroviren bei ihrer Verbreitung auf eine
Umgebung angewiesen, in der die Makrosprache ausgefhrt werden kann. Dies ist meistens eine
bestimmte Anwendung (es sei denn, mehrere Anwendungen verwenden dieselbe Makrosprache).
Wird diese Anwendung auf mehrere Systeme portiert, so ist es mglich, dass Makroviren auch
auf unterschiedlichen Betriebssystemen und Hardwareplattformen ablaufen knnen.
Netzwerklaufwerke Oftmals mssen in Institutionen Informationen gespeichert werden, die

fr mehrere Benutzer gleichzeitig verfgbar sein mssen. In solchen Szenarien bietet sich die
Verwendung von Netzwerklaufwerken an, die es erlauben, ein Dateisystem oder Teil eines Dateisystems von einem Rechner aus ber das Netzwerk auf mehrere andere Rechner zu exportieren.
Jeder Rechner kann das Dateisystem genauso verwenden, als wre es auf einer lokalen Festplatte
vorhanden (Details wie Zugriffsrechte wollen wir an dieser Stelle nicht betrachten).
Dummerweise ist ein Netzwerklaufwerk nicht nur fr die Benutzer praktisch, sondern auch fr
selbstreplizierende Malware. Wenn Schreibzugriff auf ein Netzwerklaufwerk besteht, kann sich
die Malware in eine Datei dort replizieren. Wird dann diese Datei von einem anderen Rechner
aus aufgerufen, so kann die Malware vom Netzwerklaufwerk auf das Dateisystem des anderen
Rechners springen. Schwerer wiegt vielleicht noch, dass es fr einen Benutzer kaum eine Mglichkeit gibt, sich gegen solche Angriffe zu schtzen.
6.3.2.2 Wrmer
Im Gegensatz zu Viren, die bei ihrer Verbreitung auf Wirtsprogramme oder -dokumente angewiesen sind, verbreiten sich Wrmer selbstndig ber ein Netzwerk. Wrmer nutzen Schwachstellen
in ber das Netzwerk angebotenen Diensten aus. Diese Schwachstellen sind meistens entweder einem spezischen Betriebssystem oder einem Anwendungsprogramm zuzuordnen, das den
Dienst anbietet. Hat sich ein Wurm erfolgreich auf einem Rechner eingenistet, so versucht er
ber das Netzwerk, andere Rechner zu nden, die ebenfalls die Schwachstelle besitzen und diese auszunutzen. Der Wurm kann dabei zufllig Netzwerkadressen durchprobieren oder gezielter
vorgehen.
Da sich Wrmer im Gegensatz zu Viren selbstttig verbreiten und nicht auf Benutzeraktionen
angewiesen sind, ist ihre Ausbreitungsgeschwindigkeit hug sehr hoch. Innerhalb kurzer Zeit
kann sich ein Wurm ber das Internet auf Tausenden von Rechnern verbreitet haben.
98
6 Malware
6.3.2.3 Backdoors und Root Kits

Whrend Viren und Wrmer sich, einmal programmiert und losgelassen, selbst weiterverbreiten,
gibt es auch Malware, die quasi von Hand durch einen Angreifer auf dem System untergebracht
wird. Ist ein Angreifer mit viel Mhe erfolgreich in ein System eingedrungen und hat endlich Administratorrechte erlangt, liegt es nur in der menschlichen Natur, sich das Leben fr das nchste
mal leichter zu machen. Auerdem mchte der Angreifer nur ungern das Risiko eingehen, dass
die mhsam gefundenen Sicherheitslcken geschlossen werden und so der Zugriff auf das System unterbunden wird. Also bietet es sich an, ein Hintertrchen in das System einzubauen, mit
dem der Angreifer das nchste mal sehr viel einfacher Zugriff erhlt, und dabei mglichst noch
nicht einmal bemerkt werden kann. Wenn ein Angreifer Administratorrechte erlangt hat, sind
derartige Wnsche tatschlich zu erfllen.
Beginnen wir mit dem Zugriff auf das System. Eine sehr einfache Mglichkeit fr den Angreifer wre es, sich ein eigenes Benutzerkonto auf dem System einzurichten und diesem Benutzer
Administratorrechte zu geben. Diese Variante ist zwar sehr einfach, aber auch nicht schwierig
zu entdecken. Geschickter ist es, das Programm zur Anmeldung von Benutzern auf dem System
durch ein eigens vom Angreifer geschriebenes Programm zu ersetzen. Whrend das ursprngliche Programm nach Benutzername und Passwort fragt und die Eingaben dann etwa in einer
Datenbank berprft, bernimmt das vom Angreifer modizierte Programm exakt die gleiche
Funktion mit einem kleinen, aber entscheidenden Unterschied. Der Angreifer whlt eine Benutzername/Passwortkombination, bei der die sonst bliche berprfung von Benutzernamen
und Passwort umgangen und nicht durchgefhrt wird, sondern direkter Zugriff als Administrator
erfolgen kann. Durch diese Backdoor kann der Angreifer sich spter wieder einfach Administratorzugriff auf das System verschaffen.
Dabei mchte er natrlich vom richtigen Administrator nur ungern entdeckt werden, etwa aufgrund von Eintrgen in Logdateien oder da vom Angreifer gestartete Prozesse auffallen. Daher
bietet es sich an, die Programme auf dem Rechner, welche die Benutzeraktivitten anzeigen und
protokollieren, ebenfalls durch Programme zu ersetzen, die den Angreifer verbergen. Solche Programme werden auch Root Kit genannt. Ist ein System durch Angreifer kompromittiert worden,
hinterlassen die Angreifer derartige Programme mit groer Wahrscheinlichkeit.
6.3.2.4 Zombies
Ist ein Angreifer auf einer Maschine erfolgreich gewesen oder ist anderweitig Malware auf die
Maschine gelangt, so kann der betroffene Rechner sich in einen Zombie verwandeln. Dies bedeutet, dass der Rechner von Dritten ber das Netzwerk ferngesteuert werden kann und so als
Ausgangspunkt fr weitere Angriffe auf andere Rechner oder fr kriminelle Aktivitten verwendet werden kann, ohne dass die legitimen Benutzer und Administratoren dies bemerken. Die
Malware kontaktiert das Internet mit scheinbar harmlosen Anfragen und erhlt als Antwort entsprechende Befehle, was zu tun ist. Hierzu machen sich Angreifer hug Peer-to-Peer-Strukturen
und andere Anwendungen wie IRC zu nutze, bei denen sich die Urheber von bereitgestellten Daten nur schwer zurckverfolgen lassen. In der Regel ist natrlich nicht nur ein einziger Rechner,
sondern eine ganze Gruppe von Rechnern kompromittiert. Diese Rechner gemeinsam bilden ein
Bot-Net.
6.4 Schutzmanahmen und Entfernung von Malware
99

6.4.1 Schutzmanahmen
Eine Inzierung mit Malware ist unangenehm, der mgliche Schaden schwer abschtzbar und
die Beseitigung teuer. Daher kommt der Prvention gegen Malware entscheidende Bedeutung
zu. Im Folgenden wollen wir einige der mglichen Schutzmanahmen nher darstellen.
6.4.1.1 Virenscanner
Virenscanner sind Programme, die ein System auf mgliche Infektionen mit Malware, in erster
Linie Viren, berprfen. Viele verschiedene Firmen bieten Virenscanner an, die sich in ihrem
Funktionsumfang und in der Zuverlssigkeit der Erkennung von Malware unterscheiden. Der
Funktionsumfang einiger Produkte geht ber die hier beschriebenen Merkmale deutlich hinaus.
Die wichtigsten Funktionen eines Virenscanners beinhalten
die berprfung einzelner oder aller Laufwerke und des Speichers auf vorhandene Viren,
die berprfung von Dateien auf Virenbefall vor dem ffnen oder Ausfhren und die
Verhinderung der Aktion bei Verdacht auf Virenbefall des Objekts und
die Entfernung von Viren aus inzierten Objekten.
Das Erkennen von Viren in einer Datei ist komplex. Virenscanner durchleuchten die zu untersuchenden Dateien Byte fr Byte und vergleichen vereinfacht ausgedrckt die dort gefundenen
Bytemuster mit bekannten Mustern von Viren. Solche Muster werden Signaturen genannt. Wird
eine bereinstimmung mit einer Virensignatur entdeckt, so ist das untersuchte Objekt hchstwahrscheinlich inziert und Gegenmanahmen werden eingeleitet. Leider lassen sich mit dieser
Methode nur Viren nden, deren Signatur bereits bekannt ist. Daher ist es notwendig, die Signaturen des Virenscanners regelmig auf den neuesten Stand zu bringen. Es gibt Viren, die
sich vor Signaturscans zu verbergen versuchen, indem sie bei der Replikation keine identischen
Kopien von sich erzeugen, sondern sich beim Replizieren verndern, so dass signaturbasierte
Anstze schwieriger, aber nicht unmglich werden. Ein Virus kann beispielsweise Teile von sich
verschlsseln und dabei bei jedem Replikationsvorgang den Schlssel verndern.
Zustzlich zu signaturbasierten Anstzen verwenden moderne Virenscanner Heuristiken, um
mgliche Viren auch ohne bekannte Signatur aufspren zu knnen. Darber hinaus werden oftmals Programme zur Laufzeit auf ungewhnliche Aktivitten hin berprft, so dass ein Virus
beispielsweise dann erkannt wird, wenn er eine andere Datei inzieren will.
6.4.1.2 Systemkonguration, Dienste und Einstellungen
Generell gilt ein einfacher Merksatz: Sicherheitslcken in Software, die auf einem System nicht
aktiv ist, knnen nicht ausgenutzt werden. Speziell gilt dies fr Netzwerkdienste (siehe Kapitel
7), die ber das Netzwerk von Angreifern oder Wrmern ausndig gemacht und angegriffen
werden knnen. Daher sollten nicht bentigte Softwarekomponenten und Dienste abgeschaltet
oder erst gar nicht installiert werden.
100
6 Malware
Ein weiterer wichtiger Punkt ist die Vergabe von Benutzerrechten. Diese sollten zur Verhinderung der Verbreitung von Malware mglichst restriktiv gehandhabt werden. Ein nicht notwendiges, aber erteiltes Schreibzugriffsrecht auf einem Netzwerklaufwerk ermglicht es Malware
vielleicht, dieses Laufwerk zu inzieren.
6.4.1.3 Patches und Updates
Wenn Schwachstellen in Betriebssystemen oder Anwendungen entdeckt werden, stellen die Hersteller der Software so schnell wie mglich Patches oder Updates zur Verfgung, welche die Sicherheitslcken beseitigen. Es empehlt sich dringend, solche Patches umgehend zu installieren.
Wird eine neue Lcke bekannt, so dauert es in der Regel nicht lange, bis Malware auftaucht, die
diese ausnutzt. Daher empehlt es sich, die auf einem System vorhandene Software regelmig
dahingehend zu berprfen, ob sie auf dem neuesten Stand ist. Die meisten Betriebsysteme und
Anwendungen berprfen mittlerweile automatisch ber das Netzwerk, ob sicherheitsrelevante
Patches und Updates vorliegen.
Bei veralteter Software, die von den Herstellern nicht mehr gepegt wird, knnen ebenfalls
Schwachstellen entdeckt werden. Hier werden aber keine Patches mehr angeboten, so dass die
Sicherheitslcken nur schwer geschlossen werden knnen. Daher empehlt sich der Einsatz veralteter Software aus Sicherheitsgrnden nicht.
6.4.1.4 Heterogenitt
Malware ist oft auf bestimmte Betriebssysteme und Softwarepakete festgelegt. Angreifer konzentrieren sich logischerweise auf solche Betriebssysteme und Pakete, die weit verbreitet sind,
um eine mglichst groe Zahl mglicher Opfer zu haben. Wird daher ein selteneres Betriebssystem und ein weniger huges Softwarepaket verwendet, sinkt die Gefahr eines Angriffs. Ebenso
werden Netzwerke robuster gegen Angriffe, wenn sie aus Rechnern mit verschiedenen Betriebssystemen bestehen. Dies gilt aus dem gleichen Grund, aus dem in der Natur Mischwlder gegenber Schdlingen resistenter sind als reine Monokulturen. So interessant und richtig diese
Aussage auch ist, so wenig ist dieses Prinzip in der Praxis durchgngig umsetzbar.
6.4.1.5 Firewalls und Filtermechanismen
Eine Firewall (siehe Kapitel 9) grenzt das interne Netzwerk einer Institution gegen das Internet ab
und kontrolliert den Verkehr zwischen den Netzen. Spezielle Filtermechanismen in Firewalls und
Anwendungsprogrammen knnen auf verschiedenen Ebenen verdchtige Objekte ausltern und
so eventuell einen Beitrag dazu leisten, dass Malware nicht in das Netz der Institution gelangt.
Beispielsweise kann eine Firewall bei richtiger Konguration den Einfall von Wrmern in das
Unternehmensnetz verhindern. Ein Filter auf Applikationsebene kann beispielsweise verdchtige
Anhnge aus Emails herausltern und so Malware daran hindern, ber Email in das Netz der
Institution zu gelangen.
Doch diese Mechanismen bieten keinesfalls einen vollstndigen Schutz. Malware kann an
der Firewall vorbei in das Institutionsnetzwerk gelangen und die Filtermechanismen lassen sich
101
austricksen (siehe Abschnitt 9.4). Ein unvorsichtiger Benutzer, der aus dem Internet eine Datei
herunterldt und ausfhrt, wird von der Firewall nicht unbedingt gestoppt werden.
6.4.1.6 Vorsichtige Benutzer
Bei vielen Arten von Malware, allem voran den Trojanern und (den meisten) Viren, ist zur Verbreitung die Aktion eines Benutzers erforderlich, wie das ffnen eines per Email erhaltenen
Dokuments oder das Herunterladen und Starten eines Programms. Sie basieren also auf Social
Engineering. Im richtigen Moment den Anhang einer Email zu ffnen oder nicht kann den Unterschied zwischen einem virenverseuchten System und viel erspartem rger bedeuten. Insofern
ist es also gerade fr Institutionen wichtig, die Benutzer ber mgliche Bedrohungen aufzuklren und zu kritischem Handeln zu veranlassen. Gerade per Email wird hug versucht, dieses
kritische Handeln auszuschalten, beispielsweise indem dem Benutzer eine (scheinbare) horrend
hohe Telefonrechnung, Anzeige wegen angeblicher illegaler Downloads und so weiter prsentiert
wird. Der erste Impuls ist natrlich das ffnen des Anhangs, das angeblich nhere Informationen zu Widerspruchsmglichkeiten oder hnlichem enthlt, aber in Wirklichkeit aus Malware
besteht, die sich beim ffnen auf dem System einnistet.
Auch beim Herunterladen von Dateien aus dem Netz kann Malware auf ein System gelangen.
6.4.2 Entfernung
Ist Malware auf einen Rechner gelangt und konnte dort aktiv werden, waren die Schutzmanahmen auf dem System zumindest hinsichtlich der speziellen Malware nicht ausreichend.
Dies kann unterschiedlichste Grnde haben. Selbst wenn auf einem System alle erdenklichen
Schutzmanahmen ergriffen werden, bleibt doch ein gewisses Restrisiko. Wenn Malware eine
bisher unbekannte Schwachstellen ausnutzt, knnen die obigen Schutzmechanismen versagen.
In einigen Fllen werden verffentlichte Schwachstellen von Hackern schneller ausgenutzt als es
gelingt, einen Patch zum Schlieen der Lcke bereitzustellen.
Ist es zu einer Inzierung mit Malware gekommen, besteht der erste Schritt darin, das Problem
berhaupt zu erkennen. Da die getroffenen Schutzmanahmen versagt haben, ist es mglich,
dass die Malware zunchst unbemerkt auf dem System agieren und sich gegebenenfalls ber das
Netzwerk oder anderweitig weiterverbreiten kann. Sich hufende Fehlermeldungen und ungewhnliches Systemverhalten wie geringere Leistung knnen ein Warnzeichen sein, aber genauso
gut durch Hardwaredefekte oder andere Probleme verursacht sein.
Ist das Problem erkannt worden, soll die Malware vom System natrlich sofort entfernt und
das System wieder in einen arbeitsbereiten Zustand versetzt werden, falls mglich ohne Datenverluste. Leider gibt es fr die Entfernung von Malware kein Patentrezept. Der entstandene
Schaden kann irreversibel sein, beispielsweise wenn vertrauliche Daten bereits ber das Netz
weitergeleitet wurden.
Der erste und entscheidende Schritt nach der Entdeckung von Malware ist es, das betroffene
System sofort von allen anderen Systemen zu trennen und unter Quarantne zu nehmen. Dies
betrifft bei Viren auch mglicherweise inzierte Netzwerklaufwerke auf anderen Maschinen.
Danach ist eine Analyse erforderlich, wie die Malware auf das System gelangen konnte. Die
ausgenutzte Sicherheitslcke muss gefunden und geschlossen werden. Dabei ist ebenfalls zu
102
6 Malware
prfen, ob diese Lcke auch auf anderen Rechnern vorhanden ist und dort ebenfalls geschlossen
werden muss.
Anschlieend sollte die Malware vom System entfernt werden. Die Suberungsmanahmen
sollten nach einem Neustart des Systems von einem malwarefreien Medium erfolgen (beispielsweise einer CD-Rom). Bei einem Virus sollten alle Laufwerke mit einem Virenscanner (neueste
Signaturdaten) berprft werden. Nach einem ersten Durchgang zum Entfernen der Viren empehlt sich ein zweiter Durchgang, um zu berprfen, ob tatschlich keine weiteren inzierten
Dateien gefunden werden. Die berprfung anderer Systeme im Netzwerk, die mglicherweise
betroffen sein knnten, ist ebenfalls dringend zu empfehlen.
In einigen Fllen ist es ratsam, statt einer Suberung des betroffenen Systems eine Neuinstallation durchzufhren und die Daten von einem (malwarefreien) Backup aufzuspielen.
6.5 Zusammenfassung
Unter dem Begriff Malware fasst man Programme und Programmcode zusammen,
die unerwnscht auf einem System laufen und dem System oder seinen Benutzern
mglicherweise Schaden zufgen. Es gibt viele verschiedene Typen von Malware, darunter Viren, Wrmer und Trojaner. Die bergnge zwischen diesen Typen sind ieend. Malware kann die Zerstrung von Software oder Hardware des kompromittierten Systems verursachen, dessen Benutzbarkeit beeintrchtigen, Datendiebstahl oder
Datenmissbrauch ermglichen oder ein System anderweitig missbrauchen. Malware
kann in verschiedene Klassen eingeteilt werden.
Schutzmanahmen knnen helfen, Systeme weniger anfllig fr Malware zu machen.
Hierzu zhlen der Betrieb eines Virenscanners, eine restriktive Konguration des Systems, das regelmige Patchen und Updaten, die Verwendung von Firewalls und Sensibilisierung der Benutzer fr das Problem.
6.6 bungsaufgaben
Aufgabe 6.1:
Erlutern Sie die folgenden Begriffe: Malware, Virus, Trojaner, Wrmer, Spyware,
Adware, Dialer, Zombie, Backdoor, Root Kit.
Aufgabe 6.2:
Geben Sie einige Mglichkeiten dafr an, welchen Schaden Malware verursachen kann.
Aufgabe 6.3:
Beschreiben Sie das prsentierte Klassikationsschema fr Malware und geben Sie fr jede Klasse ein Beispiel.
6.6 bungsaufgaben
103
Aufgabe 6.4:
Listen Sie verschiedene Typen von Viren auf und beschreiben Sie Unterschiede und Gemeinsamkeiten.
Aufgabe 6.5:
Erlutern Sie, welche Schutzmanahmen gegen Malware getroffen werden knnen.
Aufgabe 6.6:
Wann kann aus Sicht eines Angreifers ein manueller Angriff auf eine Maschine sinnvoller sein
als ein automatisierter Angriff beispielsweise durch einen Virus?

Aufgabe 6.7:
Geben Sie technische Mglichkeiten an, wie Benutzer daran gehindert werden knnen, potentiell
gefhrliche Aktionen, wie beispielsweise der Download und die Ausfhrung von Programmen
aus dem Internet oder das ffnen des Anhangs einer Email, durchzufhren.
Aufgabe 6.8:
Recherchieren Sie die genaue Funktionsweise von Viren und Virenscannern.
Aufgabe 6.9:
Befassen Sie sich genauer mit dem Problem, wie Malware von einem inzierten System wieder
entfernt werden kann.
Kapitel 7
7Netzwerke
Netzwerke und Netzwerkprotokolle
und Netzwerkprotokolle
7.1 Grundlagen
In den kommenden Kapiteln werden wir uns mit Netzwerksicherheit beschftigen. Dieses Kapitel soll die hierfr notwendigen Grundlagen ber Netzwerke kurz skizzieren. Natrlich kann
ein Kapitel wie dieses kein Lehrbuch ber Netzwerke ersetzen. Aus der Vielzahl kompetenter
und umfassender Standardwerke ber dieses Themas sei hier auf [Tan03], [KR02], [Com02]
oder [BH01] verwiesen. Wenn Sie sich mit den Grundlagen von Netzwerken bereits auskennen,
knnen Sie dieses Kapitel berspringen.
Die zunehmende Vernetzung von Computern und Computersystemen hat in Unternehmen und
im privaten Bereich zu tiefgreifenden Vernderungen gefhrt. Ein Netzwerk besteht aus mehreren, autonomen, verbundenen Gerten. Das Spektrum mglicher Gerte reicht von Grorechnern
und Datenbanken ber Server und PCs bis hin zu PDAs und Mobiltelefonen. In naher Zukunft
werden wahrscheinlich ebenfalls verstrkt Gerte aus dem Embedded-Bereich, beispielsweise
Sensoren, Aktoren und Haushaltselektronik, vielleicht sogar Waschmaschinen und Khlschrnke, hinzukommen.
Heutige Netzwerke arbeiten in den allermeisten Fllen paketbasiert. Dies bedeutet, dass alle zu
bertragenden Informationen in kleine Informationseinheiten, die Pakete, aufgeteilt werden, die
dann vom Sender direkt oder ber Vermittlungsstationen zum Empfnger befrdert werden. Dabei arbeitet die Mehrzahl nach dem Store-and-Forward-Prinzip. Dies bedeutet die Pakete werden
bei den Vermittlungsstationen zunchst vollstndig empfangen und erst danach weitergesendet.
Paketbasierte Netzwerke lassen sich weiter unterteilen in Datagramm-Netze und Virtual Circuit-Netze. In Datagramm-Netzen wird jedes einzelne Paket, auch Datagramm genannt, mit vollstndigen Informationen ber den jeweiligen Empfnger versehen und dann unabhngig von anderen Paketen, die zum selben Informationsuss gehren, zum Empfnger geleitet, analog zur
Befrderung von Briefen durch die Post. In Virtual Circuit-Netzen muss vor der Befrderung der
Pakete eine Verbindung zwischen Sender und Empfnger aufgebaut werden, und alle Pakete, die
zum selben Informationsuss gehren, nehmen denselben Weg durch das Netz.
In paketbasierten Netzen gibt es oft keine Garantie dafr, dass ein losgeschicktes Paket auch
wirklich beim Empfnger ankommt, im Gegenteil: Pakete knnen verloren gehen, oder in anderer Reihenfolge beim Empfnger ankommen, als sie losgeschickt wurden. Der Sender erfhrt
hiervon nichts.
106
7 Netzwerke und Netzwerkprotokolle
Schnittstelle zu Schicht i
Schicht i+1
Dienst von Schicht i

Protokoll auf Schicht i
Schicht i
Schicht i-1
Abbildung 7.1: Schichten, Dienste, Protokolle, Schnittstellen.
7.2 Das Schichtenmodell

Ein Server irgendwo im Internet und ein Mobiltelefon besitzen nicht allzu viele Gemeinsamkeiten. Whrend ein Server meistens ber eine Gigabit-Ethernetleitung drahtgebunden an das
Netzwerk angeschlossen sein wird, ist ein Mobiltelefon drahtlos mit einer weitaus geringeren
Datenrate angebunden. Hardware, Software und Betriebssysteme dieser Gerte sind vollkommen
unterschiedlich. Dennoch soll es in Netzwerken mglich sein, ber all diese Grenzen hinweg in
jeder Hinsicht heterogene und unterschiedliche Gerte miteinander kommunizieren zu lassen.
Konzeptionell untersttzt wird dies durch hierarchische Aufteilung der Netzwerke in verschiedene Schichten. Jede Schicht auf einem Gert bietet bestimmte Dienste (engl. Services) an, die
von der darbergelegenen Schicht auf diesem Gert genutzt werden. Eine Schicht realisiert die
Dienste, indem sie virtuell mit der gleichen Schicht auf einem anderen Gert kommuniziert. Die
Regeln, welche dieser Kommunikation zugrundeliegen, werden Protokoll genannt. Das Protokoll legt den Ablauf der Nachrichtenbertragung und die Aktionen beim Empfang und/oder dem
Versenden einer Nachricht fest. Tatschlich aber werden die Daten nicht direkt miteinander ausgetauscht, sondern sie werden an die darunterliegende Schicht zur Befrderung weitergegeben.
Anzahl, Name und Funktion der einzelnen Schichten kann von Netzwerk zu Netzwerk und von
Rechner zu Rechner verschieden sein.
Durch klar denierte Schnittstellen zwischen den einzelnen Schichten wird eine wesentlich
grere Flexibilitt erreicht, als es in einem monolithischen System mglich wre. Solange eine
Schicht die der darberliegenden Schicht angebotenen Dienste beibehlt und keine neuen Anforderungen an die darunterliegende Schicht stellt, knnte eine Schicht theoretisch vollstndig
ausgetauscht werden, ohne dass die darber- oder darunterliegenden Schichten gendert werden mssten. Die Zusammenhnge zwischen Schichten, Diensten, Protokollen und Schnittstellen
sind in Abbildung 7.1 graphisch dargestellt.
Es gibt verschiedene Schichtenmodelle. Die wohl bekanntesten sind TCP/IP als real existierende Protokollfamilie und das ISO/OSI-Referenzmodell [ISO]. Wie allgemein blich werden wir
uns in diesem Buch an einem fnfschichtigen Referenzmodell orientieren. Dieses Modell ist in
mit Zwischenstationen
Ende zu Ende
107
Applikationsschicht
Transportschicht
Netzwerkschicht
Datenverbindungsschicht
Physikalische
Schicht
Abbildung 7.2: Referenzmodell mit Applikationsschicht, Transportschicht, Netzwerkschicht, Datenverbindungsschicht und physikalischer Schicht.
Abbildung 7.2 dargestellt. Wie in der Abbildung gezeigt, mssen nicht alle an der Kommunikation zwischen zwei Stationen beteiligten Zwischenstationen auf allen Schichten operieren.
Die fnf Schichten in diesem Modell sind
1. Schicht Physikalische Schicht: Die physikalische Schicht regelt, wie die Bits zwischen
miteinander direkt verbundenen Stationen physikalisch bertragen werden. Diese Schicht
ist die Domne von Elektrotechnikern und wird von uns nicht weiter behandelt. Es reicht
uns zu wissen, dass sie existiert.
2. Schicht Datenverbindungsschicht: Diese Schicht sitzt auf der physikalischen Schicht
und regelt, wie die bertragung zwischen zwei benachbarten, direkt miteinander verbundenen Stationen abluft. Die auf dieser Schicht bertragenen Informationseinheiten werden auch Datenrahmen (kurz: Rahmen) oder Frames genannt. Sie sind aufgrund der physikalischen Eigenschaften des zugrundeliegenden Mediums und anderer Aspekte oftmals
hinsichtlich ihrer Lnge beschrnkt oder mssen eine gewisse Mindestlnge aufweisen.
Die Hauptaufgabe dieser Schicht liegt typischerweise bei der Entdeckung und gegebenfalls auch Beseitigung von bertragungsfehlern, beispielsweise durch Fehlerkontroll- oder
Korrekturmechanismen oder durch Besttigung von korrekt erhaltenen Rahmen. Eine weitere wichtige Aufgabe ist die Regelung des Zugriffs auf den bertragungskanal bei Mehrbenutzerbetrieb und die Ausung von Zugriffskonikten zwischen mehreren Benutzern.
3. Schicht Netzwerkschicht: Diese Schicht regelt die bertragung von Daten innerhalb
eines Netzwerks und bernimmt dabei auch das Routing, also die Weiterleitung von Informationseinheiten vom Sender zum Empfnger auf einem mglichst optimalen Weg. Die
auf dieser Schicht bertragenen Informationseinheiten werden auch Pakete genannt. Die
108
Netzwerkschicht regelt automatisch die Befrderung von Paketen zwischen Stationen, die
nicht direkt miteinder verbunden sind. Sie bestimmt, ber welche Zwischenstationen die
Pakete geleitet werden mssen, damit sie beim richtigen Empfnger ankommen. Eine weitere wichtige Aufgabe der Netzwerkschicht ist Fragmentierung. Gerade beim Transport
ber Zwischenstationen kann es vorkommen, dass ein Paket ber eine bestimmte Datenverbindungsschicht transportiert werden muss, das ganze Paket aber zu gro fr die entsprechende Datenverbindungsschicht ist. Die Netzwerkschicht teilt dieses Paket dann in
mehrere Pakete von geeigneter Gre auf und fgt diese Teilpakete (auch Fragmente genannt) spter wieder zu einem Paket zusammen.
4. Schicht Transportschicht: Die Transportschicht nimmt Daten von den jeweiligen Anwendungen an. Da die Netzwerkschicht (falls notwendig) schon regelt, wie die Daten ber
Zwischenstationen zum Empfnger gelangen, ist die Transportschicht Ende-zu-Ende, d.h.
Sender und Empfnger kommunizieren auf dieser Schicht (scheinbar) direkt miteinander. Die auf dieser Schicht bertragenen Informationseinheiten werden auch Segmente genannt. Die Protokolle auf der Transportschicht arbeiten hug verbindungsorientiert, d.h.
sie bauen vor der eigentlichen bertragung von Daten zwischen Sender und Empfnger eine Verbindung auf (und nach Beendigung wieder ab). Durch den Aufbau einer Verbindung
ist es mglich, eventuell beim Transport aufgetretene Verluste (speziell bei DatagrammNetzwerken) zu entdecken, oder Segmente, die in falscher Reihenfolge eintreffen, wieder
richtig zu ordnen. Mit anderen Worten: Was die Applikationsschicht beim Empfnger losgeschickt hat, kommt auch so bei der Applikationsschicht des Senders an. Solche Transportprotokolle werden auch als zuverlssige Transportprotokolle bezeichnet. Es gibt auch
verbindungslose Transportprotokolle, die Sender und Empfnger keine Garantie geben,
dass ein losgeschicktes Segment auch wirklich beim Empfnger ankommt. Solche Protokolle werden auch als unzuverlssige Transportprotokolle bezeichnet. Sie werden hauptschlich fr Anwendungen benutzt, bei denen der gelegentliche Verlust eines Segments
unproblematisch ist, es jedoch wichtig ist, erhaltenen Segmente mglichst schnell an die
Anwendung weiterzugeben, wie etwa bei Realzeit-Multimediaanwendungen.
5. Schicht Applikationsschicht: Die Protokolle auf dieser Schicht sind sehr stark von
der jeweiligen Anwendung abhngig und nutzen die darunterliegenden Mechanismen der
Transportschicht.
Die oben skizzierte Aufgabenverteilung zwischen den Schichten hat sich im Lauf der Zeit so
als am praktikabelsten erwiesen. Andere Aufgabenverteilungen oder auch die Duplizierung von
Mechanismen, etwa bei Verbindungsaufbau und Fehlerkontrolle, kommen vor und knnen sogar
erwnscht sein.
Jedes Protokoll auf jeder Schicht muss zur Wahrnehmung seiner Aufgabe in der Lage sein,
die zu transportierenden Informationen (synonym auch Nutzdaten, Daten, Nutzlast oder Payload
genannt), welche ihm von der darberliegenden Schicht bergeben wurden, mit weiteren protokollrelevanten Informationen zu versehen. Um etwa Segmente wieder in die richtige Reihenfolge
zu bringen oder den Verlust einzelner Segmente zu entdecken, mssen die Segmente irgendwie
nummeriert werden. Damit ein Verbindungsaufbau mglich ist, muss eine Signalisierung fr diesen Aufbau deniert sein, zur Fehlerkontrolle muss eine Prfsumme an den befrderten Daten
109
Empfnger
Sender
A
Nutzdaten
Nutzdaten
Applikationsschicht
Nutzdaten
Header des
Transportprotokolls
Nutzdaten
Transportschicht
Nutzdaten
Header des
Netzwerkprotokolls
DH N T A Nutzdaten DT
Header/Trailer des
Datenverbindungsschichtprotokolls
Nutzdaten
Netzwerkschicht
DH N
Nutzdaten DT
Abbildung 7.3: Header und Trailer von Protokollen. Zu transportierende Daten aus Sicht der jeweiligen
Schicht sind grau dargestellt.
angebracht werden usw. Diese protokollspezischen Informationen drfen nicht mit den transportierten Daten verwechselt werden. Daher versieht jedes Protokoll die zu bertragenen Daten
mit einem Header oder Trailer. Header und Trailer der Protokolle der darberliegenden Schichten werden auf der darunterliegenden Schicht als zu transportierende Daten betrachtet, ohne dass
diese interpretiert oder verwendet werden. Dies ist in Abbildung 7.3 dargestellt.
Das derzeit wichtigste und weltweit dominierende Netzwerk ist das Internet. Es basiert auf
der sogenannten TCP/IP-Protokollfamilie. Doch TCP/IP kann nicht nur im Internet eingesetzt
werden. TCP/IP kann auch zur Vernetzung von Maschinen zu einem autonomen, nicht mit dem
Internet verbundenen Netzwerk, wie etwa einem ausschlielich rmeninternen Netzwerk, benutzt werden.
Das Internet ist eher ein dezentral organisiertes Netz von Netzen als ein einziges Netz. Die
einzelnen Netzwerkbetreiber (Firmen, Institutionen, Privatpersonen ...) knnen ihre individuellen
Netze weitestgehend alleinverantwortlich und ohne Abstimmung mit Dritten konzeptionieren
und administrieren, sofern bestimmte Konventionen eingehalten werden, die das Zusammenspiel
mit den anderen Netzen im Internet mglich machen.
Alle Gerte in einem Netzwerk, angefangen von Arbeitsplatz-PCs bis hin zu Vermittlungsstationen, verfgen ber ein oder mehrere Interfaces, durch die sie mit dem Netzwerk verbunden
sind. In Netzwerken mssen die vorhandenen Stationen bei der bertragung von Daten eindeutig
angesprochen werden knnen. Hierzu ist eine eindeutige Dereferenzierung notwendig, die ber
sogenannte Adressen erfolgt. Auf den unterschiedlichen Schichten knnen unterschiedliche Typen von Adressen verwendet werden. Die Adressen sind dabei jeweils den einzelnen Interfaces
der Gerte zugeordnet. Eine Station mit mehreren aktiven Interfaces verfgt daher ber mehrere,
unterschiedliche Adressen.
110

Byte
Destination Address Source Address
Type
Data (46-1500 Bytes)
FCS
Abbildung 7.4: Ethernet Framestruktur.
7.3 Die wichtigsten Netzwerkprotokolle im berblick

Im Folgenden werden wir kurz die wichtigsten Netzwerkprotokolle vorstellen, insbesondere solche, die im Internet verwendet werden. Diese Darstellung gibt nur einen allgemeinen berblick.
Wir werden spter weitere sicherheitsrelevante Details der Protokolle unter die Lupe nehmen.
7.3.1 Datenverbindungsschicht: LAN-Technologien

7.3.1.1 IEEE 802.3 / Ethernet
Im diesem Buch werden wir uns schwerpunktmig mit Datenverbindungsschichten befassen,
deren rumliche Ausdehnung beschrnkt ist. Alle direkt auf der Datenverbindungsschicht miteinander verbundenen Stationen gemeinsam bilden ein sogenanntes Local Area Networks (LAN).
Zwischen diesen Stationen ist eine (direkte) Kommunikation mglich, ohne dass die Netzwerkschicht eingreifen muss. Wie schon erwhnt werden die ausgetauschten Informationseinheiten
als Frames oder Rahmen bezeichnet.
Der am weitesten verbreitete Typ von Datenverbindungsschicht ist Ethernet, leicht abgewandelt auch als IEEE 802.3 bekannt und in [IEEE 802.3] speziziert. An ein Ethernet-LAN knnen
mehrere Stationen angeschlossen werden, wobei jede Station mit jeder direkt kommunizieren
kann. Ethernet, zumindest in seiner ursprnglichen Variante, ist ein Broadcast-Medium. Dies bedeutet, dass jede Station alle bertragenen Frames empfngt, auch solche, die an einen anderen
Empfnger gerichtet sind.
Ethernet verwendet zur Adressierung 6-Byte lange MAC-Adressen, die konventionsgem in
Hexadezimalnotation durch Doppelpunkte oder einen Strich getrennt dargestellt werden, also
beispielsweise 02:46:8A:CE:13:57. Die MAC-Adresse eines Interfaces ist global eindeutig. Dies
bedeutet, jede Netzwerkkarte in jedem Computer besitzt eine individuelle MAC-Adresse, die
weltweit nur ein einziges mal vergeben ist. Entsprechend identiziert diese Adresse das Interface eindeutig, hnlich wie eine Seriennummer ein Auto eindeutig identiziert. Dies wird
erreicht, indem die ersten drei Bytes der MAC-Adresse vom IEEE zentral koordiniert vergeben werden. Diesen sogenannten Organizationally Unique Identier (OUI) muss ein Hersteller
von Netzwerkinterfaces beim IEEE erwerben. Auf der LAN-Datenverbindungsschicht ist es ausschlielich mglich, Frames direkt von einem Rechner zu einem anderen Rechner im gleichen
LAN zu senden. Es ist daher auch nicht mglich, die MAC-Adressen von Gerten in anderen
LANs in Erfahrung zu bringen.
Die Struktur eines Ethernet-Frames ist in Abbildung 7.4 dargestellt. Die einzelnen Felder im
Ethernet-Frame haben folgende Bedeutung:
111
Destination Address (6 Byte): MAC-Adresse des Empfngers.

Source Address (6 Byte): MAC-Adresse des Senders.
Type (2 Byte): Speziziert das Protokoll auf der darberliegenden Schicht, an das die Daten nach Transport bergeben werden (und von dem die transportierten Daten stammen).
Spezische Werte sind z.B. 2048 (0800 Hex) fr IP, 2054 fr ARP.
Data: Daten, Mindestlnge 46 Bytes, Hchstlnge 1500 Bytes.
Frame Check Sequence (FCS, 4 Byte): Prfsumme.
Nicht dargestellt ist eine 8 Byte lange Prambel, die den Frameanfang markiert.
7.3.1.2 IEEE 802.11 Wireless Local Area Networks
Zunehmender Beliebtheit erfreuen sich drahtlose lokale Netzwerke nach dem IEEE 802.11Standard [IEEE 802.11], auch Wireless Local Area Networks (WLANs) genannt. Das Frameformat von 802.11 weist erhebliche Differenzen zu Ethernet auf und ist wesentlich umfangreicher.
Dies liegt vor allem daran, dass solche Netze mit einem erhhten Administrationsaufwand verbunden sind und auch ber Zusatzfunktionen verfgen mssen, die in drahtgebundenen LANs
nicht notwendig sind. Wir werden uns mit WLANs in Abschnitt 15.3 noch genauer befassen.
7.3.1.3 Bridges und Switches
Die Stationen in einem gemeinsamen Local Area Networks (LAN) knnen direkt auf der Datenverbindungsschicht miteinander kommunizieren. Dabei mssen nicht alle Stationen im LAN die
gleiche Datenverbindungsschicht verwenden. Durch die Verwendung von Bridges ist die Kommunikation auf der Datenverbindungsschicht ohne Eingreifen der Netzwerkschicht auch ber
Technologiegrenzen hinweg mglich. Eine Bridge bersetzt Frames des einen Formats (z.B.
Ethernet) in Frames des jeweils anderen Formats (z.B. IEEE 802.11). Dabei arbeitet sie wie die
Vermittlungsstationen auf der Netzwerkschicht nach dem Store-and-Forward-Prinzip. Bridges
knnen auch verwendet werden, um eigentlich getrennte LANs mit gleicher oder unterschiedlicher Technologie zu einem groen gemeinsamen LAN zu verbinden oder um die Struktur und
damit die Performance eines LANs zu verbessern. Ein solches Gert wird Switch genannt und
verfgt oft ber eine groe Zahl von Interfaces, an die Maschinen, andere Switches, Bridges
und Router angeschlossen werden. Switches und Bridges sind fr die anderen Gerte im Netzwerk transparent und weder auf der Netzwerk- noch auf der Datenverbindungsschicht sichtbar.
Bridges und Switches lernen durch Beobachtung, an welchem ihrer Interfaces sich eine Station
bendet und senden Frames an diese Stationen nur noch an dieses Interface weiter. Wenn jede
Station direkt an einen zentralen Switch angeschlossen wird, kann damit die vorhin erwhnte
Broadcast-Eigenschaft von Ethernet faktisch unterbunden werden.
Moderne Switches erlauben es, LANs ber verschiedene Switches eventuell sogar an verschiedenen Standorten zu verteilen, so dass die einzelnen LAN-Segmente beispielsweise nach Abteilungszugehrigkeit und nicht mehr wie frher nur nach Gebude oder Etage zusammengestellt
werden knnen. Diese Technologie ist als Virtual LAN (VLAN) bekannt.
112

Byte
Data
Protocol (1 oder 2 Bytes)
Abbildung 7.5: PPP-Frame.
7.3.2 Datenverbindungsschicht: Das Point-to-Point Protocol (PPP)

In vielen Anwendungsfllen sind zwei Stationen im Netz durch eine direkte Leitung miteinander verbunden. Fr solche Szenarien wurde das Point-to-Point Protocol (PPP) entwickelt
[RFC 1661]. PPP wurde (und wird) beispielsweise bei Modemverbindungen zwischen dem Rechner des Kunden und dem Gateway eines Serviceproviders eingesetzt. PPP speziziert neben
dem eingesetzten Rahmenformat auch ein Kontrollprotokoll fr Aufbau, Konguration, Test und
Abbau der Verbindung auf der Datenverbindungsschicht. Nach dem Aufbau dieser Verbindung
erfolgt eine optionale Authentikationsphase. Danach mu die ber PPP betriebene Netzwerkschicht konguriert werden. Die Konguration erfolgt durch ein separates, fr die verwendete
Netzwerkschicht spezisches Protokoll, das die jeweils bentigten Parameter aushandelt.
Es knnen gleichzeitig verschiedene Netzwerkprotokolle ber eine PPP-Verbindung aktiv sein,
daher wird wie bei Ethernet ein Protocol-Feld verwendet, das aus ein oder zwei Bytes bestehen
kann. Da eine PPP-Verbindung zwischen zwei Stationen aktiv ist, ist eine Adressierung auf der
Datenverbindungsschicht nicht notwendig, da klar ist, wer jeweils der Sender und wer der Empfnger ist. Die Rahmenstruktur eines PPP-Frames ist in Abbildung 7.5 skizziert.
Das PPP-Protokoll ist fr uns vor allen Dingen von Interesse, da fr PPP Sicherheitsprotokolle
entwickelt wurden, die auch als Grundlage fr weitere Sicherheitsprotokolle dienen. Darber
hinaus gibt es eine ganze Reihe von Weiterentwicklungen von PPP wie etwa PPP over Ethernet
(PPPoE) [RFC 2516], die heute extensiv genutzt werden.
7.3.3 Netzwerkschicht: Internet Protocol (IP)

Das Internet Protocol (IP) wie in [RFC 791] speziziert und seine Nebenprotokolle bilden das
Rckgrat des Internets. IP ist ein unzuverlssiges, verbindungsloses Protokoll. Dies bedeutet,
dass IP-Pakete einfach versendet werden knnen, ohne dass vorher eine Verbindung zum Empfnger oder anderen Zwischenstationen aufgebaut werden muss. Verschiedene Pakete zwischen
denselben Sendern und Empfngern knnen vllig unterschiedliche Wege durch das Netz nehmen. IP merkt sich nicht, welche Pakete wohin befrdert wurden. Der Sender oder die Zwischenstationen erhalten durch das IP-Protokoll keine Information darber, ob ein losgeschicktes Paket
beim Empfnger oder der nchsten Zwischenstation angekommen ist. Ein bei der Befrderung
durch das Netz verlorengegangenes Paket wird nicht nochmals bertragen.
IP verwendet zur Adressierung 4 Byte lange IP-Adressen, die in dezimaler Notation mit einem
Punkt zwischen den einzelnen Bytes dargestellt werden, also etwa 192.168.81.206.
113
Byte
Bit
Version
IHL
Type of Service
DF MF
Identification
Time to live
Protocol
Source Address
Destination Address
Options (0 oder mehr)
Total Length
Fragment Offset
Header Checksum
Abbildung 7.6: IP-Paketstruktur (Header).
Hauptaufgaben der Netzwerkschicht sind das Routing sowie die Fragmentierung. Sie ermglicht es, Pakete, die zu gro fr die zugrundeliegende Datenverbindungsschicht sind, in mehrere
Fragmente passender Gre aufzuteilen. Die Fragmentierung kann beim Sender oder auch bei
einer Zwischenstation erfolgen. Nach der Fragmentierung setzen die Fragmente unabhngig voneinander ihren Weg zum Empfnger fort. Eine weitere Fragmentierung von Fragmenten ist ebenfalls mglich. Die einzelnen Fragmente werden erst beim Empfnger wieder zum ursprnglichen
Paket zusammengesetzt.
7.3.3.1 IP-Header
Die Struktur des Headers eines IP-Pakets ist in Abbildung 7.6 abgebildet. Die einzelnen Felder
haben folgende Bedeutung:
Version (4 Bit): Version des verwendeten IP-Protokolls, derzeit 4.
Initial Header Length (IHL, 4 Bit): Lnge des IP-Headers in 4-Byte-Schritten. Ntig, um
evtl. verwendete Optionen erkennen zu knnen. Die Optionen vergrern den Header jeweils um Vielfache von 4 Byte.
Type of Service (1 Byte): Wird zur Priorisierung von Paketen verwendet, etwa um Realzeitdaten Vorrang einrumen zu knnen.
Total Length (2 Byte): Gesamtlnge des Pakets in Bytes.
Identication (2 Byte): Identikationsnummer des Pakets, notwendig bei der Zusammensetzung fragmentierter Pakete.
DF/MF: Flags fr Fragmentierung/Defragmentierung. DF-Flag (dont fragment) zeigt
an, ob das Paket nicht fragmentiert werden darf. MF Flag (more fragments) hilft bei
der Defragmentierung. Abgesehen vom letzten Fragment ist bei Fragmenten eines Paketes
dieses Flag auf 1 gesetzt.
Fragment Offset (13 Bit): Bei Fragmentierung werden die Bytes der transportierten Daten
des ursprnglichen Pakets durchnummeriert. Dieses Feld gibt bei einem Fragment an, mit
welchem Byte der Daten dieses Fragment beginnt (gemessen in 8-Byte Schritten). Diese
Information wird zur Zusammensetzung von Fragmenten bentigt.
114
Time to live (1 Byte): Dieses Feld wird vom Sender mit einem Anfangswert (max. 255)
initialisiert. Bei jeder Zwischenstation auf der IP-Ebene wird dieser Wert um 1 dekrementiert. Erreicht der Wert null, wird das Paket verworfen und eine Fehlermeldung via
ICMP-Protokoll an den Sender des Pakets geschickt.
Protocol (1 Byte) : Speziziert das Protokoll auf der darberliegenden Schicht, an das die
Daten bergeben werden sollen. Spezische Werte sind z.B. 1 fr ICMP, 6 fr TCP oder
17 fr UDP.
Header Checksum (2 Byte): Prfsumme ber den Header.
Source Address (4 Byte): IP-Adresse des Senders.
Destination Address (4 Byte): IP-Adresse des Empfngers.
Options: Dieses Feld wird verwendet, wenn Optionen des IP-Protokolls genutzt werden.
Wir verwenden fr IP Source Address auch synonym den deutschen Begriff IP-Quelladresse.
Ebenso bezeichnen wir die IP Destination Address als IP-Zieladresse.
7.3.3.2 IPv4 und IPv6
Das hier dargestellte IP-Protokoll der Version 4 (IPv4) stammt aus dem Jahr 1981, als die heutige Verbreitung des Internet noch in keinster Weise absehbar war. Daher weist dieses Protokoll
einige Dezite auf. Beispielsweise ist der Adressraum von IPv4 aus heutiger Sicht zu klein und
die Mobilittsuntersttzung unzureichend. Bereits 1995 wurde als Nachfolger das IP-Protokoll
der Version 6 (IPv6) standardisiert. Gegenwrtig ist die Spezikation [RFC 2460] aktuell. Wer
allerdings mit einem schnellen, weltweiten Siegeszug von IPv6 gerechnet hatte, wurde bitter
enttuscht. In Europa und den USA ist IPv4 auch ber zehn Jahre nach der Standardisierung
von IPv6 nach wie vor das alles dominierende Netzwerkprotokoll. IPv6 fristet noch ein klgliches Nischendasein, was nicht zuletzt daran liegt, dass fr alle technischen Schwchen von
IPv4 mittlerweile zufriedenstellende Lsungen entwickelt und standardisiert wurden, die in Verbindung mit IPv4 eingesetzt werden knnen. Daher besteht technisch betrachtet derzeit keine
Notwendigkeit, auf IPv6 zu migrieren. In einigen Jahren, wenn der IPv4-Adressraum vollstndig
ausgeschpft sein wird und tatschlich keine freien IPv4-Adressen mehr verfgbar sind, wird
sich dies wahrscheinlich ndern.
IPv4 und IPv6 weisen deutliche Unterschiede auf. Eigentlich ist IPv6 eher ein neues Protokoll
als eine neue Version von IPv4. Da es uns in diesem Buch um die prinzipielle Betrachtung von
Sicherheitsaspekten und nicht um eine lckenlose Betrachtung aller relevanten Protokolle und
Details geht, macht es fr uns keinen groen Unterschied, welche Version des IP-Protokolls
wir betrachten. Daher werden wir uns in Beispielen und Erluterungen ausschlielich mit dem
dominierenden IPv4 beschftigen.
7.3.3.3 Das ICMP-Protokoll
Das ICMP-Protokoll wie in [RFC 792] speziziert dient zur bermittlung von Statusinformationen und Kontrollnachrichten zwischen Zwischenstationen (auch Empfngern) und Sendern von
115
IP-Paketen. Das ICMP-Protokoll verwendet das IP-Protokoll zur bermittlung von Nachrichten,
ist selbst aber auch integraler Bestandteil der Netzwerkschicht. ICMP-Nachrichten untergliedern
sich in verschiedene Typen und Codes und werden unter anderem erzeugt,
falls Pakete von einem Gateway nicht weitergeleitet werden knnen, etwa da das Zielnetzwerk oder der Empfnger der Nachricht unbekannt oder nicht erreichbar ist,
falls die Lebensdauer des Pakets berschritten ist, d.h. der TTL-Wert 0 erreicht hat,
zur Feststellung ob ein bestimmter anderer Rechner erreichbar ist (ICMP-Echo-Request
bzw. ICMP-Echo-Response, in der Literatur wird die Response auch ICMP-Echo-Reply
genannt).
Auf das Format von ICMP-Nachrichten soll an dieser Stelle nicht weiter eingegangen werden.
7.3.3.4 Routing unter IP
Auf der IP-Ebene wird das Routing in Endsystemen und Zwischenstationen meistens ber Routingtabellen durchgefhrt. Mittels dieser Tabelle wird entschieden, an welche nchste, direkt
ber die Datenverbindungsschicht erreichbare Station ein Paket (weiter-)geschickt werden muss.
Die Entscheidung wird dabei anhand der IP-Zieladresse eines Pakets und der Routingtabelle getroffen, und es werden die IP-Adresse der nchsten Station sowie das richtige Ausgangsinterface
ermittelt. Zwischenstationen auf der IP-Schicht, welche die Vermittlung von Paketen bernehmen, werden als Router bezeichnet.
Aufgrund der mglichen Anzahl von Stationen im Internet werden in der Routingtabelle eines
Routers nicht alle Stationen einzeln eingetragen, sondern sie werden hierarchisch in Gruppen
zusammengefasst. Dabei ndet meistens das Classless Inter-Domain Routing (CIDR) Anwendung [RFC 4632]. Die Routingtabelle enthlt darber hinaus als Eintrag die Adresse eines sogenannten Default-Gateway. An diese Station werden alle Pakete weitergeleitet, fr die in der
Routingtabelle kein passender Eintrag gefunden wurde. Mit Gateway wird allgemein eine Zwischenstation bezeichnet, die verschiedene Netze miteinander verbindet.
Routingtabellen knnen statisch aufgebaut sein, also beispielsweise durch einen Benutzer per
Hand eingegeben werden, oder aber durch Routingprotokolle dynamisch erzeugt sein. Bekannte
Routingprotokolle und Verfahren im Internet sind etwa das Routing Information Protocol (RIP)
[RFC 2453], Open Shortest Path First (OSPF) [RFC 2328] oder das Border Gateway Protocol
(BGP) [RFC 1771].
In Endsystemen wird zur Konguration des IP-Protokolls minimal die eigene IP-Adresse,
die Netzwerkmaske und das Default-Gateway bentigt. Unter der IP-Adresse ist das entsprechende Interface des Rechners im Netz erreichbar. Alle Pakete, die an den Rechner gerichtet
sind oder von ihm verschickt werden, tragen diese Adresse entweder als IP-Zieladresse oder
IP-Quelladresse. Fr ein Endsystem gibt die Netzwerkmaske in Verbindung mit der eigenen IPAdresse an, welche anderen Rechner direkt ber die Datenverbindungsschicht erreicht werden
knnen und welche nicht. IP-Pakete an direkt erreichbare Rechner werden direkt ber die Datenverbindungsschicht an die Rechner weitergeschickt. IP-Pakete an Rechner, die nicht direkt
ber die Datenverbindungsschicht erreichbar sind, werden an das Default-Gateway gesendet.
116
Netzwerkmaske in Binrdarstellung
Dezimal
CIDR-Darstellung
11111111 00000000 00000000 00000000

11111111 11111111 11110000 00000000
11111111 11111111 11111111 00000000
11111111 11111111 11111111 10000000
255.0.0.0
255.255.240.0
255.255.255.0
255.255.255.128
/8
/20
/24
/25
Tabelle 7.1: Einige Netzwerkmasken in binrer Darstellung, Dezimaldarstellung und CIDR-Darstellung.
Das Default-Gateway ist ein Router mit mehreren Interfaces, von dem aus das Paket dann weiter
in Richtung seines Ziels befrdert wird.
Wie die IP-Adresse besteht die Netzwerkmaske aus vier Bytes, also 32 Bits, und wird ebenfalls
in Dezimalnotation aufgeschrieben. Die in einer Netzmaske auftretende Bitfolge ist (zumindest
in der Praxis) nicht beliebig, sondern besteht aus einer Folge von Einsen gefolgt von einer Folge
von Nullen. Daher gibt es nur 32 mgliche verschiedene Netzwerkmasken, nicht 232 . Statt die
Netzwerkmaske in Dezimalnotation auszuschreiben, gengt es deshalb, einfach die Anzahl der
Einsen in der Netzwerkmaske anzugeben. Diese Notation wird beim CIDR verwendet, indem die
Anzahl der fhrenden Einsen durch einen Schrgstrich von der IP-Adresse abgetrennt angegeben
wird. Einige Beispiele fr Netzwerkmasken sind in Tabelle 7.1 angegeben.
Aus der IP-Adresse des Systems kann man durch eine bitweise UND-Verknpfung mit der
Netzwerkmaske den sogenannten Netzwerkteil der IP-Adresse erhalten. Der brige Teil der IPAdresse wird auch Hostteil der Adresse genannt. Beim Netzwerkteil der Adresse handelt es sich
um die Netzadresse desjenigen Netzes, in dem sich das System bendet.
Betrachten wir hierzu ein Beispiel. Ist die IP-Adresse eines Systems 192.168.5.19/24, so ist
die Netzadresse 192.168.5.0/24. Maschinen, die direkt ber die Datenverbindungsschicht miteinander kommunizieren knnen, haben IP-Adressen mit gleichem Netzwerkteil, aber unterschiedlichen Hostteilen, sie haben also die gleiche Netzadresse. Das System schreibt in seine Routingtabelle, dass alle Rechner im Netz 192.168.5.0/24 direkt erreichbar sind. Soll nun von diesem
System ein IP-Paket an die IP-Adresse 192.168.5.74 verschickt werden, so wird durch bitweise
UND-Verknpfung berprft, ob dieses System im Netz 192.168.5.0/24 liegt. Dies geschieht,
indem die IP-Adresse 192.168.5.74 mit der /24er Maske UND-verknpft wird. Ergibt sich als
Netzwerkanteil 192.168.5.0, so hat das System die gleiche Netzwerkadresse und ist direkt ber
die Datenverbindungsschicht erreichbar, ansonsten nicht. Die UND-Verknpfung liefert in diesem Fall 192.168.5.0, so dass das Paket direkt ber die Datenverbindungsschicht an diese Adresse weitergeleitet wird. Soll ein IP-Paket an die Adresse 192.168.9.81 verschickt werden, so erhlt
man als Netzadresse 192.168.9.0, was nicht 192.168.5.0 entspricht. Der Rechner ist also nicht
direkt auf der Datenverbindungsschicht erreichbar und das IP-Paket wird ber die Datenverbindungsschicht an das Default-Gateway weitergeleitet. Das Default-Gateway einer Maschine liegt
immer im gleichen Netzwerkteil wie sie selbst, da es direkt ber die Datenverbindungsschicht
erreichbar sein muss.
In jedem Netz gibt es eine sogenannte Broadcast-Adresse. Werden Pakete an diese Adresse
verschickt, erhalten alle Stationen im entsprechenden Teilnetz das Paket und werten es aus. Die
Broadcast-Adresse eines Netzes erhlt man, indem man den Hostteil der Adresse mit Einsen
117
fllt. Die Broadcast-Adresse des Netzes 192.168.5.0/24 ist also beispielsweise 192.168.5.255.
Konventionsgem darf diese Kombination sowie ausschlielich Nullen im Hostteil, also im
Beispiel 192.168.5.0, nicht als IP-Adresse fr einen Rechner im Netz verwendet werden. Entsprechend knnten also im Beispielnetz 254 Rechner mit den IP-Adressen von 192.168.5.1 bis
192.168.5.254 betrieben werden.
Wenden wir uns nun Routern zu. Die Eintrge in Routern sind den oben skizzierten Eintrgen
in Routingtabellen sehr hnlich. Sie geben ebenfalls eine Netzadresse und die Netzwerkmaske zu
diesem Netz an und enthalten Informationen, wohin Pakete fr dieses Netz als nchstes geschickt
werden sollen, also ber welches Interface an welches nchste Ziel. Der Router arbeitet fr ein
Paket sukzessive die Eintrge in der Routingtabelle ab. Fr jeden Eintrag wird berprft, ob die
vorliegende IP-Zieladresse des Pakets im durch den Eintrag spezizierten Netz liegt. Falls ja,
wird das Paket wie in der Regel angegeben weitergeleitet, ansonsten wird die berprfung mit
dem nchsten Eintrag fortgesetzt.
Es gibt IP-Adressen und Adressbereiche, die spezielle Bedeutung besitzen und nicht als normale IP-Adresse oder normaler IP-Adressbereich im Internet verwendet werden knnen (siehe [RFC 3330]). Hierzu gehren auch die sogenannten privaten IP-Adressen [RFC 1918]. Dabei handelt es sich um die Netzwerkadressen 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. Sie
sind zur internen, privaten Verwendung in Netzwerken gedacht. Diese privaten Adressen knnen von Institutionen in ihren eigenen Netzen beliebig vergeben werden. Entsprechende Adressen aus diesen Bereichen sind daher alles andere als global eindeutig. Auerhalb solcher nichtffentlichen Netze drfen diese Adressen daher nicht auftreten. Ein Rechner mit einer privaten
Adresse kann nicht direkt mit dem Internet kommunizieren, da die private Adresse erst in eine
ffentliche Adresse umgewandelt werden muss, beispielsweise durch Network Address Translation (NAT). Diese Technologie werden wir in Abschnitt 9.2.1.5 nher betrachten. Wir werden
hier in Beispielen ausschlielich private IP-Adressen verwenden.
7.3.3.5 Automatische Konguration von Rechnern
Die zur Konguration eines Gerts in einem IP-Netzwerk notwendigen Informationen (IP-Adresse, Netzwerkmaske, Adresse des Default-Gateway), knnen nicht nur manuell konguriert werden, sondern auch automatisch bermittelt werden. Hierfr wird das Dynamic Host Conguration Protocol (DHCP) [RFC 2131] verwendet. Durch dieses Protokoll erhlt ein Rechner die
notwendigen Kongurationdaten von einem Server zugeteilt. Die Details dieses Protokolls knnen an dieser Stelle nicht dargestellt werden.
7.3.3.6 An der Schnittstelle von IP und Datenverbindungsschicht: Address Resolution
Protocol
Nachdem eine Station auf der IP-Schicht die IP-Adresse derjenigen Station bestimmt hat, an
welche ein IP-Paket als nchstes (weiter-)geleitet werden muss und ber welches Interface diese
Station erreichbar ist, kann das Paket der Datenverbindungsschicht zum Weitertransport bergeben werden. Whrend jedoch auf der IP-Schicht zur Adressierung IP-Adressen verwendet werden, nden auf der Datenverbindungsschicht andere Adresstypen Verwendung, in Ethernets und
WLANs die sogenannten MAC-Adressen. Daher ist es in solchen Fllen notwendig, die vorlie-
118
gende IP-Adresse in eine MAC-Adresse zu bersetzen. Diese Aufgabe bernimmt das Address
Resolution Protocol (ARP) [RFC 826]. Das ARP-Protokoll schickt eine entsprechende Anfrage
an alle Stationen im jeweiligen LAN (ARP-Request). Hierzu wird eine Broadcast-Nachricht verwendet, die alle Stationen im LAN empfangen. Diejenige Station, welcher die IP-Adresse gehrt,
antwortet und schickt ihre MAC-Adresse an die anfragende Station zurck (ARP-Response, in
der Literatur auch ARP-Reply genannt).
Somit kann das Paket nun weiterverschickt werden. Das Paar (IP-Adresse, MAC-Adresse)
wird auerdem in einem Cache gespeichert (ARP-Cache), damit bei zuknftigen Paketen an
diese Adresse keine erneute Anfrage mittels des ARP-Protokolls notwendig ist. Wie bei Cachingtechniken im Netzwerkbereich allgemein blich werden veraltete Adresspaare nach einer
festgelegten Inaktivittsphase (Timeout) wieder gelscht.
7.3.4 Transportschicht: TCP und UDP

7.3.4.1 TCP
Das Transmission Control Protocol (TCP) wurde in [RFC 793] speziziert. Es bietet zuverlssigen, verbindungsorientierten Transport zwischen zwei Endpunkten. TCP verwendet IP als Netzwerkprotokoll. Vor dem Senden von Daten wird durch einen Handshake eine Verbindung zwischen den beiden Endpunkten aufgebaut. Der Endpunkt, der den Verbindungsaufbau beginnt,
wird auch als Client bezeichnet, der andere Endpunkt als Server. Nach dem Verbindungsaufbau
knnen Daten in beide Richtungen bertragen werden und es gibt zumindest aus Sicht von TCP
keine Unterschiede mehr zwischen dem Client und dem Server. Die mittels TCP bertragenen
Dateneinheiten werden Segmente genannt. Da die einzelnen Segmente ber IP bertragen werden, ist es mglich, dass die Segmente beim Transport durch das Netzwerk verloren gehen oder
in der Reihenfolge durcheinanderkommen. TCP bringt die entsprechenden Segmente wieder in
die richtige Reihenfolge. Ebenso werden verlorengegangene Segmente vom TCP-Protokoll entdeckt und nochmals bertragen. Zu diesem Zweck besttigt der Empfnger von Daten deren
Empfang. Hat der Sender vom Empfnger nach einer gewissen Zeitspanne noch keine Besttigung erhalten, so verschickt er die Daten nochmals. Wenn die Datenbertragung beendet ist,
wird die Verbindung wieder abgebaut.
Das TCP-Protokoll verfgt ber Mechanismen, die eine berlastung des Empfngers oder des
Netzwerks vermeiden (Empfngerberlastkontrolle und Netzwerkberlastkontrolle). Ein Groteil des im Internet bertragenen Verkehrs wird ber das TCP-Protokoll abgewickelt, da die
meisten Anwendungen den von TCP zur Verfgung gestellten zuverlssigen bertragungsdienst
bentigen.
Zu einem Zeitpunkt knnen auf einem Rechner mehrere TCP-Verbindungen aktiv sein. Um
diese Verbindungen auseinanderhalten zu knnen, werden sogenannte Portnummern eingesetzt.
Der Server wartet auf einem von der Anwendung, die TCP nutzt, spezizierten Port auf eingehende Verbindungen. Der Client, der eine Verbindung zum Server aufbauen mchte, erhlt auf
seiner Seite ebenfalls eine Portnummer, die von Betriebssystem zugewiesen wird. Damit kann jede TCP-Verbindung anhand von TCP Source Port (auch synonym TCP-Quellport genannt), TCP
Destination Port (auch synonym TCP-Zielport genannt), IP-Quelladresse und IP-Zieladresse eindeutig identiziert werden. TCP-Segmente, die in die entgegengesetzte Richtung bertragen
Anwendungsprotokoll
SSH
SMTP
HTTP
POP
HTTPS
119
serverseitiger TCP-Port
22
25
80
110
443
Tabelle 7.2: Serverseitige TCP-Portnummern einiger Anwendungsprotokolle.
werden, haben TCP-Quellport, TCP-Zielport und natrlich IP-Quelladresse und IP-Zieladresse

entsprechend vertauscht. Abbildung 7.7 skizziert diese Zusammenhnge. Es gibt Festlegungen,
welche TCP-Portnummern serverseitig von bestimmten Anwendungsprotokollen verwendet werden. Tabelle 7.2 enthlt eine Auistung einiger Anwendungsprotokolle und ihrer blicherweise
verwendeten Portnummern. Manche Betriebssysteme, darunter Linux, erlauben die serverseitige
Verwendung von Portnummern im Bereich unter 1024, den sogenannten privileged Ports, aus
Sicherheitsgrnden nur fr den Systemadministrator
. Greift man ber das Web auf einen
Port eines Rechners mit einer privileged Portnummer zu, so kann man also davon ausgehen, dass
der die Anfragen aus dem Netz entgegennehmende Prozess durch eine Person mit Administratorrechten aufgesetzt wurde und nicht einfach von einem normalen Benutzer. Doch gerade Prozesse,
die mit dem Netzwerk agieren, sollten nicht mit Administratorrechten laufen. Daher sollten solche Programme nach dem Anbinden an den Port, dem sogenannten Binding, ihre Root-Rechte
wieder abgeben und mit der Berechtigung eines normalen Benutzers weiterlaufen.
Der Header des TCP-Protokolls ist in Abbildung 7.8 skizziert. Die wichtigsten Felder sollen
im Folgenden kurz vorgestellt werden. Source Port (2 Byte) und Destination Port (2 Byte) werden
wie erlutert zum Identizieren der TCP-Verbindungen verwendet. TCP ist ein verbindungsorientiertes, zuverlssiges Protokoll. Dies bedeutet aus Sicht der Anwendungen, die TCP verwenden, dass beim Empfnger genau das ankommt, was der Sender losgeschickt hatte, ohne Verluste,
Vertauschungen oder hnliches. Erreicht wird dies, indem TCP die Bytes im Datenstrom durchnummeriert. Begonnen wird mit einer Anfangssequenznummer (Initial Sequence Number), die
beim Verbindungsaufbau bestimmt wird. In jedem bertragenen Segment wird im Header des
Segments die entsprechende Nummer des ersten Daten-Bytes des Segments im Feld Sequence
Number angegeben. Der Empfnger besttigt den Erhalt des Segments beim Empfnger. Dies
geschieht ber das Feld Acknowledgement Number, in welchem der Empfnger die Nummer des
nchsten erwarteten Bytes im Datenstrom angibt. Um dies zu signalisieren, wird zustzlich das
ACK-Flag gesetzt. Die Besttigung muss nicht extra geschickt werden, sondern kann mit der
bertragung von Daten in die andere Richtung verbunden sein (sog. piggybacking). Falls der
Sender eines Segments innerhalb einer gewissen Zeitspanne vom Empfnger keine Besttigung
erhlt, schickt der Sender das Segment nochmals los.
Der Empfnger der Daten nutzt die Sequenznummern, um die Segmente in die richtige Reihenfolge zu bringen und festzustellen, ob Lcken zwischen den erhaltenen Segmenten bestehen.
Der Anwendung werden nur vollstndige Daten bergeben.
120

Server S
wartet an festem Port p auf
eingehende Verbindungen
Client A
Client B
IP-Quelladresse: A
IP-Zieladresse: S
TCP-Quellport: x
TCP-Zielport: p
IP-Quelladresse: B
IP-Zieladresse: S
TCP-Quellport: x
TCP-Zielport: p
IP-Quelladresse: S
IP-Zieladresse: A
TCP-Quellport: p
TCP-Zielport: x
IP-Quelladresse: S
IP-Zieladresse: B
TCP-Quellport: p
TCP-Zielport: x
IP-Quelladresse: B
IP-Zieladresse: S
TCP-Quellport: z
TCP-Zielport: p
Tupel (IP-Quelladresse, IP-Zieladresse, TCP-Quellport,TCP-Zielport)

bestimmt eindeutig den Informationsfluss und die TCP-Verbindung
IP-Quelladresse: S
IP-Zieladresse: B
TCP-Quellport: p
TCP-Zielport: z
Abbildung 7.7: Portnummern, Multiplexing und Verbindungen bei TCP.

Byte
Bit
Source Port
Data Offset
reserved
Checksum
Destination Port
Sequence Number
Acknowledgment Number
U A P R S F
Window
Urgent Pointer
Options (0 oder mehr)
Abbildung 7.8: Header eines TCP-Segments.
Da TCP auch optionale Header-Parameter hat, gibt es wie bei IP ein Feld, in dem die Lnge
des Headers in 4-Byte-Schritten angegeben ist (Data Offset, 4 Bit). Die Optionen vergrern den
Header jeweils um das Vielfache von 4 Byte. Die Flags (in der Literatur auch Control-Bits genannt) URG, ACK, PSH, RST, SYN und FIN dienen zur Signalisierung verschiedener Ereignisse
und Zustnde, darunter auch der Aufbau und der Abbau der TCP-Verbindung. Das Feld Window
(2 Byte) dient der Vermeidung einer berlastung des Empfngers. Hier wird angegeben, wieviele
Daten der Endpunkt noch verarbeiten kann.
Zeit
SYN SEQ=clien
t_a
121
sn
cli
server_asn ACK=
SYN, ACK SEQ=
ACK SEQ=clien
ent_asn+1
t_asn+1 ACK=ser
ver_asn+1
Abbildung 7.9: Aufbau einer TCP-Verbindung.
Wie gesagt arbeitet TCP verbindungsorientiert. Der Aufbau der Verbindung kann anhand der
Flags im TCP-Header, insbesondere des SYN-Flags, erkannt werden. Der Besttigungsmechanismus fr Datenbytes in den Segmenten schliet brigens auch das SYN und das zum Verbindungsabbau eingesetzte FIN-Flag mit ein, da das Setzen dieser Bits als ein (virtuelles) Byte
im Datenstrom gezhlt wird. Daher werden solche Segmente vom Empfnger besttigt und so
kann der Sender erkennen, ob das Segment mit einem entsprechend gesetzten Flag angekommen ist, auch wenn es keine Daten enthielt. Beim Aufbau der Verbindung whlen sowohl der
die Verbindung aufbauende Client als auch der Server eine Anfangssequenznummer (Initial Sequence Number), von der ausgehend die Bytes im Datenstrom durchnummeriert werden. Das
erste jeweils von den Stationen ausgesendete Segment enthlt diese Sequenznummer und das
SYN-Flag ist gesetzt. Client und Server whlen ihre Nummer unabhngig voneinander nach
bestimmten Kriterien. Der typische Ablauf beim Aufbau einer TCP-Verbindung, auch als ThreeWay-Handshake bekannt, ist in Abbildung 7.9 dargestellt:
Der Client beginnt den Verbindungsaufbau mit einem Segment, bei dem das SYN-Flag
gesetzt ist. Dieses Segment enthlt die Anfangssequenznummer des Clients.
Der Server antwortet mit einem Segment, bei dem SYN-Flag und ACK-Flag gesetzt sind.
Die in diesem Segment angegebene Sequenznummer ist die Anfangssequenznummer des
Servers. Zudem besttigt er den Erhalt des vorangegangenen Segments des Clients durch
das gesetzte ACK-Flag und die Angabe der Nummer des nchsten erwarteten Bytes im
Datenstrom im ACK-Feld. Dieses ist gerade der Wert der Anfangssequenznummer des
Clients plus eins, da das gesetzte SYN-Flag wie oben erlutert wie ein virtuelles Byte im
Datenstrom behandelt wird.
122
CLOSED
empf. SYN /
sende SYN ACK
Starten eines
TCP-Servers
Stoppen eines
TCP-Servers
Start eines
TCP-Client /
sende SYN
LISTEN
SYN RECD
FINWAIT-1
empf. SYN ACK /

sende ACK (fr SYN)
empf. ACK (fr SYN)
schliee Vbdg. /
sende FIN
empf. ACK (fr FIN)

FINWAIT-2
ESTABLISHEDempf. FIN /
sende ACK (fr FIN)
CLOSE WAIT
empf. FIN /
sende ACK (fr FIN)
CLOSING
empf. FIN /
sende ACK (fr FIN)
SYN SENT
schliee Vbdg. /
sende FIN
LAST-ACK
empf. ACK
(fr FIN)
empf. ACK (fr FIN)

TIME WAIT
CLOSED
Abbildung 7.10: TCP-Zustandsdiagramm.
Der Client besttigt den Erhalt des Segments vom Server durch Senden eines Segments
mit gesetztem ACK-Flag und die Angabe der Nummer des nchsten erwarteten Bytes im
Datenstrom im ACK-Feld. Dieses ist gerade der Wert der Anfangssequenznummer des
Servers plus eins, da auch hier das gesetzte SYN-Flag wie ein virtuelles Byte im Datenstrom zhlt.
Damit ist der Three-Way-Handshake abgeschlossen und die Verbindung in beide Richtungen
aktiv. Nach Abschluss dieses Handshakes gibt es keine Unterschiede mehr zwischen Client und
Server in Bezug auf die TCP-Verbindung, beide knnen senden und empfangen. Bei obigen Ausfhrungen wurde unterstellt, dass whrend des Verbindungsaufbaus noch keine Daten bertragen
werden. Die meisten Implementierungen von TCP verhalten sich tatschlich so, obwohl das Protokoll die bertragung von Daten whrend des Aufbaus der Verbindung ausdrcklich erlaubt.
Solche Daten werden verworfen, wenn der Verbindungsaufbau nicht erfolgreich abgeschlossen
wird.
Jede Seite kann die TCP-Verbindung auch wieder beenden. Hierzu setzt die entsprechende
Seite das FIN-Flag, das durch den Kommunikationspartner ja als virtuelles Byte im Datenstrom
gezhlt wird und per ACK besttigt wird. In die andere Richtung knnen dann noch weiterhin
Daten bertragen werden, bis die Verbindung analog beendet wird.
Der Auf- und Abbau einer TCP-Verbindung kann teilweise auch etwas anders erfolgen, beispielsweise, indem gleichzeitig mit der Besttigung eines FIN-Flags in der einen Richtung ein eigenes FIN-Flag bertragen wird. Die TCP-Spezikation beinhaltet ein Zustandsdiagramm, welches die mglichen bergnge darstellt. Abbildung 7.10 zeigt dieses Diagramm mit den wichtigsten Zustandsbergngen. Client und Server beginnen jeweils im Zustand CLOSED. Ein Client, der einen Server kontaktiert, sendet ein SYN und wechselt in den Zustand SYN SENT. Erhlt
er vom Server ein SYN ACK, so sendet er ein ACK und wechselt in den Zustand ESTABLISHED. Dieser Zustand beschreibt eine aktive TCP-Verbindung. Wenn sich ein Server an einen
123
Byte
Bit
Source Port
Length
Destination Port
Checksum
Abbildung 7.11: UDP-Header.
Port bindet, wechselt er in den Zustand LISTEN, in dem er auf eingehende Verbindungen wartet.
Sobald ein SYN eines Client eingeht, sendet der Server ein SYN ACK zurck und wechselt in
den Zustand SYN RECD. Erhlt er das ACK des Clients, so gelangt der Server ebenfalls in den
Zustand ESTABLISHED.
7.3.4.2 User Datagram Protocol (UDP)
TCP bietet zwar zuverlssigen Service, aber das Protokoll ist verhltnismig aufwendig. Es
erfordert beispielsweise einen Verbindungsaufbau, und vom Abschicken eines Bytes auf Applikationsebene beim Sender bis zum Empfang dieses Bytes auf der Applikationsebene beim
Empfnger kann aufgrund der Protokolleigenschaften von TCP einige Zeit verstreichen.
Daher ist es fr einige Anwendungen, insbesondere solche, bei denen nur wenig Daten bertragen werden mssen (die in ein Segment passen) oder bei denen der gelegentliche Verlust von
Segmenten keine Rolle spielt, aber die Verzgerung bei der bertragung kritisch ist (wie Realzeitanwendungen), angebracht oder sogar notwendig, ein anderes Transportprotokoll zu verwenden.
Hierzu wird im Internet UDP gem [RFC 768] verwendet. UDP arbeitet ebenfalls ber IP
und bietet einen verbindungslosen, nicht-zuverlssigen Dienst. Die Anwendung bergibt UDP
ein sogenanntes Datagramm, das durch UDP sofort und ohne weitere Verzgerung losgesendet
wird. Die maximale Lnge eines Datagramms betrgt 64KB. Will eine Anwendung mehr Daten
verschicken, muss sie die Daten selbst in mehrere Datagramme aufteilen. Datagramme, die beim
Transport verloren gehen, werden nicht nochmals bertragen.
Der Header des UDP-Protokolls ist in Abbildung 7.11 skizziert. Wie man sehen kann, ist der
UDP-Header denkbar einfach aufgebaut und besteht nur aus vier Feldern. Source Port (synonym
Quellport) und Destination Port (synonym Zielport) werden analog zu TCP verwendet, ebenso
das Feld Checksum, welches eine Prfsumme beinhaltet. Das Feld Length enthlt die Lnge des
bertragenen Datagramms.
7.3.4.3 Vergleich
Tabelle 7.3 enthlt nochmals die wichtigsten Merkmale von TCP und UDP im berblick. Unabhngig davon, ob TCP oder UDP als Transportprotokoll verwendet werden und ob Informationen
verbindungsorientiert oder verbindungslos bertragen werden, beschrnkt sich die Kommunikation zwischen zwei Applikationen selten auf ein einziges Paket, sondern besteht aus mehreren Paketen, die logisch zusammengehren. Unter dem Begriff Informationsuss (auch Flow genannt)
fasst man daher alle Pakete zusammen, bei denen IP-Quelladresse, IP-Zieladresse, Transportpro-
124
Merkmal
TCP
UDP
IP-Protokollnummer
Verbindung
6
Verbindungsorientiert. Aufbau einer Verbindung vor
der Datenbertragung durch
sog. Three-Way-Handshake,
Abbau der Verbindung nach
Beendigung.
TCP bertrgt verlorengegangene Segmente nochmals und bringt die Daten
in die richtige Reihenfolge,
bevor sie dem Empfnger
bergeben werden. Was
reingeht, kommt auch raus.
Aus Sicht von Sender/Empfnger steht ein
Bytestrom zur Verfgung.
Sender kann durch den
Strom beliebige Datenmengen verschicken, evtl.
Segmentierung
erfolgt
durch das TCP-Protokoll.
17
Verbindungslos.
UDPDatagramme knnen ohne
Verbindungsaufbau einfach
abgeschickt werden.
Zuverlssigkeit
Schnittstelle zur Anwendung
Sende-/Empfangsverhalten
Von der Anwendung an

TCP bergebene Daten
mssen durch das TCPProtokoll beim Sender nicht
sofort zum Empfnger
geschickt werden. Wenn
TCP-Segmente beim Empfnger ankommen, mssen
sie nicht sofort an die
empfangende Anwendung
weitergegeben werden.
UDP-Datagramme werden
bei Verlust durch UDP
nicht nochmals bertragen,
Datagramme werden nicht
in die richtige Reihenfolge
gebracht
Anwendung muss UDP
jeweils ein Datagramm
zum
Senden
bergeben. Maximale Kapazitt
festgelegt
durch
max.
UDP-Datagrammgre.
Aufteilung grerer Datenmengen in mehrere
Datagramme muss durch
die Anwendung erfolgen.
UDP sendet bergebenes
Datagramm direkt ab und
stellt empfangenen Datagramme
empfngerseitig
sofort zur Verfgung.
Tabelle 7.3: TCP und UDP im Vergleich.
125
tokoll, Quellport des Transportprotokolls und Zielport des Transportprotokolls bereinstimmen.

Ein Informationsuss ist also unidirektional und eine TCP-Verbindung besteht aus zwei Informationsssen.
7.3.5 Applikationsschicht
7.3.5.1 Ein kleiner Spaziergang durch den Zoo der Applikationsprotokolle
Aus Sicht eines Benutzers betrachtet dienen alle oben genannten Protokolle letztendlich dazu,
eine Anwendung ber das Netzwerk zu ermglichen. Anwendungen bestehen aus vielen verschiedenen Komponenten. Aus unserer Sicht ist das in der Anwendung verwendete Protokoll
entscheidend. Die Protokolle von Anwendungen im Internet verwenden je nach ihren Anforderungen und Bedrfnissen entweder TCP oder UDP als Transportprotokoll. Um die (zumindest
serverseitig) notwendige eindeutige Zuordnung zwischen Anwendungen und Portnummern erreichen zu knnen, erhalten Applikationsprotokolle serverseitig eine spezielle TCP- oder UDPPortnummer zugeteilt.
Einige Beispiele fr Applikationsprotokolle sind:
Hypertext Transfer Protocol (HTTP): Protokoll fr Hypermediasysteme [RFC 2616]. Es
ist hauptschlich bekannt als Protokoll fr das World Wide Web (WWW), bietet aber eine ganze Reihe weiterer Mglichkeiten, die seine Anwendung fr viele anderen Zwecke
ermglichen.
Simple Mail Transfer Protocol (SMTP): Protokoll zum Transport von Emails durch das
Internet [RFC 2821].
Post Ofce Protocol (POP) und (IMAP): Protokolle zum Zugriff auf Emails durch einen
Client auf einem Server [RFC 1939] [RFC 3501].
Wir werden uns mit diesen und anderen Anwendungsprotokollen und den zugehrigen Anwendungen noch ausfhrlicher beschftigen. Die entsprechenden Protokolldetails werden wir
spter ebenfalls kennenlernen.
7.3.5.2 Domain Name Service (DNS)
Nun wollen wir uns kurz mit einer Anwendung beschftigen, welche fr die uns bekannte Funktionsweise des Internet eine wichtige Rolle spielt, nmlich mit dem Domain Name Service (DNS).
DNS ist in den Dokumenten [RFC 1034] und [RFC 1035] ausfhrlich beschrieben und speziziert. Es gibt eine ganze Reihe von Erweiterungen und Ergnzungen des DNS-Systems. Wir
wollen uns hier auf eine grobe Beschreibung der Grundfunktion von DNS beschrnken.
Wenn ein Rechner R1 im Internet einen anderen Rechner R2 im Internet kontaktieren mchte, so bentigt R1 hierzu die IP-Adresse des Rechners R2, denn die Adresse wird bentigt, um
die Kommunikation auf der Netzwerkschicht zu ermglichen. Will also ein Benutzer auf einem
Client die Webseite des Teubner-Verlags erreichen, so msste der Benutzer die IP-Adresse des
Webservers, nmlich
kennen (oder gespeichert haben). IP-Adressen sind natrlich nicht unbedingt benutzerfreundlich. Daher wurde via DNS eine andere Benennung der
126
Ressourcen im Netz ermglicht, nmlich ber die sogenannten Domainnamen. Ein Domainname ist ber das DNS-System mit einer bestimmten Ressource im Netz assoziiert, beispielsweise
der IP-Adresse eines speziellen Rechners. In diesem Fall bezeichnet man den Namen auch als
Hostnamen. Will man den Webserver des Teubner-Verlags erreichen, so kann man den Domainnamen
verwenden, was sich die meisten Menschen (Ausnahmen besttigen
die Regel) sicher leichter merken knnen als die entsprechende IP-Adresse des Webservers.
DNS hat also die Aufgabe, Domainnamen und Hostnamen in IP-Adressen zu bersetzen. Man
bezeichnet dies auch als das Ausen des Namens in eine Adresse. Somit kann man DNS als eine
Datenbank sehen, die genau dies bewerkstelligt. Dabei ist diese Datenbank aber nicht zentral
organisiert, sondern ber das gesamte Internet verteilt.
Die Domainnamen sind in Form eines Baumes strukturiert. Die Knoten des Baums sind benannt und werden im entsprechenden Namen einer Domain vom Blatt ausgehend bis zur Wurzel benannt, jeweils abgegrenzt mit einem Punkt als Trennsymbol. Jeder Knoten im Baum entspricht einer Domain, und Kinder dieses Knotens werden auch als Subdomains bezeichnet. So
ist
eine Subdomain von
. Der von der Wurzel ausgehend oberste
Knoten wird auch als Top-Level Domain bezeichnet. So hat die Adresse
die
Top-Level Domain .
Die Struktur der verteilten Datenbank ergibt sich aus der Baumstruktur des DNS-Namensraums. Fr jeden Knoten gibt einen sogenannten Name Server, der Domainnamen aus dem Namensraum seiner Kinder entweder direkt ausen kann oder aber wei, welcher Rechner der
Name Server fr den betreffenden Kindknoten ist. Es gibt mehrere DNS Root-Server, welche
die Name Server aller Top-Level Domains kennen (und meistens noch etwas mehr), und so kann
man sich vom Root-Server ausgehend durch den Baum bewegen, bis man einen entsprechenden
Domain-Namen ausen kann. Die Eintrge in der DNS Datenbank werden Resource Records
genannt und knnen neben der direkten bersetzung eines Hostnamens in eine IP-Adresse auch
andere Typen von Eintrgen untersttzen, etwa Aliase, also alternative Namen fr Rechner.
7.4 Netzwerke in der Praxis

7.4.1 Referenznetzwerk
Wir wollen nun die eher theoretische Darstellung der fundamentalsten Protokolle im Internet
praktisch unterfttern und uns den tatschlichen Weg eines Pakets durch ein Netzwerk anschauen. Hierzu betrachten wir ein Referenznetzwerk, das wir im Verlauf des Buchs erweitern und
immer wieder zur praktischen Illustration verwenden werden. Unser Ziel ist dabei nicht, smtliche eben skizzierten Protokolle in ihrer Gesamtheit zu betrachten, sondern exemplarisch einige
Protokolle zu verfolgen und das Konzept des Snifng, also das Beobachten von Paketen in Netzwerken, praktisch kennenzulernen und auszuprobieren.
Das im nun folgenden Experiment verwendete Netzwerk ist in Abbildung 7.12 dargestellt. Es
besteht aus drei Teilnetzen, nmlich 10.2.4.0/24, 172.16.2.0/24 und 192.168.1.0/24. Die Netze 10.2.4.0/24 und 192.168.1.0/24 sind exemplarisch fr Netze von Institutionen. Das Netz
172.16.2.0 stellt ein ffentliches Verbindungsnetz dar, ber das die Rechner in den Institutionsnetzwerken miteinander kommunizieren knnen.
127
10.2.4.37
172.16.2.5
10.2.4.1
172.16.2.0/24
(ffentliches Verbindungsnetz)
10.2.4.0/24
(Institutionsnetz)
172.16.2.4
Router
192.168.1.5
192.168.1.0/24
(Institutionsnetz)
192.168.1.100
Abbildung 7.12: Referenznetzwerk.
Die Institutionsnetzwerke sind jeweils ber einen Router mit dem ffentlichen Netz verbunden. Die Router verfgen ber zwei Interfaces, von denen eines mit dem Institutionsnetz und
das andere mit dem ffentlichen Netz verbunden ist. Jedes Interface hat dabei seine eigene IPAdresse. Unsere sehr einfachen Router haben daher zwei IP-Adressen, eine aus dem Institutionsnetz und eine aus dem ffentlichen Netz. Echte Router knnen ber eine wesentlich grere
Zahl von Interfaces verfgen. Der Router, der das Netz 192.168.1.0/24 mit dem ffentlichen
Netz 172.16.2.0/24 verbindet, hat auf der Institutionsseite die IP-Adresse 192.168.1.5 und auf
der ffentlichen 172.16.2.4. Analog hat der andere Router, der das ffentliche Netz mit dem
Institutionsnetz 10.2.4.0/24 verbindet, die IP-Adressen 172.16.2.5 und 10.2.4.1. Als Netzwerktechnologie auf der Datenverbindungsschicht kommt in allen Netzen Ethernet zum Einsatz.
Im 192.168.1.0er Netz gibt es noch einen normalen Rechner mit nur einem Interface, der die
IP-Adresse 192.168.1.100 hat, ebenso im anderen Institutionsnetz. Diese Maschine hat die IPAdresse 10.2.4.37.
Somit haben wir also ein sehr einfaches Szenario mit nur vier Rechnern. Was wir beobachten
wollen, ist der Ablauf einer TCP-Verbindung zwischen den beiden normalen Rechnern in den
Institutsnetzen.
7.4.2 Konguration der Rechner und Router

Wenden wir uns kurz der Konguration der einzelnen Maschinen zu. Wir haben uns entschlossen, auf allen Rechnern inklusive den Routern das Betriebssystem Linux einzusetzen. Bei vielen
anderen Betriebssystemen wre es nicht ohne weiteres mglich, sie auch auf einem Router zu
verwenden. Unsere Router sind ganz normale Rechner, die allerdings ber zwei Interfaces ver-
128
fgen. Fr ein Testnetzwerk ist dieses Vorgehen sinnvoll. In normalen Netzen werden als Router
hochspezialisierte Gerte mit spezieller Software eingesetzt, die ganz gezielt fr die Funktionen
eines Routers ausgelegt und optimiert sind.
Wir verwenden als Betriebssystem die Linux-Distribution OpenSuse [openSUSE-Web], werden jedoch die Konguration ausschlielich ber shellbasierte Verfahren und Befehle durchfhren, die dem Linux-Standard entsprechen und auch auf jeder anderen Linux-Distribution funktionieren sollten. Wir werden alle Experimente mit Administratorberechtigungen, also als
durchfhren. Mit diesem Vorgehen wollen wir uns Probleme vom Hals halten, die sonst durch das
Betriebssystem aufgrund fehlender Administratorberechtigungen auftreten knnten, beispielsweise bei der Verwendung von privileged Ports und beim Mithren von Netzwerkverkehr. Wie
Sie den vergangenen Kapiteln entnehmen konnten, ist dieses Vorgehen aus der Sicherheitsperspektive betrachtet natrlich fragwrdig. Da es uns jedoch nun bei den praktischen Beispielen
im Schwerpunkt um die Sicherheit des Netzwerks und nicht so sehr die Sicherheit der beteiligten Rechner geht, erscheint dieses Vorgehen didaktisch gerade noch vertretbar (zumindest dann,
wenn man noch diese Bemerkung dazusetzt).
Beginnen wir mit dem Aufbau des Netzwerks. Wir verbinden die Rechner innerhalb der jeweiligen Teilnetze, indem wir die entsprechenden Ethernet-Interfaces der Maschinen mit einem
Switch verbinden. Es kommt also fr jedes der drei Teilnetze ein eigener Switch zum Einsatz.
Jeder Rechner in den Teilnetzen ist mit dem entsprechenden Switch ber ein Ethernet-Kabel verbunden. Die Router verfgen ber zwei Ethernet-Interfaces, von denen jeweils eines mit dem
Switch des Teilnetzes und das andere mit dem Switch des ffentlichen Netzes verbunden ist.
Nun mssen wir die Ethernet-Interfaces noch entsprechend kongurieren. Beginnen wir mit
der Konguration der Client-Rechner und betrachten exemplarisch die Konguration des Rechners mit der IP-Adresse 192.168.1.100. Wir sind als
auf dem Rechner eingeloggt und beginnen nun mit der Konguration des Interfaces ber die Shell. Hierzu verwenden wir den Befehl
.
Ein auerordentlich hilfreiches Tool unter Linux sind die Man-Pages. Fr die meisten verfgbaren Befehle und Programme erhlt man ber die Man-Pages eine ausfhrliche Beschreibung,
was der Befehl genau bewirkt, welche Befehlssyntax zum Einsatz kommt und welche Optionen
es gibt. Die Man-Pages zu einem Kommando mit dem Namen
werden aufgerufen, indem man
auf der Kommandozeile eingibt. Mit
erhalten wir also
eine detaillierte bersicht, wie
eingesetzt werden kann. Wir werden uns im Folgenden darauf beschrnken, darzustellen, wie dieses und die anderen verwendeten Kommandos im
konkret betrachteten Fall eingesetzt werden. Dabei werden wir auch einige Optionen erlutern.
Unser Ziel besteht jedoch nicht darin, dem Leser die Kommandos nahezubringen, sondern darzustellen, was im System mit diesen Befehlen bewirkt wird. Sie sollten sich also selbst mittels
der Man-Pages mit den Befehlen beschftigen und vielleicht das eine oder andere einfach einmal
selbst ausprobieren.
Wir wollen dem Ethernet-Interface des Rechners nun die IP-Adresse 192.168.1.100 zuweisen.
Unter Linux erhlt jedes Interface einen Namen. Fr Ethernet-Interfaces ist der Name charakteristischerweise von der Form
,
,
und so weiter. Mit dem Befehl
erhalten Sie eine bersicht ber alle aktiven Interfaces auf Ihrem Rechner. In unserem Fall hat
das Ethernet-Interface den Namen
. Mit dem Befehl
Abbildung 7.13: Konguration des Ethernet-Interface mittels
129
unter Linux.
weisen wir dem Interface

die IP-Adresse 192.168.1.100 zu. Auerdem wird mit
die Netzwerkmaske fr das Netz 192.168.1.0/24 angegeben. Mit anderen Worten geben wir also bekannt, dass alle Rechner mit IP-Adressen im Bereich von 192.168.1.1 bis
192.168.1.254 direkt ber
erreichbar sind. Indem wir nochmals
, aber ohne Parameter, aufrufen, knnen wir uns die erfolgte Konguration des Interfaces betrachten.
In Abbildung 7.13 ist dargestellt, welche Ausgabe wir in unserem Fall erhalten. Die Ausgabe des Befehls listet alle aktiven Interfaces des Rechners auf und zeigt Details fr jedes Interface. Wir sehen, dass unser Rechner zwei aktive Interfaces besitzt, nmlich zum einen das
von uns kongurierte Interface
sowie ein Interface mit dem Namen . Dieses ist das
Loopback-Interface. Dabei handelt es sich um keine echte Schnittstelle, sondern um eine virtuelle Schnittstelle, die ausschlielich zur internen Kommunikation von Anwendungen auf dem
Rechner selbst ber TCP/IP dient, also nicht ber ein richtiges Netzwerk luft. Dieses Interface hat die IP-Adresse 127.0.0.1. Der gesamte Adressbereich 127.0.0.0/8 ist fr diesen Zweck
reserviert (siehe [RFC 3330]).
Betrachten wir die Details, welche uns
ber die Schnittstelle
geliefert hat.
In der ersten Zeile ist angegeben, dass es sich um ein Ethernet-Interface mit der MAC-Adresse
00:0E:0C:C5:F6:7B handelt. In der zweiten Zeile sind die Details der IP-Konguration angegeben. Zuerst die IP-Adresse, dann die dem Interface zugehrige Broadcast-Adresse und die
Netzwerkmaske. Es schlieen sich einige Informationen und Statistiken ber das Interface an,
auf die wir hier nicht nher eingehen wollen.
Um Rechner mit Adressen auerhalb unseres eigenen Teilnetzes zu erreichen, mssen die entsprechenden Pakete zunchst an den im Teilnetz bendlichen Router geschickt werden. In unserem Fall ist dies der Rechner mit der IP-Adresse 192.168.1.5 (den wir gleich noch kongurieren
werden). Ausnahmslos alle Pakete, die auerhalb unseres eigenen Teilnetzes 192.168.1.0/24 lie-
130
Abbildung 7.14: Routingtabelle des Clients 192.168.1.100.
gen, werden ber diesen Rechner verschickt. Dies mssen wir in die Routingtabelle des Rechners
eintragen. Die Routingtabelle wird unter Linux mit dem Befehl
verwaltet.
Mit dem Kommando
erstellen wir in der Tabelle einen Eintrag, der besagt, dass alle Pakete, fr die in der Tabelle sonst kein passender Eintrag gefunden wird, an die IP-Adresse 192.168.1.5, nmlich das
Default-Gateway, weitergeleitet werden sollen. Da wir keine Ausnahmen haben, ist damit die
Routing-Konguration und auch die Konguration des Rechners insgesamt abgeschlossen. Mit
dem Befehl
knnen wir uns die entstandene Routing-Tabelle anschauen.
Diese ist in Abbildung 7.14 gezeigt. Die Eintrge der Tabelle sind zeilenweise aufgelistet,
wobei uns nur die Eintrge unter Destination, Gateway, Genmask und Iface interessieren. Beginnend mit dem obersten Eintrag wird geprft, ob die IP-Zieladresse bitweise UND-verknpft
mit dem Eintrag unter Genmask gleich zu dem Eintrag beim Feld Destination ist. Falls ja, wird
das Paket ber das unter Iface angegebene Interface an die unter Gateway gelistete nchste
Station weitergeleitet (sofern dort der Eintrag 0.0.0.0 steht, wird das Paket ber das Interface
direkt an die IP-Zieladresse geschickt). Falls nein, wird mit dem nchsten Eintrag in der Tabelle
fortgefahren. Unsere Tabelle enthlt drei Eintrge. Der erste Eintrag gibt an, dass alle Pakete,
die fr das Netz 192.168.1.0/24 bestimmt sind, direkt ber das Interface
bertragen werden knnen. Dieser Eintrag ist durch unseren
-Befehl in die Routingtabelle gelangt.
Es folgt ein Eintrag fr das Loopback-Interface, der angibt, dass alle Pakete, die an IP-Adressen,
die mit 127 beginnen, gerichtet sind, ber das Loopback-Interface abgewickelt werden. Danach
folgt unser gerade erzeugter Eintrag fr das Default-Gateway. Alle Pakete (Genmask 0.0.0.0
unabhngig von der IP-Zieladresse des Pakets ist das Ergebnis der UND-Verknpfung mit 0.0.0.0
0.0.0.0, insofern trifft diese Regel auf alle Pakete zu), die durch die vorangegangenen Eintrge
nicht betroffen waren, werden ber
an das Gateway 192.168.1.5 geschickt.
131
Abbildung 7.15: Routingtabelle des Routers mit den IP-Adressen 192.168.1.5 und 172.16.2.4.
Bei der Konguration des Routers knnen wir zunchst sehr hnlich vorgehen. Der Router hat
zwei Ethernet-Interfaces
und
.
ist mit dem Switch fr das Netz 172.16.2.0/24
verbunden und soll die IP-Adresse 172.16.2.4 erhalten, whrend
sich im 192.168.1.0/24er
Netz bendet und die Adresse 192.168.1.5 bekommt. Entsprechend kongurieren wir die Interfaces mit folgenden Befehlen:
Nun mssen wir die Eintrge in der Routing-Tabelle vornehmen. Was wir erreichen wollen ist,
dass Pakete fr das Netz 10.2.4.0/24 ber das ffentliche Netz 172.16.2.0/24 an die IP-Adresse
172.16.2.5 geschickt werden. Diese Adresse ist die IP-Adresse des anderen Routers im ffentlichen Netz. Wir erreichen dies mit dem Befehl
Analog knnten wir jetzt weitere Eintrge fr andere Netze vornehmen und auch zustzlich
ein Default-Gateway angeben. Die resultierende Routing-Tabelle, die wir uns wiederum mit dem
Befehl
anzeigen lassen, ist in Abbildung 7.15 dargestellt und enthlt keine berraschung. Unser Kommando hat die erste Zeile in der Routingtabelle erzeugt. Die folgenden Zeilen
sind durch die
-Befehle in die Routing-Tabelle gelangt.
Damit ist die Konguration des Routers fast abgeschlossen. Wir mssen dem Rechner noch
mitteilen, dass er als Router fungieren und auch Pakete fremder Rechner annehmen und gem
der Routingtabelle weiterleiten soll. Dies geschieht, indem in der Datei
eine
gesetzt wird. Das entsprechende Kommando lautet
Damit ist auch die Konguration des Routers abgeschlossen. Rechner und Router im anderen
Netz knnen vllig analog konguriert werden. Damit sind unsere Vorbereitungen abgeschlossen.
132
Wir knnen die Verbindung durch Verwendung des

-Befehls, der auf ICMP Echo Request/Responses basiert, testen. Von Rechner 192.168.1.100 aus rufen wir den Befehl
auf. Wenn alles funktioniert, sollten Antworten der Form
kommen (siehe Abschnitt 7.3.3.3 und Abschnitt 11.3.2.1).
7.4.3 Unser Test

Wir werden nun folgenden Test durchfhren: Auf Rechner 10.2.4.37 soll auf TCP Port 80 ein
Prozess auf eingehende TCP-Verbindungen warten. Der Prozess ignoriert ber die TCP-Verbindung eingehende Daten und schickt dem anfragenden Rechner Informationen ber die TCP-Verbindung zurck, speziell Quell- und Zielport sowie IP-Quell- und IP-Zieladresse.
Ein entsprechendes Programm, das diese Funktion erfllt, ist in Java schnell selbst geschrieben. Es knnte etwa wie folgt aussehen:
133
Applikationen kommunizieren ber sogenannte Sockets mit der Transportschicht. Auf die
wichtigsten Programmzeilen in Bezug auf den Aufbau der TCP-Verbindung wollen wir kurz
eingehen. Genaue Details, wie man Netzwerkanwendungen mit Sockets in Java implementiert,
nden sich beispielweise in [HMHG07]. Durch
bindet sich der Prozess an Port 80 und wartet dort auf eingehende Verbindungen. Durch
wird blockierend auf eine eingehende Verbindung gewartet. Sobald diese erfolgt, ist an den zurckgelieferten Socket die Verbindung gebunden. Der Eingabestrom der TCP-Verbindung wird
eingelesen und ignoriert, dann werden in den Ausgabestrom die Daten ber die TCP-Verbindung
an den Client zurckbermittelt. Durch
wird die TCP-Verbindung geschlossen.

Dieses Programm wird auf Rechner 10.2.4.37 in Java Bytecode bersetzt und anschlieend
gestartet. Nun versuchen wir, von Rechner 192.168.1.100 aus auf diesen Dienst zuzugreifen.
Wir verwenden hierzu einen normalen Webbrowser, in unserem Fall Firefox [Moz-Web], und
geben als Ziel 10.2.4.37 an. Der Browser baut dann automatisch zum HTTP-Standardport 80 eine TCP-Verbindung auf und stellt eine HTTP-Anfrage. Diese Anfrage wird von unserem kleinen
Programm ignoriert und Text zurckgeschickt. Der Browser erkennt dies und zeigt den bersendeten Text an. Das Resultat der Anfrage ist in Abbildung 7.16 gezeigt.
Wie man sehen kann, wurde die Anfrage von 192.168.1.100 Port 34765 gestartet und war an
10.2.4.37 Port 80 gerichtet.
134
Abbildung 7.16: Anfrage von 192.168.1.100 an 10.2.4.37.
7.4.4 Sniffer und Protokollanalysierer

Ein Programm, das es ermglicht, die an einem Netzwerkinterface eines Rechners auftretenden
Pakete mitzulesen, zu analysieren und darzustellen, wird als Packet Sniffer bezeichnet. Es gibt eine ganze Reihe solcher Programme. Die bekanntesten Sniffer sind tcpdump, Ethereal [Eth-Web]
und dessen Weiterentwicklung Wireshark [Wir-Web]. Es gibt sie fr verschiedene Betriebssysteme. Wir werden in diesem Buch hauptschlich Ethereal verwenden. Ethereal bietet neben dem
Mitlesen der Pakete sehr umfangreiche Analysefunktionen, auf die wir in spteren Kapiteln noch
zu sprechen kommen werden.
Wir wiederholen den Test und protokollieren die Verbindung zwischen den Maschinen auf
dem Rechner 192.168.1.100 per Ethereal mit. Abbildung 7.17 zeigt die dabei aufgenommenen
Pakete der TCP-Verbindung.
Wie man sehen kann, protokolliert Ethereal nicht nur die Pakete mit, sondern analysiert und
interpretiert auch die Protokollinformationen der Pakete. Beispielsweise werden die TCP-Flags
in Klartext bersetzt und angezeigt. Ethereal erlaubt auch eine Abspeicherung der Pakete fr eine
sptere Analyse. Im oberen Teil des Fensters sind alle whrend der Verbindung ausgetauschten
Pakete im berblick zu sehen. Die ersten drei ausgetauschten Pakete stellen den TCP-Handshake
dar, wie wir ihn bereits kennengelernt haben. Danach folgt die HTTP-Anfrage des Browsers und
die Antwort durch unser Serverprogramm. Anschlieend wird die Verbindung geschlossen.
Im mittleren Teil des Fensters ist das erste Paket mit Daten von 192.168.1.100 zu 10.2.4.37 zu
sehen. Neben genauen Details ber die im Paket enthaltene TCP-Protokollinformation ist sind
auch die bermittelten HTTP-Nutzdaten interpretiert und im Klartext zu sehen. Der untere Teil
des Fensters zeigt die tatschlich aufgefangenen Bytes des Pakets in Hexadezimaldarstellung.
Durch die Anwendung eines Sniffers wie Ethereal knnen wir uns also einen umfassenden
detaillierten berblick verschaffen, welche Pakete ber das Netzwerk ausgetauscht wurden und
deren Inhalt betrachten. Solche Tools sind daher zur Fehlersuche in Netzen ausgesprochen hilfreich.
7.5 Zusammenfassung
Abbildung 7.17: Ethereal-Analyse der TCP-Verbindung zwischen 192.168.1.100 und 10.2.4.37.
7.5 Zusammenfassung
In diesem Kapitel wurden kurz die wichtigsten Eigenschaften von Netzwerken und
den dort verwendeten Protokollen skizziert.
Netzwerke sind konzeptionell in Schichten aufgeteilt, die eine relativ leichtere Handhabung der beachtlichen Komplexitt eines Netzes ermglichen. Wir betrachten
fnf Schichten, nmlich physikalische Schicht, Datenverbindungsschicht, Netzwerkschicht, Transportschicht und Anwendungsschicht.
Die wichtigsten Technologien auf der Datenverbindungsschicht in lokalen Netzen sind
Ethernet (IEEE 802.3) und Wireless LAN (IEEE 802.11). Auf der Netzwerkschicht
dominiert gegenwrtig das Internet Protocol (IP). Auf Basis von IP operieren zwei
Transportprotokolle, nmlich das Transmission Control Protocol (TCP) und das User
Datagram Protocol (UDP). TCP ist verbindungsorientiert und bietet zuverlssigen Service. UDP ist datagrammbasiert und unzuverlssig.
135
136
7.6 bungsaufgaben
Aufgabe 7.1:
Erlutern Sie das vorgestellte Schichten-Referenzmodell fr Netzwerke. Erklren Sie die Aufgaben der einzelnen Schichten und deren Informationsaustausch. Geben Sie fr jede Schicht ein
Protokoll an, das auf dieser Schicht arbeitet.
Aufgabe 7.2:
Beschreiben Sie das IP-Protokoll. Gehen Sie dabei auch auf die Frage ein, wie Routing unter IP
durchgefhrt wird.
Aufgabe 7.3:
Beschreiben und vergleichen Sie die zwei im Internet hauptschlich verwendeten Transportprotokolle.

Aufgabe 7.4:
Machen Sie einige eigene praktische Tests analog zu dem in Abschnitt 7.4 aufgezeigten Vorgehen. Sie knnen ein Sniffer-Tool beispielsweise zu Hause auf Ihrem eigenen Rechner installieren und beobachten, welchen Netzwerkverkehr sie bei Aktionen wie dem Benutzen des WWW,
Email usw. auffangen.
Aufgabe 7.5:
Mit dem
-Befehl kann unter Linux die aktuelle Routing-Tabelle angezeigt werden.
Beschreiben und erklren Sie die Bedeutung der Felder Flags, Metrics, Ref und Use.
Aufgabe 7.6:
Informieren Sie sich ber die Funktion des
-Befehls und der zugrundeliegenden ICMPEcho-Funktion. Gehen Sie dabei auch auf mgliche Optionen ein und beantworten Sie die Frage,
ob ping auch auf Broadcast-Adressen angewendet werden kann.
Kapitel 8
Sicherheit
8inSicherheit
in Netzwerken
Netzwerken
8.1 Bedrohungen
8.1.1 Bedrohungssituation
Nachdem wir uns nun einen ersten berblick ber die wichtigsten Mechanismen und Protokolle
in Netzwerken und speziell im Internet verschafft haben, wollen wir nun deren Sicherheit genauer betrachten, indem wir die Bedrohungssituation bei der Netzwerkkommunikation abstrakt
analysieren und dann einige konkrete Beispiele fr Angriffe vorstellen.
Die Bedrohungssituation bei Kommunikation ber ein Netzwerk ist in Abbildung 8.1 abstrakt
dargestellt. Die Kommunikation zwischen zwei Stationen kann durch einen Angreifer wie folgt
gestrt werden:
Abfangen: Durch Mitlesen der Nachrichten kann ein Angreifer Zugriff auf den Inhalt der
Kommunikation erlangen.
Manipulieren: Ein Angreifer kann bei der Kommunikation ausgetauschte Nachrichten manipulieren und verflschen.
Tuschen: Ein Angreifer kann eine falsche Identitt vortuschen und selbst mit einem
Opfer kommunizieren. Das Opfer knnen der Sender, der Empfnger oder sogar beide
sein.
Erwnschte
Kommunikation
Sender
Empfnger
Netzwerk
unbefugter
Dritter
Abfangen
Manipulieren
Tuschen
Unterbrechen
Abbildung 8.1: Bedrohung bei Kommunikation ber Netzwerke.
138
8 Sicherheit in Netzwerken
Unterbrechen: Die Kommunikationsverbindung zwischen zwei Stationen kann durch einen Angreifer sabotiert werden.
Es gibt vielfltige, nahezu unbegrenzte Mglichkeiten, wie ein Angriff in die Praxis umgesetzt
werden kann. Besonders leicht ist es einem Angreifer dann, wenn er Zugriff auf eine der Zwischenstationen der Kommunikationsverbindung hat. Wenn dies nicht ohnehin der Fall ist, kann
eine solche Situation durch Eingriffe in das Netz gezielt herbeigefhrt werden, indem die Kommunikation zwischen den Stationen ber eine Station umgeleitet wird, die unter der Kontrolle
des Angreifers steht.
8.1.2 Struktur des Internet

Einer der Hauptgrnde fr den Erfolg des Internet ist seine dezentrale Struktur. Es handelt sich
genaugenommen eben nicht um ein Netz, sondern um ein Netz von Netzen. Diese im Internet
zusammengeschlossenen Einzelnetze sind weitestgehend autonom und knnen durch die jeweiligen Netzbetreiber grtenteils beliebig gestaltet und administriert werden.
Was einerseits ein groer Vorteil ist, entpuppt sich andererseits beim zweiten Hinsehen auch
als einer der Grnde fr die massiven Sicherheitsprobleme im Internet. Die administrative Autonomie und die Freiheit, beliebige Dienste im Netz anbieten zu drfen, kann ausgenutzt werden,
um das Internet fr kriminelle Zwecke zu missbrauchen. Technische Hrden gibt es fast keine.
Da das Internet weltweit verfgbar ist, in verschiedenen Lndern unterschiedliche Gesetze gelten und die internationale Zusammenarbeit zwischen Strafverfolgungsbehrden nicht besonders
ausgeprgt ist, knnen Kriminelle, insbesondere dann, wenn sie ihre Aktivitten ber mehrere
Lnder verteilen, oftmals weitestgehend unbehelligt agieren.
Diese Situation hat in vielen Industrienationen zu Gesetzen oder Gesetzgebungsversuchen gefhrt, die alle Internetbenutzer unter Generalverdacht stellt und zu einer Datensammlung und
Bespitzelung in keinster Weise verdchtiger Personen fhrt, die sich wohl nicht einmal George
Orwell ertrumt htte. Letztlich wird man aber durch solche Manahmen auer einer bedenklichen Aushhlung der Rechte und der Privatsphre der Brger in den jeweiligen Lndern keine
nennenswerten Effekte in Bezug auf die Sicherheit des Internets erzielen knnen.
Zusammenfassend kann ganz ohne Zweifel davon ausgegangen werden, dass es im Internet
eine ausreichende Anzahl von Benutzern gibt und auch in Zukunft geben wird, die die technischen Mglichkeiten und notwendigen Ressourcen besitzen, Schwachstellen fr ihre kriminellen
Zwecke auszunutzen.
8.1.3 Mithren in der Praxis

Vielleicht haben Sie sich im letzten Kapitel in Sektion 7.4 darber gewundert, wie einfach es war,
den gesamten Verkehr im Netzwerk mitzuhren. Dieses Mithren wird auch als Packet Snifng
bezeichnet und ist auf allen Schichten von der Applikationsschicht bis zur Datenverbindungsschicht mglich, sofern keine Mechanismen und Protokolle zur Verschlsselung eingesetzt
werden. Jedes Paket ist auf jeder Zwischenstation jeder Schicht, ber die das Paket zum Ziel
transportiert wird, komplett lesbar. Sofern beispielsweise alle Pakete, die zu einer bestimmten
George
Orwell, 1984, Ullstein Verlag.
8.1 Bedrohungen
139
Abbildung 8.2: Darstellung der Nutzdaten einer TCP-Verbindung mittels Ethereal.
TCP-Verbindung gehren, ber eine bestimmte Zwischenstation laufen, so kann die Information
in den Headern der TCP-Segmente dazu verwendet werden, die Segmente zusammenzufgen.
So kann der Inhalt der kompletten TCP-Verbindung, beispielsweise eine bertragene Datei, vollstndig rekonstruiert werden.
Ethereal bietet Funktionen, die es erlauben, die Nutzdaten einer TCP-Verbindung durch Auswerten aller empfangenen Segmente auszulesen und darzustellen. Abbildung 8.2 zeigt diese
Funktion angewendet auf die Daten aus unserem Experiment aus dem vorangegangenen Abschnitt. Auf diese Weise knnen bertragene Passwrter, Dateien und letztlich alle ber eine
TCP-Verbindung ausgetauschten Informationen extrahiert und dargestellt werden. Gleiches gilt
auch fr UDP-Kommunikation oder Verbindungen, die zustzliche Protokolle verwenden. Auf
diese Weise kann beispielsweise auch ein ber IP gefhrtes Telefongesprch (Voice over IP, kurz
VoIP) aufgezeichnet oder mitgehrt werden.
Einzige Voraussetzung fr einen Angreifer, um in den Besitz der Daten zu gelangen, ist es,
(Administrator-)Zugriff auf einen Rechner im Netzwerk zu haben, von dem aus die ausgetauschten Pakete zwischen den beiden Rechnern beobachtbar sind. Dies sind unter anderem die beiden
Endpunkte selbst und alle Zwischenstationen, ber die der Verkehr luft, also die Switches, mit
denen die Endpunkte jeweils verbunden sind, und die Router. Nicht nur auf Zwischenstationen
ist Packet Snifng mglich. Einige Typen von Datenverbindungsschichten, allem voran Ethernet
in seiner ursprnglichen Variante, sind Broadcast-Technologien. Damit kann im Prinzip jede Station in einem Ethernet-LAN jede bertragung einer anderen Station in diesem LAN mithren.
Wir werden diese Techniken spter exemplarisch diskutieren.
Theoretisch kann jedes IP-Paket seinen Weg durch das Netz alleine nden, und somit knnen
an einigen Stellen im Netz vielleicht nur einige der Pakete einer Verbindung mitgelesen werden.
In der Praxis gibt es jedoch viele Knotenpunkte, die mit hoher Wahrscheinlichkeit von allen zu
einer Verbindung gehrenden Paketen durchlaufen werden. An einigen Punkten sind sogar alle
von und zu einem Rechner ber das Netz geschickten Pakete abgreifbar.
140
Nachricht
Manipulierte Nachricht
Manipulation/
Verflschung
Abbildung 8.3: Manipulation einer Nachricht auf einer Zwischenstation.
Als Faustregel gilt: Je weniger Zwischenstationen zwischen dem Endpunkt und dem Rechner
liegen, auf dem ein Angreifer mitliest, desto mehr Verkehr dieses Endpunktes kann aufgefangen
werden, an einigen Stellen sogar die gesamte Netzwerkkommunikation eines Rechners.
Das Mitlesen von Verkehr ist nicht nur ein Sicherheitsrisiko, sondern bietet auch die Mglichkeit, durch berwachung der Netzwerkaktivitt Angriffe aufzuspren. Wir werden diese Methoden in Kapitel 11 genauer vorstellen.
8.1.4 Manipulieren von Nachrichten

Zwischenstationen knnen Nachrichten jedoch nicht nur mitlesen, sondern auch deren Inhalt
manipulieren. Dies trifft sowohl auf Daten als auch auf die Header-Informationen beliebiger
Protokolle zu. In Abbildung 8.3 ist dies skizziert.
Das Verndern bestimmter Header-Daten ist bei einigen Protokollen zwingend vorgegeben,
beispielsweise muss das Time-to-live-Feld des IP-Protokolls bei jeder Zwischenstation auf IPEbene um eins dekrementiert werden. Darber hinaus ist die Vernderung von Protokollinformationen die Grundlage verschiedener Technologien und Methoden, die im Internet eingesetzt
werden, wie etwa Network Address Translation (NAT) [RFC 2663]. NAT ermglicht die Benutzung lokaler, nicht im gesamten Internet verwendbarer IP-Adressen durch die transparente
bersetzung dieser Adressen in global eindeutige Adressen auf einem sogenannten NAT-Router
(siehe Abschnitt 9.2.1.5). Oftmals werden dabei nicht nur IP-Adressen, sondern auch TCP- und
UDP-Portnummern verndert. Wie erwhnt sind TCP und UDP konzeptionell eigentlich Protokolle, die Ende-zu-Ende operieren und in die Zwischenstationen eigentlich nicht eingreifen
sollten. Trotzdem nden solche Manipulationen statt.
Es gibt noch eine ganze Reihe weiterer Beispiele fr mgliche Vernderungen von Daten und
Protokollinformationen beim Transport durch ein Netzwerk. Dies unterstreicht, dass Manipulationen nicht nur prinzipiell mglich sind, sondern auch tatschlich aus den unterschiedlichsten
Grnden durchgefhrt werden. Auch wenn dies aus sicherheitstechnischer Sicht einige Fragen
aufwirft und durchaus bedenklich sein kann, muss zur Kenntnis genommen werden, dass solche
Verfahren, die nicht bswillig gegen Sicherheit gerichtet sind, existieren.
Schwerwiegend ist jedoch, wie einfach solche Manipulationen sind und wie leicht hnliche
Techniken mit bswilligen Zielsetzungen angewendet werden knnen, sofern die Kommunikation ber das Netzwerk nicht anderweitig geschtzt wird.
Beim Entwurf des Internets mit seiner dezentralen Struktur wurde grundlegend davon ausgegangen, dass man den im Netz zusammengeschlossenen Rechnern vertrauen kann. Diese Annah-
8.1 Bedrohungen
141
me war in der Anfangszeit des Internet unkritisch, ist heute aber eine der Hauptursachen fr die
Sicherheitsprobleme.
8.1.5 Schutzmechanismen
Es stellt sich die Frage, wie man derartige Angriffe abwehren oder verhindern kann. In Kapitel
2 haben wir kryptographische Verfahren grob skizziert, die gegen einige Angriffe wirkungsvolle
Schutzmechanismen zur Verfgung stellen knnen:
Durch Verschlsselung der Kommunikation zwischen zwei Stationen kann verhindert werden, dass sich ein unbefugter Dritter durch Mitlesen Zugriff auf den Inhalt der Kommunikation verschafft.
Durch Authentikation der bei der Kommunikation bersendeten Nachrichten und der beteiligten Stationen oder Benutzer knnen Manipulationen der Kommunikation, etwa durch
Vernderung, ebenso entdeckt werden wie Tuschungen hinsichtlich der Identitt eines
Kommunikationspartners.
Unterbrechungen der Kommunikation lassen sich durch kryptographische Methoden in
einigen Fllen verhindern, insbesondere dann, wenn sie durch Manipulationen der Kommunikation, etwa durch Vernderungen oder Tuschungen herbeigefhrt werden. Leider
gibt es eine ganze Reihe von Angriffen in diesem Bereich, die durch kryptographische Methoden nicht abgewendet werden knnen. Generell sind Schutzmechanismen gegen Unterbrechungen und berlastungen schwierig zu nden und umzusetzen.
8.1.6 Anonymitt
Ein weiterer wichtiger Punkt, der nicht unmittelbar mit den oben beschriebenen Bedrohungen
zusammenhngt und den wir hier nur kurz ansprechen und in Abschnitt 13.3.8 vertiefen wollen,
ist die Anonymitt eines Benutzers bei der Verwendung des Internet.
Ein Benutzer hinterlsst bei der Verwendung des Internet an vielen Stellen Spuren, die eine
relativ genaue Eingrenzung und vielleicht sogar seine eindeutige Identizierung erlauben. Zum
Beispiel ermglicht die IP-Adresse, von der aus ein Benutzer Verbindungen zu anderen Rechnern betreibt, hug eine zumindest grobe Bestimmung seines Standortes und in einigen Fllen
sogar eine eindeutige Benutzeridentikation. Ist fr den Rechner ein Eintrag im DNS vorhanden,
so kann ber einen sogenannten Reverse-DNS-Lookup der Domainname des Rechners ermittelt
werden.
Auf den Punkt gebracht ist der Besuch in einem Kaufhaus anonymer und weniger leicht nachvollziehbar, als der Besuch der Webseite des Kaufhauses.
142
8.2 Beispiele fr Schwachstellen und Risiken in Netzwerken

und Netzwerkprotokollen
Wir haben bereits gesehen, wie leicht Nachrichten im Netz mitgehrt oder geflscht werden
knnen. Im Folgenden werden wir uns mit einigen Beispielen fr Angriffe beschftigen, die
solche Schwachstellen orchestriert ausnutzen.
8.2.1 Manipulationen beim Routing

Routing ist eine der Kernfunktionen in einem Netzwerk. Wir hatten in Abschnitt 7.3.3.4 bereits
kurz skizziert, wie das Routing im Internet abluft. Mittlerweile drfte schon klar geworden sein,
warum ein Angreifer ein Interesse haben knnte, das Routing zu manipulieren oder zu stren:
Leiten des Verkehrs ber einen durch den Angreifer kontrollierten Rechner: Gelingt es
dem Angreifer, den Verkehr ber einen Rechner unter seiner Kontrolle zu leiten, so kann
er die Daten mitlesen oder manipulieren.
Stren des Routings: Durch gezielte Fehlinformationen kann es einem Angreifer gelingen,
das Routing in einem Netzwerk zu stren oder sogar zu unterbrechen.
Es gibt vielfltige Mglichkeiten, wie es einem Angreifer gelingen kann, das Routing im Netzwerk zu manipulieren. Werden die Routingtabellen dynamisch mittels eines Routingprotokolls
aufgebaut, so kann durch das Versenden von geflschten Informationen ber diese Routingprotokolle anderen Routern suggeriert werden, eine Verbindung ber den Rechner des Angreifers sei
besonders vorteilhaft. Mit anderen Worten wird den anderen Routern vorgegaukelt, der optimale
Weg zu anderen Rechnern fhre ber den Rechner des Angreifers. Konsequenterweise werden
diese die Datenpakete ber den Rechner des Angreifers weiterleiten, so dass dieser dann den
Verkehr einfach mithren oder manipulieren kann. Einen einfachen Schutz vor solchen geflschten Routingprotokollinformationen bietet die Authentikation der zwecks Aufbau der Routingtabelle bertragenen Nachrichten. Diese Funktion ist mittlerweile in vielen Routingprotokollen
integriert, wird aber noch nicht berall angewendet.
Sind die Routingtabellen statisch, bieten sich dem Angreifer ebenfalls Mglichkeiten. Beispielsweise erlaubt es das ICMP-Protokoll, sogenannte ICMP-Redirect-Nachrichten zu versenden. Diese sind eigentlich dafr gedacht, einer anderen Station eine efzientere Route zu einem
Zielsystem mitzuteilen, doch lassen sie sich auch missbrauchen, um den Verkehr auf das System
eines Angreifers umzuleiten.
Das IP-Protokoll bietet als Option das sogenannte Source Routing an. Dies ermglicht es dem
Absender eines Paketes, den Weg des Paketes durch das Netz durch Angabe einer Liste von
Zwischenstationen, die traversiert werden mssen, genauer festzulegen. Auch hier bieten sich
Mglichkeiten fr einen Missbrauch.
Wir wollen hier nicht genauer auf technische Details eingehen. Es sollte deutlich geworden
sein, wie vielfltig die Mglichkeiten eines Angreifers sind, den Weg von Paketen durch ein
Netzwerk zu manipulieren.
8.2 Beispiele fr Schwachstellen und Risiken in Netzwerken und Netzwerkprotokollen
143
8.2.2 MAC-Address-Spoong
Wir werden jetzt einige Beispiele fr Schwachstellen betrachten, welche die im vorangegangenen
Kapitel skizzierten Protokolle und Netzwerkmechanismen aufweisen. Beginnen wollen wir mit
dem Vortuschen falscher Identitten.
Wie bereits in Sektion 7.3.1.1 erwhnt, sind die MAC-Adressen eines Interfaces global eindeutig. Daher ist man auf die Idee gekommen, diese Adressen zur Authentikation und Identikation bestimmter Systeme zu verwenden. In der Tat gibt es einige Anwendungen und Dienste,
bei denen die MAC-Adresse zur Identikation eingesetzt wird:
Bei der automatischen Vergabe von IP-Adressen ber DHCP ist es mglich, die Vergabe
der Adressen im DHCP-Server auf bestimmte MAC-Adressen zu beschrnken. Erreicht
werden soll damit eine Beschrnkung der Vergabe von IP-Adressen an im DHCP-Server
registrierte Gerte.
Einige WLAN-Access-Points ermglichten die Beschrnkung des Netzwerkzugangs anhand der MAC-Adresse der Clients.
Einige Serviceprovider beschrnken den Netzwerkzugang ebenfalls ber die MAC-Adresse der Clients.
Diese Vorgehensweise ist unzureichend, da die Flschung einer MAC-Adresse sehr einfach
ist. Die Vortuschung einer falschen Adresse wird allgemein als Address-Spoong bezeichnet. In
unserem Fall haben wir es also mit MAC-Address-Spoong zu tun.
MAC-Address-Spoong ist technisch ohne greren Aufwand mglich, wenn die verwendete Netzwerkhardware dies erlaubt. Es gibt Netzwerkprodukte fr den Heimnetzwerkbereich, die
das Klonen einer MAC-Adresse explizit ermglichen. Auf diese Weise lsst sich die Beschrnkung des Netzwerkzugangs ber die MAC-Adresse durch Serviceprovider elegant umgehen. Da
die MAC-Adresse nur innerhalb des LANs verwendet wird, ist ein Rechner, der eine geflschte MAC-Adresse verwendet, in seinen Kommunikationsmglichkeiten in keinster Weise eingeschrnkt. Die Entdeckung einer geflschten MAC-Adresse ist mehr oder weniger unmglich.
Kurz gefasst: Die Verwendung geflschter MAC-Adressen ist ohne grere Probleme mglich. Es gibt fast keine Ansatzpunkte, diesen Missbrauch zu erkennen, und ein Interface, das mit
einer geflschten MAC-Adresse betrieben wird, ist voll funktionsfhig. Daher sind Verfahren,
die eine Authentikation anhand der MAC-Adresse durchfhren, aus der Sicherheitsperspektive
betrachtet nutzlos.
8.2.3 ARP-Spoong
Das in Abschnitt 7.3.3.6 kurz vorgestellte ARP-Protokoll dient zum bersetzen einer IP-Adresse
in eine MAC-Adresse fr direkt im gleichen LAN betriebene Rechner. Wird eine bersetzung
bentigt, so wird ber das ARP-Protokoll im Netz die zu einer IP-Adresse gehrende MACAdresse ermittelt und in einem lokalen Cache abgespeichert. Auch hier bieten sich Schwachstellen, die ein Angreifer ausnutzen kann, um im ARP-Cache eines Rechners einen geflschten
Eintrag zu platzieren.
144
Angreifer A
MAC: AB:CD:EF:01:02:03
IP: 192.168.5.19
198.168.5.0/24
2. A antwortet mit
seiner eigenen MAC-Adresse
C
MAC: 01:02:03:04:05:06
IP: 192.168.5.19
1. ARP-Request von B
fr 192.168.5.19
B sendet zuknftig alle
Pakete fr C an A
3. B speichert MAC AB:CD:EF:01:02:03 fr IP 192.168.5.19

im ARP-Cache
B
MAC: AA:AB:AC:AD:AE:AF
IP: 198.168.5.2
Abbildung 8.4: ARP-Spoong.
Das Vorgehen ist denkbar einfach: Wie in Abbildung 8.4 dargestellt, sitzt der Angreifer an einer Maschine A im gleichen LAN. Maschine B mchte mit C (IP 192.168.5.19) kommunizieren.
Wir nehmen aus Vereinfachungsgrnden an, dass B die entsprechende IP-MAC-Adressenzuordnung fr C noch nicht lokal gespeichert hat. Daher stellt B eine Anfrage nach der IP-Adresse des
Rechners C. Anstelle von C antwortet aber die Maschine A des Angreifers auf die Anfrage und
teilt B ihre eigene MAC-Adresse mit, so dass B anstelle von Cs MAC-Adresse die MAC-Adresse
von A erhlt. Aufgrund dieses falschen Eintrags wird B zuknftig Pakete fr C an den Rechner
des Angreifers A senden.
Mit einem solchen Angriff kann eine Reihe von mglichen Zielen verfolgt werden:
Mithren: Der Angreifer erhlt von B (und mglicherweise anderen Maschinen) fr C
gedachte Daten. Eventuell kann er durch weitere Manahmen die Daten sogar an C weiterleiten, so dass ein Benutzer an der Maschine C hiervon nichts merkt.
Authentikation: Sofern die IP-Adresse zur Authentikation verwendet wird (ohnehin eine
schlechte Idee), kann der Angreifer die Adresse von C missbrauchen.
Denial-of-Service: Maschine C wird durch die Versendung der geflschten ARP-Nachrichten effektiv in der Kommunikation mit anderen Rechnern behindert, bis hin zur Strung
oder Unterbrechung der Verfgbarkeit der Netzwerkverbindung.
Schutzmanahmen gegen ARP-Spoong sind mglich, beispielsweise durch die Verwendung
statischer, manuell vorgenommener Eintrge im ARP-Cache. In der Praxis gestaltet sich ein
derartiges Verfahren schwierig. Der Fokus liegt daher auf Manahmen, mit denen Inkonsistenzen
und Fehler bei der Umsetzung von IP- in MAC-Adressen erkannt werden knnen, beispielsweise
durch berprfung der entsprechenden Daten verschiedener Rechner. Ebenso kann ein Rechner
ARP-Queries auf seine eigene IP-Adresse absenden und hierdurch in Erfahrung bringen, ob ein
anderer Rechner im LAN dieselbe IP-Adresse nutzt.
8.2.4 IP-Spoong
Nicht nur MAC-Adressen lassen sich mhelos flschen, sondern auch IP-Adressen. Beim IPAddress-Spoong versendet ein Rechner IP-Pakete, in denen er als Absender nicht seine eigene
145
C
IP-Zieladresse: C
IP-Quelladresse: B
IP-Zieladresse: B
IP-Quelladresse: C
1. A sendet IP-Paket mit geflschter
IP-Quelladresse B an Maschine C
2. C sendet Antwortpaket an B
Internet
B
A
Abbildung 8.5: IP-Address-Spoong.
tatschliche IP-Adresse angibt, sondern eine andere Adresse. Dies kann die tatschliche Adresse
eines anderen Rechners im gleichen LAN, einer Maschine irgendwo im Internet oder auch eine
IP-Adresse sein, unter der kein Rechner rmiert.
Im Gegensatz zum MAC-Address-Spoong schrnkt die Verwendung einer geflschten IPAdresse die Kommunikationsmglichkeiten des Rechners ein. Wie in Abbildung 8.5 gezeigt,
kann ein Rechner A zwar sehr leicht anstatt seiner tatschlichen IP-Adresse eine geflschte
Adresse B angeben, um ein IP-Paket an einen Rechner C zu senden. Da die IP-Adresse aber
zum Routing der Pakete durch das Netz verwendet wird, werden eventuelle Antworten von C
dann an die IP-Adresse B geschickt und erreichen damit A in der Regel nicht (sofern A und B
nicht im gleichen LAN liegen).
Insofern ist also unter Verwendung einer geflschten IP-Adresse auer in besonderen Situationen ausschlielich unidirektionale Kommunikation vom flschenden Rechner zu einem anderen
Rechner mglich. IP-Address-Spoong stellt aber trotzdem tatschlich ein ernsthaftes Problem
dar, da die unidirektionale Kommunikation fr bestimmte Angriffe, speziell Denial-of-ServiceAngriffe, also zur Einschrnkung oder Unterbrechung eines Dienstes, vollkommen ausreicht.
Wir werden dieses Problem und mgliche Gegenmanahmen in Abschnitt 12.2 noch nher betrachten.
8.2.5 TCP Sequence Number Attack

Aufgrund der obigen Aussagen erscheint es nicht besonders erfolgversprechend, mit einer geflschten IP-Adresse eine Verbindung ber TCP aufbauen und verwenden zu wollen. Wie wir
bereits aus Abschnitt 7.3.4.1 wissen, erfordert der Datenaustausch ber TCP einen Verbindungsaufbau, und da mit einer geflschten IP-Adresse nur Kommunikation in eine Richtung mglich
ist, sollte bereits der Verbindungsaufbau scheitern. Wenn man sich den zum Verbindungsaufbau
verwendeten Three-Way-Handshake jedoch genauer betrachtet, so stellt man fest, dass es in der
im zweiten Schritt des Handshake versendeten Antwort des Servers an die Anfrage des Clients
nur einen einzigen Wert gibt, den der Client fr die Antwort im dritten Schritt bentigt und nicht
146
B
Zeit
SYN SEQ=client_
asn
SYN ACK SEQ=
server_asn ACK=
client_
ACK SEQ=client_
asn+1 ACK=ser
ver_asn+1
asn+1
C antwortet nicht (beispielsweise wegen eines

vorangegangenen Angriffs durch A)
geraten
Verbindung erfolgreich aufgebaut
Daten
Antwort
Abbildung 8.6: Angriff auf TCP unter Verwendung einer falschen IP-Adresse.
kennt, nmlich die serverseitige Anfangssequenznummer. Wenn man diese Anfangssequenznummer des Servers richtig erraten kann, ist es mglich, dem Server den Handshake vorzutuschen
und so eine TCP-Verbindung unter einer geflschten IP-Adresse aufzubauen, ohne die Antworten
des Servers tatschlich zu empfangen.
Abbildung 8.6 verdeutlicht dieses Vorgehen. Der Angreifer A beginnt mit der IP-Adresse eines
Rechners C den Aufbau einer TCP-Verbindung mit dem Server B durch Senden eines Segments
mit gesetztem SYN-Flag. B antwortet mit dem blichen SYN ACK, wobei dieses natrlich an C
und nicht an A adressiert wird. Wenn A die Anfangssequenznummer von B richtig erraten hat,
kann er das letzte Segment im Handshake (ACK) an den Server schicken und so den Verbindungsaufbau erfolgreich durchfhren, obwohl er die Antwort von B nicht erhalten hat.
Nach dem Aufbau der Verbindung ist es mglich, Daten von A nach B zu senden. Allerdings
wird man von B keine Antworten erhalten, da diese wiederum zu C geschickt werden. Wenn die
zu erwartenden Antworten bekannt sind (was huger der Fall ist, als viele glauben), knnen auf
diese Weise per TCP Daten von A nach B geschickt werden.
Diese Kommunikation in eine Richtung kann Grundlage eines Angriffs bilden, wenn eine
Vertrauensbeziehung zwischen den Rechnern B und C besteht und die Authentikation von C
anhand der IP-Adresse vorgenommen wird. Uns reicht an dieser Stelle die exemplarische Darstellung dieser Mglichkeit, ohne weiter in Details einzusteigen.
Wie man der Abbildung entnehmen kann, gibt es zwei Voraussetzungen fr einen Erfolg dieses
Angriffs:
A muss die Anfangssequenznummer des Servers B richtig erraten und
C darf auf die von B (unverlangt) zugesendeten TCP-Segmente nicht antworten.
Tatschlich sind solche Angriffe praktiziert worden. Dies wurde dadurch begnstigt, dass sich
die als Anfangssequenznummer verwendeten Werte bei einigen Betriebssystemen durch Beob-
147
Echter Server www.irgendeinebank.de

IP 192.168.9.82
Internet
Kopie des Dienstes durch einen Angreifer

IP 10.44.21.19
DNS-Eintrag:
www.irgendeinebank.de
10.44.21.19
Rechner verwendet falschen

Eintrag und landet beim
Aufruf von www.irgendeinebank.de
beim Dienst des Angreifers
Abbildung 8.7: DNS-Spoong.
achtung vorangegangener TCP-Verbindungsaufbauten vorhersagen lieen. Rechner C kann man

ausschalten, indem man ihn vorher anderweitig angreift und zumindest kurzzeitig lahmlegt.
Sollte B die IP-Adresse von C zur Authentikation verwenden, was wie schon erwhnt keine
gute Idee ist, so kann der Angreifer A dann auf B Befehle ausfhren, die eigentlich C vorbehalten
sein sollten.
8.2.6 DNS-Spoong
Wir hatten in Abschnitt 7.3.5.2 das DNS-Protokoll kurz vorgestellt, das Domainnamen in IPAdressen aust. Da Rechner im Internet meistens ber ihren Domainnamen angesprochen werden, kommt diesem Protokoll eine wichtige Bedeutung zu.
Schwachstellen im DNS-System knnen missbraucht werden, um auf Rechnern gezielt falsche
DNS-Informationen abzulegen und so Benutzer auf Rechner unter der Kontrolle eines Angreifers
zu locken.
Prinzipiell ist die Problematik in Abbildung 8.7 skizziert. Ein Angreifer betreibt eine tuschend echte Kopie des Webauftritts der Bank
. Fr einen gewhnlichen Benutzer ist zwischen diesen Webauftritten kein Unterschied erkennbar, zumindest solange
nicht, bis der Benutzer bemerkt, dass mit den auf der geflschten Website eingegebenen PINs
und TANs erhebliche Geldbetrge gestohlen wurden.
Um den Benutzer auf diese falsche Seite zu locken, kann der Angreifer falsche DNS-Eintrge
auf dem Rechner des Benutzers erzeugen, so dass der Domainname
nicht wie eigentlich richtig in die IP-Adresse des Webservers der Bank 192.168.9.82 bersetzt
wird, sondern in die des Servers des Angreifers 10.44.21.19.
Es gibt verschiedene Arten, wie ein Angreifer dies erreichen kann. Eine Mglichkeit ist es,
ber Malware den DNS-Cache in einem Rechner zu manipulieren und so die falschen Eintrge
148
zu generieren. Ebenso ist es mglich, den lokal verwendeten DNS-Server zu kompromittieren,

so dass der Rechner auf seine Anfrage ein falsches Ergebnis geliefert bekommt. Da das DNSProtokoll heute in den meisten Fllen ohne Authentikation und ber UDP luft, ist es auerdem mglich, dem Rechner des Benutzers durch das Senden geflschter DNS-Antworten, die
scheinbar von einem korrekten DNS-Server stammen, geflschte Eintrge unterzuschieben. Der
Phantasie sind also (leider) fast keine Grenzen gesetzt.
8.3 Sicherheitsprotokolle im Internet Ein berblick

Wir haben bereits einige Beispiele dafr kennengelernt, dass nahezu alle Protokolle auf allen
Schichten des Netzes in Bezug auf die Sicherheit schwerwiegende Dezite aufweisen. Wenn
wir Sicherheit als zustzliche Funktion von Netzwerken auffassen und hierfr geeignete Protokolle oder Protokollergnzungen denieren wollten, stellt sich die Frage, auf welcher der fnf
Schichten unseres Referenzmodells eine solche Funktion angesiedelt werden sollte.
Um es vorwegzunehmen: Leider gibt es auf diese Frage keine allgemeingltige und abschlieende Antwort. Sicherheitsprotokolle nden sich auf allen Schichten des Referenzmodells, und
dies mit einiger Berechtigung. Wir werden uns in den folgenden Kapiteln ausfhrlich mit den verschiedenen Anstzen beschftigen und sichere Protokolle auf allen Schichten nher betrachten.
Vorab wollen wir nun diskutieren, warum solche Protokolle auf allen Schichten ihre Berechtigung haben, und warum es eben nicht ausreicht, Sicherheitsmechanismen nur auf einer einzigen
Schicht zu verankern.
Auf allen Schichten spielt die Authentikation von Kommunikationspartnern (Benutzern oder
Stationen) ber das Netzwerk und der Aufbau einer sicheren Kommunikation zwischen diesen
Partnern eine zentrale Rolle. Wir verwenden das Wort Kommunikation und nicht Verbindung, da die Absicherung sowohl fr verbindungsorientierte als auch fr verbindungslose Protokolle und Verfahren durchgefhrt werden kann.
Alle eben vorgestellten Sicherheitslcken sind auf mangelnde oder nicht vorhandene Authentikation und fehlende Absicherung der Kommunikation zwischen Rechnern zurckzufhren.
Ziele und Aufgaben von Sicherheitsprotokollen sind damit:
Authentikation des Kommunikationspartners. Dabei sollten
sowohl die wechselseitige als auch eine einseitige Authentikation untersttzt werden und
unterschiedliche Authentikationsmethoden mglich sein.
Schaffung der Grundlagen fr die Anwendung kryptographischer Mechanismen. Durch
diese Mechanismen soll
die Authentizitt und/oder
die Vertraulichkeit der zwischen den Stationen ausgetauschten Nachrichten sichergestellt werden.
Hierzu gehrt insbesondere die Vereinbarung kryptographischer Verfahren zur Sicherung
von Integritt und/oder zur Verschlsselung der Protokolleinheiten und das Bereitstellen
der bentigten kryptographischen Schlssel.
149
Daten
Daten
Applikationsschicht
kryptographisch
behandelte Daten
kryptographisch
behandelte Daten
Transportschicht
Abbildung 8.8: Sicherheitsmechanismen in der Anwendungsschicht.
Anwendung der kryptographischen Verfahren. Zur Gewhrleistung von (je nach Bedarf)
Vertraulichkeit, Integritt, Authentizitt, Verbindlichkeit usw.
Nicht jedes Protokoll muss zwingend alle Aufgaben bernehmen. Oft erfolgt die Authentikation und das Aushandeln der verwendeten kryptographischen Verfahren und Schlssel durch
ein Protokoll, whrend die eigentliche Kommunikation und Anwendung der kryptographischen
Verfahren ber ein anderes Protokoll erfolgt.
Die Authentikation von Benutzern oder Systemen wurde bereits in Kapitel 3 betrachtet. Die
verwendeten Verfahren basieren oft auf der Verwendung von Passwrtern oder kryptographischer Verfahren. Wir hatten in Sektion 3.6.1 gesehen, wie sich Stationen unter Verwendung eines gemeinsamen Geheimnisses (d.h. eines symmetrischen kryptograhischen Schlssels oder von
Passwrtern) oder auch durch Zertikate authentizieren knnen. Alle dort angesprochenen Methoden knnen prinzipiell auch in Netzwerken eingesetzt werden. Gerade Zertikate, die wir in
3.6.3 kennengelernt hatten, spielen in Netzwerken heute eine zentrale Rolle. Zertikate sind vor
allen Dingen deshalb wichtig, da sie die Mglichkeit bieten, beliebige Kommunikationspartner
im Besitz eines Zertikats zu authentizieren auch solche, mit denen man vorher noch nicht in
Kontakt getreten ist.
8.3.1 Sicherheit auf der Applikationsschicht

Wenn ein Anwendungsprogrammierer eine Anwendung entwickelt, die in einem Netzwerk betrieben werden soll, das als gnzlich unsicher gilt und ber keinerlei Sicherheitsfunktionen verfgt, so bleibt dem Programmierer eigentlich keine andere Wahl, als Mechanismen zur Sicherstellung von Authentikation, Vertraulichkeit und Integritt in der Anwendung selbst, also auf
der Applikationsschicht zu integrieren.
Ein Beispiel hierfr ist die Verschlsselung und/oder digitale Signatur einer Email-Nachricht
auf der Applikationsschicht vor der bertragung ber das Netz (siehe Abschnitt 13.1). Der Transportschicht wird durch die Anwendung eine bereits verschlsselte Nachricht zur bertragung
150
bergeben. Die Transportschicht und alle weiteren Schichten transportieren die von der Anwendungsschicht bergebenen verschlsselten Daten. Einem Angreifer ist es durch den kryptographischen Schutz nicht mglich, die Daten unbemerkt zu manipulieren, da durch die kryptographischen Schutzmechanismen Vernderungen auf der Anwendungsschicht beim Empfnger
entdeckt wrden. Ebenso kann Vertraulichkeit sichergestellt werden.
Letztlich entspricht dieser Ansatz einer Automatisierung von manueller Verschlsselung durch
den Benutzer selbst: Wenn ein Anwender eine vertrauliche Datei per Email betragen mchte,
so kann er diese zunchst auerhalb der Email-Anwendung mit einem anderen unabhngigen
Hilfsprogramm verschlsseln, und dann diese verschlsselte Datei per Email bertragen. Der
Empfnger auf der anderen Seite muss die per Email erhaltene Datei erst speichern und mit dem
Hilfsprogramm wieder entschlsseln, bevor er sie verwenden kann. Dieses Vorgehen ist natrlich
nicht besonders komfortabel, da die beiden Benutzer sich vorher genau darber einigen mssen,
welches Hilfsprogramm und welchen kryptographischen Schlssel sie verwenden. Bei diesem
Vorgehen gibt es auerdem eine ganze Reihe mglicher Fehlerquellen. Es ist somit nicht nur aus
Benutzersicht wesentlich angenehmer, sondern auch sicherer, wenn solche Mechanismen in die
Anwendung selbst eingebettet sind. Abbildung 8.8 zeigt exemplarisch, wie die kryptographische
Mechanismen in der Anwendungsschicht integriert werden knnen.
Als Vorteile dieses Ansatzes sind zu nennen:
Unabhngigkeit von Mechanismen auf anderen Schichten des Netzwerks: Da die Anwendung selbst die Schutzmechanismen implementiert, ist die Sicherheit der bertragung unabhngig davon, welche Sicherheitsmechanismen sonst zur Verfgung stehen.
Kryptographischer Schutz erfolgt Ende-zu-Ende: Die Verschlsselung auf der Anwendungsebene erfolgt vollstndig Ende-zu-Ende. Verschlsselt bertragene Informationen
liegen an keiner anderen Stelle im Klartext vor, da er erst beim Kommunikationspartner
wieder entschlsselt wird.
Nachteile dieses Ansatzes sind:
Komplexitt der Anwendungsprogramme: Da die Anwendung die kryptographischen Mechanismen untersttzen muss, steigt ihre Komplexitt.
Geringere Wiederverwendbarkeit erstellter Softwarekomponenten: Jede Anwendung muss
die kryptographischen Verfahren selbst untersttzen. Wird ein Mechanismus in verschiedenen Anwendungen benutzt, so muss der Mechanismus im Extremfall fr jede Anwendung separat implementiert werden. Hierdurch steigen die Entwicklungskosten und die
Fehlerwahrscheinlichkeit.
Der letzte Punkt kann relativ geschickt umgangen werden, indem die Anwendung die kryptographischen Funktionen nicht selbst bereitstellt, sondern letztlich nur eine Schnittstelle beinhaltet, ber die ein eigenstndiges Hilfsprogramm aufgerufen wird, das diese kryptographischen
Funktionen durchfhrt. Diese Lsung wirkt zwar elegant, fhrt aber zu einer ganzen Reihe von
Schwierigkeiten bei Installation und Pege des Programms, etwa wenn eine neue Version des
Hilfsprogramms eine vernderte Syntax verwendet, die die aufrufende Anwendung nicht untersttzt.
151
8.3.2 Sicherheit auf der Transportschicht

Natrlich gibt es eine ganze Reihe von Anwendungen, deren Anforderungen die bertragung
kryptographisch verschlsselter Nachrichten beinhaltet. Es ist also naheliegend, diese Funktion
aus der Anwendung auszugliedern und in die Transportschicht zu verlagern, da dann mehrere
Anwendungen diesen Dienst nutzen knnen, ohne ihn selbst eigenstndig implementieren zu
mssen.
Realisieren wir die kryptographischen Schutzfunktionen in der Transportschicht, so bergibt
die Anwendungsschicht der Transportschicht unverschlsselte, nicht integrittsgeschtzte Daten,
welche die Transportschicht dann kryptographisch behandelt und beispielsweise verschlsselt
oder durch digitale Signaturen geschtzt bertrgt.
Whrend es in einigen Fllen theoretisch mglich wre, diese Aufgaben transparent in der
Transportschicht zu erledigen (d.h. ohne Vernderung des Codes der Anwendung), verwenden
in der Praxis alle Sicherheitsprotokolle auf der Transportschicht separate Schnittstellen, mittels
derer die Anwendung ihre Anforderungen an die Transportschicht weitergibt.
Gegenber der Absicherung auf der Anwendungsschicht bietet eine Absicherung der Kommunikation auf der Transportschicht also einige Vorteile. Nachteile und groe Unterschiede sind
auf den ersten Blick vielleicht nicht unbedingt ersichtlich, sind doch sowohl die Verbindungen
auf der Transportschicht als auch auf der Anwendungsschicht Ende-zu-Ende und somit direkt
zwischen den Anwendungen abgesichert.
Doch es gibt subtile, aber schwerwiegende Unterschiede: Die Absicherung auf der Transportschicht ist zwar Ende-zu-Ende hinsichtlich der aktuellen Kommunikation zwischen den Anwendungsebenen der beteiligten Stationen, aber einige Anwendungen basieren nicht ausschlielich
auf der Kommunikation zweier Stationen, sondern zwischen mehreren Stationen. Informationen
werden beispielsweise von einem Client C1 zu einem Server S bertragen und dort von einem anderen Client C2 wieder abgeholt. So (und noch etwas komplizierter) funktionieren unter anderem
Email oder Messaging Services. Werden die Daten zwischen C1 und S auf der Transportschicht,
nicht aber auf Applikationsebene verschlsselt, so erhlt die Applikationsschicht auf S die Daten
unverschlsselt. Ob die Daten zwischen S und C2 ebenfalls gesichert bertragen werden, kann
durch C1 nicht direkt beeinusst oder beobachtet werden. Ebenso wren die auf der Applikationsschicht bei S im Klartext vorliegenden Daten eventuell gefhrdet, wenn S Schwachstellen
aufweist. Dies ist in Abbildung 8.9 skizziert.
Halten wir also Vor- und Nachteile der Integration von Sicherheitsmechanismen in die Transportschicht fest. Als Vorteile sind zu nennen:
Verwendbar durch verschiedene Anwendungen: Ein einmal implementierter Mechanismus
kann von beliebigen Anwendungen durch Benutzung der bereitgestellten Schnittstellen
verwendet werden.
Nachteile:
Anpassung der Anwendung: Die meisten Transportschichtmechanismen und -protokolle
verwenden spezielle Schnittstellen, so dass die Verwendung solcher Mechanismen eine
Anpassung bereits bestehender Anwendungen erfordert.
152
Daten
Daten
Daten
Daten
Applikationsschicht
kryptographisch
behandelte Daten
kryptographisch
behandelte Daten
kryptographisch
Daten
behandelte Daten
Daten
Transportschicht
Kryptographischer
Schutz bei nochmaligem
Transport durch das
Netz kann nicht
sichergestellt werden
Abbildung 8.9: Sicherheitsmechanismen auf der Transportschicht.
Nicht notwendigerweise Ende-zu-Ende-Schutz aus Sicht der Applikation: Verfahren auf

der Transportschicht schtzen zwar Ende-zu-Ende im Hinblick auf die aktuell bestehende
Transportverbindung, jedoch nicht notwendigerweise auch Ende-zu-Ende aus Sicht der
Applikation.
Wir werden uns mit Protokollen zur Absicherung auf Transportschichtebene in Abschnitt
13.3.3 befassen.
8.3.3 Sicherheit auf der Netzwerkschicht

Whrend die Absicherung auf Applikationsschicht und Transportschicht entweder in Bezug auf
die Applikation oder den bestehenden Kommunikationsuss auf der Transportebene Ende-zuEnde erfolgt, arbeitet die Netzwerkschicht nicht Ende-zu-Ende. Auf der Netzwerkschicht sind
typischerweise viele verschiedene Stationen an der Kommunikation beteiligt, nicht nur die jeweiligen Kommunikationsendpunkte.
Auch auf der Netzwerkschicht kann der Verkehr abgesichert werden, allerdings nicht nur
zwischen den beteiligten Endpunkten einer Kommunikationsverbindung, sondern auch auf Teilstrecken einer Verbindung. Dabei kann sich die Absicherung auf bestimmte Kommunikationssse beschrnken oder aber den gesamten Verkehr zwischen zwei Zwischenstationen umfassen.
Dies ist in Abbildung 8.10 skizziert.
Die Absicherung auf der Netzwerkschicht erfolgt transparent fr die darberliegenden Schichten. Auf der Netzwerkschicht kann also beliebiger Verkehr verschlsselt werden, ohne dass die
betroffenen Anwendungen, Anwendungsprotokolle oder Transportprotokolle dies in irgendeiner
Art und Weise untersttzen mssen. Umgekehrt erhlt die Anwendung (und damit der Anwender) aber auch keine Rckmeldung, ob ein kryptographischer Schutz erfolgt oder nicht.
Konsequenterweise ist die derzeitige Ausprgung von Verschlsselung auf der Netzwerkebene
daher nicht gut dazu geeignet, die Kommunikationssse einzelner Anwendungen in Bezug auf
die aktuelle Kommunikation Ende-zu-Ende zu schtzen, obwohl dies prinzipiell mglich wre.
Ende zu Ende
153
Applikationsschicht
abgesicherte Kommunikation auf der Netzwerkschicht
Transportschicht
Netzwerkschicht
Physikalische
Schicht
Abbildung 8.10: Sicherheitsmechanismen auf der Netzwerkschicht.
Auf den ersten Blick mag die Idee, Kommunikationssicherung auf der Netzwerkschicht zu
betreiben, in Anbetracht der skizzierten Dezite problematisch erscheinen, doch es gibt wichtige Anwendungsszenarien fr solche Mechanismen. Auch wenn andere Einsatzmglichkeiten
bestehen, nden Schutzmechanismen auf der Netzwerkschicht derzeit meistens dann Verwendung, wenn entweder der gesamte Verkehr eines Endpunktes kryptographisch geschtzt an eine
bestimmte Zwischenstation bertragen werden soll, oder wenn Daten geschtzt werden sollen,
die von einer Zwischenstation zu einer anderen Zwischenstation transportiert werden. Auf diese Weise knnen ffentliche Netzwerke wie private, abhrsichere Leitungen verwendet werden.
Solche Einsatzformen sind als Virtual Private Networks (VPN) bekannt. Wir werden VPNs in
Kapitel 10 ausfhrlich diskutieren.
Die Vorteile einer Absicherung auf der Netzwerkschicht sind:
Hohe Flexibilitt: Auf der Netzwerkschicht knnen bestimmte Teilstrecken eines Kommunikationsusses, die gesamte Kommunikation zwischen bestimmten (Zwischen-)Stationen
oder Teile dieser Kommunikation kryptographisch geschtzt werden. Andere Mglichkeiten sind umsetzbar und werden praktiziert.
Transparenz: Schutzmechanismen auf der Netzwerkschicht sind transparent fr darberliegende Schichten und mssen daher nicht durch die Anwendungen, Anwendungsprotokolle oder Transportprotokolle untersttzt werden.
Der Schutz auf der Netzwerkschichtebene hat ebenfalls Nachteile:
Nachverfolgbarkeit durch hhere Schichten: Der Schutz einer bestimmten Ende-zu-EndeKommunikation auf Transport- oder Anwendungsschicht kann ber Mechanismen auf der
154
Netzwerkschicht nur schwierig sichergestellt werden, da zum einen eine Rckmeldemglichkeit fehlt und zum anderen keine Kontrollmechanismen vorhanden sind. Somit knnen
darberliegende Schichten diese Mechanismen nur schwierig gezielt einsetzen.
8.3.4 Sicherheit auf der Datenverbindungsschicht

Auch auf der Datenverbindungsschicht gibt es Sicherheitsmechanismen. Wir werden sie im Detail in Kapitel 15 behandeln. Die Datenverbindungsschicht regelt, wie die bertragung zwischen
zwei benachbarten, direkt miteinander verbundenen Stationen abluft. Einer der wichtigsten
Aspekte bei Sicherheitsmechanismen auf der Datenverbindungsschicht ist daher die Authentikation von Stationen. Mechanismen auf der Datenverbindungsschicht stellen beispielsweise
sicher, dass nur authentizierte und autorisierte Benutzer sich ber ein Modem mit einem Netzwerk verbinden knnen. Besonders in den Fokus gerckt ist auch die Absicherung von drahtlosen
lokalen Netzen gegen unbefugte Zugriffe und gegen Abhren. Diese Mechanismen sitzen alle auf
der Datenverbindungsschicht.
Aus Sicht eines Benutzers sticht bei Mechanismen auf dieser Schicht meistens die Authentikation, Autorisation und Zugriffskontrolle hervor. Die Mechanismen auf der Datenverbindungsschicht betreffen nur die Verbindung einer Station zu den direkt ber diese Schicht verbundenen
Maschinen.
Bei der Kommunikation mit einer Maschine auerhalb des eigenen lokalen Netzes ber das
Internet (und manchmal sogar innerhalb des eigenen lokalen Netzes) werden in der Regel ganz
verschiedene Typen von Datenverbindungsschichten verwendet, die allesamt ber unterschiedliche Sicherheitsmechanismen verfgen. Der Transport durch das Netz ber diese verschiedenen
Typen kann vom Sender oder den Zwischenstationen nicht ber ihre jeweilige direkte Kommunikation hinaus beurteilt oder gar gesteuert werden. Daher sind solche Mechanismen nicht
geeignet, Teilstrecken oder gar eine Ende-zu-Ende-Kommunikation zu verschlsseln.
Als Vorteil ist also herauszuheben:
Authentikation, Autorisation und Zugriffskontrolle vor Zugriff auf ein Netzwerk: Sicherheitsmechanismen auf der Datenverbindungsschicht knnen die Netzwerkinfrastruktur vor
unbefugter Benutzung schtzen.
Die Nachteile dieses Ansatzes sind:
Ausschlielich lokaler Schutz: Die Mechanismen auf der Datenverbindungsschicht sichern

nur die Kommunikation mit der jeweils nchsten (Zwischen-)Station und eignen sich nicht
fr den Schutz von lngeren Teilstrecken oder gar Ende-zu-Ende.
8.4 Zusammenfassung
155
Ende zu Ende
Applikationsschicht
Transportschicht
Netzwerkschicht
Physikalische
Schicht
abgesicherte Kommunikation auf der Datenverbindungsschicht
Abbildung 8.11: Sicherheitsmechanismen auf der Datenverbindungsschicht.
8.4 Zusammenfassung
Bei der Kommunikation ber ein Netzwerk knnen Angreifer Informationen mitlesen, verndern und vortuschen oder die Kommunikation unterbrechen. Da das Internet eher ein Netz von relativ autonomen Netzen als ein einzelnes Netz ist, gibt
es viele potentielle Angreifer. In der Praxis ist das Mithren und Manipulieren bertragener Daten auf Endpunkten und Zwischenstationen mglich und technisch nicht
unbedingt aufwendig. Durch kryptographische Schutzmechanismen wie Verschlsselung und Authentikation knnen bis auf die Unterbrechung einer Kommunikationsverbindung Angriffe wirkungsvoll verhindert werden. Es gibt eine ganze Reihe
von Beispielen, wie das Mitlesen und die Manipulation von Nachrichten geschickt
ausgenutzt werden kann, um die IT-Sicherheit zu kompromittieren, wie etwa MACAddress-Spoong, ARP-Spoong, IP-Spoong, eine TCP Sequence Number Attack
oder DNS-Spoong.
Sicherheitsprotokolle und -mechanismen nden sich auf allen Schichten unseres Referenzmodells. Whrend Technologien auf der Applikations- und Transportschicht
meistens dem Ende-zu-Ende-Schutz eines Kommunikationsusses zwischen zwei
Stationen dienen, werden Mechanismen auf der Netzwerkschicht hug eingesetzt,
um den gesamten Verkehr zwischen zwei Vermittlungsstationen oder den gesamten
Verkehr eines Endpunktes zu einer bestimmten Vermittlungsstation zu schtzen. Mechanismen auf der Datenverbindungsschicht nden vor allen Dingen Verwendung, um
unbefugte Zugriffe auf Netzwerke zu verhindern.
156
8.5 bungsaufgaben
Aufgabe 8.1:
Skizzieren Sie mgliche Bedrohungen durch Angreifer bei der Datenbertragung in Netzwerken
und welche Schutzmechanismen Angriffe verhindern knnen.
Aufgabe 8.2:
Erlutern Sie, warum ein Angreifer das Routing in einem Netzwerk manipulieren knnte.
Aufgabe 8.3:
Erklren Sie folgende Begriffe: MAC-Address-Spoong, ARP-Spoong, IP-Spoong, TCP
Sequence Number Attack, DNS-Spoong.
Aufgabe 8.4:
Beschreiben Sie, welche Vor- und Nachteile die Umsetzung von Sicherheitsmechanismen auf
verschiedenen Schichten des Referenzmodells haben, und vergleichen Sie sie.

Aufgabe 8.5:
Diskutieren Sie, inwieweit die Verwendung von Zertikaten bei der Verhinderung von DNSSpoong-Angriffen helfen kann.
Aufgabe 8.6:
Informieren Sie sich ber die genaue Funktionsweise und Umsetzung von Source Routing fr IP.
Gehen Sie dabei insbesondere auf die Unterschiede zwischen Loose Source Routing und Strict
Source Routing ein. Beschreiben Sie im Detail, wie ein Angreifer Source Routing missbrauchen
kann, um das Routing in einem Netz zu manipulieren oder um mit einer geflschten IP-Adresse
zu kommunizieren.
Aufgabe 8.7:
Fhren Sie einige eigene praktische Tests durch und versuchen Sie, durch Mithren und Mitschneiden mit einem Snifng-Tool ein aus dem Internet heruntergeladenes Objekt (beispielsweise ein Bild von einer Website) aufzufangen und anzuzeigen.
Kapitel 9
Firewalls
9 Firewalls
9.1 Der Grundgedanke von Firewalls

Das Internet ist ein Netz von Netzen verschiedenster Institutionen wie beispielsweise Unternehmen, Verbnden, Vereinen und Hochschulen. Das Netzwerk einer Institution, speziell in Unternehmen, wird allgemein auch als Intranet bezeichnet. Das Intranet ist (meistens) mit dem Internet
verbunden, und ber das Internet knnen beliebige an das Netz angeschlossene Rechner miteinander kommunizieren. Wenn also ein Rechner einen Dienst anbietet, so macht es rein technisch
gesehen keinen Unterschied, ob ein PC aus dem Nachbarbro diesen Dienst aufruft oder ob der
Dienst von einem Computer aufgerufen wird, der sich im Hinterzimmer eines heruntergekommenen Etablissements in einem Viertel mit zweifelhaftem Ruf in einer Stadt eines Landes mit
fragwrdigen moralischen Standards bendet. Abbildung 9.1 zeigt diese Gleichbehandlung aller
mit dem Internet verbundenen Rechner.
Aus der Sicherheitsperspektive gesehen gibt es gute Grnde, den Rechner im Nachbarbro,
und generell alle Rechner im Netzwerk der eigenen Institution als etwas vertrauenswrdiger
einzustufen:
Die Rechner im Intranet unterliegen in der Regel den gleichen administrativen Richtlinien
und Regularien.
Die Rechner im Intranet werden in der Regel durch Mitglieder derselben Institution genutzt.
Somit ist also der Zugang zum Intranet im Gegensatz zum Internet bestimmten Zugangskontrollen, sowohl hinsichtlich der verwendeten Gerte als auch der Benutzer, unterworfen.
Auf Rechnern im Intranet kann es bestimmte Dienste geben, die ausschlielich fr Mitglieder der Institution gedacht sind und die aus anderen Netzen als dem Intranet nicht verfgbar
sein mssen. Beispielsweise knnte eine Firma einen Webserver betreiben, auf dem sich fr alle
Mitarbeiter zugngliche interne Webseiten benden, auf die aber von auen nicht zugegriffen
werden soll. Ganz generell sollten Rechner aus dem Internet nicht ohne weiteres in der Lage
sein, Rechner im Intranet auszukundschaften oder mit Malware zu inzieren. Umgekehrt kann
es auf Rechnern im Internet bestimmte Dienste geben, etwa Webseiten auf bestimmten Servern
oder mit Viren inzierte Dateien und Dokumente zum kostenlosen Herunterladen, deren Abruf
von Rechnern aus dem Intranet heraus unterbunden werden soll.
Zusammenfassend ist es also keine gute Idee, die Rechner im Intranet uneingeschrnkt auf das
Internet zugreifen zu lassen und umgekehrt. Pessimisten knnten anmerken, es sei keine gute
158
9 Firewalls
Intranet
Internet
Abbildung 9.1: Internet und Intranet.
Idee, das Intranet berhaupt mit dem Internet zu verbinden. Es gibt tatschlich in einigen Bereichen TCP/IP-basierte Netzwerke, die aus Sicherheitsgrnden nicht an das Internet angeschlossen
sind.
Fr gewhnliche Institutionen und deren Intranets ist es aber meistens unverzichtbar, auf das
Internet und einige der im Internet angebotenen Dienste zuzugreifen und selbst Dienste, etwa
einen Webserver, zu betreiben, auf die aus dem Internet heraus zugegriffen werden kann. Dies
fhrt zur Idee der Firewall, die eine graduelle Kontrolle darber ermglicht, was zwischen Internet und Intranet und umgekehrt erlaubt ist und was nicht.
Eine Firewall sitzt an der Verbindungsstelle von Intranet und Internet und kontrolliert den
Verkehr zwischen beiden Netzen nach festgelegten Regeln. Gem dieser Regeln, auch Policies
genannt, unterscheidet die Firewall zwischen erlaubtem und nicht erlaubtem Verkehr zwischen
den Netzen und unterbindet den unerlaubten Verkehr. Dies ist in Abbildung 9.2 skizziert. Je nach
Gre und Art des Intranets kann eine Firewall eine Vielzahl verschiedener Hard- und Softwarekomponenten umfassen und unterschiedlichste Architekturen aufweisen. Wir werden im Folgenden auf die wichtigsten Typen, Arbeitsweisen und Topologien noch genauer eingehen. Neben
der Kontrolle des Verkehrs besitzen Firewalls weitere wichtige sicherheitsrelevante Funktionen.
So protokollieren die meisten Firewalls einen groen Teil des erlaubten und unerlaubten eingehenden (also vom Internet ins Intranet) und ausgehenden (vom Intranet ins Internet) Verkehrs,
um im Falle eines Angriffs Material fr Untersuchugen zur Verfgung zu haben oder um die
gesammelten Daten automatisch zu analysieren und auf diese Weise frhzeitig Anomalien zu
entdecken. Wir werden solche Techniken in Kapitel 11 nher behandeln.
Durch eine Firewall entsteht im Intranet natrlich kein Paradies, und durch eine Firewall knnen nicht alle Sicherheitsrisiken eliminiert werden. Es bleiben insbesondere folgende Probleme
ungelst:
Bedrohung durch Innentter und legitime Stationen im Intranet: Eine Firewall berwacht
den Verkehr zwischen Internet und Intranet, nicht aber den Verkehr im Intranet selbst.
Daher beschrnkt eine Firewall nicht den Verkehr zwischen Stationen im Intranet. Rechner
im Intranet knnen mit Malware verseucht sein, die an der Firewall vorbei in das Intranet
gelangt, beispielsweise auf einer Diskette, CD-Rom oder auf einem Laptop, der vorher in
einem anderen Netz betrieben wurde. Mitarbeiter einer Firma knnen sich als schwarze
9.2 Komponenten von Firewalls
159
Firewall
Internet
Intranet
Regeln
Abbildung 9.2: Firewall.
Schafe entpuppen und ihren legitimen Zugriff auf das Intranet fr einen Angriff auf andere
Rechner im Intranet missbrauchen.
Bedrohung durch Schlupflcher und Sicherheitslcken: Intranets enthalten manchmal Lcher, durch die ein Angreifer direkten Zugriff auf das Intranet erlangen kann, entweder
an der Firewall vorbei, beispielsweise durch Zugriff ber Modem oder WLAN, durch
Verwendung eines ungesicherten Ethernetanschlusses in einem ffentlich zugnglichen
Bereich oder durch Sicherheitslcken in Design, Implementierung oder den Policies der
Firewall selbst.
Darber hinaus sollten in den allermeisten Fllen nicht alle Mitglieder einer Institution Zugriff
auf alle Daten der Institution haben. Insofern sind auch bei Verwendung einer Firewall weitere
Schutzmechanismen notwendig. In den meisten Fllen erbrigt sich kein einziger Schutzmechanismus durch die Verwendung einer Firewall. Eine Firewall ist ein sinnvoller und notwendiger
weiterer Schutz des Intranet vor Bedrohungen aus dem Internet, nicht mehr, aber auch nicht
weniger.

9.2.1 Paketlter-Firewalls
9.2.1.1 Einfhrung
Zeitgeme Firewalls bestehen aus verschiedenen Komponenten. Der ursprnglichste und am
weitesten verbreitete Typ ist der sogenannte Paketlter. Besonders einfache Firewalls knnen
auch nur aus einem Paketlter bestehen.
Wir haben bereits in Kapitel 7 und besonders in Kapitel 8 gesehen, dass eine Zwischenstation die Headerinformationen aller Pakete, die ber sie geschickt werden, auf allen Schichten
160
9 Firewalls
inspizieren und auch manipulieren kann, und wie umfangreich die Informationen sind, die man
auf diese Weise ber ein Paket erhalten kann. Es ist naheliegend, diese Technik fr Firewalls
einzusetzen.
Typischerweise sind Paketlter in der (oder den) Zwischenstation(en) auf Netzwerkschichtebene integriert, die das Intranet mit dem Internet verbinden, also einem Router. Da jeglicher
Verkehr zwischen Intranet und Internet und umgekehrt zwischen dem Internet und dem Intranet
ber diese Router luft, kann damit tatschlich auch der gesamte Verkehr zwischen den Netzen
auf Paketebene analysiert werden. Es gibt aber auch andere Mglichkeiten, einen Paketlter zu
betreiben, beispielsweise als Bridge auf der Datenverbindungsschicht, die als zustzliches Gert
zwischen dem Router und dem Intranet sitzt.
Paketlter bestehen aus einer oder mehreren Regelketten. Jede der Regelketten besteht aus einer oder mehreren Regeln und einer Default-Aktion. Jede Regel speziziert bestimmte mgliche
Eigenschaften eines Pakets sowie eine Aktion. Wenn ein Paket die in einer Regel spezizierten
Eigenschaften besitzt, spricht man von einem Match. Der Paketlter bearbeitet ein eingehendes
Paket nach dem in Abbildung 9.3 gezeigten Schema. Das Paket wird zunchst einer bestimmten Regelkette zugeordnet. Die Regeln der Regelkette werden nun in der durch die Regelkette
vorgegebenen Ordnung durchlaufen und es wird jeweils berprft, ob die Regel und das Paket
einen Match bilden. Ist dies der Fall, wird das Durchlaufen der Regelkette abgebrochen und die
in der Regel vorgegebene Aktion ausgefhrt. Mgliche Aktionen, die in einer Regel festgelegt
sein knnen, sind das Weiterleiten des Pakets (berprfung des Pakets mit positivem Ergebnis
abgeschlossen), das Verwerfen und Lschen des Pakets (berprfung des Pakets mit negativem
Ergebnis abgeschlossen) oder der Sprung in eine andere Regelkette (berprfung des Pakets
noch nicht abgeschlossen und Fortsetzung der Bearbeitung erfolgt in einer anderen Regelkette,
beginnend mit der ersten Regel dieser Kette). In einigen Fllen werden die Pakete im Paketlter
auch modiziert (etwa durch eine NAT-Funktion im Paketlter). Auch dies kann in einer Regel
angegeben sein. Durchluft das Paket die gesamte Regelkette, ohne einen Match mit einer Regel
zu bilden, wird die fr die Regelkette angegebene Default-Aktion durchgefhrt.
9.2.1.2 Typische Kongurationen von Paketltern
Es gibt im Prinzip zwei verschiedene Mglichkeiten, die Regelketten in Paketlter zu kongurieren:
Erlaube alles, was nicht explizit verboten ist: Die Regeln in den Ketten spezizieren unerwnschten Verkehr. Pakete, die mit einer der Regeln matchen, werden verboten. Pakete,
die mit keiner der Regeln gematcht werden knnen, werden erlaubt (Default-Accept).
Verbiete alles, was nicht explizit erlaubt ist: Die Regeln in den Ketten spezizieren erlaubten Verkehr. Pakete, die mit einer der Regeln matchen, werden durchgelassen. Pakete, die
mit keiner der Regeln gematcht werden knnen, gelten als unerwnscht und werden nicht
weitergeleitet (Default-Deny).
Natrlich sind auch Mischformen dieser Techniken anzutreffen, d.h. es gibt Firewalls mit unterschiedlichen Default-Regeln in verschiedenen Ketten.
Obgleich man mit beiden Techniken prinzipiell die gleiche Filterung erreichen kann, ist die
Default-Deny-Methode in der Regel als sicherer einzustufen, da Verkehr, auf den keine Regel
161
Regel 1
Regel 2
Ausfhrung der
Aktion der Regel:
- Paket verwerfen
- Paket weiterleiten
- Sprung in andere
Regelkette
Regel 3
...
Paket
Regel i
erster
Match
...
Regel n
Default-Aktion
Regelkette
Abbildung 9.3: Arbeitsweise eines Paketlters.
zutrifft, verworfen wird. Allerdings muss man bei der Spezizierung der Regeln, welche Pakete durchgelassen werden, groe Vorsicht walten lassen, um nicht unbeabsichtigt auch eigentlich
unerwnschten Verkehr durch die Firewall zu lassen. Ein weiterer wichtiger Punkt ist die Reihenfolge der Regeln in einer Regelkette. Das Filterergebnis einer Regelkette hngt stark von der
Reihenfolge der Regeln ab. Als konkretes Beispiel betrachten wir die zwei Regeln:
(a) Verbiete jeglichen Verkehr zu IP-Zieladresse x.
(b) Erlaube TCP-Verkehr zu TCP-Zielport 80.
Werden die Pakete in der Reihenfolge erst (a), dann (b), bearbeitet, so werden TCP-Segmente zu
IP-Zieladresse x und TCP-Zielport 80 durch Regel (a) verworfen und Regel (b) kommt fr das
Paket nicht zum Einsatz. Erfolgt die Bearbeitung aber in der Reihenfolge erst (b), dann (a), so
wird das Paket durch Regel (b) durchgelassen und Regel (a) wird nicht mehr beachtet.
Bei der Aufstellung der Regeln einer Firewall muss man also grte Vorsicht walten lassen.
Viele Firewalls untersttzen die Benutzer, indem sie eine einfach zu bedienende Benutzerschnittstelle zur Verfgung stellen, welche die Erstellung der Regeln vereinfacht.
9.2.1.3 Statische vs. dynamische Paketlter
Regeln spezizieren Eigenschaften. Aus der Headerinformation der Pakete auf den verschiedenen Schichten lassen sich umfangreiche Informationen aus den Paketen gewinnen. In der Regel
162
9 Firewalls
beschrnken sich Paketlter auf die Verwendung von Protokollinformationen von Datenverbindungsschicht, Netzwerkschicht und Transportschicht. Obwohl theoretisch auch Zugriff auf die
Daten der Anwendungsschicht mglich sind, ist dies in der Praxis nicht unbedingt sinnvoll, da
auf Anwendungsebene eine wesentlich feinere und einfachere Filterung durch Verwendung von
Application-Level-Gateways mglich ist (siehe 9.2.2). Die auf der Transportschicht verfgbaren Headerdaten werden aber verwendet, um zwischen verschiedenen Anwendungen anhand des
verwendeten Transportprotokolls und der Portnummern zu differenzieren und auf diese Weise
bestimmte Anwendungen zu sperren und andere zu erlauben. So kann etwa durch das Sperren
von Paketen, die an TCP-Port 80, dem Standardport fr HTTP-Server, gerichtet sind, die Kommunikation mit HTTP-Servern, die auf diesem Port arbeiten, unterbunden werden.
Im (heute hugsten) Fall eines Routers in einem TCP/IP-basierten Netzwerks ndet man
folgende Eigenschaften von Paketen in Filterregeln mit am hugsten:
Interface, auf welchem das Paket in den Paketlter gelangt ist.
IP-Zieladresse und IP-Quelladresse des Pakets (oft in Form von Adressbereichen speziziert).
Das verwendete Transportprotokoll (TCP/UDP).
Quell- und Zielport auf der Transportschicht.
Darber hinaus spielen auch andere Attribute wie etwa bestimmte Flags im TCP-Header hug eine Rolle. Auch Uhrzeit und Datum knnen manchmal in die Entscheidung miteinbezogen
werden. In den meisten Paketltern sind die mglichen Regeln exibel und erlauben unter anderem die Angabe von Bereichen, in welche bestimmte Attribute des Pakets fallen mssen, um
mit der Regel zu matchen, beispielsweise bei IP-Adressen, bei denen hug die Angabe einer
Subnetzmaske mglich ist.
Da bestimmte Anwendungen bestimmte Transportprotokolle und meistens serverseitig bestimmte festgelegte Portnummern verwenden, knnen durch Paketlter bestimmte Anwendungen effektiv blockiert werden. Durch die Verwendung mehrerer Eigenschaften in einer Regel ist
es mglich, sehr detaillierte Einstellungen vorzunehmen, was erlaubt ist und was nicht.
Regeln mit sehr feiner Granularitt knnen sogar genau festlegen, welcher Dienst von welchem Rechner aus verwendet werden kann oder nicht. Durch Eingabe von IP-Quelladresse, IPZieladresse, des Transportprotokolls und den entsprechenden Ports kann beispielsweise eine spezische Anwendung zwischen zwei Rechnern erlaubt oder blockiert werden.
Es gibt zwei Arten von Paketltern, nmlich statische und dynamische. Bei einem statischen
Paketlter hngt die Entscheidung des Filters, was mit einem Paket geschieht, ausschlielich von
dem betrachteten Paket selbst ab. Es werden keinerlei andere Informationen zur Bearbeitung herangezogen, der Paketlter ist zustandslos. Statische Paketlter sind einfach realisierbar, weisen
jedoch einige Schwchen auf. Um diese zu erkennen, wollen wir etwas tiefer in die technischen
Details einsteigen und untersuchen, welche Regeln in einer Kette notwendig sind, um einem
Rechner im Intranet (IP-Adresse x, beliebiger TCP-Port) zu ermglichen, zu Webservern im Internet eine Verbindung aufzubauen und zu kommunizieren, genauer: HTTP-Verkehr (Port 80)
ber TCP zu erlauben. Dabei gehen wir von einem Default-Deny in der konsultierten Regelkette
163
Internet
Intranet
SYN
Zeit
SYN ACK
ACK
OK
SYN
x
BLOCKIERT
Abbildung 9.4: Unterscheidung zwischen eingehenden und ausgehenden TCP-Verbindungen beim Paketlter.
aus. Wie wir ja schon aus Sektion 7.3.4.1 wissen, werden bei TCP aufgrund des Verbindungsaufbaus, der Besttigungen fr erhaltene Daten und des Verbindungsabbaus immer Segmente
in beide Richtungen ausgetauscht. Das ist auch dann der Fall, wenn die eigentlichen Nutzdaten
unidirektional sind. Alle TCP-Segmente der Verbindung mssen mit Regeln in der konsultierten
Regelkette der Firewall matchen. Daher bentigen wir zwei Regeln, um die gewnschte TCPVerbindung zu ermglichen:
Erlaube TCP-Segmente von IP-Quelladresse x, TCP-Quellport beliebig zu beliebigen Rechnern im Internet auf TCP-Zielport 80.
Erlaube TCP-Segmente von beliebigen Rechnern im Internet von TCP-Quellport 80 zu
IP-Zieladresse x, TCP-Zielport beliebig.
Diese beiden Regeln sind jedoch noch zu grob strukturiert und ffnen eine Sicherheitslcke.
Ein Angreifer irgendwo im Internet knnte von TCP-Port 80 aus versuchen, eine TCP-Verbindung zu einem beliebigen Port auf Rechner x aufzubauen. Die Firewall wrde die dabei versendeten Pakete aufgrund der obigen Regeln durchlassen und es dem Angreifer so eventuell
ermglichen, eine TCP-Verbindung mit einem beliebigen Port auf dem Rechner x herzustellen,
was natrlich verhindert werden soll.
Genau betrachtet muss also verhindert werden, dass Verbindungen vom Internet ins Intranet
aufgebaut werden, whrend umgekehrt der Aufbau einer Verbindung vom Intranet ins Internet
mglich sein soll.
Bei TCP kann dies mit einem statischen Paketlter tatschlich bewerkstelligt werden, indem
weitere Merkmale der TCP-Segmente in Betracht gezogen werden, nmlich die beim Verbindungsaufbau verwendeten Flags, speziell das SYN-Flag. Wie bereits in 7.3.4.1 erwhnt, beginnt
164
9 Firewalls
der Three-Way-Handshake zwischen dem Client und dem auf eingehende Verbindungen wartenden Server mit einem vom Client ausgesendeten TCP-Segment, bei dem das SYN-Flag gesetzt,
das ACK-Flag aber nicht gesetzt ist. Ein Segment, bei dem das SYN-Flag gesetzt ist, das ACKFlag aber nicht, charakterisiert eindeutig das erste Segment beim Verbindungsaufbau. Werden
also eingehende Segmente vom Internet ins Intranet mit gesetztem SYN-Flag und nicht gesetztem ACK-Flag blockiert, kann effektiv der Aufbau von TCP-Verbindungen vom Internet ins
Intranet unterbunden werden. Abbildung 9.4 zeigt, wie man diese Technik nutzen kann, um bei
einem statischen Paketlter vom Intranet ins Internet aufgebaute Verbindungen zu ermglichen
und Verbindungen vom Internet ins Intranet zu blockieren. Die oben prsentierten Regeln mssen
also noch um eine Regel ergnzt werden:
Verbiete TCP-Segmente von beliebigen Rechnern im Internet von TCP-Quellport 80 zu
IP-Zieladresse x, TCP-Zielport beliebig, wenn das SYN-Flag gesetzt ist, das ACK-Flag
aber nicht.
Erlaube TCP-Segmente von IP-Quelladresse x, TCP-Quellport beliebig zu beliebigen Rechnern im Internet zu TCP-Zielport 80.
Erlaube TCP-Segmente von beliebigen Rechnern im Internet von TCP-Quellport 80 zu
IP-Zieladresse x, TCP-Zielport beliebig.
Damit ist ein Verbindungsaufbau vom Internet ins Intranet unmglich geworden. Doch es
bleiben Sicherheitsprobleme bestehen, die nicht eliminiert werden knnen. Nach dem Aufbau
der TCP-Verbindung besteht zwischen Client und Server kein Unterschied mehr. Daher kann
nach dem Aufbau der Verbindung anhand eines einzelnen TCP-Segments in einem statischen
Paketlter nicht entschieden werden, wer die Verbindung aufgebaut hat, oder auch, ob berhaupt
ein Verbindungsaufbau erfolgte.
Dies kann sich ein Angreifer wiederum mglicherweise zunutze machen. Von irgendeinem
mit dem Internet verbundenen Rechner aus knnte er, ohne dass tatschlich eine Verbindung
aufgebaut wurde, ein TCP-Segment ohne gesetztes SYN-Flag flschen, das von Port 80 dieses
Rechners stammt und an einen Port auf Rechner x gerichtet ist. Die Firewall wrde ein solches Segment aufgrund der obigen Regeln durchlassen. Zwar besteht zwischen dem Rechner des
Angreifers und dem Rechner x keine TCP-Verbindung, aber der Rechner im Intranet knnte mit
einer entsprechenden Fehlermeldung reagieren, die dem Angreifer Rckschlsse auf das Intranet
erlaubt, oder eventuell sogar den Rechner x in seiner Funktion beeintrchtigt. Dies soll natrlich
auch verhindert werden. Bei einem statischen Paketlter ist dies jedoch nicht mglich.
Noch schlimmer ist die Situation bei UDP, wo bekanntlich berhaupt kein Verbindungsaufbau erfolgt. Kommunizieren zwei Anwendungen durch den gegenseitigen Austausch von UDPDatagrammen, so kann ein statischer Paketlter nicht so konguriert werden, dass ausgehende
Verbindungen mglich, eingehende Verbindungen aber unmglich sind, da es im Gegensatz zu
TCP keine Merkmale gibt, an denen man das erste ausgetauschte Paket erkennen kann.
Diese Limitationen haben dazu gefhrt, dass in der Praxis heute hauptschlich dynamische
Paketlter eingesetzt werden. Bei einem dynamischen Paketlter kann die Entscheidung des Filters, was mit einem Paket geschieht, von vorangegangenen Paketen abhngen der Paketlter
ist zustandsbehaftet. Die Frage, was mit einem Paket geschieht, hngt bei einem dynamischen
165
Filter also vom Zustand und dem jeweiligen Paket ab. In der Praxis registrieren die meisten dynamischen Paketlter den Aufbau einer TCP-Verbindung oder das erste UDP-Datagramm, welches zwischen zwei Maschinen ausgetauscht werden soll, und treffen anhand dieses Pakets eine
Entscheidung, ob diese Verbindung bzw. der Informationsuss erlaubt oder unerwnscht sind.
Diese Entscheidung wird dann auch auf alle danach eintreffenden Pakete der Verbindung oder
des Flusses angewendet (bei Informationsssen ber UDP werden dabei meistens auch Pakete
in die umgekehrte Richtung erlaubt). Durch diese Technik ist das Flschen von Datagrammen
oder Segmenten zum berwinden der Firewall nicht mehr ohne weiteres mglich. Entsprechende Regeln, um Verbindungen vom Intranet ins Internet ber HTTP (und sonst nichts) zu erlauben,
knnten daher lauten:
Erlaube neue TCP-Verbindungen von IP-Quelladresse x, TCP-Quellport beliebig zu beliebigen Rechnern im Internet, TCP-Zielport 80.
Erlaube beliebige Pakete, die zu einer bereits bestehenden Verbindung gehren.
Verwirf alle anderen Pakete.
Tabelle 9.1 vergleicht nochmals die Merkmale von statischen und dynamischen Paketltern.
In der Regel nden in der Praxis heute dynamische Paketlter Verwendung, da deren Vorteile ihre Nachteile klar berwiegen. Die Hauptnachteile eines dynamischen Paketlters liegen
im Aufwand fr die Speicherung aktueller Zustnde fr die einzelnen Verbindungen bzw. Informationssse. Da ein dynamischer Paketlter die Zustnde der einzelnen Verbindungen kennen
muss, ist es nicht einfach mglich, zum Load Balancing oder beim Ausfall einer Firewall einfach
von einer Maschine auf eine andere Maschine umzuschalten. Solche Probleme sind jedoch durch
bereits in anderen Bereichen eingesetze und erprobte Techniken und Verfahren in den Griff zu
bekommen.
9.2.1.4 Probleme und Grenzen von Paketltern
Paketlter sind ein mchtiges Werkzeug, um den Verkehr zwischen zwei Netzen zu kontrollieren,
protokollieren, ltern und gegebenenfalls auch zu verndern. Trotzdem besitzen Paketlter eine
Reihe von Limitationen, die zu Sicherheitslcken fhren knnen:
Keine benutzerspezische oder anwendungsspezische Filterung: Paketlter sind darauf
beschrnkt, statisch oder dynamisch Informationen aus den bermittelten Paketen zu verwenden, um Entscheidungen ber die Weiterleitung eines Pakets zu treffen. Damit ist in
der Regel nur die IP-Adresse des Intranet-Benutzers bekannt, nicht aber seine Identitt
oder welche Anwendung die Pakete erzeugt hat. Selbst bei Einzelplatzsystemen ist eine
eindeutige Zuordnung zwischen Benutzern und IP-Adressen in der Regel problematisch
(Verwendung von DHCP, NAT, Arbeitsplatzpools) und eine Zuordnung von Paketen zu
einzelnen Anwendungen nur schwer mglich.
Verwendung von Transportprotokollinformationen zur Applikationsidentikation: Die Verwendung bestimmter Portnummern fr bestimmte Anwendungen ist eine reine Konvention. Im Prinzip sind die verwendeten Ports aber frei whlbar. Es gibt keinen technischen
166
9 Firewalls
Merkmal
statischer Filter
dynamischer Filter
Charakteristik
Die Entscheidung des Filters, was mit einem Paket geschieht, hngt nicht
von vorangegangenen Paketen ab (zustandslos).
Kann bei UDP-Streams
nicht unterscheiden, ob das
erste Paket von innen nach
auen ging oder umgekehrt.
Geflschte TCP-Segmente
von auen knnen einfach
durch die Firewall gelangen
und so Sicherheitslcken
ffnen, da keine Information ber bestehende
Verbindungen vorliegt.
Sehr einfach, da keine Information ber vorangegangene Pakete oder Verbindungen gespeichert werden
muss.
Anforderungen
entsprechend gering.
Einfach realisierbar.
Die Entscheidung des Filters, was mit einem Paket

geschieht, kann von vorangegangenen Paketen abhngen (zustandsbehaftet).
Kann bei UDP-Streams unterscheiden, ob das erste Paket von innen nach auen
ging oder umgekehrt.
TCP-Segmente, die nicht zu
existierenden, erlaubten Verbindungen gehren, werden
verworfen.
Mglichkeiten UDP
Mglichkeiten TCP
Umsetzung
Hardware
Redundanz/Load Balancing
Komplizierter, da Information ber vorangegangene Pakete oder Verbindungen gespeichert werden muss.
Anforderungen
entsprechend hoch.
Schwierig realisierbar, da
Zustandsinformation
von
Verbindungen
verfgbar
sein muss.
Tabelle 9.1: Statische und dynamische Paketlter im Vergleich.
Grund, warum HTTP nicht auch auf anderen TCP-Ports als Port 80 funktioniert, und tatschlich laufen einige Server ganz bewusst auf anderen Ports (etwa da mehrere HTTPServices unter einer Adresse erreichbar sind). Damit kann die Blockierung einer Anwendung ber Portnummern im Paketlter umgangen umgangen werden, wenn eine andere
Portnummer verwendet wird. Eine weitere Schwierigkeit stellt die durch das IP-Protokoll
mgliche Fragmentierung von Paketen (siehe 7.3.3) dar, da bei der Aufteilung eines IPPakets in mehrere Fragmente die Headerinformation der darberliegenden Protokolle nicht
mehr in allen Fragmenten erhalten ist.
Applikationen mit vernderlichen Portnummern: Es gibt Anwendungen, bei denen im Verlauf der Anwendung spezische Transportprotokolle und Ports erst ausgehandelt werden,
167
ber die dann spter ein Datenaustausch erfolgen soll. Ein Beispiel hierfr ist FTP. Gegenwrtig treten hier besonders im Bereich Multimediakommunikation Probleme auf, speziell
bei VoIP.
Protocol Tunneling und verschlsselte Kommunikation: Bestimmte Protokolle erlauben es,
andere Protokolle zu tunneln, also die Daten anderer Protokolle in die Datenpakete des
eigenen Protokolls einzubetten, hnlich wie es die Protokolle einer Schicht mit den Daten
tun, die sie von einer darberliegenden Schicht erhalten haben. Wird ein solcher Tunnel
verwendet, dann kann es fr Paketlter schwierig sein, die tatschlich verwendeten Protokolle zu identizieren. Noch schlimmer wird es, wenn die Pakete verschlsselt sind. Paketlter sind nicht in der Lage, verschlsselte Pakete zu dechiffrieren. Konsequenterweise
kann daher die Verschlsselung von Paketen dazu fhren, dass die Protokollinformationen
einiger Schichten nicht lesbar sind. Dieses Problem ist bei Paketltern besonders ausgeprgt, lsst sich aber auch mit anderen Firewallmechanismen nicht wirklich in den Griff
bekommen. Wir werden es gleich in Abschnitt 9.4.3 noch genauer betrachten.
9.2.1.5 Network Address Translation

Wir hatten schon in Abschnitt 7.3.3.4 kurz erwhnt, dass es verschiedene IP-Adressen gibt, die
ausschlielich zur Verwendung in privaten Netzen gedacht sind. Oftmals werden in einem Intranet solche privaten Adressen verwendet. Mit einer privaten Adresse ist kein direkter Zugriff auf
das Internet mglich. Da diese privaten Adressen keinem Netzwerk fest zugeordnet sind, knnen
sie durch das ffentliche Netz nicht geroutet werden. Wenn ein Rechner mit privater IP Dienste im Internet trotzdem verwenden will, gibt es verschiedene Mglichkeiten, wie dies realisiert
werden kann. Eine Variante ist die Verwendung von Application-Level-Gateways mit privater
und ffentlicher IP-Adresse. Solche Gateways werden wir im nchsten Abschnitt dieses Kapitels
nher kennenlernen.
Doch auch auf Paketlterebene ist es mglich, Maschinen mit privater IP-Adresse den Zugang
zu ffentlichen Netzen ber UDP und TCP zu ermglichen, nmlich durch Network Address
Translation (NAT) [RFC 3022] [RFC 2663]. Gerade in kleinen Netzen ist die NAT-Funktion
in der (Paketlter-)Firewall integriert. Im Folgenden werden wir nher untersuchen, wie NATs
funktionieren und welche Bedeutung ein NAT fr die Sicherheit hat. In der Literatur wird manchmal zwischen Network Address Translation und Network Address Port Translation (NAPT) unterschieden. In unserem Kontext werden wir diese Unterscheidung nicht treffen, sondern alle
Methoden unter dem Begriff Network Address Translation zusammenfassen.
Abbildung 9.5 zeigt die grundlegende Funktion eines NAT. Im Intranet einer Institution (links)
werden private IP-Adressen verwendet. Im Intranet dargestellt sind zwei Rechner mit privaten
IP-Adressen A und B. A und B routen Ihren Internet-Verkehr ber eine Firewall/NAT-Maschine,
die im privaten Netz unter der IP-Adresse C erreichbar ist. Um berhaupt ber ffentliche Netze
kommunizieren zu knnen, muss der Betreiber des privaten Institutionsnetzes auch ber (mindestens) eine ffentliche IP-Adresse verfgen. Im Folgenden gehen wir der Einfachheit halber von einer ffentlichen Adresse aus. Diese IP-Adresse N ist dem ffentlichen Interface der
Firewall/NAT-Maschine zugeordnet.
168
9 Firewalls
Quelle A:x
Ziel D:y
NAT
Quelle N:z
Ziel D:y
Quelle D:y
Ziel A:x
NAT
Quelle D:y
Ziel N:z
NAT bersetzt Adressen gem

(dynamischer) NAT-Bindings
(Bindungen).
Bindings werden (meistens)
durch ausgehenden Verkehr erstellt.
NAT-Binding
A:x <> N:z
privater IP-Addressbereich,
private Adressen A, B, C
Internet
NAT N,
ffentliche Adresse N
private Adresse C
B
Abbildung 9.5: Grundlegende Funktionsweise von Network Address Translation.
Da private IP-Adressen in ffentlichen Netzen nicht geroutet werden knnen, ersetzt die NATMaschine bei ausgehenden IP-Paketen die privaten Quelladressen der jeweiligen Rechner im
Intranet, also etwa A oder B, durch die ffentliche Adresse N. Dies geschieht transparent fr
die Rechner im Intranet und auch fr die Maschinen im Internet, mit denen kommuniziert wird.
Entsprechend adressieren diese Maschinen ihre Antworten an die Adresse N. Die NAT-Maschine
muss analog die eingehenden Pakete untersuchen und die Zieladresse N durch die tatschliche
Zieladresse A oder B ersetzen.
Ein NAT ersetzt also bei ausgehenden Paketen die von den Rechnern verwendeten internen,
privaten IP-Adressen durch eine externe, ffentliche IP-Adressen und umgekehrt.
Dabei mssen Pakete, die zu gleichen oder zusammengehrigen Informationsssen (Hinund Rckrichtung) gehren, durch das NAT jeweils gleich bersetzt werden, sonst wrden weder UDP noch TCP funktionieren. Auerdem muss die NAT-Maschine die eingehenden Pakete
irgendwie eindeutig den jeweiligen Verbindungen oder Informationsssen den Rechnern im Intranet zuordnen knnen. Wie wir bereits aus Abschnitt 7.3.4.1 wissen, ist jede TCP-Verbindung
eindeutig durch das Tupel IP-Quelladresse, IP-Zieladresse, TCP-Quellport und TCP-Zielport
charakterisiert. Diese Eindeutigkeit muss bei der bersetzung in einem NAT ebenfalls gewahrt
bleiben.
Alleine durch bersetzung der IP-Adressen ist dies nicht mglich: Wenn Rechner A und B
(zufllig) gleichzeitig je eine TCP-Verbindung von Port 45678 zu Rechner C Port 80 aufbauen
wrden, wre die Eindeutigkeit allein durch bersetzung der IP-Adresse nicht zu gewhrleisten.
Daher werden bei der NAT-bersetzung die Portnummern von TCP und UDP miteinbezogen, so dass eine eindeutige Zuordnung sowohl fr TCP als auch fr UDP gewhrleistet werden
kann. Ist die entsprechende Kombination fr eine Verbindung bereits belegt, knnen die intranetseitigen Portnummern ebenfalls analog zu den IP-Adressen durch andere Portnummern ersetzt
werden. Bei TCP-Verbindungen, die vom Intranet in das Internet aufgebaut werden, ist die Situation besonders einfach, da die NAT-Maschine beim Empfang des ersten Pakets des Three-WayHandshakes eine entsprechende eindeutige Zuordnung treffen und speichern kann. In der obigen
Abbildung ist zu sehen, dass Maschine A von Port x aus eine Verbindung betreibt, die NATMaschine ersetzt A durch N und ersetzt die Portnummer x durch die Portnummer z. Kommen
169
Pakete aus dem Internet fr N:z, so wird N:z analog durch A:x ersetzt und das Paket an A weitergeleitet. Die entsprechende bersetzungsregel, die zur Anwendung kommt, ist als NAT-Binding
bekannt. Dieses Binding wird auf ausgehende Pakete angewendet und entsprechend auch auf die
eingehenden Pakete, es wird also sowohl auf den Informationsuss vom Intranet ins Internet als
auch auf den zugehrigen Informationsuss vom Internet ins Intranet angewendet.
Ein NAT funktioniert, solange die Eindeutigkeit der bersetzung gewhrleistet wird. Je nachdem, wie die Bindung bei der bersetzung vorgenommen wird, unterscheidet man folgende
NAT-Typen:
Symmetrisches NAT: Das Paket wird anhand von IP-Quelladresse, IP-Zieladresse, Transportprotokoll, Quellport des Transportprotokolls und Zielport des Transportprotokolls einer Verbindung bzw. einem Informationsuss zugeordnet. Anhand dieser Zuordnung wird
bestimmt, welche bersetzung vorzunehmen ist. Die bersetzungstabelle hat also schematisch folgende Form:
<interne private IP-Adresse, interner Port, extern verwendete IP-Adresse, extern
verwendeter Port, IP-Adresse des Kommunikationspartners im Internet, Port des
Kommunikationspartners im Internet, Transportprotokoll>
Cone NAT: : Bei Cone NATs sind die IP-Adressen und Ports der externen Kommunikationspartner fr die Bindings irrelevant. Es kommt nur auf die jeweiligen internen Adressen
und Ports an. Jedes Paket von (zu) einer Intranet-Maschine mit IP-Adresse A, Port x wird
fest auf IP-Adresse N Port z bersetzt, und zwar unabhngig von der IP-Zieladresse dem
Zielport bei ausgehenden bzw. der IP-Quelladresse und dem Quellport bei eingehenden
Paketen. Die bersetzungstabelle hat also schematisch folgende Form:
<interne private IP-Adresse, interner Port, extern verwendete IP-Adresse, extern
verwendeter Port, Transportprotokoll>
Es gibt verschiedene Arten, wie diese Bindings zustande kommen knnen. Natrlich knnen
entsprechenden Bindings im NAT geschaffen werden, bevor die entsprechenden Verbindungen
oder Informationssse tatschlich aktiv werden. Dies ist beispielsweise manuell oder durch
Verwendung bestimmter Protokolle mglich. Gerade bei Informationsssen und Verbindungen,
die von auen nach innen initiiert werden, ist dies insofern sinnvoll, als das NAT bei einem
eingehenden Paket sonst keine ausreichenden Informationen hat, wie mit dem Paket verfahren
und wohin es weitergeleitet werden soll.
Verbindungen und Informationssse, die aus dem Intranet initiiert werden, sind dagegen
leicht zu handhaben. Vereinfacht gesprochen wird beim ersten ausgehenden Paket eines solchen
Informationsusses vom NAT ein Binding erstellt, sofern noch keines vorhanden ist. Fr die entsprechende bersetzung ist die interne IP-Adresse und der interne Port durch das Paket bereits
vorgegeben, ausgehend kann das NAT eine noch nicht belegte Kombination whlen.
Whrend bei einem symmetrischen NAT aus die Bindungen fr jede Verbindung bzw. Informationsuss und die Rckrichtung einzeln festgelegt werden, kann bei Cone NATs eine Bindung
auch fr andere Informationssse verwendet werden, was insbesondere fr UDP wichtig sein
170
9 Firewalls
Quelle A:x
Ziel D:y
NAT
Quelle N:z
Ziel D:y
NAT-Binding
A:x <> N:z
privater IP-Addressbereich,
private Adressen A, B, C
Internet
D
NAT N,
ffentliche Adresse N
private Adresse C
Durch NAT-Binding mgliche bersetzung
Full Cone
E
NAT-Typ
Restricted Cone Port Restricted Cone
Quelle D:y
Ziel A:x
Quelle D:y
Ziel N:z
OK
OK
OK
Quelle D:w
Ziel A:x
Quelle D:w
Ziel N:z
OK
OK
wird verworfen
Quelle E:y
Ziel A:x
Quelle E:y
Ziel N:z
OK
wird verworfen
wird verworfen
Abbildung 9.6: Full Cone, Restricted Cone und Port Restricted Cone NATs.
kann. In einem Full Cone NAT wird eine existente Bindung fr alle ein- und ausgehenden Pakete angewendet. Dies bedeutet, wenn eine Bindung der internen IP-Adresse A und Port x an die
externe Adresse N und Port z fr UDP vorhanden ist, wird jedes an N Port z gerichtete UDPPaket auf A Port x bersetzt und weitergeleitet. Jeder beliebige Rechner im Internet kann also ein
UDP-Paket an N Port z schicken und so A Port x ber UDP kontaktieren. Es gibt Cone NATs,
die das Binding an die extern verwendete IP-Adresse (Restricted Cone NAT) oder den extern
verwendeter Port Port Restricted Cone NAT koppeln [RFC 3489] (siehe Abbildung 9.6).
Cone NATs sind sinnvoll, da symmetrische NATs groe Probleme bereiten, wenn durch zwei
NATs hindurch ein Informationsuss zwischen zwei Maschinen aufgebaut werden soll, wie es etwa fr VoIP notwendig sein kann. Wir wollen diese Aspekte hier jedoch nicht vertiefen, sondern
auf die Sicherheitsaspekte von NATs eingehen.
Zunchst ist bei einem NAT der Aspekt der Anonymisierung des Datenverkehrs zu nennen.
Der externe Kommunikationspartner sieht nur die NAT-Adresse und hat zumindest auf Paketebene keine direkte Mglichkeit, die private IP-Adresse des Kommunikationspartners herauszunden. Es ist also nicht mglich, direkt herauszunden, welcher Rechner aus dem privaten
Adressbereich die Verbindung aufgebaut hat.
Symmetrische NATs blockieren (bei korrekter Konguration) mehr oder weniger automatisch
eingehende Verbindungen. Dies ist ein schner Nebeneffekt. Speziell bei der Verwendung in
Privathaushalten mag dies als Paketlter vielleicht schon fast ausreichen. Allerdings ist bei Cone
NATs Vorsicht angebracht. Ein Full Cone NAT ffnet Ports bei bestehendem Binding vollstndig
nach auen.
Zusammenfassend kann ein NAT abhngig von der konkreten Art der bersetzung die Sicherheit der dahinterliegenden Rechner im privaten IP-Adressbereich in einigen Fllen tatschlich
171
172.16.2.20
10.2.4.37
172.16.2.5
10.2.4.1
172.16.2.0/24
10.2.4.0/24
Abbildung 9.7: Testnetz fr den praktischen Test eines Linux-Paketlters.

eingehende
Pakete
Wird Paket
geroutet ?
ja
ausgehende
Pakete
FORWARD
chain
nein
INPUT
chain
OUTPUT
chain
lokaler Prozess
Abbildung 9.8: Linux Netlter-Architektur.
erhhen. Es ist jedoch nicht in erster Linie als Sicherheitsmechanismus zu verstehen. Im professionellen wie auch im privaten Einsatz empehlt sich (und das ist sehr moderat ausgedrckt) der
zustzliche Einsatz einer Firewall, zumindest aber eines richtigen Paketlters.
9.2.1.6 Paketlter unter Linux
Im Folgenden werden wir uns mit einem praktischen Beispiel beschftigen, nmlich dem Betrieb
eines Paketlters unter Linux. Hierzu betrachten wir das in Abbildung 9.7 skizzierte einfache
Szenario.
Es basiert auf dem Netzwerk, das wir bereits in Kapitel 7 fr praktische Tests herangezogen
haben. Netz 172.16.2.0/24 stellt ein ffentliches Netz dar, whrend Netz 10.2.4.0/24 das private Netz einer Institution ist. Diese Institution betreibt ebenfalls den Router, der beide Netze
miteinander verbindet. Im ffentlichen und im privaten Netz bendet sich je ein Rechner. Die
Konguration der Rechner erfolgt unter Linux wie in Abschnitt 7.4 dargestellt.
Auf dem Router soll nun ein Paketlter betrieben werden. Linux bietet standardmig eine
Paketlterfunktion. Die Architektur dieses sogenannten Netlters ist in Abbildung 9.8 skizziert.
172
9 Firewalls
Detaillierte Informationen zu Netlter nden sich unter [NF-Web]. Es gibt drei verschiedene
Regelketten, je eine fr ein- und ausgehende Pakete fr bzw. von der Maschine selbst und eine Kette fr Pakete, die durch den Rechner geroutet werden. Eingehende Pakete, die fr den
Rechner selbst bestimmt sind, durchlaufen eine Regelkette (englisch Chain) mit dem Namen
INPUT und werden (falls sie durchgelassen werden) an den entsprechenden Prozess weitergegeben, fr den sie bestimmt sind. Ausgehende Pakete, die vom System selbst erzeugt wurden,
durchlaufen die Regelkette OUTPUT. Pakete, die geroutet werden, also ber ein Interface in den
Rechner gelangen und auf einem (anderen) Interface weitergeschickt werden sollen, durchlaufen
die FORWARD-Kette. Es ist ebenfalls mglich, benutzerdenierte Ketten anzulegen und diese
als Aktion, im Linux-Jargon Target, von Regeln in anderen Ketten anzugeben, so dass diese
Kette bei einem Match mit der Regel angesprungen wird. Die Bearbeitung jedes Pakets beginnt
aber in einer der Ketten INPUT, OUTPUT oder FORWARD.
Im Folgenden werden wir einige einfache Beispiele betrachten, die sich auf die RoutingFunktion des Routers beziehen, also die FORWARD-Kette betreffen. Die Firewall eines LinuxSystems lsst sich mit dem Befehl
administrieren. Fr die FORWARD-Kette ist in
unserem Fall die Default-Regel (im Linux-Jargon Policy) ACCEPT voreingestellt. Pakete, die
mit keiner Regel der Kette matchen, werden also durchgelassen.
Mit dem Befehl
lassen wir uns die FORWARD-Kette anzeigen. Sie
enthlt keine Regeln. Mit anderen Worten werden also alle Pakete ausnahmslos durchgelassen.
Das probieren wir aus, indem wir von Rechner 10.2.4.37 Rechner 172.16.2.20 mittels
ansprechen (siehe Abschnitt 7.3.3.3 und Abschnitt 11.3.2.1). Wir verwenden dazu den Befehl
, der uns zustzlich die Route zum angesprochenen Rechner ausgibt.
Wie zu erwarten war, erhalten wir von diesem Rechner eine entsprechende Antwort. Die durch
Aufruf von
erzeugten ICMP-Echo-Requests kommen also bei 172.16.2.20 an und werden
dort durch einen ICMP-Echo-Response beantwortet. Whrend wir
weiter laufen lassen,
fgen wir auf dem Router mittels des Befehls
in die FORWARD-Kette der Firewall eine Regel ein, die ICMP-Verkehr blockiert. Wenn wir das
beobachten, so ist zu sehen, dass nun auf die Anfragen keine Antworten mehr eingehen.
Der durch
ausgesandte ICMP-Echo-Request bleibt also nun unbeantwortet, da die Firewall
das entsprechende Paket ausltert. Der ICMP-Echo-Request bleibt in der Firewall hngen, Rechner 172.16.2.20 erhlt diesen nicht und erzeugt demnach auch keinen ICMP-Echo-Response.
Lschen wir auf dem Router die Firewallregel wieder mittels des Befehls
so erhlt Rechner 10.2.4.37 von 172.16.2.20 wieder Antworten auf die Anfragen. Wir wiederholen das Einfgen und Lschen der Regel und beobachten das Systemverhalten auf dem Rechner
10.2.4.37. Die Meldungen von
sind in Abbildung 9.9 dargestellt. Unter Linux schickt
jede Sekunde eine neues ICMP-Echo-Request auf den Weg. Die Anfragen sind mit einer Sequenznummer versehen, die von eins beginnend inkrementiert wird. Kommt eine Antwort an,
so gibt
unter anderem aus, wie gro die losgeschickte ICMP-Nachricht war (Standardgre 64 Byte) und zu welcher Sequenznummer die Antwort gehrt. Wie man sieht, sind die
173
Abbildung 9.9: Blockieren und ffnen der Firewall fr ICMP-Protokollpakete.
ICMP-Anfragen 1-6 beantwortet worden. Dann haben wir unsere Firewallregel eingefgt, die
die ICMP-Echo-Requests blockiert hat, so dass fr die Anfragen 7-14 keine Antworten eingegangen sind. Dann haben wir die Regel wieder gelscht, so dass die Anfragen 15-22 wieder
beantwortet wurden. Danach wurde wieder die Blockierregel eingefgt und so weiter.
Betrachten wir den Befehl, die zur Steuerung des Paketlters verwendet wurden, nochmals
genauer. Im Befehl
bedeutet
, dass in
die FORWARD-Kette eine Regel eingefgt werden soll. Die weiteren Parameter geben dann an,
um welche Regel es sich handelt. In unserem Fall sind durch die Regel wegen
Pakete
betroffen, die zum ICMP-Protokoll gehren. Die Option
speziziert die Aktion beim
Matchen der Regel und gibt an, dass das Paket verworfen wird. Dabei wird keine Fehlermeldung
an den Absender des Pakets geschickt.
Mit
knnen wir uns die Regel nochmals genauer anzeigen lassen:
174
9 Firewalls
Mit
wird die gesamte FORWARD-Regelkette gelscht. Es gibt auch
Mglichkeiten, einzelne Regeln zu entfernen und die Regeln in der Kette in eine bestimmte
Ordnung zu bringen.
Lschen wir nun die Regel von oben wieder und wenden wir uns einer etwas anspruchsvolleren Aufgabe zu. Wir mchten ausgehende TCP-Verbindungen, die also vom 10.2.4.0/24er
Netz in das 172.16.2.0/24er Netz aufgebaut werden, erlauben, aber TCP-Verbindungen, die in
die umgekehrte Richtung aufgebaut werden, blockieren, und zwar zunchst durch Verwendung
von statischen Filterregeln. Um den Erfolg unserer Manahmen zu kontrollieren, starten wir auf
den Rechnern 10.2.4.37 und 172.16.2.20 jeweils das bereits aus Abschnitt 7.4 bekannte Programm, welches auf TCP-Port 80 auf eingehende Verbindungen wartet. Ausgehend von einer
leeren FORWARD-Kette und Default ACCEPT kontrollieren wir mit Firefox zunchst, dass ein
Verbindungsaufbau in beide Richtungen mglich ist. Nun beginnen wir mit der entsprechenden
Konguration der Firewall. Wir fgen als Erstes eine Regel ein, die in das Netz 10.2.4.0/24 gehende TCP-Pakete ausltert, wenn das SYN-Flag gesetzt ist. Hierfr verwenden wir den Befehl
besagt, dass die Regel Pakete matcht, deren IP-Zieladresse innerhalb des
Netzes 10.2.4.0/24 liegt,
besagt, dass die Pakete als Transportprotokoll TCP verwenden mssen, und SYN bedeutet, dass das SYN-Flag betrachtet wird und
gesetzt sein muss. Diese Regel wird wie folgt angezeigt:
Nun testen wir die Firewall, indem wir von 172.16.2.20 aus versuchen, 10.2.4.37 zu kontaktieren. Das Ergebnis erscheint erfreulich und ist in Abbildung 9.10 zu sehen. Die Firewall ltert
tatschlich das erste TCP-Segment mit dem gesetzten SYN-Flag von 172.16.2.20 zu 10.2.4.37
beim Verbindungsaufbau aus. Beobachtet man mit Ethereal das Systemverhalten, so sieht man,
dass 172.16.2.20 noch einige weitere Versuche unternimmt, das Paket zum Ziel zu befrdern,
aber schlielich aufgibt. Dann erscheint im Browser die in der Abbildung gezeigte Meldung.
Soweit, so gut. Nun testen wir, ob wir von innen nach auen eine Verbindung aufbauen knnen. Leider ist das Ergebnis das Gleiche wie oben: Es funktioniert nicht. Mit Ethereal gehen wir
auf Spurensuche und stellen schnell fest, woran es liegt. Beim TCP-Verbindungsaufbau gelangt
das erste TCP-Segment mit dem gesetzten SYN-Flag von 10.2.4.37 zu 172.16.2.20. Die Antwort von 172.16.2.20, das zweite Segment im TCP-Handshake, hat ein gesetztes SYN-Flag und
ein gesetztes ACK-Flag. Dummerweise greift auch dort unsere Filterregel, so dass dieses Paket
ebenfalls von der Firewall aufgehalten wird und keine Verbindung zustande kommt. Dies ist in
Abbildung 9.11 skizziert.
Wir mssen also unsere Regel revidieren, so dass TCP-Segmente mit gesetztem SYN-Flag und
gesetztem ACK-Flag an 10.2.4.37 durchgelassen werden, aber TCP-Segmente mit gesetztem
175
Abbildung 9.10: Fehlgeschlagener Verbindungsversuch.
10.2.4.37
172.16.2.20
SYN
Zeit
BLOCKIERT
SYN
SYN ACK
x
BLOCKIERT
Abbildung 9.11: Fehlkonguration der Firewall durch Verwendung einer verkrzten Filterregel.
SYN-Flag und nicht gesetztem ACK-Flag verworfen werden. Nach Lschung der alten Regel
unternehmen wir also folgenden zweiten Versuch:
Diese Regel gibt an, dass im TCP-Segment das SYN und das ACK-Flag untersucht werden
sollen. Die Regel matcht dann, wenn das SYN-Flag gesetzt ist und das ACK-Flag nicht. Wie
ein praktischer Test zeigt, erzielen wir mit dieser Regel tatschlich das gewnschte Verhalten.
176
9 Firewalls
Abbildung 9.12: Fehlgeschlagener Verbindungsversuch bei Verwendung des REJECT-Targets.
Ausgehende Verbindungen von 10.2.4.37 zu 172.16.2.20 sind mglich, whrend umgekehrt eingehende Verbindungen zu 10.2.4.37 blockiert werden.
Bisher hatten wir Pakete ber das DROP-Target aussortiert und einfach nicht weiterbefrdert,
ohne den Sender der Pakete ber das Vorgehen zu informieren. Der Empfnger erhielt also kein
Feedback darber, was mit dem Paket passiert ist. Dies resultierte darin, dass die Verbindungsversuche wiederholt unternommen wurden, bis der Sender letztlich abbricht, was eine ganze Weile
dauern kann.
Es besteht auch die Mglichkeit, dem Empfnger ber das ICMP-Protokoll wie in Abschnitt
7.3.3.3 kurz skizziert eine Nachricht ber das Schicksal des Pakets zukommen zu lassen. Dies
wollen wir ebenfalls ausprobieren und das Systemverhalten dabei beobachten. Wir lschen also
wieder die FORWARD-Kette und fgen folgende Regel ein:
Der Unterschied zur vorangegangenen Regel besteht in der Verwendung des REJECT-Target.
Dies bedeutet, dass der Sender des Pakets ber das ICMP-Protokoll darber unterrichtet wird,
dass das Paket nicht weiterbefrdert werden konnte. ber
kann exibel eingestellt
werden, welche ICMP-Nachricht beim Verwerfen des Pakets an den Sender zurckgeschickt
werden soll. Wir verwenden hier die Standardeinstellung.
Betrachten wir kurz, wie sich dies auf Seiten des Senders auswirkt und rufen wiederum von
172.16.2.20 ber den Browser den Server auf 10.2.4.37. Sofort nach dem Aufrufen erhalten wir
im Browser die in Abbildung 9.12 gezeigte Meldung.
Betrachten wir, was auf Paketebene passiert, indem wir den Versuch nochmals durchfhren
und auf der Clientseite die Pakete mitlesen. Abbildung 9.13 zeigt die von Ethereal aufgefangenen
Pakete. Das TCP-Segment mit dem SYN-Flag wird von der Firewall mit einer ICMP-Nachricht
des Typs Destination unreachable und Code Port unreachable beantwortet. Absender der
ICMP-Nachricht ist die Firewall (IP-Quelladresse 172.16.2.5).
177
Abbildung 9.13: Paketanalyse eines fehlgeschlagenen Verbindungsversuchs bei Verwendung des REJECTTarget in der Firewall.
Fr den Absender eines Pakets ist es natrlich vorteilhaft, wenn er ber das Verwerfen dieses
Pakets informiert wird. Er kann dann weitere Versuche, das Ziel zu kontaktieren, sofort einstellen und auch den Benutzer umgehend informieren. Wie unser Beispiel jedoch zeigt, knnte ein
Angreifer aber mglicherweise aus dem Empfang einer solchen ICMP-Nachricht Rckschlsse
ziehen. Speziell dann, wenn gezielt die Reaktionen auf bestimmte Anfragen geprft wird, knnen
durch das systematische Sammeln und Analysieren dieser Nachrichten mglicherweise Informationen ber die Existenz einer Firewall, deren Konguration oder anderer Netzwerkkomponenten
gezogen werden, die wiederum Anhaltspunkte fr mgliche Angriffe liefern knnten.
Bisher haben wir statische Filtermethoden betrachtet. Die Paketltermechanismen unter Linux
bieten auch die Mglichkeit, dynamische Filterregeln einzusetzen. Unter Linux werden automatisch durch das
-Modul die durch die Maschine laufenden Verbindungen und
Kommunikationssse mit ihrem aktuellen Zustand erfasst. Dieses Modul kann durch den Befehl
geladen und aktiviert werden. Die Datei
enthlt eine Auistung der Verbindungen und Informationssse. Im Folgenden werden wir aus
Vereinfachungsgrnden nur noch von Verbindungen sprechen. Betrachten wir ein Beispiel:
178
9 Firewalls
Im vorliegenden Fall sind drei TCP-Verbindungen aufgelistet. Die ersten zwei Felder des Eintrags fr eine Verbindung geben an, um welches Protokoll es sich handelt. In unserem Fall ist das
TCP. Es folgt die im IP-Header angegebene Protokollnummer fr das Transportprotokoll (6 fr
TCP). Linux verwendet einen Timeout-Mechanismus, um nicht mehr existente Verbindungen
zu entfernen (dies ist notwendig, da das Ende einer Verbindung manchmal nicht erkannt werden kann). Der dritte Wert gibt an, in wieviel Sekunden der Eintrag fr die Verbindung gelscht
wird, sofern keine weiteren zu der Verbindung gehrenden Pakete beobachtet werden in unserem Fall in 431990 Sekunden. Wird weiterer zu der Verbindung gehrender Verkehr beobachtet,
wird ein neuer Timeout-Wert festgelegt. Die Lnge des Timeouts richtet sich nach dem Typ der
Verbindung und ihrem gegenwrtigen Zustand. Es folgt der Zustand der Verbindung, in unserem Fall ESTABLISHED. Die Spezikation von TCP legt verschiedene Zustnde fest, die beim
Aufbau, Betrieb und Abbau einer TCP-Verbindung durchlaufen werden (siehe Abbildung 7.10
in Abschnitt 7.3.4.1). Der entsprechende Zustand ist hier angegeben. ESTABLISHED bedeutet,
dass der Verbindungsaufbau beendet ist und Daten in beide Richtungen bertragen werden knnen. Es folgen Informationen ber IP-Quelladresse, IP-Zieladresse, Quell- und Zielport, wobei
jeder Informationsuss der Verbindung einzeln angegeben wird, und Statistiken sowie weitere
Informationen ber die Flsse. Zuerst aufgefhrt ist dabei der Flow vom Client zum Server, also
derjenige, durch den die Verbindung begonnen wurde. Fr unsere einfache Filterung kommt es
vor allen Dingen auf den Zustand der Verbindung an, daher wollen wir auf die weiteren Eintrge
nicht nher eingehen.
In unserem Beispiel sind noch zwei weitere Verbindungen gelistet. Eine davon ist im Zustand
SYN RECV, die andere im Zustand TIME WAIT. SYN RECV bedeutet, dass gerade der Verbindungsaufbau im Gang ist und die ersten beiden Schritte des Handshakes (Senden des SYN
vom Client zum Server, Senden eines SYN ACK vom Server zum Client) bereits erfolgt sind. Von
diesem Zustand aus wird beim Empfang des ACK in den Zustand ESTABLISHED gewechselt.
Die dritte Verbindung ist im Zustand TIME WAIT. Dies bedeutet, dass die TCP-Verbindung von
beiden Seiten bereits geschlossen wurde. Dieser Eintrag wird nach einem relativ kurzen Timeout
entfernt, da die Verbindung beendet ist.
Wir wollen nun die dynamische Filterung ausprobieren und verbinden den Test auerdem mit
einer Vernderung der Default-Policy der Firewall. Zunchst lschen wir die FORWARD-Kette
wieder. Auerdem ndern wir die Policy des Paketlters und legen fest, dass Pakete, die mit
keiner Regel matchen, nun verworfen werden sollen. Dies geschieht durch den Befehl
179
Wir testen wiederum Verbindungen von 172.16.2.20 nach 10.2.4.37 und stellen fest, dass die
Firewall wie erwartet keinen Verkehr durchlsst. Nun fgen wir Regeln ein, die beliebige TCPVerbindungen vom 10.2.4.0/24er Netz nach auen, aber keine eingehenden Verbindungen erlauben.
Der erste Befehl fgt eine Regel in die FORWARD-Kette ein, die alle Pakete, die aus dem
10.2.4.0/24er Netz stammen und zu einer neuen Verbindung gehren, durchlsst. Nach dem
Durchlassen wird die betreffende Verbindung wie oben skizziert von Linux registriert und in
angezeigt. Pakete, die von der Firewall nicht durchgelassen werden,
werden auch nicht registriert.
Der zweite Befehl fgt ebenfalls eine Regel in die FORWARD-Kette ein, die smtliche Pakete
in jegliche Richtung durchlsst, die zu einer Verbindung gehren, die bereits bekannt ist. Man
beachte, dass das ESTABLISHED sich nicht auf den gleichnamigen TCP-Zustand bezieht.
Wie ein kurzer Test zeigt, knnen wir mit diesen Regeln das erwnschte Verhalten der Firewall
erreichen. Es gbe noch viele weitere interessante Tests und aufschlussreiche Experimente, um
die Funktionsweise von Firewalls tiefergehend zu ergrnden, doch wir wollen es an dieser Stelle
dabei bewenden lassen.
9.2.2 Applikation-Level-Gateways
9.2.2.1 Einfhrung
Paketlter sind mchtige Werkzeuge, doch wie bereits erwhnt werden sie nur bis zur Transportschichtebene verwendet, da es zur Filterung von Daten auf Applikationsschichtebene geeignetere
Verfahren gibt, um den Verkehr zwischen zwei Netzen auf der Applikationsschichtebene zu berwachen, nmlich Application-Level-Gateways (ALGs). ALGs rmieren in der Praxis unter vielen
verschiedenen Namen, wie beispielsweise Proxies oder Session-Border-Controller. ALGs kontrollieren den Verkehr auf Anwendungsebene, daher ist die konkrete Arbeitsweise eines ALGs
stark von der jeweiligen Anwendung abhngig.
Die prinzipielle Idee hinter ALGs ist es, Verbindungen zwischen Stationen in Intranet und
im Internet nicht direkt abzuwickeln, sondern ber eine Zwischenstation laufen zu lassen, die
den Austausch von Informationen auf Applikationsebene berwacht, analysiert und ltert. Dabei
werden wiederum Regeln festgelegt, welche Aktionen und Funktionen der betreffenden Applikation jeweils erwnscht oder unerwnscht sind. Die Stationen im Intranet stellen ihre Anfragen
also nicht direkt an den zu kontaktierenden Server im Internet, sondern an das ALG, das dann
selbst den Server im Internet kontaktiert. Dies ist in Abbildung 9.14 skizziert.
Abgesehen von Sicherheitsfunktionen knnen ALGs und Proxies auch noch andere Funktionen bernehmen, etwa das Caching von durch die Applikationen hug angefragten Daten. Ein
ALG nimmt also eine Anfrage einer Maschine aus dem Intranet entgegen und analysiert diese
Anfrage auf Zulssigkeit und Sicherheitsrelevanz. Sofern die Anfrage erlaubt ist, stellt das ALG
die Anfrage entweder entsprechend bestehender Regeln verndert oder unverndert dem Server
im Internet und nimmt die Antwort des Servers entgegen.
180
9 Firewalls
Client im Intranet
Application-Level-Gateway
Server im Internet
- Zugriffskontrolle (Blockieren
bestimmter Domains)
- berprfung von Inhalten
(z.B. auf Malware)
- Logging von Aktivitten
- Upload/Download-Kontrolle
Abbildung 9.14: Application-Level-Gateway.
Die Antwort des Servers wird ebenfalls vom ALG analysiert und entsprechend bestehender
Regeln verndert oder unverndert an die anfragende Maschine aus dem Intranet geschickt. In
einigen Fllen (Caching, Antwort auf verbotene Anfragen usw.) beantwortet das ALG Anfragen
auch direkt, ohne mit Rechnern im Internet zu kommunizieren.
Somit werden die Informationen auf der Applikationsschicht nicht direkt ausgetauscht, sondern zunchst im Intranet an das ALG geschickt und dann von dort an den Sender. Die berprfung auf der Applikationsschicht hat viele Vorteile. Dort liegen vollstndige Protokoll- und
Nutzlastinformationen des jeweiligen Applikationsprotokolls vor, die einer detaillierteren Analyse unterzogen werden knnen. Eine Fragmentierung und mgliche Aufteilung dieser Information
auf tieferliegenden Schichten ist fr die Arbeitsweise des ALGs unproblematisch, da die Informationen vor der Bearbeitung durch das ALG durch die Protokolle unterer Schichten wieder
zusammengefgt werden.
Das ALG kann also den Inhalt der vom Sender erhaltenen Informationen zunchst berprfen
und dann entscheiden, ob dieser Inhalt tatschlich an den Empfnger weitergeleitet werden soll
oder nicht. Die Inhalte des Informationsaustauschs knnen unter anderem auf das Auftreten von
Schlsselwrtern im Inhalt oder auf Malware berprft werden. Darber hinaus kann ber Listen und Indexdienste berprft werden, ob der angesprochene Kommunikationspartner von der
Institution vorgegebenen Kriterien entspricht (etwa: Beschrnkung bestimmter Domains etc.).
Eine derartige Funktion wre zwar theoretisch auch auf einem Paketlter denkbar, aber in der
Praxis mit nicht vertretbarem Aufwand verbunden.
Allgemeiner formuliert kann ein ALG damit unter anderem gegenber einem Paketlter folgende erweiterten Funktionen bernehmen:
Beschrnkung der Kommunikationspartner und der Applikationsfunktionen: Kommunikationspartner knnen nicht nur wie bei Paketltern anhand von IP-Adressen oder IPAdressbereichen, sondern auch nach anderen Kriterien eingeschrnkt werden, etwa auf
Basis von Domainnamen. Die Funktionen der Applikation lassen sich ebenfalls gezielt
und graduell steuerbar einschrnken, whrend bei einem Paketlter nur die ganze Applikation zugelassen oder untersagt werden kann.
Benutzerspezische Regeln: Sofern die Applikation eine Benutzerauthentikation besitzt,
knnen fr unterschiedliche Benutzer unterschiedliche Rechte vergeben werden.
181
berprfung von Inhalten: Durch die Applikation ausgetauschte Inhalte werden zunchst
vom Sender an das ALG geschickt und knnen dort vor der Weitergabe an den an Empfnger auf sicherheitsrelevante Fragestellungen hin untersucht werden. So knnte etwa der
Versand vertraulicher Daten vom Intranet ins Internet unterbunden werden oder eine eingehende Nachricht auf darin versteckte Malware getestet werden.
Keine direkte Verbindung zwischen Sender und Empfnger: Da keine direkte Verbindung
zwischen Sender und Empfnger besteht, knnen ALGs in manchen Fllen zu einer gewissen Anonymisierung des Verkehrs beitragen, da etwa alle Kontakte einer Institution mit
Servern im Internet von einer IP-Adresse aus (der des ALGs) zu kommen scheinen. Ein
derartiger Effekt ist allerdings auch ber ein NAT erreichbar.
Logging auf Applikationsebene: Ein ALG kann detailliert mitprotokollieren, was auf Applikationsebene genau vorgeht. Diese Information ist in der Regel weitaus aussagekrftiger
als die Daten eines Paketlters.
Die meisten Applikationslter arbeiten nicht transparent, sondern bei der Konguration der
Anwendung muss die Verwendung des ALGs explizit angegeben werden. ALGs werden meistens in Verbindung mit einem oder mehreren Paketltern eingesetzt. Der Paketlter kann dann
so konguriert werden, dass die Anwendungen tatschlich ber das ALG laufen, indem direkte
Verbindungen durch entsprechende Regeln untersagt werden.
Es gibt einige Applikationen, bei denen die Verwendung eines ALGs nicht notwendig ist, da es
fr den Betrieb der Anwendung ausreicht, wenn Clients im Intranet mit einem Server im Intranet
kommunizieren, der dann die weitere Kommunikation mit Rechnern im Internet bernimmt. Zu
solchen Anwendungen gehrt beispielsweise Email.
Leider weisen ALGs auch einige signikante Nachteile im Vergleich zu Paketltern auf:
ALGs sind stark anwendungsspezisch: Die Arbeitsweise eines ALGs ist stark von der
jeweiligen Anwendung abhngig. Je nach Anwendung muss ein ALG vollkommen unterschiedliche Aufgaben durchfhren.
Grere Exposition gegenber Angriffen: Ein ALG kommuniziert direkt mit anderen Rechnern im Internet, whrend ein Paketlter transparent arbeiten kann. Daher kann ein Angreifer ein ALG leichter entdecken und einen Angriffsversuch starten. Dies trifft insbesondere
zu, wenn das ALG einen Dienst anbietet, den Rechner aus dem Internet heraus kontaktieren knnen.
ALGs knnen auch anstelle von NATs eingesetzt werden, um fr die spezische Anwendung
den Zugriff auf das Internet zu ermglichen, wenn die Clients nur ber private IP-Adressen verfgen. Dies ist dann mglich, wenn das ALG ber zwei Interfaces verfgt, eines im privaten
IP-Adressbereich und ein Interface mit einer ffentlichen IP-Adresse. Das ALG nimmt in diesem Fall die Anfragen der Clients auf dem Interface, das mit privater Adresse betrieben wird
entgegen, analysiert sie wie oben beschrieben und leitet die Anfragen dann gegebenenfalls unter Verwendung seiner ffentlichen Adresse ber das andere Interface weiter. Mit eingehenden
Antworten wird entsprechend umgekehrt verfahren.
182
9 Firewalls
9.2.3 Application-Level-Gateways und Paketlter in der Praxis

In der Praxis gibt es heute eine ganze Reihe verschiedenster Firewall-Produkte, angefangen vom
einfachen WAN/LAN-Gateway fr Heimnetzwerke bis hin zu Hochleistungsrewalls fr groe
Unternehmen. Wie beschrieben haben Paketlter und Application-Level-Gateways jeweils Vorund Nachteile, die in der Praxis in den meisten Fllen, zumindest fr grere Netze, zu einer
Verbindung dieser Konzepte gefhrt haben. Die meisten Firewalls besitzen sowohl (dynamische)
Paketlter als auch Application-Level-Gateways. Dabei knnen diese Funktionen gerade in kleinen Netzwerken auch gemeinsam auf einer Maschine untergebracht sein, die beide Aufgaben
bernimmt. Generell ist es jedoch deutlich sicherer, dezidierte Rechner fr die einzelnen Funktionen zu verwenden.
9.3 Firewall-Architekturen
9.3.1 Einfache Firewall
Abbildung 9.15 zeigt eine besonders einfache Firewallstruktur. Ein Paketlter bendet sich zwischen dem Internet und dem geschtzten Intranet. Wir wollen im Folgenden die Positionierung
folgender mglicher Komponenten in dieser Architektur diskutieren:
Server, die aus dem Internet erreichbar sein mssen: Server, auf denen Dienste laufen, die
aus dem Internet heraus angesprochen werden mssen, beispielsweise ein Email-Server
oder ein Webserver mit dem Internetauftritt der Institution.
Application-Level-Gateways: ALGs wie vorgestellt, beispielsweise ein Web-Proxy. Dabei
gehen wir davon aus, dass diese ALGs keine Services anbieten, die vom Internet aus erreichbar sein mssen (wenn dies der Fall ist, gelten hnliche berlegungen wie fr Server,
die aus dem Internet erreichbar sein mssen).
Fr die Platzierung gibt es jeweils zwei Mglichkeiten, nmlich (aus Sicht des Internet) vor
dem Paketlter oder aus Sicht des Internets hinter dem Paketlter. In Abbildung 9.15 haben wir
die extern ansprechbaren Server vor dem Paketlter platziert und die ALGs dahinter. Es stellt
sich aber die Frage, ob diese Platzierung hinsichtlich der Sicherheit optimal ist oder nicht.
Beginnen wir mit ALGs, von denen wir wie gesagt annehmen, dass sie keine Dienste anbieten,
die aus dem Internet heraus angesprochen werden drfen. ALGs bieten aber sehr wohl Dienste
an, die aus dem Intranet heraus kontaktiert werden drfen. So wartet ein Web-Proxy auf eingehende Anfragen von Maschinen aus dem Intranet. Positioniert man das ALG vor den Paketlter,
so knnen Maschinen aus dem Internet die Services des ALG kontaktieren, was unerwnscht
wre. Darber hinaus knnte das ALG dann aus dem Internet heraus auch auf anderen Ports
testweise von einem Angreifer angesprochen und gescannt werden. Somit sollte ein ALG also
hinter dem Paketlter im geschtzten Bereich des Netzes seinen Platz nden. Allerdings kommuniziert ein ALG mit vielen anderen Maschinen im Internet, so dass das ALG auch in diesem
Fall weiterhin Gefahren ausgesetzt ist, die sich aus der Erfllung seiner Aufgaben ergeben.
Betrachten wir nun die aus dem Internet erreichbaren Server. Die Dienste dieser Server mssen aus dem Internet heraus angesprochen werden knnen. Setzt man einen solchen Server vor
183
Intranet
geschtztes
internes
Netz
Internet
nur intern verfgbare

Server
extern verfgbare Server
Abbildung 9.15: Einfache Firewall-Architektur.
den Paketlter, so kann der Rechner wiederum durch einen Angreifer aus dem Internet auch auf
anderen Ports gescannt werden, so dass mgliche Schwachstellen nicht lange unentdeckt bleiben wrden. Wenn sich ein solcher Server hinter dem Paketlter bendet, so mssen Rechner
im Internet durch den Paketlter hindurch Verbindungen mit dem Server aufbauen und betreiben drfen. Das ist durch das Anlegen entsprechender Regeln im Paketlter mglich. Die Sicherheitskonsequenzen sind jedoch fatal. Whrend das ALG wenigstens nicht aktiv durch Dritte
angesprochen werden kann, ist der auf dem Server zur Verfgung gestellte Dienst aus dem Internet heraus ansprechbar. Ein Angreifer kann so eine Verbindung zu dem Dienst aufbauen und
eventuelle Schwachstellen in der Implementierung oder des Designs des Dienstes nutzen, um so
Zugriff auf den Server selbst zu erhalten. Gelingt es ihm, auf der Maschine den Root-Zugriff
zu erlangen, so kann er den Server im Intranet bernehmen und ausgehend von diesem Rechner weitere Maschinen im Intranet angreifen. Der Schutz durch den Paketlter ist so effektiv
ausgehebelt worden. Dies ist in Abbildung 9.16 verdeutlicht.
Zusammenfassend ist keine der beiden mglichen Varianten der Positionierung von externen
Servern und ALGs besonders berzeugend. Wenn berhaupt ndet man daher solche einfachen
Firewallarchitekturen nur in privaten Heimnetzwerken oder in Kleinstunternehmen.
9.3.2 Demilitarized Zone (DMZ)

Professionellere und sicherheitsbewusste Anwender wissen um die Schwchen solcher einfachen
Architekturen und setzen deshalb eine bessere, aber wesentlich komplexere Architektur ein, die
wir im Folgenden prinzipiell skizzieren wollen.
Die Idee besteht darin, eine (oder auch mehrere) neutrale Sicherheitszone(n) zu schaffen,
in welcher die extern verfgbaren Server und ALGs betrieben werden. Dies ist in Abbildung
9.17 skizziert. Diese Zone ist jeweils durch Paketlter vom Internet und von den zu schtzenden
Rechnern im Intranet getrennt und wird als Demilitarized Zone (DMZ) bezeichnet. Je nach den
184
9 Firewalls
Intranet
Paketfilter erlaubt
Zugriff auf einen Server
geschtztes
internes
Netz
Internet
kompromittierter Server
kann uneingeschrnkt auf
geschtzten Bereich zugreifen
Abbildung 9.16: Extern verfgbare Server hinter dem Paketlter sind problematisch.
Intranet
geschtztes
internes
Netz
DMZ
Internet

Server
Abbildung 9.17: Firewall mit DMZ.
fr Rechner im Intranet oder aus dem Internet angebotenen Diensten sind in den Paketltern
entsprechende Regeln vorhanden, die zwar den jeweils notwendigen Verkehr zwischen Rechnern
in der DMZ und dem Internet sowie Rechnern in der DMZ und dem Intranet erlauben, andere
Zugriffe aber unterbinden, wie beipielsweise nicht notwendige Zugriffe eines Servers aus der
DMZ auf den dahinterliegenden geschtzten Bereich.
Sollte also eine Maschine in der DMZ durch einen Angriff kompromittiert werden, so verhindert der zweite Filter, dass die Rechner in der internen Zone von dort aus unmittelbar angegriffen
werden knnen. Zustzlich genieen die Rechner in der DMZ einen Schutz gegenber dem Internet durch den ersten Filter. Somit ist diese Konguration weitaus sicherer als die vorangegangene
einfache Variante.
185
Intranet
DMZ 2
geschtztes
internes
Netz
Internet
DMZ 1

Server
Abbildung 9.18: Firewall mit mehreren DMZs.
Die unterschiedliche Gefhrdungslage extern erreichbarer Server gegenber ALGs hatten wir
ja bereits angesprochen. Erfahrungsgem sind auch externe Server mit unterschiedlichen Diensten unterschiedlichen Gefhrdungspotentialen ausgesetzt. Da innerhalb der DMZ keine weiteren
Schutzmechanismen greifen und somit ein durch einen Angreifer subvertierter Rechner die anderen Rechner innerhalb der DMZ angreifen kann, ist es naheliegend, die unterschiedlichen Server
und ALGs in verschiedene DMZs oder Zonen innerhalb der DMZ zu stellen, so dass wiederum Filtermechanismen solche Angriffe effektiv unterbinden knnen. Dies ist in Abbildung 9.18
gezeigt.
Die gewhlten Darstellungsformen zeigen den prinzipiellen Betrieb und die Funktionsweise
einer DMZ. In der Praxis nden sich hug auch andere Netzwerkaufteilungen. Beispielsweise
ist es mglich, nur einen einzigen Paketlter einzusetzen, an dem sowohl die unterschiedlichen
DMZs als auch das geschtzte interne Netz gemeinsam betrieben werden jeweils an verschiedenen Interfaces. Somit sind dann alle Paketlter in einem Gert vereinigt. Anhand der verschiedenen Interfaces kann der Filter eindeutig identizieren, aus welchem Netz ein Paket stammt
und wohin es will. Dadurch ist eine derartige Architektur von der Filtergranularitt her genauso
exibel einsetzbar wie der Betrieb mehrerer Filter. Der Vorteil beim Einsatz eines Filters gegenber mehreren Filtern liegt in Kosteneinsparungen und einer vereinfachten Netzwerkstruktur.
Aus Sicherheitsgrnden sind Architekturen mit mehreren Filtern natrlich vorzuziehen.
Besonders in groen Institutionen ist es oftmals angebracht, auch das geschtzte interne Netzwerk in weitere Teilbereiche aufzugliedern, die gegenber den jeweils anderen Netzen im Intranet der Firma abgegrenzt sind. In einigen Fllen ist es sinnvoll, solche Teilnetze gegenber dem
Intranet ebenfalls durch eine Firewall abzusichern, so dass die Kommunikation entsprechend
berwacht und gesteuert werden kann. Denken Sie etwa an eine Forschungsabteilung innerhalb
eines groen Unternehmens oder das Netz des Vorstands.
186
9 Firewalls
9.4 Schwachstellen im Konzept von Firewalls

9.4.1 Einfhrung
Wir hatten bereits zu Beginn des Kapitels die intrinsischen Sicherheitsprobleme im Konzept von
Firewalls angesprochen und wollen diese Probleme in diesem Abschnitt nochmals konkretisieren, speziell hinsichtlich
der Umgehung der Firewall durch portable Gerte wie Laptops und PDAs und
der Verwendung von Tunneln und Verschlsselung.
9.4.2 Mobile Rechner

Eine Firewall kontrolliert den Verkehr zwischen dem Netzwerk einer Institution und dem Internet und ltert unerwnschten Verkehr aus, whrend erlaubter Verkehr die Firewall passieren
kann. Portable, mobile Gerte werden im Regelbetrieb oftmals auch auerhalb des institutionseigenen Netzwerks verwendet. Das kann durch die Einwahl in das Netz eines Serviceproviders
ber ein Modem sein, durch die Verwendung einer DSL-Verbindung (etwa von zu Hause aus)
oder auch durch die Benutzung eines ffentlichen WLAN-Hot-Spots. Beim Betrieb in solchen
Netzen benden sich die mobilen Gerte auerhalb des Netzwerks der Institution. Daher sind sie
auch nicht durch die Firewall der Institution geschtzt.
Mobile Rechner, die in Fremdnetzen ohne den Schutz der institutionseigenen Firewall operieren, sind dort mglicherweise Angriffen ausgesetzt. Gerade in ffentlichen oder halbffentlichen
Netzen (Hot-Spot, WLAN auf einer Konferenz) liegt der Fokus des Netzwerkbetreibers oft nicht
so sehr auf der Sicherheit, und es ist deshalb hug fr einen Angreifer relativ leicht, andere
Rechner in diesen Netzen anzugreifen.
Ist das Fremdnetz nur unzureichend durch eine Firewall nach auen gesichert (oder auch
gar nicht), knnen Hacker ber das Internet den mobilen Rechner kontaktieren und eventuelle Schwachstellen ausnutzen. Noch schwerer wiegt, dass auch innerhalb des Fremdnetzes selbst
Angreifer lauern knnen (siehe Abschnitt 10.6.2). Einige Angriffe sind nur mglich, wenn sich
der Rechner des Angreifers im gleichen LAN wie der Rechner des Opfers bendet, was in
Fremdnetzen der Fall sein kann. Die Identikation eines Angreifers in einem Fremdnetz ist meistens ebenfalls schwierig.
Wird das mobile Gert dann wieder in der Institution betrieben, so bendet es sich schon hinter
der Firewall, so dass die hier diskutierten Firewallmechanismen wiederum effektiv ausgehebelt
sind. Wird also ein mobiles Gert durch einen Angreifer erfolgreich kompromittiert, so ist die
Sicherheit des Institutionsnetzes gefhrdet, und diese Gefhrdung kann weder durch die hier besprochenen Firewallkonzepte gelindert werden noch durch eine Authentikation von Maschinen
oder Benutzern, denn sowohl Benutzer als auch Rechner sind legitim. Es sind die Daten auf der
Maschine, von denen die Bedrohung ausgeht.
Mittlerweile haben sich einige Hersteller von Sicherheitsprodukten im IT-Bereich des Problems angenommen. Die meisten der bisherigen Konzepte setzen aber etwas unterhalb des eigentlichen Problems an und berprfen nur, inwieweit die Sicherheitseinstellungen des Rechners
konform mit denen der Institution sind und im Betrieb nicht verndert wurden, und ob das Gert
187
ber alle notwendigen Updates und Patches verfgt. Dies ist sicherlich ein wichtiger Schritt in
die richtige Richtung, aber langfristig ist mit weitergehenden Lsungen zu rechnen.
9.4.3 Tunnel und Verschlsselung

Wenden wir uns nun einer weiteren Bedrohung zu, der Firewalls nur begrenzt begegnen knnen, nmlich dem Tunneln von Protokollen durch andere Protokolle. Viele Benutzer sind mit
den Einschrnkungen, die ihnen durch die Firewall auferlegt werden, nicht besonders glcklich.
Abgeschnitten vom Zugriff auf ihre privaten Emails, Instant Messaging oder anderen Diensten,
suchen sie verzweifelt nach Mglichkeiten, diese Dienste trotzdem nutzen zu knnen unter
Umgehung der Firewall und damit der Sicherheitsrichtlinien. Es gibt vielfltige Mglichkeiten,
wie eine Firewall in der Praxis umgangen werden kann, und wir werden im Folgenden nur einige
hiervon exemplarisch skizzieren.
Betrachten wir zunchst ein einfaches Beispiel. Eine Institution mchte den Zugriff auf externe Email-Systeme aus Sicherheitsgrnden verbieten und schaltet deshalb auf der Firewall die
Weiterleitung der entsprechenden Protokolle (POP, IMAP, SMTP) ab. Viele Institutionen sehen
im Zugriff auf externe Email-Konten ein signikantes Sicherheitsrisiko, da die Filterung dieser Emails nicht durch die Institution selbst vorgenommen und berwacht werden kann, so dass
beispielsweise ein Anhang mit Malware als Email in das Intranet der Institution gelangen knnte. Doch der Zugriff auf private Email-Konten ist unter Anwendern auerordentlich beliebt, so
dass viele Email-Provider dazu bergegangen sind, den Zugriff auf Emails nicht nur durch die
ursprnglichen Protokolle und Programme zu ermglichen, sondern auch ber ein Webfrontend,
also durch den browsergesttzten Zugriff auf Emails ber das HTTP-Protokoll, auch als Webmail
bekannt. Der Email-Provider betreibt in diesem Fall einen HTTP-basierten Webserver, welcher
Zugriff auf die Email-Daten der jeweiligen Benutzer hat und diesen nach erfolgreichem Login
auf dem Server die Mglichkeit bietet, unter Verwendung eines Webbrowsers Emails zu lesen
und zu schreiben. Da in den meisten Unternehmen der Zugriff auf das WWW erlaubt ist, knnen
auf diese Weise die meisten Anwender auch dann auf Ihre Emails zugreifen, wenn die Firewall
des Unternehmens einen direkten Zugriff ber Email-Programme und die entsprechenden Protokolle blockiert. Webmail ermglicht es Anwendern meist auch, die Anhnge einer Email ber
HTTP auf ihren jeweiligen Rechner zu laden, so dass der HTTP-basierte Zugriff auf Emails Risiken birgt, die durch die restriktive Filterung von Email-Protokollen durch die Firewall eigentlich
eliminiert werden sollten.
Eine andere Mglichkeit, die zumindest Paketlter austricksen kann, ist die Verwendung eines Protokolls mit einer anderen als der eigentlich vorgegebenen Protokollnummer. Dies ist in
Abbildung 9.19 dargestellt. Technisch gibt es keinen Grund, der verhindert, dass ein Server eingehende POP-Email-Abfragen auf dem normalerweise fr HTTP verwendeten TCP-Port 80 entgegennimmt und nicht auf dem eigentlich hierfr vorgesehenen TCP-Port 110. Ist der HTTPZugang zum Internet in der Firewall durch ein ALG, sagen wir einen HTTP-Proxy, abgesichert,
so registriert dieses natrlich, dass es sich bei den ausgetauschten Nachrichten nicht um das
HTTP-Protokoll handelt, und somit lassen sich durch ein ALG derart plumpe Versuche leicht
verhindern. Ebenso drfte ein solches Vorgehen nur dann mglich sein, wenn man selbst den
Server betreibt und daher die Portnummer fr den Dienst beliebig ndern kann, was wahrscheinlich in der Regel nicht zutrifft.
188
9 Firewalls
Server nimmt POP-Anfragen
auf TCP-Port 80 entgegen
TCP-Port 110 geblockt
x
Internet
Intranet
TCP-Port 80 nicht geblockt
Abbildung 9.19: Verwendung einer anderen TCP-Portnummer.
Doch es geht noch schlimmer, und auch ein ALG kann ausgetrickst werden, und zwar ganz
ohne am Server nderungen vorzunehmen. Anstatt die Portnummer zu ndern, knnte auch
Tunneln zum Einsatz kommen. Unter Tunneln versteht man das Verpacken von Protokolldaten
eines Protokolltyps x in Protokolleinheiten eines Protokolltyps y. In unserem Beispiel wrde also
nicht einfach TCP-Port 80 genommen, sondern die POP-Nachrichten in auch fr ein ALG unverdchtig wirkende, HTTP-konforme Nachrichten verpackt. Hierzu luft auf irgendeinem anderen
Rechner im Intranet (oder auch dem Client selbst) ein Programm, das die POP-Anfragen des eigentlichen Email-Programms entgegennimmt, entsprechend in HTTP-Nachrichten einpackt und
dann an einen Tunnel-Server im Internet ber das HTTP-Protokoll weiterschickt. Dieser TunnelServer entpackt die HTTP-Daten wieder und spricht dann den eigentlichen Email-Server auf
dem eigentlichen TCP-POP-Port an. Da sowohl der Email-Client als auch der Email-Server die
normalen Portnummern fr POP verwenden, kann diese Technik in Verbindung mit beliebigen
Email-Programmen und Email-Servern zum Einsatz kommen.
Abbildung 9.20 skizziert diese fr Firewalls bedrohliche Technik. Fr unser Beispiel des Zugriffs auf Emails laufen folgende Schritte ab:
1. Der Benutzer mchte von Rechner A aus Email von einem Server Y im Internet per
POP aufrufen, direkter Zugriff auf die Email-Dienste von Server Y ist aber aufgrund
der Firewall nicht mglich, denn sie verhindert den direkten Zugriff auf alle TCP-Ports
auf Rechnern im Internet. Die Institution betreibt aber einen HTTP-Proxy. Daher hat
der User das Programm so eingestellt, dass Y nicht direkt kontaktiert wird, sondern das
Email-Programm einen Rechner B im Intranet ber POP kontaktiert. Aus Sicht des EmailProgramms ist also B der Email-Server. Tatschlich aber betreibt B einen Tunnel-Dienst,
der das POP-Protokoll ber HTTP tunnelt. A kontaktiert also B auf TCP-Port 110 mit einer
POP-Anfrage.
2. Rechner B nimmt eingehende POP-Anfragen auf dem TCP-Port fr POP entgegen, kapselt sie in HTTP ein und schickt sie ber den HTTP-Proxy der Institution an TCP-Port
80 eines Servers X im Internet weiter. B schickt also HTTP-Protokolldaten, in denen die
ursprngliche Anfrage von A enthalten ist, ber den HTTP-Proxy zum Server X.
Email-Server nimmt POP-Anfragen

auf TCP-Port 110 entgegen
189
Firewall erlaubt ausschlielich

HTTP-Verkehr ber den HTTP-Proxy
nach auen
ALG (HTTP-Proxy)
Proxy
leitet scheinbare
HTTP-Anfrage weiter
Email-Programm
schickt POP-Anfrage
an Tunnel
Internet
Intranet
A
B
X
Tunnel-Server entpackt
getunnelte POP-Anfrage
und schickt sie zum Email-Server
Nimmt POP-Anfragen
auf TCP-Port 110 entgegen,
kapselt in HTTP und schickt
auf TCP-Port 80 weiter
Abbildung 9.20: Tunneln eines anderen Protokolls ber HTTP.
3. Der Proxy analysiert den HTTP-Verkehr, kann aber aufgrund der Einkapselung keine Besonderheiten entdecken und fhrt die gewnschte, scheinbare HTTP-Kommunikation mit
X aus.
4. X ist der Tunnel-Server. Er nimmt HTTP-Anfragen entgegen, entfernt die Einkapselung
wieder und kommuniziert dann mit dem eigentlichen Email-Server Y ber das POP-Protokoll. Die von dort erhaltenen Daten werden wiederum in HTTP eingekapselt ber den
Proxy an B geschickt, wo sie entpackt und an A gesendet werden.
Somit sind also weder am Email-Server noch am Email-Client irgendwelche Modikationen
notwendig. Programme, die wie oben beschrieben funktionieren, kursieren tatschlich im Internet, beispielsweise das HTTPTunnel-Projekt [SF-Web].
Abwehrmanahmen gegen solche Tunnel sind schwierig und greifen nicht in jedem Fall, sind
aber manchmal mglich. Durch die Verwendung von ALGs kann die Verwendung eines Protokolls zum Tunneln eines anderen Protokolls durch Analyse der genauen Anfragedaten auf
Applikationprotokollebene in einigen Fllen festgestellt werden und der Zugriff auf bekannte
Tunnel-Server im Internet unterbunden werden.
Doch es geht noch schlimmer. Durch die Verschlsselung der durch den Tunnel befrderten
Information ist es nmlich nahezu unmglich, das Umgehen der Firewall ber ein ALG zu unterbinden, jedenfalls nicht, ohne die erlaubten Internetzugriffe ausgesprochen restriktiv zu handhaben. Wir werden verschlsselte Tunnel in Kapitel 13.2.3 noch im Detail betrachten.
Eine Firewall kann aus verschlsselten Daten keinerlei Informationen extrahieren. Daher sind
hchstens indirekte Versuche mglich, zwischen harmlosen und potentiell gefhrlichen Vorgngen zu unterscheiden. Aus diesem Grund sind Daten, die eine Firewall verschlsselt passierern,
generell sehr problematisch.
190
9 Firewalls
9.5 Personal Firewalls

Speziell dann, wenn ein Rechner in einem ffentlichen Netz betrieben werden soll, ist eine naheliegende Idee, auf dem Rechner ein Programm zu betreiben, das die Funktion einer Firewall auf
der Maschine selbst bernimmt. Solche Programme werden als Personal Firewall bezeichnet.
Eine Personal Firewall sitzt konzeptionell an der Verbindungsstelle von Rechner und Netzwerk und kontrolliert den Verkehr zwischen der Maschine und dem Netzwerk nach festgelegten
Regeln, genau wie eine Firewall auch. Wenn der Rechner also einen Dienst anbietet, kann dieser vom Netzwerk aus nur dann kontaktiert werden, wenn die Personal Firewall entsprechend
konguriert ist.
Vom Arbeitsprinzip hneln Personal Firewalls in den meisten Ausprgungen Paketltern, wobei jedoch durch den mglichen Zugriff auf lokale Zusatzinformationen eine feingranularere
Filterung mglich ist. Lokal kann leicht festgestellt werden, welche Anwendung ein Paket erzeugt hat und welcher Benutzer die Anwendung betreibt. Daher ist es mglich, den Zugriff auf
bestimmte Dienste auf bestimmte Anwendungen zu beschrnken, beispielsweise genau festzulegen, dass nur der Webbrowser Anfragen auf den HTTP-Standardport 80 durchfhren darf.
Personal Firewalls werden meistens durch die Benutzer selbst administriert, was aufgrund der
notwendigen Kenntnisse relativ problematisch ist. Oftmals werden die Regeln einer Personal Firewall erstellt, indem der Benutzer bei erstmals auftretendem Netzwerkverkehr gefragt wird, wie
verfahren werden soll. Das ist fr einen normalen Benutzer manchmal schwierig abzuschtzen,
und eine falsche Antwort kann fatale Folgen haben. Darber hinaus kann eine Personal Firewall,
da sie ja auf dem Rechner selbst luft, durch Malware auch abgeschaltet werden, so dass sie im
Falle einer Kompromittierung des Rechners nicht unbedingt Schutz bieten kann.
Bei Verbindungsanfragen vom lokalen Rechner ins Netz kann eine Personal Firewall oftmals
aufgrund der Rckfragen an den Benutzer (die bei manchen Produkten von Art und Umfang her
hart an einer Ntigung vorbeischrammen) als sehr strend empfunden werden. Umgekehrt ist
eine Personal Firewall bei eingehenden Verbindungsanfragen eigentlich auch unsinnig. Wird auf
dem Rechner ein Service betrieben, der unerwnscht ist, so sollte man diesen abschalten, anstatt
ihn durch die Personal Firewall zu blockieren. Wenn der Service erwnscht und notwendig ist,
muss die Personal Firewall Anfragen an den Dienst ohnehin durchlassen.
Trotz dieser konzeptionellen Schwierigkeiten bieten Personal Firewalls einen sinnvollen und
sehr empfehlenswerten Schutz, wenn der betreffende Rechner in einem ffentlichen oder teilweise ffentlichen Netz betrieben werden soll.
9.6 Zusammenfassung
Firewalls kontrollieren und protokollieren die Kommunikation zwischen dem Internet
und dem Intranet einer Institution. Gem festgesetzter Regeln wird zwischen erlaubtem und unerlaubtem Verkehr unterschieden und unerlaubter Verkehr unterbunden.
9.7 bungsaufgaben
191
Firewalls bestehen meistens aus Paketltern, die den Verkehr auf Netzwerk- und
Transportprotokollebene ltern, und aus Application-Level-Gateways, welche die
Kommunikation auf Applikationsebene berwachen. Die Firewall unterteilt das Intranet meistens in mehrere Zonen. Server, die extern erreichbare Dienste anbieten sollen,
werden in der sogenannten Demilitarized Zone (DMZ) platziert, so dass von solchen
Maschinen der Zugriff auf andere Rechner im Intranet nochmals kontrolliert und unterbunden werden kann.
Firewalls besitzen intrinsische Schwchen, da es Mglichkeiten gibt, Daten an der
Firewall vorbei in das Intranet zu schleusen oder Kommunikationsverbindungen unter Umgehung der Firewall aufzubauen. Trotz dieser Schwachstellen sind Firewalls
ein wichtiger Baustein, um interne Ressourcen vor Angriffen aus dem Internet zu
schtzen. Aufgrund der beschriebenen Schwachstellen sollte und darf eine Firewall
aber keinesfalls der einzige Schutzmechanismus sein. Darber hinaus genieen in den
seltensten Fllen alle Nutzer im Intranet den gleichen Vertrauensstatus. Rechner und
Dienste, die durch die Firewall geschtzt sind, sollten daher mit den gleichen Manahmen geschtzt werden, wie wenn sie ohne Firewall betrieben wrden.
9.7 bungsaufgaben
Aufgabe 9.1:
Erlutern und erklren Sie die folgenden Begriffe: Firewall, Paketlter, Application-LevelGateway, Intranet, Tunnel, Demilitarized Zone.
Aufgabe 9.2:
Erlutern Sie die Funktionsweise eines Paketlters.
Aufgabe 9.3:
Erlutern Sie, was Network Address Translation ist, und beschreiben Sie die Funktionsweise.
Aufgabe 9.4:
Nennen Sie mgliche Komponenten einer Firewall.
Aufgabe 9.5:
Erklren Sie prinzipielle Schwachstellen im Konzept von Firewalls.
Aufgabe 9.6:
Beschreiben Sie, was unter dem Begriff Tunneling verstanden wird und warum dieses Prinzip
die Sicherheit von Firewalls aushebeln kann.
192
9 Firewalls

Aufgabe 9.7:
Skizzieren Sie die Auswirkung der Verwendung von Verschlsselungsmechanismen auf Paketlter und Application-Level-Gateways.
Aufgabe 9.8:
In Abschnitt 9.2.1.6 haben wir als ersten Versuch ICMP-Verkehr in der Firewall blockiert, so
dass der ICMP-Echo-Request von 10.2.4.37 an 172.16.2.20 in der Firewall hngen blieb. Geben
Sie Firewallregeln an, so dass der ICMP-Echo-Request zwar zunchst die Firewall passiert, aber
der zugehrige ICMP-Echo-Response durch die Firewall blockiert wird. Beobachten Sie das
jeweilige Verhalten der Firewall durch einen Sniffer.
Aufgabe 9.9:
Befassen Sie sich mit der Paketlterstruktur des Linux-Kernels. Studieren Sie die Man-Pages des
Befehls
und bauen Sie mittels dieses Befehls ihre eigene Firewall auf. Die Firewall
soll eine bestimmte Verbindung (HTTP zu einem Rechner o..) durchlassen und andere Verbindungen blockieren. Entwerfen Sie verschiedene Firewall-Kongurationen, die das gewnschte
Verhalten haben und testen Sie sie. Untersuchen Sie Auswirkungen von Regelnderungen auf
das Verhalten der Firewall und erlutern Sie die Ursachen.
Aufgabe 9.10:
Im Folgenden betrachten wir einen Linux-Paketlter. In
sind die Zustnde einer TCP-Verbindung angegeben, wie sie durch die Firewall beobachtet wurden. Diskutieren Sie
die Frage, inwieweit diese Zustnde exakt den tatschlichen Zustnden der Verbindung bei den
Endpunkten entsprechen. Geben Sie Beispiele fr Situationen, in denen diese Zustnde voneinander abweichen, und erlutern Sie, inwieweit diese Zustandsabweichungen problematisch sein
knnten.
Aufgabe 9.11:
Informieren Sie sich ber die genaue Funktionsweise von
. Wir betrachten ein Intranet
10.5.3.0/24, das mit dem Internet ber einen Linux-Paketlter verbunden ist. Geben Sie Befehle
an, mit denen sich folgende Zielsetzungen erreichen lassen:
Vom Intranet aus sollten beliebige TCP-Verbindungen ins Internet aufgebaut werden knnen. Alle anderen Verbindungen sollen an der Firewall nicht durchgelassen werden. Geben
Sie fr dieses Szenario sowohl statische als auch dynamische Filterregeln an.
Zustzlich soll von einem Rechner im Internet mit IP-Adresse 192.168.35.88 aus auf den
Port 12345 von Rechner 10.5.3.43 eine TCP-Verbindung aufgebaut werden drfen.
Kapitel 10
Virtual
10
Virtual Private
Private Networks (VPN)
Networks (VPN)
10.1 Einfhrung
Durch die Verwendung von Firewalls werden Ressourcen im Intranet, beispielsweise ein Webserver mit internen Webseiten oder auch der Zugriff auf eine Datenbank mit Kundendaten oder
Preisinformationen, vor Zugriffen aus dem Internet geschtzt. Dies wirft jedoch Probleme auf,
denn es gibt bei vielen Institutionen Nutzer, denen aus dem Internet heraus der Zugriff auf solche
Daten eigentlich gewhrt werden sollte. Auendienstmitarbeiter oder Institutionsangehrige, die
von zu Hause aus im Home Ofce arbeiten mchten, verfgen hug bereits ber eine breitbandige Internetanbindung, knnen jedoch aufgrund der Firewall nicht auf das Intranet der Institution
und die dort vorhandenen Ressourcen und Dienste zugreifen (siehe Abbildung 10.1). Der Zugriff auf das Intranet vom Internet aus wird auch als Remote-Access (RAS) bezeichnet. Fr dieses
Problem bieten sich mehrere Lsungsmglichkeiten an:
Verwendung einer direkten Einwahlverbindung (Modem): Die Institutionsangehrigen knnen eine direkte Einwahlverbindung ber ein Modem in die Firma aufbauen und erhalten
Server im Intranet
Internet
Intranet
Firewall
Auendienstmitarbeiter
Abbildung 10.1: Firewalls blockieren den Zugriff auf Ressourcen im Intranet fr Auendienstmitarbeiter
oder Mitarbeiter, die von zu Hause aus arbeiten.
194
Internet
Intranet
Abbildung 10.2: Idee hinter einem Remote-Access-VPN.
so Zugang zum Intranet. Bei der Einwahl muss eine sichere Authentikation des Benutzers
erfolgen. Nachteil dieser Lsung sind die anfallenden Kosten und die geringe Bandbreite.
In den meisten Fllen erfolgt der Zugriff auf das Intranet von Orten aus, die ber einen
breitbandigen Internetanschluss verfgen, fr dessen Nutzung zudem weitaus geringere
Kosten anfallen als bei der Einwahl ber ein Modem.
Bereitstellung der bentigten Dienste und Ressourcen im Internet: Die nur im Intranet verfgbaren Dienste knnten in die DMZ verschoben werden. Dies wrde den Einsatz entsprechender Authentikationsmechanismen auf Applikations- oder Transportebene erfordern. Zustzlich wre eventuell eine Verschlsselung und Authentikation der Verbindung
notwendig, um passive und aktive Angriffe auf die Daten im Internet zu verhindern.
Die erste vorgeschlagene Variante einer Einwahlverbindung wird, letztlich aufgrund der geringen Bandbreite und der hohen Kosten etwa bei der Einwahl aus dem Ausland, heute nur noch
in sehr seltenen Fllen praktiziert. Die zweite Variante ist zumindest zum Teil praktikabel. Die
notwendigen Manahmen, um einen Server extern zugnglich zu machen (Umstellung auf Verschlsselung und gegebenenfalls Vernderung der Authentikationsmethoden, Verlagerung in
die DMZ, Abschalten unntiger Dienste usw.), knnen aber sehr umfangreich sein. Da die jeweilige Vorgehensweise stark von dem spezischen Dienst selbst abhngt, bietet sich dieses
Vorgehen nur dann an, wenn wenige Dienste extern verfgbar gemacht werden sollen.
Gerade in den Intranets groer Institutionen ndet sich meist eine Vielzahl von Diensten und
Ressourcen, so dass die Durchfhrung entsprechender Manahmen, um die Dienste extern zugnglich zu machen, viel zu aufwendig wre und aufgrund der Exposition extern verfgbarer
Server gegenber Angriffen auch nicht unbedingt ratsam erscheint. Es gibt nmlich eine einfachere Mglichkeit, die Virtual Private Networks (VPNs).
Ein Virtual Private Network ermglicht das Betreiben einer sicheren, scheinbar direkten Punktzu-Punkt-Verbindung zwischen zwei Stationen, hnlich einer ausschlielich fr diesen Zweck
verwendeten direkten Leitung, durch die Verwendung eines mglicherweise unsicheren Netzes
wie des Internets als Verbindungsmedium. VPNs knnen sowohl ber Software als auch durch
Hardware realisiert werden.
10.2 Technische Realisierung eines Remote-Access-VPNs
195
verschlsseltes, getunneltes
Paket von z nach w
VPN-Tunnel
Ziel:y Quelle:x
interner Server W
IP-Adresse w
verschlsseltes Paket
Internet
Intranet
Ziel:w Quelle:z
VPN-Client R
Internet IP-Adresse x
VPN IP-Adresse z
Ziel:y Quelle:x
VPN-Server S
IP-Adresse y
Ziel:w Quelle:z
Daten
Daten
Ziel:w Quelle:z
Ziel:y Quelle:x
Daten
Abbildung 10.3: Mgliche technische Realisierung eines RAS-VPNs.
Die Verwendung von VPNs zur Realisierung von Remote-Access ist in Abbildung 10.2 schematisch dargestellt. Dieses Szenario ist nur eine von mehreren mglichen Verwendungen fr
VPNs. Einige der anderen Einsatzmglichkeiten werden wir spter diskutieren.
Durch Verwendung eines VPNs kann also der Rechner des Auendienstmitarbeiters so betrieben werden, als ob er sich im Intranet befnde, und erhlt damit auch Zugriff auf alle dort
verfgbaren Dienste und Ressourcen. Beim Aufbau des VPNs erfolgt eine Authentikation, so
dass nur autorisierte Benutzer ber das VPN Zugriff erhalten knnen. Es versteht sich von selbst,
dass die VPN-Verbindung die Vertraulichkeit, Integritt und Authentizitt der bertragenen Daten gewhrleisten muss.
10.2 Technische Realisierung eines Remote-Access-VPNs

Wie der Begriff Punkt-zu-Punkt-Verbindung nahelegt, werden die Rechner durch den Aufbau
des VPNs faktisch auf der Netzwerk- oder Datenverbindungsschicht zu einem Teil des Intranets.
Betrachten wir hierzu Abbildung 10.3, die ein Beispiel zeigt. Rechner R ist im Internet und hat
IP-Adresse x. Auf R luft eine spezielle Software, der VPN-Client, der ber das Internet mit
dem VPN-Server S der Institution eine Verbindung aufbaut. Der VPN-Server hat die IP-Adresse
y. Meistens benden sich VPN-Server in der DMZ. Der VPN-Client authentiziert sich und
es werden Schlssel vereinbart, mit denen die Kommunikation zwischen dem VPN-Client und
dem VPN-Server kryptographisch geschtzt wird. Zustzlich zu seiner eigentlichen Internet-IPAdresse x erhlt der Rechner beim Aufbau der VPN-Verbindung eine zustzliche IP-Adresse z
196
scheinbare
Position im Intranet
Intranet IP-Adresse
Internet IP-Adresse
Tunnel
Netzwerkschicht
VPN
Abbildung 10.4: Mgliche technische Realisierung eines RAS-VPNs im Referenzmodell.
aus dem Adressbereich des Intranets zugewiesen. Alle Anwendungen auf dem Rechner verwenden ausschlielich diese Adresse z fr die Kommunikation ber das Netzwerk und benden sich
so virtuell im Intranet. Die VPN-Client-Software auf dem Rechner nimmt die von den Anwendungen eingehenden Pakete entgegen und tunnelt diese Pakete verschlsselt an den VPN-Server.
Dafr wird die eigentliche IP-Adresse x des Rechners verwendet.
In der Abbildung ist dies exemplarisch verdeutlicht. R will mit einem Rechner W mit IPAdresse w kommunizieren, beispielsweise einem Webserver. Hierdurch entsteht durch ein Anwendungsprogramm auf R ein Paket mit IP-Quelladresse z und IP-Zieladresse w. Dieses Paket
wird nach Anwendung kryptographischer Methoden zur Verschlsselung und Gewhrleistung
der Integritt als Nutzlast vollstndig in ein neues IP-Paket eingekapselt. Dieses neue IP-Paket
enthlt als IP-Quelladresse die eigentliche Internet-Adresse x des Rechners und ist an den VPNServer gerichtet, trgt also IP-Zieladresse y. Der VPN-Server empfngt dieses Paket, entschlsselt, berprft und entkapselt es und sendet dann das ursprnglich von der Anwendung erzeugte
Paket mit IP-Quelladresse y und Zieladresse w weiter.
Der VPN-Tunnel ist fr den Server W vollkommen transparent. Er erhlt ein Paket von der
IP-Adresse z, an die er auch wieder antwortet. Dieses Paket nimmt der VPN-Server S entgegen
und tunnelt sie analog wie oben beschrieben an R weiter.
Aus Sicht von Anwendung und Transportschicht bendet sich der Rechner also direkt im Intranet. Authentikation, Verschlsselung und Integrittsberprfung erfolgen durch das VPN,
das entweder auf der Datenverbindungsschicht oder der Netzwerkschicht residiert. Der hier exemplarisch geschilderte Betrieb eines VPNs auf der Netzwerkschicht ist in Abbildung 10.4 im
Kontext des Referenzmodells abgebildet.
10.3 VPNs als Ersatz dezidierter Datenleitungen

R1 Ziel: R2 Quelle:R1 Daten
Ziel:G2 Quelle:G1
G1
Ziel: R2 Quelle:R1 Daten R2

Internet
G2
IntranetSite B
IntranetSite A
VPN-Endpunkt
197
VPN-Tunnel
(verschlsselt)
VPN-Endpunkt
Abbildung 10.5: VPN als Ersatz einer dezidierten Datenleitung.
10.3 VPNs als Ersatz dezidierter Datenleitungen

VPNs knnen nicht nur verwendet werden, um eine sichere, scheinbar direkte Punkt-zu-PunktVerbindung zwischen einem einzelnen Rechner und einem Gateway herzustellen, sondern VPNs
knnen genauso zwei Gateways miteinander verbinden.
Betrachten wir hierzu ein Beispiel. Eine Firma besitzt zwei Standorte A und B, die jeweils
breitbandig an das Internet angeschlossen sind. An jedem der beiden Standorte betreibt die Firma
Netzwerke, die durch eine Firewall vom Internet separiert sind. Natrlich ist es naheliegend, die
Netzwerke an beiden Standorten zu einem Intranet verbinden zu wollen. Hierzu gibt es verschiedene Mglichkeiten, wie beispielsweise das Verlegen oder Mieten einer exklusiven, direkten
Leitung zwischen den beiden Standorten. Einfacher und billiger ist es jedoch, die bestehenden
Internetverbindungen an beiden Standorten zu nutzen und ein gemeinsames Intranet durch ein
VPN zu schaffen. Konzeptionell besteht zwischen dem RAS-VPN, wie wir es schon kennengelernt haben, und dem VPN zur Verbindung zweier privater Netzwerke ber das Internet kein
allzu groer Unterschied, abgesehen von der Tatsache, dass nun zwei Gateways (Router, Switches) durch das VPN verbunden sind. Eine beispielhaftes Szenario fr den Betrieb eines solchen
VPNs ist in Abbildung 10.5 gezeigt.
Wenn also Pakete von Rechner R1 in Intranet A zu Rechner R2 in Intranet B geschickt werden sollen, so werden die Pakete im Intranet A von R1 zu Gateway G1 geschickt. Gateway G1
verschlsselt diese Pakete, kapselt sie ein und schickt sie durch das VPN ber das ffentliche
Internet an das Gateway G2. Dort werden die Pakete entschlsselt und im Intranet B zu R2 weitergeleitet. Die jeweiligen Endpunkte wissen nichts von dem bestehenden VPN.
Umgekehrt luft der Prozess analog ab. Im Falle eines solchen VPNs zwischen zwei Gateways
erfolgt der Aufbau des VPNs auch zwischen diesen Gateways. Die Gateways benutzen dann
das aufgebaute VPN wie eine private dezidierte Leitung untereinander und leiten ber diese
Verbindung Pakete weiter.
Aufgrund der Einkapselung, Verschlsselung und des Tunnelns der Pakete kann ein passiver
Angreifer, der die Pakete mitlesen kann, nicht allzu viele Informationen aus dem Verkehr ent-
198
TCP
UDP
IP
IPsec
IEEE
802.11
Ethernet
...
Transportschicht
Netzwerkschicht
Abbildung 10.6: Position von IPsec im Protokollstack.
nehmen. Insbesondere lassen sich auch die IP-Adressen der eigentlichen Endpunkte der Kommunikation, R1 und R2, nicht erkennen.
Es ist wesentlich zu bemerken, dass durch VPNs in beiden betrachteten Anwendungsfllen die
Kommunikationsdaten nicht Ende-zu-Ende, sondern nur auf der durch das VPN abgesicherten
Teilstrecke verschlsselt werden. In unserem obigen Beispiel ist das Paket nur zwischen G1 und
G2 verschlsselt, nicht aber zwischen R1 und G1 oder G2 und R2. Daher ersetzen VPNs in
keinem Fall eine Ende-zu-Ende-Verschlsselung, die fr vertrauliche Informationen auf jeden
Fall zustzlich vorgenommen werden sollte.
10.4 IPsec
10.4.1 Einfhrung
Im Folgenden wollen wir ein wichtiges Protokoll nher vorstellen, mit dem sich ein VPN zwischen zwei Stationen realisieren lsst, nmlich IPsec. Dieses Protokoll ist in [RFC 4301] festgelegt. IPsec speziziert die Bereitstellung von Sicherheitsdiensten auf der IP-Schicht und arbeitet
sowohl mit IPv4 als auch mit dem neuen IPv6-Protokoll. Die Verwendung von IPsec zum Betrieb
eines VPNs ist nur eine der Anwendungsmglichkeiten von IPsec.
Im Protokollstack ist IPsec konzeptionell auf der Netzwerkschicht angesiedelt und sitzt zwischen dem IP-Protokoll und der Datenverbindungsschicht. Dies ist in Abbildung 10.6 skizziert.
Implementiert wird IPsec meistens direkt als ein Bestandteil der Implementierung von IP auf
einer Maschine, es ist aber auch mglich, IPsec eigenstndig zu implementieren und zwischen
IP und der Datenverbindungsschicht zu betreiben.
IPsec arbeitet verbindungslos und beinhaltet zwei Sicherheitsprotokolle, nmlich Authentication Header (AH) und Encapsulating Security Payload (ESP), welche in [RFC 4302] bzw.
[RFC 4303] deniert sind. Systeme, die IPsec implementieren, mssen ESP beinhalten, das AHProtokoll ist optional. Die Protokolle besitzen folgende Merkmale:
Authentication Header (AH): Ermglicht Authentikation des Senders und Integrittsschutz der Pakete, aber keine Verschlsselung.
Encapsulating Security Payload (ESP): Ermglicht Authentikation des Senders, Integrittsschutz der Pakete und Verschlsselung.
10.4 IPsec
199
Beide Protokolle ermglichen einen beschrnkten Schutz gegen sogenannte Angriffe durch
Replays, also das nochmalige Absenden von zwischen den Stationen bertragenen Paketen durch
einen Angreifer.
Grundlage von IPsec ist das Konzept einer Security Association (SA). Eine SA ist eine Vereinbarung zwischen zwei Stationen, die die Bereitstellung von Sicherheitsdiensten fr zwischen
diesen Stationen ausgetauschten IP-Paketen ermglicht. IPsec verfgt ber vielfltige Kongurationsoptionen, die beim Aufbau der SA zwischen den Stationen vereinbart werden. Unterschiedliche SAs knnen also unterschiedlich konguriert sein und damit unterschiedliche Sicherheitsdienste bereitstellen. Jede SA verwendet als Protokoll entweder ESP oder AH. Eine
SA ist immer unidirektional, betrifft also nur Pakete in eine Richtung, nicht aber in die umgekehrte Richtung. Dokumente, die festlegen, wie eine SA aufgebaut und im laufenden Betrieb
aufrechterhalten werden kann, sind Teil der IPsec-Spezikation, nmlich in Form des Internet
Key Exchange Protocol (IKE) (gegenwrtig wird Version 2 dieses Protokolls verwendet, daher
auch IKEv2 abgekrzt) [RFC 4306]. Hierbei erfolgen unter anderem die Authentikation und
der Austausch von Schlsseln. Da in den meisten Fllen durch IPsec die Kommunikation zwischen den Stationen bidirektional, also in beide Richtungen abgesichert werden soll, untersttzt
IKE direkt den Aufbau von zwei SAs zwischen den Stationen, eine in die Hin- und die andere in
die Rckrichtung.
Die unterschiedlichen SAs und ihre jeweiligen Kongurationen werden in einer Datenbank,
der Security Association Database (SAD) gespeichert. Jede SA kann eindeutig anhand folgender
drei Parameter identiziert werden:
IP-Zieladresse,
verwendetes Sicherheitsprotokoll (AH oder ESP),
Security Parameter Index (SPI). Dabei handelt es sich um einen 4 Byte-Wert, der dazu
dient, auch verschiedene SAs mit gleicher Zieladresse und gleichem Sicherheitsprotokoll
unterscheiden zu knnen.
Da diese Informationen in jedem eingehenden Paket enthalten sind, kann die zugehrige SA
einfach bestimmt werden. Eine SA kann den ganzen Verkehr zwischen zwei Stationen umfassen
oder auch nur Teile davon. So knnen ber mehrere SAs auch unterschiedliche Sicherheitsdienste
zwischen den Stationen existieren. Zu einem Zeitpunkt knnen also zwischen zwei Stationen
mehrere SAs gleichzeitig aktiv sein; jede Station kann darber hinaus noch weitere SAs mit
anderen Stationen betreiben.
IPsec verfgt ber eine Security Policy Database (SPD). Diese Datenbank hnelt der Regelkette einer Firewall und funktioniert auch ganz analog. Es lassen sich sogenannte Selektoren
angeben. Sie sind den Regeln in den Regelketten einer Firewall hnlich. Mgliche Selektoren
sind unter anderem:
IP-Adresse der Gegenstelle (IP-Quelladresse bei ankommenden, IP-Zieladresse bei ausgehenden Paketen), auch die Angabe eines Adressbereichs ist mglich, etwa um Routing
zu einer Gruppe von Stationen ber eine gesicherte Verbindung zu einem Gateway durchzufhren.
200
Lokale IP-Adresse (IP-Zieladresse bei ankommenden, IP-Quelladresse bei ausgehenden

Paketen), auch die Angabe eines Adressbereichs ist mglich.
Protokoll der darberliegenden Schicht.
Weitere Selektoren sind mglich.
Fr alle eingehenden und ausgehenden IP-Pakete konsultiert IPsec die SPD-Datenbank, um zu
bestimmen, wie mit dem Paket zu verfahren ist. Jeder Eintrag enthlt Selektoren und bestimmt,
wie mit einem matchenden Paket verfahren wird. Hierbei gibt es drei Mglichkeiten:
Das Paket wird verworfen und gelscht (discard).
Das Paket wird unverndert durchgelassen (bypass).
Das Paket wird durch IPsec geschtzt (protect). In diesem Fall enthlt die SPD einen Eintrag, durch welche SA das Paket geschtzt wird, und einen entsprechenden Verweis in
die SAD. Falls noch keine SA besteht, nden sich in der SPD Informationen, wie eine
entsprechende SA aufgebaut werden kann.
Eine SA kann entweder im Tunnel-Modus oder im Transport-Modus angewendet werden. Die
verschiedenen Modi besitzen folgende Charakteristika:
Tunnel-Modus: Wird eine SA zwischen zwei Stationen im Tunnel-Modus etabliert, so werden die Pakete, welche durch die SA abgesichert werden sollen, zwischen diesen Systemen
getunnelt. Das zu sichernde IP-Paket wird komplett in ein neues IP-Paket eingekapselt, mit
einem zustzlichen IP-Header versehen und zwischen den Systemen getunnelt. IP-Quellund IP-Zieladresse des neuen Headers sind die durch die SA verbundenen Systeme. Die
geschtzten Pakete werden dann via IP zwischen diesen Systemen befrdert und auf der
anderen Seite des Tunnels wieder entpackt und dann weiterbehandelt. Dies ist die typische Betriebsart fr VPNs und entspricht dem in Abbildungen 10.3 und 10.5 skizzierten
Vorgehen.
Transport-Modus: IPsec kann auch zur Ende-zu-Ende-Verschlsselung von Paketen verwendet werden. Hierfr ist der Transportmodus vorgesehen. In diesem Modus wird der
IP-Header des geschtzten Pakets, insbesondere Quelladresse und Zieladresse, durch IPsec nicht verndert. Daher muss die SA direkt zum Zielsystem des Pakets bestehen. Dieser
Modus kann vor allem zur Ende-zu-Ende-Absicherung zwischen zwei Stationen verwendet werden. Er eignet sich nicht ohne weiteres zur Absicherung des Verkehrs zwischen
zwei Gateways oder zwischen einem VPN-Client und einem VPN-Server.
10.4.2 Das AH-Protokoll

AH ermglicht die Authentikation des Senders von Paketen sowie eine Integrittskontrolle.
Diese Integrittskontrolle schliet die wichtigsten Felder des IP-Headers selbst mit ein.
IP-Pakete, die von IP-Sec durch eine SA und das AH-Protokoll geschtzt werden, tragen im
IP-Header im Protokoll-Feld die Nummer 51. Das AH-Header-Format ist in Abbildung 10.7
skizziert. Die einzelnen Felder haben dabei folgende Bedeutung:
10.4 IPsec
201
Byte
Bit
Next Header
Payload Length
Security Parameter Index (SPI)
Sequence Number
Reserved
Integrity Check Value (ICV), variable Lnge
Abbildung 10.7: Authentication Header.
Next Header (1 Byte): Speziziert den Typ der transportierten Information (Protokoll auf
der nchsten Schicht). Spezische Werte sind z.B. 6 fr TCP, 17 fr UDP oder 4 fr IP-inIP-Einkapselung (Tunnel-Modus).
Payload Length (1 Byte): Lnge des AH-Headers in 4-Byte-Schritten minus 2.
Reserved (2 Byte): Reserviert fr die Nutzung in einer zuknftigen Protokollversion.
Security Parameter Index (SPI) (4 Byte): Wert, der zusammen mit der IP-Adresse und dem
verwendeten Sicherheitsprotokoll (AH) die eindeutige Zuordnung des Pakets zu einer SA
ermglicht.
Sequence Number (4 Byte): Zhler, der bei Etablierung der SA auf null gesetzt wird und
vom Sender bei jedem zur SA gehrenden verschickten Paket um eins inkrementiert wird.
Ermglicht die Verhinderung von Replay-Angriffen. Falls der Maximalwert erreicht wird,
muss eine neue SA aufgebaut werden, es wird also nicht wieder bei null fortgefahren.
Aufgrund dieser Beschrnkung, die insbesondere fr Verbindungen mit hoher Bandbreite
problematisch ist, besteht die Mglichkeit, sich beim Aushandeln der SA auf eine 8 Byte
lange Sequenznummer zu einigen. Dabei werden dann nur die letzten vier Bytes in diesem
Feld bertragen, whrend die ersten vier Bytes nur in die Berechnung der Prfsumme
eingehen und so veriziert werden.
Integrity Check Value (ICV) (variable Lnge): Enthlt den Integrittskontrollwert fr das
bertragene Paket. Die Lnge dieses Feldes hngt vom verwendeten Algorithmus zur Integrittskontrolle ab, der durch die SA festgelegt ist. Die Lnge dieses Feldes ist ein Vielfaches von vier Bytes. Falls ntig, erfolgt Padding.
Je nachdem, ob AH im Transport-Modus oder im Tunnel-Modus verwendet wird, unterscheidet sich die Struktur des Pakets nach Anwendung des Protokolls. Der AH ist jeweils direkt hinter
dem IP-Header eingebracht. Wie in Abbildung 10.8 skizziert, folgt darauf dann der Datenteil
des IP-Pakets. Im IP-Header ndert sich der Wert des Protokoll-Feldes auf 51; der ursprngliche
Wert ndet sich im Next-Header Feld des AH wieder.
Die Integrittskontrolle von AH erstreckt sich ber das gesamte so erstellte Paket, abgesehen
von einigen Feldern des IP-Headers, die sich bei der Befrderung durch das Netz ndern knnen,
wie etwa das Time-to-live-Feld oder die Header Checksum.
202

ursprngliches
IP-Paket
IP-Header
nach Anwendung
von AH im
Transportmodus
IP-Header
Daten
AH
Daten
Integrittsschutz (ausgenommen vernderbare Felder im IP-Header)
Abbildung 10.8: Authentication Header im Transport-Modus.

ursprngliches
IP-Paket
IP-Header
nach Anwendung
von AH im
neuer IP-Header
Tunnelmodus
Daten
AH
IP-Header
Daten
Integrittsschutz (ausgenommen vernderbare Felder im neuen IP-Header)
Abbildung 10.9: Authentication Header im Tunnel-Modus.
Im Tunnel-Modus wird der AH zusammen mit dem unvernderten ursprnglichen Paket in

ein neues IP-Paket eingebaut (siehe Abbildung 10.9). Der AH folgt direkt nach dem neuen IPHeader, danach dann das ursprngliche Paket. Die Integrittskontrolle umfasst das komplette
ursprngliche IP-Paket, inklusive aller Header-Felder (die sich ja whrend des Tunnelns nicht
ndern) sowie alle unvernderlichen Felder des neuen IP-Headers.
10.4.3 Das ESP-Protokoll

ESP ermglicht neben der Sicherstellung der Integritt durch Authentikation des Senders der
Pakete und der Integrittskontrolle der Pakete auch die Gewhrleistung der Vertraulichkeit durch
Verschlsselung. Das Protokoll erlaubt die unabhngige Verwendung von Mechanismen zum
Integrittsschutz und zur Verschlsselung, kann also diese Dienste auch einzeln anbieten. Typischerweise wird ESP aber zum Schutz von Integritt und Vertraulichkeit eingesetzt.
IP-Pakete, die von IP-Sec durch eine SA und das ESP-Protokoll geschtzt werden, tragen im
IP-Header im Protokoll-Feld die Nummer 50. Das ESP-Format ist in Abbildung 10.10 skizziert.
Die einzelnen Felder haben dabei folgende Bedeutung:
Security Parameter Index (SPI) (4 Byte): Wert, der zusammen mit der IP-Adresse und dem
verwendeten Sicherheitsprotokoll (ESP) die eindeutige Zuordnung des Pakets zu einer SA
ermglicht.
10.4 IPsec
203
Byte
Bit
Security Parameters Index (SPI)
Sequence Number
IV (optional)
Rest der Payload Data (variable Lnge)
TFC Padding (optional, variable Lnge)
Padding(0-255 Byte)
Pad Length
Next Header
Integrity Check Value (ICV), variable Lnge
Payload Data
Abbildung 10.10: Encapsulating Security Payload Format.
Sequence Number (4 Byte): Zhler, der bei Etablierung der SA auf null gesetzt wird und
vom Sender bei jedem zur SA gehrenden verschickten Paket um eins inkrementiert wird.
Ermglicht die Verhinderung von Replay-Angriffen. Falls der Maximalwert erreicht wird,
muss eine neue SA aufgebaut werden, es wird also nicht wieder bei null fortgefahren.
Es besteht wie bei AH die Mglichkeit, sich beim Aushandeln der SA auf eine 8 Byte
lange Sequenznummer zu einigen (vor der wiederum nur die letzten vier Bytes bertragen
werden).
Payload Data (variabel): Nutzlast, bestehend aus
IV (optional, variabel): Initialization Vector (falls fr den Verschlsselungsalgorithmus notwendig.
Rest der Payload Data (variabel): Eigentliche zu bertragende Daten.
TFC Padding (optional, variabel): Trafc Flow Condentiality Padding. Ermglicht
die Variation der Lnge der bertragenen Pakete. Durch (zuflliges oder gezieltes)
Vergrern der Pakete wird es fr einen Angreifer schwieriger oder sogar unmglich,
aufgrund der Gre der bertragenen Pakete Rckschlsse auf die darin enthaltene
Nutzlast zu ziehen.
Padding (0-255 Byte): Falls der Verschlsselungsalgorithmus Datenblcke einer bestimmten Mindestgre erfordert, wird dieses Feld verwendet, um die ursprnglichen Daten entsprechend aufzufllen. Die Lnge des ESP-Pakets muss darber hinaus ein Vielfaches von
vier Bytes sein.
Pad Length (1 Byte): Anzahl der gepaddeten Bytes.
Next Header (1 Byte): Speziziert den Typ der transportierten Information (Protokoll auf
der nchsten Schicht). Spezische Werte sind z.B. 6 fr TCP, 17 fr UDP oder 4 fr IP-inIP-Einkapselung (Tunnel-Modus).
204

ursprngliches
IP-Paket
IP-Header
Daten
nach Anwendung
von ESP im
Transportmodus
IP-Header
ESP-Header
Daten
ESP-Trailer ICV
Verschlsselung
Integrittsschutz
Abbildung 10.11: ESP im Transport-Modus.
Integrity Check Value (ICV) (variable Lnge): Enthlt den Integrittskontrollwert fr das
bertragene Paket. Die Lnge dieses Feldes hngt vom verwendeten Algorithmus zur Integrittskontrolle ab, der durch die SA festgelegt ist. Die Lnge dieses Feldes ist ein Vielfaches von vier Bytes. Falls ntig, erfolgt Padding.
Das SPI-Feld und die Sequenznummer werden zwar in den Integrittsschutz miteinbezogen,
aber immer unverschlsselt bertragen. Dies ist notwendig, da das SPI-Feld zur Bestimmung
der SA beim Eingang des Paketes bentigt wird und die Sequenznummer zur Verhinderung von
Replay-Angriffen ebenfalls im Klartext vorliegen muss (sonst knnte ein Angreifer den Empfnger zur Entschlsselung der Pakete zwingen, was ressourcenintensiv sein kann und als Ausgangspunkt fr einen Angriff dienen knnte, siehe Abschnitt 12.2). Das in obiger Struktur mit
Payload Data bezeichnete Feld enthlt die (verschlsselten) Daten des ursprnglichen Pakets
im Transport-Modus bzw. das gesamte ursprngliche Paket im Tunnel-Modus.
Je nachdem, ob ESP im Transport-Modus oder im Tunnel-Modus verwendet wird, unterscheidet sich die Struktur des Pakets nach Anwendung des Protokolls. ESP beginnt jeweils direkt
hinter dem IP-Header. Wie in Abbildung 10.11 skizziert, folgt darauf dann der Datenteil des IPPakets. Am IP-Header ndert sich der Wert des Protokoll-Feldes auf 50; der ursprngliche Wert
ndet sich im Next-Header Feld von ESP wieder.
Die Integrittskontrolle von ESP beinhaltet nicht den IP-Header. Die Verschlsselung umfasst
die Payload des ursprnglichen Pakets sowie Teile des ESP-Trailers.
Im Tunnel-Modus werden die fr ESP notwendigen Informationen zusammen mit dem ursprnglichen Paket (verschlsselt) in ein neues IP-Paket eingebaut, siehe Abbildung 10.12. Der
ESP-Header folgt direkt nach dem neuen IP-Header, danach dann das ursprngliche Paket. Integrittskontrolle und Verschlsselung umfassen das komplette ursprngliche IP-Paket, inklusive
aller Header-Felder, aber nicht ber den neuen IP-Header.
Whrend sich der Integrittsschutz von AH auch auf nicht vernderliche Felder des IP-Headers
erstreckt, schtzt ESP also ausschlielich die Daten im IP-Paket hinter dem ESP-Header, also im
Falle von Transport-Modus die Nutzlast des ursprnglichen IP-Paketes und im Falle von TunnelMode das gesamte ursprngliche Paket, nicht aber den neuen IP-Header. AH und ESP knnen
auch gemeinsam angewendet werden, so dass ebenfalls ein Integrittsschutz des gesamten ber-
10.4 IPsec
205
ursprngliches
IP-Paket
IP-Header
Daten
nach Anwendung
von ESP im
Tunnelmodus
IP-Header
ESP-Header
IP-Header
Daten
ESP-Trailer ICV
Verschlsselung
Integrittsschutz
Abbildung 10.12: ESP im Tunnel-Modus.
tragenen Pakets (bis auf vernderbare Header-Felder im IP-Header) durch AH und Verschlsselung durch ESP mglich ist.
10.4.4 Aufbau und Verwaltung von SAs und Schlsselmanagement

IPsec sieht zwei Varianten fr den Aufbau von SAs und das Management kryptographischer
Schlssel vor:
Manuelle Methoden: Die einfachste Form der Verwaltung und des Aufbaus einer SA ist
es, die notwendige Konguration eines Systems zur sicheren Kommunikation mit anderen
Systemen (Bereitstellung der Schlssel, Kongurationsdaten der SA) von Hand durchzufhren.
Automatische Methoden: Die zweite Mglichkeit ist die Verwendung eines automatischen
SA-Management Protokolls, welches die SA automatisiert aushandelt, aufbaut und verwaltet.
Der Vorteil einer manuellen Konguration ist die einfache Handhabbarkeit in kleinen Systemen, die sich nicht hug ndern und die der gleichen administrativen Kontrolle unterliegen, so
dass notwendige nderungen einfach durchgefhrt werden knnen. So eignet sich eine manuelle
Konguration zur Verbindung mehrerer Standorte einer Firma, sofern die Anzahl der Standorte
nicht zu gro ist. Wenn, was meistens der Fall ist, die Schlssel fr die verwendeten kryptographischen Verfahren fest vorkonguriert sind, ist der Wechsel des Schlssels nicht ohne weiteres
mglich.
Ganz allgemein ist die Skalierbarkeit, also die Verwendbarkeit des Verfahrens bei zunehmender Anzahl von am Verfahren teilnehmender Stationen, schlecht, da die manuelle Konguration
der Stationen aufwendig wird. Eine weitverbreitete Anwendung von IPsec, beispielsweise zur
Bereitstellung von Remote-Access fr Tausende von Mitgliedern einer Institution, ist auf diese
Weise nicht zu gewhrleisten. Fr ein solches Szenario wird ein automatisiertes Management von
SAs und kryptographischen Schlsseln notwendig, welches folgenden Anforderungen gengt:
Standardisiertes Verfahren zur bergreifenden Verwendung auf verschiedenen Plattformen
und zwischen verschiedenen Institutionen,
206
Zeit
IKE-Request
IKE-Response
IKE-Exchange
Abbildung 10.13: IKE-Exchange.
gute Skalierbarkeit,
hoher Automatisierungsgrad,
Erzeugung von SAs nach Bedarf.
Hierzu wurde das Internet Key Exchange Protocol [RFC 4306] speziziert, welches wir im
Folgenden nher darstellen wollen. IKE liegt seit 2005 in einer neuen Version vor (IKEv2).
IKEv2 ist nicht kompatibel zu der vorangegangenen Version 1 und umfasst auch Bestandteile,
die vorher separat speziziert waren, insbesondere das Internet Security Association and Key
Management Protocol (ISAKMP). IKE nutzt UDP Port 500, in einigen Fllen auch Port 4500
(bei UDP-Einkapselung der zu bertragenden IP-Pakete zur berwindung von Problemen mit
NATs). IKE ermglicht
die gegenseitige Authentikation der Kommunikationspartner,
den Aufbau einer IKE Security Association (IKE-SA), aus der SAs zur Verwendung von
IPsec abgeleitet werden knnen. Dies schliet insbesondere
das Bereitstellen kryptographischer Schlssel und
das Aushandeln der zu verwendenden kryptographischen Algorithmen
ein.
Wie in Abbildung 10.13 dargestellt, basiert das IKE-Protokoll auf einem einfachen RequestResponse-Schema. Ein Austausch von Request und Response wird IKE-Exchange genannt.
10.4 IPsec
207
Byte
Bit
IKE_SA Initiator's SPI
Next Payload
Major V.
IKE_SA Responder's SPI

Minor V.
Exchange Type
Message ID
Length
Flags
Abbildung 10.14: IKE-Header.
Zum Aufbau der IKE-SA sind mehrere IKE-Exchanges zwischen den Kommunikationspartnern notwendig. Diejenige Station, die den Aufbau begonnen hat, wird als Initiator bezeichnet, die andere Station als Responder. Bevor wir einige spezische Exchanges nher betrachten,
wenden wir uns kurz dem Headerformat von IKE zu. Der IKE-Header ist in Abbildung 10.14
dargestellt. Jedem Header folgen eine oder mehrere IKE-Payloads, die jeweils unterschiedliche
Formate haben knnen.
Die einzelnen Felder haben folgende Bedeutung:
IKE_SA Initiators SPI (8 Byte): Von der Station, welche die erste Nachricht zum Aufbau
der SA gesendet hat (Initiator), gewhlter Wert.
IKE_SA Responders SPI (8 Byte): Von der Station, welche die erste Nachricht zum Aufbau der SA erhalten hat (Responder), gewhlter Wert. Bei der ersten Nachricht einer neuen
IKE-Kommunikation ist dieser Wert null. Beide SPIs zusammen dienen zur eindeutigen
Identikation der IKE-SA.
Next Payload (1 Byte): Typ der direkt an den Header anschlieenden ersten Payload der
Nachricht.
Major Version (4 Bit): Version des Protokolls, derzeit 2.
Minor Version (4 Bit): Unterversionierungsnummer, derzeit 0.
Exchange Type (1 Byte): Gibt den Typ des Austauschs an. Dies gibt fr die folgende(n)
Payload(s) bestimmte Formate und Reihenfolgen vor. Die wichtigsten Exchange-Typen
sind
34: IKE_SA_INIT
35: IKE_AUTH
36: CREATE_CHILD_SA
37: INFORMATIONAL
Flags (1 Byte): Derzeit sind drei Flags deniert.

Initiator-Flag: Gesetzt, wenn die Nachricht vom Initiator der IKE-SA stammt.
208
Version-Flag: Gesetzt, wenn die sendende Station auch neuere Versionen von IKE
beherrscht als die in Major Version angegebene.
Response-Flag: Gesetzt, wenn dies die Response zu einem Request ist.
Die restlichen Bits sind fr zuknftige Versionen reserviert.
Message ID (4 Byte): Eindeutige ID fr den betreffenden Exchange. Request und Response eines Exchanges tragen dieselbe Message ID. Die Message ID des ersten Exchanges ist
null und wird bei jedem weiteren Exchange um eins erhht. Jede Station nummeriert ihre
Requests eigenstndig. Dieses Feld wird fr die Zuordnung von Responses zu Requests
und auch zur Erkennung der nochmaligen bertragung verlorengegangener Datagramme
und zur Verhinderung von Replay-Attacks verwendet.
Length (4 Byte): Lnge der IKE-Nachricht inklusive Header in Bytes.
Die Verwendung von IKE zum Aufbau einer IKE_SA beginnt immer mit einem Exchange des
Typs IKE_SA_INIT gefolgt von einem Exchange des Typs IKE_AUTH.
Im IKE_SA_INIT-Exchange werden die zu verwendenden kryptographischen Algorithmen
ausgehandelt, Nonces ausgetauscht und mittels des Dife-Hellman-Exchange (siehe Sektion
2.3.3) ein gemeinsamer geheimer Schlssel etabliert. Eine Nonce ist eine sehr groe Zahl, die
zufllig, unter Verwendung von Zeitstempeln oder anderweitig erzeugt wird, so dass die mehrmalige Verwendung des gleichen Werts sehr unwahrscheinlich ist. Nonces werden verwendet,
um Replay-Attacks durch einen Angreifer zu verhindern.
Im anschlieenden IKE_AUTH-Exchange werden die vorher ausgetauschten Nachrichten authentiziert, Identitten und ggf. Zertikate zwischen den Stationen ausgetauscht und veriziert.
Durch Verwendung des im ersten Schritt etablierten gemeinsamen geheimen Schlssels werden
diese Daten teilweise verschlsselt und authentiziert. Wir hatten bereits in Sektion 3.6.1 prinzipiell diskutiert, wie sich Stationen durch die Verwendung eines gemeinsamen Geheimnisses
(d.h. eines symmetrischen kryptographischen Schlssels) oder durch Zertikate authentizieren
knnen, daher wollen wir an dieser Stelle nicht nher auf die konkreten Schritte eingehen.
10.4.5 Praktisches Beispiel

Wir wollen nun die praktische Verwendung von IPsec auf Basis des bereits in 7.4 verwendeten
Referenznetzwerks skizzieren.
Dieses ist in Abbildung 10.15 nochmals dargestellt. Ziel unseres Versuchs ist es, einen IPsecTunnel zwischen den beiden Intranets 192.168.1.0/24 und 10.2.4.0/24 zu betreiben, so dass die
Kommunikation zwischen den beiden Netzwerken ber das ffentliche Netz 172.16.2.0/24 verschlsselt durchgefhrt wird.
Wir verwenden dieselbe Konguration wie in Abschnitt 7.4 beschrieben und werden die IPsecImplementierung Openswan (siehe [Openswan-Web]) auf beiden Seiten zum Betrieb des Tunnels verwenden. Openswan ist in unserer Linux-Distribution vorhanden und bereits automatisch
installiert worden.
Auf dem Rechner 10.2.4.37 betreiben wir wieder unseren Server auf Port 80. Im ffentlichen
172.16.2.0/24er Netz haben wir zustzlich eine Maschine aufgesetzt, die den Verkehr zwischen
den Netzen mithren kann.
10.4 IPsec
209
10.2.4.37
172.16.2.5
172.16.2.0/24
10.2.4.1
10.2.4.0/24
172.16.2.4
192.168.1.5
IPsec-Tunnel zwischen
172.16.2.4 und 172.16.2.5
192.168.1.0/24
192.168.1.100
Abbildung 10.15: Referenznetzwerk fr den VPN-Test.
Abbildung 10.16: Ethereal-Analyse der TCP-Verbindung zwischen 192.168.1.100 und 10.2.4.37 vom
172.16.2.0/24er Netz beobachtet.
210
Von 192.168.1.100 aus kontaktieren wir 10.4.2.37 vor Konguration und Betrieb des IPsecTunnels. Abbildung 10.16 zeigt, was im 172.16.2.0/24er-Netz von der Verbindung beobachtet
werden kann. Die gesamten Daten der Verbindung laufen unverschlsselt durch smtliche traversierten Netze.
Nun wollen wir einen IPsec-Tunnel zwischen 172.16.2.4 und 172.16.2.5 betreiben. Zunchst
mssen wir die Kongurationsdatei
an unsere Bedrfnisse anpassen. Auf der
Maschine 172.16.2.4 sieht diese Datei wie folgt aus:
Wir wollen nur ganz kurz auf die verwendeten Befehle eingehen.
gibt an, dass
IPsec im Tunnelmodus betrieben werden soll, nicht im Transportmodus. Die IP-Adressen der
Tunnelendpunkte sind durch
und
angegeben, wobei
die Seite der jeweiligen Maschine selbst darstellen sollte. Die sich hinter den Endpunkten
verbergenden Netze sind mit
bzw.
angegeben. Openswan ist so konzipiert, dass auf beiden Endpunkten sogar die gleichen Kongurationsdateien verwendet werden knnten und die Bedeutung von
und
entsprechend
richtig erkannt wird.
speziziert, dass dieser Tunnel beim Start von IPsec automatisch ebenfalls gestartet wird.
gibt an, dass zur Authentikation beim Aufbau
der Verbindung ein bereits vorhandener geheimer Schlssel (shared secret) verwendet werden
soll. Dieser Schlssel muss in der Datei
abgelegt werden. Wir legen diese Datei wie folgt an:
Analog erfolgt die Konguration von 172.16.2.5. Auf beiden Maschinen starten wir nun die
Openswan IPsec-Implementierung durch den Befehl
Wiederum bauen wir zwischen 192.168.1.100 und 10.2.4.37 eine Verbindung auf und beobachten den Verkehr im 172.16.2.0/24er Netz. Abbildung 10.17 zeigt, dass der Tunnel tatschlich
aktiv ist. Sichtbar ist ausschlielich, dass IPsec-ESP-Pakete zwischen den Rechnern 172.16.2.4
und 172.16.2.5 ausgetauscht werden. Geht man davon aus, dass der kryptographische Schutz der
10.5 VPN-Technologien und Klassikation
211
Abbildung 10.17: Ethereal-Analyse der TCP-Verbindung zwischen 192.168.1.100 und 10.2.4.37 vom
172.16.2.0/24er Netz beobachtet.
Pakete sicher ist, kann ein Dritter durch Beobachtung dieser Kommunikation also keine Rckschlsse ber Inhalt und auch die tatschlichen Endpunkte der Kommunikation ziehen.
Die Einkapselung sowie Ver- und Entschlsselung der Pakete erfolgt jeweils auf 172.16.2.4
und 172.16.2.5 oder umgekehrt und ist transparent fr die beiden Endpunkte. Analysiert man
dort den Verkehr, so sind die bertragenen TCP-Segmente nach wie vor im Klartext zu sehen.
10.5 VPN-Technologien und Klassikation

Mit IPsec haben wir eine Mglichkeit der Realisierung eines VPNs betrachtet, die auf der Netzwerkschicht angesiedelt ist. Bei IPsec werden die Pakete auf der IP-Schicht von der VPN-Lsung
entgegengenommen. Die Pakete werden dann kryptographisch behandelt und direkt ber IP an
die Gegenstelle geschickt.
Zu diesem Vorgehen htte es auch einige Alternativen gegeben. Anstatt die Pakete direkt ber
die Netzwerkschicht weiterzuleiten, htten wir beispielsweise zwischen den beiden Endpunkten des VPNs eine sichere Verbindung auf der Transportschicht herstellen und die Pakete ber
diese Verbindung weiterleiten knnen (ein Protokoll fr sichere Verbindungen auf der Transportschicht, nmlich SSL/TLS, werden wir in Abschnitt 13.3.3 genauer kennenlernen).
212

Aufnahme und Abgabe
der zu befrdernden
Daten
VPN-Endpunkt A
VPN-Endpunkt B
Technologie zum sicheren

Tunneln der Daten
zwischen den Endpunkten
Netzwerkschicht
Transportschicht
Netzwerkschicht
Netzwerkschicht
Abbildung 10.18: Klassikation von VPNs.
Ebenso htten bei der Frage, auf welcher Schicht wir die Daten entgegennehmen, andere Mglichkeiten bestanden. So knnte ein VPN auch die auf der Datenverbindungsschicht transportierten Informationseinheiten aufnehmen, durch den Tunnel transportieren und auf der anderen Seite
wieder auf der Datenverbindungsschicht abgeben.
Allgemeiner formuliert gibt es zwei Merkmale fr die Klassizierung von VPNs, die in Abbildung 10.18 dargestellt sind:
Die Aufnahme und Abgabe der durch den Tunnel zu befrdernden Daten und
die Technologie zum sicheren Transport der Daten zwischen den Endpunkten den VPN.
Die zu befrdernden Daten werden in der Regel auf der Netzwerkschicht oder auf der Datenverbindungsschicht angenommen und auf derselben Schicht nach der Ankunft auf der anderen
Seite des VPNs wieder abgegeben. Wie dies genau geschieht, kann unterschiedlich gelst sein.
Als Technologie fr den sicheren Transport der Daten durch den Tunnel kommen ebenfalls
verschiedene Mglichkeiten in Betracht. blicherweise sind diese Mechanismen aber auf der
Transportschicht oder der Netzwerkschicht angesiedelt.
Eine weitere Open-Source-Implementierung fr VPNs ist OpenVPN. Sie kann sowohl auf
der Datenverbindungsschicht als auch der Netzwerkschicht Daten entgegennehmen. Zur Weiterleitung der Daten kommt eine SSL/TLS-Verbindung (siehe Abschnitt 13.3.3) zum Einsatz, er
ndet also auf der Transportschicht statt. OpenVPN ist fr verschiedene Betriebssysteme, darunter auch Windows und Linux, verfgbar. Nhere Informationen zu OpenVPN nden sich unter
[OpenVPN-Web].
Wir betrachten hier vor allen Dingen deshalb Open-Source, da mit diesen Lsungen besonders
gut experimentiert werden kann. Neben diesen Open-Source-Mglichkeiten gibt es eine ganze
Reihe von professionellen VPN-Produkten verschiedener Hersteller. Sie basieren teils auf Hardware und teils auf Software und sind ganz speziell auf den Einsatz im VPN-Bereich ausgelegt
10.6 Risiken bei der Verwendung von VPNs
213
und optimiert. In der Praxis werden solche Lsungen gerade in groen Unternehmen sehr hug
eingesetzt.

10.6.1 Split Tunneling
Bisher haben wir VPNs als (sicheres) Verfahren kennengelernt, um private Netze ber ffentliche Netzwerke zu betreiben. Doch die Verwendung von VPNs birgt auch Risiken, die wir nun
betrachten werden.
Durch die Verwendung eines Remote-Access-VPNs wird ein Endsystem in einem beliebigen
Netzwerk faktisch zu einem Teil des Intranets, in das die VPN-Verbindung aufgebaut wird. Der
Aufbau dieses Tunnels ist in erster Linie dadurch motiviert, dass auf diese Weise der Rechner
Zugang zu den Netzwerkressourcen im Intranet erlangt und der Zugriff auf diese Ressourcen nur
ber das VPN mglich ist.
Doch ein Benutzer greift typischerweise nicht ausschlielich auf Ressourcen im Intranet zu,
sondern verwendet auch Dienste, die sich im Internet benden, wie etwa der Abruf einer Webseite von einem Server im Internet. Werden smtliche Zugriffe auf das Netz durch den VPN-Tunnel
abgewickelt, so ergibt sich die in Abbildung 10.19 oben gezeigte Situation. Die bermittelten
Pakete gehen erst vom Client zum VPN-Server und dann von dort an den Server im Internet. In
der Rckrichtung verluft der Paketuss analog. Hierdurch ergibt sich ein zustzlicher Aufwand,
der eigentlich nicht notwendig wre, denn Server im Internet knnten auch direkt kontaktiert
werden.
Es erscheint aus Efzienzgesichtspunkten also naheliegend, nur die Zugriffe auf das Intranet
ber das VPN abzuwickeln und Ressourcen im Internet direkt anzusprechen, ohne den Tunnel
zu verwenden. Dieses Vorgehen ist unter dem Begriff Split Tunneling bekannt.
Split Tunneling birgt erhebliche Sicherheitsrisiken, da der Rechner mit VPN-Client in diesem
Fall ber mindestens zwei (logische) Interfaces verfgt, nmlich zum einen das VPN-Interface
und zum anderen das Interface in das LAN, an das er tatschlich angeschlossen ist. Sind beide
Interfaces gleichzeitig aktiv, so kann der Rechner theoretisch und praktisch als Router fungieren
und so anderen Maschinen (gewollt oder ungewollt) Zugriff auf das Intranet gewhren. Selbst
wenn das Routing zunchst ausgeschaltet ist, knnte es einem Angreifer gelingen, den Client
durch einen Angriff unter seine Kontrolle zu bringen und dann das Routing zu aktivieren.
Dies ist in Abbildung 10.20 dargestellt. Der Angreifer schickt seine Pakete, die an einen Server
im geschtzten Intranet gerichtet sind, an das LAN-Interface des Rechners mit VPN-Client, der
sie dann ber das VPN-Interface weiterleitet. Somit werden die Pakete verschlsselt und an den
VPN-Server geschickt. Dort werden sie wieder entpackt und an einen Server im Intranet geleitet.
Die Rckrichtung verluft analog.
Split Tunneling sollte daher generell nicht verwendet werden. Beim Betrieb eines VPN-Client
auf einer Maschine empehlt es sich, allen Verkehr ausschlielich ber das VPN abzuwickeln
und alle anderen eingehenden Pakete zu ignorieren (bis auf Pakete, die notwendige Verwaltungsinformationen fr das Interface betreffen, ber welches das VPN betrieben wird), also faktisch
die betreffenden Interfaces abzuschalten. Einige VPN-Lsungen fhren dies automatisch durch.
214

indirekter Zugriff auf
Ressourcen im Internet
ber den VPN-Server
Intranet
Internet
Tunnel
(verschlsselt)
VPN-Client
VPN-Server
direkter Zugriff auf

Ressourcen im Internet
Internet
VPN-Client
Tunnel (verschlsselt)
wird nur bei Verbindungen
ins Intranet verwendet
Intranet
VPN-Server
Abbildung 10.19: Zugriff auf Internet-Ressourcen ber ein VPN mittels vollstndigen Tunnelns oder Split
Tunneling.
10.6.2 ffentliche Zugangsnetze fr Endsysteme

Wird ein VPN zum Remote-Access benutzt, so kann sich das Endsystem mit dem VPN-Client
in einem beliebigen Netzwerk mit Internetzugang benden. Handelt es sich dabei um ein ffentlich verfgbares Netz, wie etwa einen Hot Spot oder ein Netzwerk in einem Hotel, auf einer
Konferenz oder in einer Messehalle, so kann die Sicherheit dieses Netzwerks nicht vorausgesetzt
werden. Schlimmstenfalls bendet sich das Endsystem unmittelbar in einem LAN mit Maschinen
von Angreifern, die ber die Datenverbindungsschicht den Rechner direkt attackieren knnen.
Daher ist bei der Verwendung ffentlicher Zugangsnetze uerste Vorsicht geboten. Rechner,
die ber solche Netze betrieben werden, sollten eine Personal Firewall (siehe Abschnitt 9.5) mit
215
Angreifer
Intranet
Internet
VPN-Client routet Verkehr

des Angreifers ber das VPN
VPN-Server nimmt Pakete

entgegen und leitet sie weiter
Abbildung 10.20: Angriff ber Split Tunnel.
in die html-Seite
Abbildung 10.21: Injektion von Malware in eine Webseite durch einen Switch/Router unter Kontrolle eines
Angreifers.
restriktivsten Einstellungen verwenden und selbst keinerlei Dienste ber das Netzwerk anbieten.
Diese berlegungen sind unabhngig von der Frage, ob auf dem Endsystem ein VPN betrieben wird oder nicht. Durch die Verwendung eines VPNs wird die Sicherheitssituation des
Rechners signikant verbessert, da nach dem Aufbau des VPNs die gesamte Kommunikation in
das Unternehmensnetzwerk verschlsselt erfolgt. Wie oben dargelegt, sollte jegliche Kommunikation ber andere Interfaces als das VPN unterbunden werden. Wird dies umgesetzt, so ist der
Rechner nach Aufbau des VPNs gegen Angriffe, die direkt ber das LAN erfolgen, immun. Es
bleibt jedoch das Zeitintervall vom Verbinden mit dem Netzwerk bis zum Aufbau des VPNs, in
dem der Rechner Angriffen ausgesetzt sein kann.
Wird kein VPN betrieben, so ist davon auszugehen, dass jegliche nicht auf Applikations- oder
Transportschicht kryptographisch geschtzte Kommunikation ber das Netzwerk aktiv und passiv angegriffen werden kann. Diese Risiken sind als auerordentlich schwerwiegend einzustufen.
216
Ein Angreifer muss sich nicht auf die Rolle eines gewhnlichen Teilnehmers in einem ffentlichen Netz beschrnken, sondern er kann auch selbst als Betreiber eines ffentliches Netzes
auftreten. Whrend sich der ahnungslose Nutzer ber den unerwarteten und kostenlosen Netzwerkzugang freut, nutzt der Angreifer die Gelegenheit aus, um Malware auf dem Rechner des
Nutzers zu platzieren.
Wenn ein Angreifer die Kontrolle ber das Netzwerk hat, bieten sich eine ganze Reihe von
Mglichkeiten. So knnte der Angreifer etwa einen Router oder Switch betreiben, ber den er
Malware injiziert. Wie in Abbildung 10.21 dargestellt, knnte der Switch beispielsweise in eine
html-Seite, die von einem Webserver aufgerufen wird, Malware einfgen und so in den ClientRechner einschleusen:
1. Der Benutzer ruft bei einem Webserver eine html-Seite ab.
2. Der Server reagiert und sendet die angeforderte Seite an den Benutzer zurck.
3. Fr den Benutzer unbemerkbar fngt der durch den Angreifer aufgestellte Router die Seite
zunchst ab und injiziert Malware in den html-Code der Seite. Die so vernderte Seite wird
an den Benutzer weitergeschickt.
4. Der Benutzer erhlt (scheinbar) die angeforderte Seite.
Bei der Benutzung ffentlicher Netze ist also Vorsicht geboten, egal ob mit oder ohne VPN.
10.7 Zusammenfassung
Virtual Private Networks ermglichen das Betreiben einer sicheren, scheinbar direkten
Punkt-zu-Punkt-Verbindung zwischen zwei Stationen ber ein ffentliches Netzwerk.
VPNs werden hauptschlich eingesetzt, um Rechner ber ein ffentliches Netzwerk in
ein Intranet einzubinden, oder als Ersatz einer eigenen angemieteten Leitung zwischen
verschiedenen Standorten einer Firma.
Eine technische Mglichkeit zur Realisierung eines VPNs ist das IPsec-Protokoll. IPsec sitzt auf der Netzwerkschicht. Es beinhaltet zwei Sicherheitsprotokolle, ESP und
AH und kann im Tunnel- oder Transportmodus betrieben werden. Vor der Verwendung von IPsec mssen wechselseitig Security Associations zwischen den beteiligten
Stationen aufgebaut werden. Diese knnen manuell erstellt oder mittels eines Protokolls wie beispielsweise IKE aufgebaut werden.
Die Verwendung von VPNs birgt auch einige Risiken wie beispielsweise Split Tunneling. Darber hinaus ist bei der Verwendung ffentlicher Verbindungsnetze uerste
Vorsicht geboten.
10.8 bungsaufgaben
217
10.8 bungsaufgaben
Aufgabe 10.1:
Denieren Sie den Begriff Virtual Private Network.
Aufgabe 10.2:
Erklren Sie die Funktionsweise eines Remote-Access-VPNs.
Aufgabe 10.3:
Beschreiben Sie, wie ein VPN eine dezidierte Datenleitung zwischen zwei Unternehmensstandorten ersetzen kann.
Aufgabe 10.4:
Erlutern Sie die Funktionsweise von IPsec. Gehen Sie dabei insbesondere auf die Funktionen
von ESP und AH ein.
Aufgabe 10.5:
Beschreiben Sie, welche Risiken der Betrieb eines RAS-VPNs birgt und wie man sie eliminieren
kann.

Aufgabe 10.6:
Alternative Technologien zum Betrieb eines Tunnel-VPNs sind OpenVPN und L2TP. Recherchieren Sie, wie diese Verfahren funktionieren und vergleichen Sie sie mit IPsec. Gehen sie dabei
insbesondere auf die Frage ein, auf welcher Schicht die Protokolleinheiten getunnelt werden und
auf welcher Schicht der Tunnel tatschlich aufgebaut wird.
Aufgabe 10.7:
Der Ersatz einer dezidierten Datenleitung zwischen zwei Standorten ist nicht hinsichtlich allen Zielen von IT-Sicherheit als tatschlich quivalent zu betrachten. Erlutern Sie, welche ITSicherheitsziele durch ein VPN schwieriger zu erreichen sind und warum.
Aufgabe 10.8:
Fhren Sie den in Abschnitt 10.4.5 mit IPsec und Openswan durchgefhrten VPN-Versuch mit
OpenVPN durch.
Kapitel 11
Netzwerkberwachung
11
Netzwerkberwachung
11.1 Grundlagen
Wir haben in den bisherigen Kapiteln vor allen Dingen Schwachstellen in Netzwerken kennengelernt und uns mit Konzepten, Protokollen und Technologien befasst, die Netzwerke sicherer
machen, indem sie Sicherheitslcken in den Netzwerken im weitesten Sinne schlieen oder Angriffe zumindest erschweren.
Die bisher betrachteten Manahmen waren grtenteils prventiv, also darauf ausgerichtet,
Schwachstellen zu beheben. Auf diese Weise knnen zuknftige Angriffe vereitelt werden, sie
waren also vorbeugend.
In diesem Kapitel werden wir uns mit Netzwerkberwachung beschftigen. Diese schliet neben prventiven auch detektive Manahmen ein, also Technologien und Methoden, die einen
Angriff zwar nicht verhindern, aber zu dessen Entdeckung beitragen knnen. An die Erkennung
des Angriffs schlieen sich reaktive Manahmen an, die das Ziel haben, den entstandenen Schaden zu minimieren und beheben, zuknftige Angriffe hnlicher Art zu verhindern und (eventuell)
den Tter zu ermitteln und strafrechtliche Schritte einzuleiten. Reaktive Manahmen, die nach
einem Angriff getroffen werden, um Beweise zu sichern und Tter der Straftat zu ermitteln, fallen
in das Gebiet der (Computer-)Forensik. Bei der Sicherung ist insbesondere auf die sptere Gerichtsverwertbarkeit der gesammelten Beweise zu achten. Die Computerforensik umfasst auch
Bereiche, die mit IT-Sicherheit nicht unmittelbar in Zusammenhang stehen, beispielsweise die
Untersuchung von Rechnern, die mutmalich bei der Begehung einer Straftat verwendet wurden,
etwa zum Schreiben eines Erpresserbriefes.
Auf den ersten Blick mag es lohnender erscheinen, sich auf die Verhinderung von Angriffen zu
konzentrieren, um eine Verbesserung der IT-Sicherheit zu erreichen, anstatt sich der Erkennung
von Angriffen zu widmen. Wren wir in der Lage, durch proaktive Manahmen Angriffe jeder
Art ausschlieen zu knnen, so knnte man auf die Erkennung von Angriffen tatschlich verzichten. Doch leider sind IT-Systeme komplex, und nahezu jedes IT-System drfte (unentdeckte)
Schwachstellen besitzen, die ein Angreifer auf die eine oder andere Art ausnutzen knnte.
Wenn wir die realistische Annahme treffen, dass Schwachstellen niemals vollstndig ausgeschlossen werden knnen, so kommt der mglichst frhzeitigen Erkennung von Angriffen eine
entscheidende Bedeutung zu: Je frher ein Angriff erkannt wird, desto schneller
kann der Angriff analysiert und die ausgenutzte Schwachstelle geschlossen werden,
knnen Gegenmanahmen eingeleitet und die Fortfhrung des Angriffs unterbunden werden,
220
IDS-Alarm
Anomalie
Angriff
Mibrauch
False Positive
irregulres
Systemverhalten
Abbildung 11.1: Alarme eines IDS und Klassikation entdeckter Anomalien.
kann der entstandene Schaden eingegrenzt und behoben werden.

Die Vorbeugung gegen Angriffe und die Erkennung von Angriffen sind also komplementre,
sich ergnzende Manahmen. Ein sinnvolles IT-Sicherheitsportfolio muss beide Elemente enthalten. Es ist also kein Entweder-oder, sondern ein Sowohl-als-auch gefordert.
11.2 Intrusion Detection

11.2.1 Einfhrung
Eine Intrusion ist ein unerwnschter und/oder nicht autorisierter Vorgang. Unter dem Begriff
Intrusion Detection versteht man die berwachung von Systemen und/oder Netzwerken mit dem
Ziel, unerwnschte und/oder nicht autorisierte Vorgnge zu erkennen, zu protokollieren und zu
melden.
Ein Intrusion Detection System (IDS) berwacht ein System und/oder Netzwerk und analysiert, ob das beobachtete Verhalten des Systems/Netzwerks vom erwarteten Normalzustand abweicht. Eine solche Abweichung wird als Anomalie bezeichnet. Die Frage, was genau beobachtet
wird und wie Anomalien entdeckt werden, unterscheidet sich von IDS zu IDS.
Es gibt hauptschlich zwei verschiedene Typen von Intrusion Detection Systemen, die sich
hinsichtlich ihren Anforderungen und der Arbeitsweise stark unterscheiden, nmlich
netzwerkbasierte Intrusion Detection Systeme, deren Aufgabe in der berwachung des
Netzwerkverkehrs besteht und
hostbasierte Intrusion Detection Systeme, deren Aufgabe in der berwachung eines einzelnen Rechners (Prozesse, User, Kommunikation mit anderen Maschinen) besteht.
Hybride IDS, die Komponenten netzwerkund hostbasierter Systeme beinhalten, existieren
ebenfalls.
221
Eine beobachtete Anomalie kann mehrere Ursachen haben und muss nicht unbedingt auf einen
Angriff zurckzufhren sein. Wir unterscheiden zwischen drei verschiedenen Typen von Anomalien:
Angriff: Entdeckung eines Angriffs, d.h. einer unautorisierten Benutzung des Systems oder
des Netzwerks.
Systemmissbrauch: Die Benutzung des Systems ist zwar autorisiert, stellt aber (mglicherweise) einen Missbrauch der Ressourcen dar und ist dann unerwnscht oder fr die Institution kritisch. Beispielsweise knnte ein Mitarbeiter in auergewhnlichem Umfang Daten
aus dem Internet herunterladen oder ber das Internet auf einen fremden Rechner transportieren oder auf auffallend viele vertrauliche Dokumente auf einem Dokumentenserver im
Intranet zugegriffen haben. Systemmissbrauch stellt keinen Angriff auf die IT-Sicherheit
im engeren Sinn dar, knnte aber fr die Sicherheit der Institution relevant sein.
Irregulres Systemverhalten: Die beobachtete Anomalie ist auf ungewhnliches Systemverhalten zurckzufhren, das auerhalb der gewhnlichen Benutzungsparameter des Systems liegt. Beispielsweise knnten durch den Ausfall eines Servers die Zugriffe auf einen
Backup-Server stark ansteigen.
Die Entdeckung von Systemmissbrauch und irregulrem Systemverhalten ist fr viele Intrusion Detection Systeme ebenso wichtig wie die Aufdeckung von Angriffen.
Wird durch ein Intrusion Detection System eine vermeintliche Anomalie entdeckt, so muss
diese weiter untersucht werden, um die Ursache der Anomalie genau festzustellen und um gegebenenfalls Gegenmanahmen einzuleiten. Diese Aufgaben werden nicht durch das Intrusion
Detection System erledigt und erfordern das Eingreifen von Systemadministratoren, da sie nur
sehr beschrnkt automatisiert abgewickelt werden knnen.
Hierdurch ergibt sich ein Problem bei Konguration und Betrieb des Intrusion Detection Systems. Werden die Normwerte, gegen die das IDS die aktuell beobachteten Parameter abgleicht,
zu eng gezogen, so wird es hug zu Fehlalarmen kommen. Solche false-positives fhren zu
Schwierigkeiten, da sie durch den Systemadminstrator bearbeitet werden mssen. Signalisiert
das IDS dem Administrator pro Tag hundert vermeintliche Anomalien, so besteht die Gefahr,
dass der Systemadministrator bei der Untersuchung der Meldungen nicht sorgfltig genug vorgehen kann und so tatschliche Anomalien bersieht oder die Meldungen des IDS schlimmstenfalls
vollstndig ignoriert.
Wird umgekehrt der Bereich des normalen Verhaltens des Systems oder Netzes zu weit gezogen, so besteht die Gefahr, dass das IDS tatschliche Anomalien nicht erkennt. Solche falsenegatives sind aus naheliegenden Grnden ebenfalls unerwnscht.
Somit kommt es darauf an, bei der Spezikation des normalen Systemverhaltens die richtige
Balance zu nden. Bei einer sinnvollen Konguration werden sich die false-positives zwar in
Grenzen halten, aber trotzden ab und zu auftreten. Was als normal erachtet werden sollte und
was nicht, hngt sehr vom jeweiligen System oder Netzwerk ab. Die Konguration eines IDS ist
eine sehr individuelle Aufgabe. Abbildung 11.1 stellt die mglichen Grnde fr einen durch ein
IDS ausgelsten Alarm zusammenfassend dar.
222
IDS-Server
Berichterstattung
Alarmierung und
Datenanalyse
IDS-Sensoren
Abbildung 11.2: Intrusion Detection System.
11.2.2 Architektur und Komponenten eines netzwerkbasierten IDS

Wir werden uns nun etwas detaillierter mit netzwerkbasierten Intrusion Detection Systemen befassen. Netzwerkbasierte IDS werden von Institutionen in ihren Intranets eingesetzt. Wir hatten
bereits in den Kapiteln 7 und 8 ausfhrlich betrachtet, wie einfach es ist, TCP/IP-basierte Netze
und Ethernet abzuhren. Dies machen sich netzwerkbasierte IDS zunutze und und hren den Verkehr im Intranet an einer oder an verschiedenen Stellen mit. An diesen Stellen sitzen sogenannte
Sensoren, die den Netzwerkverkehr analysieren und gegen vorgegebene Signaturen abgleichen.
Tritt dabei eine gem der Kongurationsvorgaben verdchtige oder zumindest mitteilenswerte
Kommunikation auf, so wird diese an einen IDS-Server weitergeleitet und dort in einer Datenbank gespeichert. Der IDS-Server analysiert und korreliert die Meldungen der Sensoren und lst
gegebenenfalls einen Alarm aus. Diese Architektur ist in Abbildung 11.2 skizziert.
In sehr einfachen Anwendungsfllen (nur ein Sensor) kann dieser auch seine gesammelten
Daten in eine lokale Logdatei anstatt in eine Datenbank schreiben und selbst die Alarmierung
bernehmen. Die Verwendung einer Datenbank auf einem Server hat den Vorteil, dass die gesammelten Daten fr eine detaillierte Analyse bereitstehen.
Der Auswahl der richtigen Stellen fr die Platzierung der Sensoren des IDS kommt fr die
Funktion des IDS eine wichtige Bedeutung zu, denn sie entscheidet darber, welchen Verkehr
im Netzwerk das IDS berhaupt berwacht und welcher durch das IDS nicht beobachtet werden
kann. Auch wenn die Frage, welche Punkte dies sind, stark vom individuellen Netzwerk abhngt,
so werden in vielen Fllen die Sensoren vor allem an sogenannten Choke Points des Netzwerks
installiert. Darunter versteht man Verbindungspunkte im Netzwerk, die fr den Betrieb des Netzes oder eines Teilnetzes von groer Bedeutung sind. Solche Punkte werden auch als Sperrpunkte
bezeichnet, weil deren Ausfall (oder bewusste Abschaltung) zur Abtrennung und Isolierung von
Teilen des Netzes fhren kann.
223
Pakete
Inline-Sensor
Pakete
Out-of-Line-Sensor
Abbildung 11.3: Sensorvarianten fr IDS.
Es gibt verschiedene Mglichkeiten, wie ein Sensor den Netzwerkverkehr an der gewhlten
Stelle berwachen kann. Ein Sensor kann sich entweder selbst direkt im Datenstrom benden,
oder den Verkehr durch eine indirekte Beobachtung des Datenstroms analysieren. Diese beiden
Varianten sind in Abbildung 11.3 dargestellt.
Ein Inline-Sensor sitzt direkt im Datenpfad der zu berwachenden Pakete. Typischerweise ist
der Sensor in solchen Fllen auf einer Bridge oder einem Router untergebracht, die neben ihrer
eigentlichen Aufgabe auch Bestandteil des IDS sind. Der Sensor muss die Pakete selbst also aktiv
zum Ziel weiterbefrdern
Ein Out-of-Line-Sensor bendet sich nicht direkt im Datenpfad, sondern erhlt Kopien der
zu berwachenden Pakete. Dies kann technisch auf verschiedene Arten realisiert werden. Beispielsweise bieten einige Switches die Mglichkeit, einen Mirrorport einzurichten, an dem die
aus dem Switch an einen oder mehrere Ports ausgehenden Daten zustzlich auf den Mirrorport
weitergeleitet (gespiegelt) werden. Auf diese Weise kann der ber den Switch abgewickelte
Verkehr am Mirrorport durch einen Sensor analysiert werden.
Inline-Sensoren knnen im Gegensatz zu Out-of-Line-Sensoren bei der Entdeckung von Anomalien auch aktiv eingreifen. Da sie an der Weiterleitung der Pakete beteiligt sind, kann ein
Inline-Sensor ein verdchtiges Paket nicht nur melden, sondern auch lschen, so dass auf diese
Weise nicht nur Intrusion Detection betrieben werden kann, sondern auch Intrusion Prevention,
also die Verhinderung von Intrusions. Damit bernimmt das IDS auch Aufgaben einer Firewall
(siehe Kapitel 9).
Leider hat die Inline-Variante einige gravierende Nachteile. Da der Sensor im Datenpfad liegt,
hngt die Befrderung aller Pakete auf diesem Datenpfad von der ordnungsgemen Funktion
des Sensors ab. Gerade wenn das Datenvolumen stark ansteigt und die Rechenleistung des Sensors nicht ausreicht, die notwendigen Analysen der Pakete schnell genug durchzufhren, kann
sich so eine berlastsituation ergeben. Da die Sensoren zudem hug an Choke-Points untergebracht sind, kann die berlastung oder das Versagen eines Sensors die Funktion des Netzwerks
beeintrchtigen oder sogar zum Ausfall des Netzwerks oder eines Teilnetzes fhren.
Auch bei Out-of-Line-Sensoren knnen Probleme auftreten, nmlich wenn das Kopieren der
zu berwachenden Pakete die Funktion des Netzwerks beeintrchtigt. Wird auf einem Switch
ein Mirrorport betrieben, so kostet das Spiegeln der Pakete den Switch ebenfalls Rechenzeit,
was seine Performance verringern kann. Falls mehrere Ports des Switches auf einen Mirrorport
224
gespiegelt werden, kann es auerdem zu einer berlastung des Mirrorports kommen, was zu
Paketverlusten an diesem Port fhrt und die Performance des Switches weiter beeintrchtigen
kann.
Es gibt Alternativen fr das Kopieren der zu berwachenden Pakete, welche diese Nachteile
nicht aufweisen, etwa Network Taps. Dabei handelt es sich um zustzliche Hardware mit einem
Eingangsport und zwei Ausgangsports. Das am Eingangsport anliegende Signal wird auf die beiden Ausgangsports weitergeleitet. Damit kann ein solches Tap beispielsweise vor einen Switch
geschaltet werden und den dort ein- und ausgehenden Verkehr an einen Sensor weiterleiten.
Network Taps sind dafr konzipiert, verlustfrei zu arbeiten und die Performance des Netzwerks
nicht zu beeintrchtigen. Bei einer Verwendung von Network Taps oder anderen Technologien
mit hnlichen Eigenschaften fhrt eine berlastung oder das Versagen bestimmter Out-of-LineSensoren nicht zu einer Beeintrchtigung der Funktion des Netzwerks als solches (wohl aber der
des IDS).
Ein weiterer wichtiger Punkt, den wir hier nur kurz ansprechen knnen, ist die Frage, wie
die Sensoren die Daten an den IDS-Server weiterleiten. Mglich ist sowohl ein (verschlsselter)
Transport innerhalb des berwachten Netzwerks selbst als auch die Kommunikation ber ein
separates Netz, das nur durch das IDS verwendet wird. Fr letztere Lsung spricht, dass die
Funktion des eigentlichen Netzes dann durch das IDS nicht belastet wird und sich Dritte nur mit
grerem Aufwand Zugang zu den Meldungen des IDS verschaffen knnen. Gegen diese Lsung
spricht eigentlich nur die Notwendigkeit einer zustzlichen Verkabelung fr die Sensoren.
11.2.3 Netzwerkbasierte IDS und Paketlter

Wenn der Sensor eines IDS im Datenpfad sitzt und unerwnschte Pakete auch noch aufhlt, so
erinnert dies den aufmerksamen Leser wahrscheinlich stark an die Funktion der in Kapitel 9
skizzierten Paketlter-Firewalls. Tatschlich kann man solche Systeme als erweiterte Paketlter
betrachten. Doch auch wenn ein IDS betrieben wird, das ausschlielich zur Detektion und nicht
zur Prvention verwendet wird, gibt es zwischen Paketltern und netzwerkbasierten IDS einige
Gemeinsamkeiten:
Paket- und regelbasierte Arbeitsweise: Sowohl Paketlter als auch netzwerkbasierte IDS
erfllen ihre Aufgaben durch Analyse der im Netzwerk bertragenen Pakete und den Abgleich dieser Pakete gegen bestimmte Regeln bzw. Signaturen.
Grenzen und Schwachstellen: Alle in Sektion 9.2.1.4 genannten Schwchen und Grenzen
von Paketltern treffen im Prinzip auch auf netzwerkbasierte IDS zu. Insbesondere knnen solche IDS verschlsselte Informationen nicht dechiffrieren und knnen daher durch
Verschlsselung und Tunneling ausgehebelt werden.
Als Unterschiede knnen herausgehoben werden:
Unterschiedliche Anforderungskriterien: Ein Paketlter sitzt immer im Datenpfad. Eine
schlechte Performance des Paketlters fhrt zu einer schlechten Verbindungsqualitt in
dem ber den Filter angebundenen Netzwerk. Daher ist bei Paketltern die Performance
sehr wichtig. Die Entscheidung, ob ein Paket weitergeleitet werden soll oder nicht, muss
225
mglichst schnell getroffen werden. Bei einem IDS (speziell bei Out-of-Line-Sensoren)
kommt es dagegen auf die Przision und Genauigkeit, weniger auf die Geschwindigkeit
bei der Analyse an.
Transparenz: Ein IDS verhlt sich ausschlielich passiv und kann deshalb von einem Benutzer oder Angreifer nicht bemerkt werden. Ein Paketlter kann hug durch Benutzer
bei der Beobachtung und einfachen Analysen des Netzwerkverkehrs entdeckt werden. In
jedem Fall wird die Existenz eines Paketlters dann klar, wenn er in Aktion tritt und Pakete
nicht weiterleitet.
Flexibilitt: Paketlter trennen Netze oder Netzwerksegmente voneinander ab. IDS knnen exibler positioniert werden und ermglichen es, Daten von verschiedenen, ber das
Netz verteilten Sensoren in einer zentralen Datenbank zu speichern.
Wir wollen uns mit diesen Punkten und ihrer Implikationen noch etwas detaillierter befassen. Im Gegensatz zu einem Paketlter, der fr jedes einzelne Paket schnell entscheiden muss,
ob dieses Paket durchgelassen wird oder nicht, kann ein netzwerkbasiertes IDS auftretende Ereignisse miteinander korrelieren und so zu wesentlich detaillierteren Analysen gelangen. Damit
knnen beispielsweise auch Angriffe entdeckt werden, die sich aus einzelnen, scheinbar harmlosen Paketen mit groem zeitlichen Abstand zueinander zusammensetzen. Solche Aktionen, etwa
ein Netzwerkscan (siehe Sektion 11.3), knnen Vorstufen eines Angriffs sein, deren rechtzeitige
Entdeckung den Angriff eventuell noch verhindern knnen.
Die Verwendung einer Datenbank zur Speicherung der gesammelten Informationen ermglicht eine exible und umfassende Analyse der durch die Sensoren gesammelten Daten. So lassen
sich auch Anomalien nden, beispielsweise die Zunahme von eigentlich unverdchtigem HTTPVerkehr zu einer bestimmten Webseite, was ein Hinweis auf in das System gelangte Malware
sein knnte, oder aber nur auf die Popularitt einer neuen Webseite zurckzufhren sein kann.
Paketlter werden in der Regel an der Grenze zwischen Internet und Intranet eingesetzt, oder
auch zur Auftrennung eines Intranet in mehrere Netze, aus denen heraus nicht alle Dienste der
anderen Netze unmittelbar erreichbar sind. IDS lassen sich wesentlich exibler einsetzen und
knnen auch innerhalb eines Netzwerksegments den Verkehr berwachen.
Somit sind IDS und Paketlter also komplementre Mechanismen, die sich gegenseitig ergnzen, nicht ersetzen.
11.2.4 Beispiel fr die Verwendung eines IDS

Im Folgenden wollen wir ein Beispiel betrachten, wie aussagekrftig Informationen sein knnen, die man durch die Beobachtung des Netzwerkverkehrs erhalten kann. Dabei wollen wir
uns auf die Entdeckung unautorisiert aufgestellter IEEE 802.11-WLAN-Access-Points in Institutionen durch ein IDS anhand von MAC-Adressen konzentrieren. Dieses Beispiel ist etwas ungewhnlich, aber es demonstriert eindrucksvoll, welche Mglichkeiten allein schon durch die
berwachung und berprfung von MAC-Adressen bestehen.
Drahtlose lokale Netzwerke (WLAN) nach dem IEEE 802.11-Standard erfreuen sich bei Anwendern in Institutionen und im Heimbereich wachsender Beliebtheit. Wir werden uns mit drahtlosen WLANs und deren Sicherheits in Sektion 15.3 ausfhrlicher befassen.
226
S
Netzwerk
Default-Gateway R
fr Rechner C
IDS-Sensor
LAN
C
AP
802.11-Frame
Ziel-MAC: R
Quell-MAC: C
Ethernet-Frame
Ziel-MAC: R
Quell-MAC: C
beobachtet MAC-Adresse
von Rechner C
konvertiert IEEE 802.11-Frames
in Ethernet-Frames und ungekehrt
Abbildung 11.4: Entdeckung unautorisierter WLAN-Access-Points mittels IDS.
IEEE 802.11-Netzwerke arbeiten meistens im Infrastrukturmodus. Lsst man die spezischen

Details der Datenverbindungsschicht unbercksichtigt, so bedeutet dies vereinfacht ausgedrckt,
dass jeder ber das WLAN verbundene Rechner mit einem spezischen Access-Point (AP) des
WLANs verbunden ist und seine gesamte Kommunikation ausschlielich ber diesen AccessPoint abwickelt. Genauer gesagt werden auf der Datenverbindungsschicht alle Frames des Rechners ber das drahtlose Netz an den Access-Point geschickt, und der Rechner empfngt umgekehrt ausschlielich Frames von diesem Access-Point. In diesem vereinfachten Modell kann man
sich die WLAN-Verbindung also wie ein virtuelles Kabel zwischen dem Access-Point und dem
Rechner vorstellen, hnlich wie bei Ethernet zwischen einem Rechner und einem Switch.
Natrlich muss der so drahtlos angebundene Rechner nicht nur mit anderen ber das WLAN
angebundenen Gerten kommunizieren knnen, sondern auch mit anderen, beliebigen Rechnern
in Intranet und Internet, ganz unabhngig von der verwendeten Datenverbindungsschicht. Um
dies zu erreichen, arbeitet der Access-Point als Bridge zwischen dem drahtlosen und dem drahtgebundenen Netz (siehe Abschnitt 7.3.1.3). Er besitzt sowohl ein WLAN-Interface als auch ein
Ethernet-Interface, ber das er mit dem drahtgebundenen Netzwerk der Institution verbunden
ist. Der AP bersetzt die unterschiedlichen Frameformate von WLANs und Ethernet ineinander und leitet Frames aus dem drahtlosen Netz, die fr das drahtgebundene Netz bestimmt sind
(oder umgekehrt), entsprechend weiter. Somit sind die mit dem Access-Point verbundenen Rechner Teil des drahtgebundenen LANs, in dem sich der Access-Point bendet. Rechner im gleichen
LAN knnen direkt ber die Datenverbindungsschicht erreicht werden, unabhngig vom bertragungsmedium, das sie verwenden. Dies ist in Abbildung 11.4 skizziert. Der mit dem AP drahtlos
verbundene Rechner C kommuniziert mit einem Server S irgendwo im Internet. Auf der Datenverbindungsschicht adressiert Rechner C seine nicht fr das eigene LAN bestimmten Datenpakete wie blich an sein Default-Gateway, im skizzierten Fall den Router R, genauer die MACAdresse des entsprechenden Interfaces von R im LAN. Details, wie die Frames im WLAN adressiert werden, sollen an dieser Stelle nicht behandelt werden. Als Absenderadresse verwendet C
11.3 Scannen
227
die MAC-Adresse seines IEEE 802.11-Interfaces. Die Frames werden zunchst per WLAN von
C zum AP geschickt. Dieser bersetzt die Header der Frames vom IEEE 802.11-Frameformat
in das Ethernet-Frameformat. Der hier entscheidende Punkt ist, dass dabei die MAC-Adresse
des WLAN-Interface von C als Absenderadresse im Ethernet-Frame bernommen wird. Daher
wird ber das Ethernet ein Frame verschickt, der als Absenderadresse die MAC-Adresse des
drahtlosen Interfaces von C besitzt.
Wird ein solcher Frame im LAN von einem IDS-Sensor registriert, enthlt er also die MACAdresse des drahtlosen Interfaces von C. Diese MAC Adresse kann nun weitergehend analysiert
werden. Wie bereits in 7.3.1.1 erwhnt, bestehen MAC-Adressen aus 6 Byte, von denen die ersten drei Bytes (OUI) vom Hersteller des Interface beim IEEE erworben werden mssen. Da die
Hersteller MAC-Adressen global eindeutig vergeben mssen, kann anhand der OUI und weiterer
Merkmale oft auch genau ermittelt werden, um was fr eine Art von Interface es sich handelt.
Diese Information ist ffentlich verfgbar und kann dazu genutzt werden, um ber das IDS festzustellen, dass es sich bei der MAC-Adresse C um die eines WLAN-Interfaces handelt.
In vielen Institutionen ist die Verwendung von WLANs aus Sicherheitsgrnden nicht gestattet
oder sie werden zumindest in separaten LANs betrieben. Entdeckt man dann wie oben dargestellt
in einem LAN ohne autorisierte WLAN-Komponenten eine WLAN-MAC-Adresse, so lsst dies
auf die Verwendung eines nicht autorisierten WLAN-Access-Points schlieen und weitere Manahmen knnen eingeleitet werden.
Es gibt Mglichkeiten, einen unautorisierten Access-Point oder einen drahtlosen Client an
einem unautorisierten Access-Point in einem Netzwerk zu betreiben und die oben beschriebene
Enttarnung ber die MAC-Adresse zu umgehen, etwa durch die Verwendung einer geflschten
MAC-Adresse (siehe Abschnitt 8.2.2) oder den Betrieb des Access-Points als Router mit Network
Address Translation (NAT) (siehe Abschnitt 9.2.1.5).
11.3 Scannen
11.3.1 Einfhrung
Ein Programm auf einem Rechner in einem Netzwerk kann anderen Rechnern ber das Netzwerk
Dienste anbieten. Wie in Kapitel 7 erlutert, muss sich hierfr das Programm an einen TCP oder
UDP-Port anbinden. An diesem Port eingehende Verbindungen werden dann an es weitergeleitet.
Auf eingehende Verbindungen wartende Programme sind mit einem inhrenten Sicherheitsrisiko behaftet, denn man kann diese Dienste von anderen Maschinen aus kontaktieren und so
eventuell Schwachstellen im anbietenden Programm wie in Abschnitt 4.6 skizziert ausnutzen.
Daher ist es in einer Institution wichtig, genau festzulegen, welche Dienste welcher Rechner in
einem Netzwerk anbieten soll und auch zu berprfen, dass keine weiteren, zustzlichen Dienste
angeboten werden.
Eine Mglichkeit der berprfung ist es, die Konguration jedes Rechners in Augenschein
zu nehmen und unerwnschte Dienste abzuschalten. Eine weitere Mglichkeit ist ein Scan des
Netzwerks. Unter diesem Begriff versteht man das Abtasten eines Netzes mit dem Ziel, mglichst detaillierte und umfassende Informationen ber das Netzwerk und die damit verbundenen
Rechner zu erhalten. Ein Scan kann unter anderem dazu dienen,
228
die aktiven Rechner im Netz zu identizieren,

festzustellen, welche Dienste auf den einzelnen Maschinen erreichbar sind,
das Betriebssystem auf den Rechnern zu erkennen und
die Topologie des Netzes zu analysieren.
Es versteht sich von selbst, dass solche Informationen auch fr einen Angreifer von Interesse
sind. Findet er durch einen Scan Schwachstellen in einem Netzwerk, so kann er diese fr einen
Angriff ausnutzen. Ein unautorisierter Scan kann daher die Vorstufe eines Angriffs sein. Daher
ist die Beobachtung derartiger Vorgnge (etwa durch ein IDS) ein sehr ernstzunehmendes Warnsignal. Wir werden uns nun Schritt fr Schritt vorarbeiten und das Scannen nher unter die Lupe
nehmen.
11.3.2 Finden von Gerten im Netz

11.3.2.1 Ping-Sweep
Bei der Analyse eines Netzes stellt sich die Frage, welche Maschinen dort berhaupt vorhanden
sind. Eine Maschine kann dabei jedes Gert mit IP-Adresse sein, angefangen vom Desktop-PC
ber Server bis hin zu Routern. Hat ein Gert mehrere IP-Adressen, so kann es bei einem Scan
auch mehrfach auftauchen. Die Frage, wie man feststellen kann, ob ein Gert mehrere Adressen
hat, wollen wir im Folgenden ausklammern, ebenso die Frage, wie man tatschlich vorhandene
Gerte von virtuellen Maschinen oder Proxies unterscheiden kann.
Eine einfache Mglichkeit, aktive Rechner in IP-basierten Netzen zu nden, ist die Verwendung von ICMP. Dieses Protokoll wurde in 7.3.3.3 kurz beschrieben und dient zur bermittlung
von Statusinformationen und Kontrollnachrichten zwischen Zwischenstationen (auch Empfngern) und Sendern von IP-Paketen. Das Protokoll bietet die Mglichkeit zu berprfen, ob ein
anderer Rechner ber das Netz erreicht werden kann oder nicht.
Hierzu sendet der anfragende Rechner ein ICMP-Paket an den zu berprfenden Rechner mit
dem Typ ICMP-Echo-Request. Erreicht ein solches Paket den Empfnger, so antwortet dieser
unmittelbar mit einer ICMP-Nachricht vom Typ ICMP-Echo-Response. Die bei Echo-Requests/
Responses verwendeten Pakete tragen auch Sequenznummern und Zeitstempel, so dass eine eindeutige Zuordnung der Antworten zu den Anfragen mglich ist. Auf diese Weise kann man durch
die Verwendung von ICMP auch die durchschnittliche Round Trip Time der Verbindung ermitteln, also die Zeit, die ein Paket bentigt um vom Sender zum Empfnger und zurck durch das
Netz befrdert zu werden. Es gibt darber hinaus noch eine ganze Reihe weitere Optionen, die
ICMP-Echo-Requests und Responses bei der Diagnostik in Netzwerken hilfreich machen.
Die einfachste Einsatzmglichkeit des ICMP-Echo-Mechanismus ist seine Verwendung um
festzustellen, ob ein bestimmter Rechner im Netzwerk, dessen IP-Adresse man kennt, berhaupt
erreichbar ist. Ein Anwendungsprogramm, welches das einfache Verwenden von ICMP-Echos
erlaubt, ist das Ping-Programm. Der Begriff Pingen hat sich als Synonym fr das Versenden
eines ICMP-Echo-Requests eingebrgert. Gibt man dem Ping-Programm die IP-Adresse eines
Rechners, so wird ein ICMP-Echo-Request generiert und die Antwort abgewartet. Abbildung
11.5 zeigt einen entsprechenden Screenshot. Wir hatten Ping bereits mehrfach bei unseren praktischen Tests eingesetzt, etwa in Abschnitt 7.4 und Abschnitt 9.2.1.6.
11.3 Scannen
229
Abbildung 11.5: Ping.
Erhlt man also auf ein Ping eine Antwort, so gibt es im Internet einen Rechner, der die entsprechende IP-Adresse verwendet. Die Idee, diesen Mechanismus zu verwenden, um damit aktive Rechner im Netzwerk zu suchen, ist naheliegend.
Will man etwa im Netzwerk 192.168.1.0/24 berprfen, welche Rechner dort aktiv sind, so ist
von vornherein bekannt, welche IP-Adressen in diesem Netz verwendet werden knnen. Dieser
Adressraum wird dann (vollstndig) durch sukzessives Pingen der einzelnen Adressen berprft. Dieses Vorgehen wird als Ping Sweep bezeichnet. Es gibt eine Reihe von Tools, die diese
Aufgabe selbstndig durchfhren.
Mittlerweile hat sich herumgesprochen, dass das Beantworten von Ping-Anfragen mit gewissen Risiken verbunden ist. Daher bieten die meisten Betriebssysteme die Mglichkeit, die Antwort auf ICMP-Echo-Requests zu verhindern und entsprechende Anfragen zu ignorieren.
11.3.2.2 Address Resolution Protocol
Auch das in 7.3.3.6 vorgestellte ARP-Protokoll kann dazu verwendet werden, aktive IP-Adressen
in einem Netzwerk zu ermitteln. Wie bereits erwhnt dient ARP dazu, zu einer gegebenen IPAdresse im eigenen LAN-Segment (Subnetz) die entsprechende MAC-Adresse zu ermitteln.
Sendet man also sukzessive ARP-Queries auf die lokalen IP-Adressen aus, kann man sich anhand
der Antworten ein Bild ber die im Netz verwendeten IP-Adressen machen.
ARP funktioniert nur innerhalb des eigenen Netzwerksegments, daher knnen mit dieser Methode auch nur lokal verfgbare Rechner ermittelt werden.
Die Funktion des ARP-Protokolls, nmlich das Ausen von IP- in MAC-Adressen, ist fr die
Netzwerkkommunikation unentbehrlich. Obwohl es noch andere Probleme mit der Sicherheit des
ARP-Protokolls wie ARP-Spoong gibt (siehe Abschnitt 8.2.3) und Alternativen zu ARP durchaus mglich sind, wird das Protokoll trotzdem in den meisten Netzen eingesetzt. Da ARP nur
im lokalen Netz Verwendung ndet und daher seine Schwchen nur ausgenutzt werden knnen,
wenn ein Angreifer bereits direkten Zugang zum jeweiligen Netzwerk hat, vertrauen viele Insti-
230
tutionen darauf, dass die Absicherung ihrer Netzwerke gegen unbefugte Zugriffe solche Angriffe
verhindert.
11.3.2.3 Domain Name Service
Eine andere Methode, sich Informationen ber ein Netzwerk zu beschaffen, ist die Verwendung
des Domain Name Service (DNS). Wie bereits in 7.3.5.2 beschrieben, wird dieser Dienst dazu verwendet, Domainnamen in IP-Adressen zu bersetzen. Es ist mglich, mittels sogenannter
Zone Transfers die DNS-Daten (Resource Records) ganzer Domainbereiche auf einmal zu erhalten. Dies kann einem Angreifer interessante Informationen ber die Struktur des Netzwerks
und die einzelnen Rechner liefern, speziell bei aussagekrftiger Benennung der Rechner (man
braucht nicht viel detektivischen Sprsinn, um auf eine Idee zu kommen, wer den Rechner
benutzt und in welcher Abteilung er arbeitet). Darber hinaus kann man die IP-Adressen smtlicher Rechner des Netzes mit
extern sichtbaren Domainnamen erhalten.
Die Administratoren eines Netzwerks verfgen ber diese Informationen ohnehin. Daher ist
diese Art der Informationsbeschaffung vor allem fr Angreifer interessant. Systemadministratoren sollten darauf achten, dass die von auen verfgbaren DNS-Informationen ber ein Netzwerk
auf die tatschlich notwendigen Daten (d.h. extern verfgbare Server etc.) beschrnkt sind. Im
Intranet selbst knnen durchaus weitere DNS-Namen vergeben werden, sofern diese nicht vom
Internet aus abgefragt werden knnen. Es empehlt sich also eine strikte Trennung von internem
und externem DNS-System.
11.3.3 Portscanning
11.3.3.1 Prinzipielle Vorgehensweise
Eine weitere Mglichkeit, Rechner zu entdecken oder bereits entdeckte Rechner genauer zu untersuchen, ist Portscanning. Unter diesem Begriff versteht man das Durchprobieren von TCPund/oder UDP-Ports eines Rechners mit dem Ziel festzustellen, welche Dienste auf dem Rechner verfgbar sind. Wie in 7.3.4.1 bereits erwhnt, gibt es Konventionen, welche TCP- und
UDP-Portnummern serverseitig von bestimmten Anwendungsprotokollen verwendet werden. Eine Antwort auf einem entsprechenden Port liefert also bereits einen ersten Hinweis darauf, welcher Dienst wahrscheinlich angeboten wird. Portscanning kann bei TCP und UDP durchgefhrt
werden. Die prinzipielle Vorgehensweise bei UDP und TCP ist sehr hnlich. Da UDP verbindungslos operiert, gibt es bei UDP-Scans weniger Mglichkeiten als fr TCP. Daher werden wir
uns im Folgenden hauptschlich mit TCP befassen.
11.3.3.2 TCP-Connect-Scan
Die einfachste Variante eines TCP-Scans ist der TCP-Connect-Scan. Dabei wird versucht, eine
TCP-Verbindung mit dem zu scannenden Port auf dem Zielsystem aufzubauen. Die bei einem erfolgreichen Verbindungsaufbau durchlaufenen Schritte kennen wir bereits aus Abschnitt 7.3.4.1,
wo sie in Abbildung 7.9 dargestellt wurden. Wenn auf dem gescannten System keine Anwendung
11.3 Scannen
231
(timeout)
SYN
SYN
Zeit
Zeit
SYN
hable
ICMP Port unreac
...
(timeout)
SYN
failed
keine Antwort
ICMP-Port-unreachable-Nachricht
Abbildung 11.6: Mglichkeiten bei fehlgeschlagenen TCP-Verbindungsversuchen.
am berprften TCP-Port auf eingehende Verbindungen wartet, so schlgt der Verbindungsversuch fehl. Dabei gibt es wiederum zwei Mglichkeiten, die in Abbildung 11.6 skizziert sind.
Im ersten Fall erhlt der anfragende Rechner auf das ausgesandte SYN berhaupt keine Antwort. Dies ist im linken Teil der Abbildung dargestellt. Nach mehreren weiteren Versuchen gibt
der anfragende Rechner auf. Die zweite Mglichkeit ist der Erhalt einer ICMP-Nachricht wie
im rechten Teil der Abbildung dargestellt. In diesem Fall sendet der kontaktierte Rechner nach
Empfang des Segments mit gesetzem SYN-Flag eine ICMP-Port-unreachable Nachricht an den
Sender des Segments. Bei Empfang bricht der Sender seinen Versuch, eine Verbindung zum
entsprechenden Port auf dem anderen Rechner aufzubauen, sofort ab. Fr den Sender ist dies
vorteilhaft, denn der Verbindungsaufbau wird in diesem Fall wesentlich schneller abgebrochen
als bei einem Timeout. Der Empfang einer ICMP-Nachricht ist bei einem Scan jedoch eine wertvolle Information, denn er verrt zumindest, dass die entsprechende IP-Adresse tatschlich verwendet wird. Es gibt noch andere Varianten, wie ein Verbindungsversuch fehlschlagen kann, auf
die wir aber hier nicht nher eingehen knnen.
Kommt die Verbindung zustande, so kann man bei vielen Diensten eine Reihe weiterer Informationen sammeln. Begrt einen die dahinterliegende Anwendung mit einer Meldung, welche
die eindeutige Identizierung des antwortenden Programms und dessen Version sowie vielleicht
sogar noch des auf dem Rechner laufenden Betriebssystems ermglicht, kann ein Angreifer dadurch vielleicht sogar schon erfahren, ob ein bestimmter Angriff aufgrund bekannter Schwachstellen in der entsprechenden Version des Programms lohnend erscheint oder nicht. Das Extrahieren von solchen Informationen aus den Begrungsmeldungen der Anwendungen ist unter
dem Begriff Banner Grabbing bekannt. Es hat sich mittlerweile herumgesprochen, dass es nicht
besonders ratsam ist, derartige Informationen jedem zu liefern, der ein Programm kontaktiert.
232
Zeit
SYN
SYN ACK
RST
Abbildung 11.7: Reset vor Abschluss des Three-Way-Handshakes bei TCP.
11.3.3.3 TCP-SYN-Scan
Bei obiger Vorgehensweise kommt zwischen der scannenden Maschine und dem gescannten
Rechner im Erfolgsfall eine Verbindung zustande. Verbindungen werden meistens durch das Betriebssystem und auch die Anwendung protokolliert, welche die Verbindung entgegennimmt,
und in ein Log geschrieben. Auf diese Weise hinterlsst ein potentieller Angreifer also Spuren, die er vielleicht lieber verwischen wrde. Eine Mglichkeit besteht darin, die Verbindung
nicht zustande kommen zu lassen, sondern den Verbindungsaufbau vor der Vervollstndigung
des Three-Way-Handshakes abzubrechen. Diese Variante ist unter dem Namen TCP-SYN-Scan
bekannt und ist in Abbildung 11.7 dargestellt.
Der scannende Rechner beginnt wie bei einem gewhnlichen Verbindungsaufbau. Erhlt er
die beim Three-Way-Handshake bliche Antwort, so bricht der scannende Rechner den Verbindungsaufbau ab, indem er nicht wie normalerweise den Empfang des Segments mit gesetztem
SYN-Flag und gesetztem ACK-Flag besttigt, sondern ein Segment mit gesetztem RST-Flag
(Reset) zurckschickt und damit den Verbindungsaufbau abbricht. Natrlich ist bei einem solchen Scan Banner Grabbing nicht mglich. Dafr ist die Wahrscheinlichkeit, dass der Scan unentdeckt bleibt, etwas hher.
11.3.3.4 Weitere TCP-Scans
Eine weitere Mglichkeit, TCP-Ports zu berprfen, besteht darin, gar nicht erst eine Verbindung aufzubauen, sondern TCP-Segmente zu fabrizieren, die zu keiner Verbindung gehren. Die
Reaktion auf solche Segmente erlaubt wiederum Rckschlsse auf die Frage, ob die IP-Adresse
tatschlich in Verwendung ist und ob an dem Port ein Programm auf eingehende Verbindungen
11.3 Scannen
233
wartet oder nicht. Die TCP-Spezikation [RFC 793] verlangt, dass solche Segmente an Ports,
die nicht auf eingehende Verbindungen warten, mit einem TCP-Reset beantwortet werden mssen, whrend an Ports, die auf Verbindungen warten, keine Reaktion erfolgen sollte. Auch wenn
einige Betriebssysteme diese Spezikationen nicht exakt erfllen, ist ein TCP-Reset als Antwort auf ein fabriziertes TCP-Segment zumindest ein klares Indiz dafr, dass die entsprechende
IP-Adresse in Betrieb ist.
Es ist sogar mglich, einen anderen Rechner zu scannen, ohne ihn direkt zu kontaktieren.
Beim sogenannten Idle-Scan sendet der scannende Rechner eine Anfrage mit einer geflschten
IP-Quelladresse an das Zielsystem. Die IP-Quelladresse gehrt dabei einem dritten Rechner, der
je nachdem, ob der gescannte Port offen oder geschlossen ist, unterschiedliche Antworten vom
Zielsystem erhlt (die er gar nicht angefordert hat) und auf diese dann auch unterschiedlich reagiert. Diese Reaktionen des dritten Rechners beobachtet der scannende Rechner dabei indirekt,
indem er den dritten Rechner vorher und nachher scannt. Der dritte Rechner mu dabei nicht
einmal unter der Kontrolle des Angreifers stehen, allerdings funktioniert dieser Scan nur unter
bestimmten Voraussetzungen.
11.3.3.5 OS-Fingerprinting
Durch die oben verwendeten Methoden lassen sich nicht nur aktive IP-Adressen und angebotene
Dienste ermitteln, sondern oftmals ist es auch mglich, das auf dem gescannten Rechner laufende
Betriebssystem mehr oder weniger genau zu bestimmen. Dieses Vorgehen ist unter dem Namen
OS (Operating System)-Fingerprinting bekannt. Einige der Merkmale, die eine Identizierung
des Betriebssystems erlauben knnen, sind:
die auf der Maschine verfgbaren Dienste,
durch Banner Grabbing erhaltene Informationen und
die Analyse der Reaktionen des Betriebssystems auf bestimmte Anfragen.
Die ersten beiden Punkte bedrfen keiner weiteren Erluterung, doch auf den letzten Punkt
wollen wir noch etwas genauer eingehen. Die Implementierung des TCP/IP-Protokollstacks unterscheidet sich von Betriebssystem zu Betriebssystem geringfgig. Diese geringfgigen Unterschiede zeigen sich in marginalen Differenzen im Verhalten in bestimmten Situationen. Testet
und beobachtet man gezielt das Verhalten eines Rechners im Hinblick auf diese Unterschiede,
so kann man dadurch relativ przise feststellen, welches Betriebssystem auf der Maschine luft.
Nimmt man all diese Informationen zusammen, so knnen sogar in einigen Fllen bestimmte
Varianten desselben Betriebssystems unterschieden werden.
11.3.4 Schutz vor Scanning

Zusammenfassend kann eine Analyse von durch Scanning gewonnenen Daten einem Angreifer
eine Flle von Informationen ber das gescannte Netz liefern, bis hin zu mglichen Angriffspunkten, von denen ausgehend sich der Angreifer dann vorarbeiten kann. Aus Sicherheitsgrnden ist es also ratsam, darauf zu achten, dass durch Scanning mglichst wenig oder sogar keine
Informationen ber das Netz und die im Netz bendlichen Rechner gewonnen werden knnen.
234
Um Scans eines unternehmensinternen Intranets aus dem Internet zu unterbinden, bietet sich
eine entsprechende Konguration der Firewall an. Werden bereits an der Firewall ICMP-EchoRequests und eingehende TCP-Verbindungsanfragen geblockt, sind einige der oben skizzierten
Scanning-Methoden aus dem Internet heraus schon nicht mehr praktikabel, da sie durch die Firewall unterbunden werden. Ist die Firewall dynamisch, knnen auch unangefordert an das Intranet
gerichtete UDP-Datagramme blockiert werden, und fabrizierte TCP-Segmente, die nicht zu einer
bestehenden Verbindung gehren, werden ebenfalls aufgehalten. Auch die strikte Trennung zwischen internem und externem DNS-System kann durch die Firewall berwacht werden. Wenn
die Firewall also restriktiv genug ist, dann kann sie Scans des hinter ihr liegenden Netzes nahezu
ganz verhindern. Der Vollstndigkeit halber sei erwhnt, dass bestimmte Arten von Scans auch
Informationen ber die zum Schutz des Intranets verwendete Firewall liefern.
Das Scannen eines Intranets von einem Rechner aus dem Intranet heraus lsst sich so gut wie
nicht verhindern. Jeder Dienst, den ein Rechner im Intranet bereitstellt, ist durch einen Scan
zu entdecken. Nicht nur deshalb ist es ratsam, die in Abschnitt 4.6 skizzierten Manahmen zu
befolgen und nicht bentigte Dienste auf den Rechnern abzuschalten. Da man Scans im Intranet
nicht verhindern kann, sollte man sie wenigstens entdecken, um geeignete Gegenmanahmen
einleiten zu knnen. Dies ist ein Grund, warum der Betrieb eines IDS wichtig ist.
11.3.5 Scanning zum Schutz des Netzes

Die Mglichkeit Netze zu scannen kann nicht nur von Angreifern missbraucht werden, um Informationen ber mgliche Ziele zu erhalten, sondern Scannen kann vor allen Dingen auch gezielt
dazu eingesetzt werden, die Sicherheit des Netzes im laufenden Betrieb zu berwachen. Ein
Systemadministrator kann durch den Scan seines Netzes
bestehende Schwachstellen in angebotenen Diensten nden (bevor ein Angreifer dies tut)
und
unerwnschte, von Benutzern oder Malware unautorisiert oder ungewollt eingerichtete
Dienste nden.
Der erste Punkt ist klar und bedarf eigentlich keiner weiteren Erluterung. Das Finden unautorisiert eingerichteter Dienste durch Scans ist ein sehr wichtiger Punkt. Hat beispielsweise
ein Nutzer unautorisiert einen Webserver auf seinem PC eingerichtet, wird ein Scan des Systems
diesen Dienst nden und die Abschaltung des Dienstes kann veranlasst werden. Gleiches gilt fr
unerlaubt verwendete Zusatzkomponenten (WLAN-Router, privater Laptop, etc.).
Es wird manchmal diskutiert, inwieweit Tools, die eine berprfung der Sicherheit in Netzen
erlauben, schdlich oder ntzlich sind und beispielsweise verboten und deren Benutzung unter
Strafe gestellt werden sollten. Die Antwort auf diese Frage sollte eigentlich offensichtlich sein:
Verbietet man diese Werkzeuge, so werden sich die Angreifer von deren Einsatz wohl kaum
abbringen lassen. Fr einen Angreifer ist die berprfung des Netzes oft nur die Vorstufe zu
einem Angriff, der ohnehin strafrechtlich verfolgt werden kann. Umgekehrt verlieren die Betreiber der Netze bei einem Verbot die Mglichkeit, ihr Netz regelmig (wie ein Angreifer) auf
Schwachstellen zu prfen und so vorbeugend aktiv werden zu knnen. Somit ist ein Verbot dieser
Werkzeuge also wenig hilfreich.
235
Bedauerlicherweise ndet der Einsatz und die Entwicklung solcher sinnvollen Tools zur Verbesserung der IT-Sicherheit in Deutschland zuknftig trotzdem in einer rechtlichen Grauzone
statt. Im Sommer 2007 wurde vom Gesetzgeber das Strafrechtsnderungsgesetz (StrndG) zur
Bekmpfung der Computerkriminalitt beschlossen [StrndG]. In 202c Abs. 1 heit es wrtlich: Wer eine Straftat (..) vorbereitet, indem er (...) Computerprogramme, deren Zweck die
Begehung einer solchen Tat ist, herstellt, sich oder einem anderen verschafft, verkauft, einem
anderen berlsst, verbreitet oder sonst zugnglich macht, wird mit Freiheitsstrafe bis zu einem
Jahr oder mit Geldstrafe bestraft. Viele Branchenvertreter befrchten wohl nicht zu Unrecht,
dass gerade der oben zitierte Satz 2 die Arbeit von IT-Sicherheitsexperten und Forschern kriminalisieren knnte. Tools, die Netzwerke analysieren, um Schwachstellen aufzuspren, sind per
se immer auch dazu geeignet, zur Vorbereitung eines Angriffs missbraucht zu werden.
Somit sehen sich zumindest die Entwickler solcher Werkzeuge nun mit einer unklaren Rechtslage konfrontiert. Es bleibt abzuwarten, wie die ersten Przedenzflle vor Gericht entschieden
werden. Sollte es tatschlich zu Urteilen kommen, welche die Entwickler von Sicherheitstools
oder Betreiber von Webseiten, die diese anbieten, kriminalisieren, so wre dies wahrscheinlich
ein ausgesprochen kontraproduktives Ergebnis.
Hacker mit kriminellen Absichten werden sich durch einen solchen Paragraphen kaum abschrecken lassen, da sie ohnehin noch weit schwerere Straftaten begehen, wohl aber rechtschaffene Sicherheitsexperten. Damit wre ungewollt ein gesetzlicher Vorsprung fr kriminelle Hacker
gegenber den Sicherheitsexperten geschaffen worden.
Unter Intrusion Detection versteht man das berwachen von Systemen und/oder Netzwerken mit dem Ziel, unerwnschte oder nicht autorisierte Vorgnge zu erkennen,
zu protokollieren und zu melden. Es gibt verschiedene Typen von Intrusion Detection Systemen, darunter insbesondere netzwerkbasierte und hostbasierte Systeme sowie
hybride Formen. Intrusion Detection Systeme knnen Angriffe, Missbrauch oder auch
irregulres Systemverhalten bemerken. Problematisch bei einem Intrusion Detection
System ist die richtige Austarierung der Konguration, so dass einerseits Fehlalarme
vermieden werden, aber andererseits tatschliche Intrusions auch wirklich gemeldet
werden. Ein netzwerkbasiertes Intrusion Detection System besteht aus einem oder
mehreren Sensoren, die ihre Meldungen an einen Server mit Datenbankfunktion weiterleiten. Die Sensoren sollten so positioniert sein, dass das gesamte Netzwerk abgedeckt wird.
Durch Netzwerkscanner ist es mglich, ein Netzwerk aktiv auf vorhandene Dienste
und mgliche Schwachstellen zu berprfen. Es gibt eine Vielzahl von Mglichkeiten, wie aktive Rechner in einem Netzwerk ermittelt werden knnen, angefangen von
der Verwendung von Funktionen der Netzwerkschicht bis hin zu verschiedenen Varianten von Portscans. Dabei ist es eventuell sogar mglich, das Betriebssystem eines
Rechners festzustellen.
236
11.5 bungsaufgaben
Aufgabe 11.1:
Denieren Sie den Begriff Intrusion Detection System.
Aufgabe 11.2:
Erklren und klassizieren Sie mgliche Ursachen fr den Alarm eines Intrusion Detection Systems.
Aufgabe 11.3:
Erlutern Sie Aufbau, Funktionsweise und Architektur eines netzwerkbasierten Intrusion Detection Systems. Gehen Sie dabei auch auf die verschiedenen mglichen Typen von Sensoren ein.
Aufgabe 11.4:
Beschreiben Sie Gemeinsamkeiten und Unterschiede von netzwerkbasierten Intrusion Detection
Systemen und Paketltern.
Aufgabe 11.5:
Skizzieren Sie, wie und unter welchen Voraussetzungen ein Intrusion Detection System unautorisiert aufgestellte WLAN-Access-Points entdecken kann.
Aufgabe 11.6:
Erklren Sie, wie man aktive Gerte in einem Netzwerk entdecken kann und welche Mglichkeiten es gibt, dies zu verhindern.
Aufgabe 11.7:
Beschreiben Sie die verschiedenen vorgestellen Varianten von TCP-Port-Scanning und vergleichen Sie sie.
Aufgabe 11.8:
Erlutern Sie, was man unter OS-Fingerprinting versteht.

Aufgabe 11.9:
Ein in der Praxis eingesetztes IDS ist das Open-Source-System Snort [Snort-Web]. Recherchieren Sie Details der Funktionsweise von Snort und mglicher Zusatzkomponenten des Programms. Installieren Sie Snort auf einem Rechner und testen Sie seine Funktionsweise.
Kapitel 12
Verfgbarkeit
12
Verfgbarkeit
12.1 Einleitung
Ein Ziel von IT-Sicherheit, das wir bisher nur am Rande betrachtet haben, ist die Verfgbarkeit
von Daten und Diensten fr legitime Benutzer in einem Netzwerk. Intuitiv ist klar, was mit
diesem Begriff gemeint ist, und man kann Verfgbarkeit auch quantitativ kurz und prgnant
denieren. In einem Zeitintervall t ist die Verfgbarkeit nichts anderes als der Quotient aus der
Zeit, in der der betrachtete Dienst oder die Daten zur Verfgung standen, und der Gre des
Zeitintervalls. Ist die Verfgbarkeit eines Dienstes oder von Daten bekannt, gibt dieser Wert also
die Wahrscheinlichkeit dafr an, dass Dienst oder Daten zu einem bestimmten Zeitpunkt des
Zeitintervalls zur Verfgung standen.
Mehr und mehr Anwendungen der elektronischen Datenverarbeitung sind fr die sie betreibenden Institutionen kritisch. Unter einer kritischen Anwendung verstehen wir eine Anwendung,
deren Ausfall fr die Institution mit schwerwiegenden Folgen verbunden ist. Das Spektrum solcher kritischer Netzwerkanwendungen reicht von missionsnotwendigen Systemen in Unternehmen (Workowmanagement, Supply Chain Automation ...) bis hin zu im Gesundheitswesen eingesetzten Systemen, etwa zur elektronischen berwachung der Vitalfunktionen von Patienten.
Entsprechende Systeme bestehen aus einer Vielzahl sowohl hinsichtlich ihrer Rechenleistung als auch ihren Kommunikationsmglichkeiten heterogener, autonomer Einzelgerte, die erst
durch die Vernetzung untereinander die zu erfllenden Aufgaben erledigen knnen.
Die Folgen eines Ausfalls kritischer Anwendungen knnen von Unannehmlichkeiten bis hin
zu katastrophalen Ereignissen reichen. Der ungestrte Ablauf kritischer Netzwerkanwendungen
kann nur dann dauerhaft gewhrleistet werden, wenn sowohl die beteiligten Applikationsprogramme und verwendeten Rechner als auch die zur Kommunikation verwendeten Netzwerke
sicher sind.
Eine klassische kritische Anwendung ist Telefonie. Aufgrund ihrer Bedeutung fr die Institution existiert zwischen der Institution und dem Service Provider, welcher die Telefonieleistung
erbringt, hug ein Service Level Agreement (SLA). Diese Vereinbarung legt unter anderem die
Verfgbarkeit der Leistung fest. Wird diese durch den Service Provider verletzt, so muss der
Provider den Kunden nanziell entschdigen. Im Telefoniebereich ist eine Verfgbarkeitsanforderung von 0, 99999 blich. Wie Tabelle 12.1 zeigt, entspricht dies einer Ausfallzeit von ungefhr
nur fnf Minuten pro Jahr.
Fr viele Unternehmen sind mittlerweile Systeme der Datenverarbeitung wie Server und Datenbanken ebenso wichtig wie Telefonie, und auch Telefoniedienste und andere Echtzeitkommunikation werden zunehmend ber Datennetze abgewickelt (siehe Kapitel 14). Daher hat in den
238
12 Verfgbarkeit
Verfgbarkeit
0,9
0,99
0,999
0,9999
0,99999
Ausfallzeit pro Jahr

36 Tage
3 Tage
12 Stunden
15 Stunden
8 Stunden
36 Minuten
46 Minuten
52 Minuten
5 Minuten
33 Sekunden
15 Sekunden
Tabelle 12.1: Ausfallzeit pro Jahr fr verschiedene Verfgbarkeiten.
letzten Jahren das Interesse an Methoden und Verfahren, welche die Verfgbarkeit von Systemen
verbessern, stetig zugenommen. Es ist damit zu rechnen, dass dieser Trend auch in den nchsten
Jahren anhalten wird.
Um die Verfgbarkeit von Daten und Diensten zu erhhen, sind eine ganze Reihe von Manahmen mglich, etwa eine Steigerung der Zuverlssigkeit durch redundante Hard- und Softwarekomponenten und die strkere Bercksichtigung der Zuverlssigkeitsanforderungen im Entwurfsprozess.
Ein System kann aus vielen verschiedenen Grnden nicht verfgbar sein, durch Hardwarefehler, Softwarefehler oder auch durch Fehler in der Bedienung des Systems. Eine weitere Mglichkeit, auf der unser Fokus liegt, ist die gezielte Sabotage des Systems durch einen Angreifer,
beispielsweise durch einen Denial-of-Service-Angriff.
Solche Handlungen knnen den vollstndigen Ausfall des Systems verursachen oder aber das
System in seinem Leistungsumfang einschrnken. Dieses werden wir im Folgenden als Strung
bezeichnen.
Es ist nicht schwer, sich auszumalen, welches Chaos entstehen wrde, wenn kritische Anwendungen im wirtschaftlichen oder ffentlichen Bereich durch einen Angriff gestrt oder ausgeschaltet wrden. Fr ein Online-Unternehmen kann schon die dauerhafte Strung eines Webservers katastrophale Folgen haben.
Auch wenn wir uns in diesem Buch hauptschlich mit Angriffen auf informationstechnischem
Weg beschftigen, sollen an dieser Stelle physische Angriffe auf die Systeme nicht unerwhnt
bleiben. Der Dienst eines Servers lsst sich physisch auf vielfltige Weise sabotieren. Das fngt
mit dem einfachen Abschalten des Servers an. Ein gezielter Schlag mit einer Axt oder einem
Hammer kann ebenso helfen. Auch das Unterbrechen der Stromversorgung oder der Netzwerkleitungen ist mglich. Alles in allem mssen Institutionen geeignete Manahmen ergreifen, um
ihre kritische Infrastruktur vor solchen physischen Angriffen zu schtzen. Hierzu gehrt eine Zugangskontrolle ebenso wie die geeignete Versorgung eines Rechenzentrums mit mehreren redundanten Netzwerk- und Stromversorgungsverbindungen.
Generell ist Redundanz ein wichtiges Mittel, um die Verfgbarkeit von Systemen zu erhhen.
Dies gilt nicht nur fr die Hardware, sondern auch fr die Software. Bereitgestellte Dienste,
deren Verfgbarkeit kritisch ist, sollten auf mehreren Servern verfgbar sein, so dass im Falle
des Ausfalls eines Rechners die anderen Rechner den Dienst weiterhin zur Verfgung stellen
knnen. Werden die Server weltweit durch geographische Verteilung und eine entsprechende
12.2 Denial-of-Service (DoS)
239
systematische Replizierung der Daten betrieben, so ist selbst im Fall regionaler Katastrophen
(die nicht unbedingt auf einen vorstzlichen Angriff zurckzufhren sein mssen ein lngerer
grochiger Stromausfall reicht bereits aus) ein Weiterbetrieb der Services mglich.
Wenden wir uns nun Angriffen auf die Verfgbarkeit zu, die auf elektronischem Weg herbeigefhrt werden.

12.2.1 Klassikation
Eine Denial-of-Service-Attacke (DoS-Attacke) ist ein elektronischer Angriff auf die Verfgbarkeit eines Systems oder eines Dienstes. Ziel ist es also, das System oder den Dienst zum Ausfall
zu bringen oder zu stren, so dass autorisierte Benutzer das System oder den Dienst nicht oder
nur eingeschrnkt verwenden knnen. Solche Angriffe knnen sich auch gegen einzelne Benutzer richten. Es gibt verschiedene Typen von Denial-of-Service-Angriffen, und der Phantasie der
Angreifer sind (leider) keine Grenzen gesetzt.
Beginnen wir mit einem ganz einfachen Beispiel fr einen solchen Angriff. Eine Institution
betreibt einen Webserver, auf den nach dem Durchfhren einer erfolgreichen Benutzerauthentikation (Username und Passwort) zugegriffen werden kann. Aus Sicherheitsgrnden ist der
Webserver so konguriert, dass nach dreimaliger erfolgloser Eingabe des Passworts das mit dem
Username verbundene Benutzerkonto gesperrt wird. Diese Vorgehensweise ist eine Steilvorlage
fr einen DoS-Angriff. Ein Angreifer muss nur einen Benutzernamen kennen (oder erraten) und
dreimal ein falsches Passwort eingeben, und schon ist der Dienst fr den betreffenden Benutzer
gesperrt. Wird als Benutzername beispielsweise eine Email-Adresse verlangt, ist er nicht allzu
schwer zu erraten. Ein derartiger Angriff auf einen Online-Shop wre fr dessen Betreiber mit
Sicherheit zumindest unangenehm.
Einen solchen Angriff zu verhindern, gestaltet sich nicht besonders schwierig. Man msste
einfach die Sperrung der Konten nach dreimaliger Eingabe eines falschen Passworts aufheben.
Generell bietet sich eine solche Sperrung aufgrund der eben dargestellten Missbrauchsmglichkeit nur in sehr speziellen Szenarien an (siehe Abschnitt 3.3.1).
Doch auch ohne eine Schwachstelle hat ein Angreifer die Mglichkeit, die Verfgbarkeit des
Dienstes durch eine gezielte berlastung einzuschrnken. Kann der Webserver beispielsweise
ca. 1.000 Login-Versuche pro Sekunde bearbeiten und ist der Angreifer in der Lage, 10.000
Login-Versuche zu generieren, so kann der Server auch hierdurch lahmgelegt werden.
Ganz allgemein knnen DoS-Angriffe also in zwei Kategorien eingeteilt werden:
Ausnutzen von Design- oder Implementierungsfehlern: Der Angreifer kann durch das Ausnutzen von Schwachstellen in Design oder Implementierung die Verfgbarkeit beeintrchtigen. Der Angreifer bentigt in der Regel geringe Ressourcen, um einen solchen Angriff
durchzufhren.
Herbeifhren einer berlastung: Durch gezieltes berlasten wird die Verfgbarkeit beeintrchtigt. Der Angreifer muss fr einen solchen Angriff in der Regel umfangreiche Ressourcen aufwenden.
240
12 Verfgbarkeit
Diese beiden Kategorien sind nicht exklusiv. Es gibt auch Angriffe, die in beide Kategorien
fallen. In der Regel wird sich ein Angreifer beim Herbeifhren einer berlast an einer Stelle zu
schaffen machen, an der die Ressourcen knapp sind. In beiden Fllen muss der Angriff nicht auf
das System oder den Dienst selbst durchgefhrt werden, sondern kann auch gegen Hilfskomponenten gerichtet sein, die fr die Funktion des Dienstes oder des Systems bentigt werden. So
kann beispielsweise die Netzwerkverbindung zu einem Server durch einen Angriff auf den Router unterbrochen werden, an den der Server angeschlossen ist, oder das Netzwerk, in welchem
sich der Server bendet, kann berlastet werden.
12.2.2 Ausnutzen von Schwachstellen: Ping of Death

Wir werden im Folgenden einige Methoden genauer betrachten, die fr DoS-Angriffe verwendet
wurden. Ein gutes Beispiel dafr, wie man durch Schwachstellen in Design oder Implementierung mit geringem Aufwand ein ganzes System zum Absturz bringen kann (oder besser gesagt:
konnte), ist der berchtigte Ping of Death. Diese Schwachstelle wurde 1996 aufgedeckt. Sie betraf die Implementierung des IP-Protokolls und war bei einer groen Zahl von Betriebssystemen
vorhanden, die allesamt mit Patches versehen werden mussten, um diese Lcke zu schlieen.
Das zugrundeliegende Problem ist einfach erlutert: Die maximale Gre eines IP-Pakets (siehe 7.3.3.1) betrgt inklusive Header 216 1 = 65535 Bytes. Die meisten Technologien erlauben
nur weitaus kleinere Rahmengren auf der Datenverbindungsschicht, Ethernet beispielsweise maximal 1500 Bytes. Daher fragmentiert die IP-Schicht Pakete, die grer sind, in mehrere
Fragmente passender Gre, welche dann ber die Datenverbindungsschicht versendet werden.
Die einzelnen Fragmente des ursprnglichen Pakets enthalten Informationen, durch die sie auf
der IP-Schicht des Empfngers wieder zum ursprnglichen IP-Paket zusammengesetzt werden
knnen. Bei diesem Zusammensetzen nahmen die meisten Systeme implizit (ohne dies zu verizieren) an, dass die maximal zulssige Gre eines IP-Pakets durch das Zusammensetzen der
einzelnen Fragmente eines ursprnglichen Pakets nicht berschritten wird. Geschah dies doch,
so kam es zu Programmfehlern im IP-Code und damit letztlich zum Absturz des betroffenen
Systems.
Der Fehler war als Ping of Death bekannt, da es durch die Verwendung von ICMP-EchoRequests (siehe 7.3.3.3) besonders leicht mglich war, IP-Pakete mit einer nicht dem Standard
entsprechenden Gre zu erzeugen. Eine detaillierte Darstellung des Ping of Death ndet sich
im WWW unter [Insec-Web].
12.2.3 Ausnutzen von Schwachstellen und berlastung

12.2.3.1 SYN-Flood
Ein weiteres schnes Beispiel fr einen DoS-Angriff ist die sogenannte SYN-Flood-Attacke. Dieser Angriff richtet sich gegen Netzwerkdienste, die TCP als Transportprotokoll verwenden, und
ist eigentlich eine Mischung aus dem Ausnutzen von Schwachstellen und dem Herbeifhren einer berlastsituation. Wir hatten TCP bereits in Abschnittt 7.3.4.1 skizziert. Dort wurde auch
bereits der Verbindungsaufbau zu Beginn einer TCP-Verbindung erlutert.
241
Angreifer
Server
Zeit
SYN
SYN ACK
speichert Verbindungsversuch
und reserviert Ressourcen
antwortet nicht
Timeout
Abbildung 12.1: Angriff mittels einer SYN-Flood.
Der SYN-Flood-Angriff basiert auf einem Missbrauch des Mechanismus zum Aufbau einer
TCP-Verbindung durch einen Angreifer, der gar nicht die Absicht hat, wirklich eine Verbindung
aufzubauen. Er geht dabei wie in Abbildung 12.1 skizziert vor und schickt an den Server ein
TCP-Segment mit gesetztem SYN-Flag zum Verbindungsaufbau. Der Server speichert die im
Aufbau bendliche Verbindung ab, reserviert eventuell sogar bereits Ressourcen fr die Verbindung und beantwortet das erhaltene Segment durch das Senden des SYN ACK. Doch dieses
bleibt durch den Angreifer unbeantwortet, so dass der Server mehrere Versuche unternimmt, das
SYN ACK an den Client zu bertragen und schlielich erst durch einen Timeout den vermeintlichen Verbindungswunsch verwirft.
Die Anzahl solcher angefragten, aber noch nicht zustandegekommenen Verbindungen ist limitiert, da der Server diese abspeichern muss und gegebenenfalls bereits Ressourcen (Puffer
etc.) reserviert. Daher kann ein berschwemmen des Servers mit solchen Anfragen dazu fhren, dass ernsthafte Verbindungsaufbauversuche vom Server nicht entgegengenommen werden
knnen oder der Server aufgrund der berlast sogar vollstndig zusammenbricht.
Was solche Angriffe noch gefhrlicher macht, ist, dass sie sich wunderbar mit geflschten IPAbsenderadressen durchfhren lassen, dem sogenannten IP-Address-Spoong (siehe Abschnitt
8.2.4). Dabei benutzt der Angreifer nicht seine eigene Adresse, sondern gibt eine geflschte IPAdresse an, von der er wei, dass sie auf eingehende TCP-Segmente mit gesetztem SYN-Flag
und gesetztem ACK-Flag nicht reagiert, beispielsweise weil kein Rechner unter dieser Adresse
aktiv ist oder sich der Rechner hinter einer Firewall bendet, die solche Pakete herausltert. Entsprechende Adressen sind nicht schwierig zu ermitteln. Der Server schickt dann seine Antwort an
den vermeintlichen Initiator der Verbindung, der aber nicht antwortet. Eine SYN-Flood in Verbindung mit IP-Address-Spoong ist rafniert, denn der Server erkennt aufgrund der geflschten
Adressen nicht, dass nur ein Rechner fr eine Vielzahl von Verbindungsanfragen verantwortlich
ist. Zudem bleibt die wahre IP-Adresse des Angreifers unsichtbar. Weitere Details zum SYNFlood-Angriff nden sich im unter [CERT-Web] erhltlichen Advisory CA-1996-21.
242
12 Verfgbarkeit
Opfer antwortet mit SYN ACKs an die geflschten

Adressen, die nirgendwo landen
Internet
Angreifer erzeugt TCP SYNs mit geflschten

IP-Quelladressen
Abbildung 12.2: Angriff mittels einer SYN-Flood und IP-Spoong.
Wenden wir uns nun der Frage zu, wie man sich gegen einen SYN-Flood-Angriff schtzen
kann, und beginnen mit dem betroffenen Server selbst. Dieser hat keine Mglichkeit, ernstgemeinte Verbindungsanfragen mit korrekter IP-Adresse von Angriffen mit einer gegebenenfalls
sogar geflschten IP-Adresse zu unterscheiden. Damit bleiben noch die Mglichkeiten, keine
oder mglichst wenige Ressourcen fr noch nicht vollstndig geffnete TCP-Verbindungen zu
reservieren, den vorgesehenen Speicherplatz fr noch nicht vollstndig etablierte Verbindungen
zu vergrern oder die Timeouts zu verkleinern. Doch diese Manahmen fhren letztlich nicht
zu einer Verhinderung des Angriffs, sondern nur zu einer (geringfgigen) Vergrerung der notwendigen Ressourcen beim Angreifer. Somit gibt es gegen einen solchen Angriff letztlich keine
wirksame Mglichkeit der Verteidigung durch den Server selbst.
Wenn man sicherstellen knnte, dass jede Maschine im Internet ausschlielich ihre richtige
IP-Adresse verwendet, so wre es serverseitig mglich, eine Obergrenze fr die maximale Zahl
noch nicht vollstndig etablierter TCP-Verbindungen von einer IP-Quelladresse aus festzulegen.
Hierdurch wird es einem Rechner unmglich, einen SYN-Flood-Angriff mit seiner eigenen, echten IP-Adresse durchzufhren. Wenn man also zustzlich noch die Flschung von IP-Adressen
verhindern knnte, so wre der oben beschriebene Angriff nicht mehr ohne weiteres mglich und
SYN-Flood-Angriffe knnten unterbunden werden.
Geflschte IP-Adressen lassen sich zwar beim Server nicht mehr als solche identizieren, die
Betreiber von Netzen, insbesondere die Service Provider, haben aber die Mglichkeit, geflschte
IP-Adressen, die von Netzen ihrer Kunden aus verwendet werden, zu erkennen und die entsprechenden Pakete aufzuhalten, nmlich bevor sie in das Transitnetz gelangen.
Dies gelingt folgendermaen: Hat ein Serviceprovider an einen Kunden den Netzwerkadressbereich A vergeben oder betreibt ein Netzbetreiber ein Netz mit Adressbereich A, so mssen
(mit kleinen Ausnahmen) alle Pakete, die aus diesem Netz stammen, mit einer Adresse aus diesem Bereich A als IP-Quelladresse versehen sein. Schlielich werden auch nur IP-Pakete mit
243
Internet
Rechner senden TCP-SYNs zur

angegriffenen Maschine
Opfer
Angreifer sendet Kommandos an

andere Rechner, SYNs an das
Opfer loszuschicken
Abbildung 12.3: Distributed-Denial-of-Service.
einer IP-Zieladresse im Bereich A wieder an dieses Netz geroutet. Werden Pakete mit anderen
IP-Quelladressen durch den Service Provider aussortiert, so ist das beliebige Flschen von Adressen aus diesem Netz heraus nicht mglich. Flschungen knnten ausschlielich IP-Quelladressen
aus dem Bereich A tragen. Damit liee sich im Falle einer DoS-Attacke zumindest eingrenzen,
woher die Anfragen stammen. Diese Information knnten sowohl zur Verhinderung zuknftiger
Angriffe, etwa durch Blocken aller Anfragen von Rechnern aus dem Bereich A, als auch zur
Tterermittlung eingesetzt werden (siehe [RFC 2827]).
Es sollte aber nicht verschwiegen werden, dass das Herausltern vermeintlich geflschter IPQuelladressen auch Nachteile hat, denn es verhindert nicht nur Missbrauch, sondern schrnkt
auch die Verwendung des Netzes ein. So gibt es bestimmte Protokolle, in denen die Verwendung
einer IP-Adresse aus Netz A heraus, die nicht selbst zu Netz A gehrt, vorgesehen ist. Speziell
betrifft dies Protokolle zur Mobilittsuntersttzung wie Mobile IP [RFC 3344].
12.2.3.2 Distributed-Denial-of-Service (DDos)
Selbst wenn geflschte IP-Adressen ausgeschlossen sind, kann ein Angreifer den Schutz umgehen und eine Denial-of-Service-Attacke starten, die nach demselben Prinzip funktioniert, aber
weitaus ausgeklgelter ist und auch einiges mehr an Vorarbeit erfordert. Da wie besprochen
geflschte IP-Absenderadressen zum Durchfhren der Attacke nicht mehr verwendet werden
knnen, mssen die SYNs von einer Vielzahl echter IP-Quelladressen stammen. Eine mgliche
Methode ist es, durch die Verbreitung von Malware (siehe Kapitel 6) Rechner zu kompromittieren und eine Software zu installieren, die auf Befehle des Angreifers wartet und dann auf
Kommando entsprechende SYN-Nachrichten auf dem unterwanderten Fremdrechner generiert.
Dies ist in Abbildung 12.3 dargestellt. Hat man genug Fremdrechner unter Kontrolle, so wird
sich ein solcher Angriff erfolgreich durchfhren lassen.
Gegen solche Distributed-Denial-of-Service (DDos)-Angriffe gibt es nur wenige Schutzmglichkeiten, da die Angriffe von richtigen IP-Quelladressen aus durchgefhrt werden und die Anfragen somit von echten Verbindungsanfragen nicht zu unterscheiden sind.
DDos-Angriffe betreffen nicht nur TCP, sondern knnen auch ber einer Reihe anderer Protokolle durchgefhrt werden, beispielsweise DNS.
244
12 Verfgbarkeit
12.2.4 Herbeifhren einer berlastung

12.2.4.1 berlastsituationen
Die bisher dargestellten Methoden haben an empndlichen Teilen eines Systems eine berlast
herbeigefhrt und so das System angegriffen. Nun wenden wir uns abschlieend DoS-Angriffen
zu, die nicht einmal auf eine besonders anfllige Stelle zielen, sondern einfach nur mittels berlastung arbeiten.
Nehmen wir als erstes Beispiel berlastung im (scheinbar) regulren Betrieb: Wenn ein Webserver pro Sekunde 100 Anfragen beantworten kann, und ein Angreifer 10.000 Anfragen pro
Sekunde an den Server schickt, so wird eine berlastung die Folge sein, die den Absturz des
Servers nach sich ziehen kann. Selbst wenn wir annehmen, dass der Server weiterhin voll funktionsfhig bleibt und die ber seine Kapazitten hinausgehenden Anfragen einfach ignoriert,
so werden viele der echten eingehenden Anfragen nicht mehr beantwort. Unterstellt man dabei
weiter, dass der Server zwischen den Anfragen des Angreifers und echten Anfragen nicht unterscheiden kann (beispielsweise da der Angreifer die Attacke als DDos-Angriff durchfhrt), so
liegt die Wahrscheinlichkeit, dass eine Anfrage beantwortet wird, nur noch bei 0,01, also einem
Prozent.
Ebenso ist es mglich, die Netzwerkanbindung einer Institution zu berlasten. Wenn es einem
Angreifer gelingt, 100 Mbps an die Institution zu senden, diese aber nur mit 1 Mbps angebunden
ist, so wird ein Groteil der an die Institution gesendeten Nachrichten verlorengehen.
Diese Arten von Angriffen sind primitiv, aber efzient, und es gibt nur sehr wenige Mglichkeiten, wie man sich dagegen vorbeugend schtzen kann. Am wichtigsten ist es, solche Angriffe
mglichst frhzeitig zu erkennen und dann gezielte Gegenmanahmen einzuleiten, die sehr von
der jeweiligen Form des Angriffs selbst abhngen.
12.2.4.2 TCP berlastkontrolle
Das TCP-Protokoll verfgt noch ber ein weiteres Merkmal, das es einem Angreifer ermglicht, TCP-Verbindungen zu stren, nmlich die Netzwerkberlastkontrolle [RFC 2581]. Dieser
Mechanismus dient dazu, die Bandbreite, also die gesendeten Daten pro Zeiteinheit, einer TCPVerbindung so anzupassen, dass das Netzwerk durch die TCP-Verbindung nicht berlastet wird.
Bei einer berlast liegen an einer Stelle im Netzwerk (beispielsweise einem Router oder einer
Verbindungsleitung) mehr Daten vor als verarbeitet oder transportiert werden knnen. Meistens
werden die entsprechenden Daten dann zunchst gepuffert, also im Speicher des Routers abgelegt, aber wenn die berlast bestehen bleibt, ist irgendwann auch diese Ressource vollstndig
verwendet und zu transportierende Daten gehen verloren.
TCP arbeitet bekanntlich Ende-zu-Ende, verfgt ber keine Kenntnisse ber die verwendete
Netzwerkinfrastruktur und fhrt diese Funktion selbstndig ohne Rckmeldungen der verwendeten Netzwerke aus. Ohne auf die Details des Mechanismus nher eingehen zu wollen, erhht
TCP in einem zweistugen Verfahren schrittweise die Bandbreite, um sich so an die verfgbare
Bandbreite im Netzwerk heranzutasten.
TCP erkennt berlastsituationen an verlorengegangenen Segmenten. Tritt eine solche Situation bei einer verwendeten Bandbreite auf, stellt TCP das Senden kurzzeitig ein und steigert
die Sendeleistung in exponentiellen Schritten bis zur Hlfte der vorher verwendeten Bandbreite
245
(Slow-Start-Phase). Danach wird die Bandbreite linear weiter erhht (Congestion-AvoidancePhase), bis wieder eine berlastsituation eintritt.
Der Hauptteil des Verkehrs im Internet ist derzeit TCP, und die Netzwerkberlastkontrolle
von TCP ist grundlegend fr die reibungslose Funktionsweise des Netzes, wie wir sie gewohnt
sind. Sie ist so entworfen, dass mehrere TCP-Verbindungen, die eine Ressource im Netzwerk
gemeinsam nutzen, sich die Ressouce fair teilen. Wrde jeder stur weitersenden, wenn es zu
Paketverlusten kme, knnte es im Internet zu ernsthaften Problemen kommen. Daher ist diese
Eigenschaft von TCP fr die Funktion des Internets sehr wichtig. Und doch ist die Netzwerkberlastkontrolle eine Achillesferse von TCP, an der sich ein Angreifer zu schaffen machen kann.
In drahtgebundenen Netzen treten im Normalbetrieb so gut wie keine Paketverluste durch andere Ursachen als berlastung auf. Daher interpretieren die meisten TCP-Implementierungen
(fast) jeden Verlust eines Segments letzlich als Resultat einer berlastung und fhren das oben
beschriebene Verfahren durch. Wenn der Verlust des Segments nicht auf eine berlastung zurckzufhren war, wird TCP sehr grob vereinfacht durch das Verfahren seine bertragungsgeschwindigkeit ungefhr halbieren und dann weiter linear erhhen. Wenn es einem Angreifer also
gelingt, ab und an ein TCP-Segment verschwinden zu lassen, so kann er die Bandbreite der TCPVerbindung signikant verringern. Kann ein Angreifer einen Router immer mal wieder, wenn
auch nur kurzzeitig, stark berlasten, kann bereits eine Unterbrechung der TCP-Verbindungen
die Folge sein.
Mischt man TCP-Verkehr und Informationssse, die keine Netzwerkberlastkontrollmechanismen haben (beispielsweise VoIP-Verkehr ber UDP), so wird sich im Falle einer berlastsituation die Bandbreite des gesendeten TCP-Verkehrs verringern. Bei den anderen Informationsssen werden aufgrund der berlastsituation ebenfalls Paketverluste auftreten. Hierauf muss
aber nicht unbedingt eine Reaktion erfolgen. Eine VoIP-Verbindung (mit konstanter Bitrate)
wird weiterhin die gleiche Bandbreite beanspruchen es sei denn einer der Gesprchsteilnehmer beendet entnervt die schlechte Verbindung aufgrund der Tatsache, dass er wegen der vielen
Paketverluste kein Wort mehr versteht.
Ein Angreifer kann also durch das Erzeugen einer berlast TCP-Verbindungen besonders beeintrchtigen.
12.2.4.3 Smurf-Angriff
Ein Beispiel, wie man einen Rechner oder Netzwerk durch schiere berlast lahmlegen kann,
ist der Smurf-Angriff. Dieser Angriff verwendet ICMP-Echo-Requests (siehe Abschnitt 7.3.3.3
und Abschnitt 11.3.2.1). ICMP-Echo-Requests knnen nicht nur an einzelne Rechner geschickt
werden, sondern auch an eine IP-Broadcast-Adresse. Wenn man dies in einem Netz hinreichender
Gre durchfhrt, erhlt man eine ganze Reihe von Responses. Wenn man hierbei wiederum eine
falsche IP-Quelladresse angegeben hat, kann man den Rechner mit dieser Adresse lahmlegen.
Als Manahme gegen diesen Angriff sollten Rechner so konguriert sein, dass sie, wenn
sie denn schon berhaupt auf ICMP-Echo-Requests antworten, zumindest solche an BroadcastAdressen ignorieren.
246
12 Verfgbarkeit
Verfgbarkeit ist ein wichtiges Ziel von IT-Sicherheit. Daten und Dienste sollen fr
legitime Benutzer tatschlich benutzbar sein. Fr kritische Dienste und Daten ist Verfgbarkeit ein entscheidendes Kriterium. Die Verfgbarkeit kann durch eine Reihe von
Faktoren beeinusst werden. Auch durch Angriffe kann die Verfgbarkeit von Systemen bis hin zu deren Ausfall beeintrchtigt werden. Solche sogenannten Denial-ofService-Angriffe sind hug einfacher durchzufhren und schwieriger zu verhindern
als das Kompromittieren des Systems. Sie knnen durch das gezielte Ausnutzen von
Schwachstellen oder aber auch durch schlichte berlastung hervorgerufen werden. Es
gibt nur wenige Mittel, sich wirksam gegen solche Angriffe zu schtzen.
12.4 bungsaufgaben
Aufgabe 12.1:
Erlutern Sie den Begriff Redundanz und erklren Sie, wie Redundanz mit Verfgbarkeit zusammenhngt.
Aufgabe 12.2:
Beschreiben Sie unterschiedliche Arten von Denial-of-Service-Angriffen und geben Sie jeweils
ein Beispiel.
Aufgabe 12.3:
Erlutern Sie, wie die Verwendung falscher IP-Absenderadressen fr Denial-of-Service-Angriffe
ausgenutzt werden kann.
Aufgabe 12.4:
Erklren Sie kurz TCP-Netzwerkberlastkontrolle und welche Mglichkeiten ein Angreifer hierdurch hat, die Verbindung zu stren.
Aufgabe 12.5:
Berechnen Sie die durchschnittliche tgliche Ausfallzeit eines Systems mit einer Verfgbarkeit
von 0, 9999.
Aufgabe 12.6:
Ein System muss jeden Monat wegen einer Wartung fr eine halbe Stunde abgeschaltet werden.
Berechnen Sie die Verfgbarkeit des Systems.
12.4 bungsaufgaben
247

Aufgabe 12.7:
Ein Webserver kann durchschnittlich 1.000 Anfragen pro Sekunde bearbeiten. Durchschnittlich
erreichen den Server 300 Anfragen pro Sekunde. Ein Angreifer startet einen Denial-of-ServiceAngriff, indem er pro Sekunde 30.000 Anfragen generiert. Der Server reagiert auf berlast,
indem er solche Anfragen ablehnt und gem seiner Kapazitt weiter Anfragen beantwortet.
1. Berechnen Sie die Wahrscheinlichkeit, dass eine Anfrage beantwortet wird.
2. Ermitteln Sie, wie oft ein Benutzer eine Anfrage in diesem Fall wiederholen muss, bis sie
mit einer Wahrscheinlichkeit von 0,9 beantwortet wird.
3. Berechnen Sie die durchschnittliche Anzahl von Wiederholungen einer Anfrage bis zu
ihrer Beantwortung.
Aufgabe 12.8:
Testen Sie die Auswirkung einer kurzzeitigen Unterbrechung einer TCP-Verbindung experimentell und vergleichen Sie Ihre Resultate mit UDP.
Kapitel 13
Netzwerkanwendungen
13
Netzwerkanwendungen
13.1 Email
13.1.1 Grundlegende Funktionsweise und Architektur von Email
Eine der ersten und heute noch wichtigsten Netzwerkanwendungen ist die elektronische Post,
allgemein bekannt unter dem Namen Email.
Analog zur regulren Post ermglicht Email die Befrderung einer Email-Nachricht von einem
Sender zu einem oder mehreren Empfngern. Email war ursprnglich nur fr das Versenden ausschlielich textbasierter Nachrichten konzipiert. Zustzlich zur eigentlichen Nachricht beinhaltet
die Email einen Email-Header [RFC 2822], der wichtige Zusatzinformationen wie beispielsweise Absender und Empfnger der Email beinhaltet.
Durch Erweiterungen besteht heute auch die Mglichkeit, Emails mit Anhngen (synonym
wird der Begriff Attachments verwendet) zu versehen. Dabei handelt es sich im Prinzip um Dateien beliebigen Typs, die von wenigen Byte kleinen html-Dokumenten bis hin zu mehreren
Megabyte groen Multimedia- oder Binrdateien reichen knnen.
Um Email verwenden zu knnen, muss ein Benutzer ber ein Email-Benutzerkonto auf einem
Email-Server verfgen. Die Email-Adresse, unter der dieser Benutzer dann erreichbar ist, hat in
der Regel die Form
, wobei
der Name des Benutzerkontos und
der Domainname des Email-Servers ist. Nachdem ein solches
Benutzerkonto angelegt wurde, kann der Benutzer Emails senden und empfangen. Hierzu verwendet der Benutzer auf seinem Rechner einen Email-User-Agent. Dies ist ein Programm, mit
dessen Hilfe Emails geschrieben, gesendet, empfangen und verwaltet werden knnen.
Wenn
eine Email fr
geschrieben hat
und absendet, laufen folgende einzelne Schritte ab, die in Abbildung 13.1 schematisch dargestellt
sind:
1. Der User-Agent des Senders
kontaktiert
, also den
Email-Server des Senders, und leitet die Email zur weiteren Befrderung dorthin.
2. Der Email-Server
erhlt dabei unter anderem Informationen (sie sind im
Header der Email gespeichert), aus denen der oder die Empfnger der Email hervorgehen, in unserem Beispiel also
.
kontaktiert
direkt und sendet die Email an diesen Server weiter. Der EmailServer des Empfngers, in unserem Fall
, nimmt die Email entgegen
250
Email-Server
des Senders
Empfnger
2. SMTP
1. SMTP
Internet
Sender
3. POP/IMAP
Email-Server
des Empfngers
Abbildung 13.1: Schematischer Ablauf der Befrderung von Email vom Sender zum Empfnger.
und stellt sie im Postfach des Empfngers

den Benutzer bereit.
, auch Inbox genannt, zur Abholung durch
3. Wenn
s Email-User-Agent aktiv ist, kontaktiert dieser regelmig den Email-Server

und fragt nach, ob neue Nachrichten fr
eingegangen sind,
die dann gegebenenfalls heruntergeladen und angezeigt werden.
In den Schritten 1. und 2. kommt als Protokoll das Simple Mail Transfer Protocol (SMTP)
[RFC 2821] zum Einsatz, whrend in Schritt 3. entweder das Post Ofce Protocol (POP) gem
[RFC 1939] oder das Internet Message Access Protocol (IMAP) [RFC 3501] Verwendung nden.
Historisch gesehen war SMTP lange das einzige Email-Protokoll, da im ursprnglichen Anwendungsszenario davon ausgegangen wurde, dass der User-Agent eines Email-Teilnehmers entweder direkt auf dem Email-Server selbst luft oder zumindest direkt auf das Dateisystem des
Email-Servers zugreifen kann, so dass die Verwendung eines weiteren Protokolls zur Abholung
der Emails ber das Netzwerk nicht notwendig war. Ein Email-Server muss stndig fr eingehende Verbindungsanfragen bereitstehen. Dies erfordert eine feste IP-Adresse und eine permanente
Anbindung an das Internet, denn sonst kann Schritt 2. nicht reibungslos ablaufen.
Auf Rechnern mit nicht-permanenten Dialup-Verbindungen und wechselnden IP-Adressen ist
der Betrieb eines Email-Servers somit unmglich. Da jedoch die Zahl solcher Rechner immer
mehr zunahm, wurden zustzliche Protokolle entwickelt, so dass User-Agents auch auf solchen
Rechnern problemlos betrieben werden konnten. Die Idee dahinter war denkbar einfach: Die
User-Agents auf einem anderen Rechner, etwa einem Arbeitsplatzrechner, holen die Emails mittels eines weiteren Protokolls (POP oder IMAP) ber das Netzwerk beim entsprechenden EmailServer des Teilnehmers ab, der weiterhin die Emails fr seine Benutzer entgegennimmt und
13.1 Email
251
User-Agent
Email-Server
USER markus
+OK
PASS geheim
+OK
Abbildung 13.2: Authentikation mit USER und PASS bei POP.
nun zustzlich auch auf entsprechende Anfragen der User-Agents wartet. Der User-Agent fungiert also als Client. Da POP derzeit weiter verbreitet ist als IMAP, werden wir uns bei den
folgenden Betrachtungen auf POP beschrnken.
13.1.2 SMTP und POP Eine kurze Darstellung aus

Sicherheitsperspektive
13.1.2.1 POP
Beginnen wir mit dem POP-Protokoll, das wie oben beschrieben vom User-Agent verwendet
wird, um Emails beim Email-Server abzuholen. Dabei konzentrieren wir uns auf die Sicherheitsaspekte.
POP verwendet TCP als Transportprotokoll (serverseitig Port 110) und verlangt direkt nach
Etablierung der Verbindung zunchst die Authentikation des Clients beim Server. Der UserAgent muss sich also gegenber dem Email-Server authentizieren. [RFC 1939] speziziert als
Authentikationsmglichkeit die Verwendung von USER und PASS wie in Abbildung 13.2 skizziert. Dieser Authentikationsmechanismus ist in Verbindung mit POP weit verbreitet.
Der Client sendet mittels des USER-Kommandos den Namen des Benutzerkontos, fr das die
Anmeldung erfolgen soll, an den Server. Im dargestellten Fall ist der Benutzername
.
Der Server quittiert dies entweder mit der Meldung
, oder mit einer Fehlermeldung
,
beispielsweise wenn das entsprechende Benutzerkonto nicht existiert. In unserem Fall ist dieser
erste Schritt erfolgreich verlaufen und der Client sendet nun das fr das Benutzerkonto vereinbarte Passwort an den Server. Hierzu verwendet der Client das PASS-Kommando zusammen mit
dem Passwort (hier
). Wiederum kann der Server entweder bei erfolgreicher Authenti-
252
kation mit der Meldung

reagieren, oder aber mit
bei der bermittlung eines falschen
Passworts. Wenn die Authentikation wie in unserem Beispiel erfolgreich war, ist ab diesem
Punkt der Zugriff auf die Mailbox freigegeben.
Bereits an dieser Stelle sind gravierende Mngel an dem bisher dargestellten Vorgehen von
POP ganz offensichtlich:
Die Kommunikation zwischen den Stationen ist nicht verschlsselt. Somit ist die Vertraulichkeit der Verbindung nicht gewhrleistet. Ein Angreifer kann die Kommunikation mithren und somit in den Besitz der bertragenen Nachrichten gelangen.
Benutzername und Passwort werden im Klartext ber das Netz bertragen. Ein Angreifer
kann also den Benutzernamen und das Passwort mitlesen, speichern und sich damit selbst
zuknftig beim Email-Server erfolgreich authentizieren. Damit ist es dem Angreifer mglich, zuknftig in den Besitz aller auf dem Email-Server ankommenden Nachrichten fr
den Benutzer zu gelangen.
Zusammenfassend sind die Sicherheitseigenschaften des POP-Protokolls damit als untauglich
zu bewerten. Die Verbindung erfolgt unverschlsselt, somit sind Vertraulichkeit und Integritt der
bertragenen Nachrichten nicht gewhrleistet. Der hier dargestellte vorgesehene Authentikationsmechanismus ist ebenfalls unzureichend, da der Benutzername und das Passwort im Klartext
bertragen werden.
Die einfachste Mglichkeit, die Schwachstellen des Protokolls zu beheben, besteht in der Verwendung einer verschlsselten Verbindung auf der Transportschicht, etwa durch Benutzung von
SSL oder TLS. Wir werden diese Mechanismen gleich in Abschnitt 13.3.3 etwas detaillierter
betrachten. Die meisten User-Agents und Email-Server untersttzen die Verwendung von SSL
oder TLS fr die POP-Verbindung oder erfordern sie mittlerweile sogar. Das Passwort wird dann
zwar weiterhin vom Client vollstndig an den Server bertragen, aber zumindest verschlsselt,
und bei Wahl einer ausreichenden Verschlsselung kann die Sicherheit des Verfahrens somit gewhrleistet werden.
Es gibt es auch andere Mglichkeiten, die bertragung des Passworts ber das Netz bei der
Authentikation zu vermeiden, beispielsweise durch die Verwendung eines Challenge-ResponseVerfahrens. In [RFC 1734] nden sich weitere Authentikationsmglichkeiten, die sowohl mit
POP als auch in Verbindung mit IMAP [RFC 1731] verwendbar sind. Wir knnen hier auf diese
Mechanismen nicht nher eingehen.
13.1.2.2 SMTP
Wenden wir uns nun dem SMTP-Protokoll zu. Es dient zwei Zwecken:
Dem Senden von Emails vom User-Agent des Benutzers zum Email-Server des Benutzers.
Dem Senden von Emails zwischen Email-Servern.
SMTP verwendet ebenfalls TCP als Transportprotokoll (serverseitig Port 25). Ursprnglich
waren in SMTP keinerlei Mechanismen fr Sicherheit, nicht einmal fr Authentikation vorgesehen. Die erste SMTP-Version (RFC 821) stammt von 1982. Damals war die Zahl der InternetNutzer berschaubar, und die Anzahl an Email-Servern war noch berschaubarer. Insofern stellte
13.1 Email
253
also das Fehlen von Sicherheitsmechanismen aus Sicht der Entwickler kein allzu groes Problem
dar.
Die fehlende Authentikation fhrte dazu, dass jeder eine Verbindung zu einem Email-Server
per SMTP aufbauen konnte, um damit Emails an andere zu versenden. Diese Konguration ist
unter dem Namen Open Mail Relay bekannt. Damit war es also auch ohne groen Aufwand
mglich, Emails mit geflschter oder falscher Absenderadresse zu verschicken. Somit war also
weder Vertraulichkeit noch Integritt noch Authentizitt der Nachrichten gewhrleistet.
Erst in den neunziger Jahren wurde gegen die Open Mail Relays etwas unternommen, allerdings nicht aus Sicherheitsgrnden im engeren Sinn, sondern wegen eines zunehmenden Phnomens, das uns allen auch heute leider noch unter dem Namen Spam nur zu gut bekannt ist.
Mit dem Begriff Spam bezeichnet man Email-Nachrichten, die meist zu Werbezwecken einer
groen Zahl von Empfngern unverlangt zugesandt werden. Spammer missbrauchten fr die Versendung ihrer Massenmails hug die Open Relays, so dass diese mittlerweile fast verschwunden
sind, oder aber mit technischen Mitteln zwecks Eindmmung der Spam-Flut an der Teilnahme
am regulren Email-Verkehr gehindert werden.
Das SMTP-Protokoll in seiner gegenwrtigen Form [RFC 2821] ermglicht sogenannte SMTPExtensions. [RFC 2554] speziziert eine solche Extension, um Authentikation von Clients bei
Servern zu ermglichen. Dieses Protokoll basiert auf der Simple Authentication and Security
Layer (SASL) [RFC 4422], einem erweiterbaren Protokoll-Framework zur Bereitstellung von
Sicherheitsdiensten, unter anderem auch Authentikation. Darber hinaus untersttzen viele
Email-Server mittlerweile auch fr SMTP die Verwendung einer verschlsselten Verbindung
auf der Transportschicht wie bereits fr POP beschrieben.
Trotzdem bleiben im Gesamtsystem Email gravierende Sicherheitslcken bestehen. Es ist fr
einen mittelmig versierten Benutzer auch heute noch kein Problem, beispielsweise eine Email
mit einer geflschten Absenderadresse zu generieren. Wir wollen auf Details der Protokolle zum
Austausch der Emails zwischen Servern und deren Schwachstellen hier nicht nher eingehen,
denn auch wenn viele Email-Server mittlerweile die Authentikation von Benutzern fordern, so
bleiben im Gesamtsystem zu viele Schwachstellen und Mglichkeiten, die Sicherheitsmechanismen zu umgehen oder auszuhebeln, als dass sich eine detailliertere Betrachtung lohnen wrde.
Die tgliche Spam-Flut in ihrer Email-Inbox ist hierfr eindrucksvolles Zeugnis.
13.1.3 Email als Ende-zu-Ende-Anwendung

13.1.3.1 Einfhrung
Das Fazit des vorangegangenen Abschnitts ist eigentlich vernichtend: Die Vertraulichkeit, Authentizitt und Integritt einer Email kann in keinem Fall als gegeben betrachtet werden.
Was schwerer wiegt: Ein Email-Benutzer selbst hat hierauf keinen Einuss, denn er hat nur die
Mglichkeit, zu kontrollieren, welche Sicherheitsdienste beim Abschicken seiner Emails erfolgen und welche Sicherheitsdienste er beim Empfangen seiner Email verwendet. Empfngt er die
Emails beispielsweise durch Verwendung von POP ber SSL, so kann er die Vertraulichkeit der
bertragung von seinem Email-Server auf den eigenen Rechner zwar als gegeben betrachten,
aber sie knnte bereits vorher kompromittiert worden sein, etwa weil der Absender der Email
diese per SMTP ohne Verschlsselung an seinen Email-Server verschickt hat, oder da die Email-
254
Email-Server
des Senders
Klartext
Chiffretext
Chiffretext
Empfnger
2. SMTP
1. SMTP
Chiffretext
Internet
3. POP/IMAP
Chiffretext
Klartext
Chiffretext
Chiffretext
Sender
Email-Server
des Empfngers
Abbildung 13.3: Absicherung von Email Ende-zu-Ende.
Server untereinander ohne Verschlsselung arbeiten. ber die Kommunikation hinaus stellt sich
eventuell auch die Frage nach der Sicherheit der Email-Server selbst, denn da die Verschlsselung ja jeweils nur auf den Teilstrecken erfolgt, liegen dort die Nachrichten auf jeden Fall im
Klartext vor.
Mit anderen Worten: Die Transportschichtmechanismen stellen derzeit kein akzeptables Sicherheitsniveau zur Verfgung. Um Vertraulichkeit, Authentizitt und Integritt von Email-Nachrichten wirklich sicherstellen zu knnen, ist es daher notwendig, die zu bertragenden Daten
auf der Applikationsschicht zu schtzen. Wir hatten uns in Abschnitt 8.3.1 schon abstrakt mit
der Absicherung von Kommunikation auf dieser Schicht auseinandergesetzt. Das entsprechende
Vorgehen bei Email ist in Abbildung 13.3 skizziert.
Der Sender der Email wendet vor dem Versenden der Email Verfahren an, um Authentizitt, Integritt und/oder Vertraulichkeit des Inhalts der Email sicherzustellen. Die so
verschlsselten oder signierten Daten (siehe Kapitel 2) werden dann per Email zum Empfnger verschickt.
Die so entstandene Email wird ganz normal durch das Netz befrdert.
Der Empfnger erhlt die Email und entnimmt ihr die enthaltenen Daten. Er entschlsselt
sie und/oder berprft deren Integritt und Authentizitt mittels der verwendeten kryptographischen Verfahren.
Werden Emails (oder andere Daten) auf diese Weise geschtzt, so ist die Sicherheit der Daten
von den zum Transport verwendeten Verfahren, hier von den potentiellen Gefahren des Versendens via Email, unabhngig.
Eine besonders einfache Methode des Einsatzes dieser Technik ist die quasi manuelle Verschlsselung der Daten beim Sender mittels eines anderen Anwendungsprogramms auerhalb
des Email-User-Agent. Die verschlsselten Daten werden dann als Anhang einer Email zum
13.1 Email
255
Empfnger verschickt. Nach Empfang speichert er den Anhang und entschlsselt die Daten
dann mittels des entsprechenden Anwendungsprogramms. Prinzipiell eignet sich hierzu jedes
Programm, das entsprechende Sicherheitsdienste implementiert. Natrlich hngt die Sicherheit
dieser Vorgehensweise in erster Linie von dem verwendeten Programm und den im Programm
verwendeten kryptographischen Algorithmen ab. Dies gilt ebenfalls fr die Frage, welche Arten von kryptograhischen Schlsseln Sender und Empfnger besitzen mssen und wie sie diese
austauschen.
Ein solcher Ansatz mag fr die sporadische Verschlsselung oder Authentikation von Emails
praktikabel sein, eignet sich aber keinesfalls fr einen regelmigen Einsatz. Hierfr ist eine
Verankerung eines Frontends zur einfachen Verwendung der Sicherheitsmechanismen im EmailUser-Agent sowohl senderseitig als auch empfngerseitig notwendig. Im Folgenden werden wir
einige Mglichkeiten kurz darstellen, die sich fr den kryptographischen Schutz von Email auf
Applikationsebene durchgesetzt haben und fr die es Plug-Ins gibt, so dass die Sicherheitsdienste
der Anwendungen direkt aus dem Email-User-Agent heraus betrieben werden knnen.
Die zwei gngigsten verwendeten Verfahren sind S/MIME und OpenPGP. Wir werden diese
Verfahren nun vorstellen.
13.1.3.2 S/MIME
S/MIME steht fr Secure MIME. Dieser Standard ist in [RFC 3850] bzw. [RFC 3851] beschrieben. Es verwendet, wie der Name schon sagt, MIME, die Multipurpose Internet Mail Extensions
[RFC 2045-2049]. Diese Extensions wurden deniert, da nach der ursprnglichen Spezikation Email-Nachrichten nur aus 7-Bit-ASCII-Zeichen bestehen durften, so dass die bertragung
von normalen aus je 8 Bit bestehenden Bytes, wie sie in Dateien, Bildern und anderen Objekten
vorkommen, nur nach vorheriger Umwandlung in 7-Bit-Zeichen mglich war. Diese Konversion
musste auerhalb des User-Agents mit einem separaten Programm erfolgen. Der Empfnger der
Email musste ebenfalls den Inhalt der Email zunchst speichern und dann konvertieren. Durch
MIME wurde es mglich, Bilder und beliebige Dateien einfach ber den User-Agent in Emails
zu integrieren. Bestimmte Formate (vor allem Bilder) werden heute direkt im User-Agent dargestellt. S/MIME ist ebenfalls in den User-Agents integriert, so dass die kryptographischen Funktionen und berprfungen direkt dort vor dem Versand oder nach dem Empfang vorgenommen
werden knnen.
S/MIME verwendet MIME zur Strukturierung der bertragenen Emails. Die kryptographischen Funktionen von S/MIME basieren auf der in [RFC 3852] beschriebenen Cryptographic
Message Syntax (CMS), die sich wiederum am PKCS #7-Format [RFC 2315] orientiert. Die
Sicherheitsfunktionen von S/MIME basieren auf der Verwendung von X.509-Zertikaten wie
in Abschnitt 3.6.3.2 skizziert. Somit muss ein Benutzer zum Empfangen kryptographisch geschtzter Emails und zum Signieren von Emails im Besitz eines Zertikats und des zugehrigen
privaten Schlssels sein. Darber hinaus muss der Absender einer kryptographisch geschtzten
Email das Zertikat des Empfngers haben. Wir hatten die praktische Verwendung von S/MIME
in Abschnitt 3.6.3.3 bereits betrachtet.
S/MIME erlaubt die Verwendung verschiedener kryptographischer Verfahren zur Verschlsselung und Signierung von Emails. Bei der Verschlsselung werden in der Regel hybride Verfahren
verwendet, wie wir sie in Abschnitt 2.3.4 kennengelernt haben.
256
Die Notwendigkeit, fr jeden Email-Benutzer, der S/MIME verwenden will, ein Zertikat
durch eine Certicate Authority erstellen zu lassen, stellt in der Praxis eine erhebliche Schwierigkeit dar, die bisher die weite Verbreitung von S/MIME behindert hat. Der Betrieb einer eigenen Certicate Authority, wie er sich fr grere Institutionen anbietet, ist mit erheblichem
nanziellen und administrativen Aufwand verbunden. Privatanwender mssten sich direkt bei
einer Certicate Authority ein Zertikat besorgen. Einige CAs bieten kostenlose Zertikate fr
Privatanwender, die aber hinsichtlich ihrer Funktionen meistens eingeschrnkt sind.
13.1.3.3 GPG
Eine weitere Mglichkeit zum kryptographischen Schutz von Emails ist die Verwendung von
OpenPGP [RFC 2440]. OpenPGP basiert auf Pretty Good Privacy, PGP. Eine Implementierung
von OpenPGP ist GNU Privacy Guard, GPG. OpenPGP basiert auf dem Konzept des Web of
Trust (siehe Abschnitt 3.6.3.4), es gibt also keine CAs und jeder Benutzer kann seinen privaten
Schlssel und sein Zertikat selbst erzeugen und dann von anderen Benutzern als vertrauenswrdig besttigen lassen. Damit ist OpenGPG gerade fr die Verwendung im privaten Bereich
hervorragend geeignet.
In der Praxis nden derzeit sowohl S/MIME als auch OpenGPG Verwendung. Leider sind
diese Methoden nicht zueinander kompatibel, was zu erheblichen Problemen fhren kann.
13.2 SSH
13.2.1 Einfhrung
Eine der grundlegendsten (und ltesten) Mglichkeiten, einen Rechner zu benutzen, ist die Verwendung eines Kommandozeileninterpreters, oftmals auch Terminal oder Shell genannt. Dabei
handelt es sich um ein Programm mit einem textzeilenbasierten Benutzerinterface.
Der Benutzer gibt ber die Shell Befehle ein, die diese einliest und ausfhrt. Meistens handelt
es sich bei den Befehlen um die Namen anderer Programme, die dann durch das Shellprogramm
auf dem System gestartet werden. Einige Kommandos (sogenannte Built-Ins) sind auch direkt
im Shell-Programm implementiert, etwa Befehle zum Anzeigen des Dateisystems. Shells sind
in den letzten Jahren im Desktopbereich etwas aus der Mode gekommen, werden aber fr die
Systemadministration und im Serverbereich noch hug eingesetzt.
Oft mchte ein Benutzer ber das Netzwerk auf einen entfernten Rechner zugreifen, beispielsweise vom Bro des Administrators auf den Server fnf Rume weiter, aber auch von zu Hause
aus auf den Arbeitsplatzrechner im Bro (oder umgekehrt). In der Anfangszeit des Internets gab
es eine ganze Reihe von Programmen, die den Shellzugriff auf einen entfernten Rechner ermglichten, beispielsweise
oder
. Doch diese Programme waren hinsichtlich ihrer Sicherheitseigenschaften katastrophal. Sie verwendeten keinerlei Verschlsselung und bertrugen
so unter anderem auch den zur Authentikation verwendeten Benutzernamen und das Passwort
im Klartext ber das Netz.
Daher wurde ein Programm entwickelt, das den sicheren Aufbau einer Shell auf einem entfernten Rechner ermglicht, nmlich die Secure Shell, SSH. Es wurde mittlerweile auf verschiedene
Betriebssysteme portiert.
13.2 SSH
257
SSH-Verbindung (logisch)
SSH-Server
Internet
SSH-Client
SSH Transport Protokoll
Abbildung 13.4: SSH-Architektur.
Die Architektur von SSH ist in [RFC 4251] speziziert und basiert auf dem Client/ServerPrinzip. Auf dem Rechner, von dem aus der entfernte Zugriff erfolgen soll, luft ein SSH-Client,
whrend der Rechner, auf den zugegriffen werden soll, einen SSH-Server betreibt. SSH besteht
aus drei verschiedenen Modulen, die aufeinander aufbauen:
Dem in [RFC 4253] spezizierten SSH-Transportprotokoll: Dieses Protokoll ermglicht
die Authentikation des Servers und stellt die Vertraulichkeit und Integritt der ber das
Protokoll bertragenen Daten sicher. Als Transportprotokoll verwendet dieses Protokoll
im Regelfall TCP (serverseitig Port 22), kann aber auch ber andere zuverlssige Transportprotokolle laufen.
Auf diesem Protokoll sitzt ein in [RFC 4252] speziziertes Protokoll zur Benutzerauthentikation, mittels dessen sich der User auf dem Client beim Server authentiziert.
Nach der Authentikation des Benutzers beim Server wird das in [RFC 4254] spezizierte
SSH-Verbindungsprotokoll eingesetzt. Dieses ermglicht die Auftrennung der durch das
SSH-Transportprotokoll bereitgestellten Transportverbindung in mehrere unabhngige logische Verbindungen.
Nach dem erfolgreichen Aufbau der SSH-Transportverbindung und der Benutzerauthentikation kann durch SSH eine logische Verbindung fr eine sogenannte interaktive Session, beispielsweise eine Shell erstellt werden, die dann den entfernten Zugriff auf den Server erlaubt.
Abbildung 13.4 zeigt die Architektur nochmals schematisch.
13.2.2 SSH Port Forwarding

Wie bereits erwhnt knnen ber eine SSH-Transportverbindung mehrere logische Verbindungen
abgewickelt werden. Ein aus Benutzersicht sehr angenehmes, aber aus der Sicherheitsperspektive
zumindest bedenkliches Feature ist hierbei das sogenannte SSH Port Forwarding.
258
Port Forwarding von A:x nach S:y
SSH-Server
B
B leitet weiter zu
S:y
Internet
Quelle D:z
Ziel A:x
SSH-Client
A
Quelle B:r Ziel S:y
Server S
D verbindet sich mit A:x
Rechner D
Abbildung 13.5: SSH Local Port Forwarding.
Abbildung 13.5 zeigt ein Beispiel, in welchem via (Local) Port Forwarding von TCP-Port x
auf Rechner A auf Port y auf Rechner S weitergeleitet wird. Genauer luft beim (Local) Port
Forwarding Folgendes ab:
Rechner A hat als Client eine SSH-Verbindung mit Rechner B (SSH-Server) aufgebaut.
Dabei wurde Port Forwarding von TCP-Port x auf Rechner A auf TCP-Port y von Rechner
S vereinbart.
Rechner A wartet auf TCP-Port x auf eingehende Verbindungen.
Rechner D ffnet eine entsprechende Verbindung nach A:x.
Aufgrund des Port Forwardings von A:x nach S:y informiert A Rechner B ber jede auf
A:x neu eingehende TCP-Verbindung und leitet die ber die TCP-Verbindung eingehenden
Daten umgehend ber die verschlsselte SSH-Verbindung an B weiter.
B wiederum baut fr jede neu eingehende TCP-Verbindung an Port A:x eine eigene TCPVerbindung von sich zu Rechner S, Port y auf und leitet die von A ber den SSH-Tunnel
erhaltenen Daten umgehend an S:y weiter.
Umgekehrt sendet B alle von S:y erhaltenen Daten via SSH an A, wo diese Daten dann
ebenfalls wieder weitergeleitet werden.
Damit haben wir also folgende Situation: D hat sich mit Rechner A, TCP-Port x verbunden,
kommuniziert aber in Wirklichkeit mit Rechner S, Port y. Rechner S wei von der zwischen A
und B bestehenden SSH-Verbindung nichts. Aus seiner Sicht kommuniziert er ausschlielich mit
Rechner B.
Neben der bisher dargestellten Variante des Local Port Forwarding gibt es noch das sogenannte Remote Port Forwarding. Die beiden Techniken sind hnlich. Der Unterschied besteht in der
Richtung des Port Forwarding: Beim oben dargestellten Local Port Forwarding wird von einem
13.2 SSH
259
Port Forwarding von B:x nach S:y
SSH-Server
B
D verbindet sich mit B:x
Internet
SSH-Client
A
Server S
Rechner D
A leitet weiter zu
S:y
Abbildung 13.6: SSH Remote Port Forwarding.
Port auf dem SSH-Client zum SSH-Server hin geforwarded, whrend beim Remote Port Forwarding von einem Port auf dem SSH-Server zum SSH-Client geforwarded wird. In gewissem
Sinn sind also, was das Forwarding angeht, die Rollen zwischen SSH-Client und SSH-Server
vertauscht. Remote Port Forwarding ist in Abbildung 13.6 dargestellt. SSH bietet neben diesen
bisher beschriebenen statischen Varianten des Port Fowarding auch noch dynamisches Port Forwarding. Im Prinzip luft das Forwarding wie oben beschrieben ab, jedoch ist das Ziel des Forwardings nicht statisch festgelegt, sondern kann dynamisch gewhlt werden. Die SSH-Maschine
fungiert also als Proxy. Hierbei kommt hug das SOCKS-Protokoll zum Einsatz [RFC 1928].
Es stellt sich die berechtigte Frage, wozu Port Forwarding (Local oder Remote) eigentlich
ntzlich ist. Schlielich knnte D ja auch direkt eine Verbindung nach S:y aufbauen. Doch es
gibt Situationen, in denen die oben dargestelle Funktion von Nutzen sein kann:
Ein direkter Zugriff von D auf S:y ist nicht mglich, beispielsweise
da Rechner S nur eingehende Verbindungen aus einem bestimmten Adressbereich
(Intranet) akzeptiert, zu dem B gehrt, D jedoch nicht, oder
da Rechner S hinter einer Firewall platziert ist, die eingehende Verbindungen nach
S:y nicht durchlsst, aber SSH-Verbindungen zu Rechner B, der sich hinter der Firewall bendet, mglich sind.
Ein direkter Zugriff von D auf S:y ist zwar mglich, aber unerwnscht. Durch die Verwendung des Port Forwardings ndet keine direkt beobachtbare Kommunikation zwischen D
und S, sondern nur zwischen D und A statt. Somit ist fr Dritte nicht unmittelbar ersichtlich, dass mit S kommuniziert wird.
13.2.3 Praktisches Beispiel: Zugriff auf einen Server durch eine Firewall
Fluch und Segen des Port Forwardings liegen nahe beieinander. Einerseits ist eine derartige Funktion fr Benutzer auerordentlich hilfreich, beispielsweise um eine lstige Firewall zu umgehen,
260
10.2.4.37
172.16.2.5 10.2.4.1
172.16.2.0/24
10.2.4.0/24
172.16.2.4
10.2.4.99
192.168.1.5
192.168.1.0/24
192.168.1.100
SSH-Verbindung zwischen
192.168.1.100 und 10.2.4.99
192.168.1.77
Abbildung 13.7: Referenznetzwerk fr den VPN-Test.
die zwar SSH erlaubt, aber den Zugriff auf den Email-Server von auen verbietet, andererseits
sehen die Systemadministratoren und Sicherheitsverantwortlichen mit Schrecken, wie ihre sorgsam kongurierte Firewall ausgehebelt wird, um Dienste, die sie (manchmal aus gutem Grund)
nicht zulassen wollten, eben doch zu verwenden.
Betrachten wir hierzu wiederum in unserem Referenznetzwerk ein praktisches Beispiel. Abbildung 13.7 zeigt den Aufbau unseres Experiments. Wir werden eine SSH-Verbindung zwischen
den Rechnern 192.168.1.100 und 10.2.4.99 etablieren und ber diese Verbindung Port Forwarding testen. Hierzu betreiben wir auf 10.2.4.37 unser Java-Programm, das auf Port 80 auf eingehende Anfragen wartet.
Zustzlich kongurieren wir den Paketlter auf 172.16.2.5 so, dass ausschlielich eingehende TCP-Verbindungsanfragen fr SSH (Port 22) zu Rechner 10.2.4.99 durchgelassen werden,
whrend alle anderen Verbindungsversuche verworfen werden. Dies ist beispielsweise mit den
Regeln (bei Default DENY)
mglich. Wir testen die Firewall, indem wir wie blich von Rechner 192.168.1.77 aus versuchen,
mit einem Browser auf 10.2.4.37 zuzugreifen. Dieser Zugriff wird durch die Firewall verhindert
und das Resultat ist ein Timeout, wie analog zum in Abschnitt 9.2.1.6 dargestellten Experiment ja auch zu erwarten war. Nun probieren wir aus, ob der Aufbau einer SSH-Verbindung
zu 10.2.4.99 mglich ist. Wir betreiben diese Verbindung von 192.168.1.100 aus. Auf der von
uns verwendeten Linux-Variante luft auf 10.2.4.99 automatisch ein SSH-Server, der auf eingehende Verbindungen wartet. Wir starten also von 192.168.1.100 einen Verbindungsversuch zu
10.2.4.99:
13.2 SSH
261
Die Anmeldung auf 10.2.4.99 erfolgt unter dem gleichen Benutzernamen, unter dem wir auch
auf 192.168.1.100 eingeloggt sind, also als
. Wir geben das entsprechende Passwort fr
auf 10.2.4.99 ein und haben bei erfolgreicher Authentikation jetzt eine Shell auf 10.2.4.99,
die wir von 192.168.1.100 aus bedienen. Die Verbindung funktioniert also. Wir schlieen die Verbindung wieder durch den Befehl
, der die Shell und damit auch SSH beendet. In unserem
Fall wird automatisch Public-Key-Kryptographie verwendet, um den Server zu authentizieren.
Da in unserem Fall zwischen den Rechnern vorher noch nie eine SSH-Verbindung aufgebaut wurde und der entsprechende Schlssel auch nicht anderweitig berprft werden kann, wird der Benutzer beim Verbindungsaufbau gefragt, ob er den ffentlichen Schlssel des Servers 10.2.4.99
akzeptieren mchte oder nicht.
Nun wollen wir uns dem Port Forwarding zuwenden. Wir mchten gerne ber den SSH-Tunnel
auf den von 10.2.4.37 auf Port 80 angebotenen Dienst zugreifen. Hierzu verwenden wir folgendes
SSH-Kommando auf 192.168.1.100:
Dieses Kommando besagt, dass ber lokales Port Forwarding auf dem lokalen Port 9999 unseres Rechners (also 192.168.1.100) eingehende Verbindungsanfragen entgegengenommen werden
und dann ber den SSH-Tunnel zunchst an unseren SSH-Partner 10.2.4.99 und von dort an Port
80 von 10.2.4.37 weitergeleitet werden sollen. Die Option besagt, dass unser Port 9999 Anfragen von beliebigen Rechnern (nicht nur lokale Anfragen von Prozessen auf dem Rechner selbst)
entgegennehmen soll. Wiederum mssen wir uns authentizieren. Die Bildschirmausgabe fr
dieses Kommando ist dem vorangegangenen sehr hnlich, allerdings ist nun das Port Forwarding
aktiviert.
Wir wollen dies nun ausprobieren. Von Rechner 192.168.1.77 aus verbinden wir uns ber den
Browser mit 192.168.1.100 Port 9999. Das Ergebnis ist in Abbildung 13.8 zu sehen: Wir haben
tatschlich Zugriff auf den auf Port 80 von Rechner 10.2.4.37 laufenden Service erhalten. Es ist
lohnenswert, sich die Antwort von 10.2.4.37 und die darin erhaltenen Informationen ber die Verbindung genauer anzuschauen. Aus Sicht des Servers wurde der Dienst nicht von 192.168.1.77
oder 192.168.1.100 aus aufgerufen, sondern durch den Rechner 10.2.4.99, also dem Endpunkt
des SSH-Tunnels. Die Existenz dieses Tunnels bleibt fr den Server somit vollstndig verborgen.
Von dem Paketlter 172.16.2.5 aus betrachtet ist von der erfolgten Verbindung zwischen
192.168.1.77 und 10.2.4.37 ebenfalls nichts zu sehen. Hier werden ausschlielich Pakete registriert, die zu der SSH-Verbindung zwischen 192.168.1.100 und 10.2.4.99 gehren. Die Pakete
sind verschlsselt, so dass keine Mglichkeit besteht, diese Pakete bei genauerer Inspektion auszultern. Damit ist durch den SSH-Tunnel die Firewall effektiv ausgehebelt worden.
262
Abbildung 13.8: Test des Port Forwarding von 192.168.1.77 aus.
Nun wollen wir noch dynamisches Port Forwarding ausprobieren. SSH arbeitet bei dynamischem Forwarding mit dem SOCKS-Protokoll. Wir starten auf 192.168.1.100 wiederum eine SSH-Verbindung zu 10.2.4.99, diesmal jedoch mit dynamischem Port Forwarding ber das
SOCKS-Protokoll. Dies geschieht mit dem Befehl
Der Rechner 192.168.1.100 nimmt dann auf Port 22999 SOCKS-Anfragen entgegen und leitet
sie zu 10.2.4.99 weiter, wo sie ausgefhrt werden. ber SOCKS knnen dann beliebige Ports
beliebiger anderer Rechner angesprochen werden, nicht mehr nur Port 80 von 10.2.4.37.
Wir wollen das dynamische Forwarding nun wieder von 192.168.1.77 aus mit dem Browser
testen. Hierzu mssen wir zunchst den Browser so einstellen, dass er Webseiten nicht direkt,
sondern ber den SOCKS-Proxy auf Port 22999 von 192.168.1.100 aufruft.
Abbildung 13.9 zeigt die Konguration des Browsers.
Nun wollen wir ber den Browser Port 80 auf 10.2.4.37 kontaktieren. Abbildung 13.10 zeigt
den Aufruf und das Resultat. Wie zu sehen ist, unterscheidet sich das Ergebnis nicht von dem im
vorangegangenen Experiment. Allerdings unterscheidet sich der Aufruf deutlich, denn diesmal
haben wir 10.2.4.37 direkt angesprochen. Der Aufruf wurde via SOCKS weitergeleitet und auf
10.2.4.99 umgesetzt. Anstelle von Port 80 auf 10.2.4.37 htten wir aber auch einen beliebigen
anderen Dienst kontaktieren knnen.
Wie ebenfalls deutlich wurde, erfordert die Verwendung von dynamischem Port Forwarding
eine Untersttzung des SOCKS-Protokolls durch die Anwendung, whrend statisches Port Forwarding ohne Anwendungsuntersttzung zum Einsatz kommen kann.
13.3 Das World Wide Web (WWW)

13.3.1 Einfhrung
Fr viele Benutzer ist das World Wide Web (WWW) die wichtigste Anwendung im Internet.
Das WWW ist ein weltumspannendes Netz von Objekten. Die meisten Objekte im WWW sind
Abbildung 13.9: Konguration des Browsers bei dynamischem Port Forwarding.
Abbildung 13.10: Test des dynamischen Port Forwarding von 192.168.1.77 aus.
263
264
HTTP-Request
HTTP-Response
Abbildung 13.11: HTTP-Request-Response-Sequenz.
Webseiten, also in der Dokumentenbeschreibungssprache HyperText Markup Language (html)

[W3C HTML] vorliegende Dokumente, die auch Bilder und andere Objekte enthalten knnen.
Eines der wichtigsten Merkmale ist die Mglichkeit, Hyperlinks (kurz Links) zu verwenden. Dabei handelt es sich um Verweise auf andere WWW-Objekte.
Technisch gesehen basiert die Realisierung des WWW auf dem Client/Server-Prinzip. Die
ber das WWW zugnglichen Objekte liegen auf einem Webserver. Die Benutzer verwenden als
User-Agent einen Webbrowser, der die Objekte von den Servern ldt und anzeigt. Jedes Objekt im
WWW wird durch die Angabe eines Uniform Resource Identiers (URI) [RFC 3986] eindeutig
identiziert. Die URI (frher auch Uniform Resource Locator, kurz URL, genannt) gibt unter
anderem auch den Domainnamen des Servers und das zu verwendende Zugriffsprotokoll an.
Das meistverwendete Protokoll beim Zugriff auf Objekte im WWW ist das Hypertext Transfer Protocol (HTTP) [RFC 2616]. Es verwendet TCP (serverseitig Port 80) als Transportprotokoll und folgt einem einfachen Request-Response-Schema wie in Abbildung 13.11 dargestellt.
Der Client sendet einen HTTP-Request an den Server, den dieser mit einem HTTP-Response beantwortet. Der Request speziziert eine HTTP-Methode sowie eine URI fr den Request. Zwei
Beispiele fr Methoden sind
GET: Fordert das in der URI spezizierte Objekt beim Server an.
POST: Wird verwendet, um Daten vom Client an den Server zu schicken.
Die Response besteht aus einem Statuscode, der angibt, ob der Request erfolgreich war, oder
falls nicht, Informationen enthlt, warum der Request nicht bearbeitet werden konnte. Hieran
schliet sich die bertragung angeforderter Objekte, beispielsweise einer Webseite.
Bei Webseiten wird zwischen statischen Webseiten und dynamischen Webseiten unterschieden. Statische Webseiten sind auf dem Server im Dateisystem fest abgelegt und werden bei einem GET-Request auf die URI der Seite unverndert im Response an den Client gesendet. Wird
die URI einer dynamischen Webseite aufgerufen, so erzeugt der Webserver die Seite erst nach
dem Aufruf der URI oder startet ein anderes Programm, das diese Aufgabe bernimmt. Einige
Technologien, mit denen dynamische Webseiten erzeugt werden knnen, sind
Java Server Pages,
Java Servlets,
PHP,
265
Active Server Pages (ASP) oder auch

Perl.
HTTP ist ein zustandsloses Protokoll. Dies bedeutet, dass die Response auf einen HTTPRequest ausschlielich von den im Request selbst enthaltenen Informationen abhngt, aber nicht
von vorangegangenen Requests. Es gibt viele Anwendungen, die mit einem zustandslosen Protokoll nicht betrieben werden knnen, so etwa ein Online-Shop, denn wenn Sie mehrere Artikel
nacheinander (also ber mehrere Request-Responses) in Ihren Warenkorb legen, so sollten hinterher alle Artikel dort auftauchen.
Daher ist eine Mglichkeit notwendig, mehrere HTTP-Request-Responses auf dem Server
miteinander in Beziehung setzen zu knnen und so zustandsbasiert auf Anfragen reagieren zu
knnen. Eine Mglichkeit, dies mit HTTP zu realisieren, sind sogenannte Cookies. Sie wurden
in [RFC 2965] speziziert und funktionieren relativ einfach. Ein Cookie ist eine relativ kurze
Zeichenkette. Bei einer HTTP-Response hat der Server die Mglichkeit, ein Cookie zu erzeugen und zum aufrufenden Client zu bertragen. Diesen Vorgang bezeichnet man als das Setzen
eines Cookies. Auf dem Client-Rechner speichert der User-Agent das Cookie zusammen mit
der Information, welcher Server das Cookie gesetzt hat, ab. Werden weitere Verbindungen zu
diesem Server aufgebaut, so bertrgt der Client-Rechner dieses Cookie (oder auch mehrere,
falls mehrere durch den Server gesetzt wurden) unverndert wieder zurck an den Server. Der
Server kann so anhand des Cookies den Client eindeutig identizieren und so Informationen
ber den Inhalt vorangegangener Request-Responses erhalten, etwa durch die Verwendung einer
Datenbank. Cookies knnen also dazu verwendet werden, einen Benutzer wiederzuerkennen
und so ein Benutzerprol anzulegen. Wir werden einige Risiken fr die Privatsphre, welche die
Verwendung von Cookies mit sich bringt, in Abschnitt 13.3.8 noch nher diskutieren. Werden
Cookies zur Benutzeridentikation o.. verwendet, so empehlt es sich aus Sicht des Betreibers
eines Servers natrlich, die Cookies durch kryptographische Methoden gegen Manipulationen
auf dem Client zu schtzen.
13.3.2 HTTPS
Das WWW und der browserbasierte Zugriff auf Informationen hat sich aufgrund seiner einfachen Einsetzbarkeit (clientseitig wird nur ein Browser, aber keine zustzliche Software bentigt)
mehr und mehr durchgesetzt. Mittlerweile werden immer mehr sicherheitskritische Prozesse ber
das WWW abgewickelt. Das Spektrum der Einsatzfelder reicht von einfachen Bestellungen und
Homebanking im privaten Bereich bis hin zu komplexen Portalen in Unternehmen, die vielfach
mehr oder weniger alle Informationen auch ber das WWW zugnglich machen.
Wie bereits erwhnt bietet das HTTP-Protokoll keinerlei Sicherheitsmechanismen und ist deshalb fr die bermittlung vertraulicher Daten nicht geeignet. Daher wird fr solche Zwecke
HTTP nicht direkt verwendet, sondern in Verbindung mit SSL/TLS. Die Verbindung dieser Protokolle ist unter dem Namen HTTPS bekannt und wurde in [RFC 2818] beschrieben. Im Gegensatz zu HTTP verwendet HTTPS standardmig TCP-Port 443.
Es ist einleuchtend, warum Vertraulichkeit, Authentikation und Integritt fr sicherheitskritische WWW-Anwendungen notwendig ist. Betrachten wir beispielsweise eine Internet-Bestellung:
266
Applikation
Applikation
verschlsselte Verbindung
TLS
TLS
TCP
TCP
IP
IP
Internet
Abbildung 13.12: Grundlegende Funktionsweise von SSL/TLS.
Vertraulichkeit: Wre die Vertraulichkeit der Datenbertragung nicht gesichert, so knnte

ein Angreifer in den Besitz der persnlichen Daten und der Kreditkarteninformationen des
Kunden gelangen und diese missbrauchen.
Authentikation: Der Kunde muss sicher sein, dass er tatschlich mit einem Server des
gewnschten Hndlers kommuniziert und nicht mit einem von einem Angreifer betriebenen Server, der sich auf diese Weise Kreditkarteninformationen zum spteren Missbrauch
beschaffen will. Umgekehrt sollte der Hndler auch den Kunden authentizieren knnen,
um Missbrauch und Betrug ausschlieen zu knnen.
Integritt: Ein Angreifer soll Menge und Art der bestellten Artikel keinesfalls verndern
knnen.
13.3.3 SSL und TLS

Das TLS-Protokoll wie in [RFC 4346] speziziert ist ein Protokoll zur Gewhrleistung vertraulicher, authentizierter und integrittsgeschtzter Ende-zu-Ende-Datenbertragungen. TLS steht
fr Transport Layer Security. Das TLS-Protokoll ist aus dem SSL-Protokoll (kurz fr Secure
Socket Layer) hervorgegangen. SSL und TLS sind sich bis auf Details sehr hnlich. Diese kleinen Unterschiede verhindern aber eine Kompatibilitt beider Protokolle. Gegenwrtig werden
sowohl SSL als auch TLS eingesetzt. Die Unterschiede zwischen SSL und TLS sind fr uns
nicht weiter von Bedeutung. Wir werden uns bei der Darstellung des Protokolls an TLS orientieren.
SSL/TLS ist ein Sicherheitsprotokoll auf der Transportschicht, das auf der Verwendung eines darunterliegenden zuverlssigen Ende-zu-Ende-Transportprotokolls, in der Regel TCP, basiert. Die grundlegende Funktionsweise von SSL/TLS ist in Abbildung 13.12 skizziert. SSL/TLS
nimmt Daten von der Anwendungsschicht entgegen, schtzt die Daten und leitet sie an die TCPSchicht weiter.
TLS selbst ist ebenfalls in mehrere Schichten untergliedert. Die Grundlage von TLS bildet das
TLS Record Protocol. Es sitzt direkt auf der TCP-Schicht. Das TLS Record Protocol bertrgt so-
HTTP
TLS
267
POP
Change Cipher
Spec Protocol
...
SMTP
Alert
Protocol
Handshake
Protocol
Applikationsschicht
Application
Data Protocol
Transportschicht
TLS Record Protocol

TCP
IP
Netzwerkschicht
Abbildung 13.13: Struktur von SSL/TLS.
genannte Records, die durch symmetrische kryptographische Verfahren verschlsselt werden und
einen kryptographischen Hash zur berprfung der Integritt des Records enthalten. Das TLS
Record Protocol wird von anderen Protokollen verwendet, um Nachrichten zu bertragen. Hierzu
wird diesen Protokollen ein eindeutiger Record Type zugewiesen. Jeder TLS-Record trgt einen
Header, der aus dem Typ des Records, der verwendeten TLS-Protokoll-Version und der Lnge
des Records besteht. Darauf folgt der verschlsselte und integrittsgeschtzte Record selbst.
Die TLS-Spezikation deniert vier Protokolle, die das TLS Record Protocol verwenden:
Change Cipher Spec Protocol (Record Type 20)
Alert Protocol (Record Type 21)
Handshake Protocol (Record Type 22)
Application Data Protocol (Record Type 23)
Die ersten drei Protokolle dienen zur Aushandlung der fr das TLS Record Protocol verwendeten kryptographischen Verfahren und notwendigen Schlssel sowie der Signalisierung von Fehlern. Die eigentlichen Daten werden dann ber das Application Data Protocol bertragen. Jedes
dieser Protokolle bergibt dem TLS Record Protocol die zu bermittelnde Nachricht. Das TLS
Record Protocol kann diese Nachricht fragmentieren, komprimieren und wie oben beschrieben
verschlsselt und integrittsgeschtzt bertragen. Durch die Schichtenstruktur knnen ber eine
TCP-Verbindung sowohl alle fr die TLS-Verbindung notwendigen Verhandlungen abgewickelt
und Kontrollinformationen ausgetauscht als auch die Daten bertragen werden. Die Struktur von
TLS ist in Abbildung 13.13 nochmals dargestellt.
TLS erlaubt die Verwendung vieler verschiedener kryptographischer Verfahren zur Verschlsselung und zur Integrittsberprfung. Diese werden zu Beginn der Session ber das Handshake
Protocol ausgehandelt. Da vor der Aushandlung natrlich weder die Verfahren noch die Schlssel feststehen, kann das TLS Record Protocol auch ohne Verschlsselung und Integrittskontrolle betrieben werden. Dies geschieht aber in der Regel nur zu Beginn einer Session, bevor mit
dem Handshake Protocol geeignete kryptographische Verfahren vereinbart und Schlssel ausgetauscht wurden.
268
Bei SSL/TLS wird im Handshake Protocol ebenfalls eine auf X.509-Zertikaten basierende
Authentikation durchgefhrt (siehe Abschnitt 3.6.3.2). Der Server muss sich beim Client authentizieren, whrend die Authentikation des Clients ber ein Zertikat zwar mglich, aber
nicht vorgeschrieben ist.
Meistens wird bei der Authentikation des Servers ber ein Zertikat wie folgt verfahren:
Legt der Server ein Zertikat vor, das von einer Certicate Authority unterschrieben ist, welcher
der Client vertraut (beispielsweise da sie in einer auf dem Client gespeicherten Liste vertrauenswrdiger CAs eingetragen ist), so wird das Zertikat akzeptiert. Ist das Zertikat von einer
Certicate Authority unterschrieben, welcher der Client nicht vertraut (beispielsweise weil die
CA in der Liste vertrauenswrdiger CAs nicht aufgefhrt ist), so wird meistens der Benutzer
der Anwendung alarmiert und gefragt, wie er verfahren mchte (Verbindung aufbauen oder Abbruch).
13.3.4 Client-Authentikation
Wir haben gerade dargestellt, wie TLS Vertraulichkeit, Authentikation und Integritt sicherstellen kann. Trotzdem bleiben hinsichtlich der Verwendung von HTTPS einige Sicherheitsrisiken
und es gibt kritische Punkte, auf die wir im Folgenden nher eingehen mchten. Die Risiken und
Besonderheiten betreffen die Authentikation von Client und Server, und zwar in beide Richtungen, also sowohl die Authentikation des Clients beim Server als auch die Authentikation des
Servers beim Client.
Beginnen wir mit der Authentikation des Clients beim Server. Wie bereits erlutert ist die
Authentikation des Benutzers gegenber dem Server, beispielsweise beim Online-Banking, unabdingbar. TLS ermglicht die Verwendung von Zertikaten zur Authentikation in beide Richtungen, jedoch ist diese Methode fr WWW-Anwendungen nicht unbedingt einsetzbar. Zum
einen sind nur wenige Benutzer im Besitz eines eigenen Zertikats, das von einer akzeptierten
Certicate Authority signiert ist. Zertikate, die Maschinen authentizieren, sind fr unser Zwecke nutzlos. Zudem sollte ein Online-Banking-Benutzer von jeder beliebigen Maschine aus in der
Lage sein, auf das Online-Banking zugreifen zu knnen. Daher erfolgt die Authentikation des
Benutzers auf der Clientseite typischerweise nicht ber die von TLS bereitgestellten Mechanismen, sondern durch einen im Webserver verankerten Login-Mechanismus nach Aufbau der TLSVerbindung. Die jeweils verwendeten Login-Mechanismen unterscheiden sich stark von Anwendung zu Anwendung und knnen von einfachen Benutzername/Passwort-Authentikationen bis
hin zu komplexeren Authentikationsmechanismen (Smart-Card, Token usw.) reichen.
Gerade bei Online-Hndlern ist der Grad zwischen der Sicherheit des Systems und seiner Benutzbarkeit schmal. Einerseits muss fr ausreichende Sicherheitsmechanismen gesorgt werden,
andererseits mchte man aber keine Kunden durch bertriebene Manahmen abschrecken oder
verlieren.
So ist es hug blich, dem Benutzer nach Eingabe eines falschen Passworts die Mglichkeit zu geben, das Passwort zurcksetzen zu lassen. Das neue Passwort wird dann an die fr
den Benutzer in den Kontaktdaten gespeicherte Email-Adresse bersandt unverschlsselt. Um
die Missbrauchsmglichkeiten zumindest teilweise einzuschrnken, empehlt es sich, vor dem
Rcksetzen des Passworts eine weitere Sicherheitsabfrage einzubauen, um den Missbrauch des
269
Abbildung 13.14: Anzeige eines Zertikats und der Liste der akzeptierten CAs.
Features durch Angreifer zu verhindern (siehe Sektion 12.2.1). Ein per Email bersandtes Passwort sollte beim ersten Login unbedingt gendert werden mssen.
Trotzdem muss das bersenden eines neuen Passworts an einen Benutzer per unverschlsselter
Email aus Sicherheitsperspektive als ausgesprochen riskant beurteilt werden. Aus diesem Grund
sind die Mglichkeiten nach einem erfolgreichen Benutzerlogin bei manchen Online-Hndlern
aus Sicherheitsgrnden limitiert. Beispielsweise muss bei jeder Bestellung die Zahlungsinformation nochmals neu angegeben werden, oder es muss zumindest bei einer ersten Bestellung an
eine neue Adresse die Information nochmals angegeben werden.
13.3.5 Server-Authentikation
Wenden wir uns nun der Authentikation des Servers beim Client zu. Bei der Authentikation
des Servers geht es primr darum, Angriffe zu verhindern, die darauf basieren, den Benutzer (wodurch auch immer) auf einen falschen Server unter der Kontrolle eines Angreifers zu locken,
ohne dass der Benutzer dies merkt.
So knnte auf dem falschen Server des Angreifers die Webprsenz einer Bank tuschend
echt nachempfunden sein. Der arglose Benutzer verwendet nun diesen Server anstatt des eigentlichen Servers und gibt dabei Username, Passwort, PINs, TANs etc. an. Diese missbraucht der
Angreifer dann dazu, das Konto des Benutzers bei der Bank zu plndern. Dies sollte natrlich
verhindert werden, deshalb ist die Authentikation des Servers der Bank dem Benutzer gegenber ausgesprochen wichtig.
Die Authentikation des Servers erfolgt bei TLS und damit bei HTTPS ber Zertikate, die
von entsprechenden CAs unterschrieben sind. Die gngigen Browser enthalten eine Liste von
vertrauenswrdigen CAs. Eine ganze Reihe von CAs sind in dieser Liste bereits vorinstalliert.
Der Browser berprft vorgelegte Zertikate. Falls ein von einem Server prsentiertes Zertikat
nicht durch eine vertrauenswrdige CA (also eine aus der Liste) signiert wurde oder andere
270
Flschung dieser
Anzeigen ist
mglich
zeigt HTTPSProtokoll an
zeigt verschlsselte
Verbindung an
Abbildung 13.15: Anzeige einer ber HTTPS bertragenen Webseite bei Firefox.
Mngel aufweist (Gltigkeitsdauer des Zertikats abgelaufen, Zertikat ist fr anderen DomainNamen ausgestellt ...), so meldet der Browser dies dem Benutzer, der dann selbst entscheiden
kann, ob er die Authentizitt des Webservers trotzdem als gegeben betrachtet oder nicht. Der
Benutzer kann sich das Zertikat des Webservers im Browser anzeigen lassen. Ebenso kann
auch die Liste der akzeptierten CAs angezeigt werden (siehe Abbildung 13.14).
Die meisten Browser signalisieren ber ihr User-Interface die Verwendung einer verschlsselten Verbindung, etwa durch ein geschlossenes Schloss (siehe Abbildung 13.15).
13.3.6 Phishing und Pharming

Aus rein technischer Sicht ist das Problem der Server-Authentikation mit den vorstehend genannten Methoden ausreichend gelst. Doch es gibt eine ganze Reihe mglicher Angriffspunkte
auf dieses Schema:
Flschen der Statusanzeigen und der Statusleiste im Browser: Gelingt es einem Angreifer,
die Statusanzeigen des Browsers zu manipulieren und so dem Benutzer den Besuch einer
anderen als der tatschlichen Webprsenz vorzugaukeln, greifen die Sicherheitsmechanismen nicht.
Verwenden einer nicht-verschlsselten Verbindung: Die beschriebene Authentikation greift
fr HTTPS, aber nicht fr HTTP. Es ist fr einen unerfahrenen Benutzer nicht leicht zu erkennen, ob die Verbindung verschlsselt und der Server authentiziert ist oder nicht. Selbst
ein erfahrener Benutzer achtet manchmal nicht darauf, da die Anzeige fr die Verschlsselung in vielen Browsern (vorsichtig formuliert) nicht unbedingt ins Auge springt.
Verwendung eines falschen Zertikats: Der Angreifer kann ein geflschtes Zertikat verwenden, beispielsweise eines ohne Unterschrift einer CA. Der Benutzer wird dann meist
gefragt, ob er dieses Zertikat akzeptieren mchte. Ein unkundiger Benutzer kann mit der
entsprechenden Entscheidung eventuell ebenfalls berfordert sein und setzt seine Transaktion fort.
271
Irgendeinebank
Link zu
http://www.irgendeinebank.de.aberinwirklichkeitgehteszu.irgendeinembetrueger.irgendwo.auf-irgendeinemserver.com/
Abbildung 13.16: Phishing-Email.
Diese Angriffe basieren nicht ausschlielich auf technischen Schwachstellen im engeren Sinn,
sondern immer auch auf Benutzerfehlern. Das gezielte Ausnutzen solcher Fehler wird auch als
Social Engineering bezeichnet. Auch wenn die Fehler letztlich der Benutzer macht, bleibt die
Beseitigung mglicher Bedienfehler in der Software eine Aufgabe der Softwareentwickler und
Softwaredesigner, die bei der Entwicklung des User-Interfaces mgliche Bedienfehler antizipieren und negative Folgen einer Fehlbedienung mglichst minimieren sollten.
Zentraler Punkt der Angriffe bleibt es, den Benutzer unbemerkt zur Verwendung eines Servers
des Angreifers zu bewegen. Dies kann auf technischem Weg erfolgen, oder auch ber Social
Engineering. Fr jede dieser Mglichkeiten werden wir nun ein Beispiel betrachten.
Eine ebenso dreistes wie erfolgreiches Beispiel fr Social Engineering ist Phishing. Beim
Phishing sendet der Angreifer eine (Spam-)Email an eine groe Zahl von Benutzern. Die Email
ist tuschend echt (manchmal mehr, manchmal weniger) einer echten Email einer Bank, eines
Auktionshauses oder eines Online-Hndlers nachempfunden und gibt vor, man msse sich aus
Sicherheitsgrnden mglichst schnell dort einloggen, um eine kritische Sicherheitsberprfung
durchzufhren. Eine (echte) Phishing-Email ist in Abbildung 13.16 gezeigt. In der Email ist ein
Link enthalten, der so aussieht, als wrde man tatschlich auf den Server der Bank, des Auktionshauses oder Hndlers gelangen. Beim Anklicken dieses Links gelangt man jedoch auf einen
Server des Angreifers mit einer geflschten Webprsenz. Oft hat dieser Server einen Domainnamen, der dem der echten Institution nachempfunden ist. Gibt der arglose Benutzer dort Benutzernamen und Passwort ein, so werden diese Daten umgehend an den Angreifer weitergeleitet,
der sie dann missbraucht.
Phishing ist in den letzten Jahren zu einem ernstzunehmenden Problem geworden, weshalb
mittlerweile Manahmen ergriffen wurden, Phishing mit technischen Mitteln zu unterbinden
oder zumindest schwieriger zu machen. Hierzu werden mehrere Anstze verfolgt:
272
Die Email-User-Agents berprfen eingehende Emails auf mgliche Phishing-Versuche

und informieren den Benutzer entsprechend. Ein Anfangsverdacht ergibt sich beispielsweise bei einer Diskrepanz zwischen der fr ein Link dargestellten Adresse im Text und
dem tatschlichen Ziel des Links.
Die Browser berprfen vor dem Aufruf einer Adresse im Web, ob es sich bei dieser
Adresse um eine bekannte Phishing-Seite handelt, und warnen den Benutzer beim Aufruf entsprechend. Fr die Implementierung dieses Features gibt es verschiedene Varianten,
beispielsweise das tgliche Herunterladen einer Liste bekannter Phishing-Sites durch den
Browser oder aber das aktive Kontaktieren eines Servers mit entsprechenden Informationen vor dem Aufruf der Site. Letzteres Feature wird kontrovers diskutiert, da es die Mglichkeit bietet, ein Prol des Benutzers anzulegen und die durch den Benutzer besuchten
Webseiten abzuspeichern und diese Informationen anderweitig zu verwenden.
Durch technische Manipulationen am DNS-System ist es mglich, dass ein richtiger Domainname in eine falsche IP-Adresse aufgelst wird. Diese Art des Angriffs wird als Pharming bezeichnet. Wir hatten bereits in Abschnitt 8.2.6 dargestellt, wie ein solcher Angriff ablaufen kann.
13.3.7 Weitere Bedrohungen der Sicherheit durch das WWW

13.3.7.1 Client
Rechner, die als Client das WWW benutzen, sind vielfltigen Bedrohungen und Risiken ausgesetzt:
Fehler bei der Anzeige von Objekten im Browser: Beim Anzeigen der von einem Server
abgerufenen Objekte kann es zu Fehlern kommen, etwa aufgrund einer fehlerhaften Implementierung oder Spezikation. Schwere Fehler knnen den Browser zum Absturz bringen
oder gezielt dazu missbraucht werden, den Client-Rechner unter Kontrolle zu bringen und
so beispielsweise Malware oder Spyware zu installieren.
Aktive Inhalte und Download von Programmen: Das WWW und das HTTP-Protokoll knnen nicht nur zum Webbrowsing verwendet werden, sondern auch zum direkten Herunterladen von aktiven Inhalten oder Programmen. Auf diese Weise kann ebenfalls Malware
auf einen Rechner gelangen (siehe Abschnitt 5.4.2).
Wir haben uns in den Kapiteln 5 und 6 bereits ausfhrlich mit den Problemen beschftigt, die
auftreten knnen, wenn Malware auf einen Rechner gelangt. Es spielt dabei keine Rolle, ob die
Malware vom Internet aus auf den Rechner heruntergeladen wird, von einem USB-Stick kopiert
wird oder sonstwie auf die Maschine gelangt. Die notwendigen Manahmen zum Absichern von
Rechnern gegen Malware und mglicherweise unerwnschte Anwendungen wurden bereits in
den Kapiteln 5 und 6 besprochen.
Wir wollen uns an dieser Stelle noch kurz mit der Sicherheit von Browsern befassen. Die
derzeit fhrenden Browser sind der Microsoft Internet Explorer [MS-Web] sowie der Mozilla
Firefox [Moz-Web]. Beide Browser sind hinsichtlich ihrer Sicherheits-Merkmale von Release zu
Release kontinuierlich verbessert worden und bieten mittlerweile, bei aller berechtigter Kritik,
273
einen guten Sicherheitsstandard. Dennoch ist damit zu rechnen, dass auch in Zukunft noch gravierende Sicherheitslcken in beiden Systemen entdeckt werden, die von Angreifern missbraucht
werden knnten.
Leider gibt es kein allgemeingltiges Rezept, wie man sich als Benutzer vor diesen Bedrohungen schtzen kann, jedoch gibt es einige Vorsichtsmanahmen, die getroffen werden knnen.
Als Erstes sollte man bei unbekannten Webseiten generell vorsichtig sein, speziell wenn diese
Seite Plug-Ins oder aktive Inhalte verwenden mchten. Selbst bei bekannten Webseiten ist ein
gewisses Misstrauen angebracht (siehe 5.4.2).
Fr einige Browser existieren spezielle Browsererweiterungen mit Sicherheitsfunktionen, die
beispielsweise bestimmte Funktionen fr unbekannte Webseiten blockieren oder zustzliche Sicherheitsprfungen durchfhren. Der Einsatz solcher Erweiterungen ist oft sinnvoll.
13.3.7.2 Server
Wie wir bereits aus Kapitel 9 wissen, sind Server, auf die aus dem Internet heraus zugegriffen
werden kann, Angriffen gegenber besonders exponiert. Dies trifft insbesondere auf Webserver
zu. Details und Ziele eines Angriffs knnen ganz unterschiedlich sein, beispielsweise
die Beeintrchtigung der Verfgbarkeit des Servers,
die Installation von Malware auf dem Server zur Durchfhrung weiterer Angriffe oder
das Ausspionieren vertraulicher Informationen auf der Maschine.
Auf dem Webserver luft wie blich ein Betriebssystem, auf dem die eigentliche WebserverSoftware aufsetzt. Es gibt verschiedene Webserver-Software, die auf unterschiedlichen Betriebssystemen aufsetzen. Zwei der gebruchlichsten Webserver sind Apache [Apa-Web] und die Internet Information Services (IIS) von Microsoft [MS-Web]. Zu den Webservern im weiteren Sinn
knnen auch Java Enterprise Edition Application Server (JEE Application Server) [Java-Web]
gezhlt werden, die speziell fr die Erzeugung dynamischer Webseiten geeignet sind, aber in ihrer Funktionalitt weit ber die fr einen Webserver im engeren Sinne notwendigen Funktionen
hinausgehen.
Die Architektur eines Webservers ist in Abbildung 13.17 grob skizziert. Neben den bereits
angesprochenen Komponenten kann ein Webserver selbst auch Code ausfhren, der dynamische
Webseiten erzeugt, oder externe Prozesse starten, die dynamische Webseiten erzeugen. Alle in
der Abbildung gezeigten Komponenten knnen Schwachstellen aufweisen, die ein Angreifer
ausnutzen kann, ebenso die Anbindung des Servers an das Internet.
Schwachstellen im Betriebssystem: Wenn das Betriebssystem des Servers Schwachstellen beinhaltet, so stellt dies ein signikantes Sicherheitsrisiko dar. Diese Problematik und
mgliche Anstze zur Verringerung des Risikos wurden in Sektion 4.6 bereits dargestellt.
Software- oder Kongurationsfehler der eigentlichen Serversoftware: Ist der Webserver
selbst falsch konguriert oder beinhaltet er einen Softwarefehler, kann ein Angreifer dies
ebenfalls ausnutzen.
274
Code zur
Erstellung
dynamischer
Inhalte
Webserver
Weitere Prozesse zur

Erzeugung dynamischer
Inhalte
Betriebssystem
Abbildung 13.17: Schematische Darstellung eines Webservers.
Software- oder Kongurationsfehler von Code zur Erstellung dynamischer Webinhalte:

Werden Webinhalte dynamisch erzeugt, so luft entweder im Webserver selbst (wie beispielsweise bei JEE Application Servern) oder in anderen Prozessen auf dem Rechner
weiterer Code, der ebenfalls Fehler enthalten oder falsch konguriert sein kann.
Schwachstellen bei der Anbindung an das Internet: Ein Angriff auf die Verfgbarkeit eines
Servers (Denial-of-Service) muss nicht gegen die Maschine selbst gerichtet sein. Auch die
Anbindung an das Internet kann gestrt werden, beispielsweise durch gezielte berlastung
eines Routers oder einer Verbindungsleitung. Diese Problematik wurde bereits in Kapitel
12 besprochen.
13.3.8 Anonymitt, Privatsphre und das WWW

Abschlieend wollen wir noch kurz das Thema Privatsphre im Internet ansprechen. Dieses Thema betrifft zwar nicht unmittelbar die drei Bereiche Vertraulichkeit, Authentikation und Integritt, die uns bisher hauptschlich beschftigt haben, gehrt aber trotzdem zum Bereich Sicherheit.
Seitens einiger Medien wird manchmal der Eindruck erweckt, das Internet sei eine Art rechtsfreier Raum, ein Tummelplatz von Radikalen, Terroristen, Perversen und Kriminellen jeder
Coleur, die aufgrund der Anonymitt des Mediums durch Strafverfolgungsbehrden nahezu unbehelligt ihrem verwerichen Tun nachgehen knnen.
Aus der Sicht eines Benutzers des WWW oder des Internets, der sich mit den technischen
Hintergrnden nicht ausgiebig befasst hat, mag tatschlich die Illusion entstehen, man knne
sich aus dem Schutz der huslichen, gewohnten Umgebung heraus im Netz bewegen, ohne dabei beobachtet werden zu knnen. Doch dieser Eindruck ist vollkommen falsch und entspricht
in keinster Weise der Realitt. Ein Benutzer des Internet hinterlsst bei seinem Besuch im Netz
an allen Ecken und Enden Spuren, die sich in vielen Fllen nicht nur eindeutig einem Benutzer zuordnen lassen, sondern auch zumindest seitens staatlicher Ermittlungsbehrden eine
eindeutige Identizierung des Benutzers ermglichen.
275
Im Weiteren werden wir diese gesellschaftlichen Aspekte auer Acht lassen und uns ausschlielich auf technische Fragestellungen konzentrieren.
Es gibt eine ganze Reihe von Mglichkeiten, wie und an welcher Stelle des Netzes ein bestimmter Benutzer im Internet identiziert werden kann. Unter dem Begriff identizieren verstehen wir im Folgenden nicht unbedingt die Authentikation eines Benutzers. Es reicht, wenn
vorangegangene Zugriffe und dabei gesammelte Informationen dem Benutzer zugeordnet werden knnen, ohne dass man die tatschliche Identitt des Nutzers unbedingt kennen muss. Auf
dem Webserver, der aufgerufen wird, gibt es mehrere Mglichkeiten, einen Benutzer zu identizieren:
Verwendung von Loginmechanismen auf dem Webserver: Auf einer zunehmenden Anzahl
von Webseiten besitzen die Nutzer nur noch dann Zugriff auf die Inhalte der Seite, wenn
sie sich auf der Website registrieren. Bei der Registrierung werden neben der Festlegung
eines Benutzernamens und eines Passworts auch variierende andere Angaben durch den
Benutzer verlangt, so in der Regel Name, Vorname und eine Email-Adresse. Die anzugebenden Daten unterscheiden sich von Webseite zu Webseite. Bei jedem Zugriff auf die
Seite muss sich der Benutzer dann entsprechend einloggen, worber er identiziert werden
kann.
Verwendung von Cookies: Durch Verwendung von Cookies knnen, wie bereits in 13.3.1
beschrieben, Benutzer identiziert werden. Cookies knnen auch in Verbindung mit Benutzername und Passwort verwendet werden. Hat sich ein Benutzer erfolgreich authentiziert, wird auf seinem Rechner ein Cookie abgelegt, das bei der nchsten Session automatisch an den Server bertragen wird und dort als Authentikation des Benutzers gewertet
wird.
Cookies sind nicht nur auf die Mglichkeit beschrnkt, das Benutzerverhalten auf einer Webseite zu beobachten. Durch sogenannte Third-Party-Cookies ist es mglich, das Verhalten des
Benutzers auch ber mehrere Webprsenzen hinweg zu beobachten. Wie dies geschieht, ist in
Abbildung 13.18 skizziert. Zwei verschiedene Webprsenzen A und B arbeiten mit einer Organisation zusammen, die einen Server speziell zur Beobachtung (und Datensammlung) von Benutzern unterhlt. Der Server verwendet hierfr Cookies. Die Webseiten von A und B enthalten
Referenzen auf Objekte, die nicht auf den Servern A oder B liegen, sondern auf S. Bei einem solchen Objekt kann es sich beispielsweise um eine Werbegrak handeln oder auch etwas, das auf
der Webseite fr den Benutzer nicht sichtbar ist. Der User-Agent des Clients ldt diese Objekte
beim Aufbau der Seite automatisch von S nach und schickt dabei Cookies mit, die S bereits auf
dem Client gesetzt hatte. S wei entweder anhand der verwendeten Referenz oder anderweitig,
dass der Client gerade die Webseiten von A besucht und speichert diese Information ab. So kann
im Lauf der Zeit ein aussagekrftiges Benutzerprol zustande kommen.
Aufgrund der oben skizzierten Mglichkeiten gibt es einige Bedenken gegen den Einsatz von
Cookies. Die WWW-User-Agents erlauben heute eine gezielte Verwaltung der von Servern auf
dem Client platzierten Cookies. Die Benutzer haben die Mglichkeit, durch regelmige Lschung oder gezielte Nichtannahme von Cookies ihre Privatsphre zu schtzen. Wir wollen die
Problematik der Cookies an dieser Stelle nicht weiter vertiefen.
276
Seite auf A enthlt Referenz auf S
Website A
Website B
Internet
Seite auf B enthlt
Referenz auf S
Wenn Seiten von A oder B heruntergeladen

werden, folgt der Client der Referenz zu S
und verbindet sich mit S. Dabei wird das Cookie
an S geschickt.
Third-Party-Server S
setzt websitebergreifende
Cookies
Abbildung 13.18: Third-Party-Cookies.
Die Frage, welche Webseiten Sie (regelmig) besuchen, ist natrlich nicht nur fr die Betreiber der Seiten interessant, sondern auch fr viele andere Personen und Institutionen. Das
Spektrum der Interessierten reicht vom Arbeitgeber, der das Aufrufen nichtdienstlicher Webseiten am Arbeitsplatz kontrollieren oder verhindern mchte, ber die Werbebranche, die hierdurch
interessante Benutzerprole erstellen und dann verwenden kann, bis hin zu Strafverfolgungsbehrden.
Die Mglichkeiten eines Missbrauchs solcher Daten sind durchaus gegeben. Eine gezielte
Recherche ber eine bestimmte Krankheit, der Aufruf einer Online-Jobbrse oder hnliches
kann in Verbindung mit weiteren Indizien durchaus Einblicke in die persnliche Situation eines
Menschen erlauben.
Selbst wenn Cookies abgeschaltet werden, so hinterlsst die Benutzung des Internets, und
speziell des WWW, Datenspuren, die Dritten wertvolle Informationen liefern knnen. Wir hatten
die Mglichkeit, die Kommunikationspartner anhand der IP-Quell- und/oder IP-Zieladressen zu
erkennen, bereits in Kapitel 8.1.6 detailliert beschrieben.
Techniken zur Gewhrleistung der Vertraulichkeit durch Verschlsselung der Kommunikation zwischen Client und Weberver, etwa die Verwendung von HTTPS, greifen leider zu kurz,
um diese Bedrohungen zu eliminieren, denn sie verschlsseln zwar die bertragenen Daten, jedoch bleibt das Ziel der Kommunikation dabei weiterhin in den entsprechenden IP-Headerfeldern
sichtbar, und oftmals reicht es bereits aus zu wissen, von welchem Server Daten aufgerufen wurden, um Rckschlsse auf die Inhalte der Webseiten ziehen zu knnen. Dies gilt speziell, wenn
man anhand des Domainnamens des Servers den Inhalt der Webseiten auf dem Server erkennen
kann.
Hug (aber nicht immer) lsst sich die IP-Adresse eindeutig einem Benutzer oder zumindest
Benutzerkreis zuordnen. Bei DSL-Zugngen ist dies etwa der Fall. Auch wenn die verschiedenen
IP-Adressen dynamisch vergeben werden, also nicht jeder Benutzer immer die gleiche Adresse
277
bezieht, so sind die Service Provider trotzdem in der Lage, rckwirkend festzustellen, welcher
Ihrer Kunden zu einem Zeitpunkt eine bestimmte IP-Adresse verwendet hat. Die Frage, inwieweit die Service Provider diese Informationen speichern mssen und zur Weitergabe an Dritte
verpichtet sind, beispielsweise zwecks einer Zivilklage wegen Copyrightverletzungen etc., unterscheidet sich von Land zu Land und ist Gegenstand kontroverser Diskussionen.
Zur Anonymisierung des Webverkehrs gibt es verschiedene Anstze. Bei einigen Technologien ist eine zumindest gewisse Anonymisierung ein angenehmer Nebeneffekt. Dies gilt beispielsweise fr die in Sektion 9.2.2 vorgestellten HTTP-Proxy-Server. Verwenden alle Benutzer im
Intranet einer Institution einen HTTP-Proxy-Server, so werden alle HTTP-Anfragen aus diesem
Intranet heraus ber den Proxy-Server abgewickelt, so dass von auen betrachtet alle Anfragen
aus diesem Netz vom Proxy-Server gettigt werden. Das klingt vielleicht nicht nach viel, aber
wenn die Webseite einer Konkurrenzrma besucht wird, wre es fr diese Firma vielleicht nicht
uninteressant, genauer zu erfahren, wer sich ihre Seiten betrachtet hat.
Doch das prinzipielle Problem ist hierdurch nicht gelst, und von einer echten Anonymisierung kann in diesem Fall nicht gesprochen werden. Das sieht schon etwas besser aus, wenn statt
eines Proxies im eigenen Netzwerk ein HTTP-Proxy in einem anderen Netzwerk verwendet wird.
In diesem Fall stammen die Anfragen aus Sicht des kontaktierten Servers aus diesem Netz, nicht
aus dem des eigentlich anfragenden Client. Da Anfragen vom Client an den Proxy normalerweise
nicht verschlsselt werden, bleiben schwerwiegende Risiken bestehen.
Eine Stufe weiter ist die Verwendung sogenannter Anonymisierdienste wie in Abbildung 13.19
skizziert. In seiner einfachsten Ausprgung besteht der Anonymisierdienst aus einem im Internet
erreichbaren Server. Wenn der Client eine anonymisierte Verbindung wnscht, so wird zwischen
dem Client und dem Anonymisierdienst eine verschlsselte Verbindung aufgebaut. Anfragen
des Clients werden zum Anonymisierdienst getunnelt und von dort an die eigentlichen Ziele
weitergeleitet. Die eigentliche IP-Adresse des Clients wird nur zwischen dem Client und dem
Anonymisierdienst verwendet. Die Kommunikation mit anderen Maschinen wird unter der IP des
Anonymisierdienstes abgewickelt. Die dabei verwendeten Technologien sind unterschiedlich,
unter anderem ist die Verwendung von SSH Port Forwarding (siehe Sektion 13.2.2) oder VPNTechnologien (siehe Kapitel 10) mglich.
Solche einfachen Anonymisierdienste sind sicher unter der Annahme, dass ihre Betreiber die
Benutzerdaten tatschlich geheimhalten und nicht offenlegen. Doch diese Annahme ist nicht
unumstritten. Letztlich verlagert sich durch solche Dienste das Problem der Vertrauenswrdigkeit
nur vom Service Provider zum Anonymisierdienst, wird aber nicht prinzipiell gelst.
Eine Mglichkeit, dieses Problem zu umgehen, besteht in der Anonymisierung durch die Verwendung mehrerer kaskadierter Rechner, ber welche die Verbindungen nacheinander geleitet
werden. Wenn diese Kaskaden hug gewechselt werden und die Rechner in verschiedenen
Lndern stehen und von verschiedenen Betreibern administriert werden, macht dies eine Aufdeckung der Anonymitt zumindest wesentlich unwahrscheinlicher. Dummerweise sind diese
Anstze ressourcenintensiv und letztlich derzeit nur fr Anwendungen mit kleinen Bandbreiten
verwendbar.
Natrlich versteht sich von selbst, dass die ganze hier skizzierte Anonymisierung berssig
wird und sich selbst ad absurdum fhrt, wenn man sich anschlieend beim kontaktierten Server
brav mit einem Cookie ausweist oder einloggt.
278
Server S
Quelle: A Ziel: S, Payload
Internet
Quelle: C Ziel: A ,
verschlsselte Payload
Anonymisierdienst
A
Client C
sichere Verbindung
Abbildung 13.19: Einfacher Anonymisierdienst.
Auch und gerade im Anwendungsbereich ist IT-Sicherheit ein wichtiges Thema.
Bei der bertragung von Emails kommen das Simple Mail Transfer Protocol und das
Post Ofce Protocol oder das Internet Message Access Protocol zum Einsatz. Diese
Protokolle sind vom Sicherheitsstandpunkt aus betrachtet in jeder Hinsicht als unzureichend einzustufen. In vielen Fllen werden daher die bertragungen zustzlich
durch Protokolle wie beispielsweise SSL/TLS geschtzt. Da Email bei der Befrderung vom Sender zum Empfnger zwischen verschiedenen Endpunkten bertragen
wird, kann durch solche Mechanismen allein keines der Ziele von IT-Sicherheit erreicht werden. Hierzu ist es notwendig, die bertragenen Daten auf der Applikationsebene zu verschlsseln. In der Praxis kommen hierfr S/MIME oder GPG in Frage.
SSH ist eine Anwendung, die den Betrieb einer Shell auf einem ber das Netzwerk
erreichbaren Rechner in sicherer Weise ermglicht. SSH besteht aus verschiedenen
Modulen, die aufeinander aufbauen. Besonders interessant ist die Mglichkeit des
sogenannten Port Forwardings ber SSH. Dieses Feature ermglicht es, die SSHVerbindung als Tunnel zu verwenden und so Dienste eines Rechners, der sonst nicht
erreichbar wre, ber SSH Port Forwarding anzusprechen. Hierdurch kann unter anderem die Funktion von Firewalls umgangen werden.
Das World Wide Web (WWW) stellt fr viele Nutzer die wichtigste Internetanwendung dar. Aus technischer Sicht basiert sie auf dem Hypertext Transfer Protocol
(HTTP), das keine Sicherheitsmechanismen bietet.
13.5 bungsaufgaben
279
Daher wird fr die sichere bertragung von Informationen HTTP in Verbindung mit
SSL/TLS verwendet. Dieses Protokoll ist unter dem Namen HTTPS bekannt. Serverseitig erfolgt die Authentikation zertikatsbasiert, whrend eine Authentikation der
Clients in der Regel nicht erfolgt.
Mit Phishing und Pharming bezeichnet man Betrugsversuche durch Umleiten von Benutzern auf geflschte Webseiten. ber das WWW knnen Clients mit Malware inziert und Server angegriffen werden. Daher sollten in der Regel Schutzmanahmen
ergriffen werden.
Privatsphre und Anonymitt sind im WWW durch Cookies und LoggingMechanismen nicht unbedingt sichergestellt. Es gibt Anonymisierdienste, mittels deren Hilfe auch ein nicht oder nur schwierig zurckverfolgbarer Zugriff auf Inhalte im
WWW mglich wird.
13.5 bungsaufgaben
Aufgabe 13.1:
Erlutern Sie, welche Probleme es bei Email hinsichtlich der Sicherheit gibt und wie sie gelst werden knnen. Gehen Sie dabei insbesondere auf Schwachstellen der beim Transport von
Emails verwendeten Protokolle ein.
Aufgabe 13.2:
Erklren Sie die Begriffe Local Port Forwarding und Remote Port Forwarding bei SSH und
beschreiben Sie, welche Auswirkungen die Verwendung des Mechanismus hinsichtlich der Sicherheit eines Netzwerks haben kann.
Aufgabe 13.3:
Beschreiben Sie kurz die Funktionsweise des WWW. Gehen Sie dabei insbesondere auf Sicherheitsaspekte ein. Erlutern Sie dabei die Begriffe HTTPS und TLS.
Aufgabe 13.4:
Denieren Sie die Begriffe Phishing und Pharming. Erlutern Sie, welche technischen Schutzmanahmen getroffen werden knnen. Diskutieren Sie, inwieweit das Problem durch solche
Schutzmanahmen gelst werden kann.
Aufgabe 13.5:
Skizzieren Sie mgliche Risiken des WWW fr Clients und Server.
Aufgabe 13.6:
Erlutern Sie den Begriff Cookie und beschreiben Sie, welche Auswirkungen die Verwendung
von Cookies im WWW haben kann.
280

Aufgabe 13.7:
Die POP-Spezikation [RFC 1939] ermglicht neben der hier dargestellten Authentikation durch
USER und PASS auch eine alternative Authentizierung ber das APOP-Kommando. Skizzieren
Sie die Funktion dieses Kommandos und diskutieren Sie, inwieweit die Verwendung von APOP
die Sicherheit von POP verbessert.
Aufgabe 13.8:
Lesen Sie die RFC zum Thema Cookies und fassen Sie sie zusammen.
Aufgabe 13.9:
Erlutern Sie Vor- und Nachteile der Verwendung eines HTTP-Proxies in Bezug auf Sicherheitsaspekte.
Aufgabe 13.10:
Betrachten Sie folgendes Szenario: Der Zugriff auf einen Intranetserver I ist ausschlielich von
Rechnern aus mglich, deren IP-Adressen sich in einem bestimmten Adressbereich benden. Ein
Benutzer betreibt zwei Rechner A und B auerhalb dieses Bereichs, hat aber die Mglichkeit von
A aus eine SSH-Verbindung zu einem Rechner C mit SSH-Server im Adressbereich des Intranet
aufzubauen. Der Benutzer mchte von B aus auf das Intranet zugreifen.
Erlutern Sie im Detail, wie SSH Port Forwarding in diesem Szenario eingesetzt werden knnte, um den Wunsch des Benutzers nach Zugriff auf das Intranet zu erfllen. Beschreiben Sie
insbesondere, welche Art von Port Forwarding verwendet werden muss und welche Pakete ein
Auenstehender beobachten knnte.
Aufgabe 13.11:
Skizzieren Sie ein Anwendungsszenario, in dem SSH mit Remote Port Forwarding sinnvoll eingesetzt werden knnte.
Aufgabe 13.12:
Eine Firma betreibt zur Entgegennahme von Bestellungen einen Webserver mit HTTPS. Allerdings wurde aus Kostengrnden darauf verzichtet, ein Zertikat von einer anerkannten Root-CA
zu kaufen, sondern es wird ein selbstsigniertes Zertikat verwendet. Diskutieren Sie, inwieweit
diese Lsung mgliche Schwachstellen aufweist und ob sie als sicher beurteilt werden kann.
Aufgabe 13.13:
Recherchieren Sie die Verfahren zur Email-Verschlsselung S/MIME und OpenGPG und stellen
Sie sie detailliert gegenber. Welche Probleme entstehen aus der Inkompatibilitt der Verfahren
und wie knnten sie gelst werden?
Kapitel 14
Realzeitkommunikation
14
Realzeitkommunikation
14.1 Anforderungen, Prinzipien, Protokolle

14.1.1 Einfhrung
IP-basierte Netzwerke werden mehr und mehr auch fr die bertragung von Multimedia, also
Video und Sprache, benutzt. Hierzu zhlt etwa das Streamen von Fernsehprogrammen, Radioprogrammen und Telefonie, besser unter dem Namen Voice over IP (VoIP) bekannt. Einige dieser Anwendungen fallen in den Bereich der Realzeitkommunikation, fr die es notwendig ist, die
beim Sender anfallenden Daten mglichst umgehend beim Empfnger wieder auszugeben. Es ist
bereits abzusehen, dass die bisher separaten Netzwerke fr Telefonie, Fernsehsignale und Daten
zusammenwachsen und in einigen Jahren smtliche Kommunikationsformen ber ein einziges
IP-basiertes Netzwerk laufen werden. Diese Entwicklung wird als Netzwerkkonvergenz bezeichnet und ist mittlerweile in einigen Bereichen, insbesondere bei der Telefonie, schon relativ weit
fortgeschritten.
Um Realzeitkommunikation ber ein IP-basiertes Netzwerk zu ermglichen, mssen zwei
Grundfunktionen vorhanden sein. Dies sind:
Signalisierung: In einem gewhnlichen Telefonnetz ist eine Infrastruktur vorhanden, die
es einem Teilnehmer ermglicht, einen anderen Teilnehmer anzurufen. Dieser wird dann
(durch Klingeln) auf den eingehenden Anruf aufmerksam gemacht und kann ihn annehmen
oder nicht. Ebenso gibt es erweiterte Funktionen wie beispielsweise Rufumleitung. Auch
in einem IP-Netz werden Mechanismen und Protokolle bentigt, um Realzeitkommunikationsverbindungen zwischen zwei oder mehreren Teilnehmern aufzubauen, gegebenenfalls
zu modizieren und wieder zu beenden. Vereinfacht gesagt geht es bei der Signalisierung
also darum, Whlen, Klingeln und Rufumleitungen zu ermglichen.
Medientransport: Wenn sich die Teilnehmer mittels Signalisierung (oder auch durch manuelle Koordination) gefunden haben, mssen die zu bertragenden Daten (Sprache, Video
usw.) irgendwie ber das Netzwerk transportiert werden.
Die Funktionen Signalisierung und Medientransport knnen strikt voneinander getrennt werden. In IP-basierten Netzen kommen fr diese Aufgaben verschiedene Protokolle zum Einsatz.
282
14.1.2 Medientransport
Betrachten wir den Medientransport am Beispiel Telefonie. Fr den Transport ber das paketbasierte IP-Netzwerk werden die analogen Sprachsignale zunchst durch eine Codec digitalisiert
und in Bits und Bytes umgewandelt. Es gibt ganz verschiedene Typen von Codecs, die unterschiedlich arbeiten und die anfallenden Daten auch komprimieren knnen. Je nach verwendeter
Codec kann die bentigte Bandbreite einer Sprachverbindung sehr unterschiedlich sein. Eine Verbindung mit der gleichen Qualitt wie eine ISDN-Verbindung liefert beispielsweise die G.711Codec [G.711]. Sie bentigt eine Bandbreite von jeweils 64 Kbps in jede bertragungsrichtung.
Die so entstanden digitalisierten Sprachdaten werden fr eine gewisse Zeit, das Paketisierungsintervall, gesammelt und dann wie gewohnt ber das Netzwerk verschickt. Beim Empfnger
angekommen werden die bertragenen Daten dann wieder von der Codec in analoge Daten umgewandelt und ausgegeben.
Die Anforderungen an die Dienstgte einer Verbindung (Quality of Service, QoS) bei der
bertragung von Daten einer Multimediaanwendung unterscheiden sich stark von denen bei der
bertragung einer Datei oder von Emails. Dies gilt ganz besonders fr Anwendungen, die in
den Bereich der Realzeitkommunikation fallen, wie beispielsweise Telefonie. Um eine sinnvolle Nutzung solcher Anwendungen zu ermglichen, mssen die beim Sender anfallenden Daten
schnell, nach menschlichem Empnden fast sofort, beim Empfnger wieder ausgegeben werden.
Die Zeitspanne zwischen den Anfall der Daten beim Sender und dem Abspielen beim Empfnger wird als Ende-zu-Ende-Verzgerung bezeichnet. Realzeitkommunikationsverbindungen wie
ein Telefongesprch werden bei steigender Ende-zu-Ende-Verzgerung zunchst als qualitativ
unzureichend wahrgenommen. Wenn die Ende-zu-Ende-Verzgerung weiter steigt und gewisse
Toleranzwerte berschreitet, wird die sinnvolle Nutzung der Verbindung sogar unmglich.
Die Lnge der Ende-zu-Ende-Verzgerung ist durch eine ganze Reihe von Faktoren bestimmt,
darunter die Gre des Paketisierungsintervalls und die Dauer der bertragung durch das Netz.
Gerade in einem datagrammbasierten Netz werden nicht alle Pakete gleich schnell transportiert.
Somit kommen einige Pakete spter beim Empfnger an als andere, so dass die Daten aus den
Paketen nicht unmittelbar umgewandelt und ausgegeben werden knnen. Sie mssen stattdessen beim Empfnger zunchst in einem Puffer zwischengespeichert werden, damit die Schwankungen in der bertragungszeit der Pakete durch das Netz ausgeglichen werden knnen. Die
notwendige Dauer der Zwischenspeicherung im Puffer ist umso hher, je grer die Unterschiede in der bertragungsdauer der Pakete sind. Die Zeit, welche die Pakete im Puffer verbringen
mssen, bevor sie ausgespielt werden knnen, geht ebenfalls in die Ende-zu-Ende-Verzgerung
ein.
Whrend der Verlust eines einzigen Bytes bei der bertragung eine Datei oder Email unbrauchbar machen kann, ist der gelegentliche Verlust einiger Daten bei Audio- und Videokommunikation nicht so kritisch. Ein menschlicher Benutzer bemerkt solche sporadischen Verluste
meistens noch nicht einmal.
TCP stellt durch die nochmalige bertragung verlorengegangener Daten einen zuverlssigen
Transport sicher, der fr Realzeitkommunikation nicht notwendig ist, und der jedoch gerade im
Fall von Paketverlusten zu einer starken Verzgerung fhren kann, die wiederum fr Realzeitanwendungen vllig inakzeptabel ist. Aus diesen Grnden ist TCP als Transportprotokoll fr
Realzeitkommunikation ungeeignet. Stattdessen wird fr Realzeitkommunikationsanwendungen

Byte
Bit
V=2 P X
CC
283
Payload Type
Sequence Number
Timestamp
Synchronization Source Identifier
Contributing Source Identifer (optional, 0-15 mit je 4 Byte)
Abbildung 14.1: RTP-Header.
UDP verwendet (siehe Abschnitt 7.3.4.2). UDP bietet verbindungslosen, nicht notwendigerweise zuverlssigen Transport, und bergebene Daten werden (vereinfacht gesprochen) sofort losgesendet. Insofern ist UDP fr Realzeitkommunikation ideal geeignet. Da man natrlich fr das
Zusammensetzen und Abspielen der empfangenen Daten weitere Informationen bentigt, wird
UDP fr Realzeitkommunikation meistens in Verbindung mit einem weiteren Protokoll, nmlich dem Realtime Transport Protocol (RTP), verwendet, das wir im Folgenden kurz vorstellen
werden.
14.1.3 Realtime Transport Protocol (RTP)

Das RTP-Protokoll ist in [RFC 3550] speziziert. Es verwendet UDP als unterliegendes Transportprotokoll. Die Headerstruktur von RTP ist in Abbildung 14.1 dargestellt. Wir wollen hier
nur kurz auf die wichtigsten Felder eingehen. Payload Type speziziert, welche Art von Daten
in der Nutzlast des Pakets enthalten ist. Die Pakete werden ausgehend von einer zufllig gewhlten Anfangssequenznummer fortlaufend nummeriert. Diese Nummerierung ndet sich im
Feld Sequence Number und wird bei jedem abgesendeten Paket um eins erhht. Wenn der Zhler
berluft, wird wieder bei null begonnen (es wird also modulo 216 gezhlt). Der Empfnger kann
so verlorengegangene Pakete entdecken und eventuell in falscher Reihenfolge angekommene Pakete wieder richtig anordnen. Im Feld Timestamp ndet sich eine Zeitangabe, die angibt, wann
das erste Byte der Payload beim Sender erzeugt wurde. Die genaue Bedeutung dieses Zeitwerts
hngt von der Art der Nutzlast ab. Obwohl es vielleicht auf den ersten Blick so scheinen mag,
ist keines der Felder Sequence Number und Timestamp berssig. Viele Realzeitkommunikationsanwendungen nutzen nmlich Silence Suppression und senden nur dann, wenn beispielsweise
whrend eines Telefongesprchs tatschlich gesprochen wird. Schweigt der Teilnehmer, wird oft
nichts gesendet. In diesen Fllen erhht sich die Sequence Number nicht, whrend die Zeit und
damit die Timestamp weiterluft.
Das Feld Synchronization Source Identier beinhaltet eine zu Beginn zufllig gewhlte 4-Byte
Identikation der Station, die die Sequenznummer und den Zeitstempel gesetzt hat. Normalerweise ist diese der Absender der Nutzlastdaten. Eine Ausnahme bilden Konferenzen, bei denen
die Nutzlastdaten oft zunchst an eine zentrale Sammelstation, den Mixer, gehen und dort dann
in ein Audiosignal zusammengemischt werden. Dann beinhaltet dieses Feld die ID des Mixers,
und die IDs der ursprnglichen Quellen sind jeweils in dem optionalen Feld Contributing Source Identier angegeben. Die Anzahl der Contributing Sources ist im Headerfeld Contributing
Sources Count, kurz CC, angegeben.
284
Die RTP-Spezikation [RFC 3550] ist sehr allgemein gehalten und gibt nur einen Rahmen
vor. Die konkrete Anwendung von RTP erfordert die Spezizierung eines Prols, das Details fr
den Anwendungsfall nher festlegt oder auch notwendige Erweiterungen deniert. Ein solches
Prol ist [RFC 3551], das einen Rahmen fr den Einsatz von RTP fr Audio- und Video-Realzeitkommunikation (z.B. Telefonie oder Videokonferenzen) festlegt. In einem Prol knnen
auch Erweiterungen des RTP-Headers deniert werden. [RFC 3550] speziziert zustzlich zu
RTP auch das RTP Control Protocol (RTCP), welches die berwachung der Dienstgte einer
RTP-Kommunikation und einige weitere Kontrollfunktionen ermglicht.
14.1.4 Signalisierung
Nachdem wir uns nun kurz damit beschftigt haben, wie die eigentlichen Mediendaten ber das
Netz bertragen werden, wollen wir uns nun mit der Signalisierung befassen.
Aufgabe der Signalisierung ist es, den Aufbau einer Verbindung zwischen zwei oder mehr
Kommunikationspartnern zu steuern. Zur Steuerung gehren Aufbau und Beendigung einer Verbindung und auch das Verndern bestehender Verbindungen.
Speziell im Telefoniebereich gibt es zwei beherrschende Standards, nmlich H.323 [H.323]
und SIP [RFC 3261]. H.323 entstammt der alten Telekommunikationswelt, whrend SIP aus
dem Internet-Umfeld stammt und im Markt derzeit H.323 mehr und mehr verdrngt. Da SIP von
der Struktur her den uns bereits bekannten Protokollen hnlicher ist, werden wir uns hier auf SIP
konzentrieren.
14.1.5 Session Initiation Protocol

Das Session Initiation Protocol (SIP) wie in [RFC 3261] speziziert ist ein auf der Applikationsschicht residierendes Signalisierungsprotokoll, mit dem beliebige Verbindungen (auch Sessions
genannt) zwischen zwei oder mehr Teilnehmern aufgebaut, verndert und beendet werden knnen.
SIP ist ein allgemein gehaltenes Protokoll, mit dem sich prinzipiell beliebige Sessions wie
Telefonverbindungen oder Videokonferenzen aufbauen, managen und terminieren lassen. SIP
beinhaltet auerdem Funktionen, die Benutzermobilitt und die Verwendung verschiedener Endpunkte ermglichen. Wir werden SIP im Folgenden ausschlielich am Beispiel Telefonie betrachten.
SIP kann sowohl TCP als auch UDP als Transportprotokoll verwenden (serverseitig Port 5060
sowohl fr TCP als auch UDP). Es verwendet ein zu HTTP sehr hnliches Request-ResponseFormat. Der Client sendet einen SIP-Request an den Server, welcher mit einem SIP-Response
antwortet. Der Request beinhaltet genau wie bei HTTP auch eine Methode sowie eine URI
[RFC 3986] fr den Request. Beispiele fr Methoden sind:
REGISTER: Dient zum Registrieren von Kontaktinformationen.
INVITE: Aufbau einer Session.
ACK: Besttigung vorangegangener Anfragen.
285
CANCEL: Zurckziehen vorheriger Anfragen.

BYE: Terminiert eine Session.
SIP ist mittlerweile auch erweitert worden, um Instant Messaging zu untersttzen; hierzu dienen die in [RFC 3428] denierten Methoden SUBSCRIBE und NOTIFY.
Die SIP-Responses bestehen aus einem Status-Code, der Informationen enthlt, ob der Request erfolgreich war oder nicht, und falls nicht, warum nicht.
Die Architektur von SIP unterscheidet zwischen verschiedenen Rollen:
Registrar: Registrars nehmen SIP-REGISTER-Requests entgegen, die es Benutzern ermglichen, festzulegen, auf welchem Endpunkt sie Anrufe entgegennehmen mchten.
Proxy-Server: Proxy-Server nehmen SIP-Requests fr Benutzer entgegen und leiten sie zu
den entsprechend mit den Benutzern assoziierten Endpunkten weiter.
Redirect Server: Nehmen ebenfalls Requests entgegen, leiten aber nicht weiter, sondern
verweisen auf andere Rechner, welche die Anfrage entgegennehmen.
User-Agent-Server: Prozess auf dem Endsystem des Benutzers, der eingehende SIP-Requests annimmt und den Benutzer entsprechend informiert.
Jeder Teilnehmer, der ber SIP erreichbar sein mchte, verfgt analog zu einer Telefonnummer
ber eine eindeutige Identizierung, die wie eine Email-Adresse aufgebaut ist, also zum Beispiel
lauten knnte und sowohl den Benutzernamen als auch den
Domainnamen des zu kontaktierenden Systems enthlt, wenn mit dem Benutzer eine Verbindung
aufgebaut werden soll. Diese Identizierung ist ein Bestandteil der URI bei entsprechenden SIPRequests.
In den meisten Anwendungsszenarien ist der Domainname nicht der des Endsystems, auf dem
der Benutzer seine Anrufe tatschlich entgegennehmen mchte, sondern der Domainname eines
Proxy-Servers. Hierdurch kann der Benutzer verschiedene Endgerte oder ein Gert mit wechselnden Adressen verwenden, bleibt aber unter der gleichen Adresse erreichbar.
Vergleicht man dies mit Email, so bernimmt der Proxy-Server bei SIP in etwa die Rolle des
Email-Servers, auf dem der Benutzer ein Konto hat, allerdings mit einem wichtigen Unterschied:
Eine Email kann auf dem Email-Server gehalten werden, bis der Benutzer den Server kontaktiert und die Email abholt. Es besteht dabei kein enger zeitlicher Zusammenhang zwischen dem
Empfang der Email beim Server und der Abholung beim Server durch den Benutzer. Bei SIP
funktioniert dieser Ansatz nicht, da unmittelbar eine Verbindung aufgebaut werden muss.
Deshalb wird bei SIP eine etwas andere Architektur eingesetzt. Um beim Proxy eingehende
Anfragen umgehend an den Benutzer weiterleiten zu knnen, muss dem Proxy bekannt sein,
wie der Nutzer gegenwrtig erreicht werden kann. Hierzu meldet der Benutzer das Gert, auf
welches eingehende Anrufe signalisiert werden sollen, bei einem Registrar an. Geht nun ein
Anruf beim Proxy ein, verwendet der Proxy diese Information des Registrars und kontaktiert
den entsprechend vom Benutzer registrierten Endpunkt. Der Informationsaustausch zwischen
Registrar und Proxy kann ganz unterschiedlich organisiert werden, beispielsweise indem der
Registrar die Informationen in einer Datenbank ablegt, die der Proxy dann kontaktiert. Registrar
und Proxy knnen auch zusammen in einer Maschine und einem Prozess laufen.
286
SIP-Proxy
von Alice
atlanta.com
Bobs Endgert
192.0.2.4
Internet
Alices
Endgert
pc33.atlanta.com
SIP-Proxy
von Bob
biloxy.com
Abbildung 14.2: Beispiel fr SIP.
Abbildung 14.2 und Abbildung 14.3 zeigen ein [RFC 3261] entnommenes Beispiel. Alice
(
) mchte zu Bob (
) eine Verbindung aufbauen. Sowohl
Alice als auch Bob verwenden Proxies und haben ihre gegenwrtig verwendeten Endpunkte ber
Registrars registriert. Fr Alice ist die gegenwrtige Adresse
und
fr Bob
.
Wenn Alice mit Bob beispielsweise ber VoIP telefonieren mchte, sendet Sie einen SIP. Die Signalisierung luft dabei zunchst von Alice zu
INVITE-Request an
ihrem Proxy, der dann diese Adresse auswertet und den Rechner
, also Bobs Proxy,
kontaktiert. Dort liegt die Registrierung von Bobs gegenwrtigem Endpunkt vor, an den dann
diese Anfrage weitergeleitet wird.
Abbildung 14.3 zeigt dabei den genauen Austausch von SIP-Requests und Responses nach
[RFC 3261]. Es gbe noch viel ber SIP zu sagen, aber wir mssen es an dieser Stelle dabei
bewenden lassen. Eine detaillierte Darstellung von SIP und wichtigen Realzeitkommunikationsprotokollen ndet sich beispielsweise in [Kan05] [Bad06], [SJ06], [TW05] oder [Col03].
14.2 Sicherheit von Realzeitkommunikationsanwendungen

14.2.1 Bedrohungen
Wenn Realzeitkommunikation ber IP-basierte Netze betrieben wird, kommt man leider nicht
nur in den Genuss der Vorteile dieser Technologie, sondern muss auch ihre Nachteile in Kauf
nehmen.
In Bezug auf die Sicherheit treffen alle Bedrohungen, die wir in den vorangegangenen Kapiteln
skizziert haben, auch auf ber solche Netze abgewickelte Realzeitkommunikation zu. Speziell fr
Realzeitkommunikation sind derzeit folgende Bedrohungen wahrscheinlich als am kritischsten
zu beurteilen:
Alices Endpunkt
pc33.atlanta.com
INVITE
Alices Proxy
atlanta.com
287
Bobs Endpunkt
192.0.2.4
Bobs Proxy
biloxy.com
INVITE
100 TRYING
INVITE
100 TRYING
180 RINGING
180 RINGING
180 RINGING
200 OK
200 OK
200 OK
ACK
Media Session
BYE
200 OK
Abbildung 14.3: Beispiel fr Ausgetauschte SIP-Nachrichten beim Aufbau und Abbau einer Verbindung.
Abhren: Kann ein Angreifer sich Zugriff auf (unverschlsselt) bertragene Daten verschaffen, ist es sehr einfach, diese Daten wieder zusammenzusetzen und die Realzeitkommunikation abzuhren. Fr VoIP bieten viele Sniffertools wie Wireshark eingebaute Mechanismen, um die aufgefangenen Pakete in eine abspielbare Audiodatei zu verwandeln.
Unterbrechung: Ein Angreifer kann die Kommunikation stren oder sogar einen Denialof-Service-Angriff durchfhren.
Auch das Vortuschen falscher Identitten und Angriffe analog zu Phishing und Pharming sind
mittel- und langfristig denkbar, spielen aber derzeit noch eine untergeordnete Rolle.
Manchmal wird behauptet, die oben genannten Bedrohungen seien letztlich nicht neu, sondern
auch bei Telefonnetzen herkmmlicher Prgung vorhanden, so dass sich aus der Verwendung von
VoIP keine prinzipiell neuen Bedrohungen ergeben wrden. Auch wenn dieses Argument teilweise zutrifft (das Abhren herkmmlicher Telefonie ist sowohl bei analogen als auch digitalen
Technologien tatschlich leicht), entsteht durch den Einsatz IP-basierter Technologie doch eine
vernderte Bedrohungslage.
Dies trifft speziell auf den Aspekt der Unterbrechung der Kommunikation zu. Wendet man
VoIP an, so sind die daran beteiligten Gerte, vom VoIP-Telefon angefangen ber normale Rechner mit einer softwarebasierten Telefonieanwendung (Softphone) bis hin zu beteiligten Maschinen in der Infrastruktur wie Proxies, letztlich vollwertige Gerte in einem Netzwerk Gerte
mit einem Betriebssystem, mit vollstndiger Netzwerkfunktionalitt, einer Netzwerkschnittstelle und einer IP-Adresse. Somit kann ein VoIP-Endpunkt prinzipiell genauso ber das Netzwerk
angesprochen und auch kompromittiert werden wie ein gewhnlicher Rechner.
Ein IP-basiertes Telefon ist also nicht nur ein Telefon, sondern vor allen Dingen auch ein Gert
in einem Netzwerk. Wie Server und Arbeitsplatzrechner knnen Schwachstellen in den Gerten
auf jeder Ebene ausgenutzt werden, um sie anzugreifen. Dies bezieht sich nicht nur auf den VoIP-
288
Internet
Intranet
Media/SignalingGateway
Telefonnetz
Abbildung 14.4: VoIP im institutionellen Umfeld.
Teil, sondern auch auf Fehler in der Implementierung der anderen Protokolle wie IP, UDP oder
des verwendeten Betriebssystems selbst.
Wie in Kapitel 12 schon erwhnt wurde, sind die Anforderungen an die Verfgbarkeit von
Telekommunikationssystemen im Allgemeinen sehr hoch. Entsprechend schwer ist das Risiko
eines mglichen Ausfalls der Systeme einzustufen, was umfangreiche Manahmen zum Schutz
der Infrastruktur notwendig macht.
brigens sind die Bedrohungen durch den Einsatz von VoIP nicht nur im Sicherheitsbereich
zu nden: Es ist durchaus mglich, dass in den nchsten Jahren Spam over IP Telephony (SPIT)
ein ernsthaftes Problem werden knnte.
14.2.2 Gegenwrtige Einsatzformen im institutionellen Umfeld

Der Einsatz von VoIP im institutionellen Umfeld hat in den letzten Jahren sehr stark zugenommen und wird voraussichtlich die bisher verwendeten institutionsinternen Netze fr Telefonie
mittel- bis langfristig vollstndig ersetzen. Bisher beschrnkt sich der Einsatz jedoch weitestgehend darauf, VoIP innerhalb des eigenen Intranets zu verwenden. Die entsprechend vorhandene
Infrastruktur fr Telefonie und die Firewall sind so konguriert, dass keine VoIP-Verbindungen
ber das Internet mglich sind. Verbindungen zu Teilnehmern auerhalb des Intranets erfolgen
ber das regulre Telefonnetz. Hierzu betreibt die Institution ein oder mehrere Gateways, die
mit dem Intranet auf der einen und dem Telefonnetz auf der anderen Seite verbunden sind. Konzeptionell kann wiederum zwischen Gateways fr die Signalisierung und Gateways fr die eigentlichen Audiodaten unterschieden werden. Signalisierungsgateways bersetzen die aus dem
Intranet ankommenden Signalisierungsdaten (H.323 oder SIP) in entsprechende Signale fr das
Telefonnetz und umgekehrt. Ebenso werden die Mediendaten durch die Gateways entsprechend
bersetzt und weitergeleitet. Abbildung 14.4 zeigt diese Architektur in stark vereinfachter Form
auf.
289
Wichtig aus unserer Sicht ist, dass die gesamte IP-basierte Infrastruktur fr VoIP, einschlielich des Gateways, nur ber eine IP-Verbindung in das Intranet verfgt, nicht jedoch mit dem
Internet kommunizieren kann. Von auen ist das Gateway zwar ber das Telefonnetz kontaktierbar, jedoch nicht ber ein IP-basiertes Netzwerk. Damit unterscheidet sich die Sicherheitssituation nach auen nicht wesentlich von der einer normalen Telefonanlage (zumindest unter
der Annahme einer vernnftig kongurierten Firewall zwischen Internet und Intranet). Von innen betrachtet sind jedoch das Gateway und die anderen Teile der VoIP-Infrastruktur wie andere
Netzwerkkomponenten auch an das Intranet angeschlossen. Als IP-basierte Gerte sind sie damit
einem greren Gefhrdungspotential ausgesetzt als die klassische Telefonieinfrastruktur.
Wir wollen kurz die Sicherheitsimplikationen dieser Architektur betrachten. Durch die Firewall sind die Rechner im Intranet gegen direkte Angriffe von auen weitgehend geschtzt (sieht
man wiederum von den prinzipiellen Schwchen einer Firewall ab). Jedoch ergibt sich aus dem
Intranet heraus ein Bedrohungspotential. Von dort aus knnen bestehende Verbindungen potentiell sowohl abgehrt als auch gestrt werden.
Eine erste Manahme, die VoIP-Infrastruktur gegen solche Bedrohungen zu schtzen, ist der
Betrieb dieser Gerte in einem eigenen LAN oder VLAN des Intranet. Mit anderen Worten: Von
anderen Maschinen aus sind die VoIP-Gerte nicht auf der Datenverbindungsschicht erreichbar,
sondern nur ber einen Router. Hierdurch werden ein mgliches Abhren ungeschtzter Verbindungen und bestimmte Arten von Angriffen etwas erschwert. Eine solche Architektur empehlt
sich nicht nur aus Sicherheitsgrnden, sondern wird ebenfalls empfohlen, um die zu Beginn geschilderten Anforderungen von Realzeitverkehr hinsichtlich QoS besser erreichen zu knnen.
Eine derartige Manahme kann also nicht schaden, allerdings ist die hierdurch erreichte Verbesserung der Sicherheit nicht wirklich berzeugend. Der auf diese Weise erreichte Schutz kann
relativ leicht umgangen werden. Ebenso bleiben die Telefone von normalen Rechnern im Intranet
aus erreichbar und damit angreifbar.
Eine andere Lsung ist es, das Intranet durch Einsatz einer weiteren Firewall nochmals aufzuteilen, nmlich in ein Intranet fr VoIP und ein Intranet fr Daten. Diese Netze sind miteinander
verbunden, allerdings ber eine Firewall. Konzeptionell hat man dann zwei voneinander separierte Intranets. Schematisch ist dieser Ansatz in Abbildung 14.5 skizziert.
Diese Kompartmentalisierung des Intranets in mehrere, voneinander durch Firewalls abgegrenzte Teilnetze wird nicht nur fr VoIP eingesetzt, sondern auch, um andere besonders sensitive
Teile vom Rest des Netzes abzutrennen, beispielsweise Forschungslabore oder die Rechner der
Unternehmensfhrung. Wenn die Firewall zwischen diesen sensitiven Bereichen und dem Rest
des Intranets restriktiv genug konguriert ist, sind die Rechner im sensitiven Bereich ebenso gut
gegen Angriffe aus dem Rest des Intranets geschtzt, wie es die Rechner im Rest des Intranets
gegen Angriffe aus dem Internet sind.
Doch sollte man nicht verkennen, dass dieser Ansatz, zumindest wenn er fr VoIP eingesetzt
wird, einige intrinsische Schwchen aufweist. Sind in einem Raum zwei Netzwerkanschlsse
vorhanden, einer fr das Datennetz und einer fr das VoIP-Netz, so kann die Firewall umgangen werden, indem ein Gert vom Netzwerkanschluss fr Daten auf den Netzwerkanschluss fr
VoIP umgesteckt wird. Manahmen zur Verhinderung solcher Angriffe werden wir im nchsten
Kapitel betrachten.
Ein weiterer wesentlicher Punkt ist die gegenwrtige Konvergenz der fr VoIP eingesetzten
Endgerte. Schon heute werden vielfach gewhnliche Arbeitsplatz-PCs als Softphones einge-
290
Internet
Intranet fr
Daten
Intranet fr
VoIP
Abbildung 14.5: Aufteilung des Intranets in zwei durch eine Firewall separierte Teile fr Sprache und Daten.
setzt, in naher Zukunft werden wahrscheinlich eigenstndige Telefone verschwinden und zu einem Teil des Computers werden. Langfristig knnte sich VoIP zu einer zwar wichtigen, aber
doch gewhnlichen Anwendung auf den Arbeitsplatzrechnern entwickeln. Damit besteht aber
die Mglichkeit des Schutzes durch ein separates VLAN oder eine Firewall nicht mehr.
VoIP ermglicht auch die einfache Einbindung der Telefone in Auenstellen und Filialen einer Institution in das interne Telefonnetz. ber eine eigene (Daten)leitung oder ein VPN (siehe
Kapitel 10) knnen Telefone in Auenstellen kostengnstig ber IP mit der Telefonanlage in
der Hauptstelle verbunden werden, genauso wie man durch ein VPN oder eine private Leitung
zwei Standorte einer Institution zu einem gemeinsamen Intranet verbinden kann (siehe Abschnitt
10.3). Aus der Sicherheitsperspektive ist gegen die Verwendung eines VPNs fr solche Zwecke
nichts einzuwenden. Gerade bei einer VPN-Lsung ist die Verfgbarkeit und die erreichbare
Quality of Service teilweise schwer einschtzbar und kann (in Abhngigkeit des anderen Netzwerkverkehrs) stark variieren. Deshalb ist es gerade im Telefoniebereich ratsam, die Architektur
so zu whlen, dass die jeweiligen Standorte auch dann voll betriebsfhig sind, wenn die IPAnbindung zur Hauptstelle gestrt ist.
14.2.3 Gegenwrtige Einsatzformen im privaten Umfeld

VoIP hat sich nicht nur im institutionellen Umfeld mehr und mehr durchgesetzt, sondern erfreut
sich auch bei Privatanwendern wachsender Beliebtheit. Gegenwrtig nden sich im privaten Bereich verschiedene Einsatzformen. Zum einen werden tatschlich zunehmend Ende-zu-EndeVerbindungen zwischen Teilnehmern vollstndig ber IP abgewickelt. Es gibt eine Reihe von
teilweise proprietren und mit anderen Systemen inkompatiblen VoIP- und Videokonferenzanwendungen.
14.3 Protokolle fr sichere Realzeitkommunikation
Internet
291
Heimnetz
privater
Breitbandanschluss
Media/SignalingGateway
Telefonnetz
Abbildung 14.6: VoIP als Ersatz fr einen normalen Telefonanschluss.
Interessanterweise wird VoIP aber auch zunehmend als Ersatztechnologie fr einen gewhnlichen Telefonanschluss verwendet. VoIP wird dabei auf der letzten Meile zwischen dem Endanschluss des Teilnehmers und der Vermittlungsstelle eingesetzt. ber einen Breitbandanschluss
betreibt der Teilnehmer VoIP ber das Internet zu einem Gateway, das als Brcke in das normale
Telefonnetz fungiert. Dort werden Anrufe aus dem normalen Telefonnetz in IP bersetzt und zum
Teilnehmer weitergeleitet und umgekehrt. Dies ist in Abbildung 14.6 skizziert. Beim Anwender
zuhause knnen dabei sogar analoge Telefone verwendet werden. Verschiedene Hersteller bieten
Media/Signaling-Gateways an, welche die Signalisierung und Sprachdaten des analogen Telefons auf IP bersetzen und umgekehrt.
Im Gegensatz zum Einsatz im institutionellen Umfeld werden also im Privatanwenderbereich
bereits ffentliche Datennetze fr die Kommunikation verwendet. In Anbetracht der schon ausfhrlich diskutierten Bedrohungen bei der Netzwerkkommunikation erscheint es daher dringend
ratsam, die VoIP-Kommunikation zwischen dem Privatnetz und dem Media/Signaling-Gateway
im Internet durch kryptographische Verfahren zu schtzen.
Aufgrund fehlenden Know-Hows und unzureichender Hard- und Software sind viele private
Netzwerke nur unzureichend oder gar nicht gegen Angriffe geschtzt. Daher haben Angreifer
es manchmal leicht, solche Netze zu kompromittieren und sich Zugriff auf Gerte und Daten zu
verschaffen. Werden solche Netze auch fr VoIP verwendet, so sollte dies zum Anlass genommen
werden, die Sicherheit in einem privaten Netz nochmals genauer unter die Lupe zu nehmen und
gegebenenfalls zu verbessern.

14.3.1 Sicherer Medientransport: SRTP
Aufgrund der dargestellten Schwchen und Angriffsmglichkeiten ist es generell sinnvoll, die
bei der Realzeitkommunikation bertragenen Daten gegen Angriffe abzusichern. Hierzu wurde
292
Byte
Bit
V=2 P X
CC
Payload Type
Sequence Number
Timestamp
Synchronization Source Identifier
Contributing Source Identifer (optional, 0-15 mit je 4 Byte)

RTP Header Extension (optional)
Payload
SRTP MKI (optional)
Authentification Tag (empfohlen)
Integrittsschutz
Verschlsselung
Abbildung 14.7: SRTP-Paket.
das Secure Real-time Transport Protocol [RFC 3711] entwickelt, das auf RTP und speziell dem
RTP-Prol [RFC 3551] basiert.
SRTP bietet die Mglichkeit, die Vertraulichkeit und die Integritt der einzelnen bermittelten RTP-Pakete sicherzustellen. Auerdem beinhaltet SRTP auch Mechanismen, um Replays zu
erkennen. Diese Mechanismen knnen unabhngig voneinander eingesetzt werden.
SRTP ist erweiterbar und kann auch in Verbindung mit neuen kryptographischen Verfahren
fr Verschlsselung und Gewhrleistung der Integritt verwendet werden. Darber hinaus speziziert SRTP bereits als grundlegende Standards einige kryptographische Basisfunktionen fr
Verschlsselung und Integrittsprfung, die den besonderen Anforderungen an Protokolle fr
Realzeitkommunikation gerecht werden.
Als Endpunkte fr Realzeitkommunikation werden hug Gerte eingesetzt, die hinsichtlich
ihrer Rechenleistung eher beschrnkt sind (Stichwort VoIP-Telefon). Dem mssen die Verfahren
fr Verschlsselung und Integrittsschutz Rechnung tragen. Dies ist bei SRTP realisiert, indem
auf AES basierende Schutzmechanismen speziziert worden sind. AES kann in Hardware implementiert werden und ist somit auch im Embedded-Bereich gut geeignet. Die verwendeten Betriebsmodi sind stromorientiert (siehe Abschnitt 2.4.3) und so gewhlt, dass die Entschlsselung
eines SRTP-Paketes auch dann mglich ist, wenn vorangegangene Pakete den Empfnger nicht
erreicht haben. Auch dies ist aufgrund der zu Beginn des Kapitels dargestellten Anforderungen
bei Realzeitkommunikation notwendig.
Bei der Verschlsselung und Integrittsprfung durch SRTP werden eine ganze Reihe verschiedener Session Keys (bis zu sechs) bentigt. SRTP deniert ein Verfahren, um diese Session
Keys ausgehend von einem einzigen sogenannten Master Key kryptographisch sicher abzuleiten.
Es ist mglich, den Master Key im laufenden Betrieb zu wechseln, und nach einer bestimmten
Anzahl bertragener Pakete ist der Wechsel des Master Keys sogar vorgeschrieben.
Abbildung 14.7 zeigt die SRTP-Paketstruktur. Im Vergleich zum ursprnglichen RTP-Format
kommen nur zwei SRTP-Felder am Ende des Pakets hinzu, nmlich
293
Master Key Identier (MKI): Beinhaltet eine Identizierung des zur Erzeugung der verwendeten Session Keys benutzten Master Keys. Dieses Feld ermglicht die Verwendung
mehrerer Master Keys. Es ist ein optionales Feld und seine Lnge ist durch SRTP nicht
fest vorgegeben, sondern kann durch ein separates Protokoll vor Beginn der Session frei
ausgehandelt werden.
Authentication Tag: Beinhaltet Authentikationsinformation (z.B. Hashwert) zum Schutz
der Integritt. Die Lnge des Feldes ist durch SRTP ebenfalls nicht fest vorgegeben, sondern kann durch ein separates Protokoll vor Beginn der Session frei ausgehandelt werden.
Somit beansprucht SRTP auch hinsichtlich der Bandbreite nur wenig zustzliche Kapazitt.
Whrend sich die Verschlsselung bei SRTP ausschlielich auf das Payload-Feld beschrnkt,
erstreckt sich die Integrittsprfung ber den gesamten Header des RTP-Pakets und das PayloadFeld.
Diese Beschrnkung der Verschlsselung auf die Payload hat hinsichtlich der Sicherheit natrlich einige negative Konsequenzen. So kann ein Angreifer, der SRTP-Pakete mitlesen kann,
aus dem im Klartext bertragenen Header einige Rckschlsse ber die Art der Kommunikation
ziehen.
SRTP realisiert wie bereits erwhnt auch einen Schutz gegen Replays. Dieser Schutzmechanismus basiert auf der Sequenznummer des RTP-Pakets. Daher hngt der Schutz vor Replays von
der Integrittskontrolle ab, denn wenn diese kompromittiert werden kann, knnte ein Angreifer
die Sequenznummern manipulieren und so die Replay-Kontrolle aushebeln.
Wir wollen uns diesen Schutz gegen Replays etwas genauer anschauen. Die RTP-Sequenznummer ist 16 Bit lang und wird fr jedes ausgesendete Paket um eins erhht. Wrde man nur
die Sequenznummer fr den Replay-Schutz verwenden, so wre das nicht ausreichend: Geht
man davon aus, dass bei einer VoIP-Verbindung alle 10 ms ein Paket verschickt wird, werden
pro Sekunde 100 Pakete ausgesendet, so dass in etwas weniger als 11 Minuten der Sequenzzhler wieder beim ersten Wert angelangt ist. Somit reicht die Sequenznummer allein fr die
Replaykontrolle nicht aus. Daher zhlt SRTP in einem weiteren 32-Bit-Zhler mit, wie oft der
Sequenznummerzhler bereits bergelaufen ist, also wie oft er von 216 1 auf 0 gesetzt wurde.
Dieser Zhler, genannt Rollover Counter, bildet gemeinsam mit dem Sequenzzhler einen virtuellen Zhler mit einer Lnge von 48 Bit, der in die Berechnung des Authentication Tag eingeht.
Wir wollen an dieser Stelle die Beschreibung der Funktionsweise von SRTP nicht vertiefen.
[RFC 3711] speziziert zustzlich zu SRTP auch Secure RTCP, welches die sichere bertragung
von RTCP-Daten ermglicht.
Beim Lesen ist Ihnen mittlerweile wahrscheinlich die Frage in den Sinn gekommen, wie zwischen den Kommunikationspartnern eigentlich das Master Secret vereinbart oder ausgetauscht
wurde. Dies geschieht nicht ber SRTP, sondern muss vorher durch ein entsprechendes Protokoll zum Schlsselaustausch erfolgen, das beispielsweise in die Signalisierungprotokolle mit
integriert wird. Wenden wir uns nun also Sicherheitsaspekten bei der Signalisierung zu.
14.3.2 Sicherheitsaspekte bei der Signalisierung

Auch bei der Signalisierung sind eine ganze Reihe von Sicherheitsaspekten zu beachten. Wir
wollen uns an dieser Stelle weniger mit konkreten Protokollen befassen als mit generelleren
294
Prinzipien und Problemen, die hinsichtlich der Sicherheit bei der Signalisierung von Bedeutung
sind. Dabei werden wir uns beispielhaft an der konkreten Architektur und Funktionsweise von
SIP orientieren.
Viele der skizzierten Probleme und Fragen sind dabei prinzipiell recht hnlich zu denen, die
wir bereits vom Anwendungsbeispiel Email aus Abschnitt 13.1 kennen. Jedoch gibt es auch
einige Besonderheiten.
Einige der wichtigsten notwendigen Funktionen sind:
Authentikation von Benutzern gegenber Proxies/Registrars: Benutzer mssen sich gegenber anderen Servern, speziell Proxies und Registrars sicher authentizieren. Die Integritt der von einem Benutzer zu einem Proxy geschickten Nachrichten muss ebenfalls
sichergestellt sein. Ist dies nicht der Fall, knnte ein Angreifer sich beispielsweise als
Benutzer ausgeben und seinen eigenen Endpunkt als vermeintlichen Endpunkt eines Benutzers registrieren. Dies knnte es ermglichen, auf Kosten des Benutzers Verbindungen
aufzubauen und die Dienste der Server zu missbrauchen oder eingehende Verbindungen
anstelle des Benutzers anzunehmen.
Authentikation der Benutzer untereinander: Auch Nutzer untereinander sollten die Mglichkeit erhalten, sich Ende-zu-Ende gegenseitig zu authentizieren. Hierdurch knnten
beispielsweise zuknftige Phishing- oder Pharmingangriffe ber VoIP verhindert werden.
Vertraulichkeit der Signalisierung: Die bei der Signalisierung ausgetauschten Daten knnen Informationen beinhalten, die schtzenswert sind. So kann etwa der gegenwrtig verwendete Endpunkt Rckschlsse auf den Aufenthaltsort eines Benutzers erlauben.
Aushandeln eines Master Secrets fr die Verschlsselung der Mediadaten: Um spter beispielsweise SRTP einsetzen zu knnen, mssen Schlssel ausgehandelt und bereitgestellt
werden.
Die Authentikation von Benutzern gegenber einem Server, bei dem sie ber ein Nutzerkonto verfgen, ist prinzipiell einfach zu lsen, ebenso wie ein Integrittsschutz fr die dabei
ausgetauschten Nachrichten.
Sehr viel schwieriger wird es schon, wenn man die Authentikation der Benutzer untereinander betrachtet. Prinzipiell wren Zertikate oder andere Infrastrukturen zur Authentikation
geeignet, jedoch sind solche Strukturen, insbesondere fr Benutzer, derzeit noch nicht in ausreichendem Mae umgesetzt. Dies betrifft allerdings andere Anwendungen wie Email letztlich
genauso. Wie bei Email auch sind bei VoIP in der Regel eine ganze Reihe von anderen Gerten
(Proxies, Gateways) am Aufbau der Kommunikation beteiligt. Wenn eines dieser Gerte kompromittiert wurde oder unter der Kontrolle eines Angreifers steht, gibt es vielfltige Missbrauchsmglichkeiten, die eigentlich eine Ende-zu-Ende-Authentikation mehr als ratsam erscheinen
lassen.
Betrachten wir nun noch die Vertraulichkeit bei der Signalisierung. Wie aus dem SIP-Beispiel
in Abschnitt 14.1.5 bereits deutlich wurde, erfolgt die Signalisierung hug nicht direkt zwischen den Endpunkten, sondern involviert verschiedene Gerte im Netz. Diese Gerte mssen
die Nachrichten ebenfalls (zumindest grtenteils) im Klartext vorliegen haben, da sie aktiv in
295
die Signalisierung eingebunden sind und Nachrichten auswerten und verndern mssen. Zwischen den Stationen knnen die blichen Verschlsselungsmechanismen zum Einsatz kommen.
Bestimmte andere Teile einer SIP-Nachricht betreffen jedoch nur die jeweiligen Endpunkte selbst
(z.B. die Aushandlung der tatschlich verwendeten Parameter fr die Session). Diese Teile knnen analog zum Inhalt einer Email Ende-zu-Ende verschlsselt werden.
Insgesamt stellt sich aber schon die Frage, inwieweit eine Verschlsselung der Signalisierung
sinnvoll ist. Wird SRTP zum Transport der Mediadaten verwendet, so sind viele der ber die
Signalisierung ausgehandelten Parameter spter wieder unverschlsselt im Header der SRTPPakete wiederzunden.
14.3.3 SIP-Sicherheitsfunktionen
Die Spezizierung des SIP-Protokolls [RFC 3261] beinhaltet bereits eine Reihe von Sicherheitsmechanismen, die im Wesentlichen anderen Protokollen entstammen und zur Realisierung der
oben angesprochenen Schutzmechanismen verwendet werden knnen. Darunter nden sich:
SIP Digest: Methode zur Authentikation analog zu einem ursprnglich fr HTTP vorgeschlagenen Vorgehen [RFC 2617]. Es fut auf der Verwendung eines Challenge-ResponseVerfahrens basierend auf einem Shared Secret (Passwort) zur Authentikation. Diese Methode sichert Integritt und Vertraulichkeit nur sehr eingeschrnkt, so dass ein Angreifer
eine ganze Reihe mglicher Ansatzpunkte fr einen Angriff hat. Es bietet aber Schutz vor
Replay-Attacken.
Verwendung von TLS (genannt SIPS): Wenn TCP als Transportprotokoll fr SIP verwendet wird, kann wie bei HTTP auch TLS (siehe Abschnitt 13.3.3) zum Einsatz kommen.
[RFC 3261] speziziert dabei auch, dass bei der Verwendung von TLS tatschlich smtliche bei der Signalisierung verwendeten Verbindungen gesichert sein mssen, jedenfalls
bis zum Proxy des kontaktierten Kommunikationspartners.
Verwendung von S/MIME: Da SIP-Nachrichten in Teilen, die etwa Parameter zum Aushandeln der Session beinhalten, dem MIME-Format entsprechen, kann auch S/MIME (siehe
13.1.3.2) verwendet werden, um die Nachrichten kryptographisch Ende-zu-Ende zu schtzen. Die bei der Signalisierung durchlaufenen Zwischenstationen bentigen diese Daten
nicht.
Derzeit wird darber hinaus an Standards gearbeitet, die eine mehr oder weniger einfache
Bereitstellung von Schlsseln fr den krytographischen Schutz der Mediadaten bereitstellen. Es
ist damit zu rechnen, dass solche Verfahren bald nalisiert und dann rasch auch Eingang in
entsprechende Produkte nden werden.
296
Die bertragung von Realzeit-Multimediainhalten ber IP-basierte Netze wird zunehmend wichtiger. Um solche Anwendungen zu realisieren, werden Protokolle fr
die Signalisierung und fr den eigentlichen Medientransport bentigt. Der Medientransport kann durch Protokolle wie RTP erfolgen, die Signalisierung beispielsweise
ber SIP. Realzeitkommunikationsanwendungen sind prinzipiell genauso anfllig gegen Angriffe wie andere Anwendungen ber IP-basierte Netze, so dass diese ebenfalls
gegen Angriffe geschtzt werden sollten. Die Sicherung der Mediendaten kann ber
SRTP erfolgen. Dieses Protokoll ist eine Erweiterung von RTP und verfgt ber Mechanismen zur Sicherstellung von Vertraulichkeit und Integritt sowie Schutz gegen
Replays. SRTP ist dabei besonders ressourcenschonend, was fr Realzeitanwendungen wichtig ist. Auch bei der Signalisierung ist insbesondere darauf zu achten, dass
eventuelle Benutzerauthentizierungen auf Systemen geschtzt erfolgen und dass ausgetauschte Nachrichten authentiziert und integrittsgeschtzt werden.
14.5 bungsaufgaben
Aufgabe 14.1:
Beschreiben Sie kurz, wie Realzeitkommunikation ber IP abluft und welche Protokolle dabei
zum Einsatz kommen. Erlutern Sie die Implikationen der Netzwerkkonvergenz fr Telefonie in
Bezug auf die Sicherheit.
Aufgabe 14.2:
Skizzieren Sie die gegenwrtigen Einsatzformen von VoIP im privaten und institutionellen Umfeld und analysieren Sie die Konsequenzen fr die Sicherheit.
Aufgabe 14.3:
Erklren Sie Einsatzszenarien und Funktionsweise des SRTP-Protokolls.
Aufgabe 14.4:
Eine VoIP-Verbindung sende konstant alle 30 ms ein RTP-Paket mit Audiodaten. Berechnen Sie,
wie lange es dauert, bis sich das erste Mal eine RTP-Sequenznummer wiederholt. Beschreiben
Sie, warum dies fr den von SRTP bereitgestellten Replay-Schutz relevant ist und wie das resultierende Problem bei SRTP gelst wurde.
Aufgabe 14.5:
Erlutern Sie Sicherheitsaspekte bei der Signalisierung einer Realzeitverbindung und beschreiben Sie, welche Sicherheitsfunktionen SIP beinhaltet.
14.5 bungsaufgaben
297

Aufgabe 14.6:
Ein Angreifer sei in der Lage, Netzwerkverkehr mitzuhren. Stellen Sie eine Liste zusammen,
welche Informationen aus beobachteten SRTP-Daten gewonnen werden knnen. Analysieren
Sie ebenfalls die Situation, wenn dieselbe Kommunikation ber ein VPN abgewickelt wrde,
und vergleichen Sie sie.
Aufgabe 14.7:
Wir haben bereits kurz angesprochen, dass Realzeitkommunikation auch ber VPNs abgewickelt
werden kann. Bei der Verwendung von VPNs kann es speziell hinsichtlich der Quality of Service
zu einigen Problemen kommen. Recherchieren Sie, welche Schwierigkeiten auftreten knnen
und wie sie zu lsen sind.
Kapitel 15
Sicherheit auf der
15
Sicherheit auf der Datenverbindungsschicht und
undinin
lokalen
lokalen
NetzenNetzen
15.1 Das Extensible Authentication Protocol (EAP)

15.1.1 Einfhrung
Wir haben uns in den letzten Kapiteln mit der Sicherheit im Internet beschftigt und mit der
Frage, wie private Intranets gegen Bedrohungen aus dem Internet gesichert werden knnen. In
diesem Kapitel werden wir nun den Fokus auf die Datenverbindungsschicht, speziell von lokalen Netzwerken, legen und uns mit der Frage beschftigen, wie lokale Netzwerke auch gegen
Bedrohungen von innen abgesichert werden knnen.
Konkret beginnen wollen wir unsere Betrachtungen ber Sicherheit auf der Datenverbindungsschicht mit dem Extensible Authentication Protocol (EAP) wie in [RFC 3748] speziziert. EAP
wurde ursprnglich fr den Einsatz mit PPP konzipiert, und viele der verwendeten Konzepte
lassen sich im Zusammenspiel mit PPP leicht erklren.
PPP ist wie in Abschnitt 7.3.2 erlutert ein Protokoll auf der Datenverbindungsschicht, das auf
einer Punkt-zu-Punkt-Verbindung zwischen zwei Stationen eingesetzt werden kann, wie etwa
einer Modemverbindung. Das Protokoll baut zwischen den beiden Stationen dabei eine Verbindung auf. Dieser Verbindungsaufbau gliedert sich in verschiedene Phasen wie in Abbildung 15.1
dargestellt.
Beim Aufbau der eigentlichen Verbindung auf der Datenverbindungsschicht (Establish) wird
ausgehandelt, ob und wie die (optionale) Authentikationsphase abluft. Dabei kann EAP fr
die Authentikationsphase gewhlt werden. EAP ist ein erweiterbares Protokoll, das mit vielen verschiedenen Authentikationsmechanismen verwendet werden kann. Wird EAP fr die
Authentikationsphase eingesetzt, so wird der spezische Authentikationsmechanismus erst in
UP
DEAD
FAIL
ESTABLISH
OPENED
FAIL
DOWN
TERMINATE
CLOSING
Abbildung 15.1: PPP-Phasen.
AUTHENTICATE
SUCCESS/
NONE
NETWORK
300

Byte
Bit
Code
Identifier
Length
Daten
Byte
Bit
Code
Type
Identifier
Length
Type-Daten
Abbildung 15.2: EAP-Rahmenformat.
der Authentikationsphase bestimmt. Falls die Authentikation erfolgreich ist, werden danach
die Netzwerkverbindungsparameter ausgehandelt und die Verbindung ist aktiv, ansonsten wird
die Verbindung abgebrochen.
EAP arbeitet direkt auf der Datenverbindungsschicht, bentigt also keine Netzwerkschichtprotokolle wie etwa IP. Es wurde ursprnglich fr den Einsatz bei Punkt-zu-Punkt-Verbindungen
entwickelt, kann und wird mittlerweile aber auch in Verbindung mit Ethernet und Wireless Local
Area Networks verwendet (siehe folgende Sektion).
EAP ist auerordentlich exibel, einfach strukturiert und untersttzt eine Vielzahl von Authentikationsmechanismen. Diese Mechanismen mssen nicht Teil der EAP-Spezikation sein
und knnen in anderen Dokumenten deniert sein, wie dies etwa fr EAP-TLS [RFC 2716] der
Fall ist. Auch neu entwickelte Authentikationsmechanismen knnen so ber EAP durchgefhrt
werden.
EAP ist ein Lock-Step-Protokoll. Das bedeutet, zu jedem Zeitpunkt ist klar festgelegt, welche Station sendet und welche empfngt, und die Nachrichten werden seriell, also nacheinander
bertragen, niemals mehrere gleichzeitig.
15.1.2 Nachrichtenformat
Das EAP-Rahmenformat ist sehr einfach und aufgebaut wie in Abbildung 15.2 dargestellt.
Im Header jedes EAP-Rahmens sind folgende Felder enthalten:
Code (1 Byte): Code kann folgende Werte mit folgenden Bedeutungen annehmen:
1: Request
2: Response
3: Success
4: Failure
301
EAP folgt einem einfachen Request-Response-Schema. Um eine Authentikation durchzufhren, knnen whrend der Authentikation mehrere Request-Responses durchgefhrt
werden.
Identier (1 Byte): Wird verwendet, um Responses den zugehrigen Requests zuzuordnen
und erneute bertragungen des gleichen Rahmens zu erkennen. Eine Response verwendet
den gleichen Identier wie der Request selbst. Aufgrund der Lock-Step-Eigenschaft reicht
fr dieses Feld ein Byte aus, da zur Vermeidung von Verwechslungen die IDs nur zwischen
direkt aufeinanderfolgenden Request/Response-Paaren unterschiedlich sein mssen.
Length (2 Byte): Gibt die Lnge des EAP-Rahmens inklusive des Headers in Bytes an.
Danach folgen in Request/Response-Rahmen (Code 1 und 2) weitere Daten, whrend Rahmen
des Typs Success/Failure (3 und 4) mit diesem Feld abschlieen.
In Request/Response-Rahmen sind zwei weitere Felder deniert:
Type (1 Byte): Legt den Typ des EAP-Mechanismus fest. Dieses Feld ist unabhngig vom
konkreten Authentikationstyp immer vorhanden. Der Typ einer Response zu einem Request muss mit dem Typfeld des Requests bereinstimmen, sofern nicht angezeigt wird,
dass dieser Typ von Request fr die andere Station nicht akzeptabel oder nicht implementiert ist (NAK). Einige wichtige Typen sind:
1: Identity
2: Notication
3: NAK (wie oben erlutert nur in Responses zulssig)
4: MD5-Challenge
5: One Time Password
13: EAP-TLS
21: EAP-TTLS
25: PEAP
43: EAP-FAST
47: EAP-PSK
Type-Data (variable Lnge): Abhngig vom Typ des Request/Responses.

Innerhalb einer EAP-Authentikation knnen Request/Responses verschiedener Typen auftreten. So kann beispielsweise zunchst ein Request vom Typ Identify verwendet werden, um
Informationen ber die zu authentizierende Station zu erlangen, bevor dann ein konkreter Authentikationsmechanismus gewhlt wird. Generell kann das EAP-Protokoll eingesetzt werden,
ohne dass sich die teilnehmenden Stationen vor der Authentikation auf einen spezischen Authentikationsmechanismus einigen.
Der Ablauf einer EAP-Authentikation ist einfach strukturiert. Er besteht aus einer Folge von
zusammengehrigen Request/Response-Paaren, denen nach erfolgreicher Authentikation ein
Success folgt beziehungsweise ein Failure, falls die Authentikation fehlgeschlagen ist. Wir werden spter genauere Beispiele einer Authentikation vorstellen. Zunchst wollen wir aber einen
weiteren wichtigen Aspekt von EAP betrachten, nmlich die zugrundeliegende Architektur.
302

Authentication
Server
Netzwerk
Authenticator
zu authentifizierende
Verbindung
Supplikant
Abbildung 15.3: EAP-Architektur.
15.1.3 Architektur
In vielen Anwendungsfllen von EAP sind die Stationen, welche die Authentikation vornehmen wollen, mit beschrnkter Rechenleistung und Speicherkapazitt ausgestattet denken Sie
etwa an einen WLAN-Access-Point, eine Modembank oder einen Switch. Meistens sind von
diesen Gerten mehrere vorhanden, und es kommt hug vor, dass sich Stationen je nach Situation an verschiedenen dieser Gerte authentizieren mchten. Im Folgenden werden wir die
Station, welche sich authentizieren muss, als Supplikant bezeichnen und die Station, welche die
Authentikation verlangt, als Authenticator.
Es ist naheliegend und eine in der Praxis gngige Vorgehensweise, in solchen Fllen die notwendige Funktion durch Einsatz eines Servers und einer zentralen Datenbank mit den zur Authentikation notwendigen Daten zu zentralisieren. EAP untersttzt dies durch die Mglichkeit
der Verwendung eines Authentication Servers. Dies ist in Abbildung 15.3 dargestellt.
Wenn ein Authentication Server verwendet wird, arbeitet der Authenticator weitestgehend nur
als Relay-Station: Die vom Supplikant erhaltenen Authentikationsdaten werden an den Authentication Server zur Bearbeitung weitergeleitet und umgekehrt Nachrichten vom Authentication
Server an den Supplikant. Wenn der Authentication Server eine Entscheidung getroffen hat, ob
der Supplikant authentiziert werden konnte oder nicht, erhlt der Authenticator diese Nachricht
ebenfalls, leitet sie an den Supplikant weiter und setzt diese Entscheidung des Authentication
Servers um. Beispielsweise terminiert er die Verbindung im Falle einer nicht erfolgreichen Authentikation. Whrend EAP zwischen Supplikant und Authenticator auf der Datenverbindungsschicht abluft, sind Authenticator und Authentication Server in der Regel ber die Netzwerkschicht verbunden und verwenden ein Applikationsschichtprotokoll wie beispielsweise RADIUS
[RFC 2865] [RFC 3579].
303
Byte
Bit
Code
Identifier
Type = 13
Flags
TLS Message Length (Fortsetzung)
Length
TLS Message Length
TLS Daten
Abbildung 15.4: EAP-TLS-Rahmen.
15.1.4 Einige EAP-Typen im Detail

15.1.4.1 EAP-TLS
Das TLS-Protokoll [RFC 4346] hatten wir bereits in Kapitel 13.3.3 kennengelernt. Es kann ebenfalls in Verbindung mit EAP zur Authentikation eingesetzt werden. Der entsprechende EAPTyp wurde in [RFC 2716] speziziert. Im Wesentlichen wird dort beschrieben, wie die entsprechenden TLS-Pakete in den EAP-Rahmen eingebettet werden. Das Rahmenformat fr EAP-TLS
ist in Abbildung 15.4 dargestellt.
Code, Identier und Length sind bereits in Sektion 15.1.2 erklrt worden. Die anderen Felder
haben folgende Bedeutung:
Type (1 Byte): Hat fr EAP-TLS den Wert 13.
Flags (1 Byte): Enthlt drei Flags, nmlich
L: Lnge im Rahmen mitangegeben,
M: More Fragments (bei Fragmentierung des TLS-Pakets, gesetzt bei allen Fragmenten bis auf das letzte Fragment),
S: EAP-TLS Start.
Die anderen fnf Bits besitzen derzeit noch keine Bedeutung.
TLS Message Length (4 Byte): Lnge der TLS-Nachricht. Dieses Feld ist nur vorhanden,
wenn das L-Bit bei den Flags gesetzt ist.
TLS data (variable Lnge): Eigentliches TLS-Paket im TLS-Record-Format.
EAP-TLS ermglicht die Verwendung aller Leistungsmerkmale von TLS. Somit werden bei
TLS nicht nur Supplikant und Authenticator wechselseitig durch die Verwendung von Zertikaten authentiziert, sondern die Stationen knnen sich auch auf eine Verschlsselungstechnologie
einigen und einen Session Key fr die Verschlsselung austauschen.
Allerdings besitzt TLS bei der Verwendung zur Authentikation in Netzwerken einen entscheidenden Nachteil. Wie beschrieben basiert die Authentikation von Client und Server jeweils auf Zertikaten, andere Mechanismen sind nicht vorgesehen. TLS wurde entworfen fr
die Verwendung im WWW durch HTTPS (siehe Abschnitt 13.3.2). Daher ist in erster Linie die
Authentikation des Servers beim Client von Interesse und die Authentikation des Clients ist
optional, da sie in vielen Fllen nicht notwendig ist.
304
Im hier betrachteten Fall der Authentikation auf der Datenverbindungsschicht ist vor allen
Dingen eine Authentikation des Supplikants (synonym verwenden wir in den folgenden Betrachtungen den Begriff Client) beim Authenticator (synonym Server) erforderlich.
Um diese sicher durchfhren zu knnen, ist es ebenfalls notwendig, dass sich der Authenticator beim Supplikant authentiziert. Sonst knnte sich ein Angreifer als Netzwerkzugangspunkt
ausgeben und beispielsweise einen Man-in-the-Middle-Angriff durchfhren, was letztlich zur
Aushebelung des Sicherheitsmechanismus fhren wrde. Auch andere Angriffe wie das Injizieren von Malware wren dann mglich (siehe Abschnitt 10.6.2).
Insofern ist die Authentikation des Authenticator beim Supplikant wichtig. Aber es kommt
eben vor allem auf die Authentikation des Supplikants beim Authenticator, also dem Zugangspunkt zum Netz an. Diese kann jedoch bei TLS nur ber Zertikate erfolgen, was in der Praxis
zu erheblichen Problemen fhrt. Um alle Clients in einem Netzwerk mit Zertikaten auszustatten, ist eine beachtliche Infrastruktur notwendig, deren sicherer Betrieb erhebliche Ressourcen
bindet. Daher ist EAP-TLS nicht in allen Institutionen problemlos einsetzbar.
15.1.4.2 EAP-TTLS und PEAP

Diese Schwierigkeiten haben zur Entwicklung anderer Verfahren zur Authentikation auf der
Datenverbindungsschicht mit EAP gefhrt. Die Idee hinter diesen Verfahren ist ganz analog zu
der Vorgehensweise bei der Authentikation von Clients oder Benutzern bei der Verwendung
von HTTPS, wenn keine clientseitigen Zertikate vorhanden sind (siehe Abschnitt 13.3.4):
1. Verwende TLS zum Aufbau einer sicheren, verschlsselten Verbindung zwischen Client
und Server und zur Authentikation des Servers beim Client (ber ein Zertikat).
2. Fhre unter Verwendung eines anderen Authentikationsmechanismus ber die verschlsselte Verbindung eine Authentikation des Clients beim Server durch.
Diese Vorgehensweise kommt unter anderem in den Mechanismen EAP-Tunneled TLS Authentication Protocol (EAP-TTLS) [FBW07] und Protected Extensible Authentication Protocol
(PEAP) zum Einsatz [KPW02]. Sie erfordern serverseitig den Einsatz von Zertikaten, erlauben
aber danach eine groe Flexibilitt beim Einsatz von Mechanismen zur Client-Authentikation,
beispielsweise Passwrtern. PEAP ist aus einer Initiative einer Reihe groer Unternehmen im
IT-Bereich entstanden.
15.1.4.3 EAP-FAST
Schlussendlich knnen wir auf Zertikate auch serverseitig verzichten. Hierzu gibt es das Flexible Authentication via Secure Tuneling Extensible Authentication Protocol (EAP-FAST) wie
in [RFC 4851] speziziert. Im Gegensatz zu den oben skizzierten Protokollen EAP-TTLS und
PEAP erfolgt bei EAP-FAST die Server-Authentikation gegenber dem Client ber ein gemeinsames Geheimnis.
15.2 Zugangskontrolle in LANs
305

15.2.1 Einfhrung
Wir haben uns in den vorangegangenen Kapiteln mit Sicherheitsrisiken in Netzwerken und mit
Methoden, diese Risiken zu verringern, ausfhrlich auseinandergesetzt. Ein wichtiges Konzept
waren die in Kapitel 9 besprochenen Firewalls, welche eine Separierung des Intranets einer Institution vom Internet ermglichen.
Firewalls helfen jedoch nicht gegen Angreifer, die bereits physikalisch Zugang zum Intranet
erlangt haben. Mit anderen Worten kann ein Angreifer die Firewall aushebeln, wenn er sich direkt
Zugang zum Intranet verschaffen konnte.
Direkter Zugang zum Intranet ermglicht nicht nur ein wesentlich breiteres Spektrum an mglichen Angriffen, da der Schutz durch die Firewall entfllt, sondern ist fr die betroffenen Institutionen vor allen Dingen auch deshalb so bedrohlich, weil ber das Intranet meistens auch Zugriff
auf einige vertrauliche Daten, Informationen und Geschftsgeheimnisse mglich ist. Dieser Zugriff mag durch weitere Authentikationen geschtzt sein, aber eine erste wichtige Hrde hat der
Angreifer mit dem Zugang zum Intranet bereits genommen.
In vielen Institutionen ist es einem Angreifer nicht ohne weiteres mglich, Zugriff auf das Intranet zu erhalten. Die Zugangspunkte in das Netzwerk, beispielsweise ein Ethernet-Anschluss,
liegen hug in einem Bereich, dem Perimeter, der einer physischen Zugangskontrolle unterliegt, wie bei einem Betriebsgelnde, einem Gebude oder einem Serverraum. Mitarbeiter der
Institution mssen sich beim Betreten des Bereichs ausweisen, eine Zugangskarte besitzen oder
auch nur einen gewhnlichen Schlssel benutzen. Besucher mssen sich anmelden und drfen
sich nicht frei auf dem Gelnde oder im Gebude bewegen. Auch im privaten Bereich ist die
Wohnung gegen unbefugtes Betreten gesichert, was zwar in erster Linie Einbrecher abschrecken
soll, aber auch Hackern ihr ruchloses Tagewerk erschwert.
Dieses Konzept eines abgegrenzten, berwachten Bereichs wird Perimetersicherheit genannt.
Auf diese Weise kann der physische Zugang zur Infrastruktur erschwert oder ganz unterbunden
werden. Perimetersicherheit ist fr die Sicherheit der IT-Infrastruktur im Allgemeinen ausgesprochen wichtig und kann sogar auch aus Datenschutzgrnden gesetzlich vorgeschrieben sein. Da
wir uns in diesem Buch jedoch im Schwerpunkt mit informationstechnischen Fragen befassen,
wollen wir dieses Thema nicht weiter vertiefen.
Fast alle Institutionen besitzen die eine oder andere Art von Perimetersicherheit. Doch es ist
fraglich, inwieweit solche Methoden fr einen wirkungsvollen Schutz ausreichen. Daher bietet
es sich an, zustzlich auf informationstechnischem Weg eine Zugangskontrolle zum lokalen Netz
zu implementieren.
15.2.2 Ungesicherte lokale Netze

Doch zunchst wollen wir analysieren, welche Hrden ein Angreifer sonst noch berwinden
muss, um sich Zugang zum Netzwerk zu verschaffen, wenn er seinen Rechner bereits an ein
ansonsten ungesichertes LAN anschlieen konnte, beispielsweise ber eine offene Ethernetanschlussdose in einem ungesicherten Bereich.
306
Mit der Ethernetverbindung allein ist Kommunikation mit anderen Rechnern nur sehr eingeschrnkt mglich, solange die Netzwerkkonguration auf der Netzwerkschicht, sprich die fr
die Funktion des IP-Protokolls notwendigen Einstellungen nicht erfolgt sind. Wie bereits aus
Abschnitt 7.3.3.4 bekannt, werden hierzu fr ein Endsystem zumindest die eigene IP-Adresse,
die Subnetzmaske und die IP-Adresse des Default-Gateway bentigt.
Besonders einfach macht man es einem Angreifer, wenn im Netz ein DHCP-Server betrieben
wird, der dem Angreifer bereitwillig eine IP-Adresse zuteilt und die anderen notwendigen Daten
bermittelt. Es gibt bei vielen DHCP-Servern die Mglichkeit, die Erteilung einer IP-Adresse an
bestimmte MAC-Adressen zu koppeln. Dies kann einem Angreifer die Arbeit zumindest etwas
erschweren, doch nicht fr lange Zeit. Wenn ein DCHP-Server vorhanden ist, der dem Angreifer
keine Adresse zuweist, oder aber gar kein DHCP-Server betrieben wird, muss der Angreifer den
Adressraum des Netzwerks eben allein ermitteln und sich dann selbst eine ungenutzte IP-Adresse
in diesem Adressraum zuweisen. Da zum Betrieb eines Netzes und bestimmter Anwendungen
eine ganze Reihe von Broadcast-Paketen, also Paketen, die an allen Ports des Netzwerks empfangen werden knnen, notwendig sind, ist es nicht schwer oder zeitaufwendig, den IP-Adressraum
zunchst einzugrenzen und sich dann durch gezieltes Ausprobieren weiter vorzutasten. Auf diese
Weise kann diese Hrde in verhltnismig kurzer Zeit und mit geringem Aufwand genommen
werden. Danach besitzt der Angreifer vollen Zugriff auf das Netzwerk.
15.2.3 IEEE 802.1X Port-based Access Control

15.2.3.1 Funktionsweise
Es ist naheliegend, die einzelnen Zugangspunkte zum Netzwerk fr eine informationstechnisch
realisierte Zugangskontrolle zu verwenden. Hierzu wurde der IEEE 802.1X-Standard entworfen
[IEEE 802.1X]. IEEE 802.1X funktioniert im Zusammenspiel mit verschiedenen Datenverbindungsschichten der IEEE 802-Serie, darunter auch Ethernet (IEEE 802.3). Ebenso bildet IEEE
802.1X die Grundlage fr die in IEEE 802.11i spezizierten Zugangskontrollmechanismen in
WLAN-Netzwerken nach dem IEEE 802.11-Standard [IEEE 802.11].
Wie in Abbildung 15.5 gezeigt, unterscheidet IEEE 802.1X zwischen den Rollen Supplikant,
Authenticator und Authentication Server, die wir bereits bei EAP kennengelernt hatten. Im Standard IEEE 802.1X werden die Zugangspunkte im Netzwerk als Ports bezeichnet. Diese Ports
haben nichts mit den bei TCP und UDP verwendeten Ports und Portnummern zu tun. Unter
einem Port im Sinne des 802.1X-Standards versteht man einen Anschlusspunkt in einem LANNetzwerk. Dieser Anschlusspunkt kann sowohl physikalisch (einzelnes Ethernetinterface an einem Switch oder PC) als auch logisch (wie bei WLANs) sein. Hat ein Switch beispielsweise
24 Ethernet-Interfaces (Ports), so kann jedes Interface einzeln und unabhngig von den anderen
Interfaces der Zugangskontrolle unterworfen werden.
Konzeptionell trennt IEEE 802.1X den Port des Authenticators in zwei logische Ports auf,
nmlich einen kontrollierten Port (controlled Port), der je nach Authentikationsstatus freigeschaltet oder gesperrt sein kann, und einen unkontrollierten Port (uncontrolled Port), auf dem
ausschlielich die Authentikation des Systems erfolgen kann. Bei erfolgreicher Authentikation wird der kontrollierte Port freigeschaltet. Dies ist in Abbildung 15.6 dargestellt.
307
Authentication
Server
Port
Netzwerk
Supplikant
Authenticator
Abbildung 15.5: Rollen und Funktion bei IEEE 802.1X.

Authenticator
Uncontrolled Port
Controlled Port
Controlled Port wird erst nach
erfolgreicher Authentifikation
eingeschaltet
LAN
Abbildung 15.6: IEEE 802.1X Controlled und Uncontrolled Port.
IEEE 802.1X kann nicht nur in eine Richtung zur Authentikation verwendet werden, sondern zwei Systeme knnen sich auch wechselseitig authentizieren. Dies ist unter anderem notwendig, da in LANs nicht nur Endsysteme und Switches verbunden sein knnen, sondern auch
Switches untereinander. Jeder Switch tritt dann sowohl in die Rolle des Supplikants als auch in
die Rolle des Authenticators, das heit er authentiziert den anderen Switch so wie oben dargestellt und gleichzeitig authentiziert er sich beim anderen Switch. Dies ist in Abbildung 15.7
dargestellt. Die Authentikation in den beiden Richtungen erfolgt vollkommen unabhngig voneinander. Es knnen beispielsweise auch verschiedene Authentication Server von den beiden
Authenticators eingesetzt werden.
Authenticator
Controlled Port
Authenticator
Uncontrolled Port
Controlled Port
Uncontrolled Port
LAN
Abbildung 15.7: Wechselseitige Authentikation mit IEEE 802.1X.
308

Authentication
Server
authentifiziert
C
Netzwerk
nicht authentifizierte Verbindung

nicht authentifizierte Maschine hat Zugriff
auf das Netzwerk
Abbildung 15.8: Unauthentizierte Gerte in IEEE 802.1X-geschtzten Netzen.
Das Konzept von IEEE 802.1X basiert auf dem Freischalten bzw. Sperren der Ports. Im Gegensatz zu anderen Mechanismen, die wir bereits betrachtet haben, gibt es nach einer Freischaltung
eines Ports keine Beschrnkungen hinsichtlich der Frames, die an diesem Port entgegengenommen werden. Dies bedeutet insbesondere, dass die auf dem Port eingehenden Frames nicht weiter
dahingehend berprft werden, von wem sie stammen oder wohin sie befrdert werden. Insbesondere mssen die Frames nicht unmittelbar von den Netzwerkgert stammen, das sich auch
authentiziert hat, sondern die befrderten Frames knnen beliebige MAC-Adressen als Sender
oder Empfnger enthalten. Dies ist notwendig, da es in LANs Verbindungen gibt, ber die Frames befrdert werden, die nicht direkt an die Gerte gerichtet sind, die sich am jeweiligen Port
benden, beispielsweise zwischen zwei Switches.
Dieses Verhalten ist in einigen Situationen problematisch, da nicht mit Sicherheit ausgeschlossen werden kann, dass es Gerte im Netz gibt, die nicht authentiziert wurden. Ein Beispiel fr
eine solche Situation ist in Abbildung 15.8 dargestellt. Client C ist direkt mit einem Port von
Switch B verbunden und hat sich dort entsprechend authentiziert. Er verfgt aber noch ber
ein anderes Netzwerkinterface, ber das er mit A verbunden ist und an dem keine Authentikation durchgefhrt wird. C ist als Router bzw. Bridge konguriert und forwarded Frames von
A an B. In diesem Fall ist also A ber C mit dem Netzwerk verbunden, ohne sich authentiziert zu haben. hnliche Probleme treten auch auf, wenn mehrere Gerte ber einen Hub oder
kleinen Switch mit dem Netzwerk verbunden sind. Die im IEEE 802.1X-Standard skizzierten
Mechanismen allein greifen in solchen Situationen nicht. Die Entwickler des Standards waren
sich dieser Einschrnkungen durchaus bewusst: Es wird im Standard explizit eine Punkt-zuPunkt-Verbindungscharakteristik des LANs gefordert, in dem IEEE 802.1X eingesetzt wird.
15.2.3.2 Authentikation
Die Authentikation mit IEEE 802.1X erfolgt im Wesentlichen mit EAP. Daher entspricht im
Groen und Ganzen die Vorgehensweise der bei EAP aus Abschnitt 15.1.3. Das zu authentizierende System, der Supplikant, authentiziert sich beim Authenticator, der die Authentikation
309
Supplikant
Authentication
Server
Authenticator
EAPOL
ntit
EAP Request Ide
EAP Response Ide

ntit
RADIUS
y
y (Machine A)
Zeit
EAP Response Ide

ntit
allenge)
e Time Passwd (Ch
EAP Request On
EAP Response On
e Time Passwd (Re
sponse)
y (Machine A)
allenge)
e Time Passwd (Ch
EAP Request On
EAP Response On
e
Time Passwd (Re

spo
nse)
EAP Success
EAP Success
Abbildung 15.9: Beispielhafter Ablauf einer Authentikation unter IEEE 802.1X.
nicht selbst vornehmen muss, sondern an einen Authentication Server irgendwo in Netzwerk delegieren kann. Dies ist in Abbildung 15.5 skizziert. IEEE 802.1X verwendet zur Authentikation
EAP. Hierzu wurden EAP-over-LAN-Frameformate (EAPOL-Frameformate) deniert, die beschreiben, wie EAP-Informationen direkt in Rahmen der Datenverbindungsschicht transportiert
werden knnen. Der Authenticator empfngt die Rahmen und leitet sie an den Authentication
Server weiter. Die entsprechenden EAP-Pakete werden vom Authenticator zum Authentication
Server (und umgekehrt) ber ein Protokoll einer hheren Schicht wie beispielsweise RADIUS
[RFC 3579] versendet.
Ein typischer Ablauf einer Authentikation ist in Abbildung 15.9 skizziert. Das Beispiel
stammt aus dem IEEE 802.1X-Standard [IEEE 802.1X]. Der Authenticator fragt zunchst via
EAPOL den Supplikant nach seiner Identitt. Die Antwort des Supplikants (wieder ber EAP)
erfolgt an den Authenticator, der diese Antwort an den Authentication Server weiterleitet, im
dargestellten Fall ber RADIUS. Der Authentication Server kann dann anhand der Identitt des
Supplikants das zu verwendende Authentikationsverfahren auswhlen und die Authentikation durchfhren. In der Abbildung erfolgt diese ber ein Passwort im Challenge-ResponseVerfahren. Wenn der Authentication Server den Supplikant erfolgreich authentizieren kann,
schaltet der Authenticator den Port frei. Die im Einzelnen zu verwendenden Authentikationsmechanismen sind durch den Standard nicht vorgeschrieben und knnen unterschiedlich ausgeprgt sein.
310
15.3 Sicherheit in WLANs

15.3.1 Eine kurze Einfhrung in IEEE 802.11
Drahtlose lokale Netze, sogenannte Wireless Local Area Networks (WLANs), haben in den letzten Jahren Verbreitung im privaten Bereich und in Institutionen gefunden. Im Markt hat sich
dabei der IEEE 802.11-Standard [IEEE 802.11] durchgesetzt. Wie der Werbeslogan drahtloses Ethernet suggeriert, funktioniert IEEE 802.11 aus Sicht eines Benutzers hnlich wie die
bekannte Ethernet-Technologie, nur eben drahtlos. Der IEEE 802.11-Standard gehrt in die gleiche Standardgruppe (IEEE 802) wie Ethernet (IEEE 802.3). Daher ist es sehr einfach, beide
Technologien innerhalb eines LANs miteinander zu kombinieren (siehe Sektion 11.2.4).
Aus der Perspektive eines Anwenders gibt es nur wenige Unterschiede zwischen der Verwendung eines IEEE 802.11-WLANs und Ethernet. Wenn man die Standards jedoch aus technischer Sicht vergleicht, gibt es enorme Unterschiede. So sind die in einem WLAN notwendigen Managementfunktionen wesentlich komplexer als bei gewhnlichen drahtgebundenen LANTechnologien. Fr IEEE 802.11 wurden eine ganze Reihe verschiedener physikalischer bertragungstechnologien speziziert, die sich hinsichtlich der maximal mglichen Datenrate, des verwendeten Frequenzbands und der Modulation unterscheiden. Alle physikalischen bertragungstechnologien verwenden jedoch die gleiche Datenverbindungsschicht, welche wir im Folgenden
hinsichtlich ihrer Sicherheitseigenschaften nher untersuchen werden.
IEEE 802.11 bietet zwei verschiedene Operationsmodi an, nmlich den Infrastrukturmodus
und den Ad-Hoc-Modus. Wir werden uns im Folgenden auf eine Diskussion des Infrastrukturmodus beschrnken, da Ad-Hoc-Netze bisher zwar reges akademisches Interesse ausgelst haben,
in der Praxis aber noch nicht von Bedeutung sind.
Vereinfacht ausgedrckt bedeutet Infrastrukturmodus, dass im drahtlosen Netzwerk ein AccessPoint vorhanden ist, der die Managementaufgaben im Netzwerk bernimmt und das drahtlose
Netz mit anderen (nicht-drahtlosen) Netzen wie dem Internet und anderen Access-Points ber
das sogenannte Distribution System verbindet. Der Access-Point arbeitet als Bridge zwischen
dem drahtlosen und dem drahtgebundenen Netz. Die einzelnen Teilnehmer im Netz bezeichnen wir als Stationen. Stationen, die ber das drahtlose Netz kommunizieren wollen, mssen
sich beim Access-Point anmelden (assoziieren). Der Access-Point und alle mit ihm assoziierten Stationen bilden ein sogenanntes Basic Service Set (BSS). In einem BSS kommuniziert jede
Station (fast) ausschlielich mit dem Access-Point. Da die Reichweite eines Access-Points beschrnkt ist (maximal ungefhr 50 bis zu 300 Meter je nach Umgebung und den verwendeten
Funkfrequenzen), mssen in einigen Institutionen mehrere Access-Points betrieben werden, um
das gesamte Firmengelnde oder Gebude mit dem drahtlosen LAN zu versorgen. Sind diese
Access-Points durch ein Distribution System verbunden, so bilden sie ein Extended Basic Service Set (EBSS) und es ist mglich, zwischen verschiedenen Access-Points zu wechseln, ohne
dass die Verbindung zum Netz dadurch unterbrochen wird. In der Praxis wird das Distribution
System meistens durch eine (einfache) Ethernet-Infrastruktur gebildet. Abbildung 15.10 zeigt
ein einfaches WLAN.
311
LAN (Distribution System)
AP
AP
Basic Service Sets
AP
Extended Basic Service Set
Abbildung 15.10: IEEE 802.11-Netzwerk mit Distribution System.
15.3.2 Sicherheit drahtloser LANs

Um sich ber ein drahtgebundenes LAN mit einem Netzwerk zu verbinden, ist es notwendig, sich
physisch Zugang zu einem Netzwerkanschluss wie einer Ethernetanschlussdose, einem Switch
oder einem anderen Rechner, der bereits mit dem LAN verbunden ist, zu verschaffen. Drahtlose
Signale enden nicht abrupt an einer Wohnungstr oder einem Broausgang, sondern sind auch
auerhalb des geschtzten Bereichs zu empfangen. Genauso lassen sich Signale, die von auen
nach innen gesendet werden, nur schwer aufhalten. Wenn das Signal eines drahtlosen LANs auch
in einem ffentlich zugnglichen Bereich empfangbar ist, kann ein Angreifer aus diesem Bereich
heraus einen Angriff starten.
Diese Mglichkeit ist als Parking-Lot-Scenario bekannt. Der Angreifer sitzt in einem Auto auf
einem ffentlich zugnglichen Parkplatz etwa vor einem Brogebude, und greift von dort aus
das WLAN an. Durch Verwendungen entsprechender Antennen kann ein solcher Angriff auch
aus einer gewissen Entfernung heraus durchgefhrt werden. Von dort aus kann der Angreifer
entweder passiv mithren, was in dem WLAN bertragen wird, oder er kann sich durch einen
aktiven Angriff mglicherweise Zugang zum Intranet ber das WLAN verschaffen. Aufgrund der
fehlenden Perimetersicherheit ist es sehr viel schwieriger, nach der Entdeckung eines Angriffs
mgliche Verdchtige zu ermitteln, so dass ein derartiger Angriff fr den Angreifer ein geringeres
Risiko darstellt. Es gibt sogar Hacker, die auf der Suche nach einfach anzugreifenden WLANs
durch die Gegend fahren und ihr Unwesen treiben (War Driving).
Auch das Betreiben eines Access-Points durch einen Angreifer (Rogue-Access-Point) und
Man-in-the-Middle-Angriffe sind in WLANs mglich. Es gibt verschiedenste Angriffsszenarien.
Ein Angreifer kann beispielsweise einen Rogue-Access-Point betreiben, der fr die Benutzer genauso konguriert zu sein scheint wie ihr regulrer Access-Point, den sie tagtglich verwenden.
312
Daher verbinden sie sich (oder werden sogar durch Voreinstellungen automatisch verbunden) mit
dem vom Angreifer betriebenen Access-Point. Dieser leitet die Daten ber den regulren AccessPoint weiter, so dass der Benutzer keinen Unterschied bemerkt. Tatschlich kann der Angreifer
aber auf diese Weise Malware auf der verbundenen Station einschleusen (siehe Abschnitt 10.6.2)
oder in einigen Fllen Verschlsselungsmechanismen geschickt aushebeln.
Aufgrund der fehlenden Perimetersicherheit sind drahtlose LANs also sowohl gegenber aktiven als auch gegenber passiven Angriffen besonders exponiert. Wenden wir uns nun der Frage
zu, wie solche Netze abgesichert werden knnen und welche Mechanismen die IEEE 802.11Spezikation hierfr vorsieht.
15.3.3 Schwachstellen im ursprnglichen IEEE 802.11-Standard

Der vom IEEE ursprnglich verabschiedete Standard enthielt eine Reihe von Sicherheitsmechanismen, die sich sehr schnell als untauglich und mit vielen kritischen Schwachstellen behaftet herausgestellt haben. Daher wurde vom IEEE mittlerweile ein Zusatz zum Standard, IEEE
802.11i [IEEE 802.11i], verabschiedet, in dem vollstndig neue Sicherheitsmechanismen speziziert wurden. Bisher sind in dieser neuen Spezikation keine sicherheitskritischen Schwachstellen aufgedeckt worden. Neuere WLAN-Produkte implementieren diese neuen Mechanismen, so
dass die Schwachstellen des alten Standards in der Praxis nicht mehr unmittelbar relevant sind.
Aus den Fehlern des Standards kann man jedoch auch heute noch einiges darber lernen,
wie komplex der Entwurf eines (halbwegs) sicheren Systems sein kann. Daher wollen wir diese
Fehler nun unter die Lupe nehmen.
Beginnen wir mit der Authentikation von Stationen. In einem infrastrukturbasierten WLANNetz erfolgt die Authentikation zwischen den Stationen und dem Access-Point. IEEE 802.11
speziziert zwei mgliche Authentikationsmechanismen, nmlich Open System Authentication
und Shared Key Authentication.
Open System Authentication ist ein schner Euphemismus dafr, dass keinerlei Authentikation der Stationen erfolgt, und war als Standardeinstellung eines IEEE 802.11-Netzes vorgesehen.
Wenn keine zustzlichen Zugangskontrollmechanismen angewendet werden, kann jede beliebige Station das WLAN-Netzwerk benutzen. In einigen Fllen mag dies tatschlich gewnscht
sein, beispielsweise bei einem ffentlich zugnglichen WLAN in einem Cafe, Bahnhof oder am
Flughafen. Fr ein WLAN im Intranet einer Firma aber ist diese Einstellung auerordentlich
gefhrlich, sofern keine weiteren Schutzmanahmen gegen die unbefugte Benutzung des drahtlosen Netzes getroffen wurden, beispielsweise durch ein VPN. Wir werden auf dieses Thema
spter zurckkommen.
Bei Shared Key Authentication kommt zur Authentikation ein symmetrischer kryptographischer Schlssel zum Einsatz, der sogenannte WEP-Key. Der WEP-Key wird nicht nur zur Authentikation verwendet, sondern auch fr das zur Sicherstellung der Vertraulichkeit im IEEE
802.11-Standard vorgesehene Verschlsselungsverfahren WEP (dies steht fr Wired Equivalent
Privacy). Wir hatten bereits in Abschnitt 3.6.1 gesehen, wie ein symmetrischer kryptographischer
Schlssel zur Authentikation von Kommunikationspartnern verwendet werden kann.
Der WEP-Key ist ebenfalls Grundlage des im IEEE 802.11-Standard spezizierten WEPVerschlsselungsverfahrens. WEP basiert auf der Verwendung einer pseudozuflligen Bitfolge
313
zur Verschlsselung der Frames via bitweiser XOR-Verknpfung wie in Abschnitt 2.4.3 skizziert. Diese wird mittels des RC4-Algorithmus aus dem WEP-Key und einer weiteren (zufllig
gewhlten) Bitfolge, dem Initialization Vector (IV), erzeugt. Der Initialization Vector wird bei
jedem Frame im Klartext mit bertragen, so dass der Empfnger des Frames mit dem bertragenen Initialization Vector und dem (geheimen) WEP-Schlssel dieselbe pseudozufllige Bitfolge erzeugen und so den Frame wieder entschlsseln kann. Die Verschlsselung umfasst nur
die Nutzlast des Frames, der Header wird nicht verschlsselt. Durch die bertragung des Initialization Vectors wird sichergestellt, dass die Entschlsselung eines Frames unabhngig von
vorher empfangenen Frames mglich ist (Selbstsynchronitt). Neben der Verschlsselung beinhaltet WEP ebenfalls eine Integrittskontrolle fr die versendeten Daten durch bertragung einer
Prfsumme.
Der WEP-Algorithmus selbst hat sich durch vielerlei Designfehler und Schwachstellen als
unsicher erwiesen. So ist die Integrittskontrolle nur mangelhaft und kann ausgehebelt werden.
Darber hinaus enthlt WEP keinerlei Schutz gegen Replays durch einen Angreifer. Das Todesurteil fr WEP war jedoch eine im RC4-Algorithmus entdeckte inhrente Schwche, die es
einem Angreifer ermglicht, durch kontinuierliche Beobachtung von bertragungen den WEPKey zu rekonstruieren selbst fr Schlssel mit einer Lnge von 128 Bit. Mittlerweile sind Tools
verfgbar, die diese Schwachstelle nutzen und die WEP-Verschlsselung in kurzer Zeit brechen.
Der WEP-Mechanismus hatte jedoch noch eine weitere schwerwiegende Schwachstelle, nmlich seine Handhabbarkeit. In den meisten Implementierungen von WEP war fr alle Stationen
im Netz die Verwendung eines einzigen WEP-Keys vorgesehen. Jede Station verwendete also
denselben Schlssel zur Authentikation, Verschlsselung und Entschlsselung (dies liefert fr
den Begriff shared key ganz neue Interpretationsmglichkeiten). Konsequenterweise konnte
also jede Station die bertragungen jeder anderen Station im Netz entschlsseln und mitlesen.
Whrend dies aus der Sicherheitsperspektive vielleicht nicht unbedingt eine gute Entscheidung
ist, entspricht es doch der grundlegenden Funktionsweise eines (nicht geswitchten) BroadcastMediums, wie es vom Prinzip her Ethernet schlielich auch ist.
Das eigentliche Problem liegt darin, dass IEEE 802.11 nicht speziziert, wie der WEP-Key zu
den jeweiligen Stationen gelangt. Dies schafft beim Management des drahtlosen Netzes, gerade
in greren Institutionen, schwerwiegende Probleme. Gibt man den Schlssel an die einzelnen
Institutionsmitglieder weiter, so ist die Vertraulichkeit nicht unbedingt gesichert. In der Praxis
haben daher meistens die Systemadministratoren den WEP-Key in die Rechner mit WLANVerbindung eingegeben. Doch wie ist zu verfahren, wenn ein Mitarbeiter die Institution (zwangsweise) verlsst? Im Prinzip wrde dies die nderung des gemeinsamen WEP-Keys erforderlich
machen, doch da dieser ja von Hand eingegeben werden muss, ist dies praktisch kaum oder
nur schwierig durchfhrbar. Systemadministratoren haben am Administrieren von WLANs mit
WEP-Verschlsselung daher keine besondere Freude gehabt.
15.3.4 IEEE 802.11i

Es ist also nur wenig verwunderlich, dass aufgrund der oben skizzierten Schwierigkeiten und
Schwachstellen dem Standard mittlerweile vollstndig neue Sicherheitsmechanismen hinzugefgt wurden. IEEE 802.11i [IEEE 802.11i] speziziert die sogenannte Robust Security Network
Association (RSNA).
314

RSNA
Authentifikation, Management
IEEE 802.1X
Pre-Shared Key
beide erlauben das Ableiten von Session Keys
Vertraulichkeit, Integritt
CCMP
TKIP
- basiert auf AES - basiert auf WEP
- basiert auf CCM - bergangslsung
- beinhaltet Schwachstellen
Abbildung 15.11: Komponenten der Robust Security Network Association.
Die Robust Security Network Association umfasst zwei Protokolle, die Vertraulichkeit und
Integritt schtzen sollen und WEP ersetzen, zum einen das Temporal Key Integrity Protocol
(TKIP) und zum anderen das Counter Mode with Cipher Block Chaining with Message Authentication Code Protocol (CCMP). Auerdem beinhaltet die RSNA-Spezikation Methoden zum
Auf- und Abbau einer RSNA und Verfahren, mit denen kryptographische Schlssel zwischen
Stationen sicher ausgetauscht werden knnen. Im Infrastrukturmodus basiert die Authentikation beim Aufbau der RSNA entweder auf einem bereits bestehenden gemeinsamen Schlssel
oder auf der Verwendung des oben beschriebenen IEEE 802.1X-Standards, wobei jede Station
an einem eigenen (logischen) Port betrieben wird. Abbildung 15.11 zeigt die Komponenten einer
RSNA im berblick.
Beginnen wir mit den beiden Verfahren zum Ersatz von WEP. TKIP basiert auf WEP und ist
als temporre Lsung zum Einsatz auf lterer Hardware gedacht, die CCMP nicht verwenden
kann, da AES nicht untersttzt wird. Es kann die prinzipiellen Probleme mit WEP nicht beseitigen, aber doch lindern. Das Protokoll verfgt jedoch ber verbesserte Integrittskontrolle durch
Verwendung eines verbesserten Message Integrity Codes (MIC). Aufgrund der Beschrnkung auf
das vorhandene WEP-Verfahren kann MIC das Flschen von Nachrichten nicht vollstndig verhindern, weshalb TKIP Gegenmanahmen beinhaltet, die eingeleitet werden mssen, wenn ein
Frame mit falscher MIC empfangen wird. Auerdem enthlt TKIP einen Zhler zur Verhinderung von Replays, den TKIP Sequence Counter (TSC). TKIP entschrft die Probleme mit WEPVerschlsselung, indem fr die Verschlsselung aus dem TSC und einem temporren Schlssel
ein WEP-Key erzeugt wird, der dann zur Verschlsselung verwendet wird. Daher nden also in
der Regel nur wenige bertragungen mit dem gleichen WEP-Schlssel statt.
CCMP ist ein von WEP unabhngiges Verfahren, das auf AES als Verschlsselungsverfahren [FIPS 197] basiert. Als Cipher Mode wird das in [RFC 3610] beschriebene Verfahren CCM
(Counter with Cipher Block Chaining with Message Authentication) verwendet, auf das wir hier
nicht nher eingehen wollen. CCMP schtzt aus heutiger Sicht zuverlssig Vertraulichkeit und
Integritt der bertragenen Frames. Ebenso knnen Replays erkannt werden. Seit einiger Zeit ist
ausschlielich Hardware erhltlich, die CCMP untersttzt. Somit wird in naher Zukunft nur noch
CCMP zum Einsatz kommen.
315
Die Wi-Fi Alliance, ein Industriekonsortium zur Frderung der Kompatibilitt von IEEE 802.11Produkten verschiedener Hersteller, hat unter dem Namen Wi-Fi Protected Access (WPA) und
WPA2 Teile des IEEE 802.11i-Standards ausgewhlt und zertiziert Produkte auf die Interoperabilitt hinsichtlich dieser spezizierten Teile. Vereinfacht ausgedrckt entspricht WPA im Wesentlichen TKIP, whrend WPA2 CCMP umfasst.
Der Aufbau einer RSNA kann in infrastrukturbasierten WLANs auf zwei Arten erfolgen, nmlich entweder
unter Verwendung eines bereits bestehenden gemeinsamen Schlssels, des Pre-SharedKeys (PSK), oder
durch Verwendung von IEEE 802.1X. Als Authentikationsmechanismen in Verbindung
mit IEEE 802.1X kommen derzeit im institutionellen Umfeld vor allen Dingen EAP-TLS,
PEAP und EAP-FAST zum Einsatz.
In beiden Fllen wird whrend des Aufbaus der RSNA ein symmetrischer kryptographischer
Schlssel ausgehandelt, der spter zur Verschlsselung verwendet wird. Die Verwendung eines
PSK bietet sich in sehr kleinen Netzwerken an (etwa im privaten Bereich), wo der Betrieb eines
fr IEEE 802.1X erforderlichen Authentication Servers zu aufwendig ist.
Zusammenfassend sind durch IEEE 802.11i die Schwachstellen im ursprnglichen Standard
zufriedenstellend geschlossen worden.
15.3.5 VPN-basierter Zugriff auf drahtlose LANs

Es gibt noch eine weitere Mglichkeit, drahtlose Netzwerke zu schtzen, nmlich die Verwendung der in Kapitel 10 ausfhrlich vorgestellten VPNs.
Wenn man mittels eines VPNs den Zugriff auf das Intranet von beliebigen unsicheren Netzen
aus realisieren kann, liegt der Gedanke nahe, dass man mittels der gleichen Technologie auch
sicheren Zugriff auf das Intranet von einem drahtlosen LAN aus bewerkstelligen kann.
Die Idee der Verwendung eines VPNs zur Absicherung des WLANs ist in Abbildung 15.12
skizziert. Das WLAN selbst kann in diesem Fall als Open System betrieben werden, beliebige
Stationen knnen sich also mit den Access-Points assoziieren. Damit ist zwar die Verbindung
aus der Perspektive der Datenverbindungsschicht erfolgreich zustande gekommen, die Station
hat damit jedoch nur Zugang zu einem ungesicherten LAN-Bereich erhalten, von dem aus kein
direkter Zugriff auf das Intranet mglich ist. Dies ist nur ber einen VPN-Server mglich. Die
Station muss sich also, um Zugriff auf das LAN zu erhalten, beim VPN-Server authentizieren.
Dabei wird dann ein verschlsselter Tunnel zwischen der Station und dem Server aufgebaut,
ber den dann die gesamte Kommunikation erfolgt. Da die kryptographischen Schlssel fr die
Verbindung jeder Station zum VPN-Server individuell sind, ist der Verkehr der so verbundenen
Stationen hinsichtlich Vertraulichkeit und Integritt geschtzt.
Diese Lsung wurde in Institutionen vielfach eingesetzt, um vor der Verabschiedung von IEEE
802.11i WLANs sicher einsetzen zu knnen. Es ist ein schnes Beispiel dafr, wie Sicherheitsmechanismen bei einer sinnvoll gewhlten Architektur von der Datenverbindungsschicht auf die
Netzwerkschicht verlagert werden knnen.
316

VPN-Server
VPN-Tunnel zum
VPN-Server
Intranet
AP
unsicheres LAN
AP
Abbildung 15.12: Verwendung eines VPNs zur Absicherung einer WLAN-Infrastruktur.
Auch auf der Datenverbindungsschicht sind Manahmen zum Schutz der ITSicherheit in vielen Fllen unerlsslich. Das Extensible Authentication Protocol ist
ein sehr exibles Protokoll zur Authentikation und Aushandlung von kryptographischen Mechanismen, das ursprnglich fr PPP entwickelt wurde, aber mittlerweile
auch in drahtlosen und drahtgebundenen Local Area Networks zum Einsatz kommt.
Die sich authentizierende Station, der Supplikant, authentiziert sich beim Authenticator, beispielsweise einem Modem oder anderen Netzwerkzugangspunkt. Dabei kann
der Authenticator die Authentikation nicht nur selbst durchfhren, sondern hierfr
einen Authentication Server verwenden, der sich irgendwo im Netz benden kann.
Damit erlaubt EAP die Zentralisierung der Authentikationsfunktionen. EAP erlaubt
die Verwendung vieler verschiedener Authentikationsmechanismen.
Auch fr Local Area Networks ist Zugangskontrolle und Authentikation wichtig.
Ohne solche Mechanismen hat ein Angreifer in kurzer Zeit vollen Zugriff auf das
Netzwerk, wenn er sich physikalischen Zugang zum Local Area Network verschafft
hat. IEEE 802.1X ist der IEEE-Standard fr Zugangskontrolle auf der Datenverbindungsschicht. IEEE 802.1X kontrolliert sogenannte Ports. Dies knnen echte Zugangspunkte wie Ports auf einem Ethernet-Switch sein, aber auch logische Ports wie
bei IEEE 802.11-WLANs. Der Port wird logisch in zwei Teile gespalten, den uncontrolled Port, ber den ausschlielich die Authentikation abgewickelt wird, und
den controlled Port, der erst nach erfolgreicher Authentikation geffnet wird. IEEE
802.1X verwendet im Wesentlichen EAP als Authentikationsprotokoll.
15.5 bungsaufgaben
317
Fr drahtlose lokale Netze sind Zugriffskontrolle und Verschlsselung noch wichtiger als fr gewhnliche lokale Netzwerke, da die Signale eines drahtlosen Netzes
hug auch in ffentlichen Bereichen zu empfangen sind und dadurch die normalerweise gegebene Perimetersicherkeit in einer Institution oder im privaten Bereich
ausgehebelt wird. Der ursprngliche IEEE 802.11-Standard wies schwerwiegende Sicherheitsmngel auf und wurde deshalb grundlegend berarbeitet und durch den Sicherheitsstandard IEEE 802.11i ergnzt.
Drahtlose Netze nach diesem Standard, der auch als WiFi Protected Access bezeichnet
wird, verwenden zur Authentikation und Aushandlung der Verschlsselungsmechanismen im Wesentlichen IEEE 802.1X. Zur Verschlsselung kommt AES zum Einsatz.
Eine andere Mglichkeit, WLANs vor unbefugtem Zugriff zu schtzen und die Vertraulichkeit der Kommunikation im WLAN zu wahren, ist die Verwendung einer
VPN-Struktur. Die drahtlos kommunizierenden Stationen verwenden einen VPNZugang in das LAN, so dass sie auf die vom WLAN zur Verfgung gestellten Mechanismen nicht angewiesen sind.
15.5 bungsaufgaben
Aufgabe 15.1:
Beschreiben Sie Funktionsweise und Architektur des Extensible Authentication Protocol.
Aufgabe 15.2:
Beschreiben Sie Funktionsweise und Architektur von IEEE 802.1X.
Aufgabe 15.3:
Erlutern Sie die Unterschiede in Bezug auf Sicherheitsaspekte von drahtlosen und drahtgebundenen lokalen Netzwerken.
Aufgabe 15.4:
Skizzieren und erklren Sie, wie mittels eines VPNs eine WLAN-Installation abgesichert werden
kann. Beschreiben Sie die Unterschiede einer solchen Vorgehensweise gegenber einer Absicherung ber die Mechanismen von IEEE 802.11i.

Aufgabe 15.5:
Recherchieren Sie nach weiteren EAP-Methoden und fassen Sie Ihre Ergebnisse zusammen.
318
Aufgabe 15.6:
Lesen Sie den IEEE 802.1X-Standard [IEEE 802.1X] im Hinblick auf die Frage, wie genau EAPFrames ber Ethernet bertragen werden.
Aufgabe 15.7:
Wie kurz angesprochen kommt zwischen dem Authenticator und dem Authentication Server oft
das RADIUS-Protokoll zum Einsatz. Lesen Sie die entsprechenden Standards und fassen Sie die
Arbeitsweise von RADIUS zusammen.
Aufgabe 15.8:
Das Betreiben eines Rogue-Access-Points durch einen Angreifer wurde bereits kurz skizziert.
Beschreiben Sie einige weitere mgliche Szenarien, in denen ein Angreifer einen Rogue-AccessPoint betreibt, und welche Mglichkeiten dieses Vorgehen dem Angreifer erffnet.
Aufgabe 15.9:
Diskutieren Sie, welche mglichen Sicherheitsrisiken durch die Verwendung eines VPNs anstelle
von IEEE 802.1i zur Absicherung einer WLAN-Infrastruktur entstehen knnen, und versuchen
Sie, diese Risiken zu bewerten.
Kapitel 16
Richtlinien
16
fr die Praxis
frRichtlinien
die Praxis
16.1 Einleitung
Wir sind am Ende unseres Rundgangs durch die technischen Aspekte von Netzwerk- und Datensicherheit angelangt und wenden uns abschlieend einer globalen Sicht auf die IT-Sicherheit
in der Praxis zu. In den vorangegangenen Kapiteln haben wir Schwachstellen und Bedrohungen
in Systemen und Netzwerken kennengelernt und uns mit Methoden, Techniken und Protokollen
beschftigt, wie man trotz dieser schwierigen Ausgangslage die IT-Sicherheit, speziell Vertraulichkeit, Integritt, Verfgbarkeit und Authentikation, sicherstellen oder zumindest verbessern
kann.
Die aus diesem praxisbezogenen berblick ber die technischen Aspekte von IT-Sicherheit
gewonnenen Erkenntnisse lassen sich mit folgenden drei Punkten kurz und bndig zusammenfassen:
IT-Sicherheit ist wichtig. Der Schutz von elektronisch vorliegenden Informationen und den
IT-Systemen ist wirtschaftlich geboten und rechtlich notwendig. Kriminelle sind aufgrund
des Werts der Daten ausreichend motiviert, mgliche Schwachstellen auszunutzen.
Bedrohungen der IT-Sicherheit lauern nahezu berall. Jede Komponente eines Systems,
jedes Gert in einem Netzwerk bietet ein Potential fr Schwachstellen, die ein Angreifer
missbrauchen kann. Der Phantasie der Angreifer sind dabei keine Grenzen gesetzt.
Die Schaffung und Aufrechterhaltung von IT-Sicherheit ist kompliziert und ressourcenintensiv. Da die Bedrohungen vielfltig und das Zusammenwirken der Komponenten eines
Systems oder Netzwerks komplex ist, ist auch die Aufgabe, ein System oder Netzwerk
gegen Angriffe abzusichern, eine schwierige und verantwortungsvolle Aufgabe.
Sie werden sich vielleicht schon gefragt haben, wie man sein technisches Know-How am
besten gezielt einsetzen kann, um die IT-Sicherheit eines Systems in der Praxis zu gewhrleisten.
Mit dieser Frage wollen wir uns abschlieend kurz auseinandersetzen.
16.2 IT-Sicherheit im institutionellen Umfeld

16.2.1 Organisation und Administration
Wenden wir uns nun konkreten Manahmen zu, wie die IT-Sicherheit im institutionellen Umfeld
sichergestellt werden kann. Es gibt hierzu eine ganze Reihe von Anstzen, die letztlich allesamt
320
Techniken und Methoden anwenden, die sehr hnlich zu Prinzipien sind, wie sie in anderen verwandten Gebieten eingesetzt werden, wie beispielsweise dem Software Engineering oder auch
der Sicherheitsanalyse in anderen Bereichen. Beginnen wir mit den notwendigen organisatorischen, nicht-technischen Manahmen.
Das Bundesamt fr Sicherheit in der Informationstechnik hat im Rahmen seiner Aktivitten im Bereich des IT-Grundschutzes eine Reihe von Standards herausgebracht, die genau skizzieren, welche organisatorischen und administrativen Manahmen zu treffen sind [BSI 100-1]
[BSI 100-2]. Die folgende Darstellung orientiert sich an diesen Standards.
Wir bereits in Abschnitt 1.6.2 angesprochen wurde, muss die Gewhrleistung, berprfung
und Anpassung der IT-Sicherheit in einer Institution als Prozess verankert sein. Das BSI verwendet hierfr die Bezeichnung IT-Sicherheitsprozess. Verantwortlich fr diesen Prozess ist
die Unternehmensfhrung, die eine IT-Sicherheitsstrategie entwickelt und in Form einer ITSicherheitsleitlinie dokumentiert.
Die Strategie wird dann in Form des IT-Sicherheitsprozesses implementiert. Nach BSI besteht
der Prozess aus den Phasen Planung und Konzeption, Umsetzung der Planung, Erfolgskontrolle und berwachung sowie Optimierung. Nach [BSI 100-1] gibt es zwei wesentliche
Hilfsmittel zur Umsetzung der IT-Sicherheitsstrategie, nmlich das IT-Sicherheitskonzept und
eine IT-Sicherheitsorganisation.
Die IT-Sicherheitsorganisation umfasst die fr das IT-Sicherheitsmanagement im Unternehmen geschaffenen Organisationsstrukturen. Bei deren Aufbau mssen Gremien geschaffen, Verantwortungsbereiche festgelegt und Verantwortliche benannt werden. Das BSI empehlt, einen
IT-Sicherheitsbeauftragten zu benennen, der fr die IT-Sicherheit verantwortlich ist. Um Interessenskonikte zu vermeiden, sollte dieser Beauftragte idealerweise in einer Stabsabteilung auerhalb der normalen IT-Organisationsstrukturen angesiedelt sein.
Das IT-Sicherheitskonzept umfasst alle Phasen des IT-Sicherheitsprozesses und beinhaltet unter anderem folgende Punkte:
Identikation, Analyse und Klassikation mglicher Risiken fr die IT-Sicherheit,
Festlegung der Strategie zur Behandlung der erkannten Risiken,
Auswahl von Manahmen zur Umsetzung der Strategie,
Erstellung eines Realisierungsplans,
Umsetzung des Plans,
berwachung und Steuerung der Umsetzung,
berwachung des laufenden Betriebs und
berprfung der Eignung der Manahmen.
Keiner sollte besonders berraschend sein. Letztlich liefern die Standards des BSI (und auch
anderer Organisationen) vor allem eine sinnvolle Strukturierung, wobei andere Akzentuierungen
sicherlich mglich wren, ohne dabei die Qualitt der Ergebnisse zu beeinussen. Wichtig ist
vor allen Dingen, dass strukturiert vorgegangen wird, nicht so sehr das genaue Wie.
321
Im Rahmen des Grundschutzkonzepts liefert das BSI einige Vorschlge, die wiederum vor
allen Dingen der Strukturierung dienen. Im Wesentlichen propagiert das BSI, die IT-Struktur
der Institution zu erfassen und den derzeitigen Zustand der IT-Sicherheit zu ermitteln. Ebenso
wird anhand von Vorgaben ein Soll-Konzept erstellt. Der Vergleich des tatschlichen Zustands
mit dem Soll-Konzept liefert einen Katalog notwendiger Manahmen, um das Soll-Konzept zu
realisieren.
Tiefschrfende Erkenntnisse, wie beispielsweise die, dass man zunchst den Schutzbedarf eines Systems feststellen muss, um dann geeignete Sicherheitsmanahmen auszuwhlen, will ich
ihnen an dieser Stelle ersparen. Es ist (hoffentlich) ganz offensichtlich, dass die Rechner im
PC-Pool einer Hochschule nicht genauso geschtzt werden mssen wie die Rechner des Bundeskriminalamtes mit hochsensitiven Daten.
Ein zunehmend wichtiger Aspekt aus Sicht einer Institution ist die Zertizierung der ITSicherheit durch eine Zertizierungsstelle. Zertiziert werden knnen ganz unterschiedliche Dinge, von der gesamten IT-Infrastruktur eines Unternehmens bis hin zu einem Produkt. Ein von
der Zertizierungsstelle bevollmchtigter Prfer bescheinigt durch ein Zertikat die Konformitt
des zertizierten Objekts hinsichtlich eines durch die Zertizierungsstelle festgelegten Kritierienkatalogs. Zertikate sind vor allem wichtig, da sie gegenber Geschftspartnern, Kunden
oder Versicherungen als Nachweis fr ausreichende Sicherheit vorgelegt werden knnen. Einige
Unternehmen verlangen sogar von Geschftspartnern bestimmte Zertizierungen, beispielsweise
bevor sie einem anderen Unternehmen Zugriff auf Teile der eigenen IT-Infrastruktur gestatten.
16.2.2 Leitlinien zur Erstellung und Beibehaltung sicherer IT-Strukturen

In den vorangegangenen Kapiteln haben wir eine Reihe von sicherheitsrelevanten Protokollen,
Konzepten und Methoden vorgestellt. Auch Schwachstellen wurden angesprochen und teilweise
ausfhrlich diskutiert. Wir wollen diese Punkte hier nicht wiederholen.
Stattdessen sollen die wichtigsten Designprinzipien, die generell als Leitlinien verwendet werden knnen, im Folgenden kurz erlutert werden:
Bei der Autorisationsvergabe und dem Betrieb von Programmen und Systemen gilt: So wenig wie mglich, so viel wie ntig. Jeder Benutzer und jede Anwendung sollte nur solche
Berechtigungen erhalten, die zur Erfllung der Aufgabe tatschlich bentigt werden. Was
nicht explizit erlaubt ist, sollte nicht mglich sein. Es sollten nur Programme vorhanden
sein und Dienste laufen, die wirklich erforderlich sind. Rechner, die nicht benutzt werden, sollten ebenfalls abgeschaltet werden. Schwachstellen in Programmen oder Diensten,
die nicht laufen, knnen von einem Angreifer nicht ausgenutzt werden. Ein abgeschalteter Rechner ohne die aktuellsten Softwareupdates stellt kein Risiko dar (solange er nicht
wieder angeschaltet wird).
Redundante Sicherheitsstrukturen: Die Kompromittierung eines Sicherheitsmechanismus
darf nicht unmittelbar zur Kompromittierung des gesamten IT-Systems fhren. Es sollten verschiedene Sicherheitsperimeter in den IT-Systemen existieren, so wie dies auch in
anderen Feldern der Fall ist, beispielsweide der Gebudesicherheit.
322
Keine schlecht gesicherten Hintertren: Es darf keine schlecht gesicherten Hintertrchen

geben, mittels derer sinnvolle Schutzmechanismen einfach umgangen werden knnen. Die
Schutzmechanismen in einem System mssen ausgewogen und aufeinander abgestimmt
sein. Einbrecher machen sich auch nicht an der hervorragend gesichteten Eingangstr zu
schaffen, wenn die Terrassentr offensteht.
Diese Prinzipien sind ziemlich offensichtlich. Es sollte niemand wirklich berraschen, dass
man einen Benutzer nur mit Berechtigungen ausstatten sollte, die er tatschlich zur Erfllung
seiner Aufgaben bentigt. Doch leider scheinen diese Hinweise zu einem gewissen Grad tatschlich notwendig. Whrend ein Praktikant in einem Unternehmen wohl nur ganz selten sofort
einen Schlssel fr das Vorstandsbro erhalten wird, ist die Rechtevergabepraxis im IT-Bereich
bei vielen Unternehmen, speziell im kleinen und mittelstndischen Umfeld, wesentlich offener.
So einfach vielleicht auf den ersten Blick die praktische Umsetzung dieser Kriterien erscheint,
so schwierig wird sie manchmal auf den zweiten. Wir hatten schon in der Einfhrung ber Benutzerakzeptanz als wichtiges Kriterium gesprochen. Die Verbesserung der Sicherheit geht hug,
ja sogar meistens mit einer Verschlechterung der Verwendbarkeit des Systems aus Benutzersicht
einher. Werden Dinge in einer Institution zu restriktiv gehandhabt, so werden die Mitarbeiter
schnell Wege nden, diese Mechanismen zu umgehen, was dann zu einer Verschlechterung der
Sicherheit, nicht zu einer Verbesserung fhrt. Denken Sie an das Beispiel der Passwort-Policies
oder der Umgehung von Firewalls durch Tunnel. Es kommt eben auch bei der IT-Sicherheit auf
eine vernnftige Balance zwischen Sicherheit einerseits und Benutzbarkeit andererseits an. Diese
Balance zu halten, ist ein groes Problem.
16.2.3 Minimalanforderungen
Konzentrieren wir uns nun auf Mindestkriterien, um im institutionellen Umfeld den sicheren Betrieb der IT-Struktur zu ermglichen. Mindestkriterien sind im Gegensatz zu Maximalforderungen schwer aufzustellen und einfach zu kritisieren, schon alleine deshalb, weil Mindestkriterien
gem ihrer Denition viele sinnvolle Manahmen nicht beinhalten. Trotzdem wollen wir hier
einige Punkte nennen, die unbedingt erfllt sein sollten:
Absicherung und Schutz des eigenen Netzwerks: Das eigene Intranet sollte gegenber dem
Internet geschtzt und ein direkter Zugriff vom Internet auf das Intranet unterbunden werden. Insbesondere zhlen hierzu folgende Unterpunkte:
Betrieb einer Paketlter-Firewall: Das Intranet sollte mit dem Internet ber einen Paketlter verbunden sein, der mglichst keine eingehenden Verbindungen erlaubt. Bei
allen Schwchen von Firewalls ist dies heute unverzichtbar. Mobile Rechner sollten
zustzlich zumindest im mobilen Betrieb durch eine Personal Firewall geschtzt sein.
VPN-Zugriff auf Ressourcen im Intranet: Wenn auf Intranet-Ressourcen auch vom
Internet aus zugegriffen werden muss, sollte der Zugriff ber ein VPN erfolgen.
Betrieb externer Server auerhalb des geschtzten Intranets: Gibt es Server, die
vom Internet aus zugnglich sein mssen, sollten diese auerhalb des geschtzten
Intranets betrieben werden, idealerweise in einer DMZ einer greren Firewall-Infrastruktur. Wenn diese nicht vorhanden ist, empehlt sich der Betrieb auerhalb des
323
geschtzten Bereichs. Alle nicht notwendigen Dienste sollten abgeschaltet werden

und die Administration des Servers sollte nur von Maschinen mit bestimmten IPAdressen erfolgen drfen.
Sicherung direkter Netzwerkzugnge: Wenn Perimetersicherheit nicht vorhanden ist
oder nicht ausreicht, sollte der Zugriff auf das interne Netz erst nach erfolgreicher
Authentikation mglich sein. Drahtlose Netze sollten nur mit ausreichenden Sicherheitsmechanismen betrieben werden.
Sicherheit der Systeme und Rechner im Netzwerk: Die einzelnen Systeme und Rechner im
Netzwerk sollten mindestens folgende Anforderungen erfllen:
Softwareupdates und Patches: Die Software auf smtlichen Rechnern der Institution
sollte stets mit allen verfgbaren Patches versehen werden. Nicht mehr gepegte und
veraltete Softwareprodukte sollten durch Updates ersetzt werden.
Virenscanner: Alle Arbeitsplatzrechner sollten mit Virenscannern ausgestattet sein.
Dabei ist ein regelmiges Update der Scanner (vor allem der Signaturen) essentiell.
Weitere Vorkehrungen (beispielsweise bei Email) sind wnschenswert.
Umsetzung des Prinzips So wenig wie mglich, so viel wie ntig: Dieses Designprinzip ist insbesondere bei der Systemkonguration und -installation und der Vergabe von
Benutzerberechtigungen zu beachten.
Abschaltung nicht bentigter Dienste: Nicht tatschlich bentigte Dienste und Softwarekomponenten sollten abgeschaltet bzw. von den Systemen entfernt werden.
Restriktive Benutzerberechtigungen: Benutzer sollten nur mit Berechtigungen ausgestattet werden, die sie tatschlich zur Erfllung ihrer Aufgaben bentigen.
Verschlsselung vertraulicher Daten: Vertrauliche Daten sollten ausschlielich verschlsselt bertragen und mglichst auch verschlsselt gespeichert werden.
Verwendung sicherer Netzwerkprotokolle: Wann immer mglich sollten Protokolle
und Dienste verwendet werden, die die bertragenen Daten schtzen, beispielsweise
bei der Benutzung des WWW oder von Email.
Verschlsselung von Information auf Massenspeichern: Auf Massenspeichermedien
abgelegte vertrauliche Informationen sollten ebenfalls verschlsselt werden.
Sicherstellung der Verfgbarkeit: Die Verfgbarkeit der (kritischen) Daten und Dienste
muss sichergestellt sein:
Backups: Alle wichtigen Daten sollten regelmig gesichert und sicher aufbewahrt
werden.
Redundanz: Ein Ausfall kritischer Teile der IT-Infrastruktur sollte unabhngig von
der Ursache in vertretbarer Zeit kompensiert werden knnen. Die Frage, welcher
Zeitraum als vertretbar gilt, kann von Komponente zu Komponente und Institution
zu Institution variieren.
Sensibilisierung der Benutzer fr die Wichtigkeit der IT-Sicherheit fr die Institution.
324
Beachtet man diese Minimalanforderungen, hat man noch bei weitem keine IT-Infrastruktur,
die man als gut geschtzt bezeichnen kann. Beachtet man jedoch eine dieser Anforderungen
nicht, hat man eine IT-Infrastruktur, die einen Angriff geradezu heraufbeschwrt.
16.3 IT Sicherheit im privaten Umfeld

Die eben beschriebenen Regeln gelten nicht nur im institutionellen, sondern auch im privaten
Umfeld. Einem Angreifer, der einen Rechner in einen Zombie verwandeln will, um ber diesen Email-Spam in die Welt zu schleudern, ist es relativ egal, ob er einen privaten oder einen
institutionell genutzten Rechner kompromittieren kann.
Entsprechend sollten private Rechner und Netzwerke genauso geschtzt werden wie Netze im
professionellen Umfeld. In Ermangelung eines ausreichenden Bewusstseins um die Risiken mangelnder IT-Sicherheit weigern sich viele Privatanwender aber standhaft, in ausreichender Menge
sndhaft teures Equipment zur Absicherung ihres aus ein oder zwei lteren Rechnern bestehenden Netzwerks zu beschaffen. Viele Privatpersonen sind ebenfalls nicht bereit, Sicherheitsconsultants fnf- oder sechsstellige Betrge fr entsprechende Serviceleistungen zu bezahlen. Mit
anderen Worten: Die nanziellen und personellen Ressourcen sind sehr viel beschrnkter als im
institutionellen Umfeld.
Ernsthaft betrachtet gibt es eine ganze Reihe von guter, preiswerter oder sogar kostenloser
Soft- und Hardware, die zur Absicherung der Netzwerkinfrastruktur und der Rechner im privaten Bereich vllig ausreicht. Wesentlich problematischer ist jedoch die Bedienung der Produkte. Whrend Sie und ich vielleicht groe Freude daran haben, einen im Produktpaket des
DSL-Providers gratis eingeschlossenen Paketlter in mhsamer, stundenlanger Kleinarbeit genau auszuprobieren und zu kongurieren, knnen Sie das nicht unbedingt von jedem Anwender
erwarten. Insofern kommt gerade im Privatbereich der Benutzerfreundlichkeit der Produkte und
der einfachen Handhabbarkeit durch normale Anwender eine entscheidende Bedeutung zu. Ein
aus der Sicherheitsperspektive hervorragendes Produkt, das schlecht oder schwierig zu administrieren ist, kann in der Praxis mehr Probleme aufwerfen als ein mittelmiges Produkt mit
hervorragender Administrierbarkeit.
16.4 Ausblick
In Anbetracht der praktischen Relevanz und der wirtschaftlichen Bedeutung der IT-Sicherheit
ist es nicht verwunderlich, dass derzeit auf diesem Feld sowohl von industrieller als auch von
akademischer Seite umfangreiche Forschungen betrieben werden. Im Bereich der Grundlagenforschung, die nicht auf Verbesserungen abzielen muss, die zumindest mittel- und langfristig
sowohl praktikabel als auch wirtschaftlich sinnvoll sind, gibt es wie in vielen anderen Gebieten auch ein breites Spektrum von Aktivitten, die uns in unserem Verstndnis des Gebiets ITSicherheit weiterbringen.
Die derzeitigen praktischen Probleme im Feld der IT-Sicherheit, welche die institutionellen
Anwender beschftigen, liegen hauptschlich in der Komplexitt des Aufbaus und der Aufrechterhaltung der IT-Sicherheit. Fr jede einzelne der Teilaufgaben sind durchaus die Lsungsmg-
325
lichkeiten klar und meistens auch Produkte verfgbar, welche die jeweiligen Aufgaben zufriedenstellend erledigen knnen. Das Problem ist daher nicht die Lsung von Teilaufgaben. Vielmehr besteht das Problem in der Schwierigkeit, diese Teillsungen in die Gesamtinfrastruktur in
sinnvoller und sicherer Weise zu integrieren (und dies mglichst, ohne bei der Produktwahl auf
einen einzigen Hersteller eingeschrnkt zu werden).
Viele verfgbare Produkte bieten Insellsungen, mit denen man zwar ein wichtiges Teilproblem lsen kann, doch sie fgen sich nicht mit anderen Lsungen zu einem halbwegs einheitlichen groen Ganzen zusammen.
Diese Misere hat eine ganze Reihe von Grnden. Zum einen gibt es immer verschiedene Mglichkeiten, ein Problem zu lsen, etwa zwei konkurrierende Standards, die gegenseitig inkompatibel sind. Nehmen wir als Beispiel die Verschlsselung von Emails, die mit S/MIME oder
OpenPGP erfolgen kann. Beide Standards sind aber nicht kompatibel zueinander und verwenden
unterschiedliche Authentikationsmechanismen. Entscheidet sich also eine Institution fr einen
Standard und eine andere fr den anderen Standard, knnen Emails zwischen diesen beiden Institutionen nicht geschtzt ausgetauscht werden.
Manchmal lst sich ein solches Problem mit der Zeit von selbst. Sobald einer der Standards
einen groen Marktanteil hat, wird der Einsatz des anderen Standards manchmal so unattraktiv
(weil man ihn kaum noch verwenden kann), dass nach und nach alle auf einen Standard umschwenken. Oft genug aber passiert dies aus den unterschiedlichsten Grnden nicht.
Ein weiterer Grund sind die unterschiedlichen Anforderungen in unterschiedlichen Sicherheitsbereichen. So ist die Diversitt der Produkte und Standards eigentlich nicht berraschend.
Dennoch ist wahrscheinlich die wichtigste Aufgabe der nchsten Jahre, zu bergreifenden Konzepten zu gelangen, welche die bisherigen Insellsungen in sinnvoller Weise in eine Gesamtlsung fr IT-Sicherheit integrieren.
Ein damit verwandtes Problem, das wir eben im Umfeld von Privatanwendern schon diskutiert haben, ist die Benutzerfreundlichkeit der Produkte, und zwar nicht nur fr Privatanwender,
sondern auch fr Systemadministratoren. Es muss einfacher werden, Sicherheitsmechanismen
einzusetzen. Je niedriger die Hemmschwelle ist, eine Sicherheitslsung zu betreiben und je einfacher die Konguration des Produkts ist, desto besser ist dies fr den Schutz der IT-Infrastruktur.
Auf diesem Weg bleibt sehr viel zu tun.
Wie wir in den vergangenen Kapiteln gesehen haben, ist IT-Sicherheit wichtig. Bedrohungen lauern berall und die Schaffung und Aufrechterhaltung der IT-Sicherheit ist
kompliziert.
Daher ist strukturiertes Vorgehen bei der Organisation und betrieblichen Administration von IT-Sicherheit unerllich. Welche Organisationsformen man whlen sollte, bleibt den einzelnen Unternehmen berlassen. Die Zertizierung von Sicherheit
durch Zertizierungsstellen wird zunehmend wichtiger, um gegenber Kunden und
Geschftspartnern die Sicherheit der eigenen Infrastruktur glaubhaft machen zu knnen.
326
Um eine sichere IT-Infrastruktur zu schaffen, sollten einige Leitlinien beachtet werden. So sollte bei der Autorisationsvergabe und dem Betrieb von Programmen und
Systemen der Grundsatz so wenig wie mglich, so viel wie ntig beachtet werden.
Sicherheitsstrukturen sollten redundant ausgelegt sein und schlecht gesicherte Hintertren im System vermieden werden.
Mindestkriterien fr die Schaffung und Aufrechterhaltung der IT-Sicherheit im institutionellen Umfeld beinhalten eine Sicherung des internen Netzwerks nach auen, die
Sicherung der einzelnen Systeme in diesem Netz, die Umsetzung des Grundsatzes so
wenig wie mglich, so viel wie ntig, die Verschlsselung vertraulicher Daten, die Sicherstellung der Verfgbarkeit und die Sensibilisierung der Benutzer fr IT-Sicherheit.
In der Zukunft wird es in der Praxis vor allem darum gehen, die bisherigen Insellsungen im IT-Sicherheitsumfeld zusammenzufgen und die Benutzerfreudlichkeit der
Produkte zu verbessern.
16.6 bungsaufgaben
Aufgabe 16.1:
Beschreiben Sie kurz Organisation und Administration der IT-Sicherheit im Rahmen des ITGrundschutzes des BSI.
Aufgabe 16.2:
Nennen Sie Leitlinien zur Erstellung sicherer IT-Strukturen.
Aufgabe 16.3:
Nennen und erlutern Sie die genannten Minimalanforderungen zum sicheren Betrieb einer ITInfrastruktur. Diskutieren Sie, inwieweit diese Anforderungen ausreichend sind oder nicht. Geben Sie mindestens ein Beispiel fr mgliche Angriffe und problematische Technologien, die bei
Umsetzung der skizzierten Minimalanforderungen nicht verhindert werden knnen.

Aufgabe 16.4:
Befassen Sie sich mit den BSI-Standards zum IT-Grundschutz und den IT-Grundschutzkatalogen
(online verfgbar unter [BSI-Web]). Fassen Sie das Vorgehen detailliert zusammen.
Aufgabe 16.5:
Entwickeln Sie ein Konzept fr einen benutzerfreundlichen Paketlter fr private Anwender.
Diskutieren Sie insbesondere auch mgliche Schwchen Ihres Vorschlags.
Anhang
A Weiterfhrende Literatur
Firewalls und Sicherheit im Internet von W. Cheswick, S. Bellovin und A. Rubin [CBR04]: Hervorragende praktische Abhandlung des Themas. Das Buch richtet sich in erster Linie an Netzwerkadministratoren und beinhaltet sowohl eine rigorose Analyse der Sicherheitseigenschaften von Anwendungen und Diensten als auch wertvolle praktische Tips.
Network Security von C. Kaufman, R. Perlman und M. Spenciner [KPS02]: Dieses Buch beschftigt sich ausfhrlich mit dem Thema Netzwerksicherheit aus einem eher theoretischen Blickwinkel.
Neben einer umfangreichen Einfhrung in die Kryptographie liegt der Fokus des Buchs auf einer
ausfhrlichen und sehr gut verstndlichen Darstellung der im Internet verwendeten Sicherheitsprotokolle.
Cryptography and Network Security von W. Stallings [Sta05]: Das Buch bietet ebenfalls eine ausfhrliche, relativ mathematische Einfhrung in Kryptographie und eine Darstellung der InternetSicherheitsprotokolle.
VPN - Virtual Private Networks von W. Bhmer [B5]: Gut gelungene, ausfhrliche und eher theoretisch orientierte Darstellung von VPN-Technologien und deren Umfeld.
Web Security, Privacy & Commerce von S. Garnkel und G. Spafford [GS02]: Schne, sehr praktisch
orientierte, verstndliche und ausfhrliche Darstellung von Sicherheit im WWW. Das Buch behandelt sehr viele in diesem Umfeld relevante Fragen. Derzeit ist das Buch leider nur in englischer
Sprache erhltlich.
Angewandte Kryptographie von B. Schneier [Sch06]: Vielleicht das Standardwerk zum Thema Kryptographie fr Nicht-Mathematiker. Alle relevanten kryptographschen Techniken werden algorithmenorientiert dargestellt. Unverzichtbare Lektre, wenn Sie sich nher mit Kryptographie beschftigen wollen oder kryptographische Algorithmen implementieren mssen.
Klassische Referenzen
[B5]
B HMER , W.: VPN Virtual Private Networks. Hanser, Mnchen, 2 Auflage, 2005.
[Bad06]
BADACH , A.: Voice over IP. Hanser, Mnchen, 3 Auflage, 2006.
[BDSG]
Bundesdatenschutzgesetz (BDSG). Bundesdatenschutzgesetz in der Fassung der Bekanntmachung vom 14. Januar 2003 (BGBl. I S. 66), zuletzt gendert durch Artikel 1 des Gesetzes
vom 22. August 2006 (BGBl. I S. 1970).
[BH01]
BADACH , A. und E. H OFFMANN: Technik der IP-Netze. Hanser, Mnchen, 2001.
[BSIG]
Gesetz ber die Errichtung des Bundesamtes fr Sicherheit in der Informationstechnik (BSIErrichtungsgesetz - BSIG). BGBl 1990, 2834, 1990.
[BSI 100-1]
BSI-Standard 100-1: Managementsysteme fr Informationssicherheit (ISMS) Version 1.0.

Bundesamt fr Sicherheit in der Informationstechnik, 2005. Online verfgbar unter
[BSI-Web].
[BSI 100-2]
BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise Version 1.0. Bundesamt fr Sicherheit

in der Informationstechnik, 2005. Online verfgbar unter [BSI-Web].
[BSI06]
Leitfaden IT-Sicherheit. Bundesamt fr Sicherheit in der Informationstechnik, 2006. Online

verfgbar unter [BSI-Web].
[CBR04]
C HESWICK , W. R., S. M. B ELLOVIN und A. D. RUBIN: Firewalls und Sicherheit im Internet. Addison Wesley, Mnchen, 2 Auflage, 2004.
[CC-1]
Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model. Version 3.1, Revision 1. CCMB-2006-09-001, September 2006. Online
verfgbar unter [NIST-Web].
[Col03]
C OLLINS , D.: Carrier Grade Voice over IP. McGraw-Hill, New York, NY, 2 Auflage, 2003.
[Com02]
C OMER , D. E.: Computernetzwerke und Internets. Pearson Studium, Mnchen, 3 Auflage,

2002.
[DH76]
D IFFIE , W. und M. H ELLMAN: New Directions in Cryptography. IEEE Transactions on

Information Theory, 22:644654, 1976.
[EKR+ 05]
E HSES , E., L. KHLER, P. R IEMER, H. S TENZEL und F. V ICTOR: Betriebssysteme. Pearson Studium, Mnchen, 2005.
[FBW07]
F UNK , P. und S. B LAKE -W ILSON: EAP Tunneled TLS Authentication Protocol Version 0
(EAP-TTLSv0). IETF Draft <draft-funk-eap-ttls-v0-01.txt>, 2007. Online verfgbar unter
[IETF-Web].
[FIPS 46-3]
Data Encryption Standard (DES). Federal Information Processing Standards Publication

46-3, 1999. Online verfgbar unter [NIST-Web].
[FIPS 197]
Specication for the Advanced Encryption Standard (AES). Federal Information Processing
Standards Publication 197, 2001. Online verfgbar unter [NIST-Web].
332
[FIPS 180-2] Secure Hash Standard (SHA). Federal Information Processing Standards Publication 180-2,
2002. Online verfgbar unter [NIST-Web].
[G.711]
ITU-T Recommendation G.711. General Aspects of Digital Transmission Systems. Terminal

Equipments. Puse Code Modulation (PCM) of Voice Frequencies. 1988. Online verfgbar
unter [ITU-Web].
[Gla06]
G LATZ , E.: Betriebssysteme. dpunkt.verlag, Heidelberg, 2006.
[GS02]
G ARFINKEL , S. und G. S PAFFORD: Web Security, Privacy & Commerce. OReilly, Sebastopol, CA, 2 Auflage, 2002.
[H.323]
ITU-T H.323 Series H: Audiovisual and Multimedia Sustems. Infrastructure of Audiovisual

Services - Systems and Terminal Equipment for Audiovisual Services Packet-Based Multimedia Communications Systems. 2006. Online verfgbar unter [ITU-Web].
[HGB]
Handelsgesetzbuch (HGB). Handelsgesetzbuch in der im Bundesgesetzblatt Teil III, Gliederungsnummer 4100-1, verffentlichten bereinigten Fassung, zuletzt gendert durch Artikel 5
des Gesetzes vom 5. Januar 2007 (BGBl. I S. 10)
[HMHG07]
H EINISCH , C., F. M LLER -H OFMANN und J. G OLL: Java als erste Programmiersprache.
Teubner Verlag, Wiesbaden, 5 Auflage, 2007.
[IEEE 802.11] IEEE 802.11 Standard for Wireless Local Area Networks. 1999. Online verfgbar unter
[IEEE-Web].
[IEEE 802.11i] IEEE 802.11 Standard for Wireless Local Area Networks Amendment 6: Medium Access
Control (MAC) Security Enhancements. 2004. Online verfgbar unter [IEEE-Web].
[IEEE 802.1X] 802.1X IEEE Standard for Local and Metropolitan Area Networks Port-Based Network
Access Control. 2004. Online verfgbar unter [IEEE-Web].
[IEEE 802.3] IEEE 802.3 IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specic requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access
Method and Physical Layer Specications. 2005. Online verfgbar unter [IEEE-Web].
[ISO]
Information technology Open Systems Interconnection Basic Reference Model: The Basic
Model. ISO/IEC 7498-1, 1994.
[Kan05]
K ANBACH , A.: SIP Die Technik. Vieweg, Wiesbaden, 2005.
[KPS02]
K AUFMAN , C., R. P ERLMAN und M. S PENCINER: Network Security. Prentice Hall, Upper
Saddle River, NJ, 2 Auflage, 2002.
[KPW02]
K AMATH , V., A. PALEKAR und M. W ODRICH: Microsofts PEAP version 0 (Implementation in Windows XP SP1). IETF Draft <draft-kamath-pppext-peapv0-00.txt>, 2002. Online
verfgbar unter [IETF-Web].
[KR02]
K UROSE , J. F. und K. W. ROSS: Computernetze. Pearson Studium, Mnchen, 2002.
[MOV97]
M ENEZES , A. J., P. C. O ORSCHOT und S. A. VANSTONE: Handbook of Applied Cryptography. CRC Press, Boca Raton, FL, USA, 1997.
[NIST 800-38A] DWORKIN , M ORRIS: Recommendation for Block Cipher Modes of Operation. NIST
Special Publication 800-38A, 2001. Online verfgbar unter [NIST-Web].
[NSTISSC 4009] National Information Systems Security (Infosec) Glossary. National Security Telecommunications and Information Systems Security Committee (NSTISSI) Publication No. 4009,
2000.
333
[RFC 768]
P OSTEL , J.: User Datagram Protocol. IETF RFC 768, 1980. Online verfgbar unter
[IETF-Web].
[RFC 791]
Internet Protocol. IETF RFC 791, 1981. Online verfgbar unter [IETF-Web].
[RFC 792]
P OSTEL , J.: Internet Control Message Protocol. IETF RFC 792, 1981. Online verfgbar
unter [IETF-Web].
[RFC 793]
Transmission Control Protocol. IETF RFC 793, 1981. Online verfgbar unter [IETF-Web].
[RFC 959]
P OSTEL , J. und J. R EYNOLDS: File Transfer Protocol (FTP). IETF RFC 959, 1985. Online
[RFC 826]
P LUMMER , D.: An Ethernet Address Resolution Protocol or Converting Network Protocol

Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. IETF RFC
826, 1982. Online verfgbar unter [IETF-Web].
[RFC 1034]
M OCKAPETRIS , P.: Domain Names - Concepts and Facilities. IETF RFC 1034, 1987. Online
[RFC 1035]
M OCKAPETRIS , P.: Domain Names - Implementation and Specication. IETF RFC 1035,
1987. Online verfgbar unter [IETF-Web].
[RFC 1321]
R IVEST, R.: The MD5 Message-Digest Algorithm. IETF RFC 1321, 1992. Online verfgbar
unter [IETF-Web].
[RFC 1661]
S IMPSON , W.: The Point-to-Point Protocol (PPP). IETF RFC 1661, 1994. Online verfgbar
unter [IETF-Web].
[RFC 1731]
M YERS , J.: IMAP4 Authentication Mechanisms. IETF RFC 1731, 1994. Online verfgbar
unter [IETF-Web].
[RFC 1734]
M YERS , J.: POP3 AUTHentication command. IETF RFC 1734, 1994. Online verfgbar
unter [IETF-Web].
[RFC 1771]
R EKHTER , Y. und T. L I: A Border Gateway Protocol 4 (BGP-4). IETF RFC 1771, 1995.
Online verfgbar unter [IETF-Web].
[RFC 1918]
R EKHTER , Y., B. M OSKOWITZ, D. K ARRENBERG, G. J. DE G ROOT und E. L EAR: Address

Allocation for Private Internets. IETF RFC 1918, 1996. Online verfgbar unter [IETF-Web].
[RFC 1928]
L EECH , M., M. G ANIS, Y. L EE, R. K URIS, D. KOBLAS und L. J ONES: SOCKS Protocol
Version 5. IETF RFC 1928, 1996. Online verfgbar unter [IETF-Web].
[RFC 1939]
M YERS , J. und M. ROSE: Post Ofce Protocol Version 3. IETF RFC 1939, 1996. Online
[RFC 2045-2049] F REED , N. und N. B ORENSTEIN: Multipurpose Internet Mail Extensions (MIME) Specications. IETF RFCs 2045, 2046, 2047, 2048, 2049, 1996. Online verfgbar unter
[IETF-Web].
[RFC 2131]
D ROMS , R.: Dynamic Host Conguration Protocol. IETF RFC 2131, 1997. Online verfgbar unter [IETF-Web].
[RFC 2315]
K ALISKI , B.: PKCS #7: Cryptographic Message Syntax Version 1.5. IETF RFC 2315, 1998.
[RFC 2328]
M OY, J.: OSPF Version 2. IETF RFC 2328, 1998. Online verfgbar unter [IETF-Web].
[RFC 2440]
C ALLAS , J., L. D ONNERHACKE, H. F INNLEY und R. T HAVER: OpenPGP Message Format. IETF RFC 2440, 1998. Online verfgbar unter [IETF-Web].
334
[RFC 2453]
M ALKIN , G.: RIP Version 2. IETF RFC 2453, 1998. Online verfgbar unter [IETF-Web].
[RFC 2460]
D EERING , S. und R. H INDEN: Internet Protocol Version 6 (IPv6) Specication. IETF RFC
[RFC 2516]
M AMAKOS , L., K. L IDL, J. E VARTS, D. C ARREL, D. S IMONE und R. W HEELER: A Method for Transmitting PPP Over Ethernet (PPPoE). IETF RFC 2516, 1999. Online verfgbar
unter [IETF-Web].
[RFC 2554]
M YERS , J.: SMTP Service Extension for Authentication. IETF RFC 2554, 1999. Online
[RFC 2581]
A LLMAN , M., V. PAXSON und W. S TEVENS: TCP Congestion Control. IETF RFC 2581,
[RFC 2616]
F IELDING , R., J. G ETTYS, J. M OGUL, H. F RYSTYK, L. M ASINTER, P. L EACH und

T. B ERNERS -L EE: Hypertext Transfer Protocol HTTP/1.1. IETF RFC 2616, 1999. Online
[RFC 2617]
F RANKS , J., P. H ALLAM -BAKER, J. H OSTETLER, S. L AWRENCE, P. L EACH, A. L UOTO NEN und J . S TEWART : HTTP Authentication: Basic and Digest Access Authentication. IETF
RFC 2617, 1999. Online verfgbar unter [IETF-Web].
[RFC 2663]
S RISURESH , P. und M. H OLDREGE: IP Network Address Translator (NAT) Terminology and

Considerations. IETF RFC 2663, 1999. Online verfgbar unter [IETF-Web].
[RFC 2716]
A BOBA , B. und D. S IMON: PPP EAP TLS Authentication Protocol. IETF RFC 2716, 1999.
[RFC 2821]
K LENSIN , J. (E DITOR ): Simple Mail Transfer Protocol. IETF RFC 2821, 2001. Online
[RFC 2828]
S HIREY, R.: Internet Security Glossary. IETF RFC 2828, 2000. Online verfgbar unter
[IETF-Web].
[RFC 2818]
R ESCORLA , E.: HTTP over TLS.

[IETF-Web].
[RFC 2822]
R ESNICK , P. (E DITOR ): Internet Message Format. IETF RFC 2822, 2001. Online verfgbar
unter [IETF-Web].
[RFC 2827]
F ERGUSON , P. und D. S ENIE: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoong. IETF RFC 2827, 2000. Online verfgbar
unter [IETF-Web].
[RFC 2865]
R IGNEY, C., S. W ILLENS, A. RUBENS und W. S IMPSON: Remote Authentication Dial In

User Service (RADIUS). IETF RFC 2865, 2000. Online verfgbar unter [IETF-Web].
[RFC 2965]
K RISTOL , D. und L. M ONTULLI: HTTP State Management Mechanism. IETF RFC 2965,
[RFC 3022]
S RISURESH , P. und K. E GEVANG: Traditional IP Network Address Translator (Traditional

NAT). IETF RFC 3022, 2001. Online verfgbar unter [IETF-Web].
[RFC 3279]
P OLK , W., R. H OUSLEY und W. BASSHAM: Algorithms and Identiers for the Internet
X.509 Public Key Infrastructure Certicate and Certicate Revocation List (CRL) Prole.
IETF RFC 3279, 2002. Online verfgbar unter [IETF-Web].
[RFC 3261]
ROSENBERG , J., H. S CHULZRINNE, G. C AMARILLO, A. J OHNSTON, J. P ETERSON,

R. S PARKS, H. H ANDLEY und E. S CHOOLER: SIP: Session Initiation Protocol. IETF RFC
IETF RFC 2818, 2000.
Online verfgbar unter
335
[RFC 3280]
H OUSLEY, R., W. P OLK, W. F ORD und D. S OLO: Internet X.509 Public Key Infrastructure
Certicate and Certicate Revocation List (CRL) Prole. IETF RFC 3280, 2002. Online
[RFC 3330]
Special-Use IPv4 Addresses. IETF RFC 3330, 2002. Online verfgbar unter [IETF-Web].
[RFC 3344]
P ERKINS , C. (E DITOR ): IP Mobility Support for IPv4. IETF RFC 3344, 2002. Online
[RFC 3428]
(E DITOR ), B. C AMPBELL, H. S CHULZRINNE, C. H UITEMA und D. G URLE: Session Initiation Protocol (SIP) Extension for Instant Messaging. IETF RFC 3428, 2002. Online
[RFC 3489]
ROSENBERG , J., J. W EINBERGER, C. H UITEMA und R. M AHY: STUN - Simple Traversal

of User Datagram Protocol (UDP) Through Network Address Translators (NATs). IETF
[RFC 3501]
C RISPIN , M.: Internet Message Access Protocol - Version 4rev1. IETF RFC 3501, 2003.
[RFC 3550]
H. S CHULZRINNE , S. C ASNER , R. F REDERICK V. JACOBSON: RTP: A Transport Protocol

for Real-Time Applications. IETF RFC 3550, 2003. Online verfgbar unter [IETF-Web].
[RFC 3551]
H. S CHULZRINNE , S. C ASNER: RTP Prole for Audio and Video Conferences with Minimal
Control. IETF RFC 3551, 2003. Online verfgbar unter [IETF-Web].
[RFC 3579]
A BOBA , B. und P. C ALHOUN: RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP). IETF RFC 3579, 2003. Online verfgbar
unter [IETF-Web].
[RFC 3610]
W HITING , D., R. H OUSLEY und N. F ERGUSON: Counter with CBC-MAC (CCM). IETF
[RFC 3711]
BAUGHER , M., D. M C G REW, M. NASLUND, E. C ARRARA und K. N ORRMAN: The Secure Real-time Transport Protocol (SRTP). IETF RFC 3711, 2004. Online verfgbar unter
[IETF-Web].
[RFC 3748]
A BOBA , B., L. B LUNK, J. VOLLBRECHT, J. C ARLSON und H. L EVKOWETZ: Extensible

Authentication Protocol (EAP). IETF RFC 3748, 2004. Online verfgbar unter [IETF-Web].
[RFC 3850]
R AMSDELL , B. (E DITOR ): Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certicate Handling. IETF RFC 3850, 2004. Online verfgbar unter [IETF-Web].
[RFC 3851]
R AMSDELL , B. (E DITOR ): Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specication. IETF RFC 3851, 2004. Online verfgbar unter [IETF-Web].
[RFC 3852]
H OUSLEY, R.: Cryptographic Message Syntax (CMS). IETF RFC 3852, 2004. Online verfgbar unter [IETF-Web].
[RFC 3986]
B ERNERS -L EE , T., R. F IELDING und L. M ASINTER: Uniform Resource Identier (URI):

Generic Syntax. IETF RFC 3986, 2005. Online verfgbar unter [IETF-Web].
[RFC 4251]
Y LONEN , T. und C. L ONVICK (E DITORS ): The Secure Shell (SSH) Protocol Architecture.
[RFC 4252]
Y LONEN , T. und C. L ONVICK (E DITORS ): The Secure Shell (SSH) Authentication Protocol.
[RFC 4253]
Y LONEN , T. und C. L ONVICK (E DITORS ): The Secure Shell (SSH) Transport Layer Protocol. IETF RFC 4253, 2006. Online verfgbar unter [IETF-Web].
336
[RFC 4254]
Y LONEN , T. und C. L ONVICK (E DITORS ): The Secure Shell (SSH) Connection Protocol.
[RFC 4301]
K ENT, S. und K. S EO: Security Architecture for the Internet Protocol. IETF RFC 4301,
[RFC 4302]
K ENT, S.: IP Authentication Header. IETF RFC 4302, 2005. Online verfgbar unter
[IETF-Web].
[RFC 4303]
K ENT, S.: IP Encapsulating Security Payload (ESP). IETF RFC 4303, 2005. Online verfgbar unter [IETF-Web].
[RFC 4306]
K AUFMAN , C. (E DITOR ): Internet Key Exchange (IKEv2) Protocol. IETF RFC 4306, 2005.
[RFC 4346]
D IERKS , T. und E. R ESCORLA: The Transport Layer Security (TLS) Protocol Version 1.1.
[RFC 4422]
M ELNIKOV, A. und K. Z EILENGA (E DITORS ): Simple Authentication and Security Layer

(SASL). IETF RFC4422, 2006. Online verfgbar unter [IETF-Web].
[RFC 4632]
F ULLER , V. und T. L I: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. IETF RFC 4632, 2006. Online verfgbar unter [IETF-Web].
[RFC 4851]
C AM -W INGET, N., D. M C G REW, J. S ALOWEY und H. Z HOU: The Flexible Authentication

via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST). IETF RFC
[Sch06]
S CHNEIER , B.: Angewandte Kryptographie. Pearson Studium, Mnchen, 2006. Online

[SigG]
Gesetz ber Rahmenbedingungen fr elektronische Signaturen BGBl 2001, 876, 2001.
[SJ06]
S INNREICH , H. und A. J OHNSTON: Internet Communications using SIP. Wiley, New York,
NY, 2 Auflage, 2006.
[Sta03]
S TALLINGS , W.: Betriebssysteme. Pearson Studium, Mnchen, 4 Auflage, 2003.
[Sta05]
S TALLINGS , W.: Cryptography and Network Security. Prentice Hall, Upper Saddle River,
NJ, USA, 4 Auflage, 2005.
[Sti02]
S TINSON , D.: Cryptography: Theory and Practice. CRC Press, Boca Raton, FL, 2 Auflage,
2002.
[StrndG]
Entwurf eines Strafrechtsnderungsgesetzes zur Bekmpfung der Computerkriminalitt

(StrndG). Bundestagsdrucksache 16/3656 vom 30.11.2006, 2006.
[Tan02]
TANENBAUM , A. S.: Moderne Betriebssysteme. Pearson Studium, Mnchen, 2 Auflage,

2002.
[Tan03]
TANENBAUM , A. S.: Computernetzwerke. Pearson Studium, Mnchen, 4 Auflage, 2003.
[TKG]
Telekommunikationsgesetz (TKG). Telekommunikationsgesetz vom 22. Juni 2004 (BGBl. I

S. 1190), zuletzt gendert durch Artikel 273 der Verordnung vom 31. Oktober 2006 (BGBl.
I S. 2407).
[TMG]
Telemediengesetz (TMG). Telemediengesetz vom 26. Februar 2007 (BGBl. I S. 179).
[TW05]
T RICK , U. und F. W EBER: SIP, TCP/IP und Telekommunikationsnetze. Oldenbourg, Mnchen, 2 Auflage, 2005.
[Vog01]
VOGT, C.: Betriebssysteme. Spektrum Akademischer Verlag, Heidelberg, 2001.
[W3C HTML] HTML 4.01 Specication.

[W3C-Web].
337
W3C Recommendation, 1999.
Online verfgbar unter
[W05]
W HE , G.: Einfhrung in die Allgemeine Betriebswirtschaftslehre. Vahlen Verlag, Mnchen, 22. Auflage, 2005.
[X.501]
ITU-T X.501 Series X: Data Networks, Open System Communications and Security. Directory Information technology Open Systems Interconnection The Directory: Models. 2005.
Online verfgbar unter [ITU-Web].
[X.509]
ITU-T X.509 Series X: Data Networks, Open System Communications and Security. Directory Information technology Open Systems Interconnection The Directory: Public-key and
attribute certicate frameworks. 2005. Online verfgbar unter [ITU-Web].
Bei Standards ist jeweils die derzeit aktuellste Version angegeben.
Online-Referenzen
Da sich Online-Referenzen schnell ndern, haben wir in diesem Buch Verweise auf das
WWW wenn immer mglich vermieden und referenzieren hier nur die Startseite. Sie nden
eine ausfhrliche, kommentierte und regelmig aktualisierte Linksammlung mit Hinweisen zu Produkten, Herstellern und weiteren Hintergrundinformationen auf der Webseite zum
Buch unter
.
[Apa-Web]
Webseite der Apache Software Foundation.
[BSI-Web]
Webseite des Bundesamt fr Sicherheit in der Informationstechnik.
[CERT-Web]
Computer Emergency Response Team der Carnegie Mellon Universitt.
[Eth-Web]
Webseite von Ethereal.
[GnuPG-Web]
Webseite des GNU Privacy Guard.
[IEEE-Web]
Webseite des Institute of Electrical and Electronics Engineers.
[IETF-Web]
Webseite der Internet Engineering Task Force.
[Insec-Web]
.
Webseite von insecure.org.
[ITU-Web]
Webseite der International Telecommunication Union.
[Java-Web]
Website des Sun Developer Network.
[Moz-Web]
Webseite von Mozilla (Firefox, Thunderbird).
338
[MS-Web]
Webseite von Microsoft.
[NF-Web]
Webseite des netlter/iptables-Projekts.
[NIST-Web]
Webseite des National Institute of Standards and Technology.
[openSUSE-Web]
Webseite von openSUSE.
[Openswan-Web]
Webseite der openswan IPsec-Implementierung fr Linux.
[OpenVPN-Web]
Webseite von OpenVPN.
[OpenSSL-Web]
Webseite von OpenSSL.
[W3C-Web]
Webesite des World Wide Web Consortium.
[Samba-Web]
Webseite von Samba.
[SF-Web]
Webseite von SourceForge.
[Snort-Web]
Webseite von Snort.
[TCG-Web]
Webseite der Trusted Computing Group.
[Wir-Web]
Webseite von Wireshark.
Sachverzeichnis
berlastung, 223, 239, 240
berprufung von MAC-Adressen, 225
Abhren, 287
Access-Point, 225, 310
Account, 70
Active Server Pages, 265
ActiveX Control, 91
Ad-Hoc-Modus, 310
Address Resolution Protocol, 118, siehe ARP
Address-Spoong, 143
Administrationsfehler, 6
Administrator, 71
Adresse, 109
Advanced Encryption Standard, 26
Adware, 94
AES, 26
Aktion, 160
aktiver Inhalt, 88
ALG, 179
Alias, 126
Andere, 73
Anforderungsfehler, 6
Angriff, 5
aktiver, 5
passiver, 5
Anomalie, 220
Anonymisierdienst, 277
Anonymisierung, 170
Anonymitt, 141, 274
Anwendung, 83
kritische, 237
Apache, 273
Applet, 90
Application-Level-Gateway, 179
Applikationsschicht, 108
ARP, 118
Cache, 118
statische Eintrage, 144
Reply, 118
Request, 118
Response, 118
Spoong, 143
Assembler, 84
assoziieren, 310
Ausen eines Namens, 126
Ausfhren, 73
Ausfall, 238
Ausfallzeit, 237
Austauschbarkeit von Schichten, 106
Authentication Server, 302
Authenticator, 302
Authentikation, 2, 39
false-negative, 49
false-positive, 49
Authentizierung, 2
Authentizitt, 2, 39
Autorisation, 3
Auendienstmitarbeiter, 193
Auentter, 7
Backdoor, 94, 98
Backup, 5, 71
Bandbreite, 244
Bankkarte, 42
Sperrung, 42
Banner Grabbing, 231
Basic Input Output System, 75
Basic Service Set, 310
Baum, 126
BDSG, 11
Benutzer, 70
Benutzerakzeptanz, 9, 322
Benutzerauthentikation, 39
Benutzerfehler, 271
Benutzerfreundlichkeit, 324
Benutzerkonto, 70
Berechtigungskonzept, 70
Besitzer, 73
Betriebsart, 31
340
Betriebssystem, 69, 83, 89, 96, 118

Betriebssystemdistribution, 69
Bibliotheksfunktion, 72
Binding, 119
BIOS, 75
Block, 74
Boot-Sektor-Virus, 94
Booten eines Rechners, 75
Border Gateway Protocol, 115
Bot-Net, 94, 98
Bridge, 111, 226, 310
Broadcast-Adresse, 116
Broadcast-Medium, 110
Broadcast-Nachricht, 118
Browser, siehe Webbrowser, 264
Brute-Force, 21
BSI, 13, 320
BSS, 310
Buffer Overow, 84
Built-In Shellkommando, 256
Bundesamt fr Sicherheit in der Informationstechnik, 13, 320
Bundesdatenschutzgesetz, 11
Bytecode, 89
C, 84
C++, 84
CA, 55
Caesars Cipher, 37
Canary, 86
CCMP, 314
Certicate Authority, 55
Certicate Request, 55
Certicate Revocation List, 57
Chain, 172
Challenge-Response, 45, 50
Chiffretext, 18
Chiffretextblock, 26
Chiffrierschlssel, 18
Chiffrierverfahren, 18
Choke Point, 222
Chosen-Plaintext-Angriff, 23
Cipher Mode, 31
Ciphertext-Only-Angriff, 23
Class Library, 90
Classless Inter-Domain Routing, 115
Client, 118
Client/Server-Prinzip, 264
Sachverzeichnis
CMS, 255
Codec, 282
Compiler, 84
Computerforensik, 78, 219
Computerviren, 93
controlled Port, 306
Cookie, 265, 275
Setzen eines, 265
Third-Party, 275
Counter Mode, 35
Counter Mode with Cipher Block Chaining with
Message Authentication Code Protocol,
314
CRL, 57
Cross-Site-Scripting, 91
Cryptographic Message Syntax, 255
Data Encryption Standard, 26
Datagramm, 105, 123
Datagramm-Netze, 105
Datei
lesen, 72
schreiben, 72
Dateisystem, 72
Datenrahmen, 107
Datenrate, 106
Datenverbindungsschicht, 107
Dechiffrierschlssel, 18
Dechiffrierverfahren, 18
Default-Gateway, 115
Demilitarized Zone, 183, siehe DMZ
Denial-of-Service, 95, 144, 239
DES, 26
Designfehler, 6
DHCP, 117, 143
Dialer, 94
Dictionary Attack, 45
Dienst, 106
Dienstgte, 282
Dife-Hellman-Exchange, 27
digitale Signatur, 53
Distinguished Name, 59
Distributed-Denial-of-Service, 243
Distribution System, 310
DMZ, 183, 194
DNS, 125, 141, 230
Zone Transfer, 230
Domain Name Service, 125, siehe DNS
Sachverzeichnis
Domainname, 126
DoS, 95, 144, 239
Download, 88
drahtlose lokale Netzwerke, 225
DSL, 276
Dynamic Host Conguration Protocol, 117
dynamische Webseite, 264
EAP, 299, 308
FAST, 304
over LAN, 309
PEAP, 304
TLS, 300
TTLS, 304
Tunneled TLS Authentication Protocol, 304
EAPOL, 309
EBSS, 310
einloggen, 70
Einmalpasswort, 48
Eintrittsfolgen, 8
Eintrittswahrscheinlichkeit, 8
ElGamal, 29
Elliptic Curves, 29
Email, 249
Anhang, 249
Attachment, 249
Benutzerkonto, 249
externe, 187
Header, 249
Inbox, 250
Nachricht, 249
Postfach, 250
Server, 249
Virus, 94
Empfnger, 105, 107
Ende-zu-Ende-Verzgerung, 282
Entschlsselung, 18
Erwartungswert, 8
erweiterte Maschine, 69
Escrow, 77
Ethereal, 134
Ethernet, 110
Execute Disable Bit, 86
Export eines Dateisystems, 97
Extended Basic Service Set, 310
Extensible Authentication Protocol, 299, siehe
EAP
341
Faktoren, 40
FAST, 304
FAT, 74
FCS, 111
Fernmeldegeheimnis, 12
Firefox, 133
Firewall, 157, 158, 234, 259, 289
Flexible Authentication via Secure Tuneling Extensible Authentication Protocol, 304
Flow, 123
fopen(), 72
Forensik, 78, 219
Fragment, 108
Fragmentierung, 108, 113
Frame, 107
Frame Check Sequence, 111
FTP, 167
Gateway, 115, 288
Gertecontroller, 72
Gertetreiber, 72
Gerichtsverwertbarkeit, 219
Gnu Privacy Guard, 65
GPG, 65, 256
Gruppe, 73
H.323, 284
Hrten, 79
Handlungsalternative, 8
Hashfunktion, 53
Header, 109
Herunterladen, 88
Heuristik, 99
Home Ofce, 193
Hostname, 126
Hostteil, 116
Hot Spot, 214
html, 264
HTTP, 264
GET, 264
Methode, 264
POST, 264
Request, 264
Response, 264
HTTPS, 265
hybrides Verfahren, 29
Hyperlink, 264
Hypertext Markup Language, 264
342
Hypertext Transfer Protocol, 264, siehe HTTP

i-Node, 74
ICMP, 114, 142, 172, 228
Echo-Reply, 115
Echo-Request, 115, 132, 172, 240
Echo-Response, 115, 132, 172
Port-unreachable, 231
Redirect, 142
Idle-Scan, 233
IDS, 220, siehe Intrusion Detection System
IEEE 802.11, 225, 310
IEEE 802.1X, 306
IEEE 802.3, 110
ifcong, 128
IIS, 273
IKE, 199, 206
Exchange, 206
Initiator, 207
Responder, 207
Security Association, 206
IMAP, 250
Implementierungsfehler, 6
Information, 1
Informationseinheit, 105
Informationsuss, 105, 123
Informationsgesellschaft, 1
Informationstechnologie, 1
Infrastrukturmodus, 226, 310
Initialization Vector, 32, 313
Innentter, 7, 95, 158
Insellsung, 325
Installationsfehler, 6
Integritt, 2
Interface, 109
Internet, 109
Internet Control Message Protocol, 114, siehe
ICMP
Internet Explorer, 272
Internet Information Services, 273
Internet Key Exchange Protocol, 206, siehe IKE
Internet Message Access Protocol, 250
Internet Protocol, 112, siehe IP
Internet Security Association and Key Management Protocol, 206
interpretierte Sprache, 89
Intranet, 157
Intrusion, 220
Sachverzeichnis
Intrusion Detection, 220

Intrusion Detection System, 220
false-negative, 221
false-positive, 221
Fehlalarm, 221
hostbasiertes, 220
Inline-Sensor, 223
netzwerkbasiertes, 220
Out-of-Line-Sensor, 223
Sensor, 222
Intrusion Prevention, 223
IP, 112
Address-Spoong, 144, 241
Adresse, 112
Destination Address, 114
Fragmentierung, 113, 166
Quelladresse, 114
Source Address, 114
Zieladresse, 114
ip conntrack, 177
IPsec, 198
Authentication Header, 198
bypass, 200
discard, 200
Encapsulating Security Payload, 198
protect, 200
Security Association, 199
Security Association Database, 199
Security Policy Database, 199
Selektor, 199
Trafc Flow Condentiality, 203
Transport-Modus, 200
Tunnel-Modus, 200
iptables, 172
IPv4, 114
IPv6, 114
IRC, 98
irregulres Systemverhalten, 221
ISAKMP, 206
ISO/OSI-Referenzmodell, 106
IT, 1
IT-Grundschutz, 14, 320
IT-Sicherheit, 2
IT-Sicherheitsbeauftragter, 320
IT-Sicherheitskonzept, 320
IT-Sicherheitsleitlinie, 320
IT-Sicherheitsorganisation, 320
Sachverzeichnis
IT-Sicherheitsprozess, 320
IT-Sicherheitsstrategie, 320
Java, 89
Applet, 90
Bytecode, 89
Enterprise Edition Application Server, 273
Server Pages, 264
Servlets, 264
Virtual Machine, 89
JavaScript, 91
JVM, 89
KDC, 68
Kerckhoffsches Prinzip, 20
Kernel-Mode, 72
Key Distribution Center, 68
Key Escrow, 77
Keylogger, 45, 93
Klartext, 18
Klartextblock, 26
Knoten, 126
Known-Plaintext-Angriff, 23
Kommandozeileninterpreter, 74, 256
Kompartmentalisierung, 289
kontrollierter Port, 306
kritische Anwendung, 237
Kryptanalysis, 17
Kryptographie, 17
Kryptologie, 17
LAN, 110, 305
Laufzeit, 70
Lesen, 73
Link, 264
Linux, 71, 127, 171
Local Area Network, 110, 305
Lock-Step-Protokoll, 300
Logdatei, 98
Login, 70
Logoff, 70
Logout, 70
Loopback-Interface, 129
Loose Source Routing, 156
ls, 74
MAC
Address-Spoong, 143
343
Adresse, 110
Klonen einer Adresse, 143
Makro, 97
Makrosprache, 97
Makrovirus, 94, 96
Malware, 88, 93, 147
Man-in-the-Middle, 52, 304, 311
Man-Pages, 128
Massenspeicher, 72
Master Key, 292
Master Key Identier, 293
Master Secret, 52
Match, 160
Medientransport, 281
Mehrbenutzerbetrieb, 70
Mehrfaktorauthentikation, 40
menschliches Versagen, 5
Message Integrity Code, 314
MIC, 314
Microsoft Internet Explorer, 272
Microsoft Internet Information Services, 273
Microsoft Windows, 71
MIME, 255
Mirrorport, 223
Mixer, 283
MKI, 293
Mobile IP, 243
Modem, 94
monolithisches System, 106
Mozilla Firefox, 133, 272
Mozilla Thunderbird, 62
Multimedia, 281
Multipurpose Internet Mail Extensions, 255
Nachricht, 3
Nachrichtenbertragung, 106
Name Server, 126
NAPT, 167
NAT, 117, 140, 167, 227
Binding, 169
Cone, 169
Full Cone, 170
Port Restricted Cone, 170
Restricted Cone, 170
symmetrisches, 169
Netlter, 171
Network Address Port Translation, 167
Network Address Translation, 167, siehe NAT
344
Network Tap, 224

Netzadresse, 116
Netzwerk, 105
paketbasiert, 105
Netzwerkberwachung, 219
Netzwerkkonvergenz, 281
Netzwerklaufwerk, 97
Netzwerkmaske, 115
Netzwerkschicht, 107
Netzwerkteil, 116
NFS, 78
nicht-selbstreplizierend, 95
Nichtabstreitbarkeit, 2, 53
Nonce, 208
NTFS, 74
Nutzdaten, 108
Nutzlast, 108
NX Bit, 86
One-Time-Pad, 23
One-Time-Passwort, 48
Online-Durchsuchung, 15
Online-Shop, 265
Open Mail Relay, 253
Open Shortest Path First, 115
Open System Authentication, 312
OpenPGP, 65, 256
OpenSSL, 59
OpenSuse, 128
OpenVPN, 212
Organizationally Unique Identier, 110
OS-Fingerprinting, 233
OUI, 110, 227
Packet Sniffer, 134
Packet Snifng, 138
Paket, 105, 107
Paketlter, 159
dynamischer, 164
statischer, 162
Paketisierungsintervall, 282
Parking-Lot-Scenario, 311
Partition, 75
Passwort, 41, 70
Passwortraum
Gre, 41
Patch, 100
Payload, 108
Sachverzeichnis
PEAP, 304
Perimetersicherheit, 1, 305
Perl, 265
Personal Firewall, 190
Personal Identication Number, 40, 42
personenbezogene Daten, 11
PGP, 65, 256
Pharming, 272
Phishing, 271
PHP, 264
Physikalische Schicht, 107
PIN, 40, 42
Ping, 132, 172, 228
of Death, 240
Sweep, 229
plattformunabhngig, 89
Point-to-Point Protocol, 112, siehe PPP
Policy, 158
POP, 250
PASS, 251
USER, 251
Port, 118, 306
Forwarding, 257
privileged, 119
uncontrolled, 306
unkontrollierter, 306
unreachable, 231
Portabilitt, 90
Portnummer, 118
Portscanning, 230
Post Ofce Protocol, 250
PPP, 112, 299
prventive Manahme, 219
Pre-Shared-Key, 315
Pretty Good Privacy, 65
private IP-Adresse, 117
Produktchiffre, 21
Prol, 57, 284
Programmvirus, 96
Protected Extensible Authentication Protocol, 304
Protokoll, 106
unzuverlssiges, 112
verbindungsloses, 112
zustandsbasiertes, 265
zustandsloses, 265
Protokollfamilie, 106
Proxy, 179, 259
Sachverzeichnis
Prozess, 70, 84
Prozesswechsel, 70
Pseudoparallelitt, 70
pseudozufallig, 33
PSK, 315
Public-Key-Verfahren, 25
puffern, 244
QoS, 282
Quality of Service, 282
Rcksprungadresse, 85
RA, 55
Race Condition, 86
RADUIS, 309
Rahmen, 107
RC4, 313
reaktive Manahme, 219
Realtime Transport Protocol, 283
Realzeitkommunikation, 281
Redundanz, 238
Referenzmodell, 106
Regel, 158, 160
Regelkette, 160
Registration Authority, 55
registrieren, 275
Remote-Access, 193
Replay Attack, 199, 293, 313
Replizierung, 239
Resource Record, 126
Ressourcen, 70
Ressourcenverwaltung, 69
Restrisiko, 9
Reverse-DNS-Lookup, 141
Risiko, 7
rlogin, 256
Robust Security Network Association, 313
Rogue-Access-Point, 311
Root Kit, 94, 98
Root-CA, 55
Root-Server, 126
Round Trip Time, 228
Router, 115
Routing, 107, 113
Routing Information Protocol, 115
Routingprotokoll, 115
Routingtabelle, 115
RSA, 29
345
RSNA, 313
RTCP, 284
RTP, 283
RTP Control Protocol, 284
S/MIME, 64, 255
Sabotage, 238
Salt, 45
Samba, 78
Sandboxing, 90
SASL, 253
Scan, 227
Schadprogramm, 93
Schicht, 106
Schlsselraumgre, 41
Schnittstelle, 106
abstrakte, 69
Schreiben, 73
Schwachstelle, 6
intrinsische, 6
Secure MIME, 255
Secure Real-time Transport Protocol, 292
Secure RTCP, 293
Secure Shell, 256
Secure Socket Layer, 266
Security through Obscurity, 19
Segment, 108, 118
selbstreplizierend, 95
Selbstsynchronitt, 313
Semaphor, 88
Sender, 105, 107
Server, 106, 118
Service, 106
Service Level Agreement, 237
Service Provider, 237
Session, 284
Session Initiation Protocol, 284, siehe SIP
Session Key, 27, 52, 292, 303
Session-Border-Controller, 179
setgid, 80
setuid, 74
Shared Key Authentication, 312
Shell, 74, 256
Sicherheitsbeauftragter, 320
Sicherheitskonzept, 320
Sicherheitskopie, 71
Sicherheitslcke, 6
Sicherheitsleitlinie, 320
346
Sicherheitsorganisation, 320
Sicherheitsprozess, 320
Sicherheitsstrategie, 320
Sicherungskopie, 5
Sign-In, 70
Signalisierung, 281, 284
Signatur, 99, 222
Silence Suppression, 283
Simple Authentication and Security Layer, 253
Simple Mail Transfer Protocol, 250
Single-Sign-On, 43
SIP, 284
ACK, 284
BYE, 285
CANCEL, 285
Digest, 295
INVITE, 284
NOTIFY, 285
REGISTER, 284
Request, 284
Response, 284
SUBSCRIBE, 285
SIPS, 295
Skalierbarkeit, 205
Skriptsprache, 91
SLA, 237
Smart-Card, 40, 48
SMB, 78
SMTP, 250
Extensions, 253
Smurf-Angriff, 245
Snifng, 126
Social Engineering, 5, 101, 271
Socket, 133
SOCKS, 259
Softphone, 287
Source Routing, 142
Spam, 95, 253
Spam over IP Telephony, 288
Spammer, 253
Speicherallokation, 85
speicherresidenter Virus, 96
Sperrpunkt, 222
SPIT, 288
Split Tunneling, 213
Spyware, 93
SRTCP, 293
Sachverzeichnis
SRTP, 292
SSH, 78, 256
dynamisches Port Forwarding, 259
Local Port Forwarding, 258
Port Forwarding, 257
Remote Port Forwarding, 258
Transportprotokoll, 257
Verbindungsprotokoll, 257
SSL, 266
Strung, 238
Stack, 85
Standardbibliothek, 90
Station, 107, 310
statische Webseite, 264
Store-and-Forward-Prinzip, 105
Strict Source Routing, 156
String, 85
Struktur
dezentrale, 138
Subdomain, 126
Substitution, 20
monoalphabetische, 20
Supplikant, 302
Switch, 111
symmetrisches Verfahren, 25
SYN-Flood, 240
System Call, 72, 96
Systemadministrator, 71
Systemmissbrauch, 221
Systemprogramm, 83
Systemressourcen, 69
Systemressourcenverwaltung, 69
Systemstart, 70, 94
TAN, 40
TCP, 118, 244
ACK, 119
Acknowledgement Number, 119
Anfangssequenznummer, 119
Congestion-Avoidance, 245
Connect-Scan, 230
Control-Bits, 120
Destination Port, 118
Empfangerberlastkontrolle, 118
FIN-Flag, 121
Handshake, 118
Initial Sequence Number, 119
Netzwerkberlastkontrolle, 118, 244
Sachverzeichnis
Piggybacking, 119
Portnummer, 118
Quellport, 118
Segment, 118
Sequence Number, 119
Slow-Start, 245
Source Port, 118
SYN-Flag, 121
SYN-Scan, 232
Three-Way-Handshake, 121
Verbindungsaufbau, 118
Zielport, 118
Zustandsdiagramm, 122
TCP/IP, 106
tcpdump, 134
Telefonie, 12, 237, 281
Telekommunikationsdienst, 12
Telekommunikationsgesetz, 12
Telemediengesetz, 13
telnet, 256
Temporal Key Integrity Protocol, 314
Terminal, 256
Three-Way-Handshake, 145
Thunderbird, 62
Time-of-Check-Time-of-Use, 87
Timeout, 118
TKG, 12
TKIP, 314
TKIP Sequence Counter, 314
TLS, 266
Alert Protocol, 267
Application Data Protocol, 267
Change Cipher Spec Protocol, 267
Handshake Protocol, 267
Record, 267
Record Protocol, 266
Record Type, 267
TMG, 13
TOCTOU, 87
Token, 40, 47
Top-Level Domain, 126
Trailer, 109
Transaction Authentication Number, 40
Transitnetz, 242
Transmission Control Protocol, 118, siehe TCP
Transport Layer Security, 266, siehe TLS
Transportprotokoll
347
unzuverlssiges, 108
verbindungsloses, 108
verbindungsorientiertes, 108
zuverlssiges, 108
Transportschicht, 108
Transposition, 20
Trapdoor, 94
Trojaner, 93
trusted Applet, 90
Trusted Computing Group, 77
TSC, 314
TTLS, 304
Tunneled TLS Authentication Protocol, 304
Tunneln, 187
Uniform Resource Identier, 264
Uniform Resource Locator (URL), 264
Unix-artig, 71, 72
Unsicherheit, 8
Unterbrechung, 287
untrusted Applet, 90
Update, 100
User-Agent, 249, 264
User-Mode, 72
VBA, 97
Verbindlichkeit, 2, 53
Verfgbarkeit, 2, 237
Vermittlungsstation, 105
Verschlsselung, 18
Verteilung
geographische, 238
Vertraulichkeit, 2
Verweis, 264
Verzeichnis, 72
Virenscanner, 99
Virtual Circuit-Netze, 105
Virtual LAN, 111
Virtual Private Network, 193, siehe VPN
virtuelle Adresse, 84
virtuelle Maschine, 89
virtueller Adressraum, 84
Virus, 93, 96
Visual Basic for Applications, 97
VLAN, 111
Voice over IP, 12, 139, 167, 245, 281
VoIP, 12, 139, 167, 245, 281
VPN, 153, 193, 290
348
Sachverzeichnis
Client, 195
Server, 195
Wrterbuchangriff, 45
War Driving, 311
Warenkorb, 265
Web of Trust, 65
Web-Proxy, 182
Webbrowser, 88, 133, 264
Webfrontend, 187
Webmail, 187
Webseite, 264
Webserver, 264
WEP, 312
Key, 312
Wi-Fi Alliance, 315
Wi-Fi Protected Access, 315
Windows, 71
Wired Equivalent Privacy, 312
Wireless Local Area Network, 310
Wireshark, 134
WLAN, 143, 225, 310
World Wide Web, 262

WPA, 315
Wurm, 93, 97
WWW, 262
X.501, 59
X.509, 57
Zertikat, 57, 268
XOR, 23
XSS, 91
Zertikat, 55
Zertizierung, 321
Zielsystem, 8
Zombie, 94, 98
Zugriffskontrolle, 72
Zugriffsrechte, 73
Zugriffsrechtemanagement, 75
zustandsbehaftet, 164
zustandslos, 162
Zwischenstation, 107, 108

Netzwerk - Und Datensicherheit - Eine Praktische Einführung

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Netzwerk - Und Datensicherheit - Eine Praktische Einführung

Uploaded by

Copyright:

Available Formats

Martin Kappes

Netzwerk- und Datensicherheit

Bibliografische Information der Deutschen Nationalbibliothek

Kryptographische Prinzipien und Methoden

Betriebssysteme und ihre Sicherheitsaufgaben

Netzwerke und Netzwerkprotokolle

10 Virtual Private Networks (VPN)

15 Sicherheit auf der Datenverbindungsschicht und in lokalen Netzen

15.5.2 Weiterfhrende Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . 317

1.1 Warum IT-Sicherheit

1.2 Ziele von IT-Sicherheit

1.2 Ziele von IT-Sicherheit

1.3 Angriffe auf IT-Sicherheit

1.3 Angriffe auf IT-Sicherheit

1.4 Risiken und Unsicherheit

1.3.3 Ziele eines Angriffs

1.4 Risiken und Unsicherheit

1.5 IT-Sicherheit in der Praxis

1.5 IT-Sicherheit in der Praxis

1.6 Organisatorische Grundlagen der IT-Sicherheit

1.6.2 IT-Sicherheit als Prozess

1.7 Rechtliche Grundlagen und Rahmenbedingungen in Deutschland

Abbildung 1.1: IT-Sicherheit als Prozess.

erforderlich sein, wenn die bestehenden Sicherheitsanforderungen durch das gegenwrtige

1.7 Rechtliche Grundlagen und Rahmenbedingungen in

1.7 Rechtliche Grundlagen und Rahmenbedingungen in Deutschland

1.7.5 Bundesamt fr Sicherheit in der Informationstechnik

1.9.2 Weiterfhrende Aufgaben

Abbildung 2.1: Beziehungen zwischen Kryptologie, Kryptographie und Kryptanalysis.

2 Kryptographische Prinzipien und Methoden

Abbildung 2.2: Einfaches Modell.

2 Kryptographische Prinzipien und Methoden

eine monoalphabetische Substitution deniert, in der das Wort DONAUDAMPFSCHIFFAHRT

2.2.2 Sicherheit von Verschlsselungsverfahren

Adams, Per Anhalter durch die Galaxis, Heyne Verlag

2 Kryptographische Prinzipien und Methoden

Zeit zum Durchtesten aller Schlssel

2n /(3, 1536 1013 ) Jahre

Tabelle 2.1: Wertetabelle der XOR-Verknpfung.

2 Kryptographische Prinzipien und Methoden

2.3 Symmetrische Verfahren und Public-Key-Verfahren

2.3 Symmetrische Verfahren und Public-Key-Verfahren

2.3.2 Symmetrische Verfahren

2 Kryptographische Prinzipien und Methoden

Abbildung 2.3: Symmetrische Kryptographie.

Die in der Informatik tatschlich eingesetzten symmetrischen Verfahren basieren hinsichtlich

2.3 Symmetrische Verfahren und Public-Key-Verfahren

Tabelle 2.2: Wichtige symmetrische Verschlsselungsverfahren.

2 Kryptographische Prinzipien und Methoden

Abbildung 2.4: Public-Key-Kryptographie.

2.3 Symmetrische Verfahren und Public-Key-Verfahren

+ einfach in Hard- und Software

Tabelle 2.3: Vergleich symmetrischer Verfahren und Public-Key-Verfahren.

2.3.4 Hybride Verfahren

2 Kryptographische Prinzipien und Methoden

Verschlsselung durch symmetrisches

Abbildung 2.5: Schematischer Ablauf hybrider Verfahren.

2 Kryptographische Prinzipien und Methoden

Abbildung 2.7: Cipher Block Chaining.

2.4.2 Cipher Block Chaining

Abbildung 2.8: Cipher Feedback Mode.

2.4.3 Cipher Feedback Mode und Output Feedback Mode

2 Kryptographische Prinzipien und Methoden