Netzwerkaspekte

Ausarbeitungen WS 2003/04

Editor: Harald Krottmaier

20. Januar 2004

Kurzzusammenfassung
In diesem Dokument sind die Ergebnisse der Ausarbeitungen vom
WS 2003/04 zur Lehrveranstaltung “Netzwerkaspekte” zu finden. Eine elektronische
Version ist auf [Link] zu finden.
Die jeweiligen Themen wurden von den Studierenden zu Beginn des Semesters aus-
gewählt und im Laufe des Semesters präsentiert. Die Folien sind ebenfalls elektronisch
vorhanden.
Ich danke den Studierenden für den Einsatz und die gute Zusammenarbeit bei den
Vorbereitungen und der Ausarbeitung!

1
2 INHALTSVERZEICHNIS INHALTSVERZEICHNIS 3

Inhaltsverzeichnis 2.7.1 Gnutella Bandbreiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.7.2 Down/Up-Stream Bottleneck Untersuchungen . . . . . . . . . . . . . . 29
1 Streaming Protokolle 9 2.7.3 Session Dauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7.4 Shared Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.2 Streaming Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7.5 Topologie des Gnutella Netzwerkes . . . . . . . . . . . . . . . . . . . . 30
1.2.1 Streaming Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.3 Real Time Transport Protocol (RTP) . . . . . . . . . . . . . . . . . . . . . . 10
3 Wireless LAN 33
1.3.1 Transportteil von RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.2 Realtime Control Protocol (RTCP) . . . . . . . . . . . . . . . . . . . . 12 3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.3.3 Realtime Streaming Protocol (RTSP) . . . . . . . . . . . . . . . . . . 12 3.1.1 Die Standardfamilie 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4 RealAudio r , RealVideo r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2 Media Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4.1 Übertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.3 Wireless Fidelity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4.2 Metadateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Wired Equivalent Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.4.3 Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 WEP-Attacken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5 QuickTime r Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4 Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.6 Streaming über HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4.1 NetStumbler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.6.1 HTTP als Tunnelprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.2 AiroPeek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.7 Überblick über Server-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3 Kismet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.7.1 Darwin Streaming Server . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.4 Wellenreiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.7.2 QuickTime r Streaming Server . . . . . . . . . . . . . . . . . . . . . . 14
1.7.3 Icecast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.5 WEPCrack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.7.4 RealNetworks r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.6 AirSnort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.7.5 Microsoft r Streaming Service . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.7 AP Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5 Verbesserungen der Sicherheit von WLANs . . . . . . . . . . . . . . . . . . . 40
3.5.1 Virtual Private Network . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2 Peer 2 Peer 17 3.5.2 Advanced Mobile Security Architecture . . . . . . . . . . . . . . . . . 40
2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.5.3 Global System for Mobile Communications (GSM) . . . . . . . . . . . 41
2.2 Distributed Systems (Verteilte Systeme) . . . . . . . . . . . . . . . . . . . . . 17 3.5.4 Pass-One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.1 Centralized und Decentralized Distributed Systems . . . . . . . . . . . 18
3.6 Der neue Standard 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.2 Beispiele Verteilter Systeme . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6.1 Wi-Fi Protected Access . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3 Peer 2 Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Geschichtliches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7 Gesetzlicher Schutz gegen Attacken auf Funknetze . . . . . . . . . . . . . . . 42
2.3.2 Was ist Peer 2 Peer? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.7.1 Situation in Österreich . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.3 Einteilung von Peer 2 Peer Systemen . . . . . . . . . . . . . . . . . . . 20 3.7.2 Situation in Deutschland . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4 Charakteristika von Peer 2 Peer Systemen . . . . . . . . . . . . . . . . . . . . 21 3.7.3 Datenschutzprobleme bei WLAN . . . . . . . . . . . . . . . . . . . . . 44
2.4.1 Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.2 Anonymität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.3 Cost of Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4 Personal Area Network (PAN) 46
2.4.4 Ad-Hoc Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.2 Wozu Bluetooth? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.7 Transparenz und Usability . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.3 Wie funktioniert Bluetooth? . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4.8 Fehleranfälligkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.4 Sicherheitsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.4.9 Kompatibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.5 Die Zukunft von Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . 50
2.5 Peer 2 Peer Applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Infrared Data Association (IrDA) . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.5.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.2 Architektur-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.6 Peer 2 Peer Applikationen (Fallstudien) . . . . . . . . . . . . . . . . . . . . . 27 4.2.2 IrDA Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.6.1 SETI@Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2.3 Überblick über die Spezifikationen der einzelnen Protokolle: . . . . . . 52
2.6.2 Gnutella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2.4 IrDA Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.7 Gnutella Meßungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3 Bluetooth vs. IrDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4 INHALTSVERZEICHNIS INHALTSVERZEICHNIS 5

5 Network File System (NFS)/ClusterNFS 64 7.3 XML-RPC vs. andere Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . 89

5.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.4 Details des XML-RPC Protokolls . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2 Herkunft und Entstehungsgeschichte von NFS . . . . . . . . . . . . . . . . . . 64 7.4.1 Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3 Remote Procedure Call (RPC) . . . . . . . . . . . . . . . . . . . . . . . . . . 65 7.4.2 Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4 NFS-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Einfache Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.1 Mount-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.4.3 Formate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.2 Besondere Eigenschaften des NFS-Protokolls . . . . . . . . . . . . . . 67 Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.5 NFS Version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 Response Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.6 NFS Version 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.7 Überblick über alle NFS-Protokoll-Versionen . . . . . . . . . . . . . . . . . . 69
5.8 WebNFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8 Personal Firewalls 94
5.9 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 8.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.9.1 Maßnahmen zur sichereren Authentifizierung . . . . . . . . . . . . . . 70 8.2 Was sind PFWs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.9.2 Alternative Maßnahmen zur Erhöhung der Sicherheit . . . . . . . . . . 70 8.2.1 Wogegen können PFWs schützen . . . . . . . . . . . . . . . . . . . . . 94
5.10 ClusterNFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8.2.2 Wogegen können PFWs nicht schützen . . . . . . . . . . . . . . . . . 95
5.10.1 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8.3 Typische Gefahren für den Einzelnen im Internet . . . . . . . . . . . . . . . . 96
5.10.2 Diskless Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 8.3.1 Schutzmechanismen einer PFW . . . . . . . . . . . . . . . . . . . . . . 96
5.10.3 Motivation für ClusterNFS . . . . . . . . . . . . . . . . . . . . . . . . 72 8.4 Personal Firewalls und Windows . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.10.4 Konzept von ClusterNFS . . . . . . . . . . . . . . . . . . . . . . . . . 72 8.4.1 Bekannte Personal Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 98
5.10.5 Momentane Fähigkeiten von ClusterNFS . . . . . . . . . . . . . . . . 73 8.4.2 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.10.6 Momentane Schwachpunkte von ClusterNFS . . . . . . . . . . . . . . 73
5.10.7 Ansatz zur Verbesserung der Schwachpunkte . . . . . . . . . . . . . . 73 9 Internet Firewalls 101
5.10.8 Weitere Möglichkeiten für Projekte . . . . . . . . . . . . . . . . . . . . 74 9.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.11 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 9.2 Firewall Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9.2.1 Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6 Simple Object Access Protocol (SOAP) 76 9.2.2 Proxy Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 9.3 Firewall Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2 Nachrichten in SOAP – SOAP Envelope . . . . . . . . . . . . . . . . . . . . . 76 9.3.1 Single-Box Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2.1 SOAP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 9.3.2 Screened Subnet Architekturen . . . . . . . . . . . . . . . . . . . . . . 104
6.2.2 SOAP Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 9.4 Packet Filter Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2.3 SOAP Fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 9.5 Proxy Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3 Nachrichtenaustausch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.5.1 SOCKS Proxy Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.3.1 SOAP und HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 9.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.3.2 SOAP HTTP-Request . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.3.3 SOAP HTTP Response . . . . . . . . . . . . . . . . . . . . . . . . . . 80 10 Virtual Private Networks (VPN) 110
6.3.4 SOAP und RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.4 Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 10.1.1 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.4.1 Web Service Describtion Language (WSDL) . . . . . . . . . . . . . . . 84 10.1.2 Warum VPN? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.4.2 Universial Description, Discovery and Integration (UDDI) . . . . . . . 84 10.1.3 Definition VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.4.3 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.1.4 Analogie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.4.4 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.2 VPN Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 10.2.1 Unternehmensweites VPN . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.6 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 10.2.2 Sichere Remote Ankopplung . . . . . . . . . . . . . . . . . . . . . . . . 112
6.6.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 10.2.3 VPN zwischen verschiedenen Unternehmen . . . . . . . . . . . . . . . 112
6.6.2 JAVA - Web Services Developer Pack 1.3 . . . . . . . . . . . . . . . . 86 10.3 Anforderungen an VPN’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
10.4 Sicherheit in VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7 XML-RPC 87 10.4.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 10.4.2 Schlüsselmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7.2 XML-RPC Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 10.4.3 Datenvertraulichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2.1 Was ist XML-RPC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 10.4.4 Paket-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2.2 Besonderheiten und Vorteile von XML-RPC . . . . . . . . . . . . . . . 87 10.4.5 Datenintegrität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.2.3 Probleme/Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 10.4.6 Benutzer-Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . 115
6 INHALTSVERZEICHNIS ABBILDUNGSVERZEICHNIS 7

10.5 Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 Abbildungsverzeichnis

10.5.1 Symmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . 116
10.5.2 Asymmetrische Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . 117 1 RTP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.6 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 2 Layer von Verteilten Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.7 IP-Security-Protokoll (IPSec) . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 3 Grenze zwischen Client-Server und Peer 2 Peer Systemen . . . . . . . . . . . 19
10.7.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4 Typische Umgebung fuer ein Peer 2 Peer Netzwerk. . . . . . . . . . . . . . . . 20
10.7.2 IPSec im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5 Grundsätzliche Einteilung von Peer 2 Peer Systemen. . . . . . . . . . . . . . . 21
10.7.3 Die IPSec-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6 Hybrid Peer 2 Peer Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.7.4 Security-Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7 Allgemeine Einteilung von Peer 2 Peer Applikationen . . . . . . . . . . . . . . 25
10.7.5 Security-Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 8 Zentralisiertes Verzeichnis-Modell . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.7.6 IPSec-Betriebsmodi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 9 Flooded Request-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10 Document Routing-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.7.7 Einsatzszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
11 Messungen: Down/Up-Stream Bottleneck bei Gnutella/Napster . . . . . . . . 29
10.7.8 IPSec Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
12 Messungen: Session Dauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.7.9 IPSec-Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . 123
13 Messungen: Shared Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.8 Andere Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
14 Messungen: Anzahl Shared Files / Menge Shared Data . . . . . . . . . . . . . 30
10.8.1 Point-to-Point-Tunneling-Protocol (PPTP) . . . . . . . . . . . . . . . 125
15 Messungen: Topologie des Gnutella Netzwerkes . . . . . . . . . . . . . . . . . 31
10.8.2 Layer-2-Forwarding (L2F) . . . . . . . . . . . . . . . . . . . . . . . . . 125
16 Distribution System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.8.3 Layer-2-Tunneling-Protocol (L2TP) . . . . . . . . . . . . . . . . . . . 125
17 IEEE 802-Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 18 Kanalaufteilung und -überlappung . . . . . . . . . . . . . . . . . . . . . . . . 35
19 CSMA/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11 Secure Shell 127
20 Bluetooth-Modul von Sony-Ericsson . . . . . . . . . . . . . . . . . . . . . . . 47
11.1 Einführung und Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
21 Protokollarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.1.1 Kryptografie-Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . 129
22 Standard Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1.2 Lizenzrechtliche Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . 129
23 IrDA Protokollstack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.2 SSH vs. rlogin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
24 Blockschaltbild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2.1 r-Befehle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 25 Transferraten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2.2 Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 26 Grundfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.2.3 SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 27 Verbindngsorientierte Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
11.2.4 Verschlüsselung bei SSH . . . . . . . . . . . . . . . . . . . . . . . . . . 132 28 Generelle Protokoll Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 56
11.3 Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 29 bersicht der IrDA Control Layer . . . . . . . . . . . . . . . . . . . . . . . . . 57
11.3.1 Protokoll Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 30 Bitmuster der physikalischen Übertragung . . . . . . . . . . . . . . . . . . . . 58
11.3.2 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 31 Physikalischer Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.3.3 User Authentication Layer . . . . . . . . . . . . . . . . . . . . . . . . . 134 32 MAC Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
11.3.4 Connection Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 33 LLC Frame Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
11.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 34 LLC Control Feld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
35 techn. Vergleich - Bluetooth vs. IrDA . . . . . . . . . . . . . . . . . . . . . . 63
12 File Transfer Protokolle 137 36 SOAP Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
12.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 37 Struktur einer SOAP-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . 77
12.2 File Transfer Protocol (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 38 XML-Grundstruktur einer SOAP-Nachricht . . . . . . . . . . . . . . . . . . . 78
12.2.1 Historisches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 39 Interaktion mit Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
12.2.2 Grundlagen des Protokolls . . . . . . . . . . . . . . . . . . . . . . . . . 137 40 UDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
12.2.3 FTP Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 41 Webservices via HTTP mit SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 85
12.2.4 Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 42 Schutzmöglichkeit durch Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 95
12.2.5 Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 43 Port Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
12.2.6 Datenübertragung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 44 Port Hiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
12.2.7 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 45 Screening Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.3 Trivial File Transfer Protocol (TFTP) . . . . . . . . . . . . . . . . . . . . . . 139 46 Proxy Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
12.3.1 Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 47 Screened Subnet Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.3.2 Anwendungsbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 48 Stateful Packet Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
12.3.3 Sicherheitsaskpekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 49 Proxy Server Illusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 50 SOCKS Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8 ABBILDUNGSVERZEICHNIS 9

51 Analogie Sicherheitstransporter . . . . . . . . . . . . . . . . . . . . . . . . . . 111 1 Streaming Protokolle

52 Unternehmensweites VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
53 Remote-Ankopplung mit Hilfe eines VPN . . . . . . . . . . . . . . . . . . . . 113 Dieser Abschnitt behandelt Grundlagen verbreiteter Streaming Protokolle und geht auch
54 Kooperatives VPN verschiedener Unternehmen . . . . . . . . . . . . . . . . . 114 auf einige praxisorientierte Aspekte ein.
55 Vergleich der benötigten Zeit bei Brute-Force-Attacken . . . . . . . . . . . . . 116
56 Prinzip der symmetrischen Verschlüsselung . . . . . . . . . . . . . . . . . . . 116 Wolfgang Schriebl: swulf@[Link], RealAudio r und RealVideo r , Streaming über
57 Prinzip der 3DES-Verschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . 117 http, Anforderungen an derartige Protokolle
58 Prinzip der asymmetrischen Verschlüsselung . . . . . . . . . . . . . . . . . . . 118
59 Die Architektur von IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Manfred Klopschitz: manni@[Link], RTP, QuickTime r , Streaming Server
60 Security-Assocation ist unidirektional . . . . . . . . . . . . . . . . . . . . . . 120
61 Das IPSec-AH Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 1.1 Einführung
62 Das IPSec-ESP-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
63 Die Verarbeitung eines ausgehenden IPSec-ESP-Paketes . . . . . . . . . . . . 124 Der folgende Abschnitt widmet sich einer Technologie, die in den nächsten Jahren Einzug in
64 Kexinit Paket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 die Wohn- und Arbeitszimmer rund um die Welt halten wird. Streaming, die Übertragung
65 FTP-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 digitaler Medien über Netzwerke rund um die Welt.
Ob Telefonie, Radio, Fernsehen oder Kino. Enorme Mengen an Daten müssen transportiert
werden, um diese Dienste auf Abruf anbieten zu können. Es wird auf die Anforderungen
an Protokolle allgemein, und speziell auf RTP und der Verwendung vom Web-Protokoll
HTTP eingegangen. Weiters werden verfügbare Server und kommerzielle Streaming Verfah-
ren (QuickTime r ,RealAudio r , RealVideo r ) behandelt.

1.2 Streaming Protokolle

Als Streaming bezeichnet man die Übertragung von Daten über ein Netzwerk, ohne diese
am Zielgerät lokal speichern zu müssen. Um diese Form der Echtzeitübertragung realisieren
zu können, bedarf es einiger Vorraussetzungen. Neben den Anforderungen an Hardware
und den entsprechenden Komprimierungssystemen, wird auch eine möglichst optimale Ab-
bildung der Steuerprozesse und Übertragungsvorgaben in Transport- und Steuerprotokollen
vorrausgesetzt.

1.2.1 Streaming Media

Bei Streaming Media unterscheidet man zwei von Grund auf verschiedene Anwendungen:

• Live: Übertragungen die live aufgezeichnet werden und direkt über Datennetze an
die Empfänger gesendet werden müssen. Beispiele dafür sind IP-Telefonie (VoIP),
TV-und Radio-Übertragungen oder Video-Konferenzen.

• On Demand: Unter On-Demand-Services versteht man Dienste, die auf Abruf

bereits voraufgezeichnete Daten zur Verfügung stellt. Diese Dienste bezeichnet man
auch als Audio on Demand und Video on Demand. Beispiele dafür sind Musik, TV-
Sendungen und Filme die auf Anfrage bereitgestellt werden.

Die grosse Palette verschiedenster Anwendungen müssen beim Design von Protokollen, die
diese Dienste anbieten berücksichtigt werden.

1.2.2 Anforderungen
Flexibilität ist eines der Schlagworte, die ein Streamingprotokoll auszeichnen. Jede Form von
multimedialen Daten, in jeder Form kombiniert und auch steuerbar soll möglichst effezient
über das Netzwerk übertragen werden. Die Anforderungen an solche Protokolle werden in
der folgenden Auflistung beschrieben.
10 1 STREAMING PROTOKOLLE 1.3 Real Time Transport Protocol (RTP) 11

• Unicast - Multicast: Um die Netzwerklast am Server möglich gering zu halten, Das RTP-Protokoll besteht grundsätzlich aus zwei Teilen: RTP 1.3.1 und RTCP 1.3.2.
sollten diese nur einmal versendet werden, auch wenn sie an mehrere Enpfänger gehen. RTP ist für den Transport der Daten zuständig, RTCP (RTP Control Protocol) zur Über-
Diese Form der Übertragung wird Multicast genannt, und muss von einem Protokoll wachung des QoS und zum Sammeln von Informationen über Teilnehmer einer Session.
zur Übertragung von live-Daten unterstützt werden. Zusätzlich wird häufig das RTSP 1.3.3 Protokoll verwendet, um Steuerfunktionen von Stre-
Auf Unicast, das ist das Versenden eines Packets an genau einen Empfänger, findet ams wie zum Beispiel “pause”, und “play” zur Verfügung zu stellen.
nur bei On-Demand-Anwendungen Verwendung, da jeder Client verschiedene Packete
erhält. 1.3.1 Transportteil von RTP

• Quality of Service: Quality of Services für Echtzeitdaten zu realisieren birgt einige In diesem Abschnitt bezieht sich RTP auf den Teil des RTP-Protokolles, der für den Trans-
Probleme in sich. Geht ein Packet verloren oder kommt es zu spät an, so kann es in port der Daten, wie Audio oder Video verantwortlich ist. Da RTP auf Application-Layer
den meisten Fällen verworfen werden. Daher setzen die meisten Echtzeitprotokolle auf Ebene aufsetzt verwendet es ein zugrunde liegendes Transport Protokoll, meist UDP. Die
UDP auf. Audio/Videodaten die vom Server gesendet werden sollen werden in RTP Paketen verpackt.
Mit verlorengegangenen Daten muss der Player richtig umgehen können. Im Protokoll Die zu sendenden Daten werden als RTP-Payload bezeichnet. Ein RTP-Paket, in dem
kann das aus den vorher genannten Gründen nicht geschehen. Je nach Datenformat sich eine RTP-Payload befindet enthällt Zusatzinformationen. Diese bestehen aus Sequenz-
ist dies besser oder schlechter möglich. RFC 3119 [RFC 3119 2001] zeigt ein solches nummern, Zeitmarken, Identifikationsnummern, sowie eine Kennzeichnung der verwendeten
Schema auf Datenebene. Payload Daten (Payload Type).
Im RTP Protokoll ist nicht definiert wie ein vorhandener Stream in Payloads zerteilt
• Synchronisierung: Schon die Übertragung eines Kanals birgt ein Problem in sich: werden soll. Wie man einen Stream in solche Teile zerlegt ist natürlich sehr von der Codie-
die Synchronisierung der Packete. Da Packete verloren gehen können und auch in der rung abhängig. Deshalb gibt es eine Reihe weiterer RFCs, die definieren wie man bestimmte
falschen Reihenfolge eintreffen können, muss das Protokoll einen Synchronisierungs- Typen von Streams in eine Serie von RTP Paketen verpackt.
mechnismus unterstützten. Dies geschieht meist durch Anhängen eines Zeitstempels,
der die genaue Abspielzeit (relativ zum Start) angibt.
Die Synchronierung mehrerer Kanäle kann ebenfalls durch den Zeitstempel erfolgen.
• Mehrkanalübertragung: Um die Übertragung von Videos durchzuführen ist es
sinnvoll, die einzelnen Audio- und Videokanäle in eigene Kanäle zu packen und ge-
trennt zu übermitteln. Der Client kann dann einzelne Kanäle anfordern, die die zu
Verfügung stehende Bandbreite berücksichtigt und seinen eigenen Bedürfnissen ent-
spricht (Sprache, Auflösung und Tonqualität der Hardware zur Wiedergabe, etc.) .
Bei Videokonferenzen müssen ebenfalls mehrere Kanäle, in der Regel zwei von jedem
Teilnehmer, zu allen anderen Teilnehmern geschalten werden. Um dabei die Bandbeite
der Teilnehmer nicht zu überlasten, werden sogenannte Mixer eingesetzt. Diese fassen
die Streams mehrerer Quellen zusammen und senden sie als einen Kanal weiter.
• Steuerung des Servers: Der Stream von Daten über ein Netzwerk soll für den
Benutzer die selbe Funktionalität wie die Wiedergabe eines lokalen Mediums bieten.
Um dies zu gewährleisten muss die Rückmeldung vom Client zum Server möglich sein. Abbildung 1: RTP-Header
Wie man leicht erkennen kann sind Anforderungen an den Protokollstack zur Übertragung
von Streaming Media sind sehr breit gefächert, sodass eine Aufteilung in mehrere, vonein-
ander unabhängige Protokolle sinnvoll erscheint. Zum einen in ein reines Transporprotokoll, Payload type: Dieses Feld im RTP-Header definiert den genauen Typ der Payload.
welches nur die Streamingdaten sendet. Zum anderen ein Protokoll, welches die Steuerung Sequence number: Da UDP kein zuverlässiges Protokoll ist muss ein Mechanismus zur
des Servers übernimmt. Erkennung von verlorenen oder vertauschten Paketen vorhanden sein.
Timestamp: Die Zeitmarken werden zur Synchronisation und zur Berechnung von Jitter
1.3 Real Time Transport Protocol (RTP) verwendet.
Das Realtime Transport Protocol [RFC3550 2003] ist ein Protokoll auf Application-Layer
SSRC: Synchronisation Source ID. Wird benötigt, da die Sequenznummern und Zeitmarken
Ebene. Es stellt Funktionen zur Übertragung von zeitkritischen Daten, wie Audio- Video-
unterschiedlicher Quellen nicht sinnvoll direkt miteinander verglichen werden können.
oder Simulationsdaten zur Verfügung. Allerdings werden keine Garantien über das Quality
(Es sind zum Beispiel keine Einheiten für den Timestamp definiert, nur gewisse Ei-
of Service (QoS) gemacht. Es wird Uni- und Multicast unterstützt. Weiters gibt es spezi-
genschaften.)
elle Knoten (RTP-Mixers), die mehrere Streams unterschiedlicher Quellen zu einem Stream
zusammenfassen können. So etwas macht zum Beispiel bei Videokonferenzen mit mehre- CSRC: Contributing Source. Wurden mehrere Streams von einem Mixer zusammengefasst,
ren Teilnehmern Sinn, um die Datenmenge die letztendlich bei jedem Client ankommt auf werden die ursprünglichen Quellen hier aufgelistet (im SSRC Feld würde sich die ID
wenige Streams zu reduzieren. des Mixers befinden).
12 1 STREAMING PROTOKOLLE 1.5 QuickTime r Streaming 13

1.3.2 Realtime Control Protocol (RTCP) (SureStreamTM ). Dieses Verfahren ermöglich es dem Server, verschiedenen Clients verschie-
dene Qualitäten zu liefern, ohne diese in Echtzeit generieren zu müssen. Auch ein Wechsel
Das Real Time Control Protocol [RFC3550 2003] ist Teil des RTP Protokolles und dient zur
wärend der Wiedergabe ist möglich.
Überwachung einer Session. Einerseits werden die Teilnehmer über RTCP verwaltet(z.B.:
Als Übertragungsraten gibt RealNetworks r 75% der Bandbreite bei Einwahlverbindun-
ein User beendet Session), andererseits wird der Zustand des Netzes zu jedem Teilnehmer
gen (Analog, ISDN), und 90% bei DSL/LAN an.
überwacht. Dies ermöglicht die Datenmenge der Streams an die Leistungsfähigkeit der Ver-
bindung zu den Teilnehmer anzupassen. Diese Informationen werden in gewissen Abständen
verschickt. Normalerweise wird ebenfalls UDP verwendet. 1.5 QuickTime r Streaming
Apple r QuickTime r ist eigentlich eine Erweiterung zum Macintosh r -Betriebssystem, die
1.3.3 Realtime Streaming Protocol (RTSP) das Erstellen sowie Abspielen, Komprimieren und Bearbeiten von zeitbasierten Daten er-
Das Real Time Streaming Protocol [RFC2326 1998] dient zur Steuerung der Audio und laubt. QuickTime gibt es seit 1991.
Videostreams und ist eigendlich nicht Teil von RTP [RFC3550 2003], wird aber häufig als QuickTime r bedient sich der Movie-, d.h. Film-Metapher, um zeitbasierte Daten zu be-
Ergänzung verwendet. Im Gegensatz zu RTP verwendet RTSP meist TCP. RTSP definiert schreiben. QuickTime r speichert zeitbasierte Daten in Objekten, die als QuickTime r movie
Kommandos wie zum Beispiel PLAY, die sich auf eine Quelle beziehen. Es hat eine Ähn- bezeichnet werden. Ein einzelnes QuickTime r movie kann mehr als einen Strom von Daten
lichkeit mit HTTP, allerdings können auch Anfragen vom Server an den Client geschickt enthalten. Diese können parallel und sequentiell angeordnet sein. Daher kann man eine
werden. QuickTime r Datei als einen Container für zeitbasierte Daten auffassen.
Um ein QuickTime r Video zu streamen wird eine weitere Spur(pro Medientrack) in der
.mov Datei benötigt, die dem Server Hinweise gibt, wie der Stream in Pakete aufzuspalten ist.
1.4 RealAudio r , RealVideo r Dies kann man zum Beispiel mit dem QuickTime r Player Pro machen und wird “hinting”
Als einer der ersten kommerziellen Anbieter hat sich RealNetworks r 1 mit der Übertragung genannt. Der Stream kann dann vom Server, verpackt in einzelne RTP Pakete versendet
von Audio- und Videodaten über Netzwerke beschäftigt. Herausgekommen sind patentierte werden. Die Erweiterung einer .mov Datei um streaming-spezifischer Informationen ist ein
Codecs für die Komprimierung – RealAudio r und RealVideo r . wesentlicher Unterschied zu den meisten anderen Audio/Video Dateiformaten.
Entsprechende Server und Player, die die Codecs unterstützten stehen in abgespeckten
Basisversionen gratis zum Download zur Verfügung. Weiters bietet RealNetworks r den
1.6 Streaming über HTTP
HelixTM Producer, das ist kostenlose Software zum Rendern von Fremdformaten in die haus-
eigenen Codecs, an. Eine Alternative zu Streaming Protokollen ist die Verteilung von Daten über das, für das
Web entworfene, Hypertext Transfer Protokoll (HTTP) [RFC 2616 1999].
1.4.1 Übertragung Einerseits ist HTTP oft die einzige Möglichkeit, mit Rechnern ausserhalb des eigenen
Subnetzes zu kommunizieren (Firewalls), andererseits stehen sehr viele multimediale Daten
Der Streamingserver unterstützt neben RTP auch die Übertragung/Steuerung über die An- auf Webservern zur Verfügung. Eine Anfrage eines HTTP-Clients sieht wie folgt aus:
wendungsschicht via Hypertext Transport Protocol (HTTP) [RFC 2616 1999] und RTSP.
GET /[Link] HTTP/1.1
1.4.2 Metadateien Range: bytes=21010-47021
[weitere Optionen]
Um den direkten Start von Streams im RealAudio r -/RealVideo r -Format aus einem Brow-
ser zu ermöglichen werden Metadateien eingesetzt. Synchonized Multimedia Integration
Daraufhin liest der Server die entsprechenden Daten aus seinem Speicher und sendet sie an
Language2 (SMIL, sprich “smile”), so heisst der vom W3-Konsortium definierte Standard,
den Client zurück:
wird in den Versionen 1.0 und 2.0 unterstützt.
Ein Link einer Webseite zu einem Stream zeigt nicht direkt auf die Stream-Datei sondern HTTP/1.1 206 Partial Content
auf diese Metadatei. Der Browser übergibt die File und der RealPlayer r liest sich die Content-Range: bytes 21010-47021/47022
angegebebene Tags aus. Content-Length: 26012
[weiter Optionen]
1.4.3 Codec [Daten]
Wie vorher erwähnt ist der Codec, den RealAudio r und RealVideo r verwenden, pateten- Die Daten werden dabei von TCP in Packete zerteilt. Der Client speichert die Daten zwi-
tiert. schen und kann sie dann weiterbearbeiten.
Dateien für diese Formate lassen sich mit dem HelixTM Producer, der in der Basisversion Handelt es sich beim Client um einen Webbrowser, so kann erst nach erfolgter Da-
konstenlos zur Verfügung steht, erzeugen. Als Basis dienen Standardformate wie MPEG tenübertragung die jeweilige Player-Software gestartet werden, Streaming ist nicht möglich.
und MP3, Quicktime und AIFF oder AVI und WAV. In der erweiterten Version des Pro- Da aber Streams über das Webinterface gestartet werden sollen, gibt es Metadateien die
ducers ist es auch möglich, Dateien mit multiplen Streamraten in einem File zu speichern URLs auf das jeweilige File am HTTP-Server beinhalten.
1 [Link] Damit kann der Player die Streaming-Daten selbst am Server anfragen und – sobald die
2 [Link] Packete einlangen – wiedergeben. Dabei ergeben sich aber folgende Probleme:
14 1 STREAMING PROTOKOLLE 1.8 Zusammenfassung 15

• Transport über TCP: HTTP-Verbindungen laufen immer über TCP ab, da die 1.7.4 RealNetworks r
gesendeten Packete auch ankommen müssen. Sobald ein Packet verloren geht, wird
es nochmals geschickt und blockiert damit den Datenstrom (TCP garantiert ja die RealNetworks r bietet als Streaming Server den HelixTM Universial Server an. Auf Netz-
Reihenfolge der Packete). Echtzeitübertragung ist nicht garantiert. werkebene werden RTP, RTSP, HTTP und weitere Protokolle unterstützt. Unterstütz-
te Codecs: RealAudio r , RealVideo r , RealPixTM , RealText r , QuickTime r , MPEG-1,
• Steuerung: Es gibt keine Möglichkeit, den Server direkt anzusteuern. Sobald die MPEG-4, MP3, JPEG, PNG, und einiges mehr. Live Broadcasting ist ebenfalls möglich.
Datei angefragt wurde, wird gesendet. Ein Anhalten ist nur durch Verbindungsabbruch
möglich, Sprünge in den Daten können durch Angabe einer Content-Range bei der 1.7.5 Microsoft r Streaming Service
Anfrage realisiert werden.
Das Microsoft r Streaming Service baut auf dem Internet Information Server Version 4
• Synchronisierung: Die Synchronisierung der Daten stellt kein Problem dar, da alle auf und benutzt natürlich nicht das unabhängige RTP Protokoll, sondern das proprietäre
Packete garantiert in der richtigen Reihenfolge eintreffen. Durch einen einfachen FIFO- MMS (Microsoft Media Streaming)... Gestreamt werden Windows Media r Dateien, die
Buffer kann der Player die Daten wie lokal vorliegende Multimedia-Daten behandeln. proprietäre Erweiterungen von MPEG-4 sind.

1.6.1 HTTP als Tunnelprotokoll 1.8 Zusammenfassung

Eine anderer Ansatz ist das Übertragen ganzer Streaming-Protokolle, wie RTSP und RTP, Die Entwicklung der Streaming Technologien ist schon sehr weit forgeschritten. Doch die Ka-
über HTTP, um das vorher erwähnte Problem mit Firewalls zu umgehen. pazitäten zur Umsetzung von hochauflösendem Kinoerlebnis am Heimbildschirm sind noch
Dabei können sämtliche Merkmale, die diese Protokolle beinhalten umgesetzt werden, nicht gegeben (HDTV). Es bleibt abzuwarten welche “Standards” sich durchsetzten werden.
das Problem von HTTP über TCP bleibt aber weiterhin bestehen. Einige sind bei einer Lösungen die rein auf offenen Standards basieren scheitern oft schon am verwendeten Codec
Solchen Variante zu beachten: des zu übertragenden Streams, dennoch scheinen sich zumindest auf Netzwerkebene offene
• Verschlüsselung: Sämtliche Daten müssen verschlüsselt Übertragen werden, um zu Protokolle durchzusetzen.
verhindern, dass Router die Packete durchleuchten und diese als ungültig verwerfen.

• Kommunikation: Verbindungsaufnahme von Client zum Server geschieht mit einem Literaturverzeichnis
normalen Get-Request und einem Cookie-Id. Der Server antwortet mit entsprechenden
Daten-Packeten. [Tanenbaum 2003] Andrew S. Tanenbaum: Computernetzwerke, 4. Auflage, Pearson Studi-
Die Steuerung des Servers kann durch einfache Post-Request vom Server zum Client um (2003).
realisiert werden.
[Peterson 2003] Larry L. Peterson, Bruce S. Davie:Computer Networks, 3rd Edition, Morgan
Apple hat sich mit der Entwicklung eines Servermoduls beschäftigt, das auf diese Technologie Kaufmann (2003).
umsetzt. [Apple 2003].
[RFC3550 2003] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson: “RTP: A Transport
Protocol for Real-Time Applications” RFC 3550, July 2003
1.7 Überblick über Server-Systeme
[RFC2326 1998] H. Schulzrinne, A. Rao, R. Lanphier: “Real Time Streaming Protocol
1.7.1 Darwin Streaming Server
(RTSP)” RFC 2326, April 1998
Der Darwin Streaming Server ist eine Open Source Version des QuickTime Streaming Servers
von Apple. Er ist geeignet um QuickTime und MPEG-4 zu streamen und ist für verschiedene [RFC 2327 1998] M. Handley, V. Jacobson: “SDP: Session Description Protocol” RFC 2327,
Plattformen verfügbar. Es werden gängige Standards wie RTP, RTSP und SDP [RFC 2327 April 1998
1998] unterstützt. Live streaming ist möglich. QuickTime Clients verwenden dabei eine
[RFC 3119 2001] R. Finlayson: “A More Loss-Tolerant RTP Payload Format for MP3 Au-
.sdp [RFC 2327 1998] Datei, die Informationen über die Quelle enthalten. Es werden mehr
dio” RFC 3119, june 2001
als 3000 gleichzeitige Streams unterstützt.
[RFC 2616 1999] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
1.7.2 QuickTime r Streaming Server Berners-Lee: “Hypertext Transfer Protocol – HTTP/1.1” RFC 2616, june 1999
Der QuickTime r Streaming Server ist die kommerzielle Version des Darwin Streaming Ser- [Apple 2003] QuickTime Streaming Server Concepts. [Link]
vers und bei Mac OS X r Server enthalten. Es erweitert den Darwin Server hautsächlich um documentation/QuickTime/QTSS/Concepts/chapter_2_section_14.html
eine GUI. Allerdings ist dieser Server nur für die Mac OS X r Plattform erhältlich.
[Apple 2003] QuickTime Streaming Server Overview. [Link]
1.7.3 Icecast products/qtss/

Icecast ist ein Streaming Server für Musik im Ogg Vorbis Format oder Live Streams und ist [Schetter 2003] Schetter, S. (2003) Streaming: Video und Audio im Internet. [Link]
Freie Software. Icecast benutzt ein eigenes Protokoll für die Netzwerkübertragung. [Link]/rrzk/multimedia/dokumentation/streaming/
16 LITERATURVERZEICHNIS 17

[Real 2003] Introduction to Streaming Media. [Link] 2 Peer 2 Peer

guides/realone/IntroGuide/HTML/[Link]
Unsere Idee war es, einen Netzwerklayer für Computerspiele zu entwickeln. Aus Performance-
[Real 2003] Helix Universial Server. [Link] Gründen wählten wir als praktische Entwicklungsumgebung die Programmiersprache C++.
helixuniversalserver/[Link] Da bei Computerspielen (beziehungsweise in unserem Netzwerklayer) auch Clients direkt
untereinander kommunizieren, war es naheliegend als übergeordnetes beziehungsweise theo-
[Apple 2003] Darwin Streaming Server. [Link]
retisches Thema Peer 2 Peer-Systeme zu wählen. Wir versuchen einen Einblick in Peer
projects/streaming/
2 Peer Systeme zu geben.

Ramin Dalkouhi romout@[Link], komplette Ausarbeitung gemeinsam

Philipp Fürnstahl hurri@[Link], komplette Ausarbeitung gemeinsam

2.1 Einleitung
Anfangs werden wir auf Verteilte Systeme eingehen, um uns später auf einen Teilbereich
dieser, die Peer 2 Peer Systeme, beschränken. Hier werden wir eine allgemeine Einteilung
von Peer 2 Peer Systemen vorstellen und deren Charakteristika aufzeigen. Danach werden
wir einen Überblick über Peer 2 Peer Applikationen geben und einige bekannte Peer 2 Peer
Applikationen vorstellen. Ausserdem werden wir auch noch Vergleiche (Benutzer-, Dateien-,
Bandbreiten-Statistiken) zwischen Napster und Gnutella anstellen.

2.2 Distributed Systems (Verteilte Systeme)

Da Peer 2 Peer Systeme eine Untergruppe von Verteilten Systemen sind, geben wir einen
kurzen Überblick über Verteilte Systeme. Grundsätzlich kann man ein Computer System
in Distributed Systems und Centralized Systems einteilen. Centralized Systems sind Stand-
Alone Computer (Single- oder Multiprozessor Computer, Supercomputer, Mainframes, . . . ).

Ein Verteiltes System ist eine Menge von unabhängigen Computern, die den Benutzern
als ein einzelnes, zusammenhängendes System erscheint ([Tanenbaum 2002]).

Das heißt, die Hardware ist autonom (es gibt einzelne, unabhängige Computer) und die
Software ermöglicht es den Benutzern das System als Ganzes zu benutzen.

Folgende Punkte gelten für Verteilte Systeme:

• Unterschiedliche Computer verschiedenster Hersteller und mit unterschiedlichen Be-

triebssystemen haben die Möglichkeit miteinander zu kommunizieren.

• Die Kommunikation zwischen diesen Computern soll für den/die Benutzer nicht sicht-
bar sein.

• Das System muss leicht erweiterbar und skalierbar sein.

• Ein Verteiltes System muss stets funktionsfähig sein (Auch wenn Teile des Systems
nicht erreichbar sind).

Ein Verteiltes System kann man grob in folgende Layer (Abbildung 2 auf Seite 18) ein-
teilen:

Die oberen Layer bestehen aus Benutzern und Applikationen. Die darunterliegenden
Layer (Middleware) stellen eine Schnittstelle zwischen den untersten Layern (System von
einzelnen Computern) und dem Benutzer zur Verfügung.
18 2 PEER 2 PEER 2.3 Peer 2 Peer 19

Abbildung 2: Grobe Einteilung eines Verteilten Systems in Layer ([Taylor 2003], [gezeichnet:
Fürnstahl 2003]).

2.2.1 Centralized und Decentralized Distributed Systems

Grundsätzlich gibt es zwei Bereiche von Verteilten Systemen: Centralized Systems und De-
centralized Systems. Centralized Systems sind typischerweise Client-Server Systeme, Decen-
tralized Systems typischerweise Peer 2 Peer Systeme. Abbildung 3: Es gibt keine klare Grenze zwischen Client-Server und Peer 2 Peer Systemen.
Beide Systeme weisen gewisse Charakteristika auf (Managed/Self Organized, Lookup/Discovery,. . . )
Die Grenze zwischen Client-Server und Peer 2 Peer Systemen kann nicht klar gezo-
Beide Modelle können auf verschiedenen Platformen funktionieren (Internet, Intranet, . . . ) und als
gen werden (Abbildung 3 auf Seite 19). Beispielsweise kann die Suchmaschine Google als Basis für Programme fungieren ([Morgan 2002]).
centralized eingestuft werden, da sie einen Centralized Web-Server besitzt (mit eindeutiger
IP-Adresse). Die Informationen werden von einem Datenbankcluster verwaltet, der aus über
10.000 Linux Maschinen besteht. Das wiederum kann aus Such- oder Computerperspektive
als decentralized eingestuft werden. 2.3 Peer 2 Peer
Es gibt drei wesentliche Punkte, welche deutlich machen, ob ein System zentral oder Dieses Kapitel wird einen groben Überblick über Peer 2 Peer Systeme vermitteln. Erst wird
dezentral arbeitet. Das Auffinden (zum Beispiel DNS), die Verfügbarkeit und die Kommu- auf geschichtliche Fakten eingegangen, danach werden wir uns mit der Architektur von Peer
nikation (Peer 2 Peer oder über einen Server). 2 Peer Systemen befassen. Besonderes Augenmerk wird auf deren Charakteristika geworfen.

2.3.1 Geschichtliches
2.2.2 Beispiele Verteilter Systeme
Fast alle frühen Verteilten Systeme waren Peer 2 Peer Anwendungen. UseNet-Server ver-
Ein gutes Beispiel für ein Centralized System ist ein Web-Server. Benutzer verwenden ihren banden sich untereinander, um Nachrichten von Server zu Server weiterzuleiten. Das war
Internet-Browser um auf eine bestimmte Web-Seite auf dem Web-Server zu surfen. Sie eine frühe Form von Document-Sharing. Das FTP ([FTP 1985]) ist ein reines Client-Server
erreichen ihn durch Eingabe einer Domain (Auffindung, statisch durch DNS). Die Seite ist Protokoll, doch betrieben damit viele Benutzer zu Hause einen Server, um ihre Daten mit
verfügbar, wenn der Web-Server in Funktion ist. Die gesamte Kommunikation läuft über Bekannten auszutauschen. Was dieses System zu einem Vorläufer von File-Sharing Pro-
den Web-Server. grammen machte. Dazu kam noch das ein Indexing-System (Archie, nicht mehr existent)
entwickelt wurde, was die globale Suche ermöglichte. Das Fido-Net ist ein weiteres Beispiel
Ein anderes Beispiel war Napster. Napster benutzte zentrale Server um Informationen für ein Peer 2 Peer System. Hier verbanden sich Fido-Nodes untereinander in regelmäßigen
über Dateien zu speichern. Die Kommunikation selbst passierte dann zwischen den Clients Abständen (Ad-Hoc Connection) um Mails in Foren untereinander auszutauschen.
(man konnte ein File fertig downloaden, auch wenn der Server nicht erreichbar war). Deshalb
konnte man Napster auch einfach unterbinden, da man das Betreiben der Index-Server 2.3.2 Was ist Peer 2 Peer?
untersagte. Napster lag in der Grauzone zwischen Centralized und Decentralized Systems.
Systeme die nur teilweise decentralized sind nennt man Brokered Systems. Peer heißt übersetzt ’Gleichgestellter’ oder ’ebenbürtig’, was eigentlich schon aussagt was
Peer 2 Peer bedeutet. Peer 2 Peer Systeme sind Verteilte Systeme. Anders als bei Client-
Gnutella ([GNUTELLA 2001]) ist ein Beispiel eines vollkommen dezentralen Systems. Server Systemen (centralized ) sind die einzelnen Nodes gleichgestellt, dass heißt, jeder Node
20 2 PEER 2 PEER 2.4 Charakteristika von Peer 2 Peer Systemen 21

agiert als Server und als Client. Ein Peer 2 Peer Netzwerk ist dynamisch. Nodes (Peers)
und Verbindungen sind nicht statisch. Das darunterliegende Netzwerk kann aber sehr wohl
statisch sein (zum Beispiel Internet). Nodes haben meist kein Wissen über die Topologie
des Netzwerkes (Identitäten, Verbindungen, . . . ) von anderen Peers im Netzwerk.

Ende der 1990iger Jahre kam es zu einer neuen Definition von Peer 2 Peer:

P2P is a class of applications that takes advantage of resources (for example storage,
cycles, content, human presence) available at the edges of the Internet ([Shirky]).

Mit ’Computers at the edges of the Internet’ sind Computer die zeitlich begrenzt im
Internet sind, eventuell nicht direkt erreichbar sind (Firewall, NAT,. . . ) oder verschiedene
Protokolle und Betriebssysteme verwenden, gemeint (Abbildung 4 auf Seite 20). Diese
Definition sagt auch aus, das eine Vielzahl von klassischen Client-Server Applikationen (zum
Beispiel SETI@Home ([SETI 2001])) eigentlich auch zu Peer 2 Peer Applikationen gehören, Abbildung 5: Grundsätzliche Einteilung von Peer 2 Peer Systemen in Pure- beziehungsweise
da jeder Peer seine CPU-Leistung zur Berechnung einer gemeinsamen Aufgabe verwendet. Hybrid-Systeme ([HP Laboratories]).

Abbildung 6: Hybrid Peer 2 Peer Modell: (1) Verbindungsaufnahme mit dem Server. (2) Direkte
Kommunikation 2er Peers ([HP Laboratories]).

Abbildung 4: Typische Umgebung für ein Peer 2 Peer Netzwerk ([Taylor 2003],[gezeichnet: Fürn-
stahl 2003]).
2.4 Charakteristika von Peer 2 Peer Systemen
Der größte Vorteil von Peer 2 Peer Systemen ist, dass alle Systeme dezentral sind. Diese
Topologie hat Einfluss auf alle anderen Bereiche die für Peer 2 Peer Systeme nötig sind. Des
weiteren sind folgende Punkte bei Peer 2 Peer Systemen sehr wichtig:

2.3.3 Einteilung von Peer 2 Peer Systemen 2.4.1 Skalierbarkeit

Je weniger zentral ein System ist, desto bessere Skalierbarkeit gibt es (Dies trifft beispiels-
Grundsätzlich werden Peer 2 Peer Systeme in Pure Peer 2 Peer Systems (Abbildung 5 auf
weise bei Gnutella nicht zu, darauf wird aber später noch eingegangen). Skalierbarkeit ist
Seite 21) und Hybrid Peer 2 Peer Systems (Abbildung 5 auf Seite 21).
limiertiert durch:
Pure Peer 2 Peer Modelle ist zum Beispiel Gnutella ([GNUTELLA 2001]). Sie sind
vollkommen dezentral. In einem Hybrid Modell wird zuerst Kontakt mit einem Server auf- • Durch die Anzahl von zentralen Operationen limitiert (zum Beispiel Synchronisation).
genommen, um Meta-Informationen zu erhalten (Login, File-Indices, . . . ) danach wird eine
• Durch die Anzahl an verschiedenen Zuständen die verwaltet werden müssen.
Peer 2 Peer Verbindung zu anderen Peers aufgebaut. Dieses Modell verwenden zum Beispiel
Napster oder iMesh ([IMESH]). Es gibt auch Modelle, die keinen zentralen Server besitzen • Wie gut parallele Abläufe verwaltet werden.
sondern sogenannte SuperPeers, die mehr Informationen enthalten als ein ’gewöhnlicher’
Peer (Beispiel: kaZaa ([KAZAA]) ). • Das Programm-Modell selbst.
22 2 PEER 2 PEER 2.4 Charakteristika von Peer 2 Peer Systemen 23

Das Erreichen guter Skalierbarkeit, sollte nicht auf Kosten anderer Funktionen (Perfor- 2.4.5 Performance
mance, deterministisch,. . . ) gehen.
Fast alle Peer 2 Peer Systeme steigern ihre Performance durch das verteilte speichern von
Deshalb verwalten hybride Peer 2 Peer Systeme (Napster, hatte cirka eine Skalierbarkeit Daten (Napster,. . . ) oder das verteilte Nutzen von Rechenzyklen (SETI@Home ([SETI
von 6 Millionen Usern) Teile der Operationen zentral. 2001]),. . . ). Da diese Systeme weit verteilt sind, spielen die durchlaufenden Netzwerke eine
große Rolle (Bandbreite,. . . ). Hier spricht man bei Performance nicht mehr von Millise-
Dezentrale Systeme wie zum Beispiel GNuttella, sind Ad-Hoc Systeme (blinde Systeme), kunden, sondern beispielsweise von der Zeit um eine Datei zu empfangen, oder wieviel
dass heißt ein Peer muß eine Suchanfrage zu vielen anderen Peers schicken, die wiederum Bandbreite eine Suchabfrage benötigt. Hybride Systeme versuchen durch teilweise zentrale
eine Suche starten. Die Suchzeit kann in schlechten Fällen unbegrenzt sein, was das System Verwaltungsmechanismen die Performance zu steigern. Das Problem mit sehr dezentralen
nicht deterministisch macht. System ist, dass viele Nachrichten von Hop zu Hop weitergeschickt werden müssen und so
viel Bandbreite konsumiert wird.
Bei vielen Peer 2 Peer Systemen (CAN, Chord, Oceanstore, PAST) verwaltet jede Node
eine kleine Anzahl an anderen Nodes im System. Die Anzahl der zu verwaltenden Zustände Es gibt drei häufige Methoden, die angewendet werden können, um die Performance zu
ist dadurch limitiert, was eine Steigerung der Skalierbarkeit als Folge hat. Solche Systeme verbessern:
haben eine Skalierbarkeit von Milliarden Benutzern und über 1014 Files.
• Replication: Durch diese Methode werden Kopien von Objekten näher bei Peers
platziert, die das Objekt gerade anfordern, um die Entfernung zu minimieren. Ände-
2.4.2 Anonymität rungen in den Daten müssen auch bei den Replikaten erneuert werden. Die geographi-
sche Verteilung der Peers hilft, um geeignete Positionen für Kopien zu finden. Durch
Das Free Haven Projekt ([Free Haven]) legt folgende Punkte der Anonymität fest: die Ad-Hoc Connectivity von Peers, ist Replication auch nützlich wenn Peers die Ver-
bindung zum System trennen, aber andere Peers diese Objekte trotzdem gespeichert
• Der Autor oder Hersteller eines Dokumentes oder Files kann nicht identifiziert werden. haben.

• Die Person, die das Dokument oder File im System veröffentlicht, kann nicht identifi- • Caching: Caching reduziert die Pfadlänge, die benötigt wird, um ein Objekt zu
ziert werden. empfangen. Wird ein Objekt empfangen, cachen alle oder einige Nodes die zwischen
den beiden Peers liegen das Objekt.
• Benutzer, die das Dokument oder File lesen beziehungsweise downloaden, können nicht
identifiziert werden. • Intelligentes Routing: Durch intelligentes Routen durch das Peer 2 Peer Netzwerk
kann die Performance drastisch gesteigert werden. Das Routing in Peer 2 Peer Netz-
• Peers, die das Dokument oder File besitzen, können nicht identifiziert werden. werken ist aber ein sehr komplexes Thema, weshalb wir auf einschlägige Literatur
verweisen.
• Ein Server kann bezüglich einer Suchanfrage, nicht sagen was das gefundene Dokument
beinhaltet. 2.4.6 Security
Peer 2 Peer Systeme haben bezüglich Sicherheit viel mit üblichen Verteilten Systemen ge-
Prinzipiell gibt es drei Formen der Anonymität, egal in welcher Form sie vorliegt. Sender-
meinsam, weshalb wir nur auf einige Möglichkeiten eingehen werden.
Anonymität, Empfänger-Anonymität oder Mutual-Anonymität (beides) ([Pfitzmann 1987]).
Welche Arten, welche Techniken und welche Stufen der Anonymität verwendet werden, hängt • Multi-Key Encryption: Die Verschlüsselung basiert auf einem Public Key und meh-
von den Peer 2 Peer Systemen selbst ab. reren Private Keys (Für den Ersteller, den Besitzer,. . . ). Die sogenannten Byzantine-
Attacks waren eine Gefahr für solche Systeme (siehe diverse Dokumente über Byzantine
2.4.3 Cost of Ownership General’s Problem). Aktuelle Fortschritte ([Castro 1999]) minimieren dieses Problem
aber.
Ein grundlegender Punkt bei Peer 2 Peer Systemen ist das Aufteilen der Kosten. Beispiels-
weise ist SETI@Home ([SETI 2001]) bei seinen Berechnungen schneller als der schnellste • Sandboxing: Peer 2 Peer Systeme müssen Code auf Peer-Maschinen ausführen. Es
Supercomputer, und kostet cirka nur 1% desselben ([HP Laboratories]). Das ganze File- ist wichtig, diese Computer davor zu beschützen, dass fehlerhafter oder bösartiger Co-
Sharing Konzept besteht aus der Idee, das jeder einen Teil der Dateien (zum Beispiel MP3) de ausgeführt werden kann. Es muß allgemeine Sicherheitsmaßnahmen geben, sodass
zur Verfügung stellt. kein Computer durch Code beschädigt oder zum Absturz gebracht werden kann. Es
darf auch nur der Datenzugriff auf benötigte Daten erlaubt werden. Techniken, um das
sicherzustellen wären zum Beispiel: Type-safe languages (.NET, Java), Virtual Ma-
2.4.4 Ad-Hoc Connectivity chines (VMWare,. . . ), bestimmte Compiler die spezielle Überprüfungen durchführen
und bestimmte Betriebssysteme (Windows 2003, FreeBSD, . . . ), die eine eigene Stack-
In Peer 2 Peer Systemen können nicht alle Abläufe auf allen System gleichzeitig durchgeführt Architektur haben.
werden. Manche Systeme sind nur kurzfristig oder gar nicht erreichbar. Peer 2 Peer Systeme
müssen mit dieser (bei Peer 2 Peer Systemen üblichen) Art der willkürlichen Verbindungs- • Digital Rights Management: Peer 2 Peer Systeme machen das Vebreiten von
aufnahme durch spezielle Algorithmen (beispielsweise Join/Leave) zurechtkommen. Dateien sehr einfach. Ein wesentlicher Punkt ist deshalb, Copyrightinformationen in
24 2 PEER 2 PEER 2.5 Peer 2 Peer Applikationen 25

Dateien zu speichern. Dazu werden übliche Techniken (Steganographie - zum Beispiel Anlaufstelle für Entwickler und Anwender. Ebenso gibt es Implementierungen, die versucht
Watermarking ) verwendet. sind, eine Basis für Peer 2 Peer Systeme zur Verfügung zu stellen ([JXTA]).
• Bewertungen: Es ist sinnvoll, Bewertungen von Peers abzugeben. Beispielsweise
sollen Peers gut bewertet werden, wenn sie viele Dateien zur Verfügung stellen, diese 2.5 Peer 2 Peer Applikationen
Dateien nicht korrupt sind oder sie oft erreichbar sind. Dieses Kapitel wird Peer 2 Peer Applikationen in Aufgaben-Kategorien aufteilen.
• Firewalls und NAT: Viele Peers befinden sich hinter Firewalls. Firewalls blocken
üblicherweise eingehende TCP/IP Pakets. Ein Peer innerhalb einer Firewall ist von 2.5.1 Allgemeines
aussen nicht erreichbar. Viele Computer verwenden auch NAT (Network Address Peer 2 Peer lassen sich grundsätzlich in 4 Klassen (Abbildung 7 auf Seite 25) unterteilen:
Translation) was die Verbindung mit einem Peer 2 Peer Netzwerk auch erschwert. Fast
alle Firewalls erlauben den ausgehenden Verkehr durch Port 80, womit zumindest die
Verbindung zu einem Peer 2 Peer Netzwerk aufgebaut werden kann (die Verbindung
muss aber vom Computer innerhalb der Firewall aufgebaut werden). Sind beide No-
des, die miteinander in Verbindung treten wollen, hinter Firewalls müssen sogenannte
Reflection-Server eingesetzt werden. Sie regeln die Kommunikation zwischen diesen
Peers.

2.4.7 Transparenz und Usability

Mit der Einführung von dynamischen IP-Adressen oder der Verwendung von NAT ver-
schwand die end-to-end address Transparenz. Die eindeutige Identifikation von Peers ist Abbildung 7: Allgemeine Einteilung von Peer 2 Peer Applikationen in 4 Klassen ([HP Laborato-
aber in Peer 2 Peer Systemen erforderlich, deshalb benötigen Peer 2 Peer Systeme eigene ries]).
Namen-Schemata.

Peer 2 Peer Software sollte keinen großen Konfigurationsaufwand verursachen. Peer 2

Peer Systeme sollten Netzwerk- und Geräte-Transparenz aufweisen, dass heißt, sie sollten 1. Verteiltes Rechnen
unabhängig von Netzwerken und Geräten sein. Verteiltes Rechnen baut sehr erfolgreich auf Peer 2 Peer Systemen auf. Die Idee
besteht darin, nicht benötigte Rechenkapazität von Einzelcomputern für zentrale Be-
Ebenso ist eine automatische und transparente Authentifizierung für die Sicherheit sinn- rechnungen zu nutzen. Das Weltrauminstitut NASA war an dieser Technik von Anfang
voll. an stark interessiert. Zahlreiche Projekte bauten in der Vergangenheit auf verteilten
Berechnungen auf. Typischerweise benötigen verteilte Rechensysteme eine zentra-
Ein Benutzer kann üblicherweise ein Peer 2 Peer System benutzen:
le Kontrollapplikation. Verteilte Berechnungen sind oft Aufgaben, die über mehrere
• als ein Benutzer von Services, typischerweise durch Web-Interfaces (Content Sha- Jahre hinweg laufen. Berechnungen, die zu viel Kommunikation zwischen den einzel-
ring,. . . ). nen Clients erfordern sind für Verteilte Berechnungen nicht gut geeignet (zum Beispiel
Matrix-Berechnungen). Das wohl bekannteste verteilte System ist SETI@Home ([SE-
• durch eine Peer 2 Peer Platform (Groove, .NET,. . . ), welche die Kommunikation TI 2001]), welches auf mehr als 3 Millionen registrierte Computer zugreift und so
ermöglicht. 25 T-Flop/s (1 T-Flop = 1 Milliarde floating point Operationen) an Rechenkapazität
erreicht. SETI@Home ([SETI 2001]) teilt das Hauptproblem in einzelne kleine, un-
• durch eigenständige Peer 2 Peer Software.
abhängige Aufgaben ein, wobei jede einzelne Aufgabe von einem Computer bearbeitet
wird. Die Ergebnisse werden an zentraler Stelle gesammelt.
2.4.8 Fehleranfälligkeit
2. File-Sharing
Ziel von Peer 2 Peer Systemen ist auch, die Möglichkeit von zentralen Fehlern (Beispiel:
Server Fehler) so gering wie möglich zu halten. Bei ganz dezentralen Systemen sind Server- Der File-Sharing Bereich ist der Erfolgreichste unter den Peer 2 Peer Technologien. Ge-
Fehler sogar gar nicht möglich. Dafür gibt es andere Fehlerquellen bei Peer 2 Peer Syste- rade im Multimedia-Bereich fallen große Mengen an Daten an, die mittels File-Sharing
men. Das größte Problem ist, dass Nodes nicht immer erreichbar sind. Das führt dazu effizient verbreitet werden können. Die Vorteile liegen auf der Hand. Die Daten sind
das gewünschte Daten nicht empfangen werden können. Diesem Problem versucht man mit durch Replikationen mehrfach vorhanden und dadurch abgesichert. Die Menge an
Replications entgegenzuwirken. Das zufällige Fehlen oder Erscheinen von Nodes erschwert verfügbaren Speicherplatz ist extrem groß. Ein weiterer Vorteil ist die Anonymität
auch das Routen durch das Peer 2 Peer System. (Raubkopien). Die Verwaltbarkeit ist enorm einfach, da keiner für die Verwaltung
aller Daten verantwortlich ist. Typ und Größe einer Datei verlieren an Bedeutung.
Ganze Dateien sind oft auf mehrere Knoten aufgeteilt, wodurch ein Unsicherheitsfak-
2.4.9 Kompatibilität
tor entsteht (Unerreichbarkeit benötigter Teile). Dem kann aber durch Replikation
Es gibt eigentlich noch keine wirkliche Kompatibilität zwischen den existierenden Peer 2 entgegengewirkt werden. Auf technischer Seite sind eher Performance (zum Beispiel
Peer Systemen. Die Peer 2 Peer Working Group ([P2P Working Group]) ist eine zentrale Suche) oder Routing und Bandbreitenausnutzung relevant.
26 2 PEER 2 PEER 2.6 Peer 2 Peer Applikationen (Fallstudien) 27

3. Kommunikations-Applikationen weitergegeben wird, bis ein oder mehrere Ergebnisse gefunden wurden oder eine gewis-
Der Bereich der Kommunikations-Applikationen gewinnt immer mehr an Bedeutung, se Anzahl an Weitergabeschritten durchgeführt wurde (typischerweise 5-9). Gnutella
da viele Firmen weltweit agieren und billige und schnelle Kommunikation nötig wird. greift auf dieses Modell zurück. Das Modell benötigt eine höhere Netzwerkbandbreite.
Im Allgemeinen sind all diese Kommunikations-Applikationen Ereignis-basierend (Nach- Um diesen Effekt entgegenzuwirken, gibt es Erweiterungen wie zum Beispiel Super-
richt schreiben in einem Chat Programm ist ein Event). Probleme mit denen man in Peers oder Caching.
diesem Bereich kämpfen muß, sind netzwerkbedingte Verzögerungen. Weitere Proble-
me sind Identifikation von Peers und Fehlertoleranz.

4. Platformen
Peer 2 Peer Platformen sind Layer eines Betriebssystems oder Aufsätze auf selbige,
die einfache Implementierungen von Peer 2 Peer Systemen ermöglichen. Dazu gehören
zum Beispiel .NET My Service oder JXTA.

2.5.2 Architektur-Modelle
Es gibt drei verschiedene Implementierungsmodelle, die häufig verwendet werden.

1. Zentralisiertes Verzeichnis-Modell
Dieses Modell (Abbildung 8 auf Seite 26) wurde durch Napster bekannt und zeigte
dort seine Effektivität. Ein Peer der neue Datein anbieten möchte, registriert die-
se bei einem zentralen Verzeichnis. Sollte ein anderer Peer nun diese Datei suchen
(Keywords,. . . ) so wird über dieses Verzeichnis nach der Datei gesucht. Dabei ist es
möglich, bestimmte Anforderungen mit einzubringen (Geschwindigkeit, Zuverlässig-
keit,. . . ). Der Datenaustausch erfolgt danach direkt zwischen den zwei Peers. Man
könnte vermuten, dass diese Architektur bei steigender Anzahl an Peers schnell an
ihre Performancegrenzen stößt. Napster hat jedoch bewiesen, dass dieses Modell sehr Abbildung 9: Flooded Request-Modell kommt bei Gnutella zum Einsatz ([HP Laboratories]).
zuverlässig und effizient funktioniert.

3. Document Routing-Modell
Siehe Grafik (Abbildung 10 auf Seite 28): Dokumenten, die freigegeben werden sollen,
wird eine eindeutige Kennzahl (Hash) zugewiesen, die aus Dokumenttitel und Inhalt
generiert wird. Jedem Peer in dem Netz wird ebenfalls ein GUID (global unique identi-
fier ) zugewiesen. Bei der Freigabe eines Dokumentes, wird dieses Dokument von Peer
zu Peer stets weitergereicht, wobei jeder Peer eine gegebene Anzahl an anderen Peers
kennen muss, bis das Dokument bei dem Peer landet, der die ähnlichste GUID hat.
Bei jeder Weitergabe, wird das Dokument auch bei jedem Peer gesichert (Caching,
Replication). Bei einer Anfrage wird das Dokument solange weitergereicht, bis es der
anfragende Peer erhält. Auch dabei wird das Dokument stets zwischengespeichert.
Obwohl dieses Modell sehr effizient für große Netze ist, hat es den Nachteil, dass die
Dokument-Kennzahl vor Anfrage bekannt sein muß.

2.6 Peer 2 Peer Applikationen (Fallstudien)

Abbildung 8: Zentralisiertes Verzeichnis-Modell wurde beispielsweise bei Napser verwendet ([HP Dieses Kapitel befasst sich mit einzelnen bekannten Beispielen für Peer 2 Peer Applikationen.
Laboratories]).
2.6.1 SETI@Home
SETI@Home ([SETI 2001]) ist ein wissenschaftliches Forschungsprojekt dessen Ziel es ist,
2. Flooded Request-Modell eine große Anzahl von Computern, die über das Internet angebunden sind, während deren
Dieses Modell (Abbildung 9 auf Seite 27) entspricht einem Pure Peer 2 Peer Model, in- Leerlaufzeit zu nutzen. Das Projekt fand reißende Akzeptanz und liefert heute eine Rechen-
dem keinerlei Möglichkeit besteht, eine vollständige Liste aller verfügbaren Resourcen kraft von cirka 25 T-Flop/s (1 T-Flop = 1 Milliarde floating point Operationen). Das Ziel
zu erhalten. Das Modell basiert darauf, dass eine Anfrage stets an benachbarte Peers von SETI@Home ist das Auffinden von extraterrestrischen Radioemissionen. SETI@Home
28 2 PEER 2 PEER 2.7 Gnutella Meßungen 29

2.7.2 Down/Up-Stream Bottleneck Untersuchungen

Auf der linken Grafik (Abbildung 11 auf Seite 29) erkennt man ein erwartetes Verhalten.
Ein Upstream-Bottleneck tritt bei fast allen Benutzern vor einem Downstream-Bottleneck
auf. Dies ist darauf zurückzuführen, dass der Upstream bei den meisten Benutzern niedriger
ist als der Downstream. Auf der rechten Grafik (Abbildung 11 auf Seite 29) erkennt man das
Gnutella beim Downstream überlegen ist, da bei Napster Bottlenecks immer früher erreicht
werden.

Abbildung 10: Document Routing-Modell ([HP Laboratories])

existiert schon so lange, dass die Qualität der Applikation an sich schon einen sehr hohen
Standard erreicht hat. Es gibt Implementierungen für fast alle Platformen. SETI@Home
hat trotz eines Management-Servers gute Skalierbarkeit gezeigt (cirka 3 Millionen Benutzer).

2.6.2 Gnutella
Abbildung 11: Down/Up-Stream Bottleneck Vergleiche bei Gnutella/Napster ([GRIBBLE])
Bei Gnutella ([GNUTELLA 2001]) handelt es sich um ein File-Sharing Protokoll. Applikatio-
nen, die dieses Protokol implementieren, geben diesen die Möglichkeit Dateien von anderen
Benutzern downzuloaden. Gnutella wurde im März 2000 von 2 Entwicklern der NullSoft-
Division der Firma AOL implementiert. Es wurde als Open-Source Programm ausgelegt und
funktionierte sehr ähnlich wie Napster. Gnutella wurde aber gleich am nächsten Tag wieder 2.7.3 Session Dauer
offline genommen, da AOL eine Gefahr für Warner-Music und EMI sah. Der Source-Code
Siehe Grafik (Abbildung 12 auf Seite 29): Die Session-Dauer ist bei Napster und Gnutella
des Programmes blieb jedoch lange genug online um sich in der ganzen Welt zu verbreiten.
annähernd gleich. Man erkennt, dass die Mehrzahl der Benutzer lange verbunden bleibt.
Gnutella ist vollkommen dezentral, wodurch ein sehr hoher Anonymitätsgrad erreicht wird.
Das hat große Vorteile für das Peer 2 Peer Netzwerk.
Gnutella ist nicht wirklich eine Software sondern ein Kommunikationsprotokol. Um eine
Verbindung aufzubauen, muß der User die IP-Adresse eines anderen Gnutella-Nodes wissen.
Bei einer Anfrage wird diese an alle bekannten Knoten weitergereicht, solange bis das im
Paket enthaltene time-to-live-Feld 0 ist. Gnutella ist nicht in hohem Grade skalierbar, da
durch das exponentielle Wachstum von Anforderungen beim Weiterreichen enormer Netz-
werktraffic entsteht. Das Protokoll ist nicht sehr fehlertolerant, da nur eine geringe Anzahl
an Benutzern so lange online ist, um Anfragen zu beantworten. Anhand des Broadcast-
Systems gibt es keine garantierte Lösung zu diesem Problem.

2.7 Gnutella Meßungen

2.7.1 Gnutella Bandbreiten
• 60% der Benutzer haben eine Breitbandverbindung (Kabel, DSL, T1 oder T3)
• 30% der Gnutella Benutzer haben sehr hohe Bandbreiten (3 MBit/s oder höher)
• Bottlenecks treten bei Gnutella-Benutzern später auf als bei Napster Benutzern.
Sowohl bei Gnutella als auch bei Napster gibt es die Möglichkeit die verfügbare Band-
breite eines Peers vom Benutzer selbst einzustellen. Der Benutzer selbst hat dabei keinen
Vorteil, weswegen viele Benutzer eine geringere Bandbreite als tatsächlich vorhanden ange- Abbildung 12: Session Dauer Vergleiche zwischen Napster und Gnutella ([GRIBBLE])
ben um weniger Download-Requests zu empfangen. Das hat aber einen negativen Effekt auf
das intelligente Routing-Verhalten des Systems.
30 2 PEER 2 PEER 2.8 Zusammenfassung 31

2.7.4 Shared Files

Anhand der linken Grafik (Abbildung 13 auf Seite 30) sieht man eindeutig das mehr als
25% der Gnutella-Peers kein einziges File zur Verfügung stellen. 75% stellen weniger als 100
Files zur Verfügung. Nur etwa 7% aller Clients stellen über 1000 Files zur Verfügung. Eine
einfache Berechnung zeigt auf, dass diese 7% zusammen mehr Files anbieten als der Rest
der Benutzer. Die rechte Grafik (Abbildung 13 auf Seite 30) zeigt, dass Napster eine größere
Anzahl an Benutzern mit ähnlicher Anzahl von shared Files hat.
Abbildung 15: Topologie des Gnutella Netzwerkes ([GRIBBLE]).

2.8 Zusammenfassung
Wir glauben, dass Peer 2 Peer Systeme eine wichtige Technologie ist, die mittlerweile in
zahlreichen Produkten und Forschungsprojekten eingesetzt wird. Auch in Zukunft wird
vermehrt auf Peer 2 Peer Systeme zurückgegriffen werden, wenn verteilte Probleme zu lösen
sind. Peer 2 Peer Systeme sind sicher nicht die einzige Lösung und sicher nicht in jedem Fall
anwendbar, stellen aber durch ihre hohe Skalierbarkeit, Anonymität und Fehlerresistenz
Abbildung 13: Shared Files von Benutzern bei Gnutella überhaupt und im Vergleich zu Napster
durchaus eine Alternative zu anderen Modellen dar. Peer 2 Peer Systeme werden einen
([GRIBBLE]).
weiteren Einsatzbereich bei der verteilten Wartung und Installation von Software (SMS)
finden. Peer 2 Peer ist nicht nur eine interessante Forschungstechnologie, sondern auch eine
vielversprechende Produktbasis.
Grafik (Abbildung 14 auf Seite 30) kann folgendermaßen interpretiert werden: Nach-
dem bei Napster alle Dateien im MP3-Format vorliegen müssen und ein durchschnittliches
MP3-File eine Größe von 3,7 MB hat, ergibt sich eine lineares Verhalten zur Anzahl der Fi- Literaturverzeichnis
les. Dadurch ist bei Gnutella (wo beliebige File-Typen erlaubt sind) das Verhältnis breiter
gefächert. [Castro 1999] Castro M. and Liskov B. 1999: Practical Byzantine Fault Tolerance
[FTP 1985] FTP RFC: FTP
[gezeichnet: Fürnstahl 2003] Philipp Fürnstahl 2003
[Free Haven] Free Haven Homepage: Free Haven Project
[GNUTELLA 2001] Gnutella Hompage: GNUTELLA
[GRIBBLE] Steven Gribble: A Measurement study of Peer 2 Peer File Sharing Systems
[HP Laboratories] Dejan S. Milojicic, Vana Kalogeraki, Rajan Lukose, Kiran Nagaraja1,
Jim Pruyne, Bruno Richard, Sami Rollins 2 ,Zhichen Xu, HP Laboratories Palo
Abbildung 14: Anzahl Shared Files / Menge Shared Data bei Gnutella und Napster ([GRIBBLE]). Alto 2002: Peer 2 Peer Computing
[IMESH] iMesh Homepage: iMesh
[JXTA] JXTA Hompage: JXTA

2.7.5 Topologie des Gnutella Netzwerkes [KAZAA] KaZaA Hompage: KAZAA

[Morgan 2002] Morgan J. 2002: Personal Communication
Siehe Grafik (Abbildung 15 auf Seite 31): Grafik (a) zeigt die Verbindungen von 1771 Knoten
im Gnutella Netzwerk am 16.02.2001. Auf Grafik (b) sieht man den Zustand nachdem [P2P Working Group] Peer 2 Peer Working Group Homepage: Peer 2 Peer Working Group
man zufällig 30% der Knoten entfernt hat. Das Netzwerk ist nahezu vollständig verbunden
und funktionstüchtig. Bei Bild (c) wurden die 63 höchstgradigen Knoten (weniger als 4%) [Pfitzmann 1987] Pfitzmann A., Waidner M. 1987: Networks without User Observability
entfernt, was zu vielen einzelnen kleineren Netzen geführt hat. Dieses Verhalten ist durchaus [SETI 2001] Seti Hompage: SETI@Home
auf andere dezentrale Peer 2 Peer Systeme übertragbar. Dadurch sind diese Systeme leicht
verwundbar gegenüber gezielten Angriffen. [Shirky] Clay Shirky: Peer 2 Peer Definition
32 LITERATURVERZEICHNIS 33

[Tanenbaum 2002] Andrew S. Tanenbaum and Maarten van Steen 2002: Distributed Sy- 3 Wireless LAN
stems, Principles and and Paradigms
Dieser Artikel bietet einen kurzen Überblick über den aktuellen Stand bei Wireless LANs.
[Taylor 2003] Ian Taylor 2003: Peer 2 Peer Systems Vor allem die Sicherheitsaspekte von WLANs werden genauer betrachtet. Die Schwächen
des Sicherheitsprotokolls des aktuellen WLAN-Standards werden erklärt. Außerdem wird
aufgezeigt, wie diese Schwächen von Hackern genützt werden können, um in fremde WLANs
einzudringen und Daten auszuspähen. Die dafür nötigen Sniffer-Tools werden anschließend
vorgestellt.
In Folge werden aktuelle Verbesserungsmöglichkeiten sowie der kommende IEEE Stan-
dard 802.11i erörtert.
Abgeschlossen wird der Artikel mit einem Einblick in die rechtliche Situation betreffend
Datenschutz in Österreich und Deutschland.

Alter Monika: alterm@[Link]; Abschnitt 3.5, Abschnitt 3.6, Abschnitt 3.8

Baumgartner Kerstin: kessi@[Link]; Abschnitt 3.1, Abschnitt 3.2
Schmid Elisabeth: eschmid@[Link]; Abschnitt 3.3, Abschnitt 3.4, Abschnitt 3.7

3.1 Einführung
Die Abkürzung WLAN bedeutet Wireless Local Area Network und es handelt sich dabei
um ein lokales Funknetzwerk. Es werden also die Daten “drahtlos” durch elektromagneti-
sche Wellen übertragen. Es wird hauptsächlich für die Anbindung von mobilen Clients an
ein Netzwerk (Infrastrukturmodus) verwendet. Es kann aber auch für den Datentransfer
zwischen zwei Geräten (Ad-Hoc-Modus) eingesetzt werden.
Ad-Hoc Netzwerke entstehen meistens spontan, ändern häufig ihre Infrastruktur oder
werden nur temporär benutzt. In diesem Modus kommunizieren zwei Stationen in Form
eines Peer-To-Peer (P2P) Netzwerks miteinander. Im 802.11-Standard wird eine räumli-
che Region, innerhalb der Stationen miteinander kommunizieren können, Basic Service Set
(BSS) genannt. Ein Ad-Hoc Netzwerk ist ein BSS, das nicht mit weiteren Netzwerken ver-
bunden ist, und wird daher auch als Independent BSS (IBSS) bezeichnet.
Beim Infrastrukturmodus übernimmt ein so genannter Access Point (AP) eine Mittler-
position zwischen den mobilen Clients und/oder auch mit einem LAN. Solch eine Zelle wird
im 802.11-Standard als Infrastruktur Basic Service Set bezeichnet. Durch Einbindung meh-
rerer solcher AP’s in ein verkabeltes Ethernet kann die Reichweite des drahtlosen Netzwerkes
ausgedehnt werden und die mobilen Clients können ohne Verbindungsverlust zwischen den
einzelnen AP-Domains bewegt werden. Im 802.11 Standard wird solch ein Netzwerk Exten-
ded Service Set (ESS) genannt.
Die Abbildung 16 zeigt das oben beschriebene Distribution System.
Dieses Distribution System nach dem 802.11 Standard ermöglicht folgende Services:

Distribution Service: Datenübermittlung zwischen den AP’s von Sendern und Empfängern.
Integration Service: Datenübermittlung vom AP der sendenden Station zum Portal des
Empfängers im LAN
Association Service: An- bzw. Abmeldung von Stationen beim Wechsel ihres BSS und
Benachrichtigung aller AP’s im Distribution System über den neuen Standort.

Die Reichweite eines AP’s liegt typischerweise in Gebäuden im Bereich von 10 m bis 100
m. Der Empfangsbereich ist aber von den verwendeten Antennen, der Sendeleistung und
den baulichen Gegebenheiten abhängig.
Punkt zu Punkt Verbindungen erreichen bei Sichtverbindung wesentlich höhere Reich-
weiten. Mit speziellen Richtantennen sind sogar mehrere Kilometer möglich, um Distanzen
34 3 WIRELESS LAN 3.1 Einführung 35

kontinuierlich auf einem breiten Frequenzband versendet. Der Empfänger kann das Si-
gnal nur dann empfangen, wenn ihm dieser Code bekannt ist. Diese Technologie ist wegen
der höheren Übertragungsraten (11 Mbps) am weitesten verbreitet. Im Standard 802.11b
wird nur mehr diese Technologie verwendet. Die Infrarot-Variante wird zurzeit von keinem
Netzwerk-Produkt unterstützt.
Die meisten WLANs benutzen das ISM-Band (Industrial-Scientific-Medical). Dieses
2,4 GHz-Band ist bis auf wenige Ausnahmen weltweit freigeben und darf ohne Genehmi-
gung benutzt werden. Leider verläuft der Datenverkehr in diesem Bereich nicht störungsfrei,
da neben Funksendungen anderer WLANs auch z.B. Mikrowellen als Störquellen in Frage
kommen.
Im 802.11b-Standard sieht die Kanalaufteilung wie folgt aus (siehe auch Abbildung 18):

• Kanalbreite je 22 MHz

• Kanäle sind überlappend

Abbildung 16: Distribution System (Abbildung aus [Intelligraphics]) • in Europa 13 Kanäle; in USA, Kanada 11 Kanäle

zwischen Gebäuden überbrücken zu können. Somit können zwei LANs mit Hilfe von Wireless
Bridges verbunden werden.
Der IEEE 802.11 Standard ist die genaue Bezeichnung des Standards für drahtlose Netz-
werke und ist im Juni 1997 verabschiedet worden. Seitdem ist er aber um eine Reihe von
Dokumenten erweitert worden. Erst 1999 mit der Verabschiedung von IEEE 802.11b kam es
zu einer größeren Verbreitung von WLANs, da mit dieser Erweiterung eine Übertragungs-
rate von bis zu 11 Mbps aufgebaut werden kann, während mit dem Originalstandard 802.11
nur 2 Mbps möglich waren.
Die Familie der IEEE 802.11 Standards definiert vor allem die zwei untersten Schichten Abbildung 18: Kanalaufteilung und -überlappung bei 2,4 GHz (Abbildung aus [Hübner 2003])
des OSI-Referenzmodells, wie in Abbildung 17 dargestellt. Die Spezifikation umfasst die
Beschreibung eines Media Access Control (MAC)-Protokolls und drei alternative Physical
Layer (PHY)-Technologien. Zwei davon sind Frequenzspreizverfahren (Frequency Hopping Daraus ergibt sich ein weiterer Nachteil dieses Bandes, da somit nur drei Kanäle zum
Spread Spectrum FHSS bzw. Direct Sequence Spread Spectrum DSSS) und eines funktio- konkurrierenden Betrieb zur Verfügung stehen.
niert auf Infrarot-Basis.
3.1.1 Die Standardfamilie 802.11
In diesem Abschnitt werden die IEEE Standars 802.11g, 802.11a und 802.11h kurz vor-
gestellt. Der Standard 802.11g ist der rückwärtskompatible Nachfolger von 802.11b und
erreicht eine Datenrate von bis zu 54 Mbps.
Im 5 GHz-Bereich bietet der 802.11a Standard Datenraten bis zu 54 Mbps. Dieser
Standard ist in Europa aber nicht zugelassen, sondern nur dessen europäisches Pendant
HiperLAN/2. Außerdem bringt er noch einige andere Nachteile mit sich:

Abbildung 17: IEEE 802-Standards eingebettet im OSI-Modell (Abbildung aus [Intelligraphics]) • Durch die Nutzung der höheren Frequenz ergibt sich eine höhere Dämpfung und eine
starke Anfälligkeit gegen Rauschen, Abschattungen und andere parasitäre Effekte.

• 5 GHz WLANs haben eine um die Hälfte kleinere Reichweite als 2,4 GHz Funknetze,
Bei FHSS wird das Nutzsignal auf ein permanent die Frequenz wechselndes Trägersignal was eine doppelte Anzahl an APs bedeutet.
aufmoduliert. Das Schema des Frequenzwechsels wird durch die Hopping-Sequenzen fest-
gelegt, die synchronisiert sein müssen, damit sich Sender und Empfänger verstehen. Durch • Sie benötigen kostenerhöhende technische Maßnahmen um die Störeffekte zu verrin-
Wahl von unterschiedlichen Sequenzen können mehrere WLAN’s in einem Empfangsbereich gern.
operieren.
Bei DSSS wird jedes Bit in eine Bitfolge verschlüsselt, die auf das Frequenzband auf- Daher eignen sich 5 GHz WLANs nur für große Funknetze, in denen der Vorteil von acht
gespreizt gesendet wird. Es wird hierfür ein Pseudo-Noise-Code verwendet, der das Signal parallel zur Verfügung stehenden Kanälen ausgenutzt werden kann.
36 3 WIRELESS LAN 3.2 Wired Equivalent Privacy 37

Der Standard 802.11h stellt die europäische Variante des 802.11a-Standards dar. Es bie- Produkte verliehen, die ihre Zusammenarbeit mit Produkten anderer Hersteller unter Beweis
tet mit dynamischer Frequenzauswahl (DFS = Dynamic Frequency Selection) und variabler gestellt haben. Dieses Zertifikat sagt nichts über die Sicherheit aus.
Sendeleistung (TPC = Transmit Power Control) zwei Zusatz-Features, die das ETSI (Eu-
ropäischen Standardisierungsinstitut für Telekommunikation) für den europäischen Markt 3.2 Wired Equivalent Privacy
verlangt.
Da es sich bei Funk um ein Shared Medium handelt, müssen Sicherheitsmechanismen im-
3.1.2 Media Access Control plementiert werden, die die folgenden drei Bereiche abdecken:

Dieser Abschnitt beschreibt den Media Access Control (MAC) Layer des 802.11 Standards. • Vertraulichkeit
Bei WLANs kann das aus dem Ethernet bekannte Verfahren CSMA/CD zur Koordinie-
rung des Medienzugriffes nicht verwendet werden, da bei drahtlosen Netzen nicht gleichzeitig • Zugangskontrolle
gesendet und empfangen werden kann. Aus diesem Grund kann ein Teilnehmer des Netzes
• Datenintegrität
nicht überprüfen, ob ein anderer nicht gerade dasselbe macht. Deshalb wird in der 802.11
Standardfamilie das CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) Pro- In 802.11 wurde zur Verschlüsselung und Authentifizierung WEP (Wired Equivalent
tokoll verwendet: Privacy) spezifiziert. WEP benutzt den Stromchiffrierer RC4 (Ron’s Code 4, entwickelt von
1. Sendewillige Station hört das Medium ab. Ronald L. Rivest 1987).
Bei RC4 handelt es sich im Prinzip um einen Pseudozufallszahlengenerator, der mit einen
2. Ist das Medium für die Dauer eines Inter Frame Space (IFS) frei, wird gesendet. Startwert initialisiert wird und für jedes zu verschlüsselnde Byte eine Zufallszahl ausgibt.
3. Ist das Medium belegt, wird auf ein freies IFS gewartet und dann zusätzlich um eine Diese beiden Bytes werden dann anschließend mit XOR verknüpft, wodurch man das chif-
zufällige Backoff-Zeit verzögert (Kollisionsvermeidung). frierte Byte erhält. Die Entschlüsselung erfolgt analog. Es wird dabei ein geheimer Schlüssel
verwendet, der sowohl den Sender als auch den Empfänger bekannt ist. Es wird mit Hilfe
4. Wird das Medium während der Backoff-Zeit von einem anderen Sender belegt, bleibt desselben Startwertes eine identische Folge von Pseudozufallszahlen erzeugt, die durch XOR
der Backoff-Timer solange stehen. mit dem verschlüsselten Text verknüpft werden. Somit erhält man wieder den Klartext
Bei WEP sind zwei Schlüssellängen spezifiziert 40 und 104 Bit. Der Standard macht
Kollisionen ergeben sich dann nur mehr, wenn entweder zwei sendewillige Stationen die
keine Angaben wie diese Schlüssel verteilt und ausgemacht werden. Es werden pro Paket
gleiche Backoff-Zeit wählen oder durch das Problem der “unsichtbaren Teilnehmer”. Es
die Nutzlast und der Integrity Check Value4 (ICV) mit RC4 verschlüsselt. Der ICV wird
ist möglich, dass zwei Stationen, sich nicht in gegenseitiger Reichweite befinden, aber zur
aus dem Klartext mit Hilfe einer CRC Berechnung erzeugt. Um zu verhindern, dass immer
gleichen dritten Station senden wollen. Sie sind also nicht in der Lage, zu hören, ob der
derselbe Initialisierungsvektor (IV) benutzt wird, entsteht der RC4-Initialisierungswert aus
andere Teilnehmer nicht bereits sendet. Aus diesem Grund sendet eine Station nicht sofort
einer Verkettung eines 24 Bit langen Initialisierungsvektor mit dem geheimen Schlüssel. Da
die Daten, sondern zuerst eine Anfrage. Erst nach Erhalt einer Sendebestätigung wird das
dieser Vektor auch dem Empfänger bekannt sein muss, wird dieser Wert im Header des
Paket übermittelt. Dieser Ablauf ist in Abbildung 19 dargestellt.
MAC-Pakets als Klartext mitübertragen.
Das MAC-Frame-Format für WEP sieht also folgendermaßen aus:

Präambel / PLCP Header / MAC Header / IV / Nutzdaten / ICV / FCS

Der Empfänger verkettet zur Entschlüsselung nun den mitgesendeten IV mit dem gehei-
men Schlüssel und entschlüsselt das gesendete Chiffrat mit RC4 um den Klartext und den
ICV zu erhalten. Danach führt er ebenfalls eine CRC Berechnung durch und überprüft, ob
der dadurch gewonnene ICV gleich dem Mitgesendeten ist, um die Integrität sicherzustellen.
Es wird pro Paket ein neuer IV gewählt.

3.3 WEP-Attacken
Abbildung 19: CSMA/CD (Abbildung aus [Uni Oldenburg]) Das WEP-Sicherheitsprotokoll, welches im Standard 802.11 enthalten ist, bietet etliche An-
griffsflächen. Mit den geeigneten Tools und etwas Zeit können Zugangshürden überwunden
werden. Nahezu jeder WLAN-Kartentreiber kann eine andere als die vom Hersteller zu-
gewiesene MAC verwenden. Die “erlaubten” MAC Adressen werden mit einem geeigneten
3.1.3 Wireless Fidelity Sniffer (siehe z.B. Kismet Abschnitt 3.4.3) ausgelesen oder es wird einfach solange probiert,
Ein weiteres oft genanntes Schlagwort ist Wireless Fidelity (WI-FI). bis man Zugang erhält.
Das WI-FI Konsortium3 ist eine internationale Non-Profit Organisation mit dem Ziel Die größere Schwachstelle ist aber der “geheime” Schlüssel und vor allem der Initialisie-
die Zusammenarbeit von WLAN-Produkten zu zertifizieren. Das Wi-Fi Logo wird nur an rungsvektor (IV). Die meisten WLANs verwenden einen geheimen Schlüssel für alle Clients
3 [Link] 4 Prüfsumme
38 3 WIRELESS LAN 3.4 Sniffer 39

und den AP. Aber dieser Schlüssel ist meist gar nicht für die Entschlüsselung notwendig. 3.4.1 NetStumbler
Daher ist die Schlüssellänge nicht wirklich relevant, da der IV sowohl bei Schlüssellängen von
Bei NetStumbler5 handelt es sich um ein Freeware-Hilfsprogramm für Windows. WLANs
64 bzw. 128 Bit genau 24 Bit lang ist. Somit beträgt die eigentliche WEP-Schlüssellänge
innerhalb der Reichweite werden aufspürt. Informationen über die jeweiligen Client-Adapter
bei 64 Bit-Verschlüsselung effektiv nur 40 Bit (64 - 24).
und Access Points werden ermittelt. Wenn der Hersteller des Access Points bekannt ist, sind
Aus folgendem Grund sollte man darauf achten, dass nie zwei Pakete mit demselben
auch die Default Werte für den Administrator Zugang ermittelbar. Mit einem geeigneten
IV verschlüsselt werden. Zwei Nachrichten N1 und N2 ergeben mit dem Schlüssel S zwei
GPS Receiver können Karten mit dem Empfangsbereich der Netze erstellt werden.
codierte Informationen C1 und C2.

C1 = N1 XOR S 3.4.2 AiroPeek

C2 = N2 XOR S
AiroPeek6 ist ein professioneller Protokoll-Analyzer für IEEE 802.11b von WildPackets, der
Wenn beide codierte Nachrichten abgefangen werden, erhält man: Anomalien im Netzwerkverkehr erkennt und löst. Die Hauptaufgabe ist nicht das Aufspüren
von WLANs. Dem Anwender werden detaillierten Informationen über das Geschehen in
C1 XOR C2 = N1 XOR S XOR N2 XOR S seinem Funknetz zur Verfügung gestellt. Unter anderem können Datenrate, Kanäle und
C1 XOR C2 = N1 XOR N2 XOR S XOR S Signalstärke für jedes Paket angezeigt und Statistiken erstellt werden. Es können nicht
C1 XOR C2 = N1 XOR N2 nur Ethernet Frames dekodiert werden, sondern alle 802.11 Protokolle für WLAN. Das
Programm eignet sich zum Aufspüren “wilder” APs, die zum eigenen Netz Verbindung
Mit stochastischen Methoden lässt sich daraus in vielen Fällen der Originaltext rekon- herzustellen versuchen.
struieren.
Zusätzlich gibt es noch eine Reihe von anderen Attack-Möglichkeiten, wie zum Beispiel: 3.4.3 Kismet
Wörterbuch Attacke: Eine sehr große Menge von Datenpaketen wird mitgeschnitten, um Kismet7 ist ein Freeware Tool für Linux zum Aufspüren von WLANs, das zusätzlich In-
einzelne Datenpakete zu entschlüsseln. formationen wie den Status der Verschlüsselung oder die Verfügbarkeit des DHCP-Dienstes
liefert. Der große Vorteil dieses Tools ist die Flexibilität, da nahezu alle Karten für Li-
Datenmodifikation: Bei zumindest teilweise bekannter Struktur können Pakete gezielt
nux unterstützt werden. Unter den verschiedenen Features findet man das Detektieren von
modifiziert werden, indem einzelne Bits gekippt werden.
NetStumbler Clients.
Paket-Erstellung: Wenn sowohl ein bekanntes verschlüsseltes und entschlüsseltes Paket
zur Verfügung steht, können beliebig viele gültige lange Pakete erzeugt werden. 3.4.4 Wellenreiter
Brute Force Attacke: Bei der Brute Force Attacke wird der Umstand ausgenützt, dass Wellenreiter8 detektiert Netzwerke mit ESSID Broadcasting und mit deaktivierten Broad-
manche Hersteller den IV am Beginn auf 0 setzen und dann schrittweise um eins casting. Außerdem werden Hersteller und WEP Fähigkeiten ermittelt. DHCP und ARP
erhöhen. Daher ist es durchaus möglich mit einer Brute Force Attacke den Schlüssel Datenverkehr werden dekodiert, um weitere Informationen über das Netzwerk anzuzeigen.
zu erraten. Mit einem geeigneten GPS Device und gpsd können die Standpunkte der entdeckten Netz-
werke mitgetrackt werden.
Replay Attacke: Bei der Replay Attacke wird ein verschlüsseltes Paket ein weiteres Mal
von außen über die Basisstation gesendet. Somit wird die Basisstation versuchen, das
Paket ein zweites Mal zu “verschlüsseln”. Die Eigenschaften von WEP führen dazu, 3.4.5 WEPCrack
dass beim zweiten Verschlüsseln das Ergebnis der entschlüsselte Plaintext ist. WEPCrack9 ist ein Open Source Tool zum Cracken der geheimen Schlüssel von 802.11 WEP.
Es handelt sich dabei um eine Implementierung der von Fluhrer, Mantin, and Shamir (siehe
Evil Twin Attacke: Bei der Evil Twin Attacke wird eine zweite Basisstation, ausgestattet
[Fluhrer et al 2001]) beschriebenen Attacke. WEPCrack ist eine auf Perl basierende Script-
mit dem gleichen Namen (wie die ursprüngliche Basisstation) und einer stärkeren
Sammlung und demonstriert die bereits oben beschriebenen Sicherheitslücken schwacher IV
Sendeleistung in die Reichweite des AP eingebracht. Die meisten Clients werden die
bei WEP. Dieses Tool kann unter Linux und bei vorhandenen Perl Interpreter auch unter
falsche Basisstation, die ohne Verschlüsselung betrieben wird, verwenden. Die Clients
Windows verwendet werden.
schalten dann sogar zum Teil die eigene Verschlüsselung ab. Mit einer anschließenden
Man-in-the-Middle-Attacke können die Daten über die falsche Sendestation verfälscht
und Sicherheitsmechanismen ausgehebelt werden. 3.4.6 AirSnort
Bei AirSnort10 handelt es sich um ein Linux Utility (GPL License), dass wie WEPCrack
3.4 Sniffer die WEP-Verschlüsselung knackt. Dazu werden Datenpakete passiv mitgeschrieben. Wenn
Ein Sniffer ist ein Tool zum Aufzeichnen und Auswerten des Netzwerkverkehrs. Das Spek- 5 [Link]
6 [Link]
trum reicht von Tools, die WLANs innerhalb der Reichweite aufspüren bis zu professionellen 7 [Link]
Protokoll-Analyzern. 8 [Link]
In diesem Abschnitt folgt ein kurzer Überblick über sieben Sniffer mit unterschiedlich- 9 [Link]

stem Funktionsumfang. 10 [Link]

40 3 WIRELESS LAN 3.6 Der neue Standard 802.11i 41

genug Pakete gesammelt wurden, wird versucht, die WEP Keys zu ermitteln. Stubblefield, 3.5.3 Global System for Mobile Communications (GSM)
Ioannidis und Rubin von AT&T Labs schufen auf der Grundlage der Arbeit von Fluhrer,
Eine andere Lösungsmöglichkeit wäre, die Sicherheitsmechanismen laut GSM-Standard auf
Mantin und Shamir die Implementierung. Bei schnellen Rechnern funktioniert das bei den
WLANs zu übertragen. Die in GSM verwendeten Mechanismen bieten im Gegensatz zu
meisten WLANs in akzeptabler Zeit. AirSnort funktioniert mit allen gängigen Karten.
dem IEEE Standard 802.11 ein relativ hohes Maß an Sicherheit.
Es gibt erste Lösungen von Nokia und Ericsson, die eine Verbindung von einem WLAN
3.4.7 AP Scanner mit einer GSM-Infrastruktur ermöglichen. Die Authentifzierung erfolgt über ein GSM-SIM,
Mit dem AP Scanner erhält man außer der Anzeige der WLANs innerhalb der Reichweite das in den WLAN-Adapter eingesetzt wird. Die gesamte Abwicklung (Einwählen, Roaming,
nur spärliche Zusatzinformationen. Die Besonderheit dieses Tools ist, dass es auch unter Abrechnung,...) erfolgt über das bestehende GSM-System.
Mac verwendet werden kann. Diese Idee klingt im ersten Moment sehr gut, da ein bestehendes System verwendet wird,
dessen Spezifikation ebenso wie Stärken und Schwächen bestens bekannt und in der Praxis
getestet sind. Allerdings darf nicht übersehen werden, dass es sich auch bei dieser Lösung um
eine proprietäre handelt. Im Jahr 2003 waren noch keine Standards festgelegt. Außerdem
AiroPeak ist sicher ein sehr gutes (aber auch teures) Werkzeug für den Netzwerkadministra- ist hierfür auf jeden Fall spezielle Hardware nötig.
tor. Kismet bietet dagegen viele verschiedene Features, und ist außerdem Freeware.
Grundsätzlich gibt es für Linux eine große Auswahl. Einige Produkte können auch mit 3.5.4 Pass-One
Windows verwendet werden.
Neben der von Nokia und IBM forcierten GSM-WLAN-Variante, gibt es noch einen Lösungs-
ansatz, der sowohl für Mobilfunk- als auch WLAN-Betreiber interessant ist. Pass-One ist
3.5 Verbesserungen der Sicherheit von WLANs eine Lösung die von Wireless ISPs und WLAN-Ausrüstern gestartet wurde. Dieses Sy-
Sicherheit spielt natürlich auch bei Wireless LANs eine große Rolle. Ein WLAN-Betreiber stem dient der Entwicklung eines global akzeptierten Service Level Standards für Hotspots.
muss seinen Kunden eine geschützte Datenübertragung bieten können. Dies ist vor al- Neben Sicherheitsaspekten sind in dieser praxisnahen Lösung auch organisatorische und
lem dann ein Problem, wenn ein WLAN in einer Firma verwendet wird (z.B. als LAN- wirtschaftliche Faktoren von Bedeutung. Insbesondere Roaming also der Wechsel zwischen
Erweiterung) und somit z.B. Kunden- oder Personaldaten zugänglich sind. verschiedenen WLANs soll einfach ermöglicht werden.
Da der aktuelle IEEE 802.11 Verschlüsselungsalgorithmus WEP keine ausreichende Si-
cherheit bietet, gibt es bereits verschiedene Lösungsansätze um diesem Problem zu begeg- 3.6 Der neue Standard 802.11i
nen. Der neue Standard 802.11i wird in Abschnitt 3.6 behandelt, hier werden einige derzeit
Aufgrund der erheblichen Sicherheitsmängel, die WEP aufweist, gibt es die Arbeitsgruppe
gängige proprietäre Lösungen vorgestellt.
TGi die an einer neuen Sicherheitslösung für WLAN arbeitet. Dieser Standardentwurf soll
als 802.11i verabschiedet werden.
3.5.1 Virtual Private Network Die wichtigsten Anforderungen an diese verbesserte Sicherheitslösung waren:
Wenn ein Virtual Private Network (VPN) über einem WLAN betrieben wird, werden sämt-
• Pakete müssen auch authentifiziert, nicht nur verschlüsselt werden.
liche 802.11-Sicherheitsmechanismen weggelassen. Das WLAN wird als öffentliches und da-
mit unsicheres Netzwerk betrachtet, also einfach als ein übertragungsmedium wie Ethernet • Ein Schlüssel wird nur für ein Paket benutzt.
verwendet.
Die gesamte Datenübertragung über das WLAN bis zum VPN-Gateway geht durch einen • Pakete müssen eine verschlüsselte Sequenznummer tragen.
kryptographisch abgesicherten Tunnel. Diese Lösung hat den Vorteil, dass WEP nicht ver-
wendet wird und der Zugang zum dahinter liegenden Netzwerk sauber geregelt ist. Allerdings • Kommunikationspartner müssen sich gegenseitig authentifizieren.
birgt die VPN-Lösung auch Nachteile, da bei grösseren Bandbreiten und vielen gleichzeiti-
Eines der wichtigsten Probleme bei der Erstellung dieses neuen Konzeptes war die
gen Verbindungen die notwendigen Ressourcen und Kosten stark steigen. Außerdem gibt es
Abwärtskompatibilität. Um diese einerseits zu gewährleisten und andererseits langfristig
auch hier verschiedenste Lösungsansätze, ohne dass sich ein Standard durchsetzen konnte.
einen guten Ersatz zu finden, wurden zwei Verschlüsselungsfahren ausgewählt:
Derzeit ist VPN die einzige geeignete Lösung um ein WLAN wirklich abzusichern.
Temporary Key Integrity Protocol (TKIP): Basiert auf WEP um die Kompatibilität
3.5.2 Advanced Mobile Security Architecture zu gewährleisten, aber die größten Schwachstellen fallen weg.
Advanced Mobile Security Architecture (AMSA) ist eine proprietäre Sicherheitslösung von Advanced Encryption Standard (AES): Als langfristiger Ersatz von WEP. AES wird
Agere, die nur auf spezieller Hardware läuft. Für jede Verbindung, die ein Client mit dem vom Offset Codebook (OCB) Modus verwendet.
Access Point öffnet, wird mittels 768-Bit Diffie-Hellman Key Exchange ein individueller RC4-
Schlüssel ausgehandelt. Dabei wird für jede Kommunikationsrichtung ein eigener Schlüssel Bei TKIP wird für jedes Paket ein neuer Schlüssel durch Anwendung einer Hash-Funktion
ausgehandelt. Der Diffie-Hellman Key Exchange ist von einem individuellen Shared-Secret auf dem geheimen symmetrischen Schlüssel, dem IV und einer Paketsequenznummer erzeugt.
(z.B. Benutzerpasswort) abhängig. Der RC4-Schlüssel ist Session-basierend (nicht Frame- Damit soll das Problem des derzeitigen statischen WEP-Schlüssel umgangen werden. Die
basierend wie bei WEP), dadurch entfällt die Notwendigkeit für einen öffentlichen IV, und Authentifizierung von Client und Access Point wird der Standard 802.1x ([IEEE 802.1x])
es stehen die vollen 128 Bit für den Schlüssel zur Verfügung. verwendet. Dieser Standard wurde eigentlich zur portbasierten Netzwerkzugangskontrolle
42 3 WIRELESS LAN 3.7 Gesetzlicher Schutz gegen Attacken auf Funknetze 43

für kabelbasierte Netze entworfen. 802.1x nutzt als Authentisierungssystem das Extensible Informationen und das Umfeld. Die Folge ist, dass ein Hacker von diesem Gesetz überhaupt
Authentication Protocol (EAP), als Authentifizierungs-Instanz dient ein RADIUS-Server11 . nicht berührt wird, solange er sich von personenbezogenen Daten fernhält.
Das offensichtliche Problem hier ist jedoch, dass 802.1x für kabelbasierte geswitchte Netze Das Strafgesetzbuch kennt aber den Tatbestand der Datenbeschädigung
ausgearbeitet wurde, und deshalb nicht auf das Shared Medium bei WLAN ausgerichtet ist. (§ 126a StGB). Dieser Tatbestand ist erfüllt, wenn die eigentliche Computerbenützung ein-
Erste Angriffsmöglichkeiten wurden bereits untersucht. geschränkt wird (z.B. denial of service attack) oder ein Mehraufwand auftritt. Als Mehr-
Für AES, der Nachfolger von DES, wurde der Rijndael-Algorithmus12 von Joan Daemen aufwand gilt z.B. Austausch von Passwörtern, Virenentfernung oder auch der Reboot eines
und Vincent Rijmen vom National Institute of Standards and Technology ausgewählt. Mit Servers.
diesem Verschlüsselungsverfahren wurden die oben genannten Anforderungen erfüllt. Aller- Ein reines akademisches Hacken wäre demgemäß in Österreich derzeit straffrei. Un-
dings setzt auch OCB wieder 802.1x voraus (für die Schlüsselverwaltung und -verteilung). ter “akademischem Hacken” versteht man beispielsweise das bloße Aufspüren von Sicher-
Durch den Einsatz von 802.11i erhöht sich die Komplexität des WLANs. Mit beiden heitslücken ohne sonstige Rechtsverletzungen. Durch die starke Verknüpfung von perso-
Lösungen werden verschlüsselte Sessions zwischen Client und Access Point hergestellt, was nenbezogenen und anderen Daten ist es grundsätzlich sicher sehr schwer, sich auf nicht
sich natürlich negativ auf die Mobilität (Wechsel der Zellen, BSS, ...) auswirkt. personenbezogene Daten zu konzentrieren. Die Gesetzeslücke soll durch Initiativen der EU
und des Europarats geschlossen werden.
3.6.1 Wi-Fi Protected Access
3.7.2 Situation in Deutschland
Da die Entwicklung des IEEE Standards 802.11i für die Praxis zu lange gedauert hat, wurde
vom Wi-Fi-Konsortium13 Wi-Fi Protected Access (WPA) entwickelt. In Deutschland ist nicht nur der persönliche Lebens- und Geheimbereich gesetzlich geschützt,
WPA implementiert einige Teile von 802.11i (erweiterter IV, Message-Integrity-Check,..) sondern es ist auch die Geheimhaltung von nicht unmittelbar wahrnehmbar (also beispiels-
und auch eine Authentifizierung mittels 802.1x, wie bei 802.11i vorgesehen, ist möglich. Al- weise elektronisch oder magnetisch) gespeicherten Daten geregelt. Ein potentieller Täter
lerdings werden andere 802.11i Features wie z.B. das verbesserte Verschlüsselungsverfahren verschafft sich genau dann auf unbefugten Weg Daten, wenn die Daten gegen einen unbe-
(AES) nicht angeboten. rechtigten Zugriff besonders gesichert sind. Daten sind einerseits gespeicherte Daten. Der
Aber auch wenn WPA eine Verbesserung gegenüber WEP bringt, wurden schon Schwächen Fall tritt ein, wenn über das Funknetz die Daten auf einem Rechner unbefugt ausgelesen
entdeckt. So ist auch ein mit WPA geschütztes WLAN nicht sicher gegen eine Denial-Of- werden. Andererseits werden auch die gerade in Übermittlung befindlichen Daten von dieser
Service-Attacke. Vorschrift behandelt. Dieser Fall tritt beim passiven oder aktiven Mitlesen des Datenver-
kehrs ein.
Die Vorrausetzung der besonderen Sicherung gegen unberechtigten Zugang ist im Bereich
3.7 Gesetzlicher Schutz gegen Attacken auf Funknetze der WLANs problematisch. Es stellt sich die Frage, ob Zugangssperren zum Netzwerk
ausreichend sind, oder ob die Daten auf dem Rechner ebenfalls mit Zugangssperren geschützt
Im Folgenden wird “Sniffen” im Zusammenhang mit den österreichschen bzw. deutschen
werden müssen. Beispiele für Zugangsperren bei WLANs sind:
Gesetzen betrachtet. Es wird auch gezeigt, dass die gesetzlichen Einschränkungen für Hacker
nur gelten, wenn im Vorfeld gewisse Sicherheitsmaßnahmen getroffen wurden. Tatsächlich • Hidden SSID
gibt es besonders bei der Datensicherheit gravierende Gesetzeslücken.
• shared key Systeme
3.7.1 Situation in Österreich • MAC-Adress-Control Systeme
Sniffen ist rechtlich nicht vollständig geklärt. Selbstverständlich muss es erlaubt sein, wenn Einige Stimmen in der Literatur meinen, eine besondere Sicherung muss für einen ver-
man sein eigenes Netz mittels eines Sniffers auf Sicherheitslücken überprüft. “Testet” man sierten EDV-Experten eine Hürde darstellen. Die überwiegende Meinung sagt aber im Ge-
ein fremdes Netz, ist Sniffen vergleichbar mit Hacken. Dabei geht es um datenschutzrecht- gensatz dazu, ein Hindernis für versierte EDV-Anwender und sachkundige Laien sei ausrei-
liche Aspekte (d.h. Eingriff in die Privatsphäre Dritter) und strafrechtliche Aspekte (d.h. chend. Bei Funknetzen gibt es eben derzeit noch keine anspruchsvollen und praxistauglichen
Beschädigung des Datenverkehrs Dritter). Sicherungen. Aber um die vorhandenen Sicherungen zu knacken, muss sich der Laie zumin-
Bei kabelbasierenden Netzwerken ist es noch verhältnismäßig schwer Sniffer in ein anderes dest intensiv mit der Materie beschäftigen. Mit den bereits angesprochenen Zugangssperren
Netzwerk physisch einzuschleusen. Wenn WLAN-Technologie für das betroffene Netzwerk sollte der Netzwerkbetreiber sein Geheimhaltungsinteresse ausreichend dokumentiert haben
verwendet wird, reicht es, mit dem entsprechenden Equipment herumzufahren und sich und somit zumindest strafrechtlich gegen das Ausspähen von Daten auf seinen Rechnern
z.B. dem Zaun des Firmengeländes zu nähern. Das ist im Gegensatz zu den bisherigen geschützt sein.
Möglichkeiten zum Abhören (Wanzen) nicht verboten. Inwieweit der strafrechtliche Schutz auch beim Ausspähen von in Übermittlung befindli-
Ob das sogenannte War-driving zulässig ist, ist nicht eindeutig geklärt. Eine mögliche chen Daten reicht, hängt in erster Linie von den physischen Maßnahmen (z. B. Abschirmung)
Argumentation ist, dass der Betrieb eines Sniffer-Equipments mit der Absicht fremde Daten ab. Eine Abschirmung ist ein besonderer Schutz, daher ist strafrechtlicher Schutz sicher ge-
auszuspähen erfolgt, und dass sowohl der Versuch strafbarer Handlungen als auch Vorberei- geben. Wird weder eine Abschirmung noch Verschlüsselung benützt, bekommt man keine
tungshandlungen strafbar sind. Hacken (und daher erst recht Sniffen) ist im österreichischen Unterstützung vom deutschen Gesetzgeber. Andererseits stellt sich die Frage, inwieweit eine
Datenschutzgesetz 2000 nicht geregelt. Dieses Gesetz regelt ausschließlich personenbezogene auf WEP basierte Verschlüsselung als “besondere Sicherung” gilt. Der Gesetzgeber wollte
11 Remote Authentication Dial-In User Service, Authentifizierungs-Instanz bei EAP
die Daten während der Übertragung unabhängig vom Übertragungsmedium schützen. Die
12 [Link] verschlüsselten Daten werden aber ohne weiteren Schutz übertragen. Bei der Verschlüsse-
13 [Link] lung werden neue Daten erzeugt. Werden die verschlüsselten Daten als ein eigenes Objekt
44 LITERATURVERZEICHNIS LITERATURVERZEICHNIS 45

angesehen, tritt der Fall der ungesicherten Übertragung ein. Verschlüsselung stellt also nur [Hassenstein 2002] G. Hassenstein: Wireless LAN Security; Berner Fachhochschule; PDF
dann eine rechtlich geeignete Schutzmaßnahme dar, wenn der erzeugte “Datensalat” keine
eigene Tatobjektqualität besitzt. [Hoff et al 2002] S. Hoff, H.P. Mohn: Sicherheit in Wireless LAN: Eine endlose Geschichte?;
Das Netzwerk Insider Jahrbuch 2002, pp 105–119
3.7.3 Datenschutzprobleme bei WLAN [IEEE 802.1x] IEEE 802.1x “Port-Based Network Access Control”, 2001.
Derzeit ist es also praktisch nicht möglich, ein angriffsicheres WLAN zu betrieben. Laut [Arge Daten 2002-07-20] Ist in Österreich “Sniffen” erlaubt?; Österreichische Gesell-
verschiedenen Berichten wurden zumindest in der Vergangenheit sehr viele WLANs ohne schaft für Datenschutz; [Link] Stand vom
Verschlüsselung und die üblichen Sicherheitsmaßnahmen betrieben. Beispielsweise wurden 18.11.2003
laut einer Studie von Ernst & Young 2002 in Wien rund 80 % von den 200 getesteten WLANs
ungeschützt betrieben werden. Problematisch ist dieser Zustand beispielsweise bei Banken, [Arge Daten 2002-08-19] Sicherheitstechnische Mindestandards bei Behörden; Österreichi-
Versicherungen, Rechtsanwälten und öffentlichen Unternehmen, die besondere Regelungen sche Gesellschaft für Datenschutz; [Link]
für die Datensicherheit einhalten sollen. Zumindest zum Untersuchungszeitpunkt (also vor Stand vom 18.11.2003
Februar 2002) gab es um die Wiener Stiftskaserne viele ungeschützte WLANs. Diese Kaserne
[Arge Daten 2003] Wie ist Hacken im DSG 2000 geregelt?; Österreichische Gesellschaft für
ist unter anderem Sitz des Heeresdatenverarbeitungsamtes (siehe [FuZo 2002-04-29]).
Datenschutz; [Link] Stand vom 18.11.2003
In der EU-Datenschutzrichtlinie und im DSG 2000 gibt es nur recht vage Formulierungen
zu Verpflichtungen bei Datensicherheitsmaßnahmen und keine genau definierten Mindest- [Hübner 2003] U. Hübner: IEEE 802.11/802.11b; Technische Universität Chemnitz,
standards. Diese Gesetzeslücken werden eben besonders bei Technologien wie Wireless LAN Fakultät für Informatik; [Link]
immer offensichtlicher und führen zu enormen Datenschutzproblemen. Stand vom 18.11.2003
Ein Aspekt der Entwicklung der WLAN-Technologie ist, dass durch den leichten Zugang
zu Sniffer Equipment und KnowHow eine weitere Bedrohung für die Privatsphäre entstanden [Intelligraphics] Introduction to IEEE 802.11; [Link] [Link];
ist. Dieser Bedrohung kann aber nicht ausschließlich mit Gesetzen wirksam gegenübergetre- Stand vom 18.11.2003
ten werden. Zusätzlich sind Aufklärung und Vorsorgemaßnamen notwendig.
[FuZo 2002-04-22] 80 Prozent der Wiener WLANs ungeschützt; ORF Futurezo-
ne; [Link] Stand vom
3.8 Zusammenfassung 18.11.2003
Mit Kabelnetzwerken stoßen Netzwerkadministratoren schnell an ihre Grenzen. Gerade in [FuZo 2002-04-29] Riskanter Pfusch bei Funknetzen; ORF Futurezone;
der heutigen Zeit, muss alles mobil sein. Das verlangen Anwender auch von den Computer- [Link] Stand vom
netzen. Daher sind WLANs unumgänglich. Dennoch muss bedacht werden, dass WLANs 18.11.2003
trotz aller Vorteile auch gravierende Nachteile mit sich bringen.
Die Sicherheitsaspekte von WLANs werden sehr oft vernachlässigt. Vor allem wenn ein [Uni Karlsruhe] IEEE 802.11: Architektur; Universität Karlsruhe, Institut für Telematik;
WLAN nur als Erweiterung eines LANs errichtet wird, werden die notwendigen zusätzlichen Web-Link; Stand vom 18.11.2003
Sicherheitsvorkehrungen nicht angewandt.
[ZDNet 1] TechReport: Wireless Security - So prüfen Sie Ihr WLAN auf Sicher-
Wie dieser Artikel erläutert, bieten aber nicht einmal die vorhandenen Sicherheitsvorkeh-
heitslücken; ZDNet; [Link]
rungen (WEP), wenn sie verwendet werden, ausreichend Schutz vor Hackern. Auf Grund der
7,[Link]; Stand vom 18.11.2003
deutlichen Schwächen des aktuellen Sicherheitsstandards gibt es bereits viele Hacker-Tools
(Sniffer) die das Ausspähen von WLANs ermöglichen. [ZDNet 2] TechReport: Wireless Security - Surf-Schäden; ZDNet;
Als Schlussfolgerung bleibt, dass WLANs mit den aktuellen IEEE Standards nicht ent- [Link] Stand
sprechend geschützt werden können. Ob der neue Standard 802.11i ausreichend sein wird, vom 18.11.2003
wird sich in der Praxis erweisen müssen. Auf jeden Fall ist dieser Standard deutlich kom-
plexer und aufwändiger. Ansonsten bleiben nur proprietäre Lösungen wie VPNs, um die [Uni Oldenburg] ; Universität Oldenburg, Institut für Informatik; Web-Link; Stand vom
Daten wirksam zu schützen. 23.11.2003

Literaturverzeichnis
[Dornseif et al 2002] M. Dornseif, K.H. Schumann, C. Klein: Tatsächliche und rechtliche
Risiken drahtloser Computernetzwerke; Datenschutz und Datensicherheit 2002 Heft
4; PDF

[Fluhrer et al 2001] S. Fluhrer, I. Mantin, A. Shamir: Weaknesses in the key scheduling

algorithm of RC4; Eighth Annual Workshop on Selected Areas in Cryptography,
August 2001.
46 4 PERSONAL AREA NETWORK (PAN) 4.1 Bluetooth 47

4 Personal Area Network (PAN) 4.1.2 Wozu Bluetooth?

Da Bluetooth-Module sehr klein sind, lassen sie sich praktisch überall integrieren - vom PC
Im Zeitalter der Informationstechnologie gewinnen neben den bereits bekannten Technolo-
über Handys bis zur Kleidung. Ein Bluetooth-Chip hat ungefähr die Größe eines Fingerna-
gien wie WAN und LAN auch PAN immer mehr an Bedeuntung. PANs, also Personal Area
gels und das low-power-Design ermöglicht auch kleine Energiequellen.
Networks, sind räumlich sehr eng begrenzte Netzwerke, die wie ihr Name schon sagt, den
Bereich um eine Person abdecken sollen. Damit wird es modernen elektronischen Geräten
ermöglicht miteinander zu kommunizieren. So sind z.B. die Verbindung eines Handies mit
einer Freisprecheinrichtung über Bluetooth oder das kabellose Internet surfen mittels Handy
und PDA über Infrarot weit verbreitete Anwendungsgebiete.
Dieses Kapitel liefert einen Überblick über die Technologien Bluetooth und IrDA und
erläutert ihre Vor- und Nachteile.

Dieter Steininger duttl@[Link], Bluetooth

Gert Marnaus mosquito@[Link], IrDA Data

Abbildung 20: Bluetooth-Modul, Quelle: [Sony-Ericsson]
Stephan Uray Uray@[Link], IrDA Control

So kann diese Technologie überall dort eingesetzt werden, wo elektronische Geräte über
4.1 Bluetooth kurze Distanzen miteinander kommunizieren und den ”lokalen Kabel- und Schnittstellen-
Dschungel” minimieren. Durch das Ersetzen der Kabel im Nahbereich wird ebenfalls die
Einleitung Im Folgenden wird die Technologie Bluetooth betrachtet. Dabei folgen nach
Mobilität erhöht und AD-Hoc - Verbindungen werden vereinfacht bzw. ermöglicht. Die An-
einer kurzen geschichtlichen Einleitung ein Überblick über die Funktionsweise, Protokolle,
wendungsbereiche für Bluetooth sind also mannigfaltig. Das spiegelt sich auch im rasanten
Sicherheitsaspekte und ein Blick in die Zukunft von Bluetooth im Bereich der PANs.
Anstieg der Mitglieder der Bluetooth SIG wieder - Firmen der verschiedensten Branchen
wollen diese Technologie bei ihren Produkten zum Einsatz bringen.
4.1.1 Einführung
4.1.3 Wie funktioniert Bluetooth?
Was ist Bluetooth? Bluetooth ist eine registrierte Handelsmarke, die Funkverbindungen
zwischen verschiedensten Geräten - sei es mobil oder stationär - ermöglicht. Es ist Im Gegensatz zu vielen Wireless-Standards beinhaltet die Bluetooth-Spezifikation Link-
also ein internationaler Standard, über den alle möglichen Geräte drahtlos miteinander Layer- und Application-Layer-Definitionen für Produktentwickler die Daten- Sprach- und
kommunizieren können. Inhaltsspezifische Anwendungen herstellen. Somit ist sichergestellt, dass alle Produkte die
Bluetooth nutzen miteinander kommunizieren können.
Die geschichtliche Entwicklung 1994 gab Ericsson eine Machbarkeitsstudie über low-
Technische Daten zur Funkübertragung: Für die Funkübertragung wird das ISM-Frequenzband
power und low-cost Funkübertragungen zwischen ihren Mobiltelefonen und dem ent-
genutzt. ISM steht für Industrial, Scientific and Medical. Dieses Band liegt bei
sprechenden Zubehör in Auftrag. Im Februar 1998 gründeten fünf Firmen eine Inter-
2,45 GHz und ist weltweit reserviert und lizenzfrei. Somit ist Bluetooth weltweit
essensgemeinschaft. Dieser SIG (Special Interest Group) gehörten anfangs Ericsson,
einsetzbar, ohne z.B. in irgendwelchen Ländern mit dem Militärfunk zu konkurrie-
Nokia, IBM, Toshiba und Intel an. Es waren also je zwei Marktführer aus der Telefonie
ren. Allerdings verursachen Mikrowellen in diesem Bereich Störstrahlung. Um diesem
und der Laptop-Hersteller sowie der Marktführer im Bereich der digitalen Signalver-
Problem Herr zu werden, wird eine als ”Frequency Hopping” bekannte Technologie
arbeitungstechnologie vertreten. Das gemeinsame Ziel war es anstatt der unzähligen
verwendet: Rund um die 2,45 GHz werden 79 Kanäle mit je 1 MHz genutzt. Nach
verschieden Schnittstellen zwischen diversen Geräten ein einziges, drahtloses Interface
jedem verschickten Datenpaket wechselt das Bluetooth Modul zufallsmäßig auf einen
zu kreieren. Dieser Standard wurde nach dem dänischen König Blauzahn (910-985)
anderen Kanal. Die Paketlängen bei Bluetooth- Übertragungen sind relativ klein.
benannt - wohl ein Tribut an die beteiligten skandinavischen Firmen. So wie dieser
Das bedeutet einerseits einen relativ großen Overhead, senkt aber andererseits die
König Blauzahn einst Dänemark und Norwegen vereinte, sollte Bluetooth die Welten
Störanfälligkeit, da kleinere Pakete eher störungsfrei übertragen werden können. Auf-
von Computern und Telekommunikation vereinen. Die große Bedeutung von Bluetooth
grund der Paketlängen und des Frequency-Hoppings wechselt ein Bluetooth-Device
erkannten weltweit Unternehmen aus verschiedenen Bereichen und schlossen sich der
also bis zu 1600 mal pro Sekunde den Kanal. Die Reichweite der Funkwellen beträgt
Interessensgemeinschaft an. So zählt die SIG heute bereits über 3000 Mitglieder die in
je nach Sendeleistung bis zu 10 bzw. 100 Meter, ohne dass ein Sichtkontakt zwischen
verschiedenen Arbeitsgruppen zusammenarbeiten. Der Hauptsitz der Bluetooth SIG
den Geräten nötig ist.
befindet sich seit 2002 in Overland Park, Kansas. Die Spezifikation 1.0 wurde Mitte
1999 veröffentlicht, Ende 2000 folgte die Version 1.1 und seit 5. November 2003 ist Das Pico-Netzwerk: Wenn Geräte über Bluetooth miteinander kommunizieren, bilden
die Spezifikation 1.2 veröffentlicht. Dabei wurde immer auf Abwärts-Kompatibilität sie ein Netzwerk. Diese Art Netzwerk wird als ”Pico-Netzwerk” bezeichnet. In sol-
geachtet. chen Netzen ist stets ein Gerät der Master und regelt als solcher die Kommunikation
48 4 PERSONAL AREA NETWORK (PAN) 4.1 Bluetooth 49

der Devices. Neben dem Master können bis zu sieben Geräte als aktive Slaves und L2CAP Logic Link Control and Adaption Protocol: Dieses Protokoll bietet Dien-
bis zu 255 Geräte als inaktive Slaves im Pico-Netz betrieben werden. Die einzel- ste an, damit höhere Protokolle über Bluetooth kommunizieren können. Dazu
nen Geräte verfügen über eine feste Adresse, vergleichbar mit den MAC-Adressen im gehört die Verbindungsherstellung über ACL mittels L2CAP-Signalen, das Zer-
Ethernet. Wenn ein Master einen weiteren Master in seiner Reichweite findet, kann teilen von größeren Datenpaketen für die Übertragung und das Multiplexen zwi-
er sich als Slave im anderen Netz einbuchen und so eine Brücke zwischen den Pico- schen verschiedenen höheren Protokollen. Da alle höheren Protokolle auf dieses
Netzen darstellen. Ebenso kann sich ein Slave der mehrere Master findet gleichzeitig L2CAP zurückgreifen, kommt diesem Layer eine sehr große Bedeutung zu.
in verschiedenen Netzen einbuchen. Weiters kann jedes Endgerät zu jedem beliebigen RFCOMM: emuliert eine serielle Schnittstelle. Dadurch lassen sich z.B. TCP/IP
Zeitpunkt Netze betreten oder verlassen. Die Zusammenfassung dieser Eigenschaften Verbindungen über PPP aufbauen.
wird als ”Scatternet” bezeichnet.
BNEP Bluetooth Network Encapsulation Protocol: Hier werden verschiedene
Das Protokoll: Allgemein ist zu sagen, dass bei Bluetooth verschiedene bestehende Pro- Protokolle gekapselt, um sie über L2CAP zu übertragen. So werden IPv4, IPv6
tokolle wiederverwendet und neue Protokolle implementiert werden. Dabei bauen alle und IPx und weitere vorhandene Netzwerkprotokolle unterstützt. Das ermöglicht
höheren Protokolle auf die grundlegenden Protokolle auf. Da die Spezifikation offen effiziente IP-basierende Kommunikation im Pico-Netz und die Weiterleitung von
ist, können weitere auf Buetooth basierende Protokolle implementiert werden und so IP-Paketen über Zwischenstationen. Zukünftige Netzwerkprotokolle sollen eben-
künftige Anwendungen Bluetooth einfach nutzen. Weiters benötigt jede Anwendung falls unterstützt werden. Zum BNEP gehören so genannte PAN-Profile (Personal
nicht den vollen Protokoll-Stack sondern nur eine durchgehende horizontale Linie. Area Network). Hier wird festgelegt, welche Rolle ein Gerät im Pico-Netzwerk
Dazu wurden verschiedene Profile wie LAN Access- Headset- und viele weitere Profile spielt. Dabei gibt es:
definiert. • NAP Network Acces Point: Teilnehmer mit direktem Netzwerkzugang der
sieben weiteren PANUs Zugang zum Netz ermöglichen kann.
• PANU PAN User: Teilnehmer ohne Netzzugang der Slave im NAP-Netz oder
Ad-Hoc-Netz ist.
• GN Group Ad-Hoc Network: Master in einem Pico-Netz ohne Netzwerkzu-
gang. Alle weitern Protokolle wie z.B. TCP/IP bauen auf diesen Protokollen
der niederen Schichten auf und werden hier nicht weiter erläutert.
Die Pakete: Bluetooth Pakete sind nach folgendem Schema aufgebaut:

Abbildung 21: Protokollarchitektur, Quelle: [Protokollarchitektur]

Die erwähnten grundlegenden Protokollschichten sind:

Abbildung 22: Standard Paket
Bluetooth Radio: Enthält die Funkspezifikationen (siehe 1.3.1) und die Sendelei-
stungen 1/2,5/100 mW mit Reichweiten von 0,1/10/100 Metern.
Baseband: Das Baseband ist verantwortlich für die Kanal(de)kodierung. Es stellt Der Access-Code hat eine feste Länge von 72 Bit und dient der Authentifikation und
auch Timeslots und Frequenzen bereit und ist somit für die Synchronisation ver- Synchronisation. Er hängt von der Adresse und der Uhr des Masters ab. Zusammen
antwortlich. Hier werden den Daten Adressierungsfelder und Link-Control-Felder mit der Hop-Sequenz definiert der Access-Code den physikalischen Kanal. Der Header
angefügt. Dabei stehen zwei Verbindungsarten zur Verfügung: mit 54Bit enthält Steuerinformationen wie z.B. Empfängeradresse und Sequenznum-
mer. Die Payload hat eine variable Länge zwischen Null und 2746 Bit. Wenn diese
• ACL (Asynchronous Connection Less) für z.B. Surfen; hierbei können so-
Payload einen Dateninhalt hat (im Gegensatz zu Sprachinhalt), so steht am Anfang
wohl symmetrische (432,6 kBit/s) als auch asymmetrische Kommunikation
der Payload ein weiterer Header, der zur Unterscheidung zwischen Link Manager-
(721/57,6 kBit/s) betrieben werden. und
Nachrichten und L2CAP-Paketen dient.
• SCO (Synchronous Connection Oriented) wie es für Sprachübertragungen
verwendet wird mit drei Kanälen zu je 64 kBit/s.
4.1.4 Sicherheitsaspekte
LMP Link Manager Protokoll: Dieses Protokoll ist für den Verbindungsaufbau
zwischen den Bluetooth-Geräten und Sicherheitsfunktionen wie z.B. Authentifi- Die Bluetooth-Spezifikation sieht Authentisierungs- und Verschlüsselungsmechanismen vor
zierung verantwortlich. die auf dem Chip implementiert sind und auf der Link-Ebene zur Verfügung stehen. Wollen
50 4 PERSONAL AREA NETWORK (PAN) 4.2 Infrared Data Association (IrDA) 51

zwei Geräte die Verschlüsselung für ihre Kommunikation nutzen, so müssen sie zuerst gepaart Dieses Unterkapitel behandelt die IrDA Technologie. Dabei handelt es sich um einen
werden. Bei dieser Paarung gibt es drei verschiedene Möglichkeiten: Standard zur Kommunikation mittels Infrarot. Es wird dabei auf die beiden wichtigsten
• Die Paarung geschieht für eine Session. Dabei muss unter anderem an beiden Geräten Protokolle, IrDA Data und IrDA Control, näher eingegangen.
ein bis zu 16 Byte langer PIN vorliegen. Dieser kann entweder eingegeben oder fix
eingestellt werden. Der PIN muss aber an beiden Geräten übereinstimmen. D.h., 4.2.1 Einführung
dass zwei Geräte mit fixem aber unterschiedlichen PIN ihre Kommunikation nicht Geschichte: Die IrDA wurde 1993 in Walnut Creek, Kalifornien gegründet. Ihre Aufgabe
verschlüsseln können. besteht darin einen Infrarot Standard zu definieren, der drahtlose Verbindung zwischen
• Eine weiter Möglichkeit zur Paarung ist, dass Geräteschlüssel als Verbindungsschlüssel einer großen Auswahl von unterschiedlichsten Geräten unterschiedlicher Plattformen
verwendet werden. Dieser wird bei der erstmaligen Verwendung des Bluetooth-Gerätes ermöglichen. Sie arbeitet als ”Non Profit” Vereinigung. Zu ihren Mitgliedern zählen
erzeugt und ändert sich im Allgemeinen nicht. zahlreiche Unternehmen aus den Bereichen Hardware, Software, Telefon, Automobil...

• Master-Schlüssel können vereinbart werden, wenn ein Master mehrere Geräten mit Wozu IrDA: Die Hauptanwendungsgebiete von IrDA liegen im Kruzstreckenbereich bei
demselben Schlüssel erreichen will. Sie gelten wiederum nur für die jeweilige Sitzung. einer Distanz von einigen Metern. Verwendung findet diese Technologie hauptsächlich
bei der Punkt zu Punkt Verbindung von Host-PCs, Digitalkameras, Handheld Da-
Zur Authentisierung wird eine einfache Authentisierung verwendet. Das bedeutet, dass
tensammlungsgeräten etc. Weiters wird IrDA auch für multipoint-Anwendungen wie
sich nur ein Gerät beim Anderen authentisiert und nicht zwingenderweise auch umgekehrt.
Keyboard und Mouse (1-Weg), Joysicks (2-Weg + geringe Latenzzeit) eingesetzt. Für
Wenn sich zumindest ein Gerät beim Anderen authentisiert hat, kann eine Verschlüsselung
multipoint-Anwendungen muss beim Design auf Timesharing oder Räumliche Tren-
verwendet werden. Dabei wird die Verschlüsselung nach dem Aushandeln der Parameter
nung geachtet werden um Interferenzen zu vermeiden. Es gibt zwei große IrDA Pro-
vom Master gestartet. Dazu einigen sich die Geräte auf eine Schlüssellänge zwischen 8
tokollgruppen:
und 128 Bit. Für die Verschlüsselung stehen ebenfalls die Punkt-zu-Punkt oder Punkt-zu-
Mehrpunkt-Betriebsarten zur Verfügung. • IrDA Data
Bluetooth bringt also gute Voraussetzungen für abhörsichere Verbindungen mit. Al-
• IrDA Control
lerdings ist die Verschlüsselung immer optional, muss also vom Benutzer explizit verlangt
werden! Wenn ein Gerät wie z.B. ein Headset keine Möglichkeit zur Einstellung eines PINs
bietet, sind oft schwache Schlüssel (”0000”) vom Erzeuger voreingestellt. Wenn bei der 4.2.2 IrDA Data
Paarung ein schwacher PIN verwendet wird, so kann dieser eventuell erraten werden und IrDA Data definiert seit 1994 einen Standard für eine kabellose und universelle Zweiweg
damit der Verbindungsschlüssel errechnet werden. Der PIN ist der einzige geheime Para- Infrarotübertragung. Bis jetzt wurde IrDA in über 300 Millionen Elektronikgeräten einge-
meter bei der Erzeugung des Verbindungsschlüssels und sollte möglichst schwer zu erraten baut. Beispiele hierfür sind: Notebooks, PalmPCs, Drucker, digitale Kameras, Telephone,
sein. Das steht aber im Widerspruch zu den Nutzergewohnheiten. Viele Nutzer verwenden PDAs, eBooks, Uhren und viele mehr. Das IrDA Protokoll besteht aus einer Vielzahl von
aus ”merktechnischen Gründen” denselben einfachen PIN für viele Geräte. Es gibt eine Rei- zwingenden und einigen optionalen Protokollen.
he von weiteren Kritikpunkten an den Verschlüsselungs- und Authentisierungsmechanismen Obligatorische Protokolle:
bei Bluetooth. Dabei stellt sich jedoch die Frage wie sicher Bluetooth eigentlich sein soll.
Ein Kompromiss zwischen User-Freundlichkeit und Sicherheit muss also gefunden werden. • PHY (Physical Signaling Layer)
Angesichts der begrenzten Reichweite und der oftmals nicht so sicherheitskritischen An- • IrLAP (Link Access Protocol)
wendungen reichen die implementierten Mechanismen für den Durchschnitts-User sicherlich
aus. • IrLMP (Link Management Protocol und Information Access Service (IAS))
Physikalische Eigenschaften von IrDA:
4.1.5 Die Zukunft von Bluetooth
Die nahe Zukunft von Bluetooth liegt sicherlich im Heimbereich beim entwirren des Kabel- • Reichweite: Im Abstand von 1 Meter muss eine Kommunikation fehlerfrei möglich sein
salates. Auch in Autos wird bereits Bluetooth-Technologie für Freisprechanlagen genutzt. (Entfernungen von 2 Meter sollten jedoch kein Problem darstellen). Es gibt auch eine
Haushaltsgeräte und Haussteuerungsanlagen können in Zukunft ebenfalls diese Technologie Lowpower Version die einen Mindestabstand von 20 cm unterstützt. Diese Implemen-
nutzen sowie Dienstleistungen an öffentlichen Plätzen angeboten werden. Da die Sendelei- tation verbraucht nur ein zehntel der Energie.
stung sehr gering ist (1 bis 100 mW im Vergleich zu GSM mit 800 bis 2000 mW) sind auch • Bei allen Spezifikationen ist eine Bidirektionale Kommunikation definiert.
gesundheitliche Schäden nahezu ausgeschlossen. Dies trägt zusammen mit der Gebührenfrei-
heit sicher auch zu einer großen Akzeptanz in allen Bevölkerungsschichten bei. Bluetooth ist • Die Transferrate reicht von 9600 b/s bis 16 Mb/s.
also eine kostengünstige, gebührenfreie und zukunftsorientierte Technologie auf einem klei-
• Die Datenpakete werden mittels CRC Prüfung gesichert. (CRC-16 für Geschwindig-
nen Modul, das Mobilität und Interkonnektivität erhöht und dabei bislang keine relevanten
keiten bis 1.152 Mb/s und CRC-32 für Geschwindigkeiten bis 16 Mb/s)
Nachteile aufweist. Daher ist ein Ende des Bluetooth-Booms nicht abzusehen.
Eigenschaften von IrDA Link Access Protocol (IrLAP)
4.2 Infrared Data Association (IrDA)
• Unterstützt eine Geräte zu Geräte Kommunikation für einen zuverlässigen und geord-
Einleitung neten Datentransfer
52 4 PERSONAL AREA NETWORK (PAN) 4.2 Infrared Data Association (IrDA) 53

• Unterstützt Geräteidentifizierungsroutinen.
Eigenschaften von IrDA Link Management Protokoll (IrLMP)
• Unterstützt multiplexing der IrLAP Schicht. Die ermöglicht mehrere Kanäle der über-
geordneten IrLAP Verbindung.
• Unterstützt die Protokoll- und Service Findung über das Information Access Service
(IAS).
Optionale IrDA Protokolle:
Abbildung 24: Blockschaltbild, Quelle: [Specifications]
• Tiny TP: Unterstützt die Flusskontrolle von IrLMP Verbindungen mit einem optiona-
lem Segmentation- und Reassembly Service.
• IrCOMM: Unterstützt COM (seriell und parallel) Port Emulation für COM Anwen- Inverted Modulation). Bis zu einer Geschwindigkeit von 4Mbit/s wird eine 4PPM
dungen, Drucker und Modems. (Puls Positions Modulation) Modulation verwendet, wobei eine ”1” ein Puls und eine
• OBEX: Unterstützt Objekt-austausch-services,...ähnlich zu HTTP ”0” ein Chip (Chip = Eine Zeitscheibe in einer PPM). Für Geschwindigkeiten bis
16Mbit/s findet eine HHH14 (1,13)Modulation Verwendung. Die HHH Modulation
• IrDA Lite: Unterstützt Methoden, welche den IrDA Code reduzieren mit gleichzeitiger besteht aus mindestens einem leeren bis maximal 13 leeren Chips zwischen Chips die
Kompatibilität zur vollständigen Impementation. Pulse beinhalten. Im Punkt (b) sind die elektrischen Analogien zu den optischen
Signalen an Punkt (c).
• IrTran-P: Unterstützt ein Bild-austausch Protokoll, welches z.b. in Digitalkameras
Verwendung findet. Für Transferraten bis inclusive 115.2 Kbit/s wird das Signal in Frames organisiert.
Jedes Byte wird asynchron mit einem Startbit, 8 Datenbits und einem Stopbit übert-
• IrMC: Ist eine Spezifikation die die Kommunikation zwischen mobilen Telekommuni- ragen. Für höhere Transferraten werden die Daten in synchronen Frames, bestehend
kationsgeräten beschreibt. aus mehreren Datenbytes übertragen.
• IrLAN: Beschreibt ein Protokoll, welches den Drahtlosen IR Zugang zu LANs ermöglicht. In der Tabelle sind die Transferraten, die Art der Modulation und die Signalbreiten
ersichtlich.
IrDA DATA - Hardware/Protocol Stacks:Abbildung 23

Abbildung 23: IrDA Protokollstack, Quelle: [Standards]

Abbildung 25: Transferraten, Quelle: [Specifications]

4.2.3 Überblick über die Spezifikationen der einzelnen Protokolle:
Eine genaue Beschreibung findet man auf: [Standards]
IrLAP (Link Access Protocol): IrLAP benützt einen Layer in einem hierachischen Stack
PHY (Physical layer): Diese Spezifikation definiert nur die seriell dekodierten optischen von Kommunikations-Protokoll-Schichten. Es verwendet die Services, welche vom Phy-
Ausgangs- und Eingangssignale (c) siehe: Abbildung 24 sical Layer zur Verfügung gestellt werden und versorgt die darüberliegenden Schichten
Im Diagramm ersichtlich sind die elektrischen Signale des Encoder/Dekoders (a) an der mit den entsprechenden Services.
linken Seite serielle Bitstreams. Die optischen Signale am Punkt (c) sind Bitstreams. IrLAP stellt zwei generelle Typen von Services zur Verfügung:
Für Transferraten bis 1.152Mbit/s wird ein Bitstream verwendet, wobei eine ”0” ein
Puls und eine ”1” eine Bitperiode ohne Puls ist (RZI Modulation - Return to Zero 14 HHH steht für Martin Hassner, Nyles Heise und Walter Hirt
54 4 PERSONAL AREA NETWORK (PAN) 4.2 Infrared Data Association (IrDA) 55

1. Verbindungslose Services 1. Connect Services (request, indication, response, confirm)

2. Verbindungsorientierte Services Dieser Service wird benötigt um eine IrLAP Verbindung zu einer Station mit der
gewünschten Zieladresse herzustellen.
IrLAP Service Definitions: 2. Sniffing Services (request)
IrLAP stellt vier generische Typen von Services zur Vervügung: Dieser request wird verwendet um eine spezielle lowpower Verbindung (sniffing)
herzustellen oder zu verwerfen.
1. Request: Kommt von der oberen Schicht um einen Service aufzurufen.
3. Data Services (request, indication)
2. Indication: Wird von IrLAP zur oberen Schicht gesendet um anzuzeigen, dass Die Daten können entweder zuverlässig und aufeinanferfolgend oder unzuverlässig
ein Ereignis stattgefunden hat oder die obere Schicht über eine Initialisierung zu in beliebiger Reihenfolge gesendet werden.
informieren. Wenn die Daten nicht zuverlässig gesendet werden bekommt der Sender kein
3. Response: Kommt von der oberen Schicht um ein Antwort von einer Prozedur ACK!
welche durch Indication ausgelöst wurde zu erhalten. 4. Status Services (request, indication, confirm)
4. Confirm: Wird von IrLAP zur oberen Schicht gesendet um die Ergebnisse der Dieses Service wird verwendet um der übergeordneten Schicht die Qualität der
vorangegangenen Serviceanfrage zu übermitteln. Verbindung mitzuteilen.
Wenn die Verbindung zu schlecht ist kann das einen spontanen Disconnect zur
IrLAB verwendet diese Grundfunktionen um mit der übergeordneten Schicht in einer
Folge haben.
geordneten Weise zu kommunizieren.
5. Reset Services (request, indication, response, confirm)
Die vier Grundfunktionen sind hier Graphisch dargestellt:
Ein Reset löscht alle Daten, die nicht mit ACK bestätigt wurden.
Alle Timer und Zähler werden zurückgesetzt.
Ein Reset kann nur dann ausgelöst werden, wenn beide Geräte dem zustimmen.
Wenn eines der beiden Geräte dem nicht zustimmt, wird kein Reset durchgeführt.
6. Disconnection Services (request, indication)
Ein Disconnect Aufruf trennt die logische Verbindung und alle noch anstehenden
Daten werden verworfen.

Abbildung 26: Grundfunktionen, Quelle: [Specifications]

ad 1 - Verbindungslose Services:
Es wurden folgende Services definiert:
Abbildung 27: Verbindngsorientierte Services, Quelle: [Specifications]
1. Discovery Services (request, indication, confirm)
Dienen zur Suche nach Geräten, die sich in Reichweite der Basisstation befinden.
IrLMP (Link Management Protocol und Information Access Service (IAS)) Das
2. Address Conflict Services (request, confirm)
Link Management Protokoll ist Bestandteil des IrDA Standards für IrDA Geräte und
Dienen zur Lösung von Adresskonflikten zwischen verschiedenen Geräten. unterstützt walk-up und ad-hoc Verbindungen zwischen zwei Geräten. Die Software
3. Unit Data Services (request, indication) vom einen Gerät kann die Services, welche das andere Gerät unterstützt selbständig
Bieten eine Möglichkeit um Daten außerhalb einer Verbindung zu transferieren. herausfinden. Das Protokoll unterstützt eine Vielzahl von Softwareanwendungen, die
Dieser Datentransfer ist jedoch unzuverlässig. unabhängig voneinander und gleichzeitig über die selbe IR Schnittstelle mit anderen
Geräten kommunizieren. Dies beinhaltet verschiedene Aufgaben wie Ausfindig machen
Die Daten können nicht gerichtet auf ein spezifisches Gerät gesendet werden.
von anderen Geräten, Schnittstellenmultiplexing und Kontrolle der Schnittstelle.
Entspricht also einem ”Broadcast”.
Die generelle IrDA Protokoll Architektur: Das Link Management definiert zwei Kom-
ad 2 - Verbindungsorientierte Services: ponenten innerhalb dieser Architektur:
56 4 PERSONAL AREA NETWORK (PAN) 4.2 Infrared Data Association (IrDA) 57

1. Link Management Information Access Service (LM-IAS)

2. Link Management Multiplexer (LM-MUX)

Abbildung 29: Übersicht der IrDA Control Layer, Quelle: [Specifications]

Überblick über die verschiedenen Layer: Der Physikalische Layer (IrBus PHY) defi-
niert die physikalischen Eigenschaften der Übertragung. In ihm wird z.B. die Art der
Modulation definiert. Der MAC Layer definiert das Medien-Zugriffs-Schema der IR
Abbildung 28: Generelle Protokoll Architektur, Quelle: [Specifications] Kommunikation. Der LLC dient der Übertragungssicherheit. Er stellt z.B. sicher,
dass die Daten in der richtigen Reihenfole ankommen oder sorgt für eine Neusendung
bei Datenverlust. Es gibt grundsätzlich 4 Möglichkeiten eines Application Layer Pro-
Information Access Service: Jede LM-IAS Existenz stellt eine Informationsbasis tokolls. Die Unterscheidung kann anhand des LLC frames getroffen werden. In ihm
bereit um einem anderen Gerät die Möglichkeit zu bieten Informationen über die stehen 2 Bits der HostID zur Codierung bereit. Bis jetzt gibt es allerdings nur 2 rea-
zur Verfügung stehenden Services zu geben. Natürlich ist es dann dem Gerät lisierte Application Layer. Das HA Protokoll für Heim Anwendungen und das USB
auch möglich die gleichen Informationen von einem anderen Gerät zu erhalten. HID Protokoll für Comuter Eingabegeräte.
LM-IAS definiert Operationen, welche für den Zugriff auf Information wichtig Überblick des IrDA Physical Layer:
sind.
• Der Entfernungsbereich entspricht dem herkömmlicher uni-direktionalen Infra-
Link Management Multiplexer: Der LM-MUX stellt dem lokalen LM-IAS und
rotfernsteuerungen (mindestens 5m)
dem Transport von Existenzen oder Anwendungen (die an den LM-MUX gebun-
den sind) Services zur Verfügung. IrLAP stellt hierfür eine zuverlässige Verbin- • Bidriektionalität ist die Basis aller Spezifikationen
dung zwischen zwei IrDA Geräten zur Verfügung. Der LM-MUX unterstützt • Maximal 75 kb/s Übertragungsrate.
multiple Data-link Verbindungen über IrLAP • Die Daten werden in einer 16-Puls Sequenz multipliziert mit einem 1.5 MHz
Subcarrier übertragen. Die Spezifikation befindet sich in [IEC 1603-1]. Durch die
4.2.4 IrDA Control harmonischen Frequenzen die dabei entstehen, kann die Kommunikation in andere
IEC Bänder eindringen. Durch das 16 PSM Schema werden die Interferenzen im
IrDA Control ist ein Infrarot Kommunikations Standard, welcher es erlaubt verschiedenste
33-40 kHz Band minimiert.
Peripheriegeräte wie Keyboards, Mäuse, Gamepads, Joysticks und Zeigegeräte mit vielen
Typen von intelligenten Hostgeräten zu verbinden. Unter Hostgeräten versteht man PCs, • Die Datenpakete werden durch eine CRC Summe überprüft (CRC-8 für kleine
Spielekonsolen und TV-Web Endgeräten, etc. IrDA ist perfekt geeignet um mit Geräten zu- Pakete, CRC-16 für große).
sammenzuarbeiten, welche die USB HID15 class unterstützen. Es unterstützt natürlich auch • Der physikalische Layer ist für geringen Stromverbrauch optimiert und kann mit
herkömmliche Fernsteuerungen mit komplexen Implementationsrichtlinien für bidirektionale günstiger Hardware realisiert werden.
Fernsteuerungen mit MAC Enumeration und LLC Transaktionen.
Überblick des IrDA Media Access Control Layer (MAC):
Das IrDA Control Protokoll besteht aus einem Set von wichtigen Protokollen (siehe
Abbildung 29): • Erlaubt ein Hostgerät mit mehreren pheripherie Geräten zu kommunizieren (Max
8)
• PHY (Physical layer)
• Erlaubt schnelle Reaktionszeiten (13.8 ms Grund-polling rate) und geringe Verzöge-
• MAC (Media Access Control) rung

• LLC (Logical Link Control) Überblick des asymmetrischen MAC:

• Unterstützung für die dynamische Zuordnung von Pheripherieadressen. (Wieder-
15 HID = Human Interface Device verwendung bereits vorher vergebener Adressen).
58 4 PERSONAL AREA NETWORK (PAN) 4.2 Infrared Data Association (IrDA) 59

• Scheduling des Medienzugriffs befindet sich im HID LLC.

Überblick des IrDA Logical Link Control Bridge Layer (LLC):

• Beinhaltet die Fehlerkontrolle (Überprüfung des Ankommens der Daten).

• Arbeitet mit einer HID-IrDA Controlbridge um die Link Control Funktionen des
USB-HID zu ermöglichen.

1. IrDA Physikal Layer

Das IrDA Control System benutzt das 16 Pulse Sequence Modulation Schema
für die Datenkodierung. Dabei wird die sogenannte ”Symbol Time” in 8 gleiche
Teile, die sogenannten ”Chips” unterteilt. Ein Puls darf entweder während 2
oder 4 dieser Chip-Perioden wärend einer Symbol Time aktiv sein. Gültige Puls- Abbildung 31: Physikalischer Frame, Quelle: [Specifications]
Sequenzen werden ”16 PSM Data Symbols” genannt. Es werden immer jeweils
4 Bits innerhalb einer Symbol Time übertragen. Alle möglichen Kombinationen
aus Pulssequenzen und die daraus resuldierenden Bit Muster können der Tabelle • PRE: Preamble
entnommen werden. Nachdem die Übertragung mit max 75kb/s stattfindet Pulse Sequenz:0101010101
Zur Clock Synchronisation
• STA: Start Flag
Pulse Sequenz für kurzes Paket:0110110100
Pulse Sequenz für langes Paket:0100101101
Unterscheidung zwischen langem und kurzem Paket
• MAC: Media Access Control
• STO: Stop Flag
Pulse Sequenz:01001011
Die Übertragungsreihenfolge ist von Links nach Rechts. Nachdem die Grösse der
Pakete nicht variiert (nur kurz oder lang) ist die Übertragungszeit im vorhinein
bekannt. Deshalb ist dieses Modulationsschema bei zeitkritischen Anwendungen
günstig.
2. IrDA Media Access Control Layer (MAC)
Ein IrDA Control System besteht aus Hosts und einen oder mehreren Peripherie-
Geräten zwischen denen die Infrarot Kommunikation stattfindet. Beim IrDA
Control System managen die Hosts die Kommunikation. Die Kommunikation
zwischen einem Host und mehreren Peripheriegeräten wird durch ein ”Time Sha-
ring” ermöglicht. Die Kommunikation passiert nur zwischen Host und Periphe-
riegeräten und normalerweise nur dann, wenn diese vom Host die Erlaubnis be-
kommen.
Zwischen den Hosts gibt es keine Kommunikation, aber ein Host kann die Kom-
munikation eines anderen Hosts mitlauschen und als Peripheriegerät arbeiten,
sollte er mit einem anderen Host kommunizieren müssen. Natürlich können meh-
Abbildung 30: Bitmuster der physikalischen Übertragung, Quelle: [Specifications] rere Hosts (die einander ”sehen”) nicht gleichzeitig kommunizieren. Deshalb muss
auch hier ein Time Sharing Algorithmus verwendet werden. Das Time Sharing
zwischen einem Host und seinen Peripheriegerät wird mittels eines sogenannten
ergibt sich für die Symboltime 53.33µs
Polling Verfahren realisiert. Der Host gibt, nach einer fix vorgegebenen Reihen-
PHY Paket Struktur: Folgendes Bild veranschaulicht das IrDA Control Packet folge, die Sendeerlaubnis. Danach empfängt er die Daten und reicht dann die
Format (siehe: Abbildung 31). Erlaubnis zum nächsten Gerät.
• AGC: Automatic Gain Control Gibt es eine Zeit lang kein Gerät, das Daten senden möchte, geht der Host in den
Pulse Sequenz:1111 Sleeping Mode. Dieser Sleeping Mode ist ein Ressourcen sparender Zustand des
Hilft bei der Ermittlung der Signalstärke beim Empfänger Hosts. In diesem Sleep Zustand unterbricht der Host z.B. sein Polling Verfahren
60 4 PERSONAL AREA NETWORK (PAN) 4.2 Infrared Data Association (IrDA) 61

und stopt die Kommunikation. Möchte nun ein Pheripheriegerät senden, sieht es
den Sleeping Host und kann ihn mittels eines ”wake” Frames aufwecken.
Mittels einer Address und eines Identifiers identifizieren sich die Hosts und Pheri-
pheriegeräte. Ein Host identifiziert sich mittels einer 8 Bit Adresse, die entweder
vom Hersteller vorgegeben wird oder bei der Installation gewählt wird und ei-
nes 16 Bit Identifiers. Die Peripheriegeräte identifizieren sich anhand einer 32 Bit
”Physical ID”. Um die Identifikation der einzelnen Hosts bzw. Periperiegeräten zu
erleichtern, wird ein sogenannter Bind Prozess durchgeführt. Dabei wird für jedes
Peripheriegerät eine eindeutige, 4Bit logische Adresse vom Host berechnet. Diese
Berechnung der logischen 4Bit Adresse heißt ”Enumeration”. Die 32 Bit physical
ID und die Host ID werden also nur zu Beginn einer Kommunikation benötigt,
um die Geräte zu identifizieren. Danach werden Peripheriegeräte mittels ihrer
logischen 4Bit Adresse und die Hosts mittels ihrer 8Bit Adresse angesprochen.
Nachdem der Standard relativ offen für zahlreiche Anwendungsmöglichkeiten ge-
halten worden ist, gibt es 3 unterschiedliche Host Modi.
• Mode 0 - Sleep Mode:
In diesem benötigt der Host wenig Ressourcen und Strom. Der Sleep Mode
ist der Default Mode jedes Hosts. Er wird dann eingestellt wenn weder der
Host noch die Pheripheriegeräte kommunizieren müssen. Abbildung 32: MAC Frame, Quelle: [Specifications]
• Mode-1 - Normal Mode:
Der Normal Mode ist der ”normale” Arbeitsmodus eines Hosts. In diesem
Modus werden verschiedenste Geräte unterstützt die unterschiedlichste An- In diesem Feld stehen Bits die zur Kommunikation benötigt werden. Die
forderungen an die Reaktionszeit stellen. Es gibt prinzipiell Zeitkritische Belegung der Bits ist davon abhängig, ob der Host mit der Peripherie oder
(Maus, Joystick) und nicht zeitkritische Geräte (Fernsteuerung). Bei einem umgekehrt kommuniziert. Dieses Feld beinhaltet Flags wie: Long Frame,
zeitkritischem Gerät wird ein Pollingintervall von 13.8ms vom Host garan- Binding Start, Polling Request...
tiert. Neben dem normalen MAC Layer gibt es noch den asymmetrischen MAC
Überblick des asymmetrischen MAC:
• Mode-2 - IrDA-coexistence Mode:
In diesem Modus ist es möglich das IrDA SIR 1.1 Data Communication und • Unterstützung für die dynamische Zuordnung von Peripherie Adressen.
das IrDA Control communication Protokoll gleichzeitig zu benutzen. Mode (Wiederverwendung bereits vorher vergebener Adressen)
2 muss nicht von jedem Host unterstützt werden! • Scheduling des Medienzugriffs befindet sich im HID LLC

Aufbau des MAC Frames: Wie bereits vom physikalischen Layer bekannt, 3. IrDA Logical Link Control Bridge Layer (LLC)
gibt es einen kurzen und einen langen Frame. Hosts und Peripheriegeräte Der LLC beinhaltet Ressourcen für eine zuverlässige Kommunikation zu und vom
können immer nur kurze Frames benutzen. Hosts dürfen aber im Mode- MAC Layer. Der LLC verwendet dazu einige Lightweight Protocol Controlling
1 auch lange Frames verwenden. Peripheriegeräte dürfen nur dann lange Frames. Der LLC stellt lediglich einfache Methoden zur Überprüfung des An-
Frames verwenden, wenn ihnen dies der Host mittels eines Bits im Polling kommens der Daten zur Verfügung. Sollte eine höhere Übertragungssicherheit
Frame erlaubt (Mode 1). Während der selben Polling Procedure ist es nicht gefordert sein, muss diese in einem höheren Level von der Applikation gesichert
möglich, dass sowohl Host als auch Pheriperie lange Frames verwenden. Der werden. In manchen Fällen wie bei USB-HID fungiert der LLC als Bridge zwi-
Host muss bei der Erlaubnis für lange Frames aber darauf achten, dass die schen dem MAC Layer und dem Host Betriebssystem.
Pollingzeit nicht zu groß wird, da sonst die Latenzzeit von 13.8ms nicht mehr Die Funktionen des LLC sind:
gewährleistet werden kann. • Senden von Kommandos
Host Address Field: • Empfangen von Anfragen
Besteht aus der 8Bit Host Adresse. HAAD 0x0 wird für Broadcast Wake up • Senden von Daten
für den Enumeration Prozess verwendet. Dabei startet jeder Host, der noch • Empfangen von Daten
keinen Eintrag für das sendende Gerät hat, seine Enumeration Procedur
und folgende Fehlerkontroll- Funktionen:
Peripheral Address Field:
Besteht aus der 32 Bit Physical ID. Nach dem Binding Prozess besitzt jedes • Vermeidung von doppelten Frames mittels Data Sequence Number
Gerät eine 4 Bit Logische Addresse. Diese ist nicht fix sondern kann sich • Bestätigung des Empfangs
während jedes Binding Prozesses ändern. 0x0 und 0xF sind für den Bind • Erneutes Versenden eines ”verlorenen” Frames
und Enumeration Prozess reserviert. • Meldung von nicht vorhandenen Features bzw. momentane Undurchführbar-
MAC Control Field: keit eines Requests.
62 4 PERSONAL AREA NETWORK (PAN) 4.3 Bluetooth vs. IrDA 63

LLC Frame Struktur: 4.3 Bluetooth vs. IrDA

Prinzipiell lassen sich die meisten Anwendungen sowohl über IrDA als auch Bluetooth rea-
lisieren. So ist z.B. das bei PDAs und Handys weit verbreitete Standardprotokoll OBEX
sowohl bei Bluetooth als auch IrDA realisiert. Welche Technologie ihren Einsatz findet hängt
vorallem vom Einsatzgebiet ab. So muss bei IrDA immer eine Sichtverbindung vorhanden
sein, die z.B. bei einer mobilen Freisprecheinrichtung nicht garantiert werden kann. Dafür
sind bei IrDA die Hardwarekosten gering.

Abbildung 33: LLC Frame Struktur, Quelle: [Specifications]

Abbildung 35: techn. Vergleich - Bluetooth vs. IrDA

Abbildung 34: LLC Control Feld, Quelle: [Specifications] Literaturverzeichnis

[Sony-Ericsson] Sony-Ericsson Homepage: [Link]
• Paket Code Field: Handshake und Kontroll Zustände. (Ack, NAck...)
• End Point Field: Ein IrDA Control Device kann 4 verschiedene Endpoints [Protokollarchitektur] Protokollarchitektur: [Link]
besitzen. Ein Endpoint ist eine Adresse einer Pipe. Eine Pipe ist ein logischer
[Bluetooth-SIG] Bluetooth-SIG Homepage: [Link]
Kommunikationskanal. Es gibt 3 unterschiedliche Pipes im IrDA Conrol
Protokoll. [Bundesministerium für Sicherheit in der Informationstechnologie] Bundesministerium für
Die vier Endpoints sind: Sicherheit in der Informationstechnologie Homepage: [Link]
• Endpoint 0x0 Control Pipe. Wird für alle Geräte benötigt [Standards] Standards: [Link]
• Endpoint 0x1 eine optionale IN-Pipe
[Specifications] Specifications: [Link]
• Endpoint 0x2 eine optionale OUT-Pipe
• Endpoint 0x3 eine optionale IN/OUT-Pipe [IEC 1603-1] IEC 1603-1: [Link]
Die drei Pipes sind:
• Control Pipe: Host Kommandos und Peripherieanfragen werden über diese
Pipe gesendet.
• IN Pipe:Daten von Peripherie zum Host
• OUT Pipe:Daten vom Host zur Peripherie
64 5 NETWORK FILE SYSTEM (NFS)/CLUSTERNFS 5.3 Remote Procedure Call (RPC) 65

5 Network File System (NFS)/ClusterNFS 5.3 Remote Procedure Call (RPC)

Der Remote Procedure Call 16 ([RFC 1050]) ist ein Netzwerkdienst für den Austausch von
Das Network-File-System-Protokoll erlaubt einen transparenten Zugriff auf Dateien im Netz- Nachrichten. Er bietet eine Schnittstelle für den Aufruf von Remote Services an. Das Funk-
werk. NFS bietet somit eine effiziente Möglichkeit, auf gemeinsame Datenbestände zuzu- tionsprinzip des RPC ist dem lokaler Prozeduraufrufe ähnlich, mit dem Unterschied, dass
greifen. Die Tatsache, dass NFS auf alle UNIX-Systeme und andere Betriebssysteme wie das aufrufende Modul im Client-Programm und die aufgerufene Prozedur im Server läuft.
z.B. MS-DOS, Windows NT, VMS, MVS, etc. implementiert wurde, unterstreicht die Pra- Das RPC-Protokoll dient als Transportmittel für Aufträge zum Server, wo sie in Prozedu-
xistauglichkeit dieses Netzwerkdienstes. ren münden. Vom Programmierer kann zwischen Client und Server eine beliebige Anzahl
ClusterNFS besizt die gleiche Funktionalität wie NFS und bietet zusätzlich die Möglich- von Prozeduren mit Parametern und Resultaten definiert werden. Eine funktionell zusam-
keit, sogenannte Tagged Filenames“ zu verwenden. Das sind Dateinamen, an denen ein mengehörende Gruppe von Prozeduren wird als Service oder Progamm genannt. Jedem
”
Schlüssel angehängt wird, welcher die Zugehörigkeit der Datei zu einem bestimmten Cli- Service ist eine eindeutige sogenannte Programmnummer zugeordnet, die dieses Programm
ent festlegt. Ein Tagged Filename“ ist nur für den entsprechenden Client sichtbar, für kennzeichnet. Ein RPC-Aufruf ist festgelegt durch:
”
die anderen ist er unsichtbar. Dadurch kann man mehrere Diskless Clients mit dem selben
root-directory betreiben. • eine Transaktions-ID
• eine Progammnummer zum Auffinden des Servers, der das Programm implementiert
• eine Versionsnummer zur Überprüfung von Programmversionen im Falle einer Evolu-
Lai Van Tien: lai@[Link], Abstract, Einführung, Geschichte, RPC, Ver- tion der Schnittstellendefinition
gleich NFS-Versionen. • eine Prozedurnummer zur Identifikation der Zielprozedur im Server

Karl Flicker: [Link]@[Link], Authentifizierung, ClusterNFS, Zusammenfassung Mit diesen Angaben kann die RPC-Ablaufumgebung, die im Server eingebunden ist,
in die richtige Unterprozedur verzweigen. Sämtliche Felder im RPC-Protokollkopf sind im
XDR-Format (External Data Representaion) ([RFC 1014]) kodiert.
5.1 Einführung
5.4 NFS-Protokoll
Das Network File System (NFS) erlaubt Programmen, auf Dateien in NFS-Serverrechnern Das NFS-Protokoll ([RFC 1094]) ist auf dem Remote Procedure Call (RPC) Abschnitt 5.3
schreibend und lesend zuzugreifen. Der Zugriff geschieht für diese Programme transparent: aufgebaut. Es besteht selbst aus einer Anzahl von RPC-Prozeduren. Die RPC-Protokollparameter
sie müssen für den Betrieb mit NFS weder abgeändert, noch speziell vorbereitet oder mit für das NFS Protokoll:
zusätzlichen Parametern aufgerufen werden. Die Dateien im NFS-Server werden zugänglich
Programmnummer: 100003
gemacht, indem der NFS-Client-Rechner einzelne Dateisysteme oder Ausschnitte aus Datei-
Versionsnummer: 2
systemen des NFS-Servers in sein eigenes Dateisystem einhängt ( mount“). Die Bereitstel-
” Transportprotokoll: UDP
lung der Zugriffsmöglichkeit erfolgt also nicht auf Veranlassung des zugreifenden Programms,
Portnummer: 2049
sondern muss bereits vor dem Zeitpunkt des Zugriffs für das lokale System geschehen sein.
Alle Prozeduren des NFS-Protokolls sind synchron (sequentiell und blocking)17 . Wenn ein
Prozeduraufruf zurückkehrt, kann der Client davon ausgehen, dass die Operation vollständig
abgeschlossen ist. Das ist ein wichtiger Aspekt der Zustandlosigkeit des NFS-Protokolls. Es
5.2 Herkunft und Entstehungsgeschichte von NFS folgt die Protokollspezifikation von NFS in Remote Procedure Call Language (RPCL):
NFS wurde im Jahre 1984 von der Firma Sun Microsystems, Inc. entwickelt und im fol- /*
genden Jahr die erste Implementierung mit der Versionsnummer 2.0 vorgestellt. Es enthielt * Remote file service routines
(eingebettet in das Virtual File System (VFS)) eine Client- und Server-Implementierung */
von NFS, sowie den Verzeichnis-Dienst Yellow Pages (YP). Sun Microsystems hat sich der
Philosophie der verteilten und offenen Systeme verschrieben. Daher wurde NFS von An- program NFS_PROGRAM {
fang an so konzipiert, dass es die Kopplung von Rechnern verschiedener Hersteller mit version NFS_VERSION {
den unterschiedlichsten darauf ablaufenden Betriebssystemen erlaubt. Die Spezifikationen
der NFS-Protokolle wurden veröffentlicht, eine Referenzimplementierung für UNIX ist allen /* Prozedur 0, Tut nichts - für Testzwecke */
void
interessierten Parteien für einen im Verhältnis zum Aufwand günstigen Preis zugänglich.
NFSPROC_NULL(void) = 0;
Einige wenige Hersteller und Softwarehäuser (selbstverständlich auch das Linux-Projekt)
haben das NFS-Protokoll anhand der veröffentlichten Spezifikationen von Grund auf selbst /* Prozedur 1, Dateiattribute holen */
implementiert und frei gegeben. attrstat
1992 gab es 3.1 Millionen installierte Einheiten und über 100 verschiedene Implemen- NFSPROC_GETATTR(fhandle) = 1;
tierungen - NFS ist eine der erfolgreichsten UNIX-Technologien überhaupt. Im Jahre 1995
erschien NFS Version 3 (siehe Abschnitt 5.5) und im April 2003 die Version 4 (siehe Ab- 16 Mit einem ähnlichen Thema beschäftigt sich auch die Gruppe 8: XML-RPCs“.
17 Die ”
schnitt 5.6). Linux-Implementation von NFSV2 erlaubt einen asynchronen Modus
66 5 NETWORK FILE SYSTEM (NFS)/CLUSTERNFS 5.4 NFS-Protokoll 67

/* Prozedur 2, Dateiattribute setzen */ /* Prozedur 16, Dateiverzeichnis lesen */

attrstat readdirres
NFSPROC_SETATTR(sattrargs) = 2; NFSPROC_READDIR(readdirargs) = 16;

/* Prozedur 3, Root-Verzeichnis auslesen - obsolet */ /* Prozedur 17, Dateisystemattribute lesen */

void statfsres
NFSPROC_ROOT(void) = 3; NFSPROC_STATFS(fhandle) = 17;
} = 2;
/* Prozedur 4, Dateinamen suchen */ } = 100003;
diropres
NFSPROC_LOOKUP(diropargs) = 4; Für die Beschreibung der Prozeduren und die Definition der NFS-Datentypen siehe [RFC
1094].
/* Prozedur 5, Inhalt eines symbolischen Links lesen */
readlinkres 5.4.1 Mount-Protokoll
NFSPROC_READLINK(fhandle) = 5;
Das NFS-Protokoll ([RFC 1094]) spezifiziert nur den Dateizugriff. Das Mount-Protokoll ist
/* Prozedur 6, Datei lesen */ notwendig, um den Dateibaum auf dem Server (welcher vom mountd exportiert wurde) in
readres den lokalen Dateibaum einzuhängen. Danach können die Applikationen mit Hilfe des File
NFSPROC_READ(readargs) = 6; Handles des Dateiverzeichnisses selbständig auf die Dateien dieses Baumes zugreifen. Die
Mount-Protokollspezifikation:
/* Prozedur 7, Cache schreiben - wird momentan nicht verwendet*/ /*
void * Protocol description for
NFSPROC_WRITECACHE(void) = 7; * the mount program
*/
/* Prozedur 8, Datei schreiben */ program MOUNTPROG {
attrstat /*
NFSPROC_WRITE(writeargs) = 8; * Version 1 of the mount protocol used with
* version 2 of the NFS protocol.
/* Prozedur 9, Datei einrichen */ */
diropres version MOUNTVERS {
NFSPROC_CREATE(createargs) = 9; void
MOUNTPROC_NULL(void) = 0;
/* Prozedur 10, Datei löschen */
stat fhstatus
NFSPROC_REMOVE(diropargs) = 10; MOUNTPROC_MNT(dirpath) = 1;

/* Prozedur 11, Datei umbenennen */ mountlist

stat MOUNTPROC_DUMP(void) = 2;
NFSPROC_RENAME(renameargs) = 11;
void
/* Prozedur 12, Link erzeugen */ MOUNTPROC_UMNT(dirpath) = 3;
stat
NFSPROC_LINK(linkargs) = 12; void
MOUNTPROC_UMNTALL(void) = 4;
/* Prozedur 13, Symbolischen Link erzeugen */
stat exportlist
NFSPROC_SYMLINK(symlinkargs) = 13; MOUNTPROC_EXPORT(void) = 5;
} = 1;
/* Prozedur 14, Dateiverzeichnis einrichten */ } = 100005;
diropres
NFSPROC_MKDIR(createargs) = 14; Für die Beschreibung der Prozeduren und die Definition der NFS-Datentypen siehe [RFC
1094].
/* Prozedur 15, Dateiverzeichnis löschen */
stat 5.4.2 Besondere Eigenschaften des NFS-Protokolls
NFSPROC_RMDIR(diropargs) = 15;
Beim Entwurf von NFS wurde besonders darauf geachtet, den Dateizugriff möglichst robust
zu machen. Außerdem sollte das Problem des Wiederanlaufs nach einem Absturz des Server-
68 5 NETWORK FILE SYSTEM (NFS)/CLUSTERNFS 5.7 Überblick über alle NFS-Protokoll-Versionen 69

oder Client-Rechners nicht auftreten. Die Lösung war ein zustandloses Protokoll, bei dem 5.7 Überblick über alle NFS-Protokoll-Versionen
der Server keine Information über den augenblicklichen Zustand oder Fortschritt des Dialogs
mit dem Client speichern muss. Da der File Handle für eine Datei immer eindeutig sein NFS V2 NFS V3 NFS V4
muss, ist es nach einem Server-Absturz und dem folgenden Wiederanlauf möglich, eine Transport-Protokoll UDP TCP/UDP TCP/UDP
Leseoperation transparent für das Client-Programm fortzusetzen. Während der Server nicht max. Dateigröße ≤4 GB (32-Bit) ≤4 GB (64-Bit) ≤4 GB (64-Bit)
verfügbar ist, wiederholt das Client-System in regelmäßigen Zeitabständen den Leseauftrag max. Paketgröße 8 KB Bis zu 56 KB Bis zu 56 KB
mit den gleichen Parametern an den Server - so lange, bis dieser wieder antwortet. Das Authentifizierung AUTH UNIX AUTH UNIX, Mehrere
erneute Aussenden von Aufträgen nach Ausbleiben einer Antwort ist ein Bestandteil des AUTH DES, [Link]̈glich-
RPC-Mechanismus. AUTH KERB keiten; Stan-
Die Semantik von den RPC-Prozeduren muss derart definiert sein, dass eine problemlose dardmäßig
Wiederholung (Idempotenz) möglich ist. Im NFS-Protokoll ist dies aber bei einigen Proze- Kerberos und
duren (REMOVE, CREATE, RMDIR, MKDIR, LINK, SYMLINK und SETATTR) nicht LIPKEY
der Fall. Damit daraus keine Probleme entstehen, unterhält die NFS-Serverimplementierung Leistungsoptierungen Save Asyn- Compound RP-
unter UNIX einen Cache, in dem bereits erledigte Aufrufe aller nicht wiederholbaren Pro- chronous Wri- Cs, File Delega-
zeduren mit ihrer Transaktions-ID gespeichert werden. Mit Hilfe dieses Caches lassen sich tes, Autom. tion (Update am
Wiederholungen solcher Aufträge an einer bereits gespeicherten RPC-Transaktions-ID er- Dateiattribute- Server erst bei
kennen - anstelle eines Fehlerkodes wird dann ein positives Ergebnis zurückgeliefert. Updates Bedarf)

5.5 NFS Version 3 5.8 WebNFS

NFS Version 2 war über 10 Jahre im Einsatz als im Jahre 1995 durch die neuen Anforde- Vollständigkeitshalber sei hier das WebNFS erwähnt. Die Idee dahinter ist die Verwendung
rungen (vor allem die Unterstützung für Dateien mit mehr als 2 GB) das NFS-Protokoll in des NFS-Protokolls zum Zugriff auf Daten im Zusammenhang mit WWW-Browsern bei ge-
der Version 3 ([RFC 1813]) vorgestellt wurde. Die wesentlichen Neuerung in NFS V3: ringfügigen Modifikationen von bestehenden NFS V2 & V3 Servern. Die Erweiterungen des
NFS-Protokolls sind im RFC 2054 für Web-Clients und im RFC 2055 für Web-Server spezi-
• Unterstützung von 64-Bit-Dateilängen
fiziert. Bei näherer Betrachtung stellen sich die Unterschiede des WebNFS gegenüber NFS
• Funktion zur Zugriffsprüfung durch den Server
aber als durchaus umfangreich und ein wenig konstruiert dar, sodass uns eine umfassende
• Leistungsteigerungen durch
Adaption der WebNFS-Spezifikation in normalen NFS-Implementierungen derzeit als eher
– automatische Dateiattribute-Updates mit jeder Operation unwahrscheinlich erscheint.
– Einführung des Konzeptes des Save Asynchronous Writes“: Schreiben in den
”
Servercache mit anschließender Commit-Operation
– Aufhebung der Größenbegrenzungen beim Datentransfer (NFS V2: max. 8 KB 5.9 Authentifizierung
Paketlänge)
Ursprünglich gab es in NFS keine im heutigen Sinne wirkungsvolle Form der Authentifizie-
• Offizielle Unterstützung für NFS über das TCP-Protokoll (NFS V2 nur über UDP) rung. Gründe dafür sind u.A. folgende:

5.6 NFS Version 4 • Damals hatte man eine andere Infrastruktur, nämlich größtenteils abgeschlossene Net-
ze ohne Verbindung nach außen.
Das NFS-Protokoll Version 4 unterscheidet sich von seinen Vorgängern gänzlich in seiner • Hardware war damals teuer und klobig. Es konnte nicht einfach jemand unbemerkt
Struktur. Es kommt ohne die externen Protokolle für Mount und Locking Manager aus. Die sein Notebook mitnehmen und ans Netzwerk hängen.
Verwendung von nur mehr einem Protokoll erleichtert das Zusammenspiel mit den Firewalls. • Die Computer wurden ausschließlich von Administratoren (und nicht von den Usern
Die wichtigsten Neuerungen: selbst) verwaltet, auf deren moralische Integrität man sich verließ. Den Usern war es
praktisch unmöglich, die Herrschaft über einen solchen Computer zu erlangen.
• NFSV4 ist nicht mehr zustandslos. Client und Server führen stets die Zustände für
• Früher war alles eher kooperativ“ ausgelegt (Ursprung in Unis)
ihre Operationen, z.B.: File öffnen, lesen, sperren, etc. mit. Um die Zustände konsi- ”
• An heute existierende Bedrohungen wurde nicht gedacht.
stent zu halten, sind aufwendige Maßnahmen für den Client- und Server-Wiederanlauf
notwendig.
Daraus resultieren die damals vorgesehen Authentifizierungs“- und Sicherheits-Maßnahmen
• NFSV4 unterstützt das Zusammensetzen von mehreren Operationen. Komplexe Ope- ”
für NFS:
rationen können dadurch mit einem RPC-Aufruf erledigt werden.
• NFSV4 spezifiziert mehrere Authentifzierungsmöglichkeiten (standardmäßig: Kerbe-
ros und LIPKEY). Ein API steht für die Erweiterung mit anderen Authentifizierungs- Client-Identfikation über die IP-Adresse. Die Berechtigung, ein bestimmtes Server-
mechanismen zur verfügung. Directory über NFS zu mounten, wird über die IP-Adresse gesteuert. (Zuordnung:
Datei /etc/exports) Sobald ein Host eine bestimmte IP hat, hat er Zugang zu allen
Für weitere Details siehe [Pawlowsky]. für diese IP exportierten NFS-Shares. Das war ursprünglich sicher, weil aus den oben
70 5 NETWORK FILE SYSTEM (NFS)/CLUSTERNFS 5.10 ClusterNFS 71

genannten Gründen niemand (außer root) eine falsche IP angeben konnte. Heute kann • Eigener Switch für den Cluster.
man leicht eine IP spoofen18 , wenn man Zugang zum Netz hat. (Notebook)
Wenn die Clients große Datenmengen über das Netzwerk senden, bremst eine Ver-
User-Identifikation über UID (user id) und GID (group id). Die üblichen Unix-Berechtigungen schlüsselung alle beteiligten Rechner ziemlich. (Besonders den Server.) Um ein Snif-
(numerische User- und Group-ID) gibt es auch bei NFS. Die Authentifizierung darüber fing zu verhindern, kann man den ganzen Cluster an einen eigenen, getrennten Switch
wird in den RFCs AUTH UNIX“ genannt. Jeder Benutzer hat am Client nur Zugriff hängen, der mit einer Firewall vom restlichen Netzwerk getrennt ist.
”
auf die Dateien, auf die er auch am Server mit seinen IDs Zugriff hätte. Das war Wenn man dann im Inneren des Clusters auf Sicherheitsmaßnahmen verzichtet, ist die
ursprünglich sicher, weil aus den oben genannten Gründen niemand (außer root) eine Sicherheit des Clusters durch die Sicherheit der Firewall bestimmt.
falsche ID vortäuschen konnte. Heute kann man mit Zugang zum Netz leicht beliebige
Identitäten annehmen. (Auf seinem eigenen Notebook ist man root bzw. wer immer
man sein will.) 5.10 ClusterNFS
Mapping des root-Users auf nobody. (Linux: Option root squash). Das ist die einzige Nach einer kurzen Definition und Beschreibung von Clustern werden die Fähigkeiten und
Maßnahme, die auch heute noch wirksam ist, falls der Server nicht physisch zugänglich momentanen Schwächen von ClusterNFS diskutiert.
ist. Dabei wird vom NFS-Server ein Zugriff des Users root des Clients auf den User
nobody des Servers gemappt, der üblicherweise sehr wenige Rechte hat. Damit kann
man zumindest sicherstellen, dass ein Eindringling am Server nicht mehr Rechte hat als 5.10.1 Cluster
die Vereinigung aller Rechte aller dort vorhandenen gewöhnlichen User incl. nobody
aber nicht die Rechte des privilegierten Benutzers root. Eine mögliche Definition: Eine Menge (mehr als einer) von relativ gleichartigen Computern,
die eine gemeinsame Aufgabe erfüllen.
Wenn alle Teilrechner des Clusters mit dem selben System arbeiten sollen, dann bietet
5.9.1 Maßnahmen zur sichereren Authentifizierung
es sich an, sie diskless“ zu betreiben.
”
• Secure NFS mit Hilfe von Secure-RPC
Sämtliche RPC-Calls werden mit einem Public-Key Verfahren abgesichert. (NIS19 5.10.2 Diskless Client
erleichtert dabei die Passwort-Verteilung.)
Das ist (wie der Name andeutet) ein Computer, der keine Festplatte hat, sondern sein root-
• Tunneln von NFS über SSH20 . Filesystem über das Netz bezieht. Keine Platte“ ist nicht unbedingt so streng zu sehen.
”
Man exportiert nur mehr an localhost“ und Clients müssen sich mit SSH auf den Eine reine Swap-Platte ist z.B. für bessere Performance zu empfehlen. Den Bootsektor
” und ggf. den Kernel kann man auch auf dieser Platte speichern, wenn die Netzwerkkarte
Server verbinden und das NFS-Protokoll durch einen dabei hergestellten Tunnel leiten.
nicht die notwendigen Fähigkeiten für ein direktes Booten eines Betriebssystems über das
• Einsatz von NFS4 und Verwendung eines der darin integrierten Authentifizierungs- Netzwerk hat. Der wesentliche Punkt ist der, dass man lokal kein Betriebssystem installiert
Mechanismen. hat. Vorteile eines diskless client“:
”

5.9.2 Alternative Maßnahmen zur Erhöhung der Sicherheit • Zuverlässigkeit (im wirklich disklosen“ Fall: Festplatte kann nicht kaputt werden.)
”
Oft muss man Sicherheit gegen Performance tauschen und in vielen Fällen kann man Sicher-
• Verfügbarkeit (Im Fall mit Swap-Platte: Wiederaufnahme des Betriebs innerhalb we-
heit auch ohne kryptographische Maßnahmen erreichen. Hier nur noch ein paar Stichworte
niger Minuten nach einem Plattenfehler.)
dazu:

• Serverraum absperren. • Datensicherheit (RAID am Server.)

Es gibt keine logische Sicherheit“ ohne physische“ Sicherheit. Wenn jemand Zugang • Backup kann am Server erfolgen
” ”
zu einem Computer hat, kann er alles damit machen, z.B. die Platte ausbauen.

• Einsatz von Firewalls • Kosten (Festplatte entfällt. Ein zentrales RAID am Server ist wesentlich billiger als
eines pro Client.)
• Intelligenz der Benutzer erhöhen
18 IP-Spoofing:
• Arbeitsersparnis bei Software-Pflege. (Installation bzw. Update von Software am
Unberechtigte Verwendung bzw. Vortäuschung einer IP-Adresse in einem Netzwerk. Damit
kann man sowohl Switches dazu bewegen, einem Pakete zu schicken, die eigentlich jemandem anderen gehören
Server wirkt sich bei geeigneter Konzeption des Clusters auf alle Clients aus.)
als auch Pakete unter Verwendung einer falschen Absenderadresse verschicken.
19 Network Information Service. Ein Protokoll der Firma SUN zur Erleichterung der Verwaltung von

mehreren Unix-Workstations. NIS wurde gleichzeitig mit NFS entwickelt und veröffentlicht.
Natürlich hat man auch Nachteile, wie z.B. eine geringere IO-Performance sowie die Not-
20 Secure Shell. Ein sicherer Ersatz für die unsicheren Protokolle telnet, rsh, rcp etc. Sowohl die Authenti- wendigkeit, einen schnellen Server einzusetzen, wenn man viele Clients bedienen will. Es
fizierung als auch die während der Sitzung übertragenen Daten werden mit sicheren Methoden verschlüsselt. gibt aber zahlreiche Fälle, in denen die Vorteile die Nachteile überwiegen.
72 5 NETWORK FILE SYSTEM (NFS)/CLUSTERNFS 5.10 ClusterNFS 73

5.10.3 Motivation für ClusterNFS Alle Datei- und Directory-Aktionen (read, create, link, softlink, getattrib, setattrib, rena-
me, remove, copy, mkdir, rmdir) unterstützen dieses Schema.
Wir wollen das ClusterNFS erweitern, sodass auch der Fall funktioniert, in dem sich alle Cli- ClusterNFS kann auch (in eingeschränkter Weise – siehe Abschnitt 5.10.6) die Erzeu-
ents das gleiche root-Verzeichnis schreibenderweise teilen, wobei es zu keinen ungewünschten gung von Dateien in Abhängigkeit von der Datei $$CREATE=<tag>$$“ beeinflussen. Wenn
Beeinflussungen zwischen den Clients kommen darf. ”
z.B. der Versuch gemacht wird, die Datei myfile“ anzulegen, prüft der NFS-Server auf das
Sobald das geschafft ist, kann man ohne weitere Änderungen die Clients sogar mit dem ”
Vorhandensein einer Datei namens
root-Verzeichnis des Servers selbst betreiben. myfile$$CREATE=<tag>$$“. Wenn diese Datei existiert, wird die Datei unter dem Na-
Damit ist dann das Optimum der Wartbarkeit erreicht. Um z.B. ein neues Programm ”
men myfile$$tag=value$$“ neu angelegt, wenn nicht, dann ganz normal als myfile“.
auf allen Clients zu installieren, reicht es, dieses auf dem Server wie auf einem Einzelplatz- ” ”
Das Vorhandensein einer Datei namens $$CREATE=<tag>“ steuert die Datei-Erzeugungs-
System zu installieren. Es ist dann automatisch und ohne Änderungen für alle Clients ”
Strategie für ein gesamtes Verzeichnis.
ausführbar21 .
5.10.5 Momentane Fähigkeiten von ClusterNFS
5.10.4 Konzept von ClusterNFS
ClusterNFS funktioniert bereits jetzt, wenn man sich auf read-only-mounted Clients be-
ClusterNFS22 ist ein Patch für den unter dem Namen Universal NFS Daemon“ ([UNFSD]) schränkt. Einen kleinen Fehler gibt es auch da: Ein Client kann die Dateien eines anderen
”
bekannten NFS-Server23 , der mit der Idee geschaffen wurde, mehrere Computer als Dis- Clients lesen, wenn er deren tagged name“ verwendet.
kless Clients zu betreiben, wobei nicht für jeden ein eigenes root-Verzeichnis notwendig ist, ”
sondern sich alle Clients das gleiche Verzeichnis teilen. Die wenigen Dateien, die bei den 5.10.6 Momentane Schwachpunkte von ClusterNFS
verschiedenen Clients unterschiedlich sind, werden durch interpretierte“ Dateinamen (auch
”
tagged names“ genannt) realisiert. Um die originale Datei ohne Tags zu beschreiben, wird Können die Clients auf das gemeinsam benutzte root-directory auch schreiben (read-write-
”
im Folgenden die Bezeichnung base name“ verwendet. mounted), dann kommt es zu ungewollten gegenseitigen Beeinflussungen. Es gibt momentan
”
Alle im Folgenden beschriebenen Features gelten übrigens nicht nur für Files, sondern (mindestens) folgende Fehlfunktionen:
auch für Directories, Links, Pipes, Char- und Block-Devices.
• Gemeinsam genutzte Dateien können von einem Client gelöscht werden und sind dann
Wenn ein Client die Datei /path/filename“ anfordert, sucht ClusterNFS nach dem Vor-
” für alle Clients gelöscht.
handensein von Dateien der Form /path/filename$$KEY=value$$. Wenn eine solche Datei
• Seltsame Semantik beim Löschen von Files am Client, wenn ein tagged file“ und ein
existiert und der Client einen passenden value für den KEY aufweist, dann wird diese Datei ”
base file“ existieren:
zurückgegeben. Wenn der value nicht stimmt, oder keine derartige Datei existiert, dann ”
wird der File-Request wie üblich abgearbeitet. Im Moment werden die KEYs HOST (Hostna- – Die Datei wird gelöscht ( tagged file“)
”
me), IP (IP-Adresse) und CLIENT (gilt für jeden NFS-Client) unterstützt. – Die Datei ist immer noch da, aber mit anderem Inhalt! ( base file“)
”
Indem man nun auf dem Server alle Client-spezifischen Dateien – Die Datei wird nochmal gelöscht ( base file“)
”
filename$$IP=[Link]$$“ nennt, bzw. Dateien, die für alle Clients gleich, aber – Diesmal ist sie wirklich weg. (Leider aber die gemeinsam genutze Version.)
”
für den Server unterschiedlich sind filename$$CLIENT$$“ nennt, können der Server und • Das CREATE“-Tag funktioniert nur eingeschränkt, nämlich wirklich ausschließlich beim
” ”
alle Clients das selbe root filesystem teilen. Das erleichtert es, einen ganzen Pool von plat- create“, nicht aber beim Modifizieren von Daten, wenn es ein base file“ aber noch
tenlosen Maschinen aufzusetzen und zu warten. ” ”
kein tagged file“ gibt. Durch diese unzureichende Funktionalität kann jeder Client un-
Wenn der NFS-Server mit der Option -T“ oder --translate-names“ gestartet wird, ”
” ” absichtlich gemeinsam benutzte Files überschreiben, die dann für alle Clients verändert
versucht er, einen angeforderte Dateinamen durch Anhängen von verschiedenen Zusätzen sind.
mit Dateien am Server zur Deckung zu bringen. Die Zusätze werden in der folgenden • analog zum read-only-Fall kann ein Client beliebige Dateien beliebiger anderer Clients
Reihenfolge ausprobiert und der erste übereinstimmende Name wird verwendet. überschreiben, indem er deren tagged name“ verwendet.
”
1. /path/filename$$HOSTNAME=ssss$$ (Client hat den Hostnamen ssss) Die angeführten Fehler reichen aus, um ein gemeinsames root directory nach kurzer Zeit der
2. /path/filename$$IP=[Link]$$ gemeinsamen Benutzung so zu zerschießen“, dass viele Programme und Dienste am Client
”
(Client hat die IP-Adresse [Link]) nicht mehr vernünftig oder gar nicht mehr funktonieren.
3. /path/filename$$CLIENT$$ (Client greift über NFS auf die Datei zu)
4. /path/filename (Liefert immer einen Treffer) 5.10.7 Ansatz zur Verbesserung der Schwachpunkte

Wenn eine übereinstimmende Datei gefunden wurde, aber die Berechtigungen nicht stim- Für die korrekte Funktionsweise des ClusterNFS mit Schreibzugriff werden folgende Punkte
men, dann wird das nicht als Treffer interpretiert und mit dem nächsten Zusatz fortgesetzt. benötigt:

21 Zum Glück hat sich unter Unix noch keine Art von Registry“ durchgesetzt, denn etwas derartiges Eine Möglichkeit, Dateien zu verstecken. Das braucht man für Sicherheit und für die
”
(Tausende Konfigurationseinträge zu den unterschiedlichsten Bereichen und Programmen in einer einzigen semantisch korrekte Unterstützung des Löschens von Dateien. Sicherheit: Man will
Datei) würde eine solche Vorgehensweise perfekt vereiteln.
22 Eine kurze, einführende Beschreibung findet man auf der Webseite [ClusterNFS] z.B. nicht, dass der Client die Datei “/etc/shadow“ des Servers lesen kann. Löschen:
23 Wird momentan mit den meisten Linux-Distributionen mitgeliefert, zusätzlich zum NFS-Server, der in Wenn man Dateien nicht verstecken kann, sieht der Client nach dem Löschen eines
den Linux-Kernel integriert ist. Client-Files nicht wie erwünscht Nichts, sondern das Base-File.
74 LITERATURVERZEICHNIS LITERATURVERZEICHNIS 75

Eine copy on write“-Semantik (COW) als Default. Legt zusammen mit dem fol- [Stern] Hal Stern: NFS und NIS (Managing von UNIX-Netzwerken)“, 1. Auflage, Addison-
” ”
genden Punkt das Verhalten beim Schreiben einer Datei fest. Es soll prinzipiell so Wesley (1993).
sein, dass der Client beim Schreiben einer Datei nie das Base-File überschreibt, son-
dern immer eine eigene Kopie anlegt und diese verändert. [RFC 1094] Sun Microsystem, Inc.: NFS: Network File System Protocol Specification“
”
RFC 1094, März 1989
Eine Möglichkeit, Dateien als shared“ zu definieren. Wenn man explizit wünscht,
” [RFC 1813] B. Callaghan, B. Pawlowski, P. Staubach: NFS Version 3 Protocol Specifica-
dass eine Datei geteilt wird, dann soll man das angeben können. (z.B. file$$SHARED$$“) ”
” tion“ RFC 1813, Juni 1995
Das ist eine Umkehrung des momentanen Verhaltens (alle Dateien geteilt, explizite An-
gabe des Tags CREATE“, falls das nicht erwünscht ist). Da mir aber nur ein einziger [RFC 3530] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow: (NFS) version 4 Protocol“
” ”
Fall einfällt, für den ein shared write“ bedingt sinnvoll ist (gemeinsam genutztes RFC 3530, April 2003
”
Logfile) ist es sinnlos, diesen Fall als Default festzulegen.
[Pawlowsky] B. Pawlowsky: The NFS Version 4 Protocoll“
Verhinderung des Zugriffs von Clients auf tagged names“ Das dient dazu, dass ein ”
” ([Link]
Client keine Dateien von anderen Clients lesen, verändern oder löschen kann. Das ist
am einfachsten zu realisieren, indem man dem Client den Zugriff auf Filenamen der [RFC 1050] Sun Microsystem, Inc.: RPC: Remote Procedure Call Protokoll specification
”
Form file$$<tag>$$“ prinzipiell verbietet. Da der (ziemlich unwahrscheinliche) Fall version 2“ RFC 1050, jetzt RFC 1356, Juni 1988
”
eintreten könnte, dass eine Anwendung unbedingt Namen in dieser Form schreiben
[RFC 1014] Sun Microsystem, Inc.: XDR: External Data Representation Standard“
können muss, werden wir in unserer Erweiterung das Tag-Separations-Zeichen ($$) ”
RFC 1014, Juni 1987
konfigurierbar machen. (z.B. mit der Option “--tag-separator=XX“)
[ClusterNFS] ClusterNFS: [Link]
5.10.8 Weitere Möglichkeiten für Projekte
[UNFS3] User-space NFSv3 Server (UNFS3): [Link]
Folgende Punkte sind wegen des zu großen und nicht einfach abschätzbaren Arbeitsaufwands
[UNFSD] Universal NFS2 Daemon:
nicht Bestandteil unseres praktischen Projekts, würden sich aber für Folgeprojekte anbieten:
[Link] id=142
• Portierung der ClusterNFS-Fähigkeiten auf NFS3. [Samba] Samba: opening windows to a wider world“ [Link]
(z.B. auf den User-space NFSv3 Server UNFS3: [UNFS3]) ”
• Auslagerung der Funktionalität in eine eigene Bibliothek zur Verwendung in anderen [Cygwin] Cygwin, a Linux-like environment for Windows: [Link]
Netzwerk-Dateisystemen.
• Verwendung dieser Bibliothek in Samba ([Samba]) um ein ClusterSMB“ bzw. Clu-
” ”
sterCIFS“ 24 mit ähnlichen Fähigkeiten zu bekommen25 .
• etc. . .

5.11 Zusammenfassung
NFS ist ein bewährtes Netzwerk-Dateisystem aus dem Unix-Bereich, das mit der Version 4
auch auf zukünftige Anforderungen vorbereitet ist.
ClusterNFS ist eine spezielle Version eines NFS-Servers, die es erlaubt, für unterschied-
liche Clients unterschiedliche Versionen einer Datei auszuliefern.
ClusterNFS ist im Moment wegen ein paar Schwachpunkten (die wir aber in unserem
Projekt beheben wollen) noch nicht konsequent einsetzbar.
Die Idee von ClusterNFS ist prinzipiell auch auf andere Netzwerk-Dateisysteme (z.B.
SMB/CIFS) anwendbar.

Literaturverzeichnis
[Santifaller] Michael Santifaller: TCP/IP und ONC/NFS“, 4. Auflage, Addison-Wesley
”
(1998).
24 SMB und CIFS sind die Akronyme für die älteren (SMB) und die neueren (CIFS) Versionen der Datei-

Serverdienste von Windows.

25 Man kann damit zwar kein Diskless Windows“ machen, aber zumindest ein Diskless Cygwin“. (Cyg-
” ”
win: siehe [Cygwin])
76 6 SIMPLE OBJECT ACCESS PROTOCOL (SOAP) 6.2 Nachrichten in SOAP – SOAP Envelope 77

6 Simple Object Access Protocol (SOAP) Struktur als SOAP Envelope. So enthält der Header Informationsblöcke, die sich darauf
beziehen, wie die Nachricht verarbeitet werden soll. Dazu gehören Angaben zum Routing
In der heutigen Zeit nimmt die Bedeutung des Informationsaustauschs zwischen dezentrali- und zur Auslieferung, Aussagen über die Authentifizierung oder Autorisierung und Transak-
sierten System immer mehr zu. Vorallem das Medium Internet und die damit verbundenen tionskontexte. Der Body enthält die eigentliche Nachricht, die ausgeliefert und verarbeitet
Transferprotokolle - speziell einfache, erweiterbare und unabhängige Protokolle - nehmen werden soll. Alles, was in XML-Syntax ausgedrückt werden kann, kann im Body einer
hierbei eine entscheidende Rolle ein. So macht durchaus Sinn, sich eingehender mit jenen Nachricht stehen.
Protokollstandards auseinander zu setzen. Der folgende Abschnitt beschäftigt sich mit einem Weiters wird auch der Standardnamespace27 für SOAP Encoding und Datentypen defi-
Solchen und soll eine Motivation für das eigene Einarbeiten in diese Materie geben. niert. Wie in Abbildung 38 zu sehen ist, ist es syntaktisch notwendig, sowohl den envelope-
als auch den encoding-Namespace zu verwenden.
Thomas Fuchs: minos@[Link]
Marc Klostermann: a3@[Link]
SOAP Envelope
Florian Mendel: mendel@[Link]
SOAP Header
6.1 Einführung
Simple Object Access Protocol (SOAP) ist ein XML-basiertes Messaging-Protokoll für den Headerblock
Austausch von strukturierten Informationen zwischen Peers in einer dezentralisierten, ver-
teilten Umgebung.
Headerblock

Headerblock

SOAP Body
Abbildung 36: SOAP Kommunikation [Schwichtenberg 2002]
eigentliche Nachricht

SOAP besteht aus drei Teilen:

SOAP Faults
• envelope: ist das oberste Element in der Nachricht, welches die Nachricht und wie
diese zu verarbeiten ist, beschreibt.
• encoding rules: definieren Serialisierungsmethoden zum Austausch von Objekten einer
Applikation.
• soap-rpc:ist eine Übereinkunft darüber, wie die Remote Procedure Calls (RPC) und
deren Antworten repräsentiert werden. Abbildung 37: Struktur einer SOAP-Nachricht

SOAPs großer Vorteil gegenüber anderen Messaging-Protokollen ist seine Einfachheit und
Erweiterbarkeit, d.h. mehrere Merkmale traditioneller Systeme sind nicht Teil der Spezifi-
kation von SOAP (z.B. distributed garbage collection). 6.2.1 SOAP Header
Wenn ein Envelope ein Headerelement enthält, darf er nur ein einziges enthalten, das au-
6.2 Nachrichten in SOAP – SOAP Envelope
ßerdem als erstes Kind des Envelopes vor dem Body erscheint. Der Header kann jeden
Wie bereits erwähnt, definiert die Spezifikation für eine SOAP-Nachricht lediglich einen ein- beliebigen gültigen, wohlgeformten und namespace-qualifizierten XML-Code enthalten, den
fachen XML-basierten Umschlag (Envelope) für die zu übertragenden Informationen sowie der Erzeuger der SOAP-Nachricht dort einfügen möchte.
einen Regelsatz für die Umsetzung anwendungs- und plattformspezifischer Datentypen in Jedes der im Header enthaltenen Elemente wird Headerblock genannt. Der Zweck eines
XML-Darstellungen. Headerblocks besteht darin, Kontextinformationen mitzuteilen, die für die Verarbeitung
Der SOAP Envelope besteht aus einem Body und einem optional vorangestelltem Hea- einer SOAP-Nachricht relevant sind. Ein Beispiel wäre ein Headerblock, der die Identität
der – jene Bestandteile sind im Standardnamespace26 deklariert und definieren eine solche des Absenders nachweist oder über das gewünschte Routing der Nachricht informiert.
26 [Link] 27 [Link]
78 6 SIMPLE OBJECT ACCESS PROTOCOL (SOAP) 6.2 Nachrichten in SOAP – SOAP Envelope 79

6.2.2 SOAP Body

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="[Link] Jedes Envelope-Element muss genau ein Bodyelement enthalten. Dieses kann so viele Kind-
soap:encodingStyle="[Link]
Knoten beinhalten wie benötigt werden, um die gesamte Nachricht unterzubringen. Das
<soap:Header>
... Bodyelement ist so definiert, dass es jeden gültigen, wohlgeformten XML-Code enthalten
</soap:Header> kann, der durch einen Namespace qualifiziert ist und keine Verarbeitungsanweisungen und
<soap:Body> keine Verweise auf “Document Type Definition” (DTD) enthält.
...
<soap:Fault>
...
</soap:Fault> 6.2.3 SOAP Fault
</soap:Body>

</soap:Envelope> Wie aus Abbildung 38 ersichtlich ist, besteht im SOAP Body die Möglichkeit, auch Fehler-
und Statusinformationen zur SOAP-Nachricht unterzubringen. Hierzu bedient man sich dem
optionalen SOAP-Fault-Element. Dieses Element übermittelt folgende vier Informationen:
Abbildung 38: XML-Grundstruktur einer SOAP-Nachricht

Fault-Code: Ein Wert, der den Typ des aufgetretenen Fehlers identifiziert. Der Wert
muss ein qualifizierter Name sein und hat also nur innerhalb eines definierten XML-
Gemäß dem Standardnamespace für SOAP-Envelopes existieren für Headerblöcke drei Namespaces Bedeutung.
Attribute, welche spezifizieren, wie eine SOAP-Nachricht oder Teile davon vom Empfänger
Die vier Standardtypen von Faults sind:
verarbeitet werden soll. Diese Attribute sind:
• VersionMismatch ... Envelope verwendet einen ungültigen Namespace.
actor: Vom Sender zum Empfänger werden verschiedenste Dienste (= actors) im Nachrich-
tenpfad passiert, die irgendetwas, z.B. Verifizierung einer digitalen Signatur, mit der • MustUnderstand ... Ein Headerblock mit gesetztem Attribut wurde nicht ver-
SOAP-Nachricht anstellen – allerdings wird hierzu meistens nur ein Teil der Nachricht standen (siehe 6.2.1 SOAP Header).
gebraucht. Ein Headerblock mit dem Attribut “actor” spezifiziert genau jenen Teil,
• Server ... Ein Fehler, der nicht unmittelbar mit der Verarbeitung der Nachricht
der für den zwischengeschalteten Dienst von Interesse ist.
in Verbindung gebracht werden kann.

<soap:Header> • Client ... In der Nachricht selbst tritt ein Problem auf.
<x:signature actor="uri:SignatureVerifier">
... Fault-String: Eine lesbare Erklärung des Fehlers.
</x:signature>
</soap:Header> Fault-Actor: Die eindeutige Bezeichnung des Knotens mit Nachrichtenpfad – d.h. des
Actors –, bei dem der Fehler aufgetreten ist.
mustUnderstand: Wenn eine SOAP-Nachricht von einer Anwendung an eine andere ge-
Fault-Details: Hiermit werden anwendungsspezifische Einzelheiten über den aufgetretenen
sendet wird, wird implizit vorausgesetzt, dass der Empfänger verstehen muss, wie die
Fehler mitgeteilt. Diese Information muss angegeben werden, wenn der aufgetretene
Nachricht zu verarbeiten ist. Ein Empfänger versteht (oder versteht unter Umständen
Fehler unmittelbar mit einem Problem im Body der Nachricht zusammenhängt. Sie
auch nicht), wie er mit einem bestimmten Headerblock umgehen muss, kann aber
darf jedoch nicht verwendet werden, um Informationen über Fehler auszudrücken, die
möglicherweise die eigentliche Nachricht dennoch ordnungsgemäß verarbeiten. Wenn
im Zusammenhang mit einem der anderen Aspekte des Nachrichtenprozesses aufgetre-
der Absender der Nachricht verlangen will, dass der Empfänger einen bestimmten
ten sind.
Block versteht, kann er diesem das Attribut mustUnderstand =‘‘true‘‘ hinzufügen.
Wenn dieses Flag in einem bestimmten Block gesetzt ist und der Empfänger diesen
Block nicht versteht, muss er die gesamte Nachricht zurückweisen. Beispiel eines SOAP-Faults:

<soap:Body>
<soap:Header> <soap:Fault>
<x:transaction xmlns:x="soap-transaction" <faultcode>[Link]</faultcode>
soap:mustUnderstand="true"> <faultstring>Ungültiger Identitätsnachweis</faultstring>
... <faultactor>uri:actor</faultactor>
</x:transaction> <details>
</soap:Header> <!-- Anwendungsspezifische Einzelheiten -->
</details>
encodingStyle: Wird verwendet, um die im XML-Dokument benützten Datentypen zu </soap:Fault>
charakterisieren (siehe Abbildung 38). </soap:Body>
80 6 SIMPLE OBJECT ACCESS PROTOCOL (SOAP) 6.3 Nachrichtenaustausch 81

6.3 Nachrichtenaustausch 6.3.4 SOAP und RPC

Wie bereits erwähnt, stellt SOAP eine Standardmethode für die Strukturierung von XML- RPC ist derzeit die am weitesten verbreitete Anwendung von SOAP. In den meisten Fällen
Nachrichten zur Verfügung. Da XML an keine spezielle Anwendung, Betriebssystemum- wird auch hier HTTP als Protokoll verwendet, weil ein RPC Request bzw. Response ei-
gebung oder Programmiersprache gebunden ist, können XML-Nachrichten in allen Umge- nem einfachen HTTP Request/Response entspricht. Natürlich kann SOAP-RPC28 auch mit
bungen verwendet werden. Dies stellt eine flexible Methode zur Kommunikation zwischen anderen Protokollen verwendet werden. Um einen solchen Call zu machen sind folgende
Anwendungen zur Verfügung und bildet die Grundlage für SOAP. Im Folgenden werden wir Informationen notwendig:
Methoden zum Datenaustausch mittels SOAP kennen lernen.
• URI des Zielobjekts

• Name der Methode

6.3.1 SOAP und HTTP
• Signatur der Methode
HTTP ist das bei weitem gebräuchlichste Transportprotokoll für den Austausch von SOAP-
Nachrichten. Weil HTTP ein Protokoll auf der Grundlage von Anfragen und Antworten ist, • Parameter der Methode
eignet es sich ausgezeichnet für den Austausch von SOAP-Nachrichten. Eine Nachricht, die
eine SOAP-Anfrage enthält, wird mit einer HTTP-Anfrage an den HTTP-Server gesendet, • optional Header-Information
und der Server liefert die Nachricht mit der SOAP-Antwort in der HTTP-Antwort zurück. Im Folgenden ist beschrieben, wie Methodenaufrufe und Rückgabewerte im Body einer
SOAP-Nachricht codiert werden.
6.3.2 SOAP HTTP-Request • Der Methodenaufruf wird als einzelne Struktur modelliert.
Obwohl SOAP in Kombination mit vielen HTTP-Request-Methoden verwendet werden • Der Methodenaufruf wird als Struktur dargestellt, wobei die einzelnen Parameter als
kann, wird hier nur HTTP POST besprochen. (Siehe Kapitel 6.3.4 für Inforamtion zur Ver- Feld modelliert werden.
wendung von SOAP mit RPC.) Beispiel eines SOAP Requests:
• Die Struktur hat denselben Namen und Typ wie die implementierte Methode selbst.
POST /StockQuote HTTP/1.1
• Jeder Parameter, der als Feld dargestellt wird, hat denselben Namen und Typ wie
Content-Type: text/xml; charset="utf-8"
der Parameter der Methode. Die Reihenfolge der Felder ist durch die Signatur der
Content-Length: nnnn
Methode festgelegt.
SOAPAction: "[Link]
• Eine Methoden-Antwort wird auch als Struktur modelliert.
<SOAP-ENV:Envelope...
• Die Methoden-Antwort wird als einzelne Struktur dargestellt, welche ein Feld für den
Der HTTP-Header SOAPAction zeigt den Zweck der SOAP-HTTP-Anfrage an. Er ist dafür Rückgabewert hat.
gedacht, dem HTTP-Server mitzuteilen, was die SOAP-Nachricht will, noch ehe der HTTP-
• Jedes Parameter-Feld hat einen Namen und einen Typ, welcher dem Namen des Pa-
Server den XML-Code entschlüsselt hat. Server können somit den SOAPAction-Header ver-
rameters bzw. dessen Typ entspricht.
wenden, um nicht akzeptable Anfragen herauszufiltern.
• Ein Fehler innerhalb der Methode wird mittels eines SOAP-Fault Elementes codiert.
6.3.3 SOAP HTTP Response Das bedeutet, dass die Methode addEvent mit der Signatur
SOAP HTTP verwendet die in HTTP definierten status codes für den Austausch von addEvent(String von, String bis, String titel, String ereignis)
HTTP Status Informationen. So bedeutet zum Beispiel der
2xx status code, dass die Anfrage des Clients, welche die SOAP-Nachricht enthält, er- mit folgenden Parametern aufgerufen werden kann:
folgreich empfangen, verstanden, akzeptiert usw. wurde. Beispiel eines SOAP Response:
addEvent("11.11.2003", "11.11.2003", "Titel", "Beschreibung").

HTTP/1.1 200 OK Dazu verwendet man folgende RPC Anfrage (HTTP als Protokoll):
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn POST /HistoryLine3/[Link] HTTP/1.1
Host: [Link]
<SOAP-ENV:Envelope... Content-Type: text/xml; charset=utf-8
Content-Length: length
Im Fall eines SOAP-Fehlers während der Verarbeitung der Anfrage muss der Server eine SOAPAction: "[Link]
HTTP 500 “Internal Server Error” Response mit einer SOAP-Nachricht, welche ein SOAP-
Fault-Element (siehe 6.2.3) enthält, schicken. 28 Remote Procedure Calls (RPC)
82 6 SIMPLE OBJECT ACCESS PROTOCOL (SOAP) 6.4 Webservices 83

<?xml version="1.0" encoding="utf-8"?> • Internet Inter-ORB Protocol (IIOP) für CORBA (Common Object Request Broker
<soap:Envelope xmlns:xsi="[Link] ... Architecture)
<soap:Body>
<addEvent xmlns="[Link] Alle diese Protokolle waren jedoch im Internet nicht einsetzbar, weil sie nicht plattformun-
<von>11.11.2003</von> abhängig, nicht plattformübergreifend und/oder nicht einfach genug waren.
<bis>11.11.2003</bis> Ein Webservice dagegen ist eine Programmfunktion, die auf einem Webserver bereitge-
<titel>Titel</titel> stellt wird und via HTTP unter Einsatz von SOAP-Nachrichten aufgerufen werden kann
<ereignis>Beschreibung</ereignis> und die in der HTTP-Antwort ebenfalls eine SOAP-Nachricht liefert.
</addEvent>
Die Verwendung von SOAP via HTTP bringt den unschätzbaren Vorteil, dass die Kom-
</soap:Body>
munikation über Port 80 läuft. D.h. es muss nicht in bestehende Sicherheitskonzepte (Fi-
</soap:Envelope>
rewalls, etc.) eines Unternehmens eingegriffen werden, um eine Lösung, die Webservices
Konnte die Methode erfolgreich ausgeführt werden, so schaut die RPC Antwort wie folgt verwendet, zu implementieren.
aus: Eine Anwendung, die per SOAP eine Anfrage an ein Webservice richtet und die Antwort
des Webservices empfängt, heißt Webservice-Client. Ein solcher Webservice-Client kann
HTTP/1.1 200 OK eine Windows-Anwendung, eine Konsolenanwendung unter Linux, eine Web-Applikation in
Content-Type: text/xml; charset=utf-8 [Link], J2EE oder PHP, oder auch ein anderes Webservice sein.
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="[Link] ...
<soap:Body>
<addEventResponse xmlns="[Link]
<addEventResult>true</addEventResult>
</addEventResponse>
</soap:Body>
</soap:Envelope>

Es hat sich eingebürgert, das Element mit der Nachrichten-Antwortstruktur nach der Metho-
de zu benennen und Response anzuhängen. Im ersten Feld in der Nachrichten-Antwortstruktur
wird der Rückgabewert erwartet.
SOAP-Faults werden für die Rückgabe von Fehlermeldungen an RPC-Clients verwendet,
wenn die Methode nicht ausgeführt werden konnte.

6.4 Webservices
Ein Webservice ist eine Klasse, die ihre Methoden auf einem Webserver zum Aufruf anbietet.
Der Aufruf erfolgt via SOAP, das einen Remote Procedure Call (RPC) einschließlich des
Marshalling/Unmarshalling29 der Parameter und Rückgabewerte beschreibt.
Der Gedanke, der hinter Webservices steht, ist die Koppelung von
(Geschäfts-)Anwendungen über das Internet. Dieser Wunsch ist so alt wie das Netz selbst.
Auf technischer Ebene gab und gibt es dazu eine Vielzahl von Ansätzen: Abbildung 39: Interaktion mit Webservices [Schwichtenberg 2002]
• Remote Procedure Calls (RPC) in verschiedenen Varianten: Distributed Computing
Environment (DCE), Open Network Computing (ONC) RCP von Sun, ISO30 RPC
Es gibt mittlerweile auch eine Vielzahl von Entwicklungsplattformen für Webservices.
• Remote Methode Invocation (RMI) in Java Unterstützt werden Webservices beispielsweise in Microsoft .NET, Microsoft COM, Sun
One, Oracle .Now, IBM Websphere und HP Netaction.
• Remote Function Call (RFC) in SAP Durch die Verwendung des SOAP-Standards sind Webservices plattformübergreifend.
Ein mit Java geschriebenes Webservice, das unter IBM Websphere betrieben wird, kann
• Distributed COM von Microsoft (basiert auf DCE RPC)
von einer Windows-Anwendung genutzt werden, die mit Visual Basic .NET erstellt wurde.
29 Regeln zum Codieren/Decodieren von Objekten in XML Genauso kann ein Java-Applet ein in C# entwickeltes Webservice nutzen, das auf einem IIS
30 International Organisation of Standardization läuft.
84 6 SIMPLE OBJECT ACCESS PROTOCOL (SOAP) 6.4 Webservices 85

6.4.1 Web Service Describtion Language (WSDL) • [Link]

Die Web Service Description Language (WSDL) ist eine XML-Sprache zur formalen Be- • [Link]
schreibung eines Webservices. Ein WSDL-Dokument wird von einem Webservice bereitge-
stellt, damit ein Client weiß, wie man das Webservice benutzen kann.
WSDL ist beim W3C, momentan in Version 1.1, standardisiert [W3Cwsdl]. 6.4.3 Sicherheit
Die genaue Struktur eines WSDL-Dokuments kann sehr komplex werden. Normalerweise Da eine SOAP-Anfrage auf HTTP beruht, können für HTTP alle vorhandenen Sicher-
wird aber die WSDL-Beschreibung automatisch von der Entwicklungsumgebung erstellt, sei heitsprotokolle und -mechanismen wie zum Beispiel SSL eingesetzt werden, um den SOAP-
es vom Visual Studio .Net unter Windows oder Kylx von Borland unter Linux. Datenaustausch zu sichern.

6.4.2 Universial Description, Discovery and Integration (UDDI)

UDDI (Universial Description, Discovery and Integration) ist ein Suchdienst für Webser-
vices. UDDI speichert Daten über den Dienst und den Dienstanbieter. Das Ergebnis einer
Suchanfrage ist ein Link zu einem DISCO-31 - oder einem WSDL-Document.

Abbildung 41: Webservices via HTTP mit SSL

Als speziellen Sicherungsmechanismus für Webservices gibt es auch noch von Microsoft
das so genannte WS-Security34 . Dabei können unter Einsatz von digitalen Signaturen und
Zertifikaten wichtige Sicherheitsanforderungen wie Authentifizierung, Integrität und Ver-
traulichkeit sichergestellt werden.

6.4.4 Beispiele
• CERN Webservices35 : Das CERN verwendet Webservices unteranderem zur internen
Verwaltung.
Abbildung 40: UDDI [Schwichtenberg 2002]
• Amazon Web Services API36 : Amazon ermöglicht einerseits das Abfragen von Preisen
und Lieferbeständen und andererseits das Verwalten des eigenen Angebots.
UDDI32 ist ein herstellerübergreifendes Projekt. Es gibt jedoch kein zentrales Verzeich-
nis. Prinzipiell kann jeder ein UDDI-Verzeichnis33 eröffnen. Öffentliche UDDI-Verzeichnisse • Google Web API37 : Google stellt bei Webservices ihre eigenen Such- und Wörterbuch-
gibt es momentan von Microsoft, IBM, Hewlett Packard und SAP. funktionen zur Verfügung.
Neben UDDI gibt es noch einige Websites, die XML-Webservices auflisten:
• HP & IBM online stores: Beispiele von guten e-Commerce-Anbietern mit Zugriff auf
• [Link] Lagerbästanden usw.
31 DISCO (Webservice DISCOvery) beschreibt eine XML-Sprache, um auf WSDL-Dokumente zu verweisen. 34 [Link]

Damit kann man auf einem Webserver ein Verzeichnis aller auf dem Webserver verfügbaren Webservices [Link]
bereitstellen. 35 [Link]
32 [Link] 36 [Link]
33 auch UDDI Business Registry genannt 37 [Link]
86 LITERATURVERZEICHNIS 87

6.5 Zusammenfassung 7 XML-RPC

SOAP ist als XML-basiertes Messaging-Protokoll für den Austausch von strukturierten In- Das Internet war ursprüngliche eine Mensch-zu-Mensch Kommunikationsplattform, bei der
formationen zwischen Peers in einer dezentralisierten, verteilten Umgebung besonders gut z.B. Menschen über eine Website Information für andere Menschen zur Verfügung stell-
geeignet. In der Praxis wird es meist in Zusammenhang mit Webservices verwendet, weil die- ten. Inzwischen wird das Internet aber auch zur Kommunikation zwischen Computern in
se genau die oben genannten Ansprüche an das Protokoll stellen und durch die encoding-rules verteilten Sytemen verwendet. Eine spezielle Variante, nämlich Prozeduraufrufe auf einem
Objekte plattformunabhängig ausgetauscht werden können. Im Laufe unserer Nachforschun- entfernten System mittels XML wird im Folgenden genauer untersucht.
gen hat sich herausgestellt, daß es für alle gängigen Programmiersprachen bzw. Plattformen
Bibliotheken für die Verwendung von Webservices (SOAP) gibt (siehe Abschnitt 6.6). Albert Norman: norman@[Link]

Florian Plank: fplank@[Link]

Literaturverzeichnis
[W3Csoap] Simple Object Access Protocol (SOAP) 1.1, W3C Technical Report; 8. Mai 7.1 Einleitung
2000. In jedem Computer werden unzählige Prozeduren aufgerufen, wenn man Tasten drückt,
[W3Cwsdl] Web Services Description Language (WSDL) 1.1, W3C Technical Report; 15. die Maus bewegt, usw. Bei Remote Procedure Calls (RPC) werden solche Prozeduren
März 2001. von einem Rechner auf einem entfe rnten, über Netzwerk verbundenen, Rechner ausgeführt.
Prozeduraufrufe erfolgen also nicht innerhalb eines Computers, sondern zwischen Computern
[W3Cschool] SOAP Tutorial, W3C Schools oder sogar zwischen verschiedenen Applikationen, die auf diesen Rechnern laufen. Bei XML-
PRC handelt es sich um RPCs, bei denen die Daten in Extensible Markup Language (XML)
[Snell 2002] Snell, J.; Tidwell, D.; Kulchenko, P.: Webservice-Programmierung mit SOAP ; formatiert werden und über das Hypertext Transfer Protocol (HTTP) versendet werden.
Juli 2002.
[Connel 2002] Connel, J.: Visual Basic .NET verstehen und anwenden; 2002, Microsoft 7.2 XML-RPC Allgemein
Press.
Zuerst soll hier ein Einblick gegeben werden, was XML-RPC überhaupt ist, allgemeine Ei-
[Schwichtenberg 2002] Schwichtenberg, H.: Microsoft [Link] - Das Entwicklerhandbuch; genschaften beschrieben werden, um später dann auf die Details von XML-RPC einzugehen.
2002, Microsoft Press.
7.2.1 Was ist XML-RPC?
6.6 Links Angenommen es soll eine Prozedur auf einem entfernten Rechner ausgeführt werden, dann
6.6.1 PHP müsste sich der Entwickler beim Programmentwurf auch sehr intensiv mit den Gegeben-
heiten auf dem anderen System und den verschiedenen Eigenschaften des Netzwerks usw.
• NuSOAP beschäftigen. Mit RPC kann diese Mühe erspart bleiben, denn damit wird für jede Maschine
[Link] ein Interface zur Verfügung gestellt und man braucht nur die entsprechenden Funktionen
• Professional Open Source Web Services, Onlinekapitel dieses RPC-Interfaces aufrufen, ohne sich um irgendwelche Eigenschaften des Netzwerks
[Link] [Link] oder des anderen Systems zu kümmern.
Das Internet, ursprünglich zur Mensch-Mensch Kommunikation verwendet, entwickelt
sich über Mensch-Maschine Kommunikation immer mehr auch zu Maschine-Maschine Kom-
6.6.2 JAVA - Web Services Developer Pack 1.3
munikation. In dieser Entwicklung entstand aus der Hypertext Markup Language (HTML)
• The Java Web Services Tutorial for JWSDP v1.3, XML38 . XML ist viel flexibler und ermöglicht es auch Informationen nicht nur für Menschen
[Link] sondern auch für Computer aufzubereiten. XML erlaubt es eigene Tags zu definieren und
genau diese Eigenschaft macht sich XML-RPC zu Nutzen. Da XML per HTTP übertragen
• Java Technology and Web Services, wird, wird hier eine bereits bestehende Infrastruktur genützt. Dabei baut HTTP selbst auf
[Link] RPC auf. XML-RPC ermöglicht dabei nicht nur Client-Server Kommunikation, wie durch
das Internet gegeben, sondern auch Peer-to-Peer Kommunikation.

7.2.2 Besonderheiten und Vorteile von XML-RPC

Wenn man verschiedene Computer-Systeme verbinden möchte, aber keine komplexen Daten
direkt auszutauschen hat, dann erweist sich XML-RPC als exzellentes Tool um Verbindun-
gen herzustellen. Ein offensichtlicher Anwendungsbereich ist die Verbindung verschiedener
38 Die Entwicklung erfolgte nicht direkt, sondern XML ist eigentlich aus SGML hervorgegangen und wurde

entwickelt, da man mit HTML an seine Grenzen gekommen ist.(siehe auch W3C ([Link])39 )
88 7 XML-RPC 7.3 XML-RPC vs. andere Protokolle 89

Systeme, die es erlaubt Java mit Perl, Perl mit Python, Python mit ASP usw. zu kommu- handhaben ist, wurde es nicht wirklich für große Leistungen entworfen. Weiters gibt es das
nizieren. XML-RPC stellt somit eine Möglichkeit dar, um Informationen über ein standard Problem, dass die Adresse des XML-RPC-Services nicht von einem normalen Webservice
Vokabular auszutauschen. XML-RPC bietet auch einen Vorteil, wenn man etwa ein Service unterscheidbar ist. Und es ist nicht definiert, wie etwa der XML-RPC-Server auf einen GET
zur Verfügung stellen möchte, aber nicht weiß welche Clients zu unterstützen sind. Request reagieren soll.
Hier sei auch ein kleiner Überblick zumindest über die bekanntesten Implementationen Ein wesentlicher Aspekt von XML-RPC ist auch die Sicherheit, denn damit wird es nun
gegeben: möglich gängige Sicherheitsregeln zu durchbrechen (z.B. ist es dadurch möglich Firewalls zu
umgehen). XML-RPC bietet also wenig Sicherheit und stellt somit eine neue Gefahr dar,
• Java wenn es darum geht, bestimmte Bereiche eines Netzwerks zu schützen. Zu einem gewissen
• PHP Grad kann man diese Gefahr beschränken, indem man z.B. in einem lokalen Netzwerk, keine
Anfragen von außen zulässt, sondern nur auf Anfragen innerhalb des Netzwerks antwortet.
• C/C++ Eine andere Möglichkeit wäre etwa Username und Passwort-Parameter zu übergeben, die
natürlich auch codiert und decodiert werden müssen, Oder auch die HTTP-Verbindung
• Perl mittels SSL zu verschlüsseln. Aufgrund dieser Probleme ist also diese Technologie nicht
• ASP unumstritten.

• Python ([Link])40 7.3 XML-RPC vs. andere Protokolle

41
• Tcl ([Link]) XML-RPC ist nicht die einzige Möglichkeit Remote Procedure Calls auszuführen. Dabei
seien vor allem CORBA, DCOM und SOAP (Simple Object Access Protocol) erwähnt.
• Lisp ([Link]/support/[Link])42 CORBA ist ein Protokoll für verteilte, objektorientierte Applikationen. Es bietet den
• Rebol ([Link])43 Vorteil, dass es gut mit Java, C++ und anderen Sprachen arbeitet. Es lassen sich damit
auch gute APIs entwickeln. Ein Nachteil ist jedoch, dass es sehr schwer zu lernen ist und
• Microsoft .NET auch viel Entwicklungsaufwand erfordert. CORBA ist also eher für Firmen- und Deskto-
papplikationen als für Webapplikationen geeignet.
• Macintosh OS X SOAP ist aus XML-RPC hervorgegangen, wurde mit weiteren Feartures ausgestattet
• Flash und wurde damit viel komplexer, aber auch vielseitiger, da das Anwendungsgebiet über
RPC hinausreicht.
• Internet Explorer

• Mozilla
7.4 Details des XML-RPC Protokolls
44 Dieses Kapitel beschäftigt sich mit dem XML-RPC Protokoll, also der Struktur und Abfolge
• und einige mehr [Link] .
von Anfragen und Antworten, um auf einer entfernten Maschine Prozeduren mittels XML
Davon sind sicher die ersten paar Implementationen die populärsten. und HTTP aufzurufen.

7.2.3 Probleme/Nachteile 7.4.1 Datenaustausch

Obwohl RPC und Tunneling über HTTP brauchbare Technologien sind, sollte man auch Wenn ein XML-RPC Aufruf zwischen dem Client (aufrufender Prozess) und dem Server
Aspekte der Skalierbarkeit und der Sicherheit betrachten und beurteilen ob XML-RPC die (aufgerufener Prozess) durchgeführt wird, läuft das folgendermaßen ab:
passende Technologie für ein bestimmtes Problem ist. • Das Client-Programm macht einen Prozeduraufruf durch den XML-RPC-Client und
RPC Architekturen haben natürliche Einschränkungen. Es gibt jedoch genug Fälle wo übergibt dabei Methodenname, Parameter und Zielserver
RPC angemessen ist und auch welche, die bei Kombinierung von Logik und Daten sehr kom-
plex oder riskant werden können, und unnötigen Aufwand darstellen. Außerdem bringt es • Der XML-RPC-Client nimmt diese Daten, verpackt sie in ein XML-File und verschickt
eine Einschränkung mit sich, da die Nachrichten nicht beliebig übertragen werden können, sie mit dem HTTP POST Request an den Server
sondern an gewisse Prozeduren gebunden sind, die eine bestimmte Zahl von Parametern
• Der HTTP-Server empfängt den POST Request und gibt das XML-File an den XML-
benötigt. Prozeduraufrufe bringen also bedeutende Einschränkungen für Entwicklung, Fle-
RPC Listener weiter. Dieser analysiert das File mit einem Parser, erhält daraus den
xibilität und Wartung.
Prozedurnamen, Parameter usw. und ruft die entsprechende Methode mit den richti-
Da HTTP ursprünglich zur Übertragung von Webseiten entworfen wurde gibt es daher
gen Parametern auf
einige Einschränkungen bei der Benützung für verteilte Systeme. Obwohl HTTP einfach zu
40 [Link] • Der Rückgabewert wird dann wiederum in ein entsprechendes XML-File gepackt und
41 [Link] als Antwort des POST Requests an den Client zurückgeschickt
42 [Link]
43 [Link] • Dieser parst ebenfalls das XML-File um den Rückgabewert der Funktion zu erhalten,
44 [Link] und gibt ihn an das Client Programm zurück.
90 7 XML-RPC 7.4 Details des XML-RPC Protokolls 91

Ein kurzer Exkurs zum Parser: Für XML gibt es vorallem zwei verschiedene Typen von <value><dateTime.iso8601>YYYYMMDDTHH:MM:SS
Parsern: </dateTime.iso8601></value>

• Der erste wäre der SAX-Parser (Simple API for XML). Er ist eventbasiert und liest
Binärdarstellung: XML verbietet eine Darstellung der sog. Steuerzeichen. Wie kann man
das File zeilenweise ein. [Link].org45
also Daten, die solche Zeichen enthalten (Binärfiles), übertragen? Dazu verwendet
• Der andere ist der DOM-Parser (Document Object Model). Dieser Parser liest zuerst XML-RPC die base-64 Codierung (siehe RFC 2045), wie sie in Internetapplikationen
das ganze File ein und erstellt dann einen Baum der Dokumentstruktur. [Link]/DOM46 weit verbreitet ist (z.B: Email-Attachments).

Auf eine XML-RPC Anfrage folgt genau eine Antwort. Die Antwort ist also synchron <value><base64>s</base64></value>
zur Anfrage. Der Grund dafür ist, dass die Antwort auf der selben HTTP-Verbindung wie
die Anfrage zurückkommen muss. Außerdem wird das Client Programm “geblockt”, bis es
eine Antwort bekommt, was natürlich Auswirkungen auf den Programmentwurf hat. Array: Ein <array> beinhaltet ein einziges <data> Element, welches wiederum eine va-
HTTP ist von sich aus eine stateless47 [STATE] Technologie und XML-RPC erbt diese riable Anzahl von <value> Elementen beinhalten kann. Die einzelnen Elemente ei-
Eigenschaft. Wenn nun also das Client Programm eine Funktion zweimal hintereinander nes Arrays können auch durchaus verschiedenen Typs sein und es ist auch möglich
aufruft, so können die Aufrufe von XML-RPC nur als zwei unabhängige Ereignisse behandelt mehrdimensionale Arrays zu definieren, einfach durch Verschachtelung von mehreren
werden. Es gibt aber durchaus Fälle wo ein Status von Vorteil wäre, etwa wenn ein Request einfachen Arrays.
ein Objekt erzeugt und spätere Anfragen dieses Objekt verändern wollen. Eine Lösung
wäre beispielsweise, einen Status serverseitig zu speichern und Identifiers in Cookies, um <value>
dem Server mittzuteilen, dass es sich um eine Fortsetzung einer Session handelt. <array>
<data>
7.4.2 Datentypen <value> ein XML-RPC Wert </value>
...
XML-RPC ist normalen Prozeduraufrufen sehr ähnlich, jedoch sind die Parameter in XML- <value> ein XML-RPC Wert </value>
Form gegeben. Ein Datenelement wird dabei in einem </data>
<value> ... </value> Bereich dargestellt. Es gibt eine Menge von einfachen Datenty- </array>
pen, mit denen auch komplexere Datentypen definiert werden können. </value>

Einfache Datentypen
Strukturen: Eine Struktur (<struct>) beinhaltet eine Anzahl von
Ganzzahlen: 32-bit, signed Integer XML Darstellung: <member> Unterelementen, wobei jedes <member> Element ein <name> und ein <value>
<value><i4>n</i4></value> oder <value><int>n</int></value> Element beinhaltet. Strukturen können rekursiv aufgebaut sein, d.h. jedes <value>
Element kann wiederum ein Element des Typs <struct> oder jedes anderen Typs
Fließkommazahlen: Gleitkommazahl doppelter Genauigkeit (64bit), signed beinhalten.

<value><double>n</double></value>
<value>
<struct>
Boolsche Werte: <value><boolean>b</boolean></value>
<member>
Strings: Grundsätzlich eine ASCII Zeichenkette, allerdings muss man vorsichtig sein, wenn <name> Name_1 </name>
verschiedene Systeme verschiedene Codierungen verwenden. XML-Format entweder <value> Wert_1 </value>
ohne oder auch mit expliziter Typangabe. Sonderzeichen müssen entsprechend den </member>
XML-Definitionen geschrieben werden, also z.B: für &amp; für &. ...
<member>
<value>s</value> <name> Name_N </name>
<value><string>s</string></value> oder <value> Wert_N </value>
</member>
Datums-/Zeitangaben: FÜr Datums- und Zeitangaben wird der Typ dateTime.iso8601 </struct>
verwendet. Für XML-RPC wird eine bestimmte Darstellung des ISO8601 Standards </value>
verwendet:
45 [Link] 7.4.3 Formate
46 [Link]
47 d.h. weder Client noch Server wissen was in früheren Verbindungen passierte, da jede Anfrage völlig XML-RPC bedient sich also der Sprache XML, um die Daten in einer in einer standardisier-
neu ist ten Form zu senden. Dadurch wird ja die Systemunabhängige Kommunikation ermöglicht.
92 7 XML-RPC 7.5 Zusammenfassung 93

Request Format XML-RPC definiert einen HTTP und XML Request, der zu einem <member>
Server gesendet wird um am Server Prozeduren auszuführen. Dabei besteht ein Request aus <name>faultString</name>
einem HTTP-Header und einer XML-Payload. <value><string>No such method.</string></value>
Der XML-Teil hält den Namen der aufzurufenden Methode und die dazugehörigen Pa- </member>
rameter. Dabei muss dieser Teil nach folgendem Schema gebildet sein: </struct>
</value>
<?xml version="1.0"?> </fault>
<methodCall> </methodResponse>
<methodName>print</methodName>
<params> Wie zu sehen besteht die Fehlermeldung aus einem Fehlercode und einem lesbaren String.
<param> Der Fehlercode ist jedoch nicht standardisiert und hängt von der Implementation ab.
<value><string>Hello, World!</string></value> Der HTTP-Teil:
</param> HTTP/1.1 200 OK
</params> Date: Sun, 29 Apr 2001 [Link] GMT
</methodCall> Server: Apache/1.3.12 (Unix) Debian/GNU PHP/4.0.2
Connection: close
Der HTTP-Header hat folgendes Schema und benötigt zumindest diese Einträge. Op- Content-Type: text/xml
tional können noch weitere, eigene Headereinträge hinzugefügt werden. Content-Length: 818
POST /[Link] HTTP/1.0 Der HTTP response Code muss immer 200 OK sein. Der XML-RPC Client sollte aber
User-Agent: PHP XMLRPC 1.0 auch andere Fehlercodes behandeln können, denn es kann auch durchaus vorkommen, dass
Host: [Link] ein 404 Not Found o.ä. vom Server zurückkommt. Der Server Header ist äquivalent zu
Content-Type: text/xml User-Agent und gibt die Software an mit der der Client kommuniziert. Die Content-Length
Content-Length: 216 ist unbedingt erforderlich und impliziert, dass die gesamte Antwort zuerst vollständig gene-
riert werden muss, bevor sie verschickt werden kann.
Response Format Einem XML-RPC Request folgt auch eine Antwort vom Server, in der
das Ergebnis des Prozeduraufrufs zurückgeschickt wird, oder eine Fehlermeldung im Fall, 7.5 Zusammenfassung
dass etwas nicht korrekt funktioniert hat. Auch die Antwort besteht wieder aus einem XML
und einem HTTP-Teil und ist wie zu erwarten ähnlich einem Request. XML-RPC ist also sozusagen ein Mittel um Prozeduren auf entfernten Systemen auszuführen.
Dabei werden die Daten in einer standardisierten Form (XML) übertragen. Das standar-
<?xml version="1.0"?> disierte Datenformat bietet den großen Vorteil der Systemunabhängigkeit, zwischen den
<methodResponse> beiden Computern.
<params> Dadurch dass XML-RPC eine Funktionseinheit von SOAP ist, wird die Entwicklung
<param> hin zu SOAP gehen. Da Webservices und weitere Anwendungen auch andere Aufgaben in
<value><string>London</string></value> verteilten Systemen wahrnehmen sollen, außer Funktionsaufrufen, wird der Entwickler zu
</param> SOAP greifen und sich damit die Remote Procedure Calls gleich mit erschließen. Vielleicht
</params> wird XML-RPC eine Nische besetzten, dort wo es nur auf RPC ankommt. Dort kann XML-
</methodResponse> RPC jedoch durch seine einfachen und klaren Strukturen seine Stärke voll ausspielen.

Ein kleines Problem ergibt sich aber für Prozeduren, die keinen Rückgabewert haben,
denn der <param> muss angegeben werden. Das lässt sich aber leicht lösen indem man Literaturverzeichnis
z.B. eine Bool-Variable für den Erfolg, sonst eine beliebige Variable oder den nil Wert.
Um Fehlerbehandlung zu ermöglichen werden auch die Fehler in einem eigenen Format [LJD 2001] Simon [Link], Joe Johnston, Edd Dumbill: Programming Web Services
zurückgeschickt. with XML-RPC, O’Reilly (2001).

<?xml version="1.0"?> [KIDD 2001] Eric Kidd: XML-RPC Howto, Eric Kidd (2001).
<methodResponse> [PARSER] [Link]
<fault>
<value> [IMPL] [Link]
<struct> [STATE] [Link]
<member>
<name>faultCode</name> [SEC] [Link]
<value><int>3</int></value> [MWAL 2001] [Link]
</member>
94 8 PERSONAL FIREWALLS 8.2 Was sind PFWs? 95

8 Personal Firewalls – Maildienste,

In diesem Artikel werden Personal Firewalls, deren Funktionsweise und Ziele behandelt. Der – Remote Access Dinste,
Einsatz von PFWs auf Windowssystemen wird besonders betrachtet. – Simple Trojaner,
Dogan Gecici: bilgi@[Link] – Backdoors,
– Zombies und
8.1 Einführung
– Bots.
Ziel dieses Artikels ist ein Uberblick auf die Personal Firewalls zu geben. Zuerst werden
die PFWs definiert und es wird gezeigt was sie können bzw. nicht können. Es folgt dann
die Aufzählung potentieller Gefahren für den Privatuser im Netzwerkverkehr. Welche Ge- Abbildung 42 zeigt Schutzmöglichkeiten für einen Privatuser oder ein lokales Netz.
genmassnahmen gegen diesen Gefahren die PFWs setzen wird ebenfalls erläutert. Damit
soll gezeigt werden wie Personal Firewalls funktionieren und welche Mechanismen sie haben
sollten. Zum Schluss wird einiges über Sicherheit der Windowssysteme erzählt und einige
populäre PFWs vorgestellt.

8.2 Was sind PFWs?

Personal Firewalls sind ein Oberbegriff für Produkte verschiedener Hersteller mit denen
der Einzelanwender (die Einzelanwenderin) den Netzwerkverkehr auf seinem PC beschränken
und kontrollieren kann. Sie fungieren wie eine Schranke zwischen dem zu schützenden priva-
ten PC und unsicheren Internet. Durch den Einsatz der Personal Firewalls (PFW) sollte also
der PC gegenüber den möglichen Gefahren im Netzwerk besser geschützt werden. PFWs
sind also für den Einsatz auf Desktop-PC und Notebooks konzipiert.
Eine PFW kann auf Hardware oder Software basieren. Eine Hardware PFW ist in den
meisten Fällen die beste Lösung, ist aber zu teuer (einige Tausend Euro!), komplex und
nicht Benutzer- freundlich. Software basierte PFWs sind hingegen sehr kostengünstig und
Abbildung 42: Schutzmöglichkeit durch Firewalls
Benutzer-freundlich. Die meisten PFWs sind daher Software basierte Lösungen.
PFWs bestehen meist aus Paketfiltern für Ports und Schutzfunktionen vor Cookies, Ap-
plets und ActiveX-Elementen. Es gibt Versionen für den Einzelnen oder für Unternehmen.
Die für den Einzeluser sind eher zum Einsatz auf dem Heim PC konzipiert, welche ko-
stengünstig sogar freeware sind und vom Benutzer selbst verwaltet werden. Diejenigen für 8.2.2 Wogegen können PFWs nicht schützen
Unternehmen oder Institutionen werden zusätzlich zum zentralen Firewall System auf einem
Arbeitsplatzrechner eingesetzt. Sie werden dann von einem zentralen Security Management Eine PFW bietet keinen Schutz vor:
System unternehmensweit einheitlich gesteuert. In [Fritsch et al 2003] wird die Absiche-
rung des Netzwerks (Firewall) eines fiktiven mittelständischen Unternehmens vordergründig • Angriffen von innen wie z.B.:
behandelt.
• Viren,
8.2.1 Wogegen können PFWs schützen
• Trojanern,
Eine PFW kann gegen folgende Angriffe schützen:

• Netzwerkbasierte Angriffe wie: • Angriffe, die mittels erlaubtem Netzwerkverkehr kommunizieren wie

– Portscans, – Email,
– Exploits von Software und – HTTP und
– Denial of Service (DoS)-Attacken.
– sonstige explizit erlaubte Dienste.
• Zugriff auf Rechnerressourcen, die freigegeben sind wie z.B.:
• Angriffen aus einem vertrauenswürdigen lokalen Netz, Intranet und
– Dateien,
– Drucker, • Angriffen auf die Firewall selbt.
96 8 PERSONAL FIREWALLS 8.3 Typische Gefahren für den Einzelnen im Internet 97

8.3 Typische Gefahren für den Einzelnen im Internet

Es gibt folgende typische Angriffswahrscheinlichkeiten gegen einen Privatnutzer im Netz-
werkverkehr, d.h. im Internet:

Diebstahl von Daten: Es gibt viele Dienste, die in der Standardinstallation einem an-
onymen Benutzer zu viele Rechte geben. Als Beispiel kann man hier die Dateien und
Druckerfreigabe unter Windows 9x erwähnen. Wenn dieser Dienst aktiviert ist, was
bei der Standardinstallation der Fall ist, so kann jeder Benutzer im Netz unlimitiert auf Abbildung 43: Port Blocking
die Ressourcen zugreifen. Durch fehlerhaft konfigurierte Dienste wie NetBios, FTP,
http, etc. kann also der Angreifer sein Unheil anrichten.

DoS Attacken: Eine Arbeitsstation kann auch im Netz direktes Opfer einer DoS Attacke
werden. Allerdings ist ein wirkungsvoller Schutz vor DoS Attacken bei Clientsystemen
keine zu wichtige Anforderung für eine PFW.

Spyware: Schutz der Privatspäre. Durch Installieren und Verwenden von manchen Share-
bzw. Freewaresoftware wird dem Benutzer verschiedene Programme oder Werbungen
eingeblendet. Es wird dabei persönliche Daten des Benutzer gesammelt, z.B. durch
Werbeclient. Abbildung 44: Port Hiding

Malware: Malware ist ein Überbegriff für Viren, Würmer und Trojaner. Programme also,
die sich verbreiten und dem Computer oftmals auch Schaden zufügen.
Ungewolltes Senden von Daten ins Internet: Durch Software zur Kontrolle der Netz-
Überprüfung von Dateninhalten: Damit wir schon im vorhinein die Gefahr minimieren werkaktivität auf TCP/IP API Ebene kann verhindert werden, dass User Daten un-
können, Malware, oder andere schädliche Software (gefährliche ActiveX Controls, Ja- gewollt ins Internet mittels Würmen, Sypware, kommerziellen Datensammlern etc.
vaApplets, etc) auf unsere Arbeitsstation zu laden, benötigen wir ein System, welches gesendet werden. Dieser Mechanismus ist bekannt als Application/Desktop Firewall.
alle eingehenden Daten analysiert. Man unterscheidet bei Firewalls grundsätzlich zwischen folgenden Architekturen bzw.
Technologien: Firewalls auf der Transport- und Netzwerkschicht findet man in der
Benachrichtigung bei unberechtigten Zugriffen: Wenn unsere Arbeitsstation doch ein- Regel bei Firewalls, welche ganze Netzwerke schützen. Sie lassen sich auch sehr gut
mal Opfer einer gezielten Attacke wird, dann wäre es wünschenswert, wenn wir über als Hardware Produkte realisieren. Die Application / Desktop Firewall schaltet sich
dies informiert würden. Denkbar wäre eine Vorrichtung, welche den Benutzer bei- direct in den TCP/IP Stack des Betriebssystemes ein und überwacht von dort den
spielsweise benachrichtigt, wenn jemand eine Portscan auf den Rechner macht oder gesammten TCP/IP Verkehr.
Verbindung zu verdächtigen Diensten aufzubauen versucht (NetBios, Samba, o.ä) In der untenstehenden Tabelle sind diese Firewall-Ebenen zusammengefasst.

8.3.1 Schutzmechanismen einer PFW Application Application Level Proxies Application Spesific
Inspection, Proxy
Hier werden die Gegenmassnahmen gegen die oben gezeigten potentiellen Gefahren disku- (GET, PUT, OPEN)
tiert. Es geht also um Ziele bzw. Schutzmechanismen, die eine PFw haben sollte. Transport Circuit Level Proxes Stateful Inspection
(SYN, ACK)
Diebstahl von Daten: Wir können uns gegen Datenklau schützen, in dem wir verhindern,
Network Packet Filter Secure Router
dass unser System auf Fragen aus dem Internet keine ungewollten Antworten gibt.
(Screening Router)
Durch einen sog. Port Blocking bzw. Port Hiding Mechanismus kann dies realisiert
werden.
In [Chirillo 2002] findet man Implementierungen zu all diesen hier besprochenen The-
Ein Port Blocker schliesst alle Ports, welche von Internet her nicht verwendet werden men.
dürfen. Will ein Client also ein Request aus dem Internet machen, so antwortet die
Arbeitsstation mit einer Meldung, dass dies nicht erlaubt ist. Abbildung 43 zeigt dieses Durchsuchung der eingehenden Daten: Durch ein Content Screening System können
Prinzip. die eingehenden Daten auf Viren, Trojaner und Würmer untersucht werden. Ein Con-
tent Screening System durchsucht alle eingehenden Inhalte und blockiert den Zugriff
Ein Port Hider ist eine Möglichkeit die Sicherheit noch mehr zu erhöhen. Kommt eine oder entfernt diese falls gefährliche Inhalte entdeckt werden.
Anfrage aus den Internet, so antwortet die Arbeitsstation erst gar nicht. Dadurch kann
die Arbeitsstation bei einem Subnet Scan nicht erkannt werden. Folgende Abbildung Einbruchsmeldung: Ein Alerting System überwacht den Netzwerkverkehr nach verdächti-
44 veranschaulicht dies. gen Aktivitäten. Wird zum Beispiel ein Portscan auf das System durchgeführt, dann
98 8 PERSONAL FIREWALLS 8.4 Personal Firewalls und Windows 99

alarmiert das Alerting System den Benutzer und blockt idealerweise für eine gewisse • eSafe Desctop (Aladdin) [Link].com51
Zeit die Netzwerkzugriffe des potentiellen Angreifers.
• MS Windows XP PFW

8.4 Personal Firewalls und Windows Kommerzielle: Es folgt die Aufzählung einiger kommerziellen PFWs sowie deren Websites.
Folgend sind einige Kritikpunkte aufgeführt:
• Blackice Defender [Link].com52
Fehler im Betriebssystem: In jedem guten Dokument über Firewalling ist nachzulesen, • Norton Internet Security [Link].com53
dass ein Firewallsystem grundsätzlich so schlank wie möglich programmiert werden
soll. Keine überflüssigen Features und keine unnötigen Dienste, denn je mehr Zeilen • McAfee Firewall [Link].com54
Programmcode, desto eher schleichen sich Fehler ein. Dieser Grundsatz wird spätesten • PGP7 Firewall [Link].com55
beim Einsatz von PC-Firewalls auf einem Windowssystem problematisch: Windows
ist ein Betriebssystem, das auf einer schwachen Sicherheitsarchitektur aufbaut und Windows XP Firewall: An dieser Stelle werden wichtige Features von MS Windows XP
einen unstabilen TCP/IP-Stack zu nutzen pflegt. Daher sind die meisten PFWs für PFW aufgeführt.
Windowssysteme nicht gerade schlank. Zwar wird die Messlatte der Sicherheit durch
das Nutzen einer Software-Firewall etwas erhöht, aber niemals können grundlegende • Standard Windows Hilfe.
Fehler des Betriebssystems von vornherein ausgeschlossen und nachträglich behoben
werden. • Bedienungsfreundlichkeit:

Konfigurationsfehler: Die Sicherheit kann zwar durch das Nutzen einer Personal Firewall – keine vordefinierten Regelsets,
ein bisschen erhöht werden, doch sind wir eigentlich schon beim nächsten Punkt der – nicht zu einsteigerfreundlich,
Kritik angelangt: Ein Grossteil der Windowsanwender benutzt den Computer für die – Regeln können nur auf Protokollebene gesetzt werden.
alltägliche Arbeit. Nur die wenigsten kennen sich mit der Systemarchitektur oder Netz-
werken aus. Dementsprechend werden nur wenige Nutzer die TCP/IP-Fragestellung • Sicherheit:
in der Firewall-Software korrekt beantworten und die Meldungen und Logfiles richtig – in der Standardinstallation deaktiviert,
deuten können.
– keine Applikationsbasierenden Regeln.
Programmier-Fehler: Man sollte jedoch nicht ausser Acht lassen, dass auch diverse Software- • Direkt im Betriebsystem integriert.
Firewalls direkte Mängel aufweisen, die von einem Angreifer zum eigenen Vorteil aus-
genutzt werden können. Folgend ein historisches Beispiel: Die PC-FirewallZoneAlarm TINY Personal Firewall: Hier die wichtigsten Eigenschaften des Tiny Personal Fire-
von ZoneLabs in der Version 2.1.10 wies einen markanten Mangel auf: Es werden walls. Somit kann man die Features zwei verschiedener Produkte leicht vergleichen.
grundsätzlich keine Anfragen auf Ports protokolliert, die standartmässig vom Kernel
in Anspruch genommen werden. Somit wird das Portscannen einer durch ZoneAlarm • Keine Hilfe. Es gibt aber ein Online User Forum
geschützten Maschine nicht erkannt, wenn zum Beispiel als Source-PortUDP67 (DH-
CP) gewählt wurde: Die Desktop-Firewall lässt das Paket ohne weiteres passieren, • Bedienungsfreundlichkeit:
und informiert keineswegs den User darüber. Bei den neueren Versionen wurde dieser – Für den Anfänger eher schwierig zu bedienen, sehr viele Einstellmöglichkei-
Bug beseitigt. In [Check für Windowssicherheit] wird ausfühlich beschrieben, wie man ten.
die Sicherheit von Windows xp erhöhehn kann.
– keine vordefinierten Regelsets.
8.4.1 Bekannte Personal Firewalls • Sicherheit:
Hier werden einige populäre PFWs deren Namen und Internetadressen angegeben. Stellver- – Ultimative Kontrolle über alle Protokolle,
tretend wollen wir Windows XP FW und Tiny PFW etwas ausführlicher vorstellen. Angaben – NetBios Regelset wird beim ersten Gebrauch erstellt,
basieren auf Herstellerangaben sowie diversen Internetseiten und PC Magazinen.
– Alle Filtermöglichkeiten sowohl auf Applikations als auch auf Protokoll Ebene
Freeware: Unten sind einige bekannte Personal Firewalls und deren Internetadresen ange- • Remote Administration
geben.
• MD5 Hash für Applikationen
• Tiny Personal Firewall [Link].com48
• Ausführliches Status Fenster
• SyGate Personal Firewall [Link].com49
51 [Link]
• Zone Alarm [Link].com50 52 [Link]
48 [Link] 53 [Link]
49 [Link] 54 [Link]
50 [Link] 55 [Link]
100 LITERATURVERZEICHNIS 101

8.4.2 Zusammenfassung 9 Internet Firewalls

Durch eine PFW kann man eine zusätzliche Sicherheit erreichen. Es gibt allerdings auch Sicherheit im Umgang mit dem Internet ist ein Thema das Netzwerkadminstratoren schon
Experten, die Gegenteiliger Meinung sind. Hierfür lese man PFWs Sinn oder Unsinn56 seit langem beschäftigt. Einerseits müssen sie den Mitarbeitern Zugang zum Internet erlau-
oder Sinn oder Unsinn57 . Eine sichere und angemessene Installation und Konfiguration des ben, jedoch gleichzeitig diesen so gut wie möglich nach außen (und auch innen) absichern.
Betriebssystems ist auf jeden Fall sehr wichtig und bingt sicher mehr Sicherheit. Hier kurz
Aber auch jede surfende Privatperson kann es sich kaum mehr erlauben, ohne Vorsichts-
Vor- und Nachteile:
maßnahmen durch das World Wide Web zu streifen. Durch schnelle Internetzugänge und
• Vorteile: ungesicherte PCs wird der ideale Nährboden für Hacker und die Ausbreitung von Würmern
und Viren geboten.
– Niedrige Kosten,
Dieser Artikel beschreibt die Risiken im Zusammenhang mit dem Internet und stellt
– Meist für Normal-Anwender zugeschnitten und daher leicht verständlich. Firewalltechniken als Schutz für Netzwerke vor. Der Praxisteil zu diesem Thema wird sich
• Nachteile: mit Portscan Techniken beschäftigen.

– Nicht besonders zuverlässig, da schon alleine das Betriebssystem zu viel Angriffs- Wolfgang Lazian lazian@[Link]
fläche bietet,
– Viele Anwender können aufgrund fehlender TCP/IP-Kentnisse keine korrekten Gunther Laure gunnar2@[Link]
Filter- Regeln setzen und die Protokollierung auswerten,
– Performance-Einbussen auf der Workstation,
9.1 Einführung
– trügerisches Gefühl von Sicherheit
Wenn man von Firewalls spricht, muss man sich zwangsläufig auch mit den generellen Risiken
eines Internetzugangs beschäfigten. Es ist wichtig zu definieren, was man wie schützen
Literaturverzeichnis kann. Eine Firewall kann zwar effektiv gegen gewissen Attacken sein, aber auch vollkommen
wirkungslos gegen eine Unzahl anderer.
[Fritsch et al 2003] Jörg Fritsch, Steffen Gundel: Firewalls Illustriert, ADDISON-WESLEY
Aber was ist an einem Netzwerk zu schützen? Im Allgemeinen spricht man über Schutz
(2003).
von Daten, Ressourcen und Reputation.
[Chirillo 2002] John Chirillo: Hack Attacks DENIED, 2rd Edition, Wiley Publishing (2002).
Daten: Daten haben generell drei Charakteristika die zu schützen sind. Es handelt sich
[Kurose et al 2002] James Kurose, Keith W. Ross: Computer Networking, ADDISON-
hierbei um Geheimhaltung, Integrität und Erreichbarkeit. Man will weder Informa-
WESLEY (2002).
tionen unauthoriserten Personen preisgeben, noch ihnen ermöglichen, deren Inhalt
[Zwicky et al 1995] D. Brent Chapman, Elizabeth D. Zwicky: Building Internet Firewalls, unbemerkt zu änderen. Weiters sollen Daten für Nutzer erreichbar bleiben.
O’REILLY (1995).
Ressourcen: Ein Netzwerk oder nur Computer soll für authorisierte Personen nutzbar sein,
[Kauffels 2003] Dr. Franz-Joachim Kauffels: Lokale Netze, Band 2, 15. Auflage, Mitp Verlag und nur für diese.
(2003).
[CT Magazin] Magazin für Computertechnik: CT Hefte, 13/2003 S. 70 / 22/2002 S. 198 / Reputation: Die Reputation ist in diesem Zusammenhang nicht zu unterschätzen. Einer-
15/2002 S. 144 / 23/2001 S. 174 / 21/2001 S. 152 / 04/2000 S. 224 / 20/2000 S. seits leidet das Renommee eines Unternehmen, wenn erfolgreiche IT-Angriffe bekannt
126 werden, andererseits können Hacker die Accountdaten und somit die virtuelle Identität
einer Person mißbrauchen. Darunter fallen Emails unter falschen Namen, Keditkar-
[Firewall Grundlagen] Tecchannel Firewall Grundlagen: Tecchannel Homepage tenmißbrauch etc.
[Home PC Guide] Home PC PFW Guide: PFW Guide
Angriffe auf Netzwerke können ebenfalls in Kategorien eingeteilt werden.
[Boran Security] Personal Firewalls: Boran Security Homepage
[Austricksen] Wie man PFWs austricksen kann: PFWs austricksen Intrusion: Als Intrusion wird der häufigste Angriff bezeichnet. Die Angreifer versuchen
die Kontrolle über Computer, die sich im lokalen Netzwerk befinden, zu übernehmen.
[Sicherheit von Windows] Die Sicherheit von Windows: Windows und Sicherheit; Ausführ-
liche Informationen über Sicherheit von Windows und Personal Firewalls von Marc Denial of Service: DoS Attacken haben einen anderen Zweck. Der Angreifer versucht
Ruef. nicht Daten zu erhalten oder die Kontrolle zu übernehmen, sondern nur den Computer
[Check für Windowssicherheit] Checklist for Securing Windows XP Systems: XP Securing an der Erfüllung von Aufgaben zu hindern.
Homepage
Information Theft: Dieser Angriff ist verwandt mit Intrusion. Jedoch ist es für Angreifer
56 [Link] hierbei auch möglich zu Daten zu kommen, wenn sie nur den Datenfluß nach der
57 [Link] Firewall beobachten.
102 9 INTERNET FIREWALLS 9.2 Firewall Technologien 103

Um nun sein Netzwerk zu schützen, können Firewalls eingesetzt werden. Aber was genau • Weise das Paket zurück, benachrichtige den Sender.
ist eine Firewall? Und was kann sie zur Sicherheit beitragen? Eine Firewall ist ein Gerät,
das den einzigen Verbindungsweg zwischen einem lokalen Netz und dem Internet darstellt. • Log Informationen über das Paket.
Auf diesem Weg müssen alle Verbindungen von und zum Internet durch die Firewall gehen. • Alarmiere jemanden aufgrund eines Pakets.
Somit kann sie sicher gehen, das der jeweilige Datentransfer erlaubt ist.
Da die die Firewall der einzigen Zugang zum Internet ist, kann sie Filterfunktionen Während also ein gewöhnlicher Router nur nach der Destination Adresse eins Pakets
übernehmen. Zum Beispiel kann nur “sichere” Protokolle erlauben und unsichere blockieren. entscheided, wohin das Paket gesendet werden soll, berücksichtigt ein Packet Filter immer
Weiters kann sie sehr gut und effizient Ereignisse mitloggen. Nach außen hin verdeckt eine auch den Header und den Inhalt der Pakete.
Firewall die Struktur des lokalen Netzes. So ist es für Angreifer nicht möglich gezielte Es gibt Routertypen, die sich zu jedem Paket gewisse Daten merken:
Attacken auf innen liegende Rechner durchzuführen.
Firewalls haben jedoch ihre Grenzen. Sie bieten keinerlei Schutz gegen Insider. Wer sich • Ob das Paket eine Antwort auf ein vorhergehendes Paket ist. (Source - Destination
im lokalen Netz bewegt, kann vollkommen ungehindert agieren. Wenn es internen Rechnern Adresse, Sequence Nummer)
auch möglich ist, andere Routen nach außen zu wählen (zB Modem), ist eine Firewalls • Wie viele Pakete zuletzt vom selben Host gekommen sind.
wirkungslos.
Richtig eingesetzt, sind Firewalls jedoch für die Sicherheit eines Netzwerks unersetzbar. • Ob Pakete identisch sind zu vorhergehenden.

• Ob das Paket komplett ist (oder nicht).

9.2 Firewall Technologien
Packet Filter System mit dieser Eigenschaft werden stateful packet filters genannt.
Im Rahmen von Firewalls spricht man man im Grunde von den zwei verschiedenen Techno- Die Vorteile von Packet Filter Firewalls sind schnell genannt: Sie sind sehr effizient und
logien Packet Filter und Proxy Services. bremsen das Netzwerk kaum aus. Sie sind vielfach anwendbar und ein einziger Paket Filter
kann schon ein relativ großes lokales Netz sichern.
9.2.1 Packet Filter Genauer wird auf Packet Filter im Abschnitt 9.4 eingegangen.
Packet Filter Systeme routen IP Packet zwischen internen und externen Rechnern (wie Rou-
ter). Aber sie haben die Möglichkeit dies selektiv durchzuführen. Nach einem vorgegebenen 9.2.2 Proxy Services
Regelsystem erlauben oder blockieren sie gewisse Protokolle und Pakete. Der Routertyp in Firewall Proxy Services sind verschieden von Packet Filtern. Sie sind im Grunde speziali-
einer Packet Filter Firewall wird als Screening Router (siehe Abbildung 45) bezeichnet. sierte Server Programme, die Anfragen von Clients an Internet Server übernehmen und diese
an den richtigen Server weiterleiten. Auch die Antworten der Server gehen nicht direkt an
den Client, sonderen ebenfalls an den Proxy. Erst dieser leitet die Information an den Client
weiter.

Abbildung 45: Screening Router (aus [Zwickey et al 2000])

Es ist ihm außerdem möglich den body eines IP Packets zu scannen. Das erlaubt es dem
Packet Filter das verwendete Protokol zu überprüfen. Einige DoS Attacken, die auf defekten
IP Paketen basieren, können somit abgefangen werden. Da der Router auch über zumindest
Abbildung 46: Proxy Firewalls (aus [Zwickey et al 2000])
zwei Netzwerkinterfaces verfügt, kann er innere und äußere Pakete unterscheiden.
Ein Packet Filter kann jeden der folgenden Punkte erfüllen:

• Sende das Paket an seine Zieladresse. Client Programme, die mit Proxy Servern arbeiten, müssen diesen unterstützen. Ap-
plikationen, die eine direkte Verbindung zu einem Server erwarten, funktionieren oft über
• Verwerfe das Paket, ohne den Sender zu benachrichtigen. Proxy Server nicht.
104 9 INTERNET FIREWALLS 9.4 Packet Filter Firewalls 105

Auch Proxy Firewalls haben einige Vorteile. Da sie das Protokol einer Applikation ver-
stehen, können sie alle Verbindungen effektiver mitloggen. Es ist ebenfalls recht einfach
Caching Funktionalität einem Proxy hinzuzufügen. Filter von Proxies sind wesentlich ge-
nauer. Es ist möglich Inhalt aus Übertragungen zu filtern. Ein Beispiel dazu wäre Javascript
aus übertragenen HTML Seiten zu entfernen.
Proxy kennen außerdem die Authorisierung auf Benutzerebene. Packet Filter kennen
höchstens die IP Adresse eines Hosts, aber Benutzer können sie nicht unterscheiden.
Da Proxy Server nie direkte Verbindungen zwischen Client und Server zulassen, können
sie ebenfalls fehlerhaften IP Implementationen Schutz bieten. Es wird jedes IP Packet für
den Client im Proxy neu generiert, so dass defekte Pakete aus dem Netz den Client nicht
erreichen.
Ein großer Nachteil ist, das möglicheweise für jeden neuen Service, ein neuer Proxy
Server angeschafft werden muss. Auch die Performance liegt deutlich hinter den Packet
Filtern zurück. Jede Applikation muss auch mit dem Proxy arbeiten können.

9.3 Firewall Architekturen Abbildung 47: Screened Subnet Architecture (aus [Zwickey et al 2000])
Unter Firewall Architekturen versteht man vernünftige Wege Firewall Komponenten unter-
einander zu verbinden. Es gibt verschiedene Architekturen für verschiedene Anwendungs-
zwecke. Netzwerk befindet, können sie nicht den inneren Netzwerk Verkehr sniffen (beobachten).
Dies bietet einen guten Schutz vor gescannten Login Daten.
9.3.1 Single-Box Architekturen Typische Rollen für Bastion Hosts sind alle sicheren Server Anwendungen bis zur Proxy
Funktionalität für das innere Netzwerk.
Single-Box Firewalls bestehen nur aus einer Komponente die als Firewall dient. Dies kann
ein Screening Router oder ein Dual-Homed Host sein. Der Nachteil bei allen Single-Box
Architekturen ist, das nach dem Ausfall der Firewall kein weiterer Schutz für das Netzwerk 9.4 Packet Filter Firewalls
vorhanden ist. Basic Packet Filtering wertet folgende Einträge aus einem IP Paket aus:
Diese Architektur ist in dem Fall angebracht, wenn die lokalen Rechner bereits gut
durch das Betriebssystem geschützt sind (high Host Security, user level authorisation). Die • Die Absenderadresse
unterstützten Protokolle sollten ebenfalls möglichst einfach sein.
Ein Dual-Homed Host ist, im Gegensatz zu einem Screening Router, ein vollständiger • Die Zieladresse
Rechner. Dadurch ist es möglich diesen gleichzeitig als Paket Filter und als Proxy Server
zu verwenden. Natürlich sinkt dadurch die Performance und die Anzahl der Clients, die die • Die Portnummern der Verbindung die zur Datenübertragung verwendet werden.
Firewall ohne Performanceeinbußen schützen kann.
Einfache Systeme lassen keine Kontrolle des Inhalts eines Pakets zu. Erlaubte Regeln
wären in dieser Art: Lass niemanden von außen den Telnet Port benutzen. Oder eine
9.3.2 Screened Subnet Architekturen
andere typische Regel, wäre Lass jeden Daten über den SMTP Port senden. Selektiver geht
Die Screened Subnet Architektur erhöht die Sicherheit im lokalen Netz, indem sie ein zusätz- es, wenn man Regeln auf eine gewisse IP Adresse bezieht: Lass NNTP Verbindungen nur
liches Sicherheitsnetzwerk verwendet. Dieses Perimeter Network wird für sogenannte Basti- auf [Link] ([Link]) zu. Wobei in einer Regel nie ein Hostname stehen sollte!
on Hosts verwendet. Packet Filter Regeln können sich jedoch nie auf gewisse User oder Dateien beziehen.
Bastion Hosts sind im Prinzip Server aus dem lokalen Netz, die jedoch auch Services Basic Packet Filter erlauben auch keine Rückschlüsse darauf, ob eine gewisser Port für sein
nach außen anbieten. Beispiele dafür wären Web oder SMTP Server. Da sie eben Verbin- angestammtes Protokoll verwendet wird, oder ob jemands FTP Verbindungen am SMTP
dungen vom Internet erlauben, sind sie am besten von außen angreifbar und sollten dem Port ausprobiert.
entsprechend gesichert werden. Weiters darf auch die Kompromittierung eines Bastion Host Stateful Packet Filtering erweitert die Möglichkeiten dieses Firewalltyps. Diese Systeme
nicht sofort Gefahr für das lokale Netz bedeuten. erlauben sogenanntes state tracking. Das erlaubt erweiterte Regeln dieser Art: Lass ankom-
In dem man nun ein eigenes Netzwerk zwischen dem externen und dem internen Netzwerk mende UDP Pakete nur durch, wenn sie Antworten zu gesendeten Paketen sind, oder Erlaube
einfügt, erhält man eine sogenannte Demilitarized Zone (DMZ), auch Perimeter Network TCP Pakete mit gesetztem SYN Bit, nur wenn sie Teil eines TCP Verbindungsaufbaus sind.
genannt in der nun Server laufen können, die Dienste nach außen und innen anbieten (siehe State tracking erlaubt Regeln, die sonst nicht möglich wären. Aber daraus resultieren
Abbildung 47). Das Perimeter Network ist zumindest durch Packet Filter vom Internet und auch einige Probleme. Der Router muss sich Verbindungsdaten merken. Dies erhöht die
dem inneren lokalen Netz getrennt. Dadurch verbirgt sich seine Struktur und bietet einen benötigte Rechenleistung und Speicherkapazität und erlaubt auch gewisse DoS Attacken.
gewissen Schutz gegen Insider. Wichtiger ist jedoch der Fall, dass sich Hacker Zugang zum Es ist auch schwierig mehrere Router parallel zu verwenden (zB load balancing), da jeder
Bastion Host verschafft haben. Da der Bastion Host sich in einem physikalisch getrennten Router die State Information der anderen Router wissen muss.
106 9 INTERNET FIREWALLS 9.5 Proxy Systeme 107

Example: Forward all ssh and http connection requests from the Internet
to local system [Link]

#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL

# PORT PORT(S) DEST
DNAT net loc:[Link] tcp ssh,http

Example: Redirect all locally-originating www connection requests to

# port 3128 on the firewall (Squid running on the firewall
# system) except when the destination address is [Link]
#
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
REDIRECT loc 3128 tcp www - ![Link]

9.5 Proxy Systeme

Abbildung 48: Stateful Packet Filtering am UDP Layer (aus [Zwickey et al 2000])
Bei Verwendung von Proxy Servern hat nur ein einziger oder eine geringe Anzahl Hosts
direkte Verbindung zum Internet. Diese agieren als Stellvertreter für die Rechner ohne
direkte Verbindung. Proxy Server gibt es jeweils für ein oder mehrere Protokolle und laufen
Bei UDP Paketen gibt es auch nie die Garantie einer Antwort. Dennoch muss der Router entweder auf einem Dual-Homed Host oder Bastion Host.
sich auch solche Verbindungen merken, da er ja nicht wissen kann, ob doch noch eine kommt. Aus der Sicht des Benutzers, erscheint der Proxy Server wie der richtige Server (siehe
Stateful Packet Filter speichern Verbindungen typischerweise in Tabellen. Diese bieten nur Abbildung 49). Auch der Server im Internet glaubt mit dem lokalen Rechner direkt zu
begrenzt Platz (zb Netfilter bei 256MB RAM ca 16000 Einträge) und der Router muss sprechen.
von Zeit zu Zeit Einträge verwerfen. Kommen eigentlich gültige UDP Antworten zu spät,
verwirft der Router diese fälschlicherweise (siehe Abbildung 48).
Bei der Konfiguration eines Packet Filter Routers müssen einige Dinge beachtet werden.
Typischerweise wählt man eine Default Deny Policy, und wählt dann die Dienste aus die
nicht gefiltert werden sollen. Es gibt auch die Default Permit Policy, die jedoch schon
prinzipell sehr unsicher ist, da sie von sich aus alles erlaubt. Nicht gestattete Dienste müssen
in dem Fall durch Regeln ausgeschalten werden.
Als Beispiel für eine aktuelle Stateful Packet Filter Firewall wird hier die iptables-basierte
Firewall Shorewall genannt. Die Konfiguration der Regeln erfolgt durch Editierung der
“rules” Datei im Shorewall Verzeichnis. Die Shorewall kennt folgende Regeln:

ACCEPT - Erlaube die Verbindungsanfrage.

DROP - Ignoriere die Verbindungsanfrage (ohne Benachrichtigung - stealth).
REJECT - Verbiete die Verbindungsanfrage (mit Benachrichtigung). Abbildung 49: Proxy Server Illusion (aus [Zwickey et al 2000])

DNAT - Leite die Anfrage weiter.

REDIRECT - Leite die Anfrage an ein anderes Port der FW weiter (zB laufender Proxy Wie Proxy Server arbeiten ist von Service zu Service verschieden und kann nicht gene-
an FW) rell erklärt werden. Ein HTTP-Proxy arbeitet Prinzipiell ganz anders als zB Proxies für
Streaming Anwendungen.
Regel-Beispiele einer Netfilter/iptables basierten Firewall ([Shorewall]). Auf der Client Seite muss einer der folgenden Punkte erfüllt sein:
Example: Accept www requests to the firewall.
Proxy-Aware Application Software: Hier muss die verwendete Software den Proxy Me-
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL chanismus verstehen. Sie muss davon wissen, das der Verbindungsaufbau über einen
# PORT PORT(S) DEST Proxy Server läuft. Eı́n Beispiel wäre die Einstellung eines HTTP Proxy Server in
ACCEPT net fw tcp http einem Internet Browsers.
108 9 INTERNET FIREWALLS 9.6 Zusammenfassung 109

Proxy-Aware Operating System Software: In diesem Fall weiß bereits das Betriebs- • Den SOCKS Server.
system über einen Proxy Server bescheid. Diese Methode ist wenig transparent für
den Benutzer und kann zu Problemen führen. • Die SOCKS Client library.

Proxy-Aware Router: Es gibt keine Änderung am Client. Ein Router fängt jedoch An- • Versionen von Unix Standard Programmen, die mit SOCKS arbeiten können. Darun-
fragen an Internet Server ab und leitet sie anstelle zu Proxy Server weiter. ter fällt FTP, Telnet, ping, traceroute.

• Das Program runsocks, das erlaubt Programme zu laufzeit mit SOCKS arbeiten zu
Proxy-Aware User: Für die Benutzer am unangenehmsten. Anstelle der Software Teilen
lassen (über dynamic linking).
sie dem Proxy den richtigen Request mit (zB Web Interface). Dieser leitet dann die
Antwort auf die Client Applikation, die eigentlich nicht mit Proxies arbeiten kann. Applikationen, die mit SOCKS arbeiten sollen, sind gleich zu programmieren wie gewöhn-
liche Programme, die mit Sockets arbeiten. Für jede Unix C Socket Funktion gibt es ein
Proxy Server Typen können recht einfach unterschieden werden: Äquivalent aus der SOCKS Library. Statt bind() verwendet man Rbind() etc (siehe Ta-
Application-Level vs Circuit Level Proxies: Ein Application-Level Proxy kennt die belle 1). Es sind keine Änderungen am Programm selbst notwendig. Die nötigen Verbin-
jeweilige Applikation. Er versteht und interpretiert die Befehle die im jeweiligen Proto- dungsinformationen holt sich die SOCKS Applikation dann aus der [Link] Datei, die am
koll definiert sind. Im Gegensatz dazu verbindet ein Circuit Level den Client mit dem System vorhanden sein muss.
Server ohne direkt das Protokoll zu verstehen. Der zweite arbeitet also sehr ähnlich
Standard Funktion SOCKS Funktion
einem Paket Filter, aber dennoch lässt er keine direkte Verbindung zu.
connect() Rconnect()
Generic vs Dedicated Proxies: Ein Dedicated Proxy Server ist auf ein spezielles Pro- gessockname() Rgetsockname()
tokoll spezialisiert, während ein Generic Proxy multiple Protokolle versteht. In der bind() Rbind()
Praxis sind generische Proxies meist Circuit Level Proxies. accept() Raccept()
listen() Rlisten()
Intelligent Proxy Servers: Sind meist Dedicated Proxies, die zusätzliche Funktionen wie select() Rselect()
Caching bieten.
Tabelle 1: Mapping von Netzwerk Funktion zu SOCKS
9.5.1 SOCKS Proxy Systeme
Der große Vorteil von SOCKS ist seine weite Verbreitung. Gleichzeitig aber auch der
Wenn man über Proxies recherchiert, stösst man sehr bald auf den Begriff der SOCKS größte Nachteil: es gibt bereits Trojaner die selbst SOCKS benützen.
Proxies. SOCKS ist ein Standard ([RFC1928 1980]) für generische Proxies.
Momentan sind SOCKS4 und SOCKS5 in Verwendung, wobei beide Protokolle nicht
9.6 Zusammenfassung
kompatibel zu einander sind. Im Gegensatz zu SOCKS5, kennt SOCKS4 kennt keine Be-
nutzer Authentifizierung und kann nur mit TCP basierten Clients arbeiten. Die zwei Firewall Hauptechnologien befinden sich in stetiger Weiterentwicklung, quasi im
Wettrüsten mit den jeweiligen Angreifern. Der Sicherheitsstandard ist sehr hoch, jedoch
absolut nicht 100%. Erst vor kurzem wurden erfolgreiche Einbrüche in die Debian Linux
Server gemeldet. Heute morgen (4. Dezember 2003) gab es ähnliche Meldungen von den
GNU Savannah und Gentoo Servern.
Man muss sagen, dass das Internet heutzutage ein nicht ungefährlicher Ort ist. Es ist
wichtig Sicherheitssysteme zu verwenden, zu denen die hier vorgestellten Firewall Systeme
gehören.

Literaturverzeichnis
[Zwickey et al 2000] Elizabeth D. Zwicky, Simon Cooper, D. Brent Chapman: Building
Internet Firewalls, O’Reilly, June 2000
Abbildung 50: SOCKS Proxy (aus [Zwickey et al 2000])
[Shorewall] Shorewall-iptables made easy
Wie gesagt ist SOCKS ein generischer Proxy. Aus diesem Grund hat er keine protokol- [RFC1928 1980] M. Leech: “SOCKS Protocol Version 5” RFC 1928, March 1996
spezifischen Funktionen und Logging.
SOCKS protokolliert alle Anfragen an den Server. Es erlaubt Zugriff per User, per
Source Host und Port Nummer und per Destination Host und Port Nummer. Speziell die
Einschränkungsmöglichkeiten per User sind ein Vorteil gegenüber Packet Filtern.
Das SOCKS Software Paket beinhaltet
110 10 VIRTUAL PRIVATE NETWORKS (VPN) 10.2 VPN Typen 111

10 Virtual Private Networks (VPN) • geographische Skalierbarkeit

Dieser Abschnitt behandelt Virtuelle Private Netzwerke in folge VPN’s genannt. Es werden • Bandbreiten Skalierbarkeit
Sicherheitstechnologien in Bezug auf VPN’s behandelt und Protokolle die mit VPN’s in
Verbindung stehen, insbesondere IPSec, besprochen. Geographische Skalierbarkeit,da man innerhalb kürzester Zeit über einen Einwahl-
punkt eines Internetproviders Teil des VPN’s werden kann. Bandbreiten Skalierbar-
Alexander Cucek: cucek@[Link], Grundlegendes über VPN, VPN-Typen, Anfor- keit, will man eine grössere Bandbreite zur Verfügung, wechselt man seine Anbindung
derungen an VPN’s z.B von einem 56Kbps-Modem auf 128Kbps-ISDN oder auf grössere Bandbreiten, je
nach Bedarf.
Peter Gabriel: pgabriel@[Link], Sicherheitstechnologien, Authentifizierung
Alexander Oreschnig: aoresch@[Link], IP-Security-Protocol, Andere Protokolle 10.1.3 Definition VPN

Virtuell bedeutet, dass es sich aus Anwendersicht nur um ein Netzwerk handelt, auch wenn
10.1 Einleitung
sich viele reale Teilnetzwerke dahinter verbergen.
Um einen Einstieg in das Thema VPN zu geben wird kurz auf die Geschichte der Entwicklung
von Privaten Netzwerken eingegangen, sowie die Frage beantwortet, warum eigentlich VPN’s Privat bedeutet, dass die Kommunikation vertrauenswürdig, also nicht öffentlich, durch-
benutzt werden sollen. geführt wird.

10.1.1 Geschichte Netzwerk bedeutet, dass eine definierte Gruppe von Rechnersystemen miteinandere Ver-
bunden wird, und mit Hilfe eines Protokolls (typischerweise aus der TCP/IP-Protokollfamilie)
Bevor das Internet zu einem universal benutztem Medium geworden ist, bestanden VPN’s kommuniziert.
aus von Providern gemieteten Verbindungen. Die Idee war das Kunden diese gemieteten
Verbindungen in gleicher Weise benutzen, wie ihre Verbindungen in ihrem lokalen Netzwerk.
Die Anbieter solcher VPN’s garantierten die Privatheit dieser Netze dadurch, dass nie- 10.1.4 Analogie
mand sonst dieses Netz benutzt. Das ermöglichte den Kunden ihr eigenes IP-Adressing und
Zum besseren Verständnis der grundsätzlichen Idee von VPN wird folgende Analogie ver-
deren eigene Sicherheitbedingungen [Link] Kunden vertrauten dem Anbieter das
wendet, wie sie in Abbildung 51 zu sehen ist. Sicherheitstransporter: Anders als bei nor-
innerhalb dieser gemieteten Verbindungen die Sicherheit des Datentransfers gewährleistet
malen LKW’s, bei denen die zu transportierenden Werte nicht explizit geschützt sind, dient
ist.
ein Sicherheitstransporter dazu, die auszutauschenden Werte während des Transports wir-
Als das Internet als Kommunikationsmedium immer populärer wurde, wurde auch die Si-
kungsvoll gegen Angriffe zu schützen. Dabei nutzen die Organistationen die gemeinsame
cherheit für Kunden und Anbieter ein immer wichtiger werdender Faktor. Da die bisherigen
öffentliche Infrastruktur der Strasse (Landstrasse, Autobahn) ohne eine eigene Infrastruktur
VPN’s keine wirkliche Sicherheit vorzuweisen hatte, begann man Protokolle zu entwickeln,
(Privatstrasse) aufbauen zu müssen.
die am Beginn der Übertragung die Daten verschlüsseln und am Ziel wieder entschlüsselten.
Dieser verschlüsselte Datentransfer verhaltet sich wie ein Tunnel zwischen den Netzwerken,
auch wenn ein Angreifer die Daten sieht, kann er sie nicht lesen, und wenn er sie ändert
kann das erkannt werden.

10.1.2 Warum VPN?

Die grundsätzliche Idee von VPN’s ist es die Vorteile einer offenen Kommunikationsinfra-
struktur zu nutzen, z.B dem Internet, dabei aber die Informationssicherheit zu gewährleisten.
Ein VPN soll gewährleisten das Übertragungen über verschiedene nicht einschätzbare
Netzwerke (LAN’s und WAN’s, private- und öffentliche Netze) vertrauenswürdig übertragen
werden, sodass nur berechtigte Organisationen/Personen auf zu schützende Daten zugreifen
bzw. deren Inhalt verändern können. Abbildung 51: Analogie Sicherheitstransporter (Quelle: [VPN 1998])
Vorteile von VPN’s:
Kostenersparnis: Ist ein wesentlicher Punkt, da die gemieteten Verbindungen wesentlich Entsprechend dient ein VPN dazu, Daten (elektronische Werte) sicher über öffentliche
teurer sind als eine Anbindung über einen Provider in das Internet. Infrastruktur von Netzwerken (LAN’s und WAN’s) zu transportieren, ohne dass Unbefugte
die Daten einsehen oder manipulieren können.
Flexibilität: Es können sich die Teilnehmer über verschiedenste Technologien an das In-
ternet über einen Internet-Service-Provider (ISP)und somit in das VPN verbinden.
10.2 VPN Typen
Skalierbarkeit: Da das VPN da gleiche Medium und die gleichen Technologien wie das
Internet verwendet können zwei Arten der Skalierbarkeit erreicht werden: In Prinzip gibt es drei verschieden Typen von VPN’s:
112 10 VIRTUAL PRIVATE NETWORKS (VPN) 10.4 Sicherheit in VPNs 113

10.2.1 Unternehmensweites VPN

Darunter versteht man die privateNetzwerkverbindung zwischen verschiedenen LAN-Standorten
eines Unternehmens (Zentrale und Niederlassungen), die dazu dienen, Unternehmensdaten
vertrauenswürdig über ein unsicheres Netz wie das Internet austauschen zu können. Hier
spielt die Transparenz eine wichtige Rolle. Abbildung 52 zeigt ein unternehmensweites VPN.

Abbildung 53: Remote-Ankopplung mit Hilfe eines VPN (Quelle: [VPN 1998])

• Die Daten können durch Dritte gelesen und verändert werden, während sie über das
öffentliche Netz übertragen werden.

• Durch die Ankopplung an ein offenes Netzwerk können Unbefugte auf die Rechnersy-
Abbildung 52: Unternehmensweites VPN (Quelle: [VPN 1998])
steme des eigenen Netzes zugreifen und Schaden anrichten.

Mehrere Sicherheitstechniken können Daten auf Ihren Weg über öffentliche Netze so
schützen, dass ihre Vertraulichkeit(Privatheit) gewährleistet bleibt, und niemand in der Lage
10.2.2 Sichere Remote Ankopplung ist, unbefugte auf die eigenen Rechnersysteme zuzugreifen. Diese Sicherheitsmassnahmen
Heim- und/oder Mobile-Arbeitsplätze, wie es Abbildung 53 in zu sehen ist, greifen innerhalb ermöglichen es die Vorteile öffentlicher Kommunikationsstrukturen zu nutzen und zugleich
eines VPN über ein öffentliches Netzwerk (z.B Internet) geschützt auf die zentral gespeicher- die Vertraulichkeit und Informationssicherheit eines privaten Netzwerkes zu bewahren.
ten Unternehmensdaten zu. Hier spielt die Identifikation und Authentifikation des Nutzers, Um diese Ziele zu erreichen, müssen kryptographische Verfahren und andere Sicherheits-
der auf die Daten zugreifen möchte, eine besondere Rolle. mechanismen eingesetzt werden:

• Verschlüsselung
10.2.3 VPN zwischen verschiedenen Unternehmen
In einer definierten Gruppe von Unternehmen (z.B Automobilherstellern und Zulieferer) • Authentifikation
können alle Partner miteinander mit Hilfe von VPN’s eine vertrauenswürdige, unterein- • Digitale Signaturen
ander und nach aussen hin geschützte Kommunikation realisieren. Hier spielt das unter-
nehmensübergreifende Sicherheitsmanagment eine besondere Rolle. Abbildung 54 zeigt das • Tunneling
Schema eines kooperativen VPN.
Diese Begriffe werden in nachfolgenden Kapiteln behandelt.
10.3 Anforderungen an VPN’s
10.4 Sicherheit in VPNs
In der Informationstechnik wird zunehmend mit verteilten Anwendungen gearbeitet, dass be-
deutet das Daten an verschiedenen Orten erstellt/bearbeitet werden und dann über Kommu- Da bei VPNs der Datenaustausch über ein unsicheres Medium erfolgt, sind besondere Si-
nikationsnetze ausgetauscht werden. Diese Kommunikationstechniken bieten enorme Vortei- cherheitsmaßnahmen zu treffen. In diesem Kapitel werden die VPN-Mechanismen, die die
le in Schnelligkeit und Flexibilität der Informationsübertragung, aber es entstehen dadurch Sicherung privater Daten beim Transport durch das Internet garantieren, etwas genauer
auch nicht zu unterschätzende Sicherheitsrisiken. erläutert.
114 10 VIRTUAL PRIVATE NETWORKS (VPN) 10.5 Verschlüsselung 115

10.4.3 Datenvertraulichkeit
Beim Versenden der Daten über das Internet, soll natürlich gewährleistet werden, dass
keine unauthorisierten Personen die Daten im Klartext lesen können. Dies wird durch
Verschlüsselung erreicht.
Oft wird weiters gefordert, dass auch die internen Netzwerk-Beziehungen (Quell- und
Zieladresse, Protokoll- und Portnummern) geschützt werden. Dies erreicht man, indem
das gesamte Original-Paket, also auch der Header, in den Datenbereich des neuen, ver-
schlüsselten Pakets geschrieben wird. In diesem Fall spricht man dann von Tunneling (siehe
Abschnitt 10.7.6).

10.4.4 Paket-Authentifizierung
Wird ein Paket vom Empfänger empfangen, möchte dieser natürl]ich auch sicher sein, dass
das Paket auch tatsächlich vom authentisierten Sender stammt. Dazu kann die Prüfsumme
des Pakets verwendet werden:
Der Sender berechnet die Prüfsumme des Pakets mittels einer Hash-Funktion. Hier
bieten sich der Message Digest 5 (MD5) und der Secure Hash Algorithmus (SHA) an. Auf
Abbildung 54: Kooperatives VPN verschiedener Unternehmen (Quelle: [VPN 1998])
den genauen Algorithmus wird hier nicht eingegangen. Hier sei auf die [RFC1321 1992]
für den MD5 und [FIPS-PUB 180-1 1993] für den SHA verwiesen. An dieser Stelle sei nur
erwähnt, das der MD5 einen Hashwert der Länge 128 Bit, der SHA hingegen einen Hashwert
der Länge 160 Bit ermittelt. Weiters noch zu erwähnen ist, dass für den MD5 Kollisionen
10.4.1 Einführung bekannt sind. Vor einer Kollision spricht man, wenn zwei unterschiedliche Nachrichten den
selben Hash-Wert ergeben.
Um die privaten Daten genügend zu schützen, werden im generellen folgende Mechanismen Der Empfänger seinerseits berechnet ebenfalls die Prüfsumme des Paketes und vergleicht
gefordert: diese mit der des Senders. Allerdings reichen bei VPNs normale Prüfsummenverfahren nicht
aus. Denn ein Angreifer könnte nachdem er das Paket verändert hat, die Prüfsumme einfach
• Schlüsselmanagement
neu berechnen. Um dies zu verhindern finden sog. Keyed Hash Algorithmen ihren Einsatz.
Diese bilden den Hashwert aus der Nachricht selbst sowie einem symmetrischen Schlüssel.
• Daten-Vertraulichkeit
Da dieser Schlüssel dem Angreifer nicht bekannt ist, kann er auch die Prüfsumme nach ei-
• Paket-Authentifizierung ner Datenänderung nicht korrekt berechnen. Das bei VPNs verwendete Verfahren nennt
sich Hash-Based Message Authentication Code (HMAC). Dies ist kein eigener Algorith-
• Datenintegrität mus, es kombiniert vielmehr bereits bestehende Verfahren (MD5, SHA) mit symmetrischen
Schlüsseln und Padding. Dardurch wird auch die Kollisionssicherheit stark erhöht.
• Benutzer-Authentifizierung
10.4.5 Datenintegrität
Nun werden diese Schlagwörter im Detail etwas genauer erläutert.
Diese dient zur Sicherstellung, dass die Daten auf ihrem Transportweg nicht verändert wer-
den. Oftmals werden die Überprüfung der Datenintegrität und die Paket-Authentifizierung
10.4.2 Schlüsselmanagement kombiniert.
Um die Sicherheit gewährleisten zu können, sind vor allem sichere Schlüssel nötig. Schlüssel
sollten im Allgemeinen, besonders jene zur Datenverschlüsselung, eine begrenzte Lebens- 10.4.6 Benutzer-Authentifizierung
dauer (eine Session, wenige Stunden) haben. Daraus folgt sofort, dass Schlüssel oft erzeugt Mittels der Benutzer-Authentifizierung wird sichergestellt, dass der Absender der Daten
und verteilt werden müssen. Aus diesem Grund fallen manuelle Verfahren aus. Auch sog. auch derjenige ist, der er vorgibt zu sein. Die Authentifizierung der Kommunikationspart-
Out-of-Band-Verfahren sind nicht die optimale Lösung, da dadurch der Netzaufwand nahe- ner erfolgt am Beginn der Kommunikation. Die Authentifizierungsverfahren reichen von
zu verdoppelt wird. Aus diesen Gründen wird bei VPNs ein Schlüsselmanagement, das die einfachen Passwortverfahren bishin zu digitalen Zertifikaten. Welche Möglichkeiten der Au-
Aufgaben der Erstellung, rechtzeitigen Erneuerung und Verteilung der Schlüssel übernimmt, thentifizierung bestehen wird in Abschnitt 10.6 beschrieben. Die Authentifizierung ist bei
verwendet. Die genauen Vorschriften zur Erzeugung und Vergabe der Schlüssel wird durch Remote-Access-VPNs besonders wichtig.
das Internet-Key-Exchange-Protokoll (IKE) definiert. IKE ist kein auf IPSec festgelegtes
Protokoll, die genaue Spezifikation für IPSec findet sich im IPSec Domain of Interpretation
10.5 Verschlüsselung
([RFC2407 1998]). Auf die grundsätzliche Schlüsselerzeugung und -vergabe wird im Ab-
schnitt 10.5.2 eingegangen. Hier sei nur erwähnt, dass dazu sog. asymmetrische Verfahren Die Algorithmen zur Erstellung des Chiffretextes sind im allgemeinem wohl bekannt. Aus
verwendet werden. diesem Grund hängt die Sicherheit des Algorithmus nur von der Geheimhaltung des Schlüssels
116 10 VIRTUAL PRIVATE NETWORKS (VPN) 10.5 Verschlüsselung 117

ab. Daraus ergibt sich, dass die Länge eines Schlüssels sehr stark zur Sicherheit des Algo- dieser wohl definiert und standardisiert ist. Hier eine kleine Liste möglicher symmetrischen
rithmus beiträgt. Ein Algorithmus gilt als sicher, wenn keine schnellere Methode, als die Verschlüsselungsverfahren:
Brute-Force-Attacke bekannt ist. Darunter versteht man das Durchlaufen aller möglichen
Schlüsselkombinationen. In Abbildung 55 findet sich ein Vergleich verschiedener Algorith- • Data Encryption Standard (DES)
men.
• Tiple-DES (3DES)
Grundsätzlich gibt es zwei Arten der Verschlüsselung, die symmetrische und die asym-
metrische Verschlüsselung. • International Data Encryption Algorithm (IDEA)
• Advanced Encryption Standard (AES)
• Carlisle Adams, Stafford Tavares (CAST)
• Blowfish

Im folgenden soll auf den DES sowie den 3DES etwas eingegangen werden.

Data Encryption Standard: Der DES wurde im Jahr 1977 vom National Bureau of Stan-
dards (USA) verabschiedet. Seine genaue Beschreibung findet sich im [FIPS-PUB 46-2
1988]. Der DES ist bis heute noch ungebrochen, d.h. es gibt noch keine schnellere Me-
thode als die Brute-Force-Attacke um den Algorithmus zu [Link] Schwachpunkt
erweist sich beim DES die fixe Schlüssellänge von 56-Bit. Dadurch kann der DES
mittels richtiger Ausstattung und Brute-Force-Attacke in annehmbarer Zeit geknackt
werden. Dies führt uns zum 3DES.
Abbildung 55: Vergleich der benötigten Zeit bei Brute-Force-Attacken
(Quelle: [VPN 2001]) Tiple-DES: Der 3DES arbeitet mit einer dreifachen DES-Verschlüsselung, wie es Abbil-
dung 57) zeigt.

10.5.1 Symmetrische Verschlüsselung

Die symmetrische Verschlüsselung, auch Secret-Key-Verschlüsselung genannt, geht davon

aus, dass alle Beteiligten den Schlüssel kennen. Dieser wird sowohl zur Ver- als auch zur
Entschlüsselung verwendet (siehe Abbildung 56).

Abbildung 57: Prinzip der 3DES-Verschlüsselung (Quelle: [VPN 2001])

Daraus ergeben sich insgesamt 2168 mögliche Schlüssel. Dies ist mittels Brute-Force-
Attacke nicht mehr möglich zu entschlüsseln. Außerdem bleibt die Kompatibilität zu
DES erhalten. Es müssen lediglich allen 3 Stufen des Triple-DES der 56-Bit-Schlüssel
gleichzeitig zugeführt werden.

10.5.2 Asymmetrische Verschlüsselung

Die Idee der asymmetrischen Verschlüsselung geht auf Diffie-Hellman (1976) zurück. Bei
der asymmetrischen Verschlüsselung existieren zwei verschiedene Schlüssel. Ein öffentlicher
Schlüssel (Public Key), der zum Verschlüsseln und ein privater Schlüssel (Private Key), der
Abbildung 56: Prinzip der symmetrischen Verschlüsselung (Quelle: [VPN 2001]) zum Entschlüsseln, verwendet wird (siehe Abbildung 58). Eine verschlüsselte Nachricht
kann nicht mehr mit einem öffentlichen Schlüssel entschlüsselt werden. Der private und
public Key sind nach einem mathematischen Modell voneinander abgeleitet. Trotz dieser
Zur Verschlüsselung in VPNs werden ausschließlich symmetrische Verfahren verwendet. Relation der beiden Schlüssel ist es nicht möglich den private Key aus dem public Key zu
Der Grund hierfür liegt vorallem darin, dass diese schneller sind als vergleichbare asym- ermitteln. Asymmetrische Verfahren sind wesentlich langsamer als symmetrische Verfahren.
metrische Verfahren. Bei der Wahl des Algorithmus sollte darauf geachtet werden, dass Sie finden vorallem zu automatischen Schlüsselerstellung und -vergabe Anwendung.
118 10 VIRTUAL PRIVATE NETWORKS (VPN) 10.7 IP-Security-Protokoll (IPSec) 119

IPSec für das Internet Protokoll Version 6 (IPv6). Durch die Inkompatibilität von IPv6
zu IPv4 hat es bis jetzt keine nennenswerte Verbreitung gefunden. Auf die Sicherheit von
Datennetzen wird aber immer mehr Wert gelegt. Daher wurde die Funktionalität von IPSec
auf IPv4 portiert. IPSec ist standardisiert und kann in mehreren Request for Comments
(RFCs) nachgelesen werden. Es wird dabei die generelle Funktionsweise, die einzelnen zum
Einsatz kommenden Protokolle, sowie die Verschlüsselungsalgorithmen beschrieben. Ein
Überblick über IPSec ist in [RFC2401 1998] beschrieben.

10.7.2 IPSec im Überblick

IPSec bietet einen weitreichenden Schutz von IP-Datagrammen. Dabei werden folgende
Bereiche abgedeckt:

Paketintegrität: Paketintegrität wird sichergestellt, indem in das IPSec-Paket ein Hash-

Abbildung 58: Prinzip der asymmetrischen Verschlüsselung (Quelle: [VPN 2001]) base Message Authenication Code (HMAC) eingefügt wird. Dies ist ein durch einen
symmetrischen Schlüssel abgesicherter Hashwert, der über das zu versendende IP-
Paket gebildet wird. Die korrekte Berechnung des HMAC ist nur dem Sender und
10.6 Authentifizierung Empfänger des Paketes möglich, da nur die über den Schlüssel verfügen.

Bei der Authentifizierung müssen grundsätzlich zwei Arten unterschieden werden: Paketauthentifizierung: Für die Paketauthentifzierung wird auch der HMAC verwendet.
Überprüft der Empfänger eines IPSec-Paketes den HMAC und stellt keine Veränderung
Benutzer-Authentifizierung: Bringt den Nachweis der Identität einer Person. fest, ist sichergestellt, dass das Paket nicht verändert wurde und es von dem richtigen
Partner stammt.
Absender-Authentifizierung: Bringt den Nachweis der Identität des Absenders (VPN-
Gateway, Router). Diese läuft in einem zweistufigen Prozess ab. Zuerst, beim Verbin- Paketvertraulichkeit: Die Vertraulichkeit der Daten wird durch Verschlüsselung erreicht
dungsaufbau, identifizieren sich die Gegenstellen. Danach, bei der Datenübertragung, (kann auch für Paketintegrität und -authentifizierung verwendet werden). Nachdem
werden die Pakete nach dem Absender überprüft. IPSec symmetrische Verschlüsselungsalgorithmen verwendet, sind die Schlüssel nur
dem Sender und Empfänger bekannt.
Weiters kann man bei der Authentifizierung zwischen einer starken und eine schwachen
Authentifizierung unterscheiden. Verkehrsflussvertraulichkeit: IP-Pakete werden komplett in einen neues Paket gekap-
Starke Authentifizierung: Erbringung des tatsächlichen Nachweises der Identität durch selt und der neue Datenbereich wird verschlüsselt (Tunneling: siehe Abschnitt 10.7.6).
Überprüfung der persönlichen Anwesenheit. Dadurch kann ein Angreifer sich keine Informationen über das private Netzwerk ver-
schaffen.
Schwache Authentifizierung: Betreffende Person weiß oder hat etwas, was normalerwei-
se nur die tatsächlich zugangsberechtigte Person weiß [Link]. Schutz vor Replay-Angriffen: Ein Angreifer kann IPSec Pakete “aufzeichnen” und er-
neut schicken. Diese Pakete schauen für den Empfänger vertraulich aus. Um dies
Zum Abschluss sollen noch die verschiedenen Möglichkeiten der Authentifizierung angeführt zu Verhindern wurde der Anti-Replay Service (ARS) eingeführt. Näheres zu diesem
werden. Service kann im [RFC2406 1998] nachgelesen werden.
Wissensbasierte Authentifizierung: z.B.: Benutzer-ID und Passwort bzw. PIN Schutz vor Denial-of-Service-Angriffen: DoS-Angriffe, sind Attacken, die darauf ab-
zielen ein Gerät in einen Zustand zu versetzen indem es seine Aufgabe nicht mehr
Besitzbasierte Authentifizierung: z.B.: Chipkarte, Token-Karte in vollem Maße ausführen kann. Ziel ist dabei meist der TCP-Stack. Abhilfe schafft
Kombinationsverfahren: z.B.: Bankomat-Karte dabei ein gehärteter IP-Stack. Dieser ist so programmiert das er nur die Protokolle 50
(ESP), 51 (AH) und 17 (UDP) mit den Portnummern 500 in die Schicht 3 durchläßt.
Biometrik: z.B.: Fingerabdruck-Leser, Augennetzhaut-Scanner
Digitale Signaturen und Zertifikate: Die Verschlüsselung erfolgt mittels private Key, 10.7.3 Die IPSec-Architektur
die Entschlüsselung mittels eines public Keys, der einem bestimmten Benutzer zuge- Die Standardisierung von IPSec ist schon weit fortgeschritten und kann in etlichen RFCs
ordnet ist. nachgelesen werden ([RFC2401 1998] und folgende). Die Architektur kann man in der
Übersicht in Abbildung 59 sehen.
10.7 IP-Security-Protokoll (IPSec) Ausgehend von dieser Architektur und den jeweiligen Anwendungsstrategien, ergeben
sich eine Fülle von Kombinationen von IPSec-Diensten:
10.7.1 Einführung
• ESP mit Verschlüsselung, Integritätsprüfung, Authentifizerung und ARS.
Das IP-Security-Protokoll, kurz IPSec, erweitert das bestehende IP Protokoll mit Sicherheit.
Es ist daher im Netzwerk-Layer des OSI-Schichten-Modells anzusiedeln. Entwickelt wurde • AH mit Integritätsprüfung, Authentifizierung und ARS
120 10 VIRTUAL PRIVATE NETWORKS (VPN) 10.7 IP-Security-Protokoll (IPSec) 121

löscht wenn die Life-Time abgelaufen ist und eine neue SA generiert. Die Sicherheit kann
dadurch erhöht werden.

10.7.5 Security-Policy
Die Sicherheitsstrategie oder Security-Policy legt fest, welche Dienste auf ein- und ausgehen-
de Pakete anzuwenden sind. Die Regeln für die Strategien werden aus der Security Policy
Database entnommen. Die Startegie wählt dann eine aus drei Arten aus, wie die Pakete
behandelt werden sollen: Die Pakete werden verworfen (discard), nicht von IPSec-Diensten
bearbeitet und weitergeleitet (bypass) oder durch IPSec bearbeitet (apply). Im apply-Fall
liefert die SPD einen Verweis auf einen Eintrag in der SAD. Dadurch erhält man die not-
wendigen Parameter und Optionen für die Bearbeitung.

10.7.6 IPSec-Betriebsmodi
Abbildung 59: Die Architektur von IPSec (Quelle: [VPN 2001]) Es stehen zwei Betriebsmodi zur Verfügung:

Tunnelmodus: Der Tunnelmodus wird eingesetzt, um komplette IP-Pakete einschließlich

Header zu schützen. Dies wird erreicht, indem ein neues IP-Paket erzeugt wird, in
• ...
dessen Datenbereich das zu übertragende Paket eingefügt wird. Durch Einsatz des
ESP-Protokolles erhält der Angreifer keinerlei Information über das Originalpaketes.
10.7.4 Security-Associations Im Gegensatz zu anderen Tunneling-Protokollen, die es erlauben andere Netzwerkpro-
Eine Security-Assication (SA) ist das Fundament von IPSec. Sie bestimmt das Verhalten tokolle (z.B.: IPX) zu kapseln, ist mit IPSec nur IP-in-IP-Tunneling möglich.
der Sicherheitsprotkolle, also welche Verschlüsselungalgorithmen verwendet werden, die Le- Transportmodus: Der Transportmodus wird benutzt um höhere Protokollschichten zu
bensdauer der SA, das Authentifizierungsprotokoll usw. Die verschiedenen SAs werden in schützen, die im Datenbereich der IP-Pakete eingekapselt sind. Der Overhead ist
der Security Assocation Database (SAD) gespeichert. Eine SA ist immer unidirektional. nicht so groß, da kein neuer IP-Header erzeugt wird. Angreifer können aber Infor-
Das bedeutet, wie in Abbildung 60 gezeigt, dass für einen bidirektionalen Datenverkehr mationen über die interne Netzwerkstruktur und die verwendeten Protokolle (Anwen-
müssen zwei SAs existieren. Eine für den eingehenden und eine andere für den ausgehenden dungen) erlangen. Außerdem kann der Transportmodus nur bei IPSec-Host-to-Host-
Datenverkehr (Inbounded-SA und Outbounded-SA). Verbindungen genutzt werden, da kein neuer IP-Header erzeugt werden.

10.7.7 Einsatzszenarien
Abhängig wo die IPSec-Verbindungen initiiert und terminiert werden, gibt es drei mögliche
Einsatzszenarien.

Gateway-to-Gateway: Hier erfolgt der Schutz der IP-Datagrammen durch IPSec zwischen
zwei Gateways. Es sind meist VPN-Gateways oder Router. Der Haupteinsatzzweck
ist die Verbindung von privaten Netzen über das Internet.

Host-to-Gateway: Hier erfolgt der Schutz der IP-Pakete auf dem Transport von einem
Endgerät (Host) zu einem Gateway. Einsatzgebiet ist das Einbinden eines Hosts über
das Internet in ein lokales Netzwerk (Remote Access).

Host-to-Host: Hier werden IP-Pakete zwischen zwei Endgeräten übertragen. Ist nicht
sehr oft anzutreffen, dafür gibt es bessere (“billigere”) Lösungen. Einsatzgebiet wäre
Intranet-VPNs.
Abbildung 60: Security-Assocation ist unidirektional (Quelle: [VPN 2001])
10.7.8 IPSec Protokolle
Der Security Parameter Index (SPI), der in jedem IPSec-Protokoll eingetragen ist, ordnet Zuerst wird auf die Paketverarbeitung etwas näher eingegangen:
jedes Packet einer SA zu.
SAs werden in der Regel durch das Internet-Key-Exchange Protokoll (IKE) erzeugt. Sie Ausgehende Pakete: Ausgehende Pakete werden von der höheren Transportschicht an
können aber manuell generiert werden, abhängig vom Einsatzszenario. Es ist aber empfeh- das IP-Protokoll weitergegeben. Es erfolgt eine Abfrage in der Security Policy Data-
lenswert das IKE zu verwenden, da IKE die SA erstellt wenn noch keine verfügbar ist, sie base, was mit dem betreffenden Paket geschehen soll. Dabei sind drei Fälle möglich.
122 10 VIRTUAL PRIVATE NETWORKS (VPN) 10.7 IP-Security-Protokoll (IPSec) 123

Es wird Fallengelassen (Discard), es wird umgehend verschickt (Bypass) oder es wird

ein Verweis auf eine SA zurückgeliefert, das Paket verarbeitet und verschickt (Apply).
Wenn keine SA besteht, wird von IKE eine generiert.
Eingehende Pakete: Eingehende Pakete werden erst überprüft ob es sich um IPSec- Da-
tagramme handelt und ob eine SA aufgebaut wurde. Ist keine SA vorhanden, wird das
Paket sofort fallen gelassen. In anderem Falle wird auf Grund der Einträge in der SA
die notwendige Transformation durchgeführt. Handelt es sich um kein IPSec Paket,
wird überprüft, ob auf das Paket eine Security Policy anwendbar ist. Ist das der Fall,
aber es besteht keine SA dafür, wird das Paket fallen gelassen. Ist keine SP anwendbar
wird das IP-Paket an die höhere Schicht weitergereicht.
Das Authentication-Header-Protokoll (AH): Authentication Header ist ein IPsec-Protokoll,
das außer der Datenvertraulichkeit alle in IPSec geforderten Schutzmechanismen bie-
tet. Die detaillierte Spezifikation ist in [RFC2402 1998] nachzulesen. Die Hauptaufga-
be des AH besteht in der Authentifizierung der Datenpakete und der Sicherung ihrer
Integrität. Optional kann man den Schutz vor wiederholten Senden der Datagramme Abbildung 62: Das IPSec-ESP-Protokoll (Quelle: [VPN 2001])
aktivieren.

In Abbildung 63 sieht man die Verarbeitung eines ausgehenden ESP Paketes im Tun-
nelmodus. Die IPSec-Security-Policy prüft zuerst anhand ihrer Datenbank, ob das
für das Paket eine Regel zutrifft, und liefert im Erfolgsfall einen Verweis auf einen
Eintrag in der SAD zurück. In der SAD ist dann genau festgelegt wie das Paket be-
arbeitet werden muß (Tunnelparameter, Verschlüsselungsalgorithmus, Schlüssel, ...).
Die Verarbeitung eines eingehenden Paketes kann man als Umkehrung des Prozesses
verstehen.

10.7.9 IPSec-Implementierungen
Betriebssystemembene, IPSec-Stack: In dieser Variante wird der ursprünglich IP-Stack
durch einen neuen Stack ersetzt, der eine zusätzliche IPSec-Funktionalität aufweist. In
Abbildung 61: Das IPSec-AH Protokoll (Quelle: [VPN 2001])
dieser Implementierung ist leider nur in bestimmten Umgebungen einsetzbar. Wenn
es sich zusätzlich um ein reines VPN-Gatway handelt, kann man “gehärtete” Stacks
einsetzen, die zusätzliche Sicherheit bieten. Wie schon erwähnt sind nur die IPSec-
In Abbildung 61 sieht man das AH einmal im Transport- und im Tunnelmodus. Der Dienste (ESP, AH, IKE) in diesem Stack aktiviert, andere Dienste werden verworfen.
Schutz der Datenintegrität erstreckt sich über das vollständige IP-Paket, also auch
über den Header. Das AH-Protokoll wird im IP-Header durch die Protokollnummer Bumb-in-the-Stack (BITS): Wenn die IPSec-Funktionalität nicht im Betriebssystem im-
51 gekennzeichnet. Der eigentliche Header wird zwischen IP-Header und Payload plementiert ist, muß man diese BITS-Variante wählen. Der Eingriff in den IP-Stack des
eingefügt. Betriebssystems wäre zu schwerwiegend, daher fügt man IPSec als zusätzliche Verar-
beitungsschicht zwischen der Datenübertragungs- und IP-Schichte ein. Es ist nicht die
Das Encapsulation-Security-Payload-Protokoll (ESP): Das Encapsulating-Security-
leistungsfähigste Lösung, da die Netzwerkschicht in diesem Falle zweimal durchlaufen
Payload-Protokoll bietet alle Sicherheitsfunktionen, die auch AH bietet, plus einem
wird, aber man ist unabhängig von IPStack und Übertragungstechnlogie.
zusätzlichen Schutz der Datenvertraulichkeit. Um dies zu erreichen, wird ein Teil des
IP-Paketes verschlüsselt und ein Header und ein Trailer in das Datagramm eingefügt. Implementationen:
Die Datenintegritätsprüfung und Authentifizierung erstreckt sich im Gegensatz zum
AH Header nicht über das vollständige Paket, sondern der IP-Header wird von der
Berechnung ausgenommen. ESP ist ebenfalls ein IP-Protokoll, dem die Nummer 50 Betriebssysteme mit IPSec Support:
zugeordnet wurde. Ebenso wie beim AH Header sind die Algorithmen, die zur In- Microsoft hat IPSec in den Windows 2000/XP implementiert. Linux bietet IPSec
tegritätsprüfung und Verschlüsselung benutzt werden im IKE-Protokoll oder manuell ab der Kernel-Version 2.6. Der Backport von IPSec in Kernel 2.4 wird überlegt.
festgelegt. Sun hat in Solaris 8 IPsec aufgenommen. Hewlett Packard bietet auch IPSec in
In Abbildung 62 sieht man ein ESP Paket im Tunnel- und Transportmodus. Es ist den UNIX Maschinen. Für den Palm gibt es von Certicom eine IPSec Implemen-
außerdem der authentifizierte und verschlüsselte Bereich ersichtlich. tierung. Bei Mac OS ist der Support in Planung.
124 10 VIRTUAL PRIVATE NETWORKS (VPN) 10.8 Andere Protokolle 125

10.8 Andere Protokolle

Im folgenden werden noch 3 alternative Protokolle zu IPSec beschrieben:

10.8.1 Point-to-Point-Tunneling-Protocol (PPTP)

Das Point-to-Point-Tunneling-Protocol (PPTP) wurde ursprünglich von Microsoft und Ascend
entwickelt und ist deshalb in der Windows-Welt weit verbreitet. PPTP ermöglicht nicht nur
die Übertragung von IP-Paketen, sondern auch von IPX- und NetBUI-Paketen. Je Kommu-
nikationspaar kann nur ein Tunnel aufgebaut werden. In PPTP sind keine Key-Management-
Protokolle implementiert. Die Datenverschlüsselung erfolgt nach dem RC4-Verfahren mit
Schlüssellängen von 40, 56 oder 128 Bit. Eine Paket-Integritätsprüfung ist nicht implemen-
tiert. PPTP ist nicht standardisiert. In die Schlagzeilen ist PPTP geraten, da verschiedene
Berichte über Implementierungsdefizite bei der Schlüsselverwaltung veröffentlich wurden!
Details sind auf [PHION Security Advisory 2002] nachzulesen.

10.8.2 Layer-2-Forwarding (L2F)

Layer 2 Forwarding und wurde von Cisco, Nortel und Shiva entwickelt. Die sogenannte
Multiplex-ID L2F-Header erlaubt den gleichzeitigen Betrieb mehrerer Tunnel. Unterstützt
Abbildung 63: Die Verarbeitung eines ausgehenden IPSec-ESP-Paketes werden Punkt-zu-Punkt und Punkt-zu-Mehrpunkt-Verbindungen. Neben PPP kann man
(Quelle: [VPN 2001]) mit L2F auch SLIP tunneln. Die Authentisierung erfolgt über ein Challenge-Handshake-
Verfahren. L2F kann über unterschiedliche Paketnetze transportiert werden wie z.B. X.25,
Frame Relay oder ATM. Es erfolgt keine Verschlüsselung der Daten! Der zugehörige RFC
2341 hat den Stand “historic”!
Open source Implementation:
Für Linux gibt es FreeS/WAN, pipsecd, ipnsec und NIST Cerberus. Für BSD
10.8.3 Layer-2-Tunneling-Protocol (L2TP)
Unix ist verfügbar KAME, OpenBSD includes IPSec in the distribution and IPSec
for FreeBSD. Das Layer-2-Tunnelung Protocol vereint die Vorteile von PPTP und L2F. Eine Tunnel-ID im
IPSec in Routern: L2TP-Header erlaubt den Betrieb multipler Tunnels. Network Address Translation (NAT)
Die Produkte vn CISCO, Ascend, Bay Networks (Contivity Switches) und 3Com wird unterstützt, welche in [RFC2766 2002] beschrieben ist. L2TP erlaubt eine Authenti-
besitzen IPSec Support. sierung auf der Basis von CHAP/ PAP. Es ist keine Verschlüsselung definiert. L2TP ist ein
Proposed Standard nach IETF (RFC 2661). Im “Proposed Standard” RFC 3193 (“Securing
IPSec in Firewalls: L2TP using IPsec”) ist eine Methode beschrieben, um L2TP und IPsec zu kombinieren und
Borderware, Ashley Laurent, Watchguard und Injoy für OS/2 bieten Firewalls L2TP dadurch mit der fehlenden Verschlüsselung zu versehen.
mit IPSec an.
IPSec auf Netzwerkkarten: 10.9 Zusammenfassung
Intel, 3Com und RedCreek haben Netzwerkkarten mit IPSec im Angebot.
Nachdem Vergleich mit den eben erwähnten Protokollen, kann man IPSec als beste Lösung
für ein VPN betrachten. Eine vollständige Sicherheit wird man nie erreichen können, wenn
man einen Datenverkehr über ein unsicheres Netz betreibt. Aber IPSec bietet die beste
Lösung an und es wird weiter an diesem Protokoll gearbeitet. Und nachdem IPSec für IPv6
geplant war, wird es auch weiter Verbreitung finden.

Literaturverzeichnis
[VPN 2001] Manfred Lipp: VPN - Virtuelle Private Netzwerke: Aufbau und Sicherheit,
Addison-Wesley (2001).
[VPN 1998] Dave Kosiur: Virtual Private Network - Building and Managing, Wiley Com-
puter Publishing (1998).
[VPN 2001 Campo] Markus a Campo, Norbert Pohlmann: Virtual Private Network, mitp
(2001).
126 LITERATURVERZEICHNIS 127

[RFC2401 1998] S. Kent, R. Atkinson: “Security Architecture for the Internet Protocol” 11 Secure Shell
RFC 2401, November 1998
Aus Anwendersicht ist Secure ShellTM (Ssh) ein Programm, um über ein Netzwerk auf einen
[RFC2402 1998] S. Kent, R. Atkinson: “IP Authentication Header” RFC 2402, November anderen Computer zuzugreifen. Einmal eingeloggt, kann man auf dem entfernten Rech-
1998 ner Befehle und Programme ausführen sowie Dateien übertragen. Ssh bietet eine starke
[RFC2403 1998] C. Madson, R. Glenn: “The Use of HMAC-MD5-96 within ESP and AH” Authentifizierung und sichere Kommunikation über unsichere Kanäle wie z.B. dem Inter-
RFC 2403, November 1998 net. Ssh soll als Nachfolger der klassischen “r”-Befehle (rsh, rlogin, rcp) sowie telnet diese
vollständig ersetzen. Zusätzlich bietet Ssh sichere X-Verbindungen und kann beliebige un-
[RFC2404 1998] C. Madson, R. Glenn: “The Use of HMAC-SHA-1-96 within ESP and AH” sichere TCP/IP-Ports in beide Richtungen durch den verschlüsselten Kanal weiterleiten.
RFC 2404, November 1998 Weiters wird unter dem Begriff Secure Shell auch das Secure Shell Protocol verstanden,
ein Protokoll zur sicheren Datenübertragung über das Internet. Von diesem gibt es zwei
[RFC2405 1998] C. Madson, N. Doraswamy: “The ESP DES-CBC Cipher Algorithm With untereinander nicht kompatible Versionen, nämlich SSHv1 (mit Unterversionen) und SSHv2.
Explicit IV” RFC 2405, November 1998
Dieses Dokument bietet eine grundlegende Einführung in Ssh und dessen Funktionen
[RFC2406 1998] Kent & Atkinson: “IP Encapsulating Security Payload (ESP)” RFC 2406, und Anwendungsgebiete. Ebenso wird eine kurze Einführung in die Kryptografie und Ver-
November 1998 schlüsselungsalgorithmen geboten und die Verwundbarkeit von unverschlüsselten Verbindun-
gen aufgezeigt. Abschließend folgt eine tiefere technische Betrachtung des SSH-Protokolls.
[RFC2407 1998] D. Piper: “The Internet IP Security Domain of Interpretation for
ISAKMP” RFC 2407, November 1998 Reinhard Hutter: hudri@[Link], Abstract, Einführung und Grundlagen
[RFC2408 1998] D. Maughan, M. Schertler, M. Schneider, J. Turner: “Internet Security
Association and Key Management Protocol (ISAKMP)” RFC 2408, November 1998 Jürgen Häuselhofer: haeuselh@[Link], SSH vs. rlogin

[RFC2409 1998] D. Harkins, D. Carrel: “The Internet Key Exchange (IKE)” RFC 2409, Lukas Gruber: luke13@[Link], Das Ssh-Protokoll im Detail
November 1998
[RFC2410 1998] R. Glenn, S. Kent: “The NULL Encryption Algorithm and Its Use With 11.1 Einführung und Grundlagen
IPsec” RFC 2410, November 1998
Mit Secure Shell bzw. Ssh wird sowohl ein kryptographisches Protokoll als auch eine konkre-
[RFC2411 1998] R. Thayer, N. Doraswamy, R. Glenn: “IP Security Document Roadmap” te Implementierung dieses Protokolls bezeichnet58 . Ursprünglicher SSH-Protokoll-Designer
RFC 2411, November 1998 und Software-Autor ist Tatu Ylönen aus Finnland, der die Secure Shell an der TU Helsinki
entwickelte und später die Firma SSH Communications Security Ltd (siehe [SSHCOMM])
[RFC2412 1998] H. Orman: “The OAKLEY Key Determination Protocol” RFC 2412, No-
gründete. Ssh ermöglicht eine kryptographisch gesicherte Kommunikation über unsichere
vember 1998
Netze und bietet dabei ein hohes Sicherheitsniveau: zuverlässige gegenseitige Authentifi-
[RFC1321 1992] R. Rivest “The MD5 Message-Digest Algorithm ” RFC 1321, April 1992 zierung der Partner sowie Integrität und Vertraulichkeit der ausgetauschten Daten. Ssh-
Implementationen befolgen das von der IETF59 gewartete SSH-Protokoll, welches mittler-
[FIPS-PUB 180-1 1993] “Secure Hash Standard” [Link] weile mehrere Versionssprünge hinter sich hat: SSHv1 mit den wichtigen Unterversionen 1.3
[Link], May 1993 und 1.5 gilt mittlerweile als veraltet und nicht mehr sicher. Aktueller Stand ist Version 2.0,
welche zahlreiche Korrekturen und Erweiterungen beinhaltet, aber leider auch nicht kompa-
[FIPS-PUB 46-2 1988] “Data Encryption Standard” [Link]
tibel zu den Versionen 1.x ist. Während Ssh anfangs als Ersatz für die unsicheren “r”-Befehle
fipspubs/[Link], January 1988
rsh, rlogin und rcp als auch für telnet gedacht war, bieten heutige Ssh-Implementationen
[VPN Consortium] “Virtual Private Networks Consortium” [Link] foun- (im besonderen die frei erhältliche und weit verbreitete OpenSSH-Implementation (siehe
ded 1999 [OPENSSH]) vom OpenBSD60 -Team) deutlich mehr Features:

[PHION Security Advisory 2002] “PHION Security Advisory 2002” [Link] Starke Verschlüsselung durch 3DES und Blowfish: Triple DES ist ein sehr guter
com/adv/, September 2002 Chiffrieralgorithmus, der zwar sehr sicher ist und eine starke Verschlüsselung bereit-
stellt, aber als nicht besonders schnell gilt. Blowfish ist ein schneller Blockchiffrierer,
[RFC2766 2002] G. Tsirtsis, P. Srisuresh “Network Address Translation - Protocol Trans-
der von Bruce Schneier entworfen wurde und von Leuten benutzt werden kann, die eine
lation” RFC 2766, February 2002
58 Im folgenden wird die Abkürzung Ssh für Secure Shell allgemein und für konkrete Implementationen

verwendet, während die Abkürzung SSH (in Grossbuchstaben) explizit das SSH-Protokoll anspricht.
59 IETF: Die Internet Engineering Task Force (siehe [IETF 2003]) ist eine offene internationale Gemein-

schaft von Netzwerkdesignern, professionellen Anwendern und Herstellern, die zur Entwicklung des Internet
und dessen reibungslosem Betrieb beitragen.
60 OpenBSD: Das OpenBSD Projekt produziert ein freies UNIX-ähnliches Betriebssystem unter besonderer

Wertlegung von Sicherheit und Portabilität.

128 11 SECURE SHELL 11.1 Einführung und Grundlagen 129

schnellere Verschlüsselung benötigen. Die Verschlüsselung beginnt vor der Authenti- 11.1.1 Kryptografie-Grundlagen
fizierung und es werden keine Passwörter oder andere Daten im Klartext übermit-
Eine Methode zur Verschlüsselung und Entschlüsselung wird als Cipher bezeichnet, dement-
telt. Verschlüsselung wird auch benutzt, um sich gegen sogenannte “spoof attacks”61
sprechend wird eine unverschlüsselte Nachricht als Plaintext oder Klartext und eine ver-
zu verteidigen, bei denen sich eine Person als jemand anderes ausgibt. Vom IDEA-
schlüsselte Nachricht als Ciphertext bezeichnet. Manche alte (oder gar altertümliche) Kry-
Algorithmus ist aus patentrechtlichen Gründen abzuraten, da er auch in Österreich
pografiemethoden beruhen auf der Gemeimhaltung der Algorithmen und sind bestenfalls
geschützt ist.
historisch interessant, aber unbrauchbar für heutige Anwendungen. Anstatt dessen verwer-
X11 Forwarding: X1162 Forwarding erlaubt die Verschlüsselung von X Window’s Netz- den alle modernen Algorithmen Schlüssel zur Kontrolle des Codierens und Entschlüsselns.
werkverkehr auf eine Weise, so dass niemand den Datenverkehr mitlesen oder bösartige Dabei gibt es zwei Arten von schlüsselbasierenden Ciphern: symmetrische und asymmetri-
Kommandos einschleusen kann. Das Programm setzt DISPLAY automatisch auf dem sche Algorithmen.
Server, und leitet jegliche X11-Verbindung über den sicheren Tunnel weiter. Gefälschte
Symmetrische Algorithmen: Bei symmetrischen Algorithmen wird für Ver- und Ent-
Xauthority Informationen werden automatisch generiert und an die entfernte Maschine
schlüsselung der selbe Schlüssel verwendet (oder der Dekodierungsschlüssel kann leicht
weitergeleitet; der lokale Client untersucht automatisch ankommende X11 Verbindun-
aus dem Codierungsschlüssel abgeleitet werden). Diese Verfahren werden auch “secret
gen und ersetzt die gefälschten Authorisierungs-Daten mit den echten Daten (und gibt
key”-Verfahren genannt. Diese unterteilen sich wiederum in stream cipher (jedes Bit
der entfernten Maschine nie die echten Informationen).
des Klartextes wird einzeln chiffriert) und block cipher (der Klartext wird zu Bit-
Port Forwarding: Port Forwarding erlaubt das Weiterleiten von TCP/IP Verbindungen Blöcken zusammengefasst und diese als Einheit verschlüsselt). Gängige symmetrische
zu einer entfernten Maschine über ein verschlüsseltes Protokoll. Standard Internet Algorithmen sind DES/3DES, Blowfish und IDEA. Symmetrische Verfahren werden
Applikationen wie POP oder IMAP können damit sicherer gemacht werden. vor allem im SSH Transport Layer Protokoll verwendet, also in der eigentlichen Da-
tenübertragung.
Starke Authentifizierung: Starke Authentifizierung schützt gegen verschiedene Sicher-
Asymmetrische Algorithmen: Im Gegensatz dazu ist bei asymmetrischen Algorithmen
heitsprobleme, z.B. IP spoofing, fake routes, und DNS spoofing (siehe Abschnitt 11.2).
der Codierungs-Schlüssel öffentlich, sodaß jedermann die Nachricht verschlüsseln kann,
Agent Forwarding: Ein Authentifizierungs-Agent, der auf der lokalen Maschine des Users aber nur der Empfänger mit dem richtigen Decodierungs-Schlüssel die Nachricht ent-
läuft, kann benutzt werden, um den RSA- oder DSA-Authentifizierungs-Schlüssel des schlüsseln kann. Daher werden diese Verfahren auch “public key” genannt. Zu den
Users bereitzuhalten. Die Authentifizierungsprotokolle geben die Schlüssel niemals bekanntesten asymmetrischen Algorithmen gehören RSA und DSA. Asymmetrische
preis; sie können nur dazu benutzt werden, um abzufragen, ob der User einen entspre- Verfahren kommen vor allem bei der Authentifizierung zum Einsatz.
chenden Schlüssel hat.
Grundsätzlich sind symmetrische Algorithmen schneller als Asymmetrische, aber in der
Plattformunabhängigkeit: Gängige Ssh-Implementationen unterstützen neben den Ssh Praxis kommt häufig eine Kombination von beiden vor (Hybrid-Verschlüsselung).
Protokollversionen 1.3 und 1.5 auch das SSH Protokoll Version 2.0. Zudem sind so-
wohl Clients als auch Server für alle gängigen Unix-, Linux- und Windows-Varianten 11.1.2 Lizenzrechtliche Fragen
verfügbar, oft sogar als freie Open Source Programme Da Ssh meist auf Unix- und Linux-Derivaten eingesetzt wird, die meist mit sehr freizügigen
Open Source-Lizenzen veröffentlicht werden, wird dies oft auch für Ssh-Implementationen
Datenkompression: Datenkompression vor der Verschlüsselung verbessert die Leistung
allgemein angenommen. Dies ist aber nicht ganz korrekt und wird durch eine Änderung der
über langsame Netzwerkverbindungen.
Lizenzpolitik des wohl bekanntesten Anbieters zusätzlich akut.
Prozessorbelastung: Durch die Verschlüsselung entsteht verständlicherweise eine zusätz- Die erste Implementation von Ssh von Tatu Ylönen und trug auch den Namen “ssh”.
liche Belastung für den Prozessor. Während dies für heutige Prozessoren und Standar- Diese wurde anfangs noch unter der GPL bzw. der LGPL63 veröffentlicht. Jedoch wurden
danwendungsgebiete absolut kein Problem mehr darstellt, kann dies für ältere Rechner bald darauf folgende Versionen unter immer strengeren Lizenzen veröffentlicht. Da jedoch
oder unter besonders zeitkritischen Anforderungen eventuell nicht vernachlässigt wer- die nichtkommerzielle Nutzung weiterhin erlaubt war und der Quellcode für diese (einge-
den. In diesen Sonderfällen sollte man das Verschlüsselungsverfahren mit Bedacht schränkte) Implementation auch weiterhin verfügbar war, blieb die Implementation von
wählen: 3DES gilt als eher langsam, Blowfish und Arcfour gelten als schnelle Algo- Ylönens Firma weiterhin sehr verbreitet. Seit Version 4 jedoch wurde Ylönens Programm-
rithmen (siehe auch Verschlüsselung bei SSH). paket in SSH Tectia umbenannt und ist nunmehr weder als Sourcecode noch als kostenloses
Programm erhältlich.
Prinzipiell gibt es keinen Grund, Ssh nicht zu verwenden! Wann immer man sich auf einem Aus diesem Grund ist vor allem im nichtkommerziellen Umfeld die OpenSSH-Implementation
entfernten Rechner einloggt, Daten überträgt oder Kommandos ausführt, sollte man Ssh des OpenBSD64 -Teams stark im Wachsen. Diese Version beruht ursprünglich auf eine sehr
gegenüber rlogin, rsh und telnet den Vorzug geben. Weiters ist SSHv2 den 1.x Versionen frühe und damit genügend freie Version von Ylönens Implementation. Sowohl das Binärpro-
immer vorzuziehen, da diese noch konzeptionelle Schwächen beinhalten. gramm als auch der Quellcode sind frei verfügbar und geschützte Teile (z.B. Bibliothe-
ken, die IDEA oder RC5 verwenden) wurden aus dem Programm entfernt und können
61 Spoof attacks: Ein Angreifer versucht eine falsche (für das Opfer vertrauenswürdige) Absenderadresse

vorzutäuschen, mit der Absicht vom Opfer wegen der gefälschten Adresse authentifiziert zu werden. 63 GPL und LGPL: Die GNU General Public Licence und die Lesser GNU General Public Licence sind
62 X11: Das X-Window System, kurz X11, ist ein hardware- und plattformunabhängige grafische Engine eine weitverbreitete Lizenz, die sicherstellt, dass die Software und deren Quellcode frei verfügbar sind.
und der Defacto-Standard in Unix- und Linux-Betriebssystemen, auf dessen Basis grafische Benutzerober- 64 Das OpenBSD Projekt produziert ein freies Unix-ähnliches Betriebssystem, dass vor allem auf Sicherheit

flächen wie Gnome und KDE laufen. und Portierbarkeit Wert legt.
130 11 SECURE SHELL 11.2 SSH vs. rlogin 131

über externe Bibliotheken eingebunden werden. Während heutzutage gängige Unix- und 11.2.3 SSH
Linux-Distributionen OpenSSH portiert und als Standard übernommen haben, gilt für die
Die erste Version von SSH wurde 1995 von Tatu Ylönen entwickelt, welcher an der Helsinky
Windows-Welt nach wie vor “SSH - don’t tell anyone it’s free”. Als kostenlose Implementa-
University of Technology als Forscher tätig ist. Im Gegensatz zu den vorher erläuterten
tion für Microsoft-Betriebssysteme sei an dieser Stelle PuTTy65 empfohlen.
Protokollen, liegt das Hauptaugenmerk von SSH auf der Authentifizierung, Verschlüsselung
und Integrität in der Nutzung von Netzwerken. SSH wurde demnach als Ersatz für die UNIX
11.2 SSH vs. rlogin r-Befehle konzipiert. 1996 wurde die zweite Version von SSH entwickelt. Die Versionen 1.x66
und 2 sind miteinander allerdings nicht kompatibel.
Vor der Entwicklung des ersten SSH-Protokolls und damit einer sichereren Kommunikati-
In SSHv2 wird das SSHv1.x-Protokoll in drei verschiedenen Schichten neu definiert, wel-
on zwischen Servern und Clients, standen viele unsichere Protokolle. So wären dies z.B.
che im nachfolgenden Kapitel (Abschnitt 11.3) genauer behandelt werden:
die r-Befehle, von denen rlogin praktisch der Vorläufer des telnet-Protokolls darstellt. In
den folgenden Unterpunkten wird auf die historische Entwicklung der SSH-Protokolle sowie 1. SSH Transport Layer Protocol (SSH-TRANS)
deren Unterschiede gegenüber anderen Protokolle erläutert. Ebenso interessieren mögliche 2. SSH Authentication Protocol (SSH-AUTH)
Attacken auf verschlüsselte und nicht verschlüsselte Kommunikationen.
3. SSH Connection Protocol (SSH-CONN)
11.2.1 r-Befehle Diese drei Protokolle sind in jeweils einem Dokument definiert, wobei noch ein weiteres
Dokument beigefügt ist, welches die Architektur beschreibt (SSH Architecture Protocol67 ).
Diese Befehle, welche aus rsh, rlogin und rcp bestehen, sind in der Unix-Welt sehr weit ver- Dieses gesamte Dokument wurde von der IETF normiert.
breitet. Die Kommunikation erfolgt hierbei unverschlüsselt. Zur Authentifizierung verlässt Die wichtigsten technischen Unterschiede zwischen den beiden Versionen sind in folgender
man sich hierbei auf das sogenannte “Trusted Host”-Konzept, welches auf einer Kombinati- Tabelle zusammengefasst:
on von Benutzernamen und Hostnamen beruht. Aus diesem Grund kann der Benutzer auf
jeglichen besuchten Maschinen eine Datei (.rhosts) anlegen, in der solche Kombinationen SSHv1.x SSHv2
gespeichert werden. Zur weiteren Sicherheit gibt es auf jedem Rechner noch eine zusätzli- integriertes Design Trennung in 3 Ebenen
che, system-weite Datei ([Link]) in welcher die vertrauenswürdigen Hosts eingetragen Integrität mittels CRC32 (sehr unsi- Integrität mittels HMAC (hash-
sind. cher) Verschlüsselung)
Ein Benutzer kann sich auf jeden Rechner einloggen, auf welchem seine Kombination nur ein Kanal per Sitzung unbeschränkte Kanal-Anzahl
in der “.rhosts”-Datei existiert. Der Zielrechner ermittelt den Namen des Benutzerrechners Aushandlung mit einzigem symm. detailierte Aushandlung (symm. Chif-
über eine Name-Server Anfrage und vergleicht ob die IP-Adresse des Rechners, sowie des- Chiffre; Indentifizierung mit eindeuti- fre, öffentlicher Schlüssel, Komprimie-
sen Name übereinstimmen. Die eben erwähnten Dateien sind auch gleichzeitig die größten gem Schlüssel auf beiden Seiten rung...); auf beiden Seiten separater
Risikofaktoren. Sitzungsschlüssel, Komprimierung und
Die r-Befehle haben drei schwerwiegende Sicherheitslücken: Integrität
Rivest-Shamir-Adleman (RSA) als Al- RSA & Digital Signal Algorithm
.rhosts: Hierbei kann ungewollt ein Angreifer Zugang zu einem oder mehreren Rechnern gorithmus für öffentlichen Schlüssel (DSA) als Algorithmus für öffentlichen
erhalten, wenn die Einträge in die Datei zu unvorsichtig durchge-führt werden. Schlüssel
Sitzungsschlüssel vom Client übermit- Sitzungsschlüssel über Diffie-Hellman-
DNS-Attacke: Hier kann es einem Angreifer durch Manipulation des Name-Servers gelin-
telt Protokoll ausgehandelt
gen, seinen eigenen Rechner als “Trusted Host” auszugeben.
Sitzungsschlüssel für ganze Sitzung Sitzungsschlüssel erneuerbar
Island-hopping: Durch die Verwendung von rlogin oder rsh kann es einem Angreifer ge- gültig
lingen von einem Rechner zum anderen zu gelangen. Im Gegensatz zu Telnet erfolgt die Authentifizierung bei SSH über einen verschlüs-selten
Kanal, in dem das Passwort eingekapselt und somit nicht mehr lesbar für Dritte ist.
11.2.2 Telnet Natürlich ist SSH wie jedes andere Protokoll nicht vor Angriffen sicher. So sind auch
hier z.B. MITM-Angriffe möglich. Ein Angreifer kann hier die Daten zwar nicht lesen, er
Terminal Emulation over Network oder kurz Telnet ist SSH sehr ähnlich. Der Unterschied kann jedoch auf die Länge des Passwortes oder der Shell-Befehle schließen und diese Daten
besteht jedoch darin, dass Benutzername und Passwort in Plain-Text übertragen werden, für Brute-Force-Attacken68 benutzen. Wie Openwall ([OPENWALL 2001]) berichtet ist es
und es somit sehr anfällig für Man-in-the-Middle Attacken (MITM) ist. Ebenso kann man sogar möglich, aus diesen Daten die RSA oder DSA Authentifizierung zu erraten.
mit Hilfe eines Monitorprogrammes einfach in den Besitz der Benutzernamen und Passwörter Unter SSHv1.x ist es möglich sogenannte “Buffer-Overflow-Attacken” durchzu-führen
der Benutzer gelangen. Wird ein solches Programm auf einem Backbone im Netzwerk in- und somit die Möglichkeit zu erlangen, beliebigen Code auf dem attackierten System aus-
stalliert, so protokolliert es danach einfach jegliche Login-Aktivitäten mit und der Angreifer zuführen, typischerweise mit “root”-Rechten. Der Buffer-Overflow wird hierbei durch den
erhält somit rasch eine Vielzahl von Benutzernamen und Passwörtern. Die Abhilfe für diese CRC32 Attack-Detection-Function hervorgerufen. Hierbei wird die Größe der Hash-Tabelle,
Sicherheitslücken stellt nun SSH dar. welche die Sitzungsinformationen speichert, auf null gesetzt.
65 PuTTy: Ein kostenloser Client für SSHv1, SSHv2 und Telnet von Simon Tatham. Weitere Informationen 66 1.x da es von Version 1 mehrere Unterversionen gibt
und das Programm selbst zum Download findet man unter [Link] sgtatham/- 67 SSH Architecture Protocol: kurz SSH-ARCH
putty/ 68 Brute-Force-Attacken: simples Ausprobieren von Passwörtern
132 11 SECURE SHELL 11.3 Protokolle 133

11.2.4 Verschlüsselung bei SSH 11.3 Protokolle

Der Vorteil des SSH-Protokolls ist die verschlüsselte Kommunikation. Nun sollen die ver- Die folgenden Abschnitte befassen sich eingehender mit dem SSH Protokoll Version 2. Das
schiedenen Verschlüsselungsverfahren, die bei SSH ihre Anwendung finden, betrachtet wer- Protokoll selbst existiert als Internet Draft ([SSH-DRAFTS 2003]) und wird von der INET
den. Alle folgenden Algorithmen sind symmetrische Verschlüsselungsverfahren. betreut. Die Protokolle auf die sich diese Ausarbeitung bezieht verlieren Ende März 2004
ihre Gültigkeit.
Data Encryption Standard (DES): Der zu verschlüsselnde Text wird hierbei zuerst per-
mutiert und substituiert und danach mit einem 56 Bit langen Schlüssel konvertiert. 11.3.1 Protokoll Architektur
Das erhaltene Ergebnis wird dann mit dem ursprünglichen Text über ein XOR mitein-
ander verknüpft. Am Ende wird dies weitere 16mal mit unterschiedlich positionierten In der Protokoll Architektur ([SSH-ARCH 2003]) sind Sicherheitskonzepte und Namensde-
Schlüsselbits wiederholt. Dieser Algorithmus sollte allerdings nicht verwendet werden, klarationen festgelegt. Es werden zwei Vertrauensmodelle propagiert. Das eine basiert auf
da er bei einer großen Angreiferzahl brechbar ist. einer lokalen Datenbank die vom Client verwaltet wird; auf längere Sicht betrachtet eine
etwas aufwendigere Methode. Sie stellt den Zusammenhang zwischen hostname und pu-
Triple DES (3DES): Basiert auf dem DES Verfahren, besitzt aber allerdings die dop- blic key dar. Das andere Modell wird durch einen zentralen CA 69 zertifizierten universal
pelte Schlüssellänge (112 Bit). Die Daten werden hierbei mit einer dreifachen DES Schlüssel realisiert (CA root key). Mit diesem einen Schlüssel könnte man alle Hosts veri-
Kombination verschlüsselt. Es werden drei verschiedene Schlüssel verwendet. fizieren, sofern sie bei einer CA certifiziert sind. Die folgenden Kapitel beleuchten die drei
wichtigsten Layer der SSHv2 Protokoll Architektur.
International Data Encryption Algorithm (IDEA): Der Schlüssel ist 128 Bit lang.
Ein 64 Bit Textblock wird in vier Teilblöcke zu je 16 Bit zerlegt, welche acht Itera- 11.3.2 Transport Layer
tionsschritte durchlaufen. In diesen Iterationen werden 3 Grundoperat-ionen mit den
Teilblöcken durchgeführt. Diese sind XOR, Addition und Subtraktion, welche mit Der “SSHv2 Transport Layer” ([SSH-TRANS 2003]) ist ein sicheres “low level” Transport
52 Teilschlüsseln kombiniert werden. Dieses Ver-fahren ist allerdings patentiert und Protokoll. Es bietet starke Verschlüsselung, kryptographische Host Authentifizierung und
unterliegt daher gewissen Lizenzbe-dingungen. bewahrt die Datenintegrität. Dieses Protokoll unterstützt nur Host basierende Authentifi-
zierung. Weiters ist das Protokoll dermaßen konzipiert, daß die Anzahl der “round trips”
70
Blowfish: Die Blockgröße beträgt hier ebenfalls 64 Bit, jedoch ist die Schlüssel-länge va- minimal ist. Die maximale Anzahl von “round trips” liegt bei 3. Port 22 wurde als re-
riabel und kann bis zu 448 Bit betragen. Die Verschlüsselung ist hier eine Art Kombi- gulärer Port für den Server bei IANA 71 registriert. Folgende Auflistung soll die wichtigsten
nation aus DES und IDEA mit dem Vorteil, dass er viel rascher terminiert. Blowfish Aufgaben des Transport Protokolles näher bringen:
ist ein freier Algorithmus.
Protokollversion: Unmittelbar nach dem erfolgreichen Verbidungsaufbau, müssen sich
Twofish: Ist ein Blockverschlüsselungs-Algorithmus und war in den finalen fünf des AES beide Seiten auf eine gemeinsame Protokollversion einigen. Der Client macht ein An-
Bewerbes. Die Blockgröße beträgt hierbei 128 Bit. Die Schlüssellänge beträgt bis zu gebot an den Server indem er seine Protokollversion als erster übermittelt.
256 Bit.
Paketformate: Das Format der einzelnen Pakete ist folgendermaßen definiert:
Arcfour: Dieser Verschlüsselungsalgorithmus ist äquivlent zum RC4-Algorithmus, welcher
bei der RSA-Authentifizierung verwendet wird. Die Schlüssellänge beträgt 128 Bit. • uint32 packet length
Arcfour gilt als das schnellste Verschlüsselungsverfahren. • byte padding length
• byte[n1] payload; n1 = packet length - padding length - 1
Cast128: Die Blockgröße beträgt bei diesem Algorithmus wie bei den meisten anderen
ebenfalls 64 Bit. Die Schlüssellängen variieren von 40 Bit bis 128 Bit in 8 Bit Schrit- • byte[n2] random padding; n2 = padding length
ten. Der Algorithmus benötigt für Verschlüsselungen mit Schlüssellängen bis 80 Bit • byte[m] mac(message authentication code); m = mac lengh
jeweils 12 Durchläufe, darüber sind 16 Durchläufe nötig. Um Brute-Force-Attacken
vorzubeugen werden meist Schlüssellängen von mindestens 80 Bit verwendet. Im “payload” steht der Inhalt des jeweiligen Paketes. Dieser kann je nach Vereinbarung
komprimiert sein. Damit die Gesamtlänge des Paketes entweder ein Vielfaches der
Hier noch eine Auflistung der verwendeten Algorithmen in Abhängigkeit der SSH-Version: “cipher block size” oder von 8 ist, wird das randomisierte “padding” hinzugefügt. Der
MAC ist optional.
Algorithmus SSHv1.x SSHv2
DES ja nein Datenintegrität: Die Datenintegrität wird durch das generieren eines MAC gewährleistet.
3DES ja ja Der MAC wird aus einer geheimen “sequence-number” und dem Inhalt des Paketes
IDEA ja nein erzeugt. Dies geschieht während dem Schlüsselaustausch.
Blowfish ja ja 69 CA: Certificate Authority - Eine Organisation die für das Internet Sicherheitszertifikate verwaltet und

Twofish nein ja ausstellt.

70 round trips: Anzahl der Versuche eine Verbindung herzustellen, wobei hiermit der Schlüsselaustausch,
Arcfour nein ja
die Server Authentifizierung, die Service Anfrage und deren Bestätigung miteinberechnet werden.
Cast128 nein ja 71 IANA: Internet Assigned Numbers Authority [Link]
134 11 SECURE SHELL 11.4 Zusammenfassung 135

mac = MAC(key, sequence-number || unencrypted_packet). “Session Identifier”: Der User Authentication Layer erhält am Anfang aus dem Trans-
port Layer den aus dem Hash H erworbenen “session identifier”.

Verschlüsselung: Alle übertragenen Informationen brauchen prinzipiell keine zusätzlichen

Key Exchange: Generell ist nur eine Key-Exchange Methode explizit definiert und zwin-
Verschlüsselungen da dies bereits der darunterliegende Layer garantiert. Passwörter
gend: der “Diffi-Hellman Algorithmus” (diffi-hellman-group1-sha1). Das Transport
werden somit aus der Sicht des User-Auth Layer unverschlüsselt übertragen.
Protokoll wurde derart entwickelt, dass es mit allen möglichen “public key” Forma-
ten, Codierungen und Algorithmen zurecht kommt. Hier ist ssh-dss (raw dss key) das
einzig zwingende “public key” Format. 11.3.4 Connection Layer
Das “KEXINIT” 72 Paket ist dafür zuständig die jeweiligen Algorithmen (mac algorithm, Das SSH Connection Protokoll ([SSH-CONN 2003]) setzt auf dem SSH Transport und SSH
encryption algorithm, etc.), Konditionen sowie die Sprache auszuhandeln. Um es für Authentication Protokoll auf. Es werden dadurch interaktive “login sessions” sowie “remote
beide Seiten unmöglich zu machen die “keys” und die “session identifier” nachvollzieh- executions” von Kommandos oder TCP/IP und “X11 forwarding” ermöglicht.
bar zu erhalten, wird ein zusätzliches cookie, welches einen randomisierten Wert hat,
im Paket eingebunden. Nachdem “KEXINIT” Paketaustausch werden die einzelnen Channel Mechanismus: Alle “terminal sessions”, “forwardings” etc. basieren auf dem
Algorithmen ausgeführt (z.B.: key exchange algorithm). Channel Mechanismus. Jeder Channel hat eine eigene Identifikationsnummer. Die
Übertragung von Daten auf einem Channel sind “flow-controlled”. Es werden keine
Daten geschickt solange der “window-space”73 nicht groß genug ist. Beide Seiten
können den “window-space” inkrementieren. Den jeweiligen Channels können je nach
Anforderungen spezielle Eigenschaften gegeben werden (z.B.: boolean want reply).
Sämtliche SSHv2 interne Kontrollnachrichten können zu jeder Zeit gesendet werden
da sie keinen “window-space” verbrauchen, zum Beispiel SSH MSG CHANNEL CLOSE. Dies
unterstüzt die Stabilität des Systems.

Interactive Sessions: Unter “Interactive Sessions” wird das Ausführen eines Programmes
(z.B.: shell, system command) verstanden, welches sich nicht auf dem lokalen Sy-
stem befindet. Mehrere “sessions” können gleichzeitig offen sein. Um Attacken von
bösartigen Servern zu vermeiden sollte jede Anfrage für einen Channel, eines Servers,
vom Client verworfen werden. Unteranderem gehöhrt auch “X11 forwarding” zu den
interaktiven “sessions”. Hierzu ist zu bemerken, dass alle später geöffneten X11 Chan-
Abbildung 64: Beispiel eines Schlüsselaustausches
nels keinen Einfluss auf den “X11 forwarded Channel” haben. Der bleibt auch bei
Schließungen von gewöhnlichen X11 Channels erhalten.
Der “key exchange algorithm” erzeugt zwei Werte: einen von beiden Seiten benutz-
baren geheimen Key K und ein Hashwert H. Diese Werte sind Grundlagen für die 11.4 Zusammenfassung
“encryption” und “authentication keys”. Zusätzlich wird der “session identifier”, der
einzigartig für jede Verbindung ist, aus dem Hashwert des ersten Schlüsselaustausches SSH ist sicherlich nicht das “non-plus-ultra” oder die Lösung aller Sicherheits-probleme bei
gebildet. Netzwerkübertragungen. Dennoch ist es ein großer Schritt in Richtung Kommunikationssi-
cherheit. Angreifern ist es dadurch beinahe unmöglich nicht berechtigten Zugriff zu Daten zu
Service Request: Nach erfolgreichen Schlüsselaustausch kann der Client ein Service vom erhalten, da die Verschlüsselungsalgorithmen inzwischen sehr ausgereift sind. Etwas später
Server beantragen. Service Namen und Formate sind im User Authentication Protokoll begann man am IPv6-Protokoll zu arbeiten, welches die Verschlüsselung bereits direkt in-
([SSH-AUTH 2003]) definiert (zb.: ssh-userauth und ssh-connection). kludiert hat. Für Interessierte hier der Link auf die IPv6 Spezifikation: [Link]

11.3.3 User Authentication Layer

Literaturverzeichnis
Das User Authentication Protokoll basiert auf dem Transport Layer. Der Servicename ist
ssh-userauth. Das Framework ist folgendermaßen definiert: [SSHCOMM] SSH Security Communications: Offizielle Homepage

[SSHFAQ 2001] Steve Acheson: The Secure Shell Frequently Asked Questions; 2001
“Public Key Authentication”: Der Server offeriert dem Client eine Anzahl an mögli-
chen Authentifizierungsmethoden. Diese folgen einem bestimmten Format. “Public [OPENSSH] The OpenBSD Project: OpenSSH - Offizielle Homepage
Key Authentication” ist wiederum die einzige Authentifizierungsmethode die obliga-
torisch ist. Alle Implementierungen müssen diese Methode unterstützen. Des weiteren [IETF 2003] Internet Engineering Task Force: Secure Shell (secsh), 2003,
existieren die “password authentication” Methode und die “host-based authentication” [Link]
Methode. 73 widow-space: Datenmenge die die jeweilige gegenüber stehende Seite momentan empfangen und verar-
72 KEXINIT: Name des Paketes welches zum Schlüsselaustausch eingesetzt wird (key exchange init) beiten kann.
136 LITERATURVERZEICHNIS 137

[OPENWALL 2001] Passive Analysis of SSH Traffic, [Link] 12 File Transfer Protokolle
[Link]
In diesem Kapitel werden das File Transfer Protocol (FTP) und seine nächsten Verwandten
[YLOENEN] Tatu Ylönen, Mat Brandy: SSH - Secure Shell, behandelt. Wobei der Schwerpunkt der Ausarbeitung auf der Client Seite liegt. Weiters
[Link] brandy/artikel/[Link] soll auch auf Probleme im Zusammenhang mit Firewalls und die Sicherheitsproblematik
von FTP im Allgemeinen eingegangen werden. Als zweiter Schwerpunkt soll das Trivial
[SSH-DRAFTS 2003] Network Working Group: SSHv2 Internet Drafts, 2003,
File Transfer Protocol (TFTP) vorgestellt werden und die Unterschied zu FTP analysiert
[Link]
werden.
[SSH-CONN 2003] Network Working Group: SSHv2 Connection Protocoll, 2003,
[Link] David Feiner: dave@[Link]

[SSH-ARCH 2003] Network Working Group: SSHv2 Architecture Protocoll, 2003, Thomas Trathnigg: tomtrath@[Link]
[Link]
12.1 Einführung
[SSH-TRANS 2003] Network Working Group: SSHv2 Transport Protocoll, 2003,
[Link] File Transfer Protokolle dienen der Übertragung von Dateien zwischen Computern. Dabei
sind die Anforderungen an das Protokoll stark abhängig von der Art des Netzwerkes und der
[SSH-AUTH 2003] Network Working Group: SSHv2 Authentication Protokoll, 2003, benötigten Sicherheit. FTP ist ein auf TCP/IP aufbauendes Anwendungsprotokoll, das zur
[Link] Übertragung von Dateien zwischen Computern im Internet dient. TFTP hingegen basiert
auf UDP und wird hauptsächlich in lokalen Netzwerken eingesetzt.

12.2 File Transfer Protocol (FTP)

Das File Transfer Protocol (FTP) ist ein Anwendungsprotokoll, das die Übertragung von
Dateien zwischen Computern über ein TCP/IP Netzwerk ermöglicht.

12.2.1 Historisches
Da die Übertragung von Dateien eine der Grundanforderungen an ein Computernetzwerk
ist wurde schon sehr früh in der Geschichte der Computernetzwerke ein solches Protokoll
entwickelt. Bereits 1971 wurde in [RFC114 1971] eine erste Variante eines solchen Proto-
kolls festgelegt. In den darauffolgenden Jahren veränderte sich dieses Protokoll jedoch recht
häufig (siehe [RFC172 1971], [RFC265 1971]). Mit [RFC354 1972] wurden die Kommandos
am Kontrollkanal per Telnet (siehe [RFC854 1983]) übermittelt. Die weiteren Entwicklungs-
schritte des Protokolls sind in [RFC542 1973] und [RFC765 1980] enthalten, bis letztendlich
mit [RFC959 1985] FTP zu einem IETF Standard wurde. Seitdem hat sich das Protokoll
kaum noch verändert, bis auf Erweiterungen bezüglich Internationalisierung und Sicherheit.

12.2.2 Grundlagen des Protokolls

FTP liegt folgendes Modell zu Grunde: Es werden zwei Verbindungen zwischen Server und
Client erzeugt. Die erste wird Kontrollkanal genannt und dient ausschließlich der Übermitt-
lung von FTP-Kommandos und den dazugehörigen Antworten. Die Übertragung erfolgt
dabei unter Verwendung des Telnet-Protokolls. Die zweite Verbindung ist der sogenann-
te Datenkanal über den die eigentliche Datenübertragung erfolgt. Als TCP-Port für den
Kontrollkanal wird standardmäßig Port 21 und für den Datenkanal Port 20 verwendet.

12.2.3 FTP Modell

Auf beiden Seiten der Verbindung gibt es einen Protcol Interpreter (PI) und einen Data
Transfer Process (DTP). Der Client-PI initiiert die Verbindung, sendet Kommandos an den
Server, bearbeitet dessen Antworten und steuert den Client-DTP entsprechend. Der Server-
PI empfängt die Kommandos des Client-PI und steuert den Server-DTP entsprechend. Der
Kontrollkanal muss während einer Datenübertragung bestehen bleiben.
138 12 FILE TRANSFER PROTOKOLLE 12.3 Trivial File Transfer Protocol (TFTP) 139

Da im Internet aus Sicherheitsgründen heutzutage viele Firewalls eingesetzt werden und

daher nicht immer ein Verbindungsaufbau vom Server zum Client möglich ist, wurde in
[RFC1579 1994] dem passiven FTP der Vorzug gegeben. Viele der heute eingesetzten FTP-
Server unterstützen daher nur mehr passives FTP.
User Die Übertragung der Daten über den Datenkanal kann in einem der 3 folgenden Modi
User
Interface erfolgen:

Stream Mode: Im Stream Mode werden die Daten als Bytestrom übermittelt. Das Ende
Server FTP Commands
User PI der Übertragung wird durch das Schließen des Datenkanals bekanntgegeben.
PI FTP Replies

Block Mode: Im Block Mode und im Compressed Mode werden die Daten in Packete
unterteilt und mit einem Header versehen. Das Ende der Übertragung wird durch ein
File Server Data User File
spezielles EOF Packet angezeigt.
System DTP Connection
DTP System

Server- Compressed Mode: Ähnlich wie der Block Mode, zusätzlich wird Run Length Encoding
FTP User-FTP zur Komprimierung verwendet.

Die Repräsentation der Daten kann wie folgt erfolgen:

• ASCII TYPE
Abbildung 65: FTP-Modell
• EBCDIC TYPE
• IMAGE TYPE
12.2.4 Verbindungsaufbau
• LOCAL TYPE
Der Client-PI baut den Kontrollkanal zum TCP-Port 21 des Servers auf und erhält bei Erfolg
vom Server eine Bestätigung. Als nächstes muss der Client sich beim Server authentifizieren. ASCII TYPE wird zur Übertragung von Textdateien eingesetzt. Bei IMAGE TYPE
Dies erfolgt mittels der Kommandos USER und PASS. Die meisten FTP-Server ermöglichen wird der Bitstream in Packeten zu jeweils 8 Bit übertragen, daher ist diese Repräsentation
auch einen anonymen Zugang, bei dem anonymous als Username und die Email Adresse für die Übertragung von binären Dateien zu verwenden.
als Passwort eingegeben werden müssen. Ist die Authentifizierung erfolgreich, so gibt der
Server eine kurze Beschreibung seiner selbst zurück. Damit ist der Kontrollkanal aufgebaut 12.2.7 Sicherheit
und der User authentifiziert.
Da bei der Authentifizierung sowohl der Username als auch das Passwort im Klartext über
den Kontrollkanal übermittelt werden, können Passwort und Username leicht in flasche
12.2.5 Verbindungsabbau Hände geraten. Weiters wird auch die eigentliche Datenübertragung unverschlüsselt durch-
geführt und auch die Integrität nicht geprüft. Ein Ansatz um das Problem der Klartext-
Der Verbindungsabbau kann auf zwei Arten erfolgen. Entweder vom User durch Senden des
passwörter in den Griff zu bekommen ist in [RFC2228 1997] beschrieben. Eine heutzutage
Kommandos QUIT, oder nach Überschreitung eines Zeitlimits vom Server.
weitaus verbreitetere Lösung ist sftp74 . Dabei wird eine SSH Kanal zum FTP-Server aufge-
baut und über diesen dann normales FTP abgewickelt.
12.2.6 Datenübertragung
Man spricht bei FTP von aktivem und passivem FTP. Damit ist die Art gemeint, wie der 12.3 Trivial File Transfer Protocol (TFTP)
zur Datenübertragung benötigte Datenkanal aufgebaut wird. Das Trivial File Transfer Protocol (TFTP) ist ein sehr einfaches Dateiübertragungspro-
tokoll das normalerweis das UDP-Protokoll als Grundlage verwendet. TFTP unterstützt
Active FTP: Der Client schickt ein PORT Kommando mit seiner IP-Adresse und dem Port, lediglich das Lesen oder Schreiben von Dateien (PUT und GET). Viele Funktion des klassi-
auf dem der Client-DTP lauscht, an den Server. Der Server baut dann die TCP/IP schen FTP wie etwa Rechtevergabe mittels chmod, Anzeigen der vorhandenen Dateien oder
Verbindung zu dem spezifizierten Port am Client auf. Benutzerauthentifizierung sind nicht implementiert.
[RFC1350 1992] beschreibt das TFTP-Protokoll. Es werden lediglich 5 Packet-Typen
Passiv FTP: Der Client schickt ein PASV Kommando an den Server. Die Antwort des
definiert: Read request (RRQ), Write request (WRQ), Data (DATA), Acknowledgment
Servers enthält die IP-Adresse und den Port des Servers auf dem er den Datenkanal
(ACK), Error (ERROR).
erwartet. Die Verbindung für den Datenkanal baut der Client auf.
Um eine Verbindung zu erstellen, bestimmen beide Hosts eine TID für sich selbst, die
zufällig gewählt werden sollte und für die Dauer der Verbindung gültig ist. Diese TIDs
Diese beiden Arten des Verbindungsaufbau für den Datenkanal sind in
werden als Quell- bzw. Zielport an den Transportlayer übergeben. Besteht die Verbindung,
[RFC959 1985] als gleichwertig beschrieben und sollten auch von jedem FTP-Server be-
ziehungsweise Client beherscht werden. 74 [Link]
140 12 FILE TRANSFER PROTOKOLLE 12.4 Zusammenfassung 141

kann der Datentransfer beginnen. Da UDP keine verlorenen Packete erkennt, definiert TFTP 12.3.3 Sicherheitsaskpekte
eine einfache Flusskontrolle (ACK, ERROR). Jedes Datenpacket ist genau 512 Bytes lang.
TFTP stellt in Hinblick auf Systemsicherheit ein beträchtliches Problem dar. Da keine
Ein kürzeres Datenpacket signalisiert das Ende der Übertragung.
Authentifizierung stattfindet, kann per TFTP nur auf öffentlich lesbare Dateien zugegriffen
In [RFC2090 1997] ist die Möglichkeit Multicast-Packete per TFTP zu verschicken vor-
werden. Es können nur solche Dateien geschrieben werden, die bereits existieren und bereits
gesehen. Durch diese Option können z.B. mehrere Computer beim Booten dasselbe Image
öffentlich schreibbar sind. Ein wichtiger Aspekt ist daher, den Zugriff des TFTP-Dämons
gleichzeitig herunterladen. Die Netzwerkeffizienz kann damit erhöht werden.
auf bestimmte Verzeichnisse einzuschränken. Ein weiteres (von FTP vererbtes) Problem ist,
In [RFC1350 1992] waren die Datenpackete auf 512 Bytes beschränkt. In [RFC2348
dass keine Verschlüsselung vorgesehen ist und daher der gesamte Datenverkehr mitgelesen
1998] wurde diese Einschränkung aufgehoben. Die Datenpackete können nun zwischen 8
werden kann. Sollte TFTP am System nicht unbedingt notwendig sein, sollte man es auf
und 65464 Bytes groß sein. Ist ein Datenpacket kürzer als die verhandelte Länge, zeigt es
jeden Fall deaktivieren.
wieder das Ende der Übertragung an.
[RFC2349 1998] erweitert das TFTP-Protokoll um 2 weitere Optionen: Server und Client
können nun über ein Timeout-Intervall verhandeln. Wird eine Datei empfangen kann eine 12.4 Zusammenfassung
maximale Dateigröße mitangegeben werden. FTP und TFTP sind bewährte Lösungen um Dateien in Netzwerken zu übertragen. TFTP
wird hauptsächlich in lokalen Netzwerken eingesetzt, unterstützt keine Authentifizierung und
12.3.1 Anwendungen basiert im Gegesatz zu FTP auf UDP. FTP benötigt zwei TCP Kanäle, wobei der Aufbau
des Datenkanals entweder aktiv oder passiv erfolgt. Beide Protokolle sind nicht zur siche-
Die Anwendungsgebiete von TFTP sind klein. Die Hauptverwendung findet es in dem Start
ren Datenübertragung geeignet, da weder sichere Authentifizierung noch Verschlüsselung
von Betriebssystemen. Viele BIOSe unterstützen heute das Booten über ein Netzwerk. Für
vorgesehen ist.
dieses Verfahren initialisiert das BIOS die Netzwerkkarte und lädt den Kernel des Betriebssy-
stems mittels TFTP von einem Server. Da TFTP auf dem verbindungslosen UDP-Protokoll
aufsetzt, kann dieses Protokoll mit wenig Aufwand in einem ROM implementiert werden. Literaturverzeichnis
Aktive Netzwerkkomponenten wie Router und Bridges verwenden TFTP, um ihre Konfi-
gurationsdateien von einem TFTP-Server zu laden. TFTP wird auch verwendet, um die [RFC854 1983] J. Postel, J. Reynolds: “TELNET PROTOCOL SPECIFICATION”
Computerarbeitsplätze in großen Netzwerken (Schulen, Universitäten, Firmen) zentral zu RFC 854, May 1983
administrieren.
[RFC114 1971] A. Bhushan: “A FILE TRANSFER PROTOCOL” RFC 114, April 1971
12.3.2 Anwendungsbeispiel [RFC172 1971] Abhay Bhushan, Bob Braden, Will Crowther, Eric Harslem, John Heafner,
Alex McKenzie, John Melvin, Bob Sundberg, Dick Watson, Jim White: “THE FILE
Der Bootvorgang einer Festplattenlosen Linux Workstation läuft im groben folgendermaßen
TRANSFER PROTOCOL” RFC 172, June 1971
ab [LinDL]:
[RFC265 1971] Abbay Bhushan, Bob Braden, Will Crowther, Eric Narslem, John Heafner,
• Nachdem der Rechner eingeschaltet wurde, wird das Boot-ROM auf der Netzwerkkarte Alex McKenzie, John Melvin, Bob Sundberg, Dick Watson, Jim White: “THE FILE
vom PC BIOS gestartet. Das Programm im Boot-ROM enthält einen Treiber für die TRANSFER PROTOCOL” RFC 265, November 1971
Netzwerkkarte.
[RFC354 1972] Abhay Bhushan: “THE FILE TRANSFER PROTOCOL” RFC 354, July
• Das Boot-ROM sucht nun nach einem BOOTP Server. Dafür werden IP Packete 1972
mit der Absenderadresse [Link] versendet. Die Identifikation der Rechner im Netz
geschieht noch über die MAC Adresse. [RFC542 1973] Nancy J. Neigus: “File Transfer Protocol for the ARPA Network” RFC 542,
August 1973
• Der BOOTP Server weist dem Programm im Boot-ROM eine IP Adresse und einige
andere Netzdaten zu. [RFC765 1980] J. Postel: “FILE TRANSFER PROTOCOL” RFC 765, June 1980

[RFC959 1985] J. Postel, J. Reynolds: “FILE TRANSFER PROTOCOL (FTP)” RFC 959,
• Über das TFTP Protokoll lädt die Workstation ein spezielles Boot Kernel Image vom
October 1985
Server und startet diesen.
[RFC1579 1994] S. Bellovin: “Firewall-Friendly FTP” RFC 1579, February 1994
• Der Linux Kernel wird gestartet.
[RFC2228 1997] M. Horowitz, S. Lunt: “FTP Security Extensions” RFC 2228, October
• Der Kernel befragt nochmals den BOOTP Server um eine IP-Konfiguration auf Ker- 1997
nelebene zu bekommen.
[RFC2640 1999] B. Curtin: “Internationalization of the File Transfer Protocol” RFC 2640,
• Der Kernel bindet über NFS die Partion mit einem Linux Dateisystem ein. July 1999

Von nun an läuft der Startvorgang wie bei einem “normalen” Linux Rechner mit Fest- [RFC1350 1992] K. Sollins: “THE TFTP PROTOCOL (REVISION 2)” RFC 1350, July
platte ab. 1992
142 LITERATURVERZEICHNIS

[RFC2090 1997] A. Emberson: “TFTP Multicast Option” RFC 2090, February 1997
[RFC2348 1998] G. Malkin, A. Harkin: “TFTP Blocksize Option” RFC 2348, May 1998
[RFC2349 1998] G. Malkin, A. Harkin: “TFTP Timeout Interval and Transfer Size Options
” RFC 2349, May 1998

[Strobel 1999] Stefan Strobel: Firewalls, 2. Auflage, dpunkt Verlag (1999).

[LinDL] Linux Festplattenlos - Eine Einführung in BOOTP und TFTP
[Link]