Warenkorb
0 Artikel | US$ 0,00
ID 7060
Fuchs, Florian: Sicherheit von Internet- und Intranetdiensten
Hamburg: Diplomica GmbH, 2003
Zugl.: Universität Klagenfurt, Universität, Diplomarbeit, 2001
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
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 wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
Inhaltsverzeichnis
1 Einleitung
11
2 Grundbegriffe
13
2.1 Authentizit¨at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2 Integrit¨at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3 Vertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.4 Beweisbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.5 Anonymit¨at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.6 Verf¨ugbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.7 Symmetrische Verschl¨usselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.8 Asymmetrische Verschl¨usselung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.9 Hashfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.10 Zufallszahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.11 Covert Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.12 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.13 Digitale Signaturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3 OSI Referenz Modell
23
3.1 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3 Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.4 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.5 Session Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.6 Presentation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.7 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.8 TCP/IP Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.8.1
Host-to-Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.8.2
Internet Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3
4
INHALTSVERZEICHNIS
3.8.3
Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.8.4
Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4 Allgemeine Sicherheitsprobleme
29
4.1 Denial-of-Service Attacke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2 Man-in-the-middle Attacke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.3 Sniffing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.4 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.5 Trojanische Pferde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.6 Viren und W¨urmer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5 Bedeutende Angriffe in der Vergangenheit
33
5.1 Internetwurm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.2 Melissa-Virus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.3 Distributed Denial-of-Service-Attacken . . . . . . . . . . . . . . . . . . . . . . . .
38
5.4 Echelon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6 Netzwerkprotokolle und deren Sicherheitsbedrohungen
45
6.1 IP Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.2 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.3 PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.4 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.4.1
Authentizit¨atsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.4.2
Verf¨ugbarkeitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.5 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.5.1
Authentifizierungsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.5.2
Integrit¨ats- und Vertraulichkeitsprobleme . . . . . . . . . . . . . . . . . .
54
6.5.3
Verf¨ugbarkeitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6.5.4
Beweisbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
6.5.5
Anonymit¨at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.6 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.7 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.8 Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
6.9 rlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
6.10 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
6.10.1 Authentizit¨ats- und Integrit¨atsprobleme . . . . . . . . . . . . . . . . . . .
65
6.10.2 Verf¨ugbarkeitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
INHALTSVERZEICHNIS
5
6.10.3 Weitere Sicherheitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.11 SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
6.11.1 Authentizit¨atsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
6.11.2 Integrit¨atsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.11.3 Vertraulichkeitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.11.4 Weitere Sicherheitsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.12 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.12.1 Authentifizierungsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . .
74
6.12.2 Integrit¨ats- und Vertraulichkeitsprobleme . . . . . . . . . . . . . . . . . .
75
6.12.3 Anonymit¨atsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.13 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.13.1 Authentizit¨atsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
6.13.2 Integrit¨ats- und Vertraulichkeitsprobleme . . . . . . . . . . . . . . . . . .
78
7 Sicherheitsmaßnahmen
79
7.1 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
7.1.1
Paketfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
7.1.2
Application Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
7.1.3
Bastion Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
7.1.4
DMZ oder Perimeternetz . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
7.1.5
Personal Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
7.2 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
7.3 Intrusion Detection Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
8 Verbesserte Protokolle
91
8.1 PPTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
8.1.1
Authentifizierung in Microsofts PPTP . . . . . . . . . . . . . . . . . . . .
91
8.1.2
Vertraulichkeit in Microsofts PPTP . . . . . . . . . . . . . . . . . . . . .
93
8.2 IPv6 und IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
8.2.1
Encapsulating security payload . . . . . . . . . . . . . . . . . . . . . . . .
94
8.2.2
Authentication Header (AH) . . . . . . . . . . . . . . . . . . . . . . . . .
96
8.2.3
Internet key exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
8.3 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
8.4 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.5 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.6 Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.7 Anonyme Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6
INHALTSVERZEICHNIS
8.7.1
Anonyme Proxyserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
8.7.2
Crowds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.7.3
Onion Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9 Schlußwort
123
A Abk¨
urzungen
125
Literaturverzeichnis
129
Abbildungsverzeichnis
2.1 Beispiel f¨ur asymmetrische Verschl¨usselung . . . . . . . . . . . . . . . . . . . . .
17
3.1 OSI-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2
¨
Ubertragung mit falscher Reihenfolge . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.3 TCP/IP Reference Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5.1 Distributed Denial-of-Service-Attacken (nach [CER99]) . . . . . . . . . . . . . . .
38
6.1 ARP-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.2 ARP-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
6.3 PPP-Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.4 TCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.5 UDP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.6 DNS-Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.7 DNS-Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.8 DNS-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6.9 FTP-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
6.10 FTP-DoS Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.11 SMTP-Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
6.12 Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.13 NFS-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
7.1 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
7.2 IP Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
7.3 Bastion Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
7.4 Perimeternetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
7.5 Virtual Private Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
8.1 Unterschied IP-Paket mit und ohne ESP . . . . . . . . . . . . . . . . . . . . . . .
95
8.2 ESP Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
7
8
ABBILDUNGSVERZEICHNIS
8.3 IKE: Main Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
8.4 IKE: Aggressive Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
8.5 IKE: Quick Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
8.6 SSL Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.7 SSL Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
8.8 SSH Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.9 hybride Verschl¨usselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.10 Kerberos allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.11 Kerberos 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.12 Kerberos 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8.13 Anonymer Proxyserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.14 Crowds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.15 Onion Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Tabellenverzeichnis
5.1 angebliche IXPs der NSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
6.1 ICMP Nachrichten Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2 g¨angige TCP Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.3 TCP Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
6.4 FTP Kommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.5 FTP-Antworten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.6 SMTP Kommandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
6.7 HTTP-Antworten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
8.1 Ports f¨ur SSL Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
8.2 S/MIME-Content Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.3 base64 Alphabet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
9
Kapitel 1
Einleitung
Netzwerke gewinnen immer mehr an Bedeutung. W¨ahrend noch vor einigen Jahren die mei-
sten Heimcomputer nicht vernetzt waren, hat sich das mit der Verbreitung des Internets rasch
ge¨andert, aus ehemaligen Einzelplatzrechnern wurden Teilnehmer in einem großen Netzwerk.
Auch viele Firmen haben ihre bestehenden Systeme in das Internet eingebunden.
Dadurch ist aber auch das Sicherheitsbed¨urfnis gestiegen. Heute ist es f¨ur einen Angreifer kein
Problem mehr zum Beispiel von Europa aus eine Firma in Australien erfolgreich zu attackieren
und dieser einen großen wirtschaftlichen Schaden zuzuf¨ugen. Aber auch im privaten Bereich
gewinnt die Systemsicherheit immer mehr an Bedeutung, da Personen ihre Privatsph¨are sch¨utzen
wollen.
In dieser Diplomarbeit m¨ochte ich verschiedene Aspekte von Internet- und Intranetsicherheit be-
handeln. In Kapitel 2 erkl¨are ich die wichtigsten Grundbegriffe im Zusammenhang mit System-
sicherheit, damit auch Leser, die mit diesem Thema nicht so vertraut sind, die nachfolgenden
Kapitel leicht verstehen k¨onnen. Kapitel 3 beschreibt kurz das OSI- und das TCP-Modell und den
allgemeinen Aufbau von Netzwerken. Anschließend werden in Kapitel 4 allgemeine Sicherheits-
probleme angef¨uhrt, auf die in der Arbeit ¨ofter eingegangen wird. Um dem Leser die Relevanz
von Sicheheitsbedrohungen n¨aher zu bringen, habe ich in Kapitel 5 einige bedeutende Angriffe
beschrieben.
Auf Sicherheitsprobleme in bestehenden Netzwerkprotokollen gehe ich in Kapitel 6 n¨aher ein.
Dabei beschreibe ich zuerst einige Netzwerkprotokolle und gehe dann anschließend jeweils auf
deren Sicherheitsprobleme ein. Die Protokolle wurden von mir so ausgew¨ahlt, daß sie einerseits
sehr bekannt sind und h¨aufig eingesetzt werden, andererseits aber m¨oglichst viele Sicherheits-
probleme aufwerfen. Einige Sicherheitsmaßnahmen, die getroffen werden k¨onnen um Systeme zu
sichern, stelle ich in Kapitel 7 vor. In Kapitel 8 zeige ich exemplarisch verbesserte Protokolle, die
mehr Sicherheit bieten sollen. Einige von diesen weisen aber auch Schw¨achen auf, die ich dann
jeweils beschreibe. In Kapitel 9 bringe ich eine kurze Zusammenfassung, die die wesentlichen
11
12
Einleitung
Aspekte von Sicherheit im Internet und Intranet noch einmal betont.
Wesentlich ist jedoch, daß sich der Leser immer vor Augen h¨alt, daß "Sicherheit wie eine Ket-
te ist, die so stark ist wie ihr schw¨achstes Glied. Sicherheit ist ein Prozeß und kein Produkt"
(vgl. [Sch00b], Seite xii). Damit ist gemeint, daß die Sicherheit eines Systems immer von meh-
reren Faktoren abh¨angt, wobei sich die Faktoren zum Beispiel durch neue Erkenntnisse oder
Anforderungen mit der Zeit ¨andern k¨onnen.
Kapitel 2
Grundbegriffe
In diesem Kapitel m¨ochte ich einige Grundbegriffe in Zusammenhang mit Systemsicherheit auf
einfache Weise erkl¨aren. Die Liste ist nicht vollst¨andig, soll aber dem Leser rasch einen ¨
Uberblick
liefern. Als weiterf¨uhrende Literatur kann ich [Sch00b], [MOV97] und [RS92] empfehlen.
2.1
Authentizit¨
at
Die Authentizit¨at garantiert dem Empf¨anger einer Nachricht, daß die Daten tats¨achlich von
demjenigen sind, der vorgibt der Sender zu sein. Der Empf¨anger kann sich also darauf verlassen,
daß niemand anderer diese Nachricht geschickt hat.
2.2
Integrit¨
at
Die Integrit¨at garantiert dem Empf¨anger einer Nachricht, daß die Daten nicht ver¨andert wurden.
Zusammen mit der Authentizit¨at gew¨ahrleistet die Integrit¨at, daß die Nachricht unver¨andert
vom Sender zum Empf¨anger gelangt ist und daß diese auch tats¨achlich vom Sender stammt.
2.3
Vertraulichkeit
Weder Authentizit¨at noch Integrit¨at garantieren allerdings, daß ein Angreifer die Nachricht nicht
m¨oglicherweise w¨ahrend der ¨
Ubertragung gelesen hat. Erst die Vertraulichkeit bedeutet, daß die
Nachricht tats¨achlich nur von den daf¨ur autorisierten Personen gelesen werden kann.
13
14
Grundbegriffe
2.4
Beweisbarkeit
Die Beweisbarkeit erm¨oglicht es auch gegen¨uber Dritten zu zeigen, daß eine Nachricht von ei-
nem bestimmten Sender stammt. Auf den ersten Blick mag dieser Punkt etwas verwunderlich
erscheinen, da bereits die Authentizit¨at zeigt, daß eine Nachricht tats¨achlich von einem bestimm-
ten Sender ist. Das ist aber, wie bereits in Abschnitt 2.1 beschrieben nur insofern richtig, als
der Empf¨anger sicher sein kann, daß die Nachricht tats¨achlich von einem bestimmten Sender
stammt. Der Empf¨anger kann aber einem Dritten gegen¨uber nicht beweisen, daß die Nachricht
von diesem Sender verschickt wurde.
Das kann man mit einem einfachen Beispiel zeigen: Alice und Bob m¨ochten einander Briefe
schicken, bei denen die Authentizit¨at gew¨ahrleistet ist. Sie vereinbaren ein geheimes Codewort.
Jede Nachricht, egal von wem sie stammt, muß dieses Codewort enthalten, denn dann wissen
die beiden, daß die Nachricht vom anderen gesendet wurde. Zus¨atzlich verschl¨usseln sie die
Nachricht, sodaß ein Angreifer, der die Nachricht abf¨angt, das Codewort nicht erf¨ahrt.
Bekommt nun zum Beispiel Bob eine Nachricht, die das Codewort enth¨alt, kann er sicher sein,
daß diese von Alice ist, da nur sie und er das Codewort kennen. Er kann aber einem Dritten
gegen¨uber nicht beweisen, daß die Nachricht von Alice ist, selbst wenn er dem Dritten das
Codewort verr¨at. Er h¨atte die Nachricht n¨amlich auch selber schreiben k¨onnen, da auch er das
Codewort kennt.
Diese Form der Beweisbarkeit kann aber sehr entscheidend sein, wenn eine Nachricht einen
rechtsverbindlichen Charakter haben soll. Ob die Nachricht dann tats¨achlich rechtsverbindlich
ist, h¨angt von mehreren rechtlichen Faktoren ab (vgl. [Bre99] und [MSPS99]).
Ein weiterer Aspekt der Beweisbarkeit ist, daß ein Sender beweisen k¨onnen muß eine Nachricht
an den Empf¨anger geschickt zu haben. Diese Form der Beweisbarkeit wird bei der herk¨ommli-
chen Briefpost meistens mittels Einschreiben realisiert, wobei bei Einschreiben der Inhalt einer
Sendung nicht best¨atigt wird (es wird nun best¨atigt, daß eine Sendung abgeschickt wurde).
2.5
Anonymit¨
at
In der heutigen Zeit nimmt der Einsatz von Computern und Netzwerken st¨andig zu. Dadurch
wird es immer einfacher, genaue Profile von Menschen zu erstellen und viele sind der Ansicht,
daß wir der von George Orwell beschriebenen Welt in seinem Werk "1984" nicht mehr so fern
sind.
Auf der anderen Seite ist es nat¨urlich manchmal wichtig zu wissen, mit wem man kommuni-
ziert. Beispielsweise haben die Betreiber von einigen Sites, die anonyme Proxies anbieten (siehe
Abschnitt 8.7) bemerkt, daß ¨uber ihr Service h¨aufig Zahlungen mit gestohlenen Kreditkarten
2.6
Verf¨
ugbarkeit
15
geschickt wurden (vgl. [RR99]). Auch hat der Staat im Bereich der Verfolgung von Straftaten
sicher ein berechtigtes Interesse herauszufinden, wer mit wem kommuniziert hat.
Auch die Vertraulichkeit erlaubt etwas Anonymit¨at, da die Nachricht nur von den daf¨ur be-
stimmten Personen gelesen werden kann. Allerdings erkennt ein Angreifer trotzdem, wer mit
wem kommuniziert, da er den Weg der Nachricht verfolgen kann. Das Wissen dar¨uber, daß zwei
Personen miteinander kommunzieren, reicht aber oft schon f¨ur einen Angreifer aus, um f¨ur ihn
wichtige Schl¨usse ziehen zu k¨onnen.
2.6
Verf¨
ugbarkeit
Da wir uns heute immer mehr auf Computer und Netzwerke verlassen, spielt die Verf¨ugbarkeit
dieser Systeme eine sehr große Rolle. Es ist heute nicht mehr akzeptabel, daß Rechner in Atom-
kraftwerken, Flugzeugen, Banken, Rettungsleitstellen, etc. ausfallen, da davon Menschenleben
oder die Wirtschaft abh¨angen.
Um die Verf¨ugbarkeit zu gew¨ahrleisten muß man immer das gesamte System betrachten. Es
macht keinen Sinn, wenn s¨amtliche Rechner ausfallssicher sind, aber beispielsweise nicht an eine
Notstromversorgung angeschlossen sind. Deshalb gehe ich in meiner Arbeit nur fallweise auf
dieses Thema ein.
2.7
Symmetrische Verschl¨
usselung
Die symmetrische Verschl¨usselung war lange Zeit die einzige Form der Verschl¨usselung. Bei dieser
Form der Verschl¨usselung einigen sich Sender und Empf¨anger auf einen gemeinsamen, geheimen
Schl¨ussel und einen gemeinsamen Verschl¨usselungsalgorithmus.
Ein Beispiel f¨ur einen ganz simplen Verschl¨usselungsalgorithmus ist die sogenannte C¨asar-Chiffre
(benannt nach C¨asar, weil dieser davon Gebrauch machte). Es handelt sich dabei um eine ein-
fache Verschiebechiffre.
Bei der C¨asar-Chiffre wurden die Buchstaben einfach um drei Zeichen verschoben, aus einem A
wurde ein D, aus einem B ein E, aus einem Z ein C, usw.
Allgemeiner formuliert kann man den Verschl¨usselungsalgorithmus so beschreiben: Jedem Buch-
staben im Alphabet wird eine Zahl zugeordnet, beginnend bei A = 0 bis Z = 25. C =
(E + k) mod 26, wobei C f¨ur den verschl¨usselten Buchstaben steht, E f¨ur den Entschl¨ussel-
ten und k f¨ur den Schl¨ussel. F¨ur den Schl¨ussel gilt allerdings, daß k < 26 sein muß, da bei
k = 26 oder einem Vielfachen von 26 keine Verschl¨usselung stattfinden w¨urde und k > 26 keinen
Sinn macht, da sich die Werte aufgrund der modulo-Division ohnehin nur zwischen 0 und 25
bewegen.
16
Grundbegriffe
Dieser Algorithmus ist nat¨urlich sehr leicht zu brechen. Einerseits ist der Schl¨usselraum (Anzahl
der m¨oglichen Schl¨ussel) sehr klein, andererseits kann man mit Hilfe von H¨aufigkeitstabellen die
Nachrichten rasch brechen.
H¨aufigkeitstabellen geben an, wie oft ein Buchstabe in einer bestimmten Sprache durchschnittlich
vorkommt. Da bei einem Substitutionsverfahren jedes Zeichen immer genau durch ein anderes
ersetzt wird, bleibt die Verteilung der Zeichen auch nach der Verschl¨usselung enthalten. Da in
der deutschen Sprache zum Beispiel der Buchstabe E der am h¨aufigsten verwendete ist, wird mit
ziemlich hoher Sicherheit auch im verschl¨usselten Text das am h¨aufigsten verwendete Zeichen
ein E repr¨asentieren.
In der Zwischenzeit sind die Verschl¨usselungsalgorithmen wesentlich sicherer geworden. Bekannte
Beispiele f¨ur symmetrische Verschl¨usselungsalgorithmen sind heute IDEA, Rijndael und 3DES
(Triple DES).
2.8
Asymmetrische Verschl¨
usselung
Das Hauptproblem der symmetrischen Verschl¨usselungsalgorithmen besteht darin, daß sich Sen-
der und Empf¨anger auf einen geheimen Schl¨ussel einigen m¨ussen. Um sich auf diesen Schl¨ussel
zu einigen, ben¨otigen sie einen sicheren Kanal. In der Praxis heißt das, daß sie sich treffen
m¨ussen, um einen Schl¨ussel zu vereinbaren. Ein weiteres Problem in diesem Zusammenhang ist,
daß wenn jemand mit vielen Personen kommunizieren will, er mit jeder Person einen eigenen
Schl¨ussel vereinbaren muß. Diese Personen wiederum m¨ussen ebenfalls mit s¨amtlichen Personen
Schl¨ussel vereinbaren, mit denen sie kommunizieren wollen. Wollen also N Personen miteinander
kommunizieren, m¨ussen ingesamt N · (N - 1)/2 Schl¨ussel vereinbart werden.
Das Ziel der asymmetrischen Verschl¨usselung ist, daß zwei oder mehrere Partner miteinander
verschl¨usselt kommunizieren k¨onnen, ohne vorher einen gemeinsamen Schl¨ussel vereinbart zu
haben.
In [Sin00] wird ein Verfahren auf einfache Weise beschrieben, damit der Leser asymmetrische
Verschl¨usselung leichter versteht. Alice m¨ochte Bob eine Nachricht schicken, die nur Bob lesen
k¨onnen soll (siehe Abbildung 2.1). Dazu steckt sie die Nachricht in eine Kiste und versperrt diese
mit einem Vorh¨angeschloß. Anschließend schickt sie die versperrte Kiste an Bob. Bob kann die
Kiste nicht ¨offnen, da er den Schl¨ussel f¨ur das Vorh¨angeschloß nicht besitzt. Er h¨angt selber ein
eigenes Vorhangschloß dazu und schickt die nun mit zwei Schl¨ossern versperrte Kiste an Alice
zur¨uck. Alice sperrt ihr eigenes Schloß auf und schickt die Kiste abermals an Bob zur¨uck. Dieser
kann nun sein eigenes Schloß ¨offnen und die Nachricht in der Kiste lesen. Somit ist w¨ahrend des
Tranports die Kiste immer mit mindestens einem Schloß gesichert.
Damit wird das Problem gel¨ost, daß sich Alice und Bob nicht auf einen gemeinsamen Schl¨ussel
2.8
Asymmetrische Verschl¨
usselung
17
Alice
Bob
A
B
A
B
B
A
A
B
Abbildung 2.1: Beispiel f¨
ur asymmetrische Verschl¨
usselung
einigen m¨ussen. Trotzdem gibt es bei dem Verfahren ein Problem. Alice kann nicht sicher sein,
daß tats¨achlich Bob und niemand anders die Nachricht empf¨angt.
Nehmen wir an Eve m¨ochte die Nachricht an Bob abfangen und schafft es die Kiste vor Bob zu
bekommen. Sie h¨angt ihr eigenes Vorhangschloß auf die Kiste und schickt diese zur¨uck an Alice.
Alice glaubt, daß Bob sein Schloß auf die Kiste geh¨angt hat, ¨offnet ihr eigenes und schickt die
Kiste zur¨uck. Abermals f¨angt Eve die Kiste ab, ¨offnet ihr eigenes Schloß und kann die Nachricht,
die eigentlich f¨ur Bob bestimmt war, lesen. Alice hatte keine M¨oglichkeit festzustellen, wessen
Schloß dazugeh¨angt wurde, weil die Authentizit¨at von Bobs Schloß nicht gew¨ahrleistet war.
Genauso kann auch Bob nicht sicher sein, daß eine Nachricht tats¨achlich von Alice stammt. Sie
k¨onnte genauso gut von Eve sein.
Die Mathematik hinter asymmetrischen Verschl¨usselungsalgorithmen ist eher kompliziert. Der
interessierte Leser wird auf [MOV97] verwiesen.
Bekannte Beispiele f¨ur asymmetrische Verschl¨usselungsalgorithmen sind RSA (vgl. [RSA78])
und DH (vgl. [DH76]). Dabei verf¨ugt jeder der Kommunikationspartner ¨uber einen ¨offentlichen
und einen privaten Schl¨ussel. Der ¨offentliche Schl¨ussel kann jeder Person ¨ubermittelt werden,
die jemandem etwas verschl¨usselt schicken m¨ochte. Entschl¨usselt werden kann die Nachricht nur
mit dem privaten Schl¨ussel, der geheimhalten gehalten werden muß.
Gegen¨uber symmetrischen Verfahren sind asymmetrische wesentlich langsamer. Deshalb setzt
man heute oft ein hybrides Verfahren, bestehend aus einem symmetrischen und einem asymme-
trischen Algorithmus, ein. Dabei wird ein zuf¨alliger Schl¨ussel k generiert, mit dem die Nachricht
m symmetrisch verschl¨usselt wird. Der Schl¨ussel k wird dann anschließend mit dem ¨offentlichen
Schl¨ussel des Empf¨angers verschl¨usselt.
18
Grundbegriffe
Bei der Entschl¨usselung muß der Empf¨anger zuerst mit seinem privaten Schl¨ussel k entschl¨usseln,
damit er dann anschließend mit Hilfe von k die Nachricht m dechiffrieren kann.
2.9
Hashfunktionen
Hashfunktionen k¨onnen zu einer beliebig langen Nachricht einen Funktionswert bilden. Im Be-
reich der Kryptographie ist es außerdem wichtig, daß man von dem abgebildeten Wert keine
R¨uckschl¨usse auf die urspr¨ungliche Nachricht ziehen kann, selbst wenn der Angreifer weiß, wel-
cher Algorithmus eingesetzt wurde.
Interessant sind Hashfunktionen im Bereich der Integrit¨at. Man kann vor dem Versenden einer
Nachricht den Hashwert h
1
dieser Nachricht berechnen. Anschließend schickt man h
1
und die
Nachricht dem Empf¨anger. Dieser kann den Hashwert h
2
f¨ur die empfangene Nachricht aus-
rechnen. Sind h
1
und h
2
ident, dann wurde die Nachricht nicht ver¨andert und die Integrit¨at
ist gew¨ahrleistet (die Authentizit¨at jedoch nicht, da auch h
1
bei der ¨
Ubertragung manipuliert
werden k¨onnte).
2.10
Zufallszahlen
Zufallszahlen spielen eine sehr wichtige Rolle in der Kryptographie. Sehr viele Protokolle basie-
ren letztendlich auf der Qualit¨at der Zufallszahlen. Nur wenn ein Schl¨ussel tats¨achlich zuf¨allig
gew¨ahlt wurde (mit einer entsprechenden L¨ange) kann er als sicher gelten.
Auf ersten Blick wirkt die Generierung von Zufallszahlen trivial. Das Problem ist aber, daß der
Computer eine deterministische Maschine ist. Das heißt in der gleichen Situation wird er immer
gleich reagieren. Verwendet man beispielsweise die Uhr eines Computers um Zufallszahlen zu
generieren, wirken die Ergebnisse auf den ersten Blick tats¨achlich zuf¨allig. Wer allerdings weiß
wann die Zufallszahl generiert wurde, kann ganz leicht einen Schl¨ussel herausfinden, der auf
dieser Zufallszahl basiert.
Nehmen wir an ein Angreifer weiß, daß ein Schl¨ussel ca. um 12:00 generiert wurde. Er braucht
dann eigentlich nur s¨amtliche Werte, die zwischen 11:50 und 12:10 durch den Zufallsgenerator
erzeugt werden k¨onnen, durchprobieren. Einer der Werte ist mit Sicherheit der Schl¨ussel. Selbst
eine große Schl¨ussell¨ange zu w¨ahlen ist sinnlos, da in diesem Zeitfenster nur eine sehr begrenzte
Anzahl an Werten generiert werden kann. Auch andere Verfahren, wie etwa die aktuelle Netzlast
als Quelle f¨ur Zufallszahlen heranzuziehen, sind nicht besser.
In Hochsicherheitsbereichen werden oft physikalische Prozesse, die sehr zuf¨allig wirken, heran-
gezogen, wie etwa das Rauschen von Funksendern. Im privaten Bereich werden oft Mausbe-
wegungen oder die Abst¨ande zwischen Tastenanschl¨agen als Zufallswerte verwendet. Werden
2.11
Covert Channels
19
viele Zufallswerte ben¨otigt, wird mit Hilfe dieser Zufallswerte eine sogenannte "seed" erzeugt,
die dann f¨ur die Generierung weiterer Zufallswerte herangezogen wird, die dann aber nur noch
pseudo-zuf¨allig sind, da sie wieder nach einem fixen Algorithmus errechnet werden. So lange die
"seed" geheim bleibt funktioniert diese Methode recht gut (vgl. [Sch00b]).
2.11
Covert Channels
"Unter Covert Channel (versteckte Kan¨ale) versteht man einen Kommunikationskanal der einem
Prozeß erlaubt Informationen auf eine Art zu ¨ubertragen, die die Security Policy (die Sicher-
heitsregeln) verletzen." ([RS92], Seite 409) Covert Channels sind ein großes Problem f¨ur die
Vertraulichkeit. Je geschickter ein Angreifer sie versteckt, desto schwieriger wird es sie zu ver-
hindern. Theoretisch kann jede Information weitere versteckte Informationen enthalten, wenn
vorher entsprechende Vereinbarungen bez¨uglich der Codierung getroffen werden. Beispielsweise
k¨onnen zwei Spione vereinbaren, daß wenn einer von ihnen ein blaues Taschentuch eingesteckt
hat, alles in Ordnung ist, wenn er hingegen ein rotes Taschentuch eingesteckt hat, ein Problem
aufgetreten ist.
Auch bei Computern kann man ¨ahnliche Vereinbarungen treffen. Beispielsweise kann eine
Workload (Maß f¨ur die momentane Auslastung des Rechners) von mehr als zwei auf einem
Server bedeuten, daß alles in Ordnung ist, eine Workload darunter, daß es ein Problem gegeben
hat.
2.12
Auditing
"Unter Auditing versteht man das Aufzeichnen, Untersuchen und Reviewen von sicherheitsrele-
vanten Aktivit¨aten in einem vertrauensw¨urdigen System." ([RS92], Seite 128)
Auditing ist ein sehr wichtiger Bestandteil jedes Sicherheitskonzepts. Ohne Auditing ist es prak-
tisch unm¨oglich Angriffe zu erkennen und zur¨uckzuverfolgen. Es ist jedoch erforderlich, die Log-
files, die beim Auditing erzeugt werden, abzuspeichern. Da diese Logfiles aber einfache Dateien
sind, k¨onnen sie von einem Angreifer leicht manipuliert werden, wodurch sie dann wertlos sind.
Deshalb sollten Logfiles entweder auf Medien geschrieben werden, die nur einmal beschreibar
sind oder es m¨ussen andere Verfahren eingesetzt werden, wie zum Beispiel kryptographische
Protokolle. Ein solches Protokoll wird unter anderem in [SK98] vorgestellt.
20
Grundbegriffe
2.13
Digitale Signaturen
Digitale Signaturen, im Signaturgesetz auch elektronische Signaturen genannt (vgl. [Bre99]),
sollen die Authentizit¨at, Integrit¨at und Beweisbarkeit garantieren. Generiert werden digitale
Signaturen mit Hilfe eines asymmetrischen Verfahrens. Erstellt wird eine Signatur von einer
Signierungsfunktion, die diese aus der Nachricht selbst und dem geheimen Schl¨ussel erzeugt.
Um die Signatur zu pr¨ufen errechnet der Empf¨anger mittels einer Verifizierungsfunktion, die die
Nachricht, den ¨offentlichen Schl¨ussel und die Signatur selbst heranzieht, ob diese korrekt ist.
Damit der Empf¨anger aber auch sicher sein kann, daß der ¨offentliche Schl¨ussel tats¨achlich dem
Sender geh¨ort, ist dieser mit einem Zertifikat einer vertrauensw¨urdigen Stelle (Certificate Au-
thority) ausgestattet. Die Certificate Authority (CA) best¨atigt, daß ein bestimmter Schl¨ussel
einer bestimmten Person geh¨ort, indem sie vorher die pers¨onlichen Daten der Person anhand
von festgelegten Kriterien (zum Beispiel Lichtbildausweis) ¨uberpr¨uft hat.
Wenn der ¨offentliche Schl¨ussel mit einem Zertifikat einer CA ausgestattet ist und die Verifizie-
rungsfunktion die Korrektheit der Nachricht festgestellt hat, sind Authentizit¨at, Integrit¨at und
Beweisbarkeit garantiert.
Viele halten digitale Signaturen f¨ur einen echten Ersatz herk¨ommlicher Unterschriften. Das
stimmt so allerdings nicht:
1. Mittels elektronischer Signaturen werden keine Inhalte signiert, sondern lediglich Bitfol-
gen. Wie diese Bitfolgen zu interpretieren sind (wie der Inhalt angezeigt werden muß) ist
Sache der jeweiligen Applikation, mit der das signierte Dokument geschrieben wurde. Das
heißt, man m¨ußte die Applikation ebenfalls mitsignieren. Die Applikation wiederum l¨auft
unter einem bestimmten Betriebssystem, das eigentlich daf¨ur zust¨andig ist die Informatio-
nen an die Hardware weiterzuleiten. Somit m¨ußte auch das Betriebssystem in die digitale
Signatur miteinbezogen werden. Zum Schluß bleibt noch die Hardware, die die Informatio-
nen letztendlich erst anzeigt. Das heißt, auch die m¨ußte mitsigniert werden. In der Praxis
ist das aber nicht m¨oglich.
2. Da man wie unter Punkt 1 beschrieben nicht alle Komponenten signieren kann, muß der
Anwender letztendlich beim Signieren bzw. beim Verifizieren einer digitalen Signatur ge-
wissen Komponenten vertrauen. Er muß sich sicher sein, daß die Software tats¨achlich vor
dem Signieren den Text anzeigt, den er signieren m¨ochte und daß er nicht in Wirklich-
keit einen anderen Text signiert. Auch beim Verifizieren einer Signatur muß er sich darauf
verlassen k¨onnen, daß das Ergebnis der Verifizierung korrekt ist. Das ist aber insofern
problematisch, da die Signaturen oft mit herk¨ommlichen PCs erstellt werden, die leicht
manipuliert werden k¨onnen, da auf ihnen praktisch jede beliebige Software und somit auch
2.13
Digitale Signaturen
21
trojanische Pferde (vgl. Abschnitt 4.5) und Viren (vgl. Abschnitt 4.6) laufen k¨onnen.
3. Aufgrund m¨oglicher Manipulationen kann ein Empf¨anger also eigentlich nicht wirklich
sicher sein, daß tats¨achlich der angegebene Signator ein bestimmtes Dokument signieren
wollte. Aufgrund des Signaturgesetzes jedoch sind digitale Signaturen bis auf wenige Aus-
nahmen rechtlich bindend.
4. Die Algorithmen, die zur Erstellung digitaler Signaturen eingesetzt werden, gelten heute
als sicher. Was aber passiert, wenn diese einmal gebrochen werden, ist nicht klar. Neh-
men wir an, daß bestimmte Algorithmen nicht mehr sicher sind und jeder mit einfachsten
Mitteln digitale Signaturen f¨alschen kann. Nat¨urlich werden diese Algorithmen zur Erstel-
lung digitaler Signaturen nicht mehr zugelassen. Die Frage ist aber, was mit Dokumenten
passiert, die in der Vergangenheit signiert wurden, zu einem Zeitpunkt, als die Algorith-
men noch als sicher gegolten haben. In der Regel wird es dem Willen der Vertragspartner
entsprechen, wenn ein Vertrag seine Rechtskraft beh¨alt.
Problematisch wird es wenn jemand bestreitet den Vertrag signiert zu haben, denn dann
fehlt letztendlich der Nachweis, daß das Dokument jemals signiert wurde, da die Algorith-
men ja nicht mehr als sicher gelten. Zwar k¨onnte man die digital signierten Dokumente zum
Beispiel bei einem Notar hinterlegen lassen, aber das w¨urde den Aufwand enorm erh¨ohen
und damit den digitalen Signaturen ihren Reiz, den elektronischen Gesch¨aftsverkehr zu
erleichtern, nehmen.
Kapitel 3
OSI Referenz Modell
Netzwerkprotokolle werden in verschiedene Schichten unterteilt. Der Grund daf¨ur ist, daß Netz-
werke dadurch etwas an Komplexit¨at verlieren. Zwar haben unterschiedliche Netzwerktypen
verschiedene Schichten, aber trotzdem bieten eigentlich bei allen Netzwerkarten die darunter-
liegenden Schichten Services f¨ur dar¨uberliegende Schichten an. Das hat den Vorteil, daß man
sich zum Beispiel als Entwickler einer Client-Server-Anwendung nicht mehr darum k¨ummern
muß, welche Hardware f¨ur das Netzwerk eingesetzt wird oder wie die Pakete ihren Weg zum Ziel
finden.
Das OSI Modell basiert auf einem Entwurf der International Standards Organization (ISO)
(vgl. [DZ83]). Die Idee war, einen einheitlichen Standard f¨ur Netzwerkprotokolle zu schaffen.
Der Name OSI bedeutet "Open Systems Interconnection". Gew¨ahlt wurde der Name, weil sich
das Modell mit der Verbindung offener Systeme besch¨aftigt, also mit Systemen, die offen sind,
mit anderen Systemen zu kommunizieren (vgl. [Tan96], Seite 28).
3.1
Physical Layer
Der "Physical Layer" (Bit¨ubertragungsschicht) ist die unterste Schicht im OSI-Modell (vgl. Ab-
bildung 3.1). Er definiert, wie Bits repr¨asentiert werden. Beispielsweise wird festgelegt, welches
Signal wie lange gesendet wird, um eine Eins darzustellen. Hier wird auch bestimmt, ob beide
Seiten parallel eine ¨
Ubertragung durchf¨uhren k¨onnen.
3.2
Data Link Layer
Eine Schicht ¨uber dem Physical Layer liegt der Data Link Layer (Verbindungssicherungsschicht).
Aufgabe des Data Link Layers ist die ¨
Ubertragung von Daten zwischen zwei Punkten im Netz-
werk. Das k¨onnen unter Umst¨anden zwei Rechner sein, aber auch ein Rechner und ein Router
23
24
OSI Referenz Modell
Presentation
Application
Session
Transport
Network
Data link
Physical
Layer
7
6
5
4
3
2
1
Datendarstellung
Anwendung
Verbindung
Transport
Netzwerk
Verbindungs-
sicherung
Bitübertragung
Schicht
7
6
5
4
3
2
1
Abbildung 3.1: OSI-Modell
oder zwei Router. Der Data Link Layer sorgt daf¨ur, daß die Daten sicher beim anderen Punkt
ankommen. Ist das nicht der Fall, k¨onnen die Daten noch einmal geschickt werden. Zus¨atzlich
ist es Aufgabe des Data Link Layer daf¨ur zu sorgen, daß Daten gepuffert werden, wenn der
Empf¨anger derzeit keine Daten annehmen kann.
F¨ur diese Probleme gibt es verschiedene L¨osungen, die jeweils ihre Vor- und Nachteile haben.
Finden mehr Pr¨ufungen statt, wird das Netzwerk langsamer. Werden weniger Pr¨ufungen durch-
gef¨uhrt, ist das Netzwerk zwar schneller, aber eventuell auftretende Fehler werden nicht oder
erst auf h¨oherer Ebene bemerkt und m¨ussen dann dort korrigiert werden.
3.3
Network Layer
Der Network Layer (Netzwerkschicht) kontrolliert die Operationen in einem Subnetz. Wichtig
ist hier, daß kontrolliert wird, wieviele Pakete zwischen Sender und Empf¨anger verschickt wer-
den. Die Routen zwischen Sender und Empf¨anger k¨onnen dabei statisch festgelegt oder auch
dynamisch sein, sodaß jedes Netzwerkpaket auf einem anderen Weg zum Sender gelangt. Das
kann zum Beispiel dann von Vorteil sein, wenn damit Engp¨asse bei bestimmten Netzwerkteilen
vermieden werden k¨onnen. Der Nachteil dabei ist, daß Pakete m¨oglicher Weise in der falschen
3.4
Transport Layer
25
[a,b,c]
[c,a,b]
[a,b]
[c]
Abbildung 3.2: ¨
Ubertragung mit falscher Reihenfolge
Reihenfolge ankommen k¨onnen, da sie ¨uber verschiedene Routen transportiert wurden.
Eine wichtige Rolle spielt nat¨urlich die Netzwerkadressierung, sprich wie eine bestimmte Kom-
ponente im Netzwerk angesprochen werden kann. Verwenden unterschiedliche Netzwerke unter-
schiedliche Netzwerkadressierungsarten, kann das zu großen Problemen f¨uhren, da die Adressie-
rung erst konvertiert werden muß.
3.4
Transport Layer
Der Transport Layer (Transportschicht) erh¨alt seine Daten vom Session Layer. Er unterteilt die
Daten, wenn notwendig, in mehrere Pakete. Diese werden unter Umst¨anden auf verschiedenen
Wegen zum Empf¨anger geschickt. Dabei kann die Reihenfolge durcheinander geraten, wenn
ein Netzwerkpaket, das sp¨ater geschickt wurde, fr¨uher ankommt als eines, das bereits fr¨uher
abgeschickt wurde (vgl. Abbildung 3.2). Bei einigen Protokollen, wie etwa bei TCP (Transmission
Control Protocol) (siehe Abschnitt 6.5), ist es die Aufgabe des Transport Layers, die richtige
Reihenfolge wiederherzustellen.
Der Transport Layer ist auch die erste Schicht, die sich nicht mehr um das Routing zwischen
Sender und Empf¨anger k¨ummern muß. Sie kann direkt Kontakt zum Empf¨anger aufnehmen.
3.5
Session Layer
Der Session Layer (Verbindungsschicht) richtet, wie der Name schon sagt, eine Session (Sitzung)
ein. In einer Session kann zum Beispiel ein Dialog mit einem anderen Rechner durchgef¨uhrt oder
26
OSI Referenz Modell
Application
Presentation
Session
Transport
Network
Data link
Physical
7
6
5
4
3
2
1
OSI
Host-to-
network
Internet
Transport
nicht
implementiert
nicht
implementiert
Application
TCP/IP
Layer
Abbildung 3.3: TCP/IP Reference Model
auch eine Datei ¨ubertragen werden. Der Session Layer bietet bestimmte Checkpoints an, bei
denen eine ¨
Ubertragung im Falle eines Abbruchs fortgesetzt werden kann. Das ist besonders dann
wichtig, wenn eine gr¨oßere Datei ¨ubertragen werden soll. Bricht die Verbindung beispielsweise
in der Mitte der ¨
Ubertragung ab, w¨are es sehr l¨astig, wenn man die ¨
Ubertragung wieder von
Anfang an beginnen m¨ußte. Dieser Layer ist auch f¨ur die Benutzerauthentifizierung zwischen
zwei Rechnern zust¨andig.
3.6
Presentation Layer
Der Presentation Layer (Datendarstellungsschicht) legt fest, wie die Daten f¨ur die ¨
Ubertragung
codiert werden. Hier k¨onnen Daten aber auch verschl¨usselt oder komprimiert werden.
3.7
Application Layer
Der Application Layer (Anwendungsschicht) kommuniziert mit den Anwendungsprogrammen.
Programme wie FTP, Sendmail oder auch Netscape schicken ¨uber diesen Layer ihre Daten.
3.8
TCP/IP Reference Model
27
3.8
TCP/IP Reference Model
Ein anderes Netzwerkreferenzmodell ist das TCP/IP Reference Model. Entstanden ist dieses
Modell durch das ARPANET (Vorl¨aufer vom Internet), das vom DoD (U.S. Department of
Defense), dem amerikanischen Verteidigungsministerium, in Auftrag gegeben wurde. Ziel des
ARPANETs war es ein Netzwerk zu schaffen, das auch einen Atomkrieg ¨uberstehen w¨urde.
Selbst wenn ein Teil des Netzwerkes ausfallen sollte, w¨urden die Pakete auf anderen Wegen noch
immer zu ihren Zielen gelangen.
Das erste Mal wurde das TCP/IP Reference Model von Cerf und Kahn 1974 definiert (vgl.
[Tan96], Seite 35).
3.8.1
Host-to-Network Layer
Das TCP/IP Reference Model definiert diese Schicht eigentlich nicht genauer. In der Literatur
wird sie kaum behandelt.
3.8.2
Internet Layer
Der Internet Layer entspricht dem Network Layer im OSI-Modell (vgl. Abbildung 3.3). Zust¨andig
ist er f¨ur das Routing, also der Weiterleitung der Pakete zur Zieladresse. Im Internet Layer wurde
ein eigenes Protokoll definiert, n¨amlich das IP (Internet Protocol).
3.8.3
Transport Layer
¨
Uber dem Internet Layer befindet sich der Transport Layer. Hier sind zwei Protokolle definiert,
das TCP (Transmission Control Protocol) und das UDP (User Datagram Protocol). TCP ist
zuverl¨assig und verbindungsorientiert. Bei diesem Protokoll ist sichergestellt, daß die Daten auch
tats¨achlich beim Empf¨anger ankommen. Verbindungsorientiert bedeutet, daß die Verbindung so
lange offen bleibt, bis sie explizit geschlossen wird.
UDP hingegen ist unzuverl¨assig und nicht verbindungsorientiert. Es ist somit nicht garantiert,
daß die Daten wirklich den Empf¨anger erreichen und auch nicht, daß die Daten in der richtigen
Reihenfolge ankommen. Ben¨otigt wird dieses Protokoll vor allem dann, wenn es wichtiger ist,
daß die Daten schnell ankommen und Zuverl¨assigkeit keine große Rolle spielt.
3.8.4
Application Layer
Der Session und der Presentation Layer werden im TCP/IP Model nicht verwendet, da die
Praxis gezeigt hat, daß dieser Layer kaum ben¨otigt werden (vgl. [Tan96], Seite 37).
28
OSI Referenz Modell
Im Application Layer werden Protokolle wie Telnet (vgl. Abschnitt 6.8), FTP (vgl. Abschnitt
6.10) oder SMTP (vgl. Abschnitt 6.11) angewendet. Die Liste der im Application Layer an-
gewendeten Protokolle wird allerdings mit der Zeit immer gr¨oßer, da st¨andig neue Protokolle
definiert werden.
Kapitel 4
Allgemeine Sicherheitsprobleme
Im Folgenden zeige ich einige allgemeine Sicherheitsprobleme auf, damit der Leser, der mit der
Materie nicht so vertraut ist, rasch einen ¨
Uberblick ¨uber verschiedene Attacken erh¨alt.
4.1
Denial-of-Service Attacke
Bei einer Denial-of-Service (DoS) Attacke versucht der Angreifer ein System lahmzulegen, indem
er es mit Anfragen "bombardiert". Das System ist dann praktisch nur noch damit besch¨aftigt,
die zumeist sinnlosen Anfragen des Angreifers zu bearbeiten. Es kann seiner eigentlichen Aufgabe
nicht mehr nachkommen und wird somit nutzlos. Die Verf¨ugbarkeit ist gef¨ahrdet.
Ein typisches Beispiel f¨ur eine Denial-of-Service Attacke ist, wenn man bei einem Pizza-Service
viele Speisen zu verschiedenen Orten, die aber nicht exisitieren, bringen l¨aßt. Gibt man gen¨ugend
Bestellungen auf, so ist der gesamte Pizza-Service nur noch damit besch¨aftigt, diese Bestellungen
zu bearbeiten und hat f¨ur andere, sinnvolle Bestellungen keine Zeit mehr.
Eine Variante von Denial-of-Service Attacken sind sogenannte Distributed-Denial-of-Service At-
tacken (DDoS). Dabei geht die Attacke nicht von einer Quelle aus, sondern von vielen. Ein
System wird dabei dann von vielen Quellen mit Anfragen "bombardiert", was eine Abwehr
nat¨urlich erschwert.
4.2
Man-in-the-middle Attacke
Bei einer Man-in-the-middle Attacke befindet sich ein Angreifer zwischen kommunizierenden
Systemen. Er kann dabei aktiv in die Kommunikation eingreifen und Pakete abfangen oder
umleiten. Damit wird die Authentizit¨at, Vertraulichkeit oder Integrit¨at der Daten verletzt.
29
30
Allgemeine Sicherheitsprobleme
4.3
Sniffing
Unter Sniffing versteht man das Mitlesen von Paketen, die ¨uber das Netzwerk ¨ubertragen werden.
Dadurch wird die Vertraulichkeit verletzt.
Sniffing wird normalerweise mit sogenannten Netzwerksniffern durchgef¨uhrt. Diese schalten die
Netzwerkkarte in den "promiscuous mode". ¨
Ublicher Weise liest die Netzwerkkarte nur die Pa-
kete ein, die f¨ur sie bestimmt sind. Im promiscuous mode jedoch liest sie alle Pakete aus dem
Netzwerk ein, auch die, die nicht f¨ur sie bestimmt sind. Der Netzwerksniffer kann dann somit
alle Pakete auswerten und dem Angreifer anzeigen, die bei seiner Netzwerkkarte vorbeigeschickt
werden.
4.4
Spoofing
Beim Spoofing gibt der Angreifer vor jemand anderer zu sein. Dadurch bekommt er unter
Umst¨anden mehr Rechte und kann diese mißbrauchen. Dabei wird die Authentizit¨at verletzt,
eventuell auch die Vertraulichkeit, wenn der Angreifer Daten liest. Sofern der Angreifer Daten
manipuliert, wird auch die Integrit¨at verletzt und m¨oglicherweise die Verf¨ugbarkeit gef¨ahrdet,
wenn er dem System Schaden zuf¨ugt.
4.5
Trojanische Pferde
Trojanische Pferde haben ihren Namen aus der griechischen Mythologie. Dabei gibt ein Pro-
gramm vor eine bestimmte Funktionalit¨at zu besitzen, f¨uhrt aber in Wirklichkeit eine andere,
zumeist b¨osartige Funktion aus. Zum Beispiel k¨onnte ein trojanisches Pferd eine Melodie vor-
spielen und dabei im Hintergrund die Festplatte l¨oschen.
Durch trojanische Pferde kann die Vertraulichkeit verletzt werden, wenn das trojanische Pferd
Daten verschickt. Aber auch die Integrit¨at und Verf¨ugbarkeit kann gef¨ahrdet werden, wenn das
trojanische Pferd Daten und Programme manipuliert oder l¨oscht.
4.6
Viren und W¨
urmer
Viren und W¨urmer sind Programme, die sich selbst replizieren k¨onnen und auch meistens eine
Schadensfunktion besitzen. Der Hauptunterschied zwischen Viren und W¨urmer besteht darin,
daß sich Viren an andere Programm anh¨angen, w¨ahrend W¨urmer eigenst¨andige Programme
sind.
Die Weitergabe von Viren und W¨urmern erfolgte vor einigen Jahren noch zumeist durch das
Austauschen von Raubkopien. Heutzutage ist der prim¨are Verbreitungsweg jedoch das Internet,
Ende der Leseprobe aus 132 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2001, Sicherheit von Internet- und Intranetdiensten, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/222381
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare