Ein Mehrbenutzersystem in der Praxis Netzwerk Linux/Unix

Ein Mehrbenutzersystem in der Praxis Netzwerk Linux/Unix

Ein Mehrbenutzersystem in der Praxis
Netzwerk
Linux/Unix
Kursunterlagen
-Universitäten Göttingen und Freiburg-
WLAN
Internet
WAN
192.168.1.0/24
LAN
printer
hera
zeus
.dom.test .dom.test
aphrodite
.dom.test
Dirk von Suchodoletz (dirk@goe.net)
mit Beiträgen von:
Frank Schwichtenberg
Daniel van Ross
Tim Oliver Kaiser
Steffen Wagner
Stefan Koospal
Korrekturgelesen und zusammengestellt von:
Antonia Blanke
3. Auflage
22. Mai 2006
Alle in diesem Dokument erscheinenden Produktnamen dienen nur zu Identifikationszwecken und sind Eigentum ihrer jeweiligen Besitzer.
Inhaltsverzeichnis
1 Einleitung Netzwerk
1.1 Zu diesen Unterlagen . . . . . . . . . . . . . .
1.2 Bezeichnung von Dateien und Verzeichnissen
1.3 Begriffserklärungen - Bereich Netzwerk . . . .
1.4 Begriffserklärungen - Telefonie . . . . . . . .
2 OSI-Schichtenmodell
2.1 Kategorisierungen . . . . . . .
2.2 Protokollhierarchien . . . . . .
2.2.1 Hierarchie . . . . . . . .
2.3 Motivation . . . . . . . . . . .
2.4 Die einzelnen Schichten . . . .
2.4.1 Bitübertragungsschicht
2.4.2 Sicherungsschicht . . . .
2.4.3 Vermittlungsschicht . .
2.4.4 Transportschicht . . . .
2.4.5 Sitzungsschicht . . . . .
2.4.6 Darstellungsschicht . . .
2.4.7 Verarbeitungsschicht . .
2.5 Konzepte . . . . . . . . . . . .
2.5.1 Protokolle . . . . . . . .
2.6 Einordnungen . . . . . . . . . .
2.7 Aufgaben . . . . . . . . . . . .
2.7.1 OSI . . . . . . . . . . .
2.7.2 Netzwerke . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 LAN Hardware
3.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Ethernet-Adapter . . . . . . . . . . . . . . . . . . .
3.1.2 Koaxialkabelbasierte Netze für 10 MBit . . . . . .
3.1.3 Twisted-Pair-basierte Verkabelungen 10/100 Mbit .
3.1.4 1000 Mbit . . . . . . . . . . . . . . . . . . . . . . .
3.1.5 Ethernet unter Linux . . . . . . . . . . . . . . . .
3.2 Funk-Netze . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 TokenRing . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Netzwerk-Interfaces von Linux . . . . . . . . . . . . . . .
3.5 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
9
10
12
12
12
12
13
13
13
13
13
14
14
15
15
16
.
.
.
.
.
.
.
.
.
.
.
17
17
19
19
20
20
20
22
24
26
27
27
4
INHALTSVERZEICHNIS
4 WAN Hardware
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Leistung und Kosten der einzelnen Technologien . . .
4.2.1 Leistung / Datendurchsatz . . . . . . . . . . .
4.2.2 Kosten . . . . . . . . . . . . . . . . . . . . . . .
4.3 Telefonnetze . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Das klassische Telefonnetz . . . . . . . . . . . .
4.3.2 Digitale Telefonnetze - ISDN . . . . . . . . . .
4.3.3 Mobilfunknetze nach dem GSM-Standard . . .
4.3.4 GPRS . . . . . . . . . . . . . . . . . . . . . . .
4.3.5 HSCSD . . . . . . . . . . . . . . . . . . . . . .
4.3.6 Mobilfunknetze der dritten Generation - UMTS
4.4 ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Modem . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 ADSL . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Designüberlegungen . . . . . . . . . . . . . . .
4.6.2 Übertragungsmethoden . . . . . . . . . . . . .
4.6.3 Vorteile der neuen Technik . . . . . . . . . . .
4.6.4 Benutzung unter Linux . . . . . . . . . . . . .
4.7 ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1 Die ATM-Zelle . . . . . . . . . . . . . . . . . .
4.8 FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9 Mobilfunknetze . . . . . . . . . . . . . . . . . . . . . .
4.9.1 GSM, HSCSD, GPRS und UMTS . . . . . . .
4.10 Netzwerkadapter für Mobilfunknetze . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
30
30
30
30
31
31
32
32
33
33
34
34
34
35
35
36
37
37
38
40
40
40
41
5 TCP-IP
5.1 Schaffung von ”Inter-Nets” . . . . .
5.2 Überblick über TCP/IP . . . . . . .
5.3 Design . . . . . . . . . . . . . . . . .
5.4 Internet Protocol (IP) . . . . . . . .
5.5 Spezifikation . . . . . . . . . . . . .
5.5.1 IPv4-Standard . . . . . . . .
5.5.2 Notation . . . . . . . . . . . .
5.5.3 Adressbereiche . . . . . . . .
5.5.4 Spezielle IP-Adressen . . . .
5.5.5 Private IP-Adressen . . . . .
5.6 Der IP-Header . . . . . . . . . . . .
5.6.1 Fragmentierung . . . . . . . .
5.7 IP-Routing . . . . . . . . . . . . . .
5.7.1 Prinzip der IP-Netze . . . . .
5.7.2 Routing (Die Wege im Netz)
5.7.3 Einfaches Hostrouting . . . .
5.7.4 Routingentscheidung . . . . .
5.7.5 Subnetting und Supernetting
5.7.6 QoS-Routing . . . . . . . . .
5.8 Address Resolution Protocol . . . . .
5.8.1 ARP - Hilfsprotokoll des IP .
5.8.2 Funktionsweise . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
44
46
46
48
48
48
49
50
51
52
53
53
54
55
56
56
58
60
61
61
62
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
5.9
5.10
5.11
5.12
5.13
5.14
5.8.3 ARP unter Linux . . . . . . . . . . .
5.8.4 Eingebaute Sicherheitslücken . . . .
5.8.5 Gefahrenabwehr . . . . . . . . . . .
5.8.6 ARP und doppelte IP-Adressen . . .
5.8.7 Proxy-ARP . . . . . . . . . . . . . .
5.8.8 Probleme durch Proxy-ARP . . . . .
ICMP - Internet Control Message Protocol
Domain-Name-Service (DNS) . . . . . . . .
Transmission Control Protocol (TCP) . . .
User Datagram Protocol (UDP) . . . . . . .
Ports . . . . . . . . . . . . . . . . . . . . . .
Aufgaben . . . . . . . . . . . . . . . . . . .
5.14.1 Internets . . . . . . . . . . . . . . .
5.14.2 Internet Protokoll / Header . . . . .
5.14.3 IP-Netze . . . . . . . . . . . . . . . .
5.14.4 Fragmentierung . . . . . . . . . . . .
5.14.5 IP-Routing . . . . . . . . . . . . . .
5.14.6 ARP . . . . . . . . . . . . . . . . . .
6 Linux im Netzwerk
6.1 IP-Konfiguration unter Linux . . . . . . . .
6.1.1 Die traditionellen Tools . . . . . . .
6.1.2 Routing . . . . . . . . . . . . . . . .
6.1.3 Next Generation IP-Config . . . . .
6.1.4 Das Kommando ip . . . . . . . . . .
6.1.5 Erste Schritte mit ip . . . . . . . . .
6.2 Weitergehende Anwendungen von IProute2
6.2.1 Weitere Tools . . . . . . . . . . . . .
6.2.2 Routing Policy Database . . . . . .
6.2.3 Generelle 2-Wege-Routen . . . . . .
6.2.4 Dienste-basiertes Routing . . . . . .
6.3 Überprüfung der Konfiguration . . . . . . .
6.4 Aufgaben . . . . . . . . . . . . . . . . . . .
6.4.1 IP-Konfiguration und Erreichbarkeit
6.4.2 Datenverkehr zählen . . . . . . . . .
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
64
66
68
69
70
71
72
73
75
77
78
78
78
78
79
79
80
80
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
81
81
81
82
83
83
85
86
87
88
89
91
91
91
91
92
7 DHCP
7.1 Automatische IP-Zuweisung . . . . . . . . . .
7.2 Implementation . . . . . . . . . . . . . . . . .
7.3 DHCP-Server . . . . . . . . . . . . . . . . . .
7.3.1 DHCP-Standardoptionen . . . . . . .
7.3.2 DHCP-DNS-Verbindung . . . . . . . .
7.4 Benutzerdefinierte Optionen . . . . . . . . . .
7.5 Die Verwendung von Vendor-Code-Identifiern
7.6 DHCP-Client . . . . . . . . . . . . . . . . . .
7.7 DHCP mit LDAP-Backend . . . . . . . . . .
7.8 Aufgaben . . . . . . . . . . . . . . . . . . . .
7.8.1 DHCP . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
93
93
93
96
97
98
99
100
101
104
106
106
6
INHALTSVERZEICHNIS
8 DNS
8.1 Einstieg . . . . . . . . . . . . . . . . . . . . . . .
8.1.1 Enstehungsgeschichte . . . . . . . . . . .
8.1.2 DNS - Das virtuelle IP-Telefonbuch . . .
8.1.3 Regeln für die Namensgebung . . . . . . .
8.1.4 Registrieren und Verwalten von Domains
8.2 Implementation . . . . . . . . . . . . . . . . . . .
8.2.1 Nameserver und Zuständigkeiten . . . . .
8.2.2 Caching . . . . . . . . . . . . . . . . . . .
8.2.3 Primärer und sekundäre Nameserver . . .
8.3 DNS-Server mit Linux . . . . . . . . . . . . . . .
8.3.1 Der Dämon . . . . . . . . . . . . . . . . .
8.3.2 Die DNS-Datenbank . . . . . . . . . . . .
8.3.3 Starten und Anhalten des Nameservers .
8.3.4 Slave-Server . . . . . . . . . . . . . . . . .
8.3.5 Delegation einer Subdomain . . . . . . . .
8.4 Dynamische Updates der Zonendateien . . . . . .
8.4.1 Sicherheit . . . . . . . . . . . . . . . . . .
8.5 DNS bekommt neue Aufgaben . . . . . . . . . .
8.5.1 ENUM . . . . . . . . . . . . . . . . . . . .
8.5.2 IPv6 . . . . . . . . . . . . . . . . . . . . .
8.5.3 DNS als Bannerfilter . . . . . . . . . . . .
8.6 Aufgaben . . . . . . . . . . . . . . . . . . . . . .
8.6.1 Rechnernamen im Internet . . . . . . . .
8.6.2 Domain Name Service (DNS) . . . . . . .
8.6.3 DNS Server . . . . . . . . . . . . . . . . .
9 Webserver
9.1 Überblick . . . . . . . . . . . . . . . . . . . .
9.2 HTTP-Kommunikation . . . . . . . . . . . .
9.3 Was ist ein Webserver? . . . . . . . . . . . . .
9.4 Apache 2 . . . . . . . . . . . . . . . . . . . .
9.4.1 Erweiterte Funktionalität . . . . . . .
9.5 Konfiguration . . . . . . . . . . . . . . . . . .
9.5.1 Optionen . . . . . . . . . . . . . . . .
9.5.2 Module . . . . . . . . . . . . . . . . .
9.5.3 User-WWW . . . . . . . . . . . . . . .
9.6 Webserver Erweiterungen . . . . . . . . . . .
9.6.1 Die Benutzer-Homepage - mod userdir
9.6.2 URL-Umschreiber mod rewrite . . . .
9.6.3 Zugriffskontrollen . . . . . . . . . . . .
9.6.4 Kompression . . . . . . . . . . . . . .
9.6.5 Das Web-DAV Modul . . . . . . . . .
9.6.6 Vrituelle Webserver . . . . . . . . . .
9.7 SSL (Secure Socket Layer) . . . . . . . . . . .
9.7.1 Funktionsweise . . . . . . . . . . . . .
9.7.2 Zertifikate . . . . . . . . . . . . . . . .
9.7.3 Zertifikate erzeugen . . . . . . . . . .
9.7.4 Integration . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
107
107
107
109
109
110
111
111
113
113
113
114
115
117
117
118
119
119
121
121
122
122
123
123
124
124
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
125
125
126
127
127
127
127
128
129
129
130
131
131
131
133
133
134
135
136
136
136
137
INHALTSVERZEICHNIS
9.8
9.9
9.10
9.11
9.12
9.13
9.14
9.15
9.16
9.17
7
CGI (-Modul) . . . . . . . . . .
PHP . . . . . . . . . . . . . . .
9.9.1 Das Apache-PHP-Modul
SSI (Server Side Includes) . . .
Überblick . . . . . . . . . . . .
HTTP-Kommunikation . . . .
Überblick . . . . . . . . . . . .
HTTP-Kommunikation . . . .
Überblick . . . . . . . . . . . .
HTTP-Kommunikation . . . .
Dokumentation . . . . . . . . .
10 Mail
10.1 SMTP . . . . . . . . .
10.1.1 E-Mail-Adresse
10.1.2 Versenden einer
10.1.3 Mail-Body . . .
10.1.4 E-Mail Header
10.1.5 Open-Relay . .
10.1.6 Sicherheit . . .
10.2 sendmail . . . . . . . .
10.3 exim . . . . . . . . . .
10.4 POP . . . . . . . . . .
10.5 IMAP . . . . . . . . .
10.6 Aufgaben . . . . . . .
10.6.1 Dienste . . . .
. . . . .
. . . . .
E-Mail
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
137
138
139
140
141
142
142
143
143
144
144
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
145
146
147
147
148
149
150
150
152
152
153
155
156
156
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
157
157
158
159
161
161
161
162
162
166
166
166
166
169
170
171
171
172
173
175
11 Fileserver
11.1 Unix-Netzwerkdateisystem - NFS . . . . . . .
11.1.1 NFS im Einsatz . . . . . . . . . . . . .
11.1.2 NFS und Portmapper . . . . . . . . .
11.1.3 NFS-Clients . . . . . . . . . . . . . . .
11.1.4 NFS-Server . . . . . . . . . . . . . . .
11.1.5 NFS und (Un)Sicherheit . . . . . . . .
11.2 Andrew Filesystem (AFS) . . . . . . . . . . .
11.2.1 Die Clientseite . . . . . . . . . . . . .
11.3 File Transfer Protocol . . . . . . . . . . . . .
11.3.1 Dateiarchiv - FTP-Server . . . . . . .
11.3.2 FTP-Clients . . . . . . . . . . . . . . .
11.4 Das Minimal-FTP (TFTP) . . . . . . . . . .
11.5 Weitere Fileserver-Konzepte . . . . . . . . . .
11.6 Network Block Devices . . . . . . . . . . . . .
11.7 NBDs im Einsatz . . . . . . . . . . . . . . . .
11.7.1 Erste Versuche mit NBD . . . . . . .
11.7.2 NBD und Filesysteme . . . . . . . . .
11.7.3 DNBD - eine spezialisierte Alternative
11.8 Spezielle Blockdevice-Erweiterungen . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
INHALTSVERZEICHNIS
12 Samba
12.1 Samba - Brücke zwischen Microsoft- und Unix-Welt
12.1.1 Einsatzgebiete von Samba . . . . . . . . . . .
12.2 Erste Versuche . . . . . . . . . . . . . . . . . . . . .
12.2.1 Windows-Server - Linux-Client . . . . . . . .
12.2.2 Linux-Server - Windows-Client . . . . . . . .
12.3 Weitergehende Konfiguration . . . . . . . . . . . . .
12.3.1 Homeverzeichnisse für Windows und Linux .
12.3.2 Druckerfreigaben . . . . . . . . . . . . . . . .
12.3.3 Nachrichtendienst auf Linux-Clients . . . . .
12.4 Die zentrale Samba-Konfigurationsdatei . . . . . . .
12.4.1 Struktur . . . . . . . . . . . . . . . . . . . . .
12.4.2 Wichtige Optionen in der Sektion [global] . .
12.4.3 Wichtige Optionen der anderen Abschnitte .
12.4.4 Virtuelle Samba-Server . . . . . . . . . . . .
12.5 Controller-Funktionalität . . . . . . . . . . . . . . .
12.5.1 Der Windows Namensdienst . . . . . . . . . .
12.5.2 NetBIOS Namen . . . . . . . . . . . . . . . .
12.5.3 Der Nameserver (WINS) . . . . . . . . . . . .
12.6 Samba als PDC . . . . . . . . . . . . . . . . . . . . .
12.6.1 Benutzerprofile und Logon-Skripten . . . . .
12.7 Samba und LDAP . . . . . . . . . . . . . . . . . . .
12.7.1 Konfiguration des LDAP-Servers . . . . . . .
12.7.2 Die neue Samba-Konfiguration . . . . . . . .
12.7.3 Die IDEALX-Skripten . . . . . . . . . . . . .
12.7.4 Fazit von Samba-LDAP-Aktionen . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
177
177
177
178
178
180
181
183
184
184
184
185
185
186
187
187
187
188
190
191
192
194
195
195
197
202
13 Ressourcenverwaltung
13.1 Einleitung . . . . . . . . . . . . . . . . . . . . . .
13.2 NIS . . . . . . . . . . . . . . . . . . . . . . . . .
13.2.1 Zielsetzung . . . . . . . . . . . . . . . . .
13.2.2 NIS-Datenbanken . . . . . . . . . . . . . .
13.2.3 NIS-Server . . . . . . . . . . . . . . . . .
13.2.4 NIS-Client . . . . . . . . . . . . . . . . . .
13.3 Hierarchische Datenbank: LDAP . . . . . . . . .
13.3.1 Intro . . . . . . . . . . . . . . . . . . . . .
13.3.2 Was kann mit LDAP abgebildet werden .
13.3.3 Das Datenmodell . . . . . . . . . . . . . .
13.3.4 Das Protokoll . . . . . . . . . . . . . . . .
13.4 LDAP praktisch . . . . . . . . . . . . . . . . . .
13.4.1 Server- und Clientprogramme unter Linux
13.4.2 Eine einfache Beispielkonfiguration . . . .
13.4.3 Absicherung durch SSL . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
203
203
203
203
203
204
204
204
204
205
206
209
209
209
210
213
14 Drucken im Netz
14.1 Einleitung . . . . . . .
14.1.1 Anforderungen
14.1.2 Grundlagen . .
14.2 CUPS . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
219
219
219
220
220
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
14.2.1 Client-Server-Architektur
14.2.2 IPP . . . . . . . . . . . .
14.2.3 Funktionsweise . . . . . .
14.2.4 Filter . . . . . . . . . . .
14.2.5 Konfiguration . . . . . . .
14.3 Alternativen . . . . . . . . . . . .
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
221
221
222
222
222
223
15 Wichtige Netzwerkkommandos
15.1 Offene Dateien und Netzwerkverbindungen
15.2 netstat . . . . . . . . . . . . . . . . . . . . .
15.3 Systemprogramme . . . . . . . . . . . . . .
15.3.1 Dämonen . . . . . . . . . . . . . . .
15.4 Netzwerkkonfiguration . . . . . . . . . . . .
15.4.1 Netzwerktests . . . . . . . . . . . . .
15.4.2 Netzwerküberwachung . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
225
225
225
226
226
227
227
229
16 Netzwerküberwachung
16.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.2 SNMP - Das Simple Network Mangement Protocol . . . . . . . . . . . . .
16.2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3 Die Datendefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3.1 Der SNMP-Namensraum und die Management Information Bases .
16.3.2 Die SNMP-Agenten . . . . . . . . . . . . . . . . . . . . . . . . . .
16.3.3 Der Kommunikations-Code der Agenten . . . . . . . . . . . . . . .
16.4 SNMP-Implementierungen unter Linux . . . . . . . . . . . . . . . . . . . .
16.5 Kommandos zur Datenbeschaffung . . . . . . . . . . . . . . . . . . . . . .
16.6 Konfiguration des UCD-SNMP . . . . . . . . . . . . . . . . . . . . . . . .
16.6.1 Der Kopf definiert die Zugriffs-Policies . . . . . . . . . . . . . . . .
16.6.2 Parameter der ”Enterprise”-Erweiterungen . . . . . . . . . . . . .
16.6.3 Erweiterung durch externe Skripten und Programme . . . . . . . .
16.7 Überwachung weiterer Parameter . . . . . . . . . . . . . . . . . . . . . . .
16.7.1 Weitergehende Ergänzungen . . . . . . . . . . . . . . . . . . . . . .
16.7.2 Parameter der Host-Ressource-Erweiterungen . . . . . . . . . . . .
16.8 MRTG als Frontend zur Anzeige von Zeitreihen . . . . . . . . . . . . . . .
16.9 Einige abschließende Worte zu SNMP . . . . . . . . . . . . . . . . . . . .
16.10Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
231
231
231
231
232
233
234
234
235
235
236
236
237
237
238
239
240
241
242
242
17 Systemsicherheit
17.1 Generelle Überlegungen . . . . . . . . . . . . . .
17.2 Sicherheit auf dem Rechner . . . . . . . . . . . .
17.2.1 Einleitung . . . . . . . . . . . . . . . . . .
17.2.2 Passwörter . . . . . . . . . . . . . . . . .
17.2.3 Der Admin-Account . . . . . . . . . . . .
17.2.4 /etc/passwd und /etc/shadow . . . . . . .
17.2.5 Locken oder ausloggen . . . . . . . . . . .
17.2.6 Setuid und Verzeichnisse . . . . . . . . . .
17.2.7 Setuid und Mounting . . . . . . . . . . .
17.2.8 Browser, CGI / Java-Applet und Binaries,
17.2.9 Physikalischer Zugriff . . . . . . . . . . .
17.3 Literatur . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
245
245
245
245
245
246
246
246
246
247
247
247
247
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
per Mail
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
INHALTSVERZEICHNIS
17.4 Sicherheit im Netzwerk . . . . . . . . . . . . . . . .
17.4.1 Einleitung . . . . . . . . . . . . . . . . . . .
17.4.2 Gesicherte Verbindungen . . . . . . . . . .
17.4.3 ssh und scp . . . . . . . . . . . . . . . . . .
17.4.4 Der Intenet-”Super”-Daemon (x)inetd . . .
17.4.5 xhost + und das unsichtbare Fenster . . . .
17.4.6 .rhosts . . . . . . . . . . . . . . . . . . . . .
17.4.7 Überprüfung der Netzwerksicherheit eigener
17.4.8 Firewall . . . . . . . . . . . . . . . . . . . .
17.5 Aufgaben . . . . . . . . . . . . . . . . . . . . . . .
17.5.1 Secure Shell . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
und anderer Rechner .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
248
248
248
248
249
250
250
250
251
251
251
18 Sicheres IP
18.1 Sicherheitsprobleme des derzeitigen IP-Standards
18.1.1 Intro . . . . . . . . . . . . . . . . . . . . .
18.1.2 Offener Datentransport . . . . . . . . . .
18.1.3 Absicherung - Lösungsansätze . . . . . . .
18.2 VPNs - Sichere Netze über das Internet . . . . .
18.3 CIPE . . . . . . . . . . . . . . . . . . . . . . . .
18.3.1 Idee . . . . . . . . . . . . . . . . . . . . .
18.3.2 Aufsetzen von CIPE . . . . . . . . . . . .
18.4 IPsec-Theorie . . . . . . . . . . . . . . . . . . . .
18.5 IPsec praktisch - FreeSWAN . . . . . . . . . . . .
18.5.1 Konfigurationsmöglichkeiten von IPsec . .
18.5.2 Einrichtung von IPsec unter Linux . . . .
18.5.3 Einschaltbare Optionen . . . . . . . . . .
18.5.4 Konfiguration von IPsec-Verbindungen . .
18.6 Kommerzielle VPN-Lösungen . . . . . . . . . . .
18.6.1 Cisco-VPN . . . . . . . . . . . . . . . . .
18.6.2 Verwendung der Cisco-Tools . . . . . . . .
18.6.3 Einsatzszenarien . . . . . . . . . . . . . .
18.6.4 Fazit . . . . . . . . . . . . . . . . . . . . .
18.7 Literatur . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
253
253
253
253
255
257
257
257
259
260
262
263
264
265
266
267
267
270
272
273
273
19 Firewall
19.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . .
19.2 Ein- und Austragen von chains und Filter-Regeln
19.2.1 Pakete genauer spezifizieren . . . . . . . .
19.2.2 ”Match Extensions” und Erweiterbarkeit
19.3 von ”masquerading” und ”packet mangling” . . .
19.3.1 Network Address Translation . . . . . . .
19.3.2 packet mangling . . . . . . . . . . . . . .
19.4 connection tracking . . . . . . . . . . . . . . . . .
19.5 Referenzen . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
275
275
276
276
277
279
279
280
281
282
Kapitel 1
Einleitung Netzwerk
1.1
Zu diesen Unterlagen
Der Kurs ”Linux und Netzwerke” soll in die Begriffswelt vernetzter Rechner einführen. Vorgestellt werden die Grundlagen von Netzwerken und darauf aufbauende Applikationen. Zur
besseren Einordnung der unterschiedlichen Netzwerk-Layer ist das OSI-Schichtenmodell
vorangestellt. Gefolgt wird dieses von Ausführungen zu derzeitig verfügbarer Netzwerkhardware, wie Ethernet oder Funk-Lan und verfügbaren Netzwerkanschlüssen, wie Modem,
ISDN, ATM und ADSL. Alle Erläuterungen erfolgen am Beispiel des Betriebssystems Linux. Im Zuge des Skriptes werden etliche Programme vorgestellt, welche zu Konfiguration,
Tests, Fehlersuche, Betrieb bestimmter Dienste und Abfragen dieser benötigt werden.
Diese Unterlagen wurden aus Anlass mehrerer Vorlesungen, Seminare und einiger Fortbildungskurse zum Thema “Linux und Administration in Netzwerken”, ”Linux als Beispiel
eines Netzwerkbetriebssystems” oder ”Einführung in IP-Netzwerke” zusammengestellt. Sie
sind inzwischen ein gemeinsames Projekt des Rechenzentrums der Universität Freiburg und
der mathematischen Fakultät Göttingen. Die Unterlagen werden permanent aktualisiert, jedoch können einige Teile durchaus älteren Datums sein.
Sollte es Fehler in den Texten oder Probleme geben, bitte ich Sie, mich einfach zu
benachrichtigen.1 Viele Teile stammen von Artikeln ab, die ich irgendwann mal in der
einen oder anderen Publikumszeitschrift veröffentlicht hatte.
Ich habe daher nichts dagegen, wenn diese Unterlagen ganz oder zum Teil für andere
Projekte Verwendung finden. Ich möchte dann nur auf den Haftungsausschluss hinweisen
und bitten, die Quellen zu überprüfen und gegebenenfalls zu kennzeichnen. Deshalb möchte
ich die GPL möchte auf diese Unterlagen angewandt sehen.
Das Skript erhebt keinen Anspruch auf Vollständigkeit oder Originalität. Vieles findet
man im Internet oder in Lehrbüchern ebenso gut oder besser. Dort nachzuschlagen und zu
vergleichen, sei den Lesern nachdrücklich ans Herz gelegt. Dennoch wird immer wieder ein
”eigener” Weg der Darstellung begangen, wobei manches über den normalen Umfang einer
Einführung hinausgehen kann. Dafür kommen manche traditionell breits abgehandelten
Gebiete hier recht kurz weg. Manches fehlt auch ganz, weil man es woanders leicht finden
kann. Dieses Skript will und kann kein Lehrbuch ersetzen (das brauchen Sie außerdem),
sondern ergänzen. Das “Self-Linux”-Projekt2 bietet eine vernünftige Ergänzung zu den
vorliegenden Unterlagen.
Einiges wird anders als gewohnt präsentiert. Es werden Beispiele und auch zusätzliche
Informationen angeboten, die nicht unbedingt zum Prüfungsstoff gehören, aber gut zu wis1
2
beispielsweise per Mail an dirk@goe.net
www.selflinux.org
1
2
KAPITEL 1. EINLEITUNG NETZWERK
sen sind (oder die man hier bequemer findet). Dafür entfallen viele Aspekte, die in den
Standard-Lehrbüchern gut dargestellt oder weitgehend bekannt sind. Die weiterführende
Literatur findet sich am Ende eines Abschnitts. Ich hoffe, dass diese Kursunterlagen den
Einstieg in Netzwerke und Linux in diesen erleichtern. Die Beispiele habe ich in den meisten Fällen selbst ausprobiert und Angaben aus Konfigurationsdateien stammen aus meiner
eigenen Praxis. Trotzdem können Fehler enthalten sein, die ich dann zu entschuldigen bitte
...
1.2
Bezeichnung von Dateien und Verzeichnissen
Zur Erhöhung der Lesbarkeit werden alle auführbaren Dateien/Systembefehle durch Fettdruck, z.B. dhcpd hervorgehoben. Alle Konfigurationsdateien, IP- und MAC-Adressen,
Hostnamen werden italic gesetzt, um sie vom Druckbild hervorzuheben.
Um den Lesefluss nicht stark zu stören, werden viele Erläuterungen als Fussnoten angefügt. Auch alle Links zu den entsprechenden Webseiten sind hier zu finden.
1.3
Begriffserklärungen - Bereich Netzwerk
Im folgenden werden einige Begriffe und Abkürzungen erläutert, die im Bereich Linux im
Netzwerk und Internet häufig vorkommen.
Bandbreite wird in mehreren Bedeutungen benutzt: Zum einen ist die Bandbreite ein
Mass für die Breite eines Frequenzbands. Die Differenz zwischen einer oberen und einer
unteren Grenzfrequenz, die nie über- oder unterschritten wird. So hat beispielsweise hat ein
analoges Telefonsignal, das in einem Frequenzbandbereich von 300 Hz bis 3400 Hz übertragen wird, eine Bandbreite von 3100 Hz. Andererseits ist die Bandbreite ein Mass für die
Anzahl Bits pro Sekunde, die gleichzeitig über eine Kommunikationsleitung transferiert
werden können. So hat das klassische Ethernet eine Bandbreite von 10 Mbit/s.
CSMA Carrier Sense Multiple Access beschreibt das Zugriffsverfahren für bestimmte
Broadcast-Netze, wie Ethernet oder TokenRing. Dabei gibt es zwei wichtige Ausprägungen:
CD steht für Collision Detection, das Erkennen und CA für Collision Avoidance - das
Vermeiden von Paketzusammenstößen. Ersteres ist charakteristisch für Ethernet, das Zweite
für TokenRing oder FDDI.
Datenübertragungsrate Die maximale Datenübertragungsrate R lässt sich gemäss dem
Nyquist-Theorem folgendermassen berechnen: Wenn das Signal aus V diskreten Stufen
besteht: R = 2Hlog2V Bit/s. Nach Shannon beträgt die maximale Datenübertragungsrate
R eines rauschenden Kanals mit einer Bandbreite von H Hz und einem Rauschabstand von
S/N gleich Hlog2(1 + S/N ), die maximale Anzahl von Bit pro Sekunde.
Dezibel (dB) ist ein einheitenloses Maß. Bel ist nach dem Physiker Alexander Graham Bell benannt. In der Nachrichtentechnik verwendet kommt üblicherweise die Masseinheit Dezibel (dB) zum Einsatz. Das Dezibel ist ein logarithmisches Maß. Es vereinfacht
die Berechnung der Dämpfung oder Verstärkung. Damit müssen für die Ermittlung der
Verstärkung eines Gesamtsystems nur die einzelnen dB-Werte addiert werden. Eine Rechnung der Sendeleistung (beispielsweise eines WLAN-Access-Points) addiert die Leistung
1.3. BEGRIFFSERKLÄRUNGEN - BEREICH NETZWERK
3
des Senders/Empfängers zur Leistung eines eventuell verwendeten Verstärkers und der Antennenleistung. Von diesem Wert zieht man den Leistungsverlust durch Kabel, Stecker
und eventuellem Blitzschutz ab. Eine Veränderung um 3 dB entspricht immer einer Leistungsverdoppelung oder Halbierung. Die Einheit Dezibel Milliwatt (dBm) beschreibt den
Leistungspegel bezogen auf ein Milliwatt. Die Einheit ist eine absolute Angabe. 20 dBm entsprechen einer Leistung von 100 mW, 0 dBm entsprechen 1 mW. Der Antennengewinn in dBi
beschreibt die Leistungsverbesserung gegenüber einem isotrophen Kugelstrahler. Sobald die
Leistung nicht mehr in alle Richtungen gleichmäßig, sondern bezogen auf ein bestimmtes
Raumsegment abgegeben wird, erhält man einen Gewinn.
Diskless X-Station Diskless X-Station meint Workstations auf PC-Basis. Diese Geräte
mounten ihr Dateisystem von einem Fileserver und gestatten dem Benutzer das lokale
Ausführen von Applikationen, sowie den Zugriff auf alle Laufwerke, installierte Erweiterungshardware (Audio, Video, SCSI, USB ...) und angeschlossene Perepheriegeräte.
DHCP Dynamic Host Control Protocol. DHCP basiert auf UDP und benutzt für den
Server-Kanal Port 67 und den Client-Kanal Port 68.
Durchsatz oder Datendurchsatz bezeichnet die gemessene Leistung eines Kanals und
wird in Bit pro Sekunde (bps) angegeben.
ERP und EIRP machen Angaben zur abgestrahlten Leistung von Antennen. ERP (Effective Radiated Power) gibt die effektiv abgestrahlte Leistung in der Hauptstrahlungsrichtung
der Antenne an. EIRP (Effective Isotropic Radiated Power) wird benutzt um Richtantennen zu charakterisieren. EIRP gibt an, wie stark eine ungerichtete Antenne (isotrop) senden
müsste, um die gleiche Wirkung zu erzielen wie die Richtantenne in ihrer Hauptsenderichtung.
FTP Das File Transfer Protocal ist eine der ältesten Möglichkeiten über TCP/IP Dateien zwischen Rechnern zu kopieren. Es verwendet das verbindungsorientierte TCP und
verwendet Port 23.
LAN Local Area Network. Meint Netzwerke einer geringen bis mittleren Ausbreitung,
die sich üblicherweise der Ethernet-, ATM-, TokenRing- oder FDDI-Technologie bedienen.
Latenz ist die Dauer, die eine Nachricht von einem Ende eines Netzwerks zum anderen
braucht. Die Zeitspanne, eine Nachricht von einem Ende eines Netzwerks zum anderen und
wieder zurück zu senden, wird als Round Trip Time (RTT) des Netzwerks bezeichnet, sie
bewegt sich (in den meisten Netzen) meist im Millisekundenbereich.
MIME Multipurpose Internet Mail Extension ist ein Kodierstandard, der die Struktur
und den Aufbau von E-Mails und anderen Internetnachrichten festlegt.
Modulation Unter Modulation versteht man die Veränderung von Merkmalen eines Signals, z.B. der Frequenz, Amplitude oder Phase, um Informationen zu kodieren.
NFS Network File System. NFS ist ein UDP-basiertes Protokoll, das Dateisysteme über
ein TCP/IP-Netzwerk zur Verfügung stellen kann.
4
KAPITEL 1. EINLEITUNG NETZWERK
Nyquist-Theorem besagt, dass ein Signal mit der Bandbreite H durch 2H Abtastwerte
pro Sekunde vollständig rekonstruiert werden kann. Anders ausgedrückt kann ein Signal
der Frequenz f mit 2f Abtastwerten vollständig rekonstruiert werden.
OSI-Schichtenmodell Dieses Modell der International Organization for Standardization (ISO) betrifft die Organisation von Datenfernübertragungen und veranschaulicht die
ebenenorientierte Denkweise in der Informatik.
Port Neben der IP-Adresse verfügt ein Rechner über jeweils 65.535 TCP bzw. UDPPorts. Damit wird es möglich viele verschiedene Dienste auf einem Rechner gleichzeitig
anzubieten, bzw. viele gleichzeitige Verbindunge aufzubauen.
Server Der Server ist ein Diensteanbieter im klassichen TCP/IP-Client-Server-Modell,
d.h. er stellt, meistens zentral, bestimmte Funktionalitäten, wie Mail-, File- und Webdienste
oder Applikationen zur Verfügung. Benutzer können sich an einem Server anmelden, werden
aber nur in den seltensten Fällen physisch vor dem Gerät sitzen.
Signal-Rausch-Abstand (englisch: Signal Noise Ratio (SNR) beschreibt das Verhältnis
der Signalstärke S zur Rauschstärke N , also die Intensität des thermischen Rauschens in
einem Übertragungskanal: S/N , und wird in Dezibel (dB) gemessen. Es ist ein Mass für
die Reinheit eines Signals.
SSH Secure Shell Verbindung. Diese ist dem Telnet auf jeden Fall vorzuziehen, da sie
verschlüsselt erfolgt. Das Programm auf der Serverseite heisst üblicherweise sshd, die Clientapplikation ssh.
Telnet Eines der ersten Protokolle der TCP/IP-Suite, um sich an entfernten Rechnern
anmelden zu können. Telnet verwendet als Transportprotokoll TCP und arbeitet auf Port
21. Der Daemon, d.h. der Hintergrundprozess, der den Telnet-Dienst auf einem Rechner
anbietet, heisst üblicherweise (in.)telnetd und wird meistens über den Internet-SuperDaemon (x)inetd gestartet. Die Clientapplikation heisst einfach telnet. Heutzutage aus
Sicherheitsgründen kaum noch Telnet-Server, jedoch lassen sich mit Telnet einfache Tests
auf TCP-basierte Dienste loslassen.
TFTP Trivial File Transfer Protocol. TFTP stellt eine stark vereinfachte Version des
FTP dar und arbeitet auf Basis von UDP Port 69.
UDP User Datagram Protocol. UDP ist Teil von TCP/IP und stellt eine Implementation
der Transportschicht dar. UDP arbeitet verbindungslos.
User Agent oder Benutzeragent, -programm ist ein Client Programm in Netzwerkverbindungen. Es initiiert Anfragen, beispiel ein Browser an einen Web-Server.
WAN Wide Area Network. Meint Netzwerke mit großer räumlicher Ausdehnung, die sich
üblicherweise der ISDN oder ATM Technologie bedienen. (Lichtwellenleiter, Kupferkabel)
1.4. BEGRIFFSERKLÄRUNGEN - TELEFONIE
5
XDMCP Das X display message control protocol steuert die Grafikschnittstelle auf UnixSystemen. Diese Schnittstelle ist netzwerktransparent. Dabei erfolgt die Ausgabe des Grafikoberfläche des Servers lokal auf der Maschine. Die Bentutzereingaben durch Tastatur und
Maus werden über XDMCP an den Server weitergereicht.
1.4
Begriffserklärungen - Telefonie
Im folgenden werden einige Begriffe und Abkürzungen erläutert, die im Bereich digitaler
Telefonnetze, Mobiltelefonie, Voice-over-IP, ISDN häufig verwendet werden.
ACM Die Address Complete Message signalisiert im PSTN, dass das Routing eines Telefonanrufes erfolgt ist. Üblicherweise erhält der Anrufer in der Zwischenzeit das Rufzeichen,
Ansagen wie ”The person you have called is temporarily not available”, ”This number is no
longer in service” ... Ein PSTN-2-SIP Gateway muss eine solche Meldung geeignet weitergeben - durch ”early media” (definiert in RFC2543) und/oder durch 183 Session Progress.
AIN Advanced Intelligent Network, siehe auch IN.
ANM steht für Answer Message im PSTN.
BSC
Base Station Controller.
BSS bezeichnet das Base Station System. Dieses besteht aus einem oder mehreren BSC.
BTS Base Transceiver Station .
CCI Der Call Charge Indicator ist ein ISUP Parameterfeld.
CdPN Called Party Number ist ein Teil der ISUP Message. Dieses Feld enthält den NPI
(Numbering Plan Indicator), beispielsweise ”E.164” und NOA (Nature of Address, z.B.
”national”).
CgPN
Calling Party Number ist ein weiterer Teil der ISUP Message.
CPC Die Calling Party Category ist ein ISUP Parameterfeld.
CSD Circuit Switched Data ist ein Begriff aus dem Bereich der GSM-Telefonnetze und
bezeichnet den Standard zum Datenaustausch. Die Nutzdatenrate beschränkte sich auf
maximal 9,6 kBit/s. In der GSM-Phase-2 wurde die Geschwindigkeit der Datenübertragung
auf 14,4 kBit/s erhöht, in der GSM-Phase-2+ die Bündelung mehrerer Kanäle ermöglicht.
DTAP Der Direct Transfer Application Part ist das Call Control Protocol zwischen MS
und MSC.
FCI Der Forward Call Indicator ist ein ISUP Parameterfeld.
6
KAPITEL 1. EINLEITUNG NETZWERK
GPRS Der General Packet Radio Service benötigt keine eigene Infrastruktur, sondern ist
lediglich eine Erweiterung der bestehenden GSM-Netze. GPRS-Mobiltelefone stellen für den
schnellen Austausch der Datenpakete eine dauerhafte Verbindung zu einem Einwahlpunkt
(APN = Acces Point Name) ins Netz her. Für die Datenkommunikation wird es Endgeräten
erlaubt mehrere GSM-Kanäle zusammenzufassen und für die Kommunikation zu reservieren. Bandbreiten in Funknetzen haben immer ein Problem: Alle Nutzer einer Zelle teilen
sich ein gemeinsames Medium. Wollen alle gemeinsam zugreifen, sinkt für jeden einzelnen
die erreichbare Datenrate. n der Einführungsphase von GPRS wurde netzseitig eine Bandbreite von 53,6 kbit/s (4 Kanäle à 13,4 kbit/s) pro Funkzelle vorgesehen. Stehen alle acht
Kanäle für GPRS zur Verfügung, würde die Bandbreite auf 107,2 kbit/s steigen. Weitere
Steigerungen durch bessere Fehlerprotokoll erlaubten theoretische 171,2 kbit/s (acht Kanäle
a 21,4 kbit/s). Mobiltelefone arbeiten momentan mit 13,4 kbit/s pro Kanal. Sie können je
nach Gerät zwei bis drei Kanäle zusammenfassen.
GMSC
Gateway Mobile Switching Centre.
GSM Global System of Mobile Telecommunication bezeichnet allgemein den weltweiten
Generation 2 Standard digitalen Mobilfunks.
HLR Home Location Register
HSCSD High Speed Circuit Switched Data, der Nachfolger von CSD, erreicht eine maximale Datentransferrate von 57,6 kBit/s. Der Unterschied zwischen den beiden Systemen
liegt in den verwendeten Protokollen und der Übertragungstechnik. Wie bei einer Telefonleitung steht bei HSCSD jedem User ein dedizierter Nutzkanal exklusiv zur Verfügung. Die
Zahl der gleichzeitig aktiven Teilnehmern ist für die verfügbare Bandbreite nicht relevant
und nur durch die maximale Zellkapazität (bezogen auf aktive Teilnehmer) beschränkt.
IAM steht für Initial Address Message im PSTN und ist Bestandteil des ISUP. IAM
entspricht der ISDN Message ”Setup” und der SIP Message INVITE.
IMSI Die International Mobile Subscriber Identity ist auf der SIM-Karte hinterlegt. Sie
besteht aus maximal 15 Ziffern, wobei die ersten drei Ziffern für die MCC und die folgenden zwei oder drei Ziffern für die MNC vorgesehen sind. Dabei bezeichnet MCC den Mobile
Country Code und MNC (Mobile Network Code) den Betreiber des Mobilfunknetzes innerhalb eines Landes. Unterhalb des MCC ist der MNC immer einheitlich zwei oder drei
Ziffern lang. Der Rest ist die MSIN, Mobile Subscriber Identification Number. Sie dient zur
Identifikation eines Benutzers im PLMN.
IN Intelligent Network meint in der Telco-Szene moderne digitale circuit-switched Telefonnetze, die noch großartigere Form wird mit AIN bezeichnet.
Interface Anders als in paketorientierten IP-Netzwerken, wo die Einhaltung von (offenen) Protokollen und Standards eine wesentliche Voraussetzung ist, spielen im Bereich
klassische Telefonie Interfaces eine große Rolle für die Signalisierung zwischen Komponenten des Netzwerks. So bezeichnet das A Interface die Verbindung zwischen MSC und BSC,
Abis liegt zwischen BSC und BTS, D zwischen MSC und HLR und Um für die Funkverbindung zwischen MS und BTS. Im Bereich des ISDN bezeichnet S0 die Schnittstelle zwischen
1.4. BEGRIFFSERKLÄRUNGEN - TELEFONIE
7
NTBA und den Endgeräten, wie ISDN-Telefon oder AB-Wandler. Uk0 ist die ZweidrahtKupferschnittstelle zwischen NTBA und Vermittlungsstelle.
ISDN Integrated Services Digital Network ist ein weltweiter Standard der leitungsvermittelten (circuit-switched) Telefonie. Endbenutzer haben mit dem sogenannten Basic Rate
Interface (BRI) zu tun. Grosse Nebenstellenanlagen sind mittels Primary Rate Interfaces
(PRI) mit dem öffentlichen Telefonnetz verbunden.
ISUP Der ISDN User Part regelt die Inter-Circuit-Signalisierung von Anrufen und ist für
deren Auf- und Abbau zuständig. Diese kann mittels SS7 oder alternativ mittels D-Kanal
(Q.931) erfolgen. ISUP beinhaltet folgende Felder: IAM, CgPN, CdPN, USI, FCI, CPC,
CCI.
MSC Das Mobile Service Switching Centre ist die zentrale Schaltstelle im TelefonieNetzwerk. Es ist verbunden mit dem Radio Access Network (RAN), welches von den BTS
und BSCs gebildet wird, welche wiederum das Public Land Mobile Network (PLMN) bilden.
MISDN Die Mobile Station ISDN Number wird dazu verwendet Benutzer zu identifizieren, wenn Verbindungen aufgebaut werden. Sie besteht aus maximal 15 Ziffern,3 wobei die
ersten eins, zwei oder drei Ziffern für den Country Code (CC) und anschliessende Ziffern
für den National Destination Code (NDC) stehen. Letzterer bezeichnet üblicherweise die
”Vorwahlen” der diversen Mobilfunkanbieter. Der Rest ist dann die Subscriber Number
(SN), welche den Benutzer innerhalb eines PLMN Nummernplans einsortiert. Die MISDN
ist dabei nicht(!) auf der SIM gespeichert und ist nicht auf der MS feststellbar. Unabhängig
davon kann sich jeder die Nummer natürlich irgendwo hin speichern, was aber für das Netz
keine Auswirkungen hat.
MS Die Mobile Station ist das Benutzerendgerät in Mobilfunknetzen, welches man in der
Hand hält. Dieses besteht aus dem Mobiltelefon, dem Mobile Equipment (ME) und der
SIM-Card. Jedes Mobiltelefon hat eine eindeutige Kennung (IMEI - International Mobile
Equipment Identifier), die hardcodiert im Gerät hinterlegt ist.
MSRN Die Mobile Station Roaming Number ist eine temporäre Nummer, die einer MS
zugeordnet wird, wenn eine Verbindung aufgebaut wird. Dieses ist notwendig, da zwar die
MISDN einen Benutzer identifiziert, aber nichts darüber aussagt, wo er sich gerade befindet.
PBX
Private Branch eXchange meint die Endbenutzer Vermittlungsstelle.
PLMN Public Land Mobile Network. So sind GSM und UMTS Beispiele für PLMNs.
GSM unterscheidet hier noch in Home PLMN (HPLMN), Visited PLMN (VPLMN) und
Interrogating PLMN (IPLMN)
3
Im Gegensatz zu den bekannten IP-Adressen handelt es sich hier um aufeinanderfolgende Dezimalziffern. Das liegt an der langen Historie von Telefonnetzen, die traditionell Teilnehmern Ziffernfolgen des
Dezimalsystems zuordnen.
8
KAPITEL 1. EINLEITUNG NETZWERK
POTS Plain Old Telephony System bezeichnet oft die klassische ”Analog”-Teleonie über
die 2-Draht-Kupferleitung.
PSTN Das Public Switched Telephone Network meint das klassische System der (digitalen) Telefonie. Üblicherweise wird hierfür ISDN eingesetzt.
REL
ist eine ISUP Message (Release) und entspricht dem ”Release” des ISDN.
RLC ist eine ISUP Message (Release complete) und entspricht dem ”Release Complete”
des ISDN.
SIM Subscriber Identification Module ist ein Chip (auf einem genormten Stück Plastik,
das in das ME gesteckt wird), welcher den sogenannten Subscriber (Mobilfunkbenutzer)
gegenüber dem GSM-Netz identifiziert.
SIP Session Initiation Protocol ist ein Application Layer Protocol welches auf Basis von
TCP oder UDP Session-Setup, In-Session-Info und Session-Close-Services für interaktive
Dienste wie Telefonie, Video-Conferencing oder Multi-User-Games zur Verfügung stellen
kann.
SS7 Das Signalisierungs System (Signaling System) 7 ist ein Standard der Out-of-BandSignalisierung in digitalen Telefonnetzen.
UTMS Hinter der Abkürzung Universal Mobile Telecommunications System steckt der
1998 von der ETSI (Abkürzung für European Telecommunications Standard Institute)
vorgestellte Breitband-Mobilfunkstandard der 3. Generation (G3). Die Weiterentwicklung
und Pflege des Standards unterliegt inzwischen dem 3GPP (3rd Generation Partnership
Project). Zu den wesentlichen Leistungsmerkmale von UMTS zählt die Übertragung von
Sprache und Audiodaten, die Übermittlung von multimedialen Inhalten sowie der schnelle
Zugriff auf das Internet. UMTS ermöglicht Datenübertragungsraten von 364 kbit/s bis zu
2 Mbit/s, womit Streaming Video und Audio Übertragung, sowie Bildtelefonie ermöglicht
werden sollen. Diese Übertragungsraten erreicht UMTS durch den asynchronen Transfermodus kurz ATM-Verfahren im sogenannten Codemultiplexverfahren. Als Funk-Technologie
kommt Wideband CDMA (WCDMA) im Frequenzbereich um die 2 GHz zum Einsatz.
VLR Visitor Location Register ist ein Begriff auf dem Bereich digitaler Mobilfunknetze
der zweiten (GSM) und dritten Generation (UMTS).
Kapitel 2
OSI-Schichtenmodell
2.1
Kategorisierungen
Computernetze sind durchaus komplex aufgebaut. Nicht jede Applikation soll diese Komplexität jeweils nachvollziehen müssen. An dieser Stelle wird wiederum Abstraktion verlangt. Dies ist durchaus vergleichbar mit den Aufgaben von Betriebssystemen, welche die
Hardware virtualisieren. Eine ”saubere” Trennung der Aufgaben (im Sinne der Programmierung von Schnittstellen) ist erforderlich. Sonst wären Applikationen schwer zu warten,
schlecht erweiterbar und im Laufe ihrer Weiterentwicklung kaum überschaubar. Deshalb ist
ein strukturierter Aufbau notwendig. Hierfür erfolgt die Vereinbarung von Protokollen und
die Definition von Schnittstellen.
Für die Modellierung von Netzwerken bietet das OSI-Schichtenmodell eine Orientierung.
Dieses schafft eine hierarchische Aufteilung der Hardware und Programme in Module, die
jedoch durchaus von sehr verschiedenen Lieferanten stammen können.
2.2
Protokollhierarchien
Protokolle sind Regeln, die den Austausch von Nachrichten - oder allgemeiner das Verhalten
- zwischen (Kommunikations-) Partnern regeln (”Protocols are formal rules of behaviour”).
Die Verletzung eines vereinbarten Protokolls erschwert die Kommunikation oder macht sie
sogar gänzlich unmöglich.
Ein Beispiel für ein Protokoll ”aus dem täglichen Leben” ist z.B. der Sprechfunkverkehr:
Die Kommunikationspartner bestätigen den Empfang einer Nachricht mit ”Roger” und
leiten einen Wechsel der Sprechrichtung mit ”Over” ein. Beendet wird die Verbindung
schließlich mit ”Over and out”.
Ähnliche Protokolle werden auch beim Datenaustausch zwischen verschiedenen Computern benötigt - auch wenn hier die Komplexität der Anforderungen etwas höher ist.
Aufgrund dieser höheren Komplexität werden viele Aufgabe nicht von einem einzigen Protokoll abgewickelt. In der Regel kommen eine ganze Reihe von Protokollen, mit verschiedenen Teilaufgaben, zum Einsatz. Diese Protokolle sind dann in Form von Protokollschichten
mit jeweils unterschiedlichen Funktionen angeordnet.
2.2.1
Hierarchie
Jede Schicht n enthält Instanzen für den Datenaustausch mit der Partnerinstanz der gleichen Schicht n in anderen Computern. Die Vereinbarungen, nach denen diese Kommunikation abgewickelt wird, nennt man das Protokoll der Schicht n. Praktisch kommunizieren die
9
10
KAPITEL 2. OSI-SCHICHTENMODELL
Schichten nicht direkt miteinander, sondern jede Schicht gibt der darunterliegenden Schicht
die Daten und Steuerinformationen. Man kann sich vorstellen, dass jede Schicht (bis auf
die unterste Schicht, die nur für das Senden und Empfangen eines nicht formatierten Bitstroms zuständig ist) die erhaltenen Daten in einen Umschlag steckt, in dem zusätzlich
Informationen für die korrespondierende Schicht auf der anderen Maschine stecken, die für
die korrekte Wiederherstellung der Daten nötig sind. Auf der untersten Schicht (Schicht
1) findet die tatsächliche Kommunikation auf dem darunterliegenden Medium statt. Auf
der anderen Maschine werden nun die Daten von der untersten Schicht in Empfang genommen und an die Schicht 2 übergeben. Diese öffnet den Umschlag und stellt mit den darin
enthaltenen Informationen die korrekte Nachricht für Schicht 3 wieder her. Dies geschieht
solange, bis die oberste Schicht erreicht ist. Diesen Satz von Schichten und Protokollen
nennt man Protokollarchitektur. Das Schichtenmodell und die Protokollarchitektur, sowie
die standardisierten Kommunikationsprotokolle bilden das OSI-Referenzmodell.
2.3
Motivation
Der Name des Modells lautet “Open Systems Interconnection”. Dieses Referenzmodell ist
als Vorschlag für die Standardisierung von Netzwerkprotokollen durch die ISO entstanden.
Es wurde etwas später bzw. in gewissem Maße zeitgleich zu TCP/IP vorgeschlagen. Es
sollte deshalb eher als theoretisches Konzept denn als technische Leitlinie der Entwicklung
von Netzwerkschichten verstanden werden.
Layer
7
Name of Unit
Application
Application
ftp,http,smtp,pop3
6
Presentation
Presentation
A
5
Session
4
Transport
3
Network
Session
TCP, UDP, SPX, Appleshare
Transport
IP, IPX, Appletalk
Network
Packet
Data link
Frame
Physical
Bit
N
Ethernet-, ATM-Switch
2
Data link
1
Physical
Ethernet, TokenRing, ISDN
Host A
Host B
Real Connection
Virtual Connection
A
User-Application
N
Network-Protocol
Flow of Data from A to B
Abbildung 2.1: OSI-Schichtenmodell
Kaum ein Protokoll für Internets setzt alle Vorschläge des Schichtenmodells um. Trotzdem ist es hilfreich für die Strukturierung und Abgrenzung von Netzwerkprotokollen und
zum Verständnis für die Funktion von Netzwerken.
2.3. MOTIVATION
11
Hardware (-nahe) Protokolle für LANs und WANs lassen sich mit OSI erklären und
einordnen. Auch die Abbildung der Dienste der TCP/IP-Suite kann innerhalb des OSIModells erfolgen. Die Kommunikation zwischen verschiedenen Hosts läßt sich anhand von
OSI gut veranschaulichen. Deshalb wird dieses durchaus immer noch erwähnt bzw. gelehrt.
Die sieben Schichten entstammen folgenden Designprinzipen:
• Eine Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird
• Jede Schicht soll genau definierte Funktionen erfüllen
• Bei der Funktionswahl sollte die Definition international genormter Protokolle berücksichtigt werden
• Grenzen zwischen Schnittstellen so wählen, dass möglichst wenig Informationsfluß
über Schnittstellen notwendig wird
• Es sind so viele Schichten vorzusehen, dass keine Notwendigkeit besteht mehrere verschiedene Funktionen in einer Schicht zu implementieren
Schichten von unten nach oben (d.h. ausgehend von der Hardware hoch zur Applikation)
sind in der Tabelle dargestellt.
#
7
Schicht
Layer
(engl.)
Anwendungs- application
-
Orientiert
Aufgabe
Anwen-dungs-
Verbindung zwischen
Benutzern
und deren Tätigkeiten
Datenformat des
Informationsaustausches
Verbindung zwischen
Prozessen
auf verschiedenen
Rechnern
Zusammensetzung
der Nachrichten
Adressierung
der
Nachrichten
zwischen Rechnern
Beseitigung
von
Übertragunsfehlern
durch
Störungen
Betrieb der Netzkarten
6
Darstellungs- presentation Anwendungs-
5
Kommunika- session tionssteuer-
Anwendungs-
4
Transport-
Transport-
3
Vermittlungs- network -
Transport-
2
Sicherungs-
data link -
Transport-
1
Bitübertragungs-
physical -
Transport-
transport -
Prot.
FTP
TCP
TCP
IP
Tabelle 2.1: Das OSI-Modell mit Beispiel FTP als TCP/IP-Protokoll
12
KAPITEL 2. OSI-SCHICHTENMODELL
2.4
Die einzelnen Schichten
Im OSI-Modell sind die Schichten 1 - 4 transportorientiert; sie entsprechen den verschiedenen Netzwerkprotokollen, welche in der Netzwerkhardware oder im Betriebssystem implementiert sind. Die Schichten 5 - 7 arbeiten anwendungsorientiert; sie finden üblicherweise
innerhalb einer Anwendung statt. Jede Schicht soll sich dabei nur der Dienste der darunterliegenden Schicht bedienen. Die Implementation ist dabei beliebig, d.h. liegt im Ermessen
des Anwenders oder Netzwerkdesigners. Der Austausch von Schichten soll dabei möglich
sein, wenn die neue Schicht die Funktionen der alten zur Verfügung stellt.
Die Aufgaben der einzelnen Schichten lassen sich wie folgt beschreiben:
2.4.1
Bitübertragungsschicht
regelt die Übertragung von ”rohen” Bits über den Kommunikationskanal. Dabei handelt
es sich um einen unstrukturierten Bitstrom. Die Bitübertragungsschicht enthält die Definition, welcher elektrischer, physikalischer Zustand einer binären ”Null” bzw. einer ”Eins”
entspricht. Dazu zählt beispielsweise, welche Länge ein bestimmter Zustand andauern muss
oder mit wieviel Volt signalisiert wird. Weiterhin erfolgt die Festlegung, wie gross bestimmte Toleranzen sein dürfen, damit ein Signal noch interpretiert werden kann und welche
Abstände zwischen verschiedenen Zuständen liegen, damit diese sauber interpretiert werden können.
Weiterhin zählt dazu die Festlegung von Kabeltypen und -qualitäten (optisch bzw. elektrisch) oder die Definition von Funkstandards für drahtlose Übermittlung. Bestandteil ist
weiterhin die Definition von Steckern und Buchsen, die Anzahl benötigter Adern und die
full- oder halfduplex Datenkommunikation.
2.4.2
Sicherungsschicht
übernimmt die Umwandlung des rohen Datenkanals der Bitübertragungsschicht in eine
Leitung, welche virtuell frei von unerkannten Übertragungsfehlern ist. Dies geschieht durch
die Aufteilung des Datenstroms in Frames1 . Dabei erfolgt das Setzen von Rahmengrenzen
durch spezielle Kontrollbits. Weiterhin werden einfache Prüfmechanismen geschaffen z.B.
durch die Einführung von CRC-Prüfsummen. Die Sicherungsschicht erlaubt weiterhin eine
Datenverkehrskontrolle. Sie kann Meldungen von Überschwemmungen eines Empfängers
generieren. Darüberhinaus regelt sie die Zugriffssteuerung in Broadcastnetzen.
2.4.3
Vermittlungsschicht
sichert die Steuerung des Teilnetzbetriebes. Sie ist sozusagen verantwortlich für die Auswahl
der Paketrouten auf dem Weg vom Ursprungs- zum Bestimmungsort. Die auftretenden
Routen können statisch, d.h. fest verdrahtet sein oder dynamisch für jede Sitzung festgelegt
werden. Es geht auch noch dynamischer: Für jedes Paket einer Sitzung wird eine Route
generiert.
Bei Überlastungen der Teilnetze mit zuvielen Paketen muss eine Engpass- bzw. Stausteuerung erfolgen. Darüberhinaus können Abrechnungsfunktionen2 in dieser Schicht implementiert sein. Die Vermittlungsschicht überwindet verschiedene Hardwareprotokolle. Sie
kann Pakete in die angepaßte Größe für jedes Teilnetz umbauen.
1
anderer Name für Paket, um die Daten”häppchen” der verschiedenen Schichten unterscheiden zu können
z.B. für die Paketdurchleitung; da kaum ein Anbieter jede End-zu-Endverbindung im eigenen Netz
realisieren kann
2
2.5. KONZEPTE
2.4.4
13
Transportschicht
ist für die Entgegennahme der Daten aus der Sitzungsschicht verantwortlich. Die Transportschicht regelt gegebenenfalls die geeignete Zerstückelung des eintreffenden Datenstromes.
Diese Daten werden an die Vermittlungsschicht weitergegeben.
Die Transportschicht bietet eine End-zu-End-Kontrolle der Korrektheit der Pakete und
deren Reihenfolge. Dadurch erhält der Anwender einen fehlerfreien Punkt-zu-Punkt-Datenkanal. Die Transportschicht ist echte End-zu-End-Schicht, d.h. sie stellt die Ebene dar, auf
der Programme Informationen miteinander austauschen können. Weiterhin erlaubt sie das
Multiplexen mehrerer Datenströme, da ein Host durchaus mehrere Verbindungen unterhalten kann.
2.4.5
Sitzungsschicht
soll den Benutzern an verschiedenen Maschinen erlauben, Sitzungen miteinander aufzubauen, d.h. einerseits einen gewöhnlichen Datentransport zu realisieren, aber auch zusätzliche
Dienste anzubieten. Dialogsteuerungen und Tokenmanagement einiger Anwendungen könnten in der Sitzungsschicht verortet werden. Weitere mögliche Aufgaben wären die Synchronisation z.B. Recovery eines Datenstransfers nach einem längerem Ausfall. Die genannten
Beschreibungen deuten bereits an, dass diese Schicht sich schwer abgrenzen läßt.
2.4.6
Darstellungsschicht
realisiert Funktionen, die sich mit Syntax und Semantik der übertragenen Informationen
beschäftigen. Hierzu zählt die Kodierung der Daten auf vereinbarte Weise3 . In der Darstellungsschicht erfolgt die Umwandlung spezieller Daten- und Objektstrukturen eines Rechners
in die für die Netzübertragung geeignete Form.
2.4.7
Verarbeitungsschicht
wird in einigen Darstellungen auch Anwendungsschicht genannt. Sie bezieht sich auf die
letztendlich auf einem Host ablaufenden Netzwerk-Applikationen. Diese können z.B. eine
einheitliche Terminalemulation4 umfassen, die eine Vielzahl sehr unterschiedlicher Terminaltypen darstellen kann. Damit wird anderen Programmen (und deren Programmierern)
die Ausgaben von Text und die Entgegennahme von Tastatureingaben erleichtert.
Weiterhin könnte die Verarbeitungsschicht den Dateitransfer über verschiedene Standards von Dateisystemen und Namenskonventionen hinweg organisieren. Diese Erörterungen lassen sich ebenso auf Email-, Webdienste etc. anwenden.
2.5
Konzepte
Für den Zusammenschluss verschiedener Netze sind spezielle Hardwarekomponenten notwendig. Diese regeln die Übergänge zwischen verschiedenen Teilnetzen und Netzwerktechnologien, die sich sowohl im Medientyp, den Adressierungsschemata und den Frameformaten
unterscheiden können.
3
little- oder bigendian, ASCII oder Unicode, Kodierung negativer Ganzzahlen als Einer- oder Zweierkomplement, ...
4
Mit ”Terminals” sind im heutigen Sprachgebrauch die virtuellen Nachbildungen der meist seriellen
Datensichtgeräte an Workstations oder Mainframes gemeint.
14
KAPITEL 2. OSI-SCHICHTENMODELL
Diese Hardwarekomponenten können wie Hosts mit mindestens zwei Interfaces aufgefaßt
werden. Sie sollen sich wie ein Host5 im jeweiligen Teil-Netz verhalten, wobei die Zahl von
Übergängen zwischen verschiedenen Netzwerken möglichst nicht begrenzt sein sollte. Hierfür
dient der Einsatz sogenannter ”Router”.
Weiterhin:
• Schaffung eines Adressierungsschemas, welches hardwareunabhängig (z.B. von der
Ethernetadressierung) ist
• Schaffung eines virtuellen Netzes; die Netzstuktur dieses ”Super”-Netzes muss von
Topologie und Ausdehnung der darunterliegenden Netze unabhängig sein
• abstraktes Kommunikationssystem, .h. Soft- und Hardwarelösungen bilden eine Illusion eines gemeinsamen übergreifenden Netzes
2.5.1
Protokolle
”Protokoll” dient als gemeinsame Vereinbarung (Standard) über die Kommunikationsparameter. Es wurden verschiedene Protokolle für den genannten Aufgabenbereich geschaffen:
• TCP/IP als bekanntester Vertreter dieser Gruppe, da das weltweite Internet dieses
verwendet
• IPX/SPX als Netzwerkprotokoll von Novell
• Appletalk: Netzwerkdienst der Apple-Macintosh-Architektur
• DECnet: Vernetzung von Unix-Workstations
• X25: ITU-Standard für WAN-Technologien, Angebot von Telefongesellschaften
Diese Protokolle besitzen Routingfähigkeit, d.h. verschiedene Netze können über spezielle
Rechner (Router) miteinander gekoppelt werden. Sie bieten einen einheitlichen bzw. ”globalen” Adressraum und sind für verschiedene Netzwerkhardware verfügbar. Andere Protokolle, z.B. NetBIOS von Microsoft, sind nur im LAN einsetzbar, weil sie über kein globales
Adressschema verfügen, nicht routingfähig sind und nur auf bestimmte Netzwerkhardware
anwendbar sind.
Mit der Ausdehnung der Firmennetze, dem Ausbruch des Rechners aus dem Rechenzentrum, der Popularisierung von Computern spielen Netzwerke eine immer größere Rolle.
Deshalb wurde ein allgemein standardisiertes, nichtproprietäres Netzwerkprotokoll gesucht,
welches gleichzeitig die Unabhängigkeit von bestimmten Herstellern besitzt. Betriebserfahrungen und Robustheit im Einsatz waren weitere Argumente. Die TCP/IP-Suite hat sich
umfassend durchgesetzt; andere Protokolle sind nur mehr Randerscheinungen.
2.6
Einordnungen
Nach dem Aufbau eines Theoriegerüstes in Form des OSI-Modells, läßt sich nun eine Einordnung der im Folgenden vorgestellten Netzwerkprotokolle in einem kurzen Ausblick vornehmen. Dabei wird sichtbar, welche Protokolle jeweils für die Umsetzung bestimmter Aufgaben
benötigt werden.
5
einfaches Mitglied in einem Netzwerk
2.7. AUFGABEN
15
Ethernet, TokenRing, ADSL, ISDN oder Modem definieren in erster Linie verschiedene Typen von Bitübertragungsschichten. Sie stellen die Übertragungsstandards, was Kabel
und elektrische bzw. optische Signalisierung, Verbindungslängen etc. betrifft, sicher. Sie bestimmen außerdem die Datenraten und Half- oder Fullduplex-Betrieb, sowie die Kodierung
der Daten für beste Erkennung und höchste Datenraten.
Weiterhin implementieren Ethernet- und TokenRing jeweils die Medienzugriffsverfahren,
wie CSMA/CD oder CA6 , die der Sicherungsschicht zuzuordnen sind. MAC-Adressierung
ist ebenfalls ein Konzept der Sicherungsschicht. Ethernetswitches arbeiten auf dieser und
schalten virtuelle Punkt-zu-Punkt-Verbindungen auf dieser Ebene. Ethernet implementiert
weiterhin Verfahren zur Congestioncontrol. Auch Korrekturverfahren, wie sie bei Modemkommunikation definiert werden, sind der Sicherungsschicht zuzuordnen.
Das Internet-Protokoll läßt sich der Vermittlungsschicht zuordnen. Es übernimmt die
Paketadressierung der End-zu-End-Zustellung und implementiert die Routingfunktionalitäten. IP kann dabei auf austauschbare Bitübertragungs- bzw. Sicherungsschichten zurückgreifen. Es kann über Ethernet, GPRS, ADSL, ISDN oder Modem ohne Änderungen im
Protokoll arbeiten. Dabei nimmt es evtl. Paketgrößenanpassungen vor. Dies geschieht durch
die Steuerung der Paketfragmentierung auf dem Weg und durch den Zusammenbau im Zielhost. Der Weg eines Paketes von Rechner A zu Rechner B durch ein Netzwerk liesse sich
im OSI-Modell wie folgt veranschaulichen.
Weg eines Datenpaketes von Host A zu B über einen Router
Schicht
7
6
5
4
3
2
1
Host A
Eth-HUB
Router
Switch
Host B
Abbildung 2.2: Weg eines Paketes durch OSI-Schichten
2.7
2.7.1
Aufgaben
OSI
1. Worin unterscheiden sich das OSI- und TCP-Schichtenmodell?
6
Carrier Sense Multiple Access with Collision Detection bzw. Collision Avoidance
16
KAPITEL 2. OSI-SCHICHTENMODELL
2. Warum kann es passieren, dass einzelne Schichten vielfach nochmal unterteilt wurden?
3. Was sind Gründe um geschichtete Protokolle zu verwenden?
4. Ein System verwendet eine n-Layer Protokollhierarchie. Eine Applikation generiert eine Nachricht von der Länge N Bytes. Auf jeder Schicht wird ein H Byte langer Header
angefügt. Welcher Anteil der Netzwerkbandbreite wird allein durch die Headerinformation belegt?
5. Welche OSI-Schicht handelt die folgenden Aufgaben ab: a) Aufteilung des zu übertragenden Datenstroms in Frames und b) festzustellen, welche Route durch das Netzwerk
benutzt werden soll?
2.7.2
Netzwerke
1. Was sind die wesentlichen Unterschiedungen von packet-switching und circuit-switched
Networks?
2. Wodurch kommen Ende-zu-Ende-Verzögerungen zustande? Woraus setzt sich die Gesamtverzögerung zusammen? Annahme: Pakete bewegen sich entlang einer festgelegten Route.
Kapitel 3
LAN Hardware
3.1
Ethernet
Die in LANs am weitesten verbreitete Hardware ist im allgemeinen unter dem Namen Ethernet bekannt. Es umfaßt die Schichten 1 und 2 des ISO/OSI-Modells. Ethernets sind in der
Installation relativ günstig, was, zusammen mit Übertragungsraten von bis zu 1000 Megabit
pro Sekunde, zu seiner starken Popularität gesorgt hat.
ISO/OSI
IEEE 802.3
reference model
Application
Presentation
Session
Upper-layer
protocols
Transport
Network
MAC-Client
Data Link
Media Access (MAC)
Physical
Physical (PHY)
IEEE 802-spcific
IEEE 802.3-spcific
Media-specific
Abbildung 3.1: Ethernet im OSI-Schichtenmodell
Ein Nachteil der Ethernet-Technologie ist die begrenzte Länge der Kabel, was die Verwendung auf LAN’s (Local Area Network) beschränkt. Allerdings kann man aber mehrere
Ethernet-Segmente miteinander verbinden, indem man sogenannte Repeater, Bridges oder
Router verwendet. Repeater kopieren einfach die Signale zwischen zwei oder mehreren Segmenten, was bedeutet, dass alle Segmente zusammenarbeiten, als wäre es ein einzelnes
Ethernet. Aufgrund der Timing-Anforderungen dürfen zwischen zwei Hosts im Netzwerk
nicht mehr als vier Repeater verwendet werden. Bridges und Router sind da schon etwas
aufwendiger. Sie analysieren die eingehenden Daten und leiten sie nur dann weiter, wenn
sich der empfangende Host nicht im lokalen Ethernet befindet.
Ethernet arbeitet wie ein Bus-System, bei dem ein Host die Pakete (oder Frames) mit
einer Größe von bis zu 1500 Byte an einen anderen Host in demselben Ethernet übertragen
kann. Ein Host wird dabei über eine sechs Byte lange Adresse (MAC) angesprochen, die
in die Firmware der Ethernet-Karte fest eingetragen ist. Diese Adressen werden von der
FCC in den USA zugeteilt. Die Sequenz von zweistelligen Hexadezimalzahlen, die jeweils
durch Doppelpunkte voneinander getrennt werden, kennt inzwischen fast jeder, der mit
17
18
KAPITEL 3. LAN HARDWARE
Transmission order: left-to-right, bit serial
FCS error detection coverage
FCS generation span
PRE
SFD
DA
SA
7
1
6
6
Field length in bytes
Length/Type
4
Data
46
Pad
-
1500
FCS
4
Abbildung 3.2: Aufbau des Ethernet-Headers
Netzwerken zu tun hat.
Ein Ethernet-Header beginnt mit einer 64 bit (8 octets) langen Sequenz aus Nullen
und Einsen um ein Paket einzuleiten. Dieses ist zur Synchronisation der angeschlossenen
Geräte und zur Collision Detection erforderlich. Die ersten sieben Bytes besitzen jeweils
einen Wert von 10101010 während das letzte Byte mit dem Wert 10101011 das Ende der
Präambel ankündigt. Es folgen die Ziel und Quelladresse (jeweils 6 octets lang) und die Art
des darüberliegenden Protokolls (kodiert in 2 octets). Nach den minimal 46 und maximal
1500 Byte Daten schliesst sich eine Prüfsumme (4 octets lang). Unterschreitet eine Datagrammgröße 46 Bytes, so muss mit Zusatz-Bits erweitert werden. Die Vermittlungsschicht
verwendet das Längen-Feld im Header, um die Füllbits zu erkennen. Durch das CRC-Feld
wird überprüft, ob irgendwelche Bits im Rahmen durch äußere Einflüsse (z.B. Dämpfung
der Signalstärke, elektromagnetische Umgebungsstörungen, usw.) gekippt (komplementiert)
wurden. Der Client berechnet den Wert des CRC-Feldes aus den übrigen Bits im Rahmen
einschließlich der Präambelbits. Der Server wendet auf die empfangenden Bits im Rahmen
dieselbe Berechnung an (CRC-Prüfung) und überprüft damit den vom Client eingetragenen
Wert.
Ethernet arbeitet nach dem CSMA/CD-Verfahren, was ”Carrier Sense Multiple Access/Collision Detection” bedeutet. Bevor eine Datenübertragung beginnt, wird der Zustand des Netzes von der sendewilligen Station überprüft. Jede Station darf immer dann
senden, wenn in diesem Moment keine andere Station Daten überträgt. Deshalb kann jede
Station simultan horchen und senden.
Ein von einem Rechner ausgesandter Frame wird von allen vorhandenen Rechnern registriert, aber nur der Ziel-Host liest das Paket und verarbeitet es. Hierin liegt ein Sicherheitsproblem von Ethernet, weil ein Rechner einfach alle im Netz kursierenden Frames
untersuchen kann.
Eine sendende Station überprüft - zur Sicherstellung, dass sie alleine sendete - ob das gesendete Signal gleich dem empfangenden ist. Sollte dies nicht der Fall sein, so verschickt die
Station ein Störsignal (Jam-Sequence), um allen anderen Stationen zu signalisieren, dass
eine Kollision stattfand. Anschliessend stellt sie das Senden ein. Die andere gleichzeitig
sendende Station registriert dieses Signal und stellt ebenfalls das Senden ein. Der nächste
Sendeversuch erfolgt zeitversetzt um einen Zufallsfaktor, damit ein weiteres Zusammentreffen von Paketen vermieden wird.
Befindet sich jedoch eine sehr hohe Last auf dem Netzwerk, so wird - aufgrund dieses
Verfahrens zu Kollisionsbehebung - der Datendurchsatz dieser Netzwerktechnologie stark
eingeschränkt. Moderne Netzwerkkomponenten wie Switches reduzieren das Sicherheitsund Kollisionsproblem, in dem sie zum einen die Datenpakete nur noch an dem Port zur
Verfügung stellen, an dem eine bestimmte MAC anliegt (hierzu haben diese Geräte übli-
3.1. ETHERNET
19
cherweise einen Speicher von 1000 - 8000 MAC-Adressen) und zum anderen wird per Store&Forward das Zusammentreffen von Paketen vermeiden.
3.1.1
Ethernet-Adapter
Die Protokolle sind in einen sogenannten Adapter, welcher auch als Netzwerkschnittstellenkarte bekannt ist und der mit einem ROM sowie mit einem DSP-Chip versehen ist, implementiert. Ein Adapter ist eine halbautonome Einheit. Er besitzt eine eigene feste Adresse,
MAC-Adresse (Media Access Controll), welche bei der Herstellung in das ROM des Adapters fest eingebrannt wird. Diese Adresse ist sechs Bytes lang und wird normalerweise in
hexa-dezimaler Notation ausgedrückt. Somit leitet die Vermittlungsschicht des sendenden
Clients Datagramme an den Adapter der Sicherungsschicht weiter, während dieser dann die
Erweiterung des Ethernet-Headers übernimmt und den so entstandenen Rahmen auf der
Kommunikationsleitung überträgt.
Der Adapter des empfangenden Servers extrahiert dann die Datagramme aus den Rahmen und leitet sie nach der Überprüfung auf Fehler gegebenenfalls an die Vermittlungsschicht weiter. Der Adapter besitzt die Freiheit einen Rahmen zu verwerfen, falls er feststellt, dass dieser fehlerhaft ist, ohne die oberen Schichten informieren zu müssen. Ein
wesentlicher Grund dafür, warum man auf der Sicherungsschicht MAC-Adressen und keine
gewöhnliche IP-Adressen verwendet, ist, dass dann die Adapter kaum andere Protokolle der
Vermittlungsschicht (z.B. IPX, DECNet) unterstützten könnten und somit ihre Flexibilität
verlieren würden.
Adressauflösungsprotokolle wie ARP, dienen den Sende-Adaptern, aus den Ziel-IPAdressen die MAC-Adressen der entsprechenden Empfangs-Adapter zu ermitteln. Es ist
zu erwähnen, dass ARP nur die IP-Adressen in MAC-Adressen auflöst, deren Hosts sich im
gleichen LAN befinden.
3.1.2
Koaxialkabelbasierte Netze für 10 MBit
max. 30 Stationen pro Segment
PC 1
TERM CHEAPER-NET
50Ohm
2,5m
10Base2
max. 100 Stationen pro Segment
TERM
50Ohm
PC 2
WS 1
WS 2
MAUI
YELLOW-CABLE
max. 4 Repeater
185m
WS 3
TERM
50Ohm
T-Connector
Repeater
TERM
50Ohm
10Base5
500m
Abbildung 3.3: Regeln in BNC-Netzen
Thin Ethernet, Cheaper Net oder auch BNC bezeichnet die inzwischen veraltetete Vernetzung mittels 50 Ohm abgeschirmten Koaxialkabel (wie beim Rundfunk; Verbindungsstücke und -kupplungen sind in BNC-Technik ausgeführt. Die Enden müssen mit Endwiderständen ”terminiert”, d.h. abgeschlossen werden.). Diese Topologie ist preiswert und
recht einfach; neue Knoten sind mit geringem Aufwand einzufügen. Die Nachteile liegen jedoch in der primitiven Technik und seiner Empfindlichkeit. Die Unterbrechung des Kabels
an einer Stelle führt zum Ausfall des ganzen Netzwerk(-segment)es. Bezeichnet wird dieser
Standard mit 10Base2. Mittels Cheapernet können bis zu 185 m überbrückt werden. Der
ursrpüngliche Standard 10Base5 basiert auf dickerem Koaxialkabel, wobei die Anschlüsse
20
KAPITEL 3. LAN HARDWARE
der Endgeräte mittels Transceiver erfolgte. Hiermit sind bis zu 500 m Gesamtlänge erreichbar.
3.1.3
Twisted-Pair-basierte Verkabelungen 10/100 Mbit
Twisted Pair Kabel mit 10/100 Mbit verwendet vier Kupferadern, die paarweise verdrillt
sind. Die maximale Segmentlänge liegt hier bei 100 m. Bei mehr als zwei Rechnern ist nun
üblicherweise zusätzliche Hardware notwendig, die als ”Hub” bezeichnet ist. Die Verkabelung erfolgt sternförmig zum HUB und erlaubt die einzelne Segmentierung (Abschaltung)
eines Rechners, falls es zu Fehlern auf dem Kabel kommt.
Im 8-adrigen Kabel bzw. auf der 8-poligen Anschlussdose werden üblicherweise die Kabelpaare 1,2 und 3,6 verwendet. Möchte man zwei Rechner direkt mittels TP-Kabel verbinden, muss dieses gekreuzt sein, damit Empfangs- und Sendeanschlüsse entsprechend
miteinander verbunden werden. Diese Aufgabe wird üblicherweise von einem Hub bzw.
Switch übernommen. Eine andere Möglichkeit ist die beiden Rechner mit einem “CrossConnenct-Kabel” zu verbinden.
Damit Endgeräte und Netzwerkkomponenten mit unterschiedlichen Übertragungsraten
in einem Netz betrieben werden können, sind Komponenten, die 100 Mbit transferieren
können, mit einem Media Independent Interface (MII) ausgestattet. Dieses handelt beim
Aufbau der Verbindung die Übertragungsrate, sowie den Verbindungsmodus (Voll- oder
Halbduplexbetrieb) aus.
3.1.4
1000 Mbit
Für Ethernetverbindungen mit 1000 Mbit (Gigabit) benötigt man vier verdrillte Kupferadernpaare. Das hat zur Folge, dass ältere Kabel aufgrund ihrer Beschaltung und elektrischen
Eigenschaften nicht mehr genutzt werden können. Gigabitnetzwerkkomponenten verfügen
analog zu 100 Mbit Geräten über ein Gigabit Media Independent Interface (GMII), welches die Aushandlung der Verbindungsart vornimmt. Auf diese Weise können ältere Geräte
weiterhin in einem solchen Netz betrieben werden. Das GMII ist in der Lage automatisch
zwischen gekreuzten und ungekreuzten Kabelverbindungen zu unterscheiden und die Verbindung entsprechend zu schalten.
416 byte for 1000Base-X
520 byte for 1000Base-T
PRE
SFD
DA
SA
Length/Type
7
1
6
6
Field length in bytes
4
Data
46
Pad
-
1500
FCS
Extension
4
Abbildung 3.4: Erweiterungen des Ethernet-Standards für Gigabit
3.1.5
Ethernet unter Linux
Die durchschnittliche vernetzte Linux-Maschine hängt an einem Ethernet. Für mobile Endgeräte wie Laptops oder Tablet-PC gilt, dass dieses noch nicht einmal die ganze Zeit der
Fall sein muss. Wenn auch Ethernets zu den fehlerfreiesten Netzwerken zählen, so müssen
trotzdem nicht immer alle Komponenten problemlos miteinander kooperieren. Klappt die
Aushandlung der Verbindungsgeschwindigkeit beispielsweise zwischen älterer Switch und
billigem Netzwerkadapter nicht, kommt kein Datenaustausch zustande.
3.1. ETHERNET
21
Weniger dramatisch ist eine Netzwerkkarte im Fullduplex-Mode an einem Hub. Hier
leidet die Verbindungsqualität unter Umständen heftig, wegen der ausgeschalteten Kollisionserkennung der Netzwerkkarte. Als Ergebnis beobachtet man Datenraten durchaus weit
unter der nominellen Schnittstellengeschwindigkeit.
An dieser Stelle setzen Programme wie ethtool, mii-diag oder die Toolsuite ”nictools” an. Man als Systemadministrator ethtool eth0 aufruft, erhält man einen umfassenden Überblick zum Ethernet-Interface eth0. Hierzu gehören die unterstützten InterfaceGeschwindigkeiten, die aktuell benutzte Geschwindigkeit, der Duplex-Status, welche Art
des Mediums angeschlossen ist, ob ein Link besteht und weiteres. Wenn es Probleme mit
der automatischen Aushandlung der Parameter gibt, lässt sich diese ausschalten:
s02:~ # ethtool -s eth0 autoneg off
s02:~ # ethtool -s eth0 speed 10
s02:~ # ethtool -s eth0 duplex half
Anschliessend kann die Geschwindkeit und die Art des Links manuell eingestellt werden.
Das Ergebnis der letzten beiden Kommandos sorgt für eine Netzwerkverbindung in der Qualität des alten BNC-Ethernets - 10 Mbits half duplex. Unterstützt die Netzwerkkomponente
Hub oder Switch die Anzeige der Geschwindigkeit, kann man die Änderung der Parameter
dort nachvollziehen. Nach der Wiedereinschaltung der ”Autonegotiation” reicht ein kurzes
Ziehen und Wiedereinstecken des Kabels, um wieder die alten Parameter vor dem Experiment zu erhalten. Die Einstellungen kann ein Admin natürlich auch Schritt-für-Schritt in
der Kommandozeile vornehmen, indem er die eben gezeigten Befehle umkehrt.
Ein gezogenes Kabel quittiert ethtool mit der Meldung ”Link detected: no”. Ähnliche
Informationen liefert auch mii-diag.
hermes:~ # mii-diag eth0
Basic registers of MII PHY #1: 1000 796d 0020 6162 05e1 41e1 0005 2001.
The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
Basic mode control register 0x1000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD
10baseT.
End of basic transceiver information.
ethtool kann bei einer Reihe von Netzwerkkarten, beispielsweise einigen Onboard ViaRhine, dazu verwendet werden, Wake-on-LAN einzuschalten. Dieses erreicht man durch
ethtool -s eth0 wol g. Der Parameter ”g” steht für ”Wake on MagicPacket”. Einen
solchen Weckruf kann das Programm ether-wake erschallen lassen.
ether-wake 00:10:20:30:40:50 schickt ein geeignet formatiertes Ethernet-Frame an
die angegebene MAC-Adresse. Es gibt eine ganze Reihe weiterer Programme, die solche
Pakete schicken können, auch über Router hinweg.
Möchte man permanent den Link-Status überwachen, weil man beispielsweise nicht zum
Ablesen der LEDs an der Karte auf die Rechnerrückseite krabbeln will, können hier die
Nic-Tools weiterhelfen. So überwacht beispielsweise für eine SMC Epic100-Karte (83c170)
”epic-diag -mm” permanent ob ein Kabel angeschlossen ist oder ein Link zu einer anderen Netzwerkkomponente besteht. Die Diag-Tools - der Name beginnt immer mit der
Netzwerkkarte oder dem Chip - können weitere Informationen, beispielsweise über den
Inhalt des Konfigurations-EEPROMs oder Device-Register ausgeben: via-diag -e oder
rtl8139-diag -a.
22
KAPITEL 3. LAN HARDWARE
3.2
Funk-Netze
Drahtlose lokale Kommunikationssysteme, sogenannte Wireless LANs, finden bei zunehmender Produktvielfalt eine immer grössere Verbreitung. Sie basieren üblicherweise auf
Funk als Übertragungsweg. Lokale Funknetze können eine effiziente Alternative zu aufwendigem Verlegen von Kabeln darstellen. Eine Ad-hoc-Vernetzung per Funk erlaubt den
spontanen und mobilen Datenaustausch. Kabellose Eingabegeräte erhöhen den Bedienkomfort von Computern. Mit heute verfügbarer drahtloser Technik sind eine ganze Reihe von
Mobilitätsansprüche der Nutzer von IT-Technik realisierbar. Die wichtigsten technischen
Systeme hierzu sind z.Z. WLAN (IEEE 802.11) und Bluetooth-Module (IEEE 802.15).
Funknetze sind komplexer im Zugriff als drahtgebundene LANs. Die begrenzte Reichweite der einzelnen Teilnehmer und Stationen verhindern, dass ein übergreifendes Signalerkennen möglich ist oder stark erschwert wird. Zusätzlich soll eine Bewegung zwischen
verschiedenen Zellen ermöglicht werden. Diese Fähigkeit von Netzen wird als Roaming bezeichnet.
Um die beschriebenen Probleme in den Griff zu bekommen, wird ein MAC-SublayerProtokoll implementiert. Damit wird ein einheitliches Netz über verschiedene Sender möglich.
Ein naiver Ansatz wäre Verwendung des CSMA/CD-Verfahrens, wie es beim drahtgebundenen Ethernet geschieht. Jedoch hört 3 nichts bei einem Transfer zwischen 1 & 2 und
könnte zu 2 übertragen wollen. Die Leitung scheint frei zu sein, obwohl gesendet wird.
Diese Situation wird als ”Hidden Station Problem” bezeichnet.
Es tritt weiterhin folgende Schwierigkeit auf: Bei einem Datentransfer von 2 zu 1 denkt
3, dass Zelle blockiert ist und unterläßt einen gleichzeitigen Transferversuch zu 4, obwohl
dadurch keine gegenseitige Störung auftreten würde. Auf diese Weise wird Bandbreite verschenkt: ”Exposed Station Problem”. Deshalb wird ein neues Zugriffsverfahren eingeführt.
MACA(W) bezeichnet Multiple Access with Collision Avoidance. Bei diesem Verfahren wird
vor dem eigentlichen Datentransfer ein kurzes Testsignal mit der Bezeichnung RTS (Ready
To Send) gesendet. Mit diesem Signal erfolgt die Ankündigung des großen Datenblocks. Die
Zielstation antwortet mit einem CTS (Clear To Send).
Reichweite von 1
3
1 RTS 2
4
3
1
5
CTS 2
4
5
Reichweite von 2
MACA (W) Zugriffsverfahren für WLAN
Abbildung 3.5: Sichtbarkeitsproblem
Alle Stationen, die ein RTS-Signal hören, müssen in der Zwischenzeit ”schweigen”. Es
gibt eine Optimierung des Protokolls, die mit MACAW bezeichnet wird.
Folgende wichtige Standards regeln die Implementierung drahtloser Netzwerke:
• 802.11a bis 54 Mbit/s im 5 GHz Band
• 802.11b derzeitige Implementation bis 11 Mbit/s
3.2. FUNK-NETZE
23
• 802.11g bis 54M bit/s jedoch im 2,4 GHz Band
Mit dem derzeitig verfügbaren Standard sind bei 11 Mbit/s nominaler Übertragungsrate aufgrund von Protokolloverheads real ca. 6 Mbit/s erreichbar. Verwendet wird das für
Forschung, Medizin und private Zwecke freigegebene Frequenzband bei 2,4 GHz. Die Leistung der verwendeten Geräte, Access-Points, Netzwerkkarten oder Repeater darf maximal
100 mW betragen. Die Reichweiten liegen indoor je nach Gebäudebeschaffenheit bei 30 bis
100 m. Im Freien sind bei Sichtkontakt 300 bis 500 m und mit Antenne verstärkt bis zu
mehreren Kilometern überbrückbar.
Ein Funknetz kann in verschiedenen Modi aufgebaut werden: AdHoc, Managed, Master,
AccessPoint. Hiervon hängt ab, ob die Netzwerkkarten auf eine feste Frequenz eingestellt
werden müssen oder sie nach einem gemeinsamen Kanal suchen. Beim AccessPoint-Modus
übernimmt der AccessPoint die Steuerung der Verbindung. Der 802.11g Standard versucht
bis zu 54 Mbit/s noch im 2,4 GHz Band zu realisieren, weiterhin gibt es herstellereigene Zwischenstandards bis 22 Mbits/s, die derzeitig auf dem Markt auftauchen und meistens nicht
untereinander kompatibel sind. Die WiFi-Zertifizierung kennzeichnet Geräte, die nach den
gegebenen Standards interoperabel sind. Erreicht werden die höheren Bandbreiten durch
Kanalbündelung, womit insgesamt weniger Kanäle für verschiedene Netze zur Auswahl stehen. Die Aufteilung des zur Verfügung stehenden Frequenzspektrums erfolgt auf bis zu
13 Kanäle1 Bei einem engmaschigem Netz von AccessPoints ist eine geschickte Kanalaufteilung notwendig, um Signalstörung oder Auslöschung zu vermeiden. Mehrere AccessPoints
können in einem Bereich betrieben werden, wenn ihre Kanäle weit genug auseinanderliegen.
Alle Bandbreitenangaben beziehen sich auf ein ”Shared Medium”, d.h. bei steigender
Teilnehmerzahl steht dem einzelnen eine niedrigere Datenrate, vergleichbar mit Ethernet
über Koaxialkabel, zur Verfügung. Die nutzbare Bandbreite hängt also von den Teilnehmern pro Funkzelle ab. Es ist jedoch möglich mehrere Zellen parallel zu betreiben. Die
Kennung erfolgt über die sechsstellige MAC, mit dieser erfolgt auch die Anmeldung an den
AccessPoints.
2,4000GHz
2,4835GHz
1
2
3
4
5
6
7
8
9
10 11 12 13
Kanalbelegung und evtl. Überschneidung beim WLAN (802.11b)
Abbildung 3.6: Kanalaufteilung
1
Die Verteilung ist in verschiedenen Ländern unterschiedlich, so dass nicht immer alle Kanäle genutzt
werden dürfen.
24
KAPITEL 3. LAN HARDWARE
Ein wesentliches Problem haben WLANs gegenüber ihren drahtgebundenen Pendents;
sie sind sehr offen. Deshalb muss eine ganz andere Absicherung als bei drahtgebundenen
Netzen erfolgen. Zur Sicherung der Verbindung wurde WEP (WiredEquivalentPrivacy) eingeführt. Es arbeitet mit 64 bzw. 128 Bit Schlüsseln. Diese sind jedoch nicht unproblematisch:
Sie besitzen einen Klartext-Initialisierungsvektor (24 bit), der jeder Nachricht voransteht.
Damit ist der WEP-Key nur noch 40 bzw. 104 Bit lang.
Die Einfachheit der Konfiguration von WLANs bringt weitere Probleme mit sich: Die
AccessPoints arbeiten meistens sofort und ohne voreingestellte Absicherung. Zusätzlich werden meistens DHCP-Server für sich anmeldende Geräte betrieben, die meist so konfiguriert
sind, dass jeder Host eine Adresse erhält. Deshalb gibt es inzwischen eine Art Volkssport:
WarDriving (oder WarChalking - Suchen nach offenen WLAN-Netzen).
3.3
TokenRing
TokenRing wurde von IBM entwickelt und ist heutzutage nur noch in alten Netzen im
Einsatz. Im Gegensatz zu Ethernet kreist zur Zuteilung der Sendeerlaubnis ein ”Token”,
welches dem Netzadapter - der im Besitz dieses Tokens ist - erlaubt Pakete zu verschicken.
So kommt es nicht zu Kollisionen und die Bandbreite des Netzes (üblicherweise 4 oder
16 Mbit) kann auch mit einer grösseren Zahl von Maschinen besser ausgenutzt werden, als im
ungeswitchten Ethernet. Die Verzögerungszeiten in einem TokenRing liegen üblicherweise
unter 250 ms.
In der Regel berechtigt der Besitz des Tokens nur zur Sendung eines Blocks (non exhaustive). Im anderen Extremfall könnte auch definiert werden, dass die Station soviele
Datenblöcke senden kann, wie sie möchte (exhaustive). Damit könnte aber eine Station,
die den Token besitzt, alle anderen dominieren. Normalerweise wird deshalb nur ein Block
gesendet. Außerdem wird die Dauer der Sendeberechtigung befristet (Token Holding Time,
z.B. 10 ms). Solange das Netz fehlerfrei funktioniert, stellt Token-Ring ein sehr einfach zu
bedienendes Verfahren dar. Komplexer sind die Aufgaben beim Initieren des Netzes und
bein Ein- oder Auskoppeln von Stationen. TokenRing ist das einzige Netz mit aktiven Stationen, die aus Eingabe- und Ausgabeeinheit bestehen. Grundsätzlich sind alle Stationen
gleichberechtigt, jedoch übernimmt eine von ihnen als ”aktiver Monitor” besondere Überwachungsaufgaben im Netz. Eine andere Station überwacht als ”passiver Monitor” den
aktiven Monitor und kann gegebenenfalls dessen Aufgaben übernehmen. Die Aufgaben des
aktiven Monitors sind:
• Erzeugen des Ringtaktes
• Überwachen des Tokens (Neuen Token erzeugen, falls er verloren geht; Verhindern
mehrerer Tokens)
• Unterbinden permanent kreisender Blöcke oder Tokens erhöhter Priorität. (Generell:
Ring säubern durch Senden eines “Purge Ring Frame” an alle Stationen und Erzeugen
eines neuen Frei-Tokens).
• Verhindern, dass mehrere Monitore aktiv sind.
• Verzögerung des Token-Rahmens um 24 Bit-Zeiten (die Länge des Token-Rahmens
beträgt 24 Bit). Auch bei extrem kleinem Ring wird so sichergestellt, dass eine Station
den Token-Rahmen vollständig senden kann, bevor sie ihn wieder empfängt.
In regelmäßigen Abständen sendet der aktive Monitor einen “Active Monitor Present
Frame” an alle Stationen im Ring. Gleichzeitig wird dadurch eine Prozedur in Gang gesetzt,
3.3. TOKENRING
25
die allen Stationen die Adresse des jeweiligen Vorgängers im Ring liefert (NAUN = Nearest
Active Upstream Neighbour) - eine Information, die nur im Fehlerfall wichtig ist. Ein Fehler
auf Empfangsseite bedeutet, dass der eigene Empfänger oder der Sender des NAUN defekt
ist. Die Auswahl des aktiven Monitors geschieht per “Claim-Token Process” durch:
• den derzeit aktiven Monitor, wenn dieser Probleme bei der Durchführung seiner Aufgaben hat,
• einen passiven Monitor, wenn der aktive Monitor nicht korrekt arbeitet (z.B. Timeout
auftritt).
• eine neu eingegliederte Station, wenn diese das Fehlen des aktiven Monitors feststellt.
Token-Ring-Netze werden normalerweise als Stern-Ring-Verbindungen mit passiven Ringleitungsverteilern aufgebaut. In den Ringleitungsverteilern befinden sich Relais (die von den
Stationen gesteuert werden); sie dienen der Eingliederung von Stationen und der Schaltung
von Ersatzringen bei Defekten.
Die Eingliederung einer Station erfolgt in fünf Schritten:
1. Ist ein Adapter vom Ring getrennt, sind gleichzeitig Eingangs- und Ausgangsleitung
kurzgeschlossen. Es erfolgt zunächst ein Adaptertest. Nach dem Test versorgt der
Adapter die Relais mit Strom und wird in den Ring eingegliedert.
2. Die Station hört nun den Ring ab. Wenn sie innerhalb einer festgelegten Zeit keine
Aktivität des aktiven Monitors wahrnimmt, startet sie den Prozeß zur Auswahl des
aktiven Monitors.
3. Durch Aussenden eines ”Duplicate Address Test Frame” prüft die Station die Eindeutigkeit ihrer Adresse. Ist sie nicht eindeutig, koppelt sich die Station wieder ab.
4. Durch den NAUN-Prozeß erfährt die Station die Adresse ihres Vorgängers und ist
nun ins Netz eingegliedert.
5. Von den Voreinstellungen abweichende Parameter können nun bei einer Server-Station
abgefragt werden, sofern dies nötig ist.
Die Funktionen von Monitor und von den eingegliederten Stationen müssen nicht nur
einmalig initiiert, sondern auch ständig überwacht werden. In vielen Fällen sind dies zahlreiche Aktionen, die auch viele Blöcke auf dem Netz zur Folge haben und in deren Verlauf
auch Fehler- und Ausnahmebedingungen auftreten können. Der Nachteil von Token-Ring
liegt darin, dass beim Ausfall einer Station oder bei Kabeldefekten das Netz unterbrochen
wird. Wird die defekte Station hingegen abgeschaltet, so schalten die Relais im Ringleitungsverteiler die Leitung durch. Token Ring ist genormt nach IEEE 802.5.
Jede Station empfängt, liest und sendet die auf dem Ring zirkulierenden Daten. Dabei
gibt sie im allgemeinen nach dem Lesen die jeweilige Nachricht an die Nachbarstation
weiter. Jedes Paket enthält die Adresse des Senders (SA) und die Zieladresse (DA). Wenn
die Zieladresse mit der eigenen Adresse übereinstimmt, wird die Nachricht in den lokalen
Speicher kopiert. Dies wird der lokalen LLC-Komponenete (Logical Link Control) gemeldet,
und es wird ein Quittierungsfeld- oder Fehlerfeld entsprechend verändert. Anschließend
wird diese Nachricht an die Nachbarstation weiter gesendet. Die sendende Station entfernt
die von ihr gesendete Nachricht und interpretiert die Quittierungsfelder. Um Senderecht
zu erhalten, muß jede Station das Token erhalten. Dies kann von jeder Station mit einer
entsprechenden Priorität vorab reserviert werden:
26
KAPITEL 3. LAN HARDWARE
Priorität
0
1-3
4
5,6
7
Anwendung
frei verfügbar, von den meisten Anwendungen verwendet
frei verfügbar
von Bridges verwendet
reserviert, jedoch nicht verwendet
für die Administration des Ringes verwendet
Tabelle 3.1: Prioritätslevel bei TokenRing
Nur die Station mit der höchsten reservierten Priorität erhält somit das Senderecht.
Diese Prioritäten, zusammen mit der festgelegten maximalen Umlaufzeit eines Paketes,
ermöglichen eine garantierte Datenübertragung kontinuierlicher Medientypen.
3.4
Netzwerk-Interfaces von Linux
Auf irgendeine Weise müssen Netzwerkdatenpakete in eine Linuxmaschine hineinkommen
oder diese verlassen können. Dies geschieht über sogenannte Netzwerk-Interfaces. Durch
den Namen des Interfaces wird meistens die Art der Verbindung oder der verwendeten
Netzwerkhardware spezifiziert. Anders als bei anderen Unixes verwendet Linux für alle
Ethernet-Interfaces die Bezeichnung ethN. Das ”N” ist eine natürliche Zahl zwischen ”0”
für das erste Interface und ”n-1” für die letzte Netzwerkkarte, die in eine Maschine eingebaut ist. Ein Rechner kann durchaus über etliche Interfaces auch von verschiedenen Typen
verfügen. Die Verfügbarkeit eines bestimmten Interfaces hängt meistens von einem Kerneltreiber ab. Mit dem Laden des entsprechenden Moduls für einen TokenRing, Ethernet oder
ähnliche Adapter steht sodann das entsprechende Interface zur Verfügung. Dabei hängt die
Reihenfolge der Nummerierung von der Reihenfolge des Modul-Ladens oder der automatischen Erkennung des Linux-Kernels ab.
TokenRing-Adapter stellen nach dem Laden der entsprechenden Kernelmodule ein Netzwerkinterface vom Typ tr0 und folgende für weitere Adapter dieser Art bereit. Ähnliches
geschieht bei den entsprechenden Modulen für ATM, FDDI und andere Netzwerkhardware.
Eine Besonderheit ist das Loopback-Interface, welches mit dem Einschalten der TCP/IP
Unterstützung, im Kernel automatisch zur Verfügung steht. Es wird mit lo bezeichnet und
existiert nur in einfacher Ausführung. Weiterhin gibt es eine Reihe von Software-Interfaces,
wie ppp0 für PPP-Verbindungen verschiedener Art, slip0 für Serial-Line-IP, dummy0 für
Testzwecke, ipsec0 für IPsec-Verbindungen und weitere.
dirk@linux:~/kurs> /sbin/ifconfig
cipcb0
Link encap:IPIP Tunnel HWaddr
inet addr:192.168.2.2 P-t-P:192.168.2.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0
Link encap:Ethernet HWaddr 00:02:B3:87:53:43
inet addr:132.230.9.124 Bcast:132.230.9.255 Mask:255.255.255.0
inet6 addr: fe80::202:b3ff:fe87:5343/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5323418 errors:0 dropped:0 overruns:0 frame:0
TX packets:6567650 errors:0 dropped:0 overruns:1 carrier:0
collisions:0 txqueuelen:100
3.5. AUFGABEN
27
RX bytes:795523375 (758.6 Mb) TX bytes:2554637681 (2436.2 Mb)
Interrupt:10 Base address:0xec00 Memory:dffff000-dffff038
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:8401120 errors:0 dropped:0 overruns:0 frame:0
TX packets:8401120 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:802796349 (765.6 Mb) TX bytes:802796349 (765.6 Mb)
vmnet8
Link encap:Ethernet HWaddr 00:50:56:C0:00:08
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:8/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:4297 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Mit dem Kommando ifconfig erhält man z.B. obige Ausgabe, welche ein Interface für CIPE
(cipcb0 ), ein klassisches Ethernet-Interface (eth0 ), das Loopback-Interface (lo) und ein virtuelles Ethernet-Interface für die Software VMware (vmnet8) als konfiguriert anzeigt. Die
angezeigten Zusatzinformationen variieren in Abhängigkeit vom Interface-Typ. Die Maximum Transfer Unit (MTU) hängt von der darunterliegenden Netzwerkhardware ab und
liegt, z.B. im Ethernet bei 1500 Byte. Das Loopback-Interface, welches nur in Software auf
der Maschine selbst stattfindet, kann in einer Einheit bis zu 16 kByte übertragen. Hardwaredaten, wie verwendeter Interrupt und Speicherbereiche findet man natürlich nur bei
Interfaces, die direkt mit einer Hardware zu identifizieren sind.
3.5
Aufgaben
3.5.1
Ethernet
1. Welche Medien verwenden die Ethernet-Standards 10Base2, 100BaseTX und 10Base5?
2. Was versteht man unter ”promiscuous mode”? Was heisst dieses speziell in Ethernets?
28
KAPITEL 3. LAN HARDWARE
Kapitel 4
WAN Hardware
4.1
Einleitung
Der Begriff Internet hat heute einen festen Platz in fast jedermanns Wortschatz. Die Entdeckung des Internets beeinflusst das Leben aller Generationen. Kommunikation (Chatt,
E-Mail, ), Einkaufen, Überweisungen (Online-Banking), Recherchieren - um nur einige zu
nennen - sind Bereiche, in die das Internet auf selbstverständliche Art und Weise Einzug
gehalten hat. Das Internet ist heutzutage aus fast keinem Lebensbereich mehr wegzudenken. Das Internet Protokoll selbst definiert jedoch keine Hardware, die zur Bitübertragung
eingesetzt werden kann.
Die folgenden Abschnitte wollen deshalb versuchen, dem Leser einem Blick hinter die
Kulissen der physikalischen Datenübertragung zu verschaffen. Dabei wird insbesondere auf
die eingesetzten Technologien und Methoden der Datenübertragung eingegangen.
Wie aus dem Namen bereits ersichtlich, bilden Computernetzwerke einen Verbund von
mehreren Computern. Dabei können diese Computer sich alle in einem Raum befinden und
über sogenannte Netzwerkkabel direkt miteinander verbunden sein oder sich in unterschiedlichen Teilen der Welt aufgestellt sein und über Netzwerkkabel und Funknetze miteinander
kommunizieren. Sobald in irgendeiner Form mindestens zwei physikalisch getrennte Computer miteinander verbunden sind, spricht man von einem Computernetzwerk.
Im Fachjargon bezeichnet man alle Computer, die im Netzwerk registriert sind, als Hosts
oder Endsysteme. In diesen Unterlagen werden zumeist die Begriffe Host oder Netzwerkrechner verwendet werden. In der heutigen Zeit existieren unzählige Computernetzwerke (kurz:
Netzwerke). Ein Netzwerk liegt bereits vor, wenn in einem kleinen Haushalt die Computer
aller Familienmitglieder über ein lokales Netz (LAN) miteinander verbunden sind. Umfangreichre Netzwerke sind beispielsweise Unternehmensnetzwerke, Firmennetzwerke oder Universitätsnetzwerke. Das berühmteste Netzwerk ist aber sicherlich das öffentliche Internet,
welches Millionen von Computern miteinander verbindet und so als ein Zusammenschluss
von verschiedenen Netzwerken interpretiert werden kann.
Da - wie oben bereits erwähnt - die Hosts sich in den verschiedensten Teilen der Welt
befinden können und in jedem Land unter Umständen andere Standards bezüglich der eingesetzten Computertechnologien existieren, beschäftigte man sich schon in den früheren
Jahren der Netzwerkeinführung mit der Frage des reibungslosen Ablaufes der Kommunikationen zwischen den verschiedenen Hosts.
29
30
4.2
4.2.1
KAPITEL 4. WAN HARDWARE
Leistung und Kosten der einzelnen Technologien
Leistung / Datendurchsatz
In Tabelle 3.1. sind die häufig verwendeten Verbindungsprotokolle aufgeführt. ATM, ISDN
und Modem werden eher dem WAN-Bereich, der Rest dem LAN zugeordnet. Aus der Tabelle
geht die max. Reichweite, die Anzahl der Knoten und der Datendurchsatz hervor.
4.2.2
Kosten
Die Kosten für die verschiedenen Netzwerktypen sind in Tabelle 3.2. aufgelistet. Sie lassen
sich hier natürlich nur grob angeben. Bei Festinstallationen wird man noch die Aufwendungen für Anschlussdosen (10 - 20 EUR/Stück), die Unterverteiler (Patchpanel (100 300 EUR), Datenschränke (200 - 600 EUR), Patchkabel (TP 2.5 EUR/m, LWL 12 EUR/m
...) mit einplanen müssen. Wenn Lichtwellenleiter zum Einsatz kommt, sind die Aufwendungen noch etwas höher anzusetzen, da für den Anschluss (das Spleissen) in den meisten
Fällen eine Firma beauftragt werden muss. Bei einer Funkvernetzung entfallen die Kosten
für eine Festinstallation, jedoch sind die weitaus höheren Aufwendungen für die Netzwerkkarten und die Access-Points zu berücksichtigen.
Medium
Funk-LAN
ADSL
ATM
Ethernet (TP)
Ethernet (BNC)
ISDN
loopback
Modem
GPRS/HSCSD
UMTS
Serieller Port
Tokenring
Reichweite
einige 100m
mehrere km
mehrere km
100 m
185 m
0
mehrere km
mehrere km
30 m
100 m
Knoten
ca. 20 - 50
????
2 - ...
ca. 35
1
2
2
8
Durchsatz
2 - 11 Mbits
0.5 - 7.6 Mbit
2 - 622 Mbits
10 - 1000 Mbits
10 Mbits
¿ 64 Kbits
¿ 100 Mbits
0.3 - 56 Kbits
0.3 - 56 KBit
128 - 386 KBit
300 - 112000 Bits
4, 16 Mbits
Tabelle 4.1: Leistung und Datendurchsatz einiger Netzwerke
Einige Netzwerk-Technologien wird man nur noch in bestehenden Installationen oder
Computer-Flohmärkten antreffen. Hierzu gehören sicherlich BNC-Ethernet, TokenRing oder
auch Parallelport-Verbinder.
4.3
Telefonnetze
Telefonnetze gehören zu den ältesten Weitverkehrsnetzen überhaupt. Die ersten ZweidrahtKupfer-Telefonnetze wurden bereits Ende des 19. Jahrhunderts eingerichtet. Die Versorgung
mit Telefonanschlüssen liegt in Deutschland inzwischen bei nahe 100 Prozent. Datennetze kamen deutlich später. Deshalb wurden die ersten Datenleitungen über Telefonnetze
geschaltet. Die meisten Internet-Benutzer verwenden in irgendeiner Form Telefonleitungen
für die Verbindung. Dabei geht der Trend jedoch eindeutig weg von den alten ”analogen” Telefonanschlüssen über ISDN hin zu DSL. Jedoch bleibt der Anbieter der Zweidraht-Leitung
4.3. TELEFONNETZE
Medium
ATM
Parallelport
Ethernet (TP 1000)
Ethernet (TP 100)
Ethernet (TP 10)
Ethernet (BNC 10)
Funk-LAN (2/11 Mbit)
ISDN
Modem
GPRS
HSCSD
UMTS
Serieller Port
TokenRing
31
Adapter
300 - 600 EUR
5 - 10
15 - 100 EUR
4 - 40 EUR
–
–
100 - 200 EUR
100
80 - 200
40 - 300 EUR
40 - 200 EUR
80 - 300 EUR
–
–
Kabel
4/m (LWL)
10
0.70/m
0.70/m
0.70/m
0.20/m
500/AccessPoint
5
0.70/m
Gebühren (ca. EUR)
Grosskunde
Telefongebühren
Telefongebühren
saftige Volumengebühr
saftige Zeitgebühr
saftige Volumengebühr
0
-
Tabelle 4.2: Kosten einiger Netzwerke
in den meisten Fällen identisch.
Die Zeit der analogen Telefonnetze in Deutschland ist Mitte der 90er Jahre abgelaufen.
Wenn auch die meisten Endgeräte in den Haushalten nach den Prinzipien der Telefone von
vor 70 Jahren arbeiten, so findet die Gesprächsvermittlung und Übertragung im Hintergrund meistens nur noch digital statt.
4.3.1
Das klassische Telefonnetz
Das klassische Telefonnetz nutzt eine Kupfer-Zweidraht-Leitung von der Vermittlungsstelle
bis in die Haushalte. Diese Art Telefonsystem wird von Netzwerkern oft als ”plain old
telephone system” - POTS bezeichnet.
Übertragungsmethoden
Analoge Modems
IDSN
Symmetrisches DSL
ADSL (DMT)
ADSL (CAP)
VDSL
Kabelmodems
Datenrate
Upstream
33.6 kbps
128 kbps
2048 kbps
768 kbps
64 kbps
640 kbps
640 kbps
1,6 bis 2,3 Mbps
768 kbps
Datenrate
Downstream
56 kbps
128 kbps
2048 kbps
8 Mbps
1,54 Mbps
6,14 Mbps
13 Mbps
52 Mbps
30 Mbps
Reichweite
in Meter
etliche km
etliche km
4000
6000
6000
4000
1500
300
je nach Kabel
Verfügbarkeit
in Deutschland
verfügbar
verfügbar
verfügbar
verfügbar
verfügbar
Testphase
Testphase
Testphase
Testphase
Tabelle 4.3: Protokolle auf 2-draht Kupferleitungen im Überblick
4.3.2
Digitale Telefonnetze - ISDN
Meistens wird ISDN für einen Zugang zum Internet verwendet; es ist für interne Vernetzungen fast nur im Bereich der WAN’s (Wide Area Networks) anzutreffen. ISDN wird üblicherweise von Telefongesellschaften zur Sprachkommunikation angeboten und findet sich auch
32
KAPITEL 4. WAN HARDWARE
im Umfeld grösserer Firmentelefonanlagen. Die Primärbandbreite beträgt 64 kbit, welches
von der digitalen Sprachvermittlung herrührt. Verwendet wird PCM (Pulse Code Modulation), welche 8000 Samples von 8 bit Grösse pro Sekunde erzeugt.
Oft findet man passive ISDN-Karten im Computer, die nur einen einfachen Wandler
des digitalen Datenstroms der ISDN-Verbindung zum Rechnerbus vornehmen. Für den
jeweiligen Adapter muss eine Treiberunterstützung im Linux-Kernel vorhanden sein, damit
er benutzt werden kann. Zur Ansprache als Netzwerk-Interface stehen bei erfolgreicher
Konfiguration die Point-to-Point (PPP) Interfaces ippp0 und folgende zur Verfügung. Diese
können sodann mit den klassischen Netzwerktools eingerichtet und gesteuert werden.
4.3.3
Mobilfunknetze nach dem GSM-Standard
GSM - der Global Standard for Mobile Communication definiert ein digitales Mobilfunknetz, was in der überwiegenden Zahl der Länder weltweit eingesetzt wird. Über dieses
Telefonnetz ist es ebenfalls möglich Daten zu übertragen. Dabei gibt es zwei Ausprägungen:
CSD benutzt direkt GSM-Technik und benötigt keine zusätzliche Infrastruktur. GPRS ist
eine Erweiterung des GSM Standards und benötigt zusätzliche Komponenten. Inzwischen
sind jedoch die meisten GSM-Netze auch GPRS-fähig.
4.3.4
GPRS
Der General Packet Radio Service (GPRS) benötigt keine eigene Infrastruktur, sondern
ist lediglich eine Erweiterung der bestehenden GSM-Netze. GPRS-Handys stellen für den
schnellen Austausch der Datenpakete eine dauerhafte Verbindung zu einem Einwahlpunkt1
ins Netz her. Für die Datenkommunikation wird es Endgeräten erlaubt mehrere GSMKanäle zusammenzufassen und für die Kommunikation zu reservieren. Bandbreiten in Funknetzen haben immer ein Problem: Alle Nutzer einer Zelle teilen sich ein gemeinsames
Medium. Wollen alle gemeinsam zugreifen, sinkt für jeden einzelnen die erreichbare Datenrate.
Üblicherweise haben Sprachverbindungen Vorrang, so dass die verfügbare Bandbreite
je nach Auslastung einer GSM-Zelle unterschiedlich ausfällt. Auch können verschiedene
GPRS-Geräte, wie PCMCIA, Cardbus-Adapter oder Mobiltelefone mit entsprechender Erweiterung unterschiedlich viele Kanäle gleichzeitig nutzen. In der Einführungsphase von
GPRS wurde netzseitig eine Bandbreite von 53,6 kbit/s (4 Kanäle à 13,4 kbit/s) pro Funkzelle vorgesehen. Stehen alle acht Kanäle für GPRS zur Verfügung, würde die Bandbreite auf
107,2 kbit/s steigen. Weitere Steigerungen durch bessere Fehlerprotokolle erlaubten theoretische 171,2 kbit/s (8 Kanäle a 21,4 kbit/s). Handys arbeiten momentan mit 13,4 kbit/s
pro Kanal. Sie können je nach Gerät zwei bis drei Kanäle zusammenfassen.
Aktuelle Geräte unterstützen auch vier Kanäle und können damit auf eine Bandbreite
von 53,6 kbit/s kommen. Die Angaben beziehen sich jedoch meistens nur auf den DownloadKanal. Im Upload können Mobiltelefone oft nur einen oder zwei Kanäle benutzen. Oft
findet man eine Klassifizierung: So bedeutet Class 10, dass das Gerät vier Down- und zwei
Upstreamkanäle nutzen kann. Class 8 deutet auf vier Down- aber nur einen Upstream hin.
GPRS selbst arbeitet schon mit starker Datenkompression. Deshalb kann der Endanwender auf eine Kompression auf höheren Protokollschichten verzichten. GPRS verwendet zur
Paketvermittlung gleich das Internet-Protokoll. Üblicherweise stellen die Mobilfunkanbieter
ihren Datenkunden dabei eine private Netzwerkadresse zur Verfügung. Die Aushandlung der
IP-Parameter übernimmt das von anderen Diensten wohlbekannte Point-to-Point-Protokoll
1
APN = Acces Point Name
4.3. TELEFONNETZE
33
(PPP). Jedes Datenpaket besitzt somit eine eindeutige Empfängeradresse im Funknetz, um
zu dem Endgerät zu gelangen. Hierfür ist es unerheblich, über welchen der Funkkanäle es
übertragen wird.
Wie beim GSM auch halten alle eingebuchten GPRS-Teilnehmer permanent über Signalisierungskanäle Kontakt mit dem Netz. Der Teilnehmer ist über den Zeitraum der Einbuchung immer online. Hierfür müssen die Kanäle nicht aufgebaut sein. Die notwendigen
Kanäle werden erst zugeschaltet, wenn tatsächlich Daten abgerufen werden.
Die Einführung von GPRS erfolgte in Deutschland schrittweise ab dem Jahr 2000. GPRS
wurde dabei technisch gesehen über das bestehende GSM-Netz gelegt. Wesentliche Teile der
GSM-Infrastruktur kommen auch für das GPRS-Netz zum Einsatz.
4.3.5
HSCSD
CSD (Circuit Switched Data) existiert seit Beginn der GSM-Netze. Die Nutzdatenrate beschränkte sich auf maximal 9,6 kBit/s. In der GSM-Phase-2 wurde die Geschwindigkeit der
Datenübertragung auf 14,4 kBit/s erhöht, in der GSM-Phase-2+ die Bündelung mehrerer
Kanäle ermöglicht.
GPRS war nicht der einzige Ansatz zur Erhöhung der möglichen Datenrate. HSCSD
(High Speed Circuit Switched Data), der Nachfolger von CSD, erreicht eine maximale Datentransferrate von 57,6 kbit/s. Der Unterschied zwischen den beiden Systemen liegt in
den verwendeten Protokollen und der Übertragungstechnik. Wie bei einer Telefonleitung
steht bei HSCSD jedem User ein dedizierter Nutzkanal exklusiv zur Verfügung. Das macht
sich im Abrechnungsmodell bemerkbar: HSCSD-Anbieter offerieren dem Teilnehmer einen
zeitabhängigen Tarif, der unabhängig vom Datenvolumen ist. Die Zahl der gleichzeitig aktiven Teilnehmern ist nicht relevant und durch die maximale Zellkapazität beschränkt.
E-Plus und Vodafone bieten in Deutschland HSCSD an. Die Preisgestaltung legt jedoch die
Nutzung von GPRS für die gewohnte Internet-Nutzung nahe. HSCSD lohnt sich nur bei
permanenten gleichmäßig hohen Datenraten.
4.3.6
Mobilfunknetze der dritten Generation - UMTS
Hinter der Abkürzung UTMS (Universal Mobile Telecommunications System) steckt der
1998 von der ETSI (Abkürzung für European Telecommunications Standard Institute) vorgestellte Breitband-Mobilfunkstandard der dritten Generation (G3). Die Weiterentwicklung
und Pflege des Standards unterliegt inzwischen dem 3GPP (3rd Generation Partnership
Project). Zu den wesentlichen Leistungsmerkmale von UMTS zählt die Übertragung von
Sprache und Audiodaten, die Übermittlung von multimedialen Inhalten sowie der schnelle
Zugriff auf das Internet. UMTS ermöglicht Datenübertragungsraten von 364 kbit/s bis zu
2 Mbit/s, womit Streaming Video und Audio Übertragung, sowie Bildtelefonie ermöglicht
werden sollen.
Diese Übertragungsraten erreicht UMTS durch den asynchronen Transfermodus kurz
ATM-Verfahren im sogenannten Codemultiplexverfahren. Als Funk-Technologie kommt Wideband CDMA (WCDMA) im Frequenzbereich um die 2 GHz zum Einsatz. UMTS-Hotspots
existieren bereits in Ballungszentren und Großstädten. Ob eine flächendeckende Einführung
stattfindet, muss abgewartet werden. Nicht mehr alle Bieter um die Lizenzen im Jahr 2000
sind am Start und die Aktivitäten der verbliebenen sind von Zurückhaltung gekennzeichnet.
34
4.4
KAPITEL 4. WAN HARDWARE
ISDN
Meistens wird ISDN für einen Zugang zum Internet verwendet; es ist für interne Vernetzungen fast nur im Bereich der WAN’s (Wide Area Networks) anzutreffen. ISDN wird üblicherweise von Telefongesellschaften zur Sprachkommunikation angeboten und findet sich auch
im Umfeld grösserer Firmentelefonanlagen. Die Primärbandbreite beträgt 64 kbit, welches
von der digitalen Sprachvermittlung herrührt. Verwendet wird PCM (Pulse Code Modulation), welche 8000 Samples von 8 bit Grösse pro Sekunde erzeugt.
Oft findet man passive ISDN-Karten im Computer, die nur einen einfachen Wandler
des digitalen Datenstroms der ISDN-Verbindung zum Rechnerbus vornehmen. Für den
jeweiligen Adapter muss eine Treiberunterstützung im Linux-Kernel vorhanden sein, damit
er benutzt werden kann. Zur Ansprache als Netzwerk-Interface stehen bei erfolgreicher
Konfiguration die Point-to-Point (PPP) Interfaces ippp0 und folgende zur Verfügung. Diese
können sodann mit den klassischen Netzwerktools eingerichtet und gesteuert werden.
4.5
Modem
Ein ”Modem” empfängt Daten von der seriellen Schnittstelle und verschickt sie über die
Telefonleitung oder Zweidraht-Standleitung. Externe Modems werden zwischen serielleroder USB-Schnittstelle und Telefon geschaltet. Interne Modems (PC-Einschubkarte) besitzen eigene serielle Schnittstellen. Die Datenrate ist durch die Eigenschaften der analogen
Telefonleitung beschränkt und liegt zur Zeit höchstens bei 56 kbit.
Modems waren sehr lange Zeit traditionell über die serielle Schnittstelle an Computer
oder entsprechende Geräte angeschlossen. Unter Linux erfolgt der Zugriff auf diese Schnittstellen über Device-Dateien vom Type Character-Device im Verzeichnis /dev. Die Schnittstellen werden dabei durchnummeriert mit ttyS0 bis ttySn. Das Netzwerkinterface ist dabei
nicht mit der Device-Datei gleichzusetzen, sondern hängt von der Art der Verbindung ab:
Bei PPP-Verbindungen handelt es sich dann um ein Interface mit der Bezeichnung ppp0
oder folgende, welches mit den Standardwerkzeugen für Netzwerkinterfaces aufgesetzt und
ausgelesen werden kann.
Handelt es sich um ein USB-Modem, wird es nicht mehr über eine Device-Datei vom
Typ ttySn, sondern über eine entsprechende USB-Device-Datei angesprochen. Auch hier
sieht man den typischen schichtenweisen Aufbau von Protokollen: Die Geräte auf unterster
Ebene können sich unterscheiden, das Netzwerk-Interface bleibt weiterhin identisch: ppp0
und entsprechende.
4.6
ADSL
Die Grenzen der Übertragungskapazität der analogen Telefonleitungen sind durch das Nyquistund das Shannon-Theorem beschrieben. Das Nyquist-Theorem besagt, dass die Schrittgeschwindigkeit bei der verzerrungsfreien Übertragung von Impulsen maximal doppelt so groß
sein darf wie die Bandbreite des benutzten Übertragungskanals. Das Shannon-Theorem
zeigt Zusammenhänge zwischen der verfügbaren Bandbreite - dem Verhältnis zwischen
Signal- und Rauschpegel - und der maximal möglichen Anzahl übertragbarer Bits pro Sekunde. Beim derzeitigen analogen Telefonnetz ist die Bandbreite auf 4 kHz beschränkt und
das Signal-/Rauschverhältnis liegt bei 30 bis 35 dB. Daraus resultiert eine Übertragungsrate
von maximal 35 kBit/s (für Modems!)
4.6. ADSL
4.6.1
35
Designüberlegungen
Allerdings ist das Erreichen der maximalen Übertragungsgeschwindigkeit von verschiedenen
Faktoren abhängig: Insbesondere die Länge und der Querschnitt des Kupferkabels, sowie
die Dämpfung begrenzen die theoretisch möglichen Transferraten. In der Praxis bedeutet
das für Anwender, deren Hausanschluß weit von der nächsten Vermittlungsstelle entfernt
liegt, Tranferraten im unteren Bereich.
ADSL basiert technisch auf der Trennung des nutzbaren Frequenzspektrums in drei
Kanäle. Hierbei finden zwei unterschiedliche Verfahren Verwendung: Frequency Division
Multiplexing oder Echo Cancellation (EC). EC spielt jedoch eine eher untergeordnete Rolle.
Grund dafür ist, dass im Gegensatz zu FDM die Kanäle für Up- und Downstream nicht
komplett getrennt, sondern überlagert werden. Dies erhöht den technischen Aufwand zur
Signaltrennung wesentlich und verteuert die Endgeräte.
FDM hingegen erzeugt einen schmalbandigen Frequenzbereich, der direkt oberhalb der
Sprachfrequenzen angesiedelt ist. Der breitbandige Downstream-Bereich schließt direkt an
den Upstream-Bereich an. Frequency Division Multiplexing beziehungsweise Echo Cancellation sorgen lediglich für die Trennung des Frequenzspektrums in entsprechende Kanäle,
schaffen also nur die Grundlage für den eigentlichen Datentransfer. Dieser kann wiederum durch verschiedene Übertragungsmethoden realisiert werden. Auch hier läßt die ADSLSpezifikation - die in Händen von ANSI (American National Standards Institute) und ETSI
(European Telecommunications Standards Institute) liegt - verschiedene Methoden zu. Daher kommen derzeit in der Praxis drei Modulationsverfahren zum Einsatz, die zueinander
inkompatibel sind. Ähnlich wie anfangs bei der 56 k-Technik kann es also dem Anwender
passieren, dass eine Kommunikation trotz gleicher Basistechnologie scheitert. Im folgeden
Kapitel werden verschiedene Übertragungsverfahren beschrieben.
4.6.2
4.6.2.1
Übertragungsmethoden
QAM
Quadrature Amplitude Modulation versetzt die Signale einfach in einen höheren Frequenzbereich versetzt. Dies wird durch Modulation eines Basisbandsignals mit einem Trägersignal
erreicht, wobei die Amplitude moduliert wird.
QAM ist ein sogenanntes Einträger-Bandpaßübertragungsverfahren, das ein Trägersignal mit einem Symbolstrom moduliert. Bei diesem Verfahren wird der Datenstrom in
zwei einzelne Ströme mit halber Übertragungsrate aufgespaltet und anschließend mit einem Trägerpaar aufmoduliert. Bei den orthogonalen Trägern handelt es sich um eine Sinusund eine Kosinusfunktion.
Der Sender beinhaltet einen Scrambler (Chiffrierer), einen Leitungskodierer, einen Sendefilter, einen Modulator und einen D/A- Wandler. Das Signal wird in einem Demultiplexer
in zwei Teilsignale aufgeteilt. Diese Teilsignale durchlaufen anschließend die Leitungscodierer, die eine Bit-nach-Symbol-Kodierung ähnlich wie bei der 56 kbit-Technologie vornehmen.
Anschließend werden die kodierten Signale im Modulator mit einer definierten Frequenz
(f0) multipliziert. Das eine Signal wird mit einem Kosinus, das andere mit einem Sinus
moduliert. Anschließend erfolgt die Addition sowie eine D/A-Wandlung. Ein Sendefilter
schließlich bringt das Signal auf die Leitung.
Auf der Empfängerseite passiert ähnliches: Das Signal wird zunächst in einem Empfangsfilter bandbegrenzt und nach einer A/D-Wandlung mit einem Kosinus- beziehungsweise Sinusträger gleicher Frequenz wie beim Sender multipliziert. Ein nachfolgender Entzerrer macht eventuell bei der Übertragung aufgetretene Verzerrungen des Leiterpaares
36
KAPITEL 4. WAN HARDWARE
rückgängig und filtert die Frequenzanteile (f0) heraus. Danach liegt wieder das ursprüngliche Basisbandsignal vor. Dieses wird für das jeweilige Signal getrennt dekodiert, um die
Teilsignale schließlich in einem Multiplexer (zur Serialisierung der Signale) zusammenzufassen.
4.6.2.2
CAP
(Carrierless Amplitude/Phase Modulation) Grundlage von CAP ist eine trägerlose Amplituden/ Phasenmodulation. Ein einziges Trägersignal dient als Transportmittel, das selbst
weder übertragen wird, noch eigene Informationen beinhaltet.
Auch CAP zählt zu den Einträger-Bandpaßübertragungsverfahren. Schon die Bezeichnung des Modulationsverfahren deutet seine Besonderheit an: Es wird eine trägerlose Amplituden/ Phasenmodulation durchgeführt, wobei ein technischer Kniff die Übertragung der
Trägerfrequenz verhindert. Zusätzlicher Unterschied zu QAM: Modulation und Demodulation erfolgen beim Sender und Empfänger über digitale Filter.
Die Grafik verdeutlicht die Arbeitsweise der CAP. An die Stelle der orthogonalen Trägerfunktionen von QAM treten digitale Filter, um die Teilströme zu modulieren. Das zu übertragende Signal wird einfach durch Addition der beiden Filterausgaben gebildet.
Nachdem das Signal eine D/A-Wandlung erfahren hat und den Sendefilter passiert hat,
wird es auf die Leitung gelegt.
4.6.2.3
DTM
(Discrete Multi-Tone Modulation) beschreibt ein Verfahren, bei dem mehrere Trägersignale
für die Übermittlung eingesetzt werden. Die übermittelten Daten verteilen sich also auf eine
Vielzahl von Trägern, die alle eine Form der Quadrature Amplitude Modulation (QAM)
einsetzen. DMT basiert auf der Discrete-Fast-Fourier-Transformation, die aus der digitalen
Technik stammt.
Im Unterschied zu CAP und QAM zählt Discrete-Multi-Tone-Modulation zu den sogenannten Mehrträger-Bandpaßübertragungsverfahren. Dieses Verfahren findet bei den Herstellern derzeit breite Unterstützung. Zur Umsetzung wird der gesamte Übertragungskanal
in mehrere Teilkanäle unterteilt, die - theoretisch - die gleiche Bandbreite aufweisen. Im
einfachsten Fall findet bei jedem dieser Teilkanäle das gleiche Modulationsschema Verwendung. Die Übertragungsrate ist daher identisch. Allerdings hat dies einen entscheidenden
Nachteil gegenüber den zuvor beschriebenen Modulationsmethoden: Wenn Teilkanäle in
hohen Frequenzbereichen liegen, so schlagen sich die schlechten Übertragungseigenschaften
von Kupfer auf den Datentransfer nieder. Daher legen die Hersteller die Bitrate des jeweiligen Teilkanals entsprechend seiner Störanfälligkeit fest. Nur so ist eine optimale Nutzung
des Übertragungsmediums Kupfer möglich.
DMT läßt sich im Prinzip als eine Reihe von parallel arbeitenden QAM-Systemen verstehen. Dabei verwendet jedes QAM-System die zu einem DMT-Teilkanal korrespondierende
Trägerfrequenz. Der Transmitter moduliert Daten, indem er Töne bestimmter Frequenzen
erzeugt, diese zusammenfaßt und schließlich über die Leitung schickt.
4.6.3
Vorteile der neuen Technik
Bei hinreichend kleiner Teilkanalbandbreite ist die Dämpfung für jeden einzelnen Teilkanal
nahezu konstant. Ein weiterer Vorzug dieser Technik: Beim Empfänger entfällt der Entzerrer. Es reicht ein einfacher Kanalverstärker, da der Einfluß der nichtlinearen Phase des
4.7. ATM
37
Kabels auf das übertragene Signal in einem Teilkanal vernachlässigbar ist. Damit ist die
Herstellung derartiger ADSL-Modems relativ preiswert.
Allerdings setzt ein Mehrträger-Modulationsverfahren Orthogonalität zwischen den verschiedenen Teilkanälen voraus. Dies kann man beispielsweise durch die Verwendung von
Fast-Fourier-Transformation-Methoden erreichen. Der Aufbau eines DMT-ADSL-Transceivers entspricht im wesentlichen dem eines CAP-ADSL-Gerätes.
Wie bereits erwähnt, kann die Anzahl der Bits, die über einen Teilkanal gesendet werden,
bei DMT variieren. Daraus ergibt sich eine verbesserte Performance, da störanfällige Frequenzen außen vor bleiben. Die mögliche Übertragungsrate beim Upstream-Kanal erhöht
sich dabei auf 256 kBit/s.
4.6.4
Benutzung unter Linux
Klassischerweise verfügen ADSL-Geräte beim Endnutzer über Ethernet- oder ATM-Schnittstellen, wobei üblicherweise nur erstere benutzt werden (können). ADSL stellt die Grundlage
für das Tunneln von Ethernetframes bereit. Damit eine benutzerbasierte Authentifizierung
erfolgen kann - die Ethernet selbst nicht bereitstellt - wird ein spezielles Protokoll, das
PPPoE2 , eingesetzt.
Linux kommuniziert auf dem unteren, dem Ethernet-Layer, klassischerweise über die
eingebaute Ethernet-Netzwerkkarte. Diese sollte vom Kernel treiberseitig unterstützt sein,
womit ein Netzwerk-Interface vom Typ eth0 und folgende (für weitere Netzwerkkarten)
zur Verfügung steht. Darüberhinaus wird ein Software-Treiber benötigt, der das PPPoEProtokoll zur Verfügung stellt. Als Netzwerk-Interface steht anschließend eines vom Typ
ppp0 (und weitere) zur Verfügung. Damit wird über das broadcastfähige Medium “Ethernet” eine Punkt-zu-Punkt-Verbindung zwischen zwei Rechnern aufgebaut.
4.7
ATM
Unter der Zielsetzung, die Grundlagen für eine weltweit einheitliche Netz-Architektur zu
schaffen, veröffentlichte die ITU 1984 die erste Empfehlung zum Schmalband-ISDN, kurz
ISDN. Nachdem als Implementierungsversuch des Breitband-ISDN (B-ISDN) zu dieser Zeit
auch STM in Erwägung gezogen wurde, entschied sich die ITU 1987 für den Asynchronous
Transfer Mode (ATM). Die ersten Empfehlungen hierzu wurden in den Jahren 1990/91
veröffentlicht.
Neben der ITU kam es im September 1991 zur Gründung eines weiteren Gremiums,
welches sich ausschließlich mit der Standardisierung von ATM befaßt, dem ATM-Forum.
Gegründet von CISCO-Systems, NET/adaptive, Northern Telekom und US-Sprint, gehören
dem ATM-Forum inzwischen mehrere hundert Mitglieder an.
Ziel des ATM-Forums ist ein zügiges Voranbringen des Standards ATM in enger Zusammenarbeit mit der ITU und der Industrie. Bei der Normierung früherer Standards war
es aufgrund des langwierigen Normierungsprozesses oft zu einem Auseinanderdriften von
ITU-Norm und von der Industrie entwickelten Quasistandards gekommen.
Wie auch andere Übertragungsverfahren basiert ATM grundsätzlich auf einer Paketübertragungstechnik. Hierbei sind jedoch folgende wesentliche Änderungen bzw. Ergänzungen zu bisherigen Paketvermittlungsverfahren festzuhalten:
2
PPP über Ethernet: PPP-Pakete werden als Ethernetframes geschickt, welche selbst wiederum über
den ADSL-Layer laufen. Damit erfolgt in den beiden unteren Schichten des OSI-Modells nochmals eine
Untergliederung.
38
KAPITEL 4. WAN HARDWARE
• Feste Paketlänge: ATM nutzt zur Übertragung ausschließlich Pakete mit einer festen
Länge von 53 Bytes. Diese kleinste unteilbare Übertragungseinheit wird daher ATMZelle genannt.
• Qualitätsparameter der Verbindung: ATM unterstützt QoS. Die hierzu notwendigen
Parameter und Betriebsmittel werden beim Aufbau einer Verbindung festgelegt bzw.
zugewiesen.
• Verbindungsorientierte Betriebsweise: ATM agiert grundsätzlich verbindungsorientiert. Die Umsetzung verbindungsloser Dienste höherer Schichten ist vorgesehen.
• Verzicht auf eine abschnittsweise Fehlersicherung: Die sehr geringen Bitfehlerwahrscheinlichkeiten heutiger Lichtwellenleiter ermöglichen den Verzicht auf eine abschnittsweise Fehlersicherung zugunsten einer höheren Übertragungsrate.
• Verzicht auf eine abschnittsweise Flußsteuerung: Aufgrund der hohen Übertragungsund Verarbeitungsgeschwindigkeiten ist eine abschnittsweise Flußsteuerung nicht möglich.
• Außenband-Signalisierung: Wie im Schmalband-ISDN wird die Signalisierung durch
Nutzung separater Signalisierungskanäle vom Nutzdatenstrom entkoppelt.
4.7.1
Die ATM-Zelle
Die ATM-Zelle ist eine starre Einheit von 53 Bytes. Sie besteht aus einen 5 Bytes langen Header sowie 48 Bytes Nutzinformation (Payload). Es wird zwischen zwei Arten von
ATM-Zellen unterschieden, die sich in der Belegung der Bits 5-8 des ersten Headerbytes
unterscheiden:
0
1
2
3
Flow Control (GFC)
4
5
6
7
8 Bit
Channel Identifier
Channel Identifier (VCI)
Path Identifier (VPI)
Path Identifier
PT
CLP
HEADER CHECKSUM (CRC)
Header einer User Network Interface Zelle
Abbildung 4.1: User-Network-Interface Zelle
UNI-Zellen Die User-Network-Interface-Zellen dienen zur Kommunikation zwischen
Nutzer- und Benutzer-Netzwerk-Schnittstelle (User-Network-Interface, UNI). Der Header
der UNI-Zelle unterteilt sich in sechs Elemente, die in der Abbildung dargestellt sind. Das
Feld GFC (Generic Flow Control) dient der direkten Zugriffssteuerung auf ein Übertragungsmedium. Es ist daher nur im Bereich lokaler ATM-Netze von Relevanz und wird von ATMVermittlungsstellen und Cross-Connects am NNI-Interface überschrieben. Eine Standardisierung zur Nutzung des GFC Feldes steht bislang aus.
4.7. ATM
39
Zur Adressierung stehen die Felder VPI (Virtual Path Identifier) und VCI (Virtual
Channel Identifier) zur Verfügung. Sie werden im Abschnitt weiter betrachtet.
Anhand des Feldes PT (Payload Type) wird zwischen Benutzerzellen und OAM-Zellen
(Operation and Maintenance) unterschieden. Der Standardwert ist 000. Die Funktion der
OAM-Zellen liegt in der Überwachung des Systems. Sie ermöglichen die Aufdeckung und
Behebung von Fehlfunktionen auf allen ATM-Ebenen.
PT-Feld
000
001
010
011
100
101
110
111
Bedeutung
Benutzerzelle, keine Überlast festgestellt, SDU-Type=0
Benutzerzelle, keine Überlast festgestellt, SDU-Type=1
Benutzerzelle, Überlast festgestellt, SDU-Type=0
Benutzerzelle, Überlast festgestellt, SDU-Type=1
Segment-OAM-F5-Zelle
End-to-End-OAM-F5-Zelle
Reserviert für zukünftiges Lastmanagement
Reserviert für zukünftigen Gebrauch
Tabelle 4.4: Mögliche Nutzlasttypen von ATM
Das Feld CLP (Cell Loss Priority) definiert die Priorität einer Zelle. Bei auftretender
Überlast an Netzwerkschnittstellen werden Zellen mit niedriger Priorität (CLP=1) zuerst
verworfen. Eine Priorisierung bzw. Markierung von Zellen erfolgt, wenn die sie erzeugende
Anwendung Resourcen in höherem Maße belegt, als ihr zugeordnet wurde. Verworfen werden
also erst die Zellen, die außerhalb ihrer QoS-Parameter generiert wurden, bzw. Zellen deren
Priorität bereits bei ihrer Generierung auf 1 gesetzt wurde.
Die letzten 8 Bits werden durch das Feld CRC (Cyclic Redundancy Checksum) belegt.
Bei der Bildung der Prüfsumme werden dabei nur die 32 Bits des Zellheaders (ohne CRCFeld) berücksichtigt. Die Bildung einer Headerprüfsumme ist sinnvoll, da sich die Informationen des Headers an jedem NNI, den die Zelle passiert, ändern kann, die Nutzinformation
jedoch erhalten bleibt.
NNI-Zellen Die Network-Node-Interface-Zellen werden entsprechend zur Kommunikation zwischen den einzelnen Knoten des ATM-Netzwerks genutzt (Network-Node-Interface,
NNI).
0
1
2
3
4
5
6
7
8 Bit
Channel Identifier (VCI)
Channel Identifier
Path Identifier
Path Identifier (VPI)
Path Identifier
PT
CLP
HEADER CHECKSUM (CRC)
Header einer Network Node Interface Zelle
Abbildung 4.2: Network-Node-Interface Zelle
40
KAPITEL 4. WAN HARDWARE
Im Vergleich mit dem UNI-Header ist das VPI-Feld des NNI-Headers um 4 Bit verlängert.
Dies trägt der pfadorientierten Wegelenkung (Routing) in ATM-Weitverkehrsnetzen Rechnung, sowie der Tatsache, daß hier eine direkte Zugriffskontrolle auf das Übertragungsmedium nicht benötigt wird.
4.8
FDDI
Für Backboneverbindungen in grossen LAN’s kam bis zum Ende der 90er Jahre üblicherweise FDDI (Fiber Distributed Data Interface) zum Einsatz. FDDI erlaubt maximale Kabellängen von bis zu 200km, die maximale Geschwindigkeit von 100 Mbit ist jedoch der
Grund, weshalb FDDI nicht mehr eingesetzt wird.
FDDI verwendet einen anderen Ansatz bei der Datenübertragung, bei dem eine Reihe
sogenannter Tokens ausgesandt werden. Eine Station darf nur dann ein Paket übertragen,
wenn sie eines dieser Tokens auffangen konnte. Somit entfällt wie bei TokenRing das Problem der Paketkollisionen.
4.9
Mobilfunknetze
Das Interesse an “Internet überall” hat mit der Vielzahl mobiler Endgeräte deutlich zugenommen. Laptops und PDAs sind keine Seltenheit mehr, sondern inzwischen die Grundausstattung der verschiedenen Datennomaden. Die Nahfunktechniken nach dem 802.11 Standard beherrschen dabei das Feld. Daher sind die meisten Geräte dafür schon werksseitig
mit einem entsprechenden Netzwerkadapter ausgestattet. Diese schöne neue Welt dieser
Netze weist jedoch noch gravierende Löcher in der Abdeckung auf, so dass schnell nicht
mehr von einem wirklich mobilen Internetzugang gesprochen werden kann. Es gibt zwar
eine wachsende Zahl von Hotspots, leider jedoch auch eine wachsende Anzahl durchaus
unterschiedlicher Zugangsprocederes. Wenn auch an vielen Stellen noch offene WLANs zu
finden sind, so ist die Benutzung eines solchen Zugangs ohne Einverständnis des Betreibers
nicht unbedingt legal.
Obwohl schon seit einigen Jahren am Start erhielten die Datendienste über die Mobilfunknetze erst mit der Einführung von UMTS wieder größere Aufmerksamkeit. Mobilfunknetze
decken zu fast 100% das Land ab und erlauben damit fast überall und jederzeit online zu
gehen.
4.9.1
GSM, HSCSD, GPRS und UMTS
Es gibt inzwischen eine ganze Reihe von Methoden Daten in Mobilfunknetzen zu transportieren. GPRS (General Packet Radio Service ist sicherlich das inzwischen verbreiteste
Verfahren und wird von allen Mobilfunkbetreibern fast überall angeboten. Es arbeitet mit
zeitunabhängigen Volumentarifen. GPRS kommt nicht nur beim Internet-Zugriff via PC
zum Einsatz, sondern versendet auch MMS (Multimedia Message und wird zum Transport
von WAP-Inhalten eingesetzt.
Darüberhinaus gibt es HSCSD. Dieses belegt für die Online-Zeit einen GSM-Mobilfunkkanal und wird daher zeitbezogen abgerechnet. HSCSD ist bei weitem nicht so verbreitet
wie inzwischen GPRS. Die Zukunft liegt sicherlich erstmal in UMTS. Wenn auch die Anbieter immer noch nach einer ”Killerapplikation” suchen, um von den Kunden das Geld
für die Lizenz wieder einzusammeln, so ist jetzt schon für den Internet-Zugriff eine ernstzunehmende Alternative. Die erreichbaren Geschwindigkeiten, so eine Zelle verfügbar und
4.10. NETZWERKADAPTER FÜR MOBILFUNKNETZE
41
nicht ausgelastet ist, liegen bei 384 kbit/s. Das ist deutlich mehr als die ca. 55 kbit/s mittels GPRS oder HSCSD. Da UMTS bei weitem nicht die Abdeckung von GSM erreicht,
ist ein Fallback auf GPRS vorgesehen. Daraus resultieren oft identische Volumentarife für
GPRS und UMTS. Die entsprechenden Netzwerkadapter für UMTS beherrschen daher beide Übertragungsverfahren.
4.10
Netzwerkadapter für Mobilfunknetze
Wie für jedes andere Netzwerk auch, benötigt man einen passenden Netzwerkadapter. Der
Adapter für Mobilfunknetze kommt üblicherweise als PCMCIA- oder Cardbus-Karte daher.
Alle neueren Mobiltelefone bringen GPRS-Unterstützung mit und kommen ebenfalls als
Zugangshardware in Frage. Vielfach wird dieser Adapter auch als ”Modem” bezeichnet,
da es sich um einen Netzwerkzugang per Telefonnetz handelt. Das Mobilfunknetz arbeitet
jedoch von sich aus schon digital. Deshalb ist eine (De)Modulation gar nicht mehr nötig.
Trotzdem findet man einige Anleihen aus der Modem-Welt wieder.
Die meisten Mobiltelefone unterstützen GPRS. Eine gewisse Schwierigkeit stellt die
Verbindung zwischen Rechner und Handy dar. Hier gibt es je nach Ausstattung der Geräte
drei Möglichkeiten. Die Verbindung mittels Bluetooth ist sicherlich die modernste Variante.
Hierzu müssen selbstredend beide Seiten mit dieser Art des Drahtlosfunks ausgestattet sein.
Das Fehlen an Laptop oder PC ist kein Problem, da man Bluetooth per USB-Dongle oder
PCMCIA-Steckkarte nachrüsten kann. Die drahtlose Verbindung zwischen den Geräten hat
den Vorteil, dass sich das Telefon für optimalen Empfang leicht positionieren lässt. Jedoch
sorgt Bluetooth gerade auf der Seite des Mobiltelefons dafür, dass sich dessen Akkulaufzeit
oft deutlich reduziert.
Ebenfalls sollte man die Datensicherheit im Blick. Unter Umständen ist ein Mobiltelefon
in einem weiten Umkreis sichtbar. Wenn dann auch noch die Firmware einige gravierende
Sicherheitslücken aufweist, eröffnet man anderen vielleicht tiefere Einblicke in das Telefon
als einem lieb ist.
Unter Sicherheitsaspekten deutlich unproblematischer ist eine Verbindung mit optischem Drahtlos-Funk. Viele Mobiltelefone, eine große Zahl von tragbaren Computern und
PDAs haben Infrarot eingebaut. Die Reichweite von IrDA ist mit üblicherweise einem halben
Meter beschränkt. Ein weiterer Vorteil: Steckt das Mobiltelefon irgendwo in der Tasche, ist
es für andere per IrDA nicht mehr sichtbar. Die Ausrichtung der beiden kommunizierenden
Geräte zueinander ist nun entscheidend: Viel mehr als 30 Grad von der Hauptstrahlrichtung
sollte der Winkel nicht betragen.
Unter Energie- und Sicherheitsgesichtspunkten schneidet sicherlich die drahtgebundene
Verbindung zwischen Mobiltelefon und Rechner ab. Ältere Mobiltelefone beherrschen nur
die serielle, neuere Geräte auch USB-Verbindungen. Die entsprechenden PC-Gegenstücke
sind eigentlich immer vorhanden. Leider gibt es jedoch kaum Telefone bei denen das Kabel
schon beiliegt.
42
KAPITEL 4. WAN HARDWARE
Kapitel 5
TCP-IP
5.1
Schaffung von ”Inter-Nets”
In den bisherigen Abschnitten erfolgte die Einführung in das Thema Netzwerke, in die Konzepte der paketorientierten Datenübertragung, der Signalisierung und der Kodierung. Als
Protokolle der Hardwareebene wurden Ethernet und sehr kurz aus historischen Gründen
TokenRing besprochen. Diese Netzwerkhardware wird überlicherweise für Local Area Networks verwendet, da die überbrückbaren Entfernungen nur wenige einhundert Meter und
mit optischen Medien nur wenige Kilometer betragen.
Ethernet
10Base-T
803.11a
#2
192.168.2.0/22
#1
Router 2
Ethernet
1000Base-X
ATM over
ADSL
Internet
ATM over
ADSL
#1
192.168.6.0/24
#3
Router 1
#2
Router n
Ethernet
100Base-T
#2
#1
FDDI
Router 3
TokenRing
192.168.1.0/24
192.168.10.0/24
172.16.1.0/24
Abbildung 5.1: IP als Universalservice
Für Weitverkehrsnetze greift man auf überall verbreitete Telefonnetze in ihrer analogen oder digitalen Ausprägung zurück. Dann kommt entweder ein Modem oder ein ISDNAdapter als Netzwerkanschluss zum Einsatz. Auf diese Weise lassen sich verschiedene Hardwareausprägungen für die Paketübertragung nutzen. Jedoch besteht dadurch auch ein Problem: Ethernet ist zwar für fast alle Medientypen implementiert1 aber z.B. nicht für ZweiDraht-Verbindungen für weite Entfernungen. Die WAN-Techniken, wie z.B. ISDN und analoges Modem eignen sich kaum für die Vernetzung vieler Maschinen bzw. Komponenten.
ISDN und Modem können weite Entfernungen realisieren, bieten aber nur Punkt-zuPunkt-Verbindungen zwischen jeweils zwei dedizierten Interfaces2 . Verschiedene physikali1
Es existieren jeweils Standards für Koaxialkabel (10Base5 ThickEthernet/Yellow-Cable bzw. 10Base2
für Cheapternet), TwistedPair-Kabel (4 bzw. 8 adrig), Lichtwellenleiter, Funkwellen im 2.4 GHz-Bereich
2
In den typischen Einwahlsituationen von Internet-Providern handelt es sich dabei um spezielle Hardware,
welche eine große Anzahl von Netzwerkinterfaces in einer Maschine vereint.
43
44
KAPITEL 5. TCP-IP
sche Netze sind unumgänglich, da keine Technologie sich für alle Einsatzszenarios eignet.
Weiterhin sind Trennungen an bestimmten ”Grenzen”, wie abgeschlossene Firmen- oder
Abteilungsnetze durchaus gewünscht und aus Sicherheitsgründen notwendig.
Deshalb wird ein ”Universaldienst” geschaffen, welcher Verbindungen zwischen beliebigen Rechnern erlaubt. Dabei soll die Kommunikation über unterschiedliche Entfernungen,
durch unterschiedliche Netze (LAN oder WAN) und über verschiedene Medien realisierbar
sein. Virtuell soll jede Verbindung für die kommunizierenden Maschinen ”gleich” aussehen,
d.h. es sollen keine anderen Applikationen oder Protokolle in Abhängigkeit davon verwendet werden müssen, ob sich die Maschinen im gleichen LAN befinden oder über Kontinente
hinweg Daten austauschen.
Dabei soll keine Entscheidung für eine bestimmte Technologie3 getroffen werden, sondern ein Universalnetz über mehrere heterogene Netze hinweg geschaffen werden. Ein solcher
Universaldienst wird als ”Inter-Net” bezeichnet.
5.2
Überblick über TCP/IP
Im vorhergehenden Abschnitt wurde das OSI-Referenzmodell vorgestellt. In den nun folgenden Abschnitten soll nun das Referenzmodell für die TCP/IP-Architektur vorgestellt
werden. Das TCP/IP-Referenzmodell - benannt nach den beiden primären Protokollen
TCP und IP der Netzarchitektur beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANETs gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSIReferenzmodell entstanden, deshalb sind auch die Erfahrungen des TCP/IP-Modells mit in
die OSI-Standardisierung eingeflossen. Als Ziele der Architektur wurden bei der Entwicklung definiert:
• Unabhängigkeit von der Architektur der Hostrechner.
• Universelle Verbindungsmöglichkeiten im gesamten Netzwerk.
• Ende-zu-Ende-Quittungen.
• Standardisierte Anwendungsprotokolle.
• Unabhängigkeit von der verwendeten Netzwerk-Technologie.
Das TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus nur vier Schichten: Application Layer, Transport Layer, Internet Layer, Network Layer.
Applikationssschicht (application layer): Die Applikationsschicht (auch Verarbeitungsschicht genannt) umfaßt alle höherschichtigen Protokolle des TCP/IP-Modells. Zu den ersten Protokollen der Verarbeitungsschicht zählen SSH (für virtuelle Terminals), FTP (Dateitransfer), SMTP (zur Übertragung von E-Mail), DNS (Domain Name Service), HTTP
(Hypertext Transfer Protocol) etc.
Transportschicht (transport layer): Wie im OSI-Modell ermöglicht die Transportschicht
die Kommunikation zwischen den Quell- und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser Schicht zwei Ende-zu-Ende-Protokolle definiert: das Transmission Control
Protocol (TCP) und das User Datagram Protocol (UDP). TCP ist ein zuverlässiges verbindungsorientiertes Protokoll, durch das ein Bytestrom fehlerfrei zu einem anderen Rechner im
3
Netzwerkhardware mit bestimmten darauf laufenden hardwarenahen Protokollen
5.2. ÜBERBLICK ÜBER TCP/IP
45
Internet übermittelt werden kann. UDP ist ein unzuverlässiges verbindungsloses Protokoll,
das vorwiegend für Abfragen und Anwendungen in Client/Server- Umgebungen verwendet
wird, in denen es in erster Linie nicht um eine sehr genaue, sondern schnelle Datenübermittlung geht (z.B. Übertragung von Sprache und Bildsignalen). Diese Protokolle werden
gleich noch ausführlicher behandelt.
Internetschicht (internet layer): Die Internetschicht im TCP/IP-Modell definiert nur
ein Protokoll namens IP (Internet Protocol), das alle am Netzwerk beteiligten Rechner
verstehen können. Die Internetschicht hat die Aufgabe IP-Pakete richtig zuzustellen. Dabei
spielt das Routing der Pakete eine wichtige Rolle. Das Internet Control Message Protocol
(ICMP) ist fester Bestandteil jeder IP-Implementierung und dient zur Übertragung von
Diagnose- und Fehlerinformationen für das Internet Protocol.
Netzwerkschicht (network layer): Unterhalb der Internetschicht befindet sich im
TCP/IP-Modell eine große Definitionslücke. Das Referenzmodell sagt auf dieser Ebene nicht
viel darüber aus, was hier passieren soll. Festgelegt ist lediglich, daß zur Übermittlung von
IP-Paketen ein Host über ein bestimmtes Protokoll an ein Netz angeschlossen werden muß.
Dieses Protokoll ist im TCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz
und Host zu Host ab. Das TCP/IP-Modell macht an dieser Stelle vielmehr Gebrauch von
bereits vorhandenen Protokollen, wie z.B. Ethernet (IEEE 802.3), PPP, etc.
SSH
FTP
HTTP
Transmission
Control P. (TCP)
DNS
DHCP
User Datagram
Protocol (UDP)
Internet Protocol (IP)
ICMP / ARP
Ethernet
ATM
FDDI
Modem
Application
Layer
Transport
Layer
Internet
Layer
ISDN
Network
Layer
Abbildung 5.2: Der TCP/IP-Protokoll-Stapel
Um Datenpakete im großen Umfang und möglichst schnell an verschiedenste Empfänger
schicken zu können, muß das Format der Adressen besonders gut von Computern oder speziellen elektronischen Schaltkreisen zu verarbeiten sein. Daher steckt das Konzept zur Verarbeitung der IP-Adressen im Binärformat (denn Host- und Domänennamen zu analysieren
kostete zuviel Zeit!) Maschinen-intern entsprechen dem üblichen, dezimalen Format der IPAdressen (a.b.c.d) pro Zahl 8-bits. IP-Adressen sind also insgesamt 32-bit lang, wobei die
Unterteilung in 8 bit Blöcke nur der Lesbarkeit halber eingeführt wurde. Dieses Format wird
auch Dotted Quad Notation genannt:
192.168.22.3 entspricht 11000000.10101000.00010110.00000011
In dieser simplen Form kann die Adresse von sehr primitiven und enorm schnellen LogikBausteinen analysiert werden und sehr schnell mit Netzmasken und Broadcastadressen zum
Routing berechnet werden.
46
KAPITEL 5. TCP-IP
5.3
Design
Für das Verständnis und die Behandlung des Internet-Protokolls sind einige Vereinbarungen
sinnvoll: Ein Host(-rechner): Meint ein beliebiges Computersystem, das an ein Internet
angeschlossen ist und auf dem Anwendungen laufen. Dabei spielt die Rechnerhardware,
Typ und Geschwindigkeit des Netzwerkes keine Rolle. Alle Hosts können ungeachtet der
Hardwareunterschiede (und Betriebssysteme) miteinander kommunizieren. Ein Router ist
ein Host mit mehrern Interfaces.
Eine (global) einheitliche Adressierung eines Hosts muss sichergestellt sein, damit ein
übergreifendes Inter-Net sinnvoll funktionieren kann. Das Internet-Protokoll (IP) ist Abstraktion der Konzepte seiner Entwickler. Es ist unabhängig von einer speziellen physikalischen Hardware angelegt. Die Implementierung findet ausschliesslich in Software statt. Damit kann es Bestandteil des Betriebssystems eines Rechners werden oder als eigenständige
Applikation, die unter einem Betriebssystem ausgeführt wird, laufen. Das Adressierungsschema bildet dabei die zentrale Komponente der Abstraktion. Zum einen können die physikalischen Adressen nicht ausreichen,4 zum anderen können sie sehr unterschiedliche Schemata5 verwenden.
Die Zustellung von IP-Paketen erfolgt analog zur Zustellung von Frames auf Hardwareebene. Die Adressierung der virtuellen Ebene läßt sich gut mit der physikalischen Adressierung vergleichen. Der Host trägt die Zieladresse in den Header6 des zu verschickenden
Datenpaketes ein und vermerkt seine eigene Adresse als Absenderkennung. Das Zielsystem,
welches durchaus ein Zwischenziel in Form eines Routers auf dem Weg eines Datenpaketes
sein kann, überprüft die Adresse auf Übereinstimmung mit der eigenen. Anhand dieser wird
das Paket behandelt: Im Falle eines Routers erfolgt die Weiterleitung in ein angeschlossenes
Netz, soweit ein geeignetes vorhanden ist. Erreicht das Paket den adressierten Host, kann
dieser die Absendeadresse als Ziel für das Verschicken einer Antwort verwenden. An jeder
Stelle auf dem Weg eines Paketes ist die entsprechende Protokollsoftware mit der Zustellung
beschäftigt.
5.4
Internet Protocol (IP)
Netzwerke sollen unabhängig von der verwendeten Hardware ein einheitliches Adressschema
verwenden. Die Beschränkung auf Ethernet verbietet sich allein schon wegen der begrenzten
Kabellängen im LAN. Der Hauptvorteil von IP besteht also darin, daß es physikalisch verschiedene Netzwerke zu einem scheinbar homogenen Netzwerk zusammenfaßt. Die Zusammenarbeit verschiedener Netze wird als ”Internetworking” bezeichnet, die Kommunikation
verläuft über das Internet-Protokoll (IP).
Es gibt nicht DAS Internet, sondern das Internet ist eine Sammlung von Teilnetzen,
die miteinander verbunden sind. Es gibt keine echte Struktur des Netzes, sondern mehrere größere Backbones, die quasi das Rückgrat (wie der Name Backbone ja schon sagt)
des Internet bilden. Die Backbones werden aus Leitungen mit sehr hoher Bandbreite und
schnellen Routern gebildet. An die Backbones sind wiederum größere regionale Netze an4
Obwohl das MAC-Adressierungsschema des Ethernets z.B. mit 248 mehr Adressen umfaßt als das
Internet-Protokoll der Version 4. Hier besteht jedoch die Schwierigkeit, dass die Adressen fest mit einem
Netzwerkadapter verknüpft sind, d.h. eine beliebige Abstraktion nicht möglich ist.
5
Die Zuordnung von Modem- oder ISDN-Leitungen könnte z.B. anhand der Telefonnummer erfolgen,
TokenRing und Ethernet verwenden MAC-Adressen.
6
speziell gekennzeichneter Kopf eines Datenpaketes, welcher keine Nutzdaten enhält, sondern Zustellvermerke speichert
5.4. INTERNET PROTOCOL (IP)
47
geschlossen, die LANs von Universitäten, Behörden, Unternehmen und Service-Providern
verbinden.
IP stellt die Basisdienste für die Übermittlung von Daten in TCP/IP-Netzen bereit.
Hauptaufgaben des Internet Protokolls sind die Adressierung von Hosts und das Fragmentieren von Paketen. Diese Pakete werden von IP nach bestem Bemühen (”best effort”) von
der Quelle zum Ziel befördert, unabhängig davon, ob sich die Hosts im gleichen Netz befinden oder andere Netze dazwischen liegen. Garantiert ist die Zustellung allerdings nicht.
Das Internet Protokoll enthält keine Funktionen für die Ende-zu-Ende-Sicherung oder für
die Flußkontrolle.
Das Internet-Protokoll muss eine Reihe von Aufgaben erfüllen, um eine End-zu-EndZustellung von Datenpaketen zu gewährleisten. Dazu zählt die Definition von Datagrammen,
welche die Basiseinheiten zur Datenübermittlung in Internets bilden. Weiterhin wird das
bereits angesprochene Adressierungsschema benötigt. Eine weitere Aufgabe besteht in der
Übermittlung der Daten von der Transportschicht zur Netzwerkschicht.7
Die Datagramme müssen geeignet durch das Netz geschleust werden, dieser Vorgang
wird als ”Routing” bezeichnet. Da auf diesem Wege durchaus unterschiedliche Arten von
Netzwerkhardware passiert werden kann, muss die optimale Framegröße nicht unbedingt
auf allen Teilstrecken identisch sein. Da die Framegröße nur anhand der Daten des ersten
Teilnetzes, in dem der sendende Host Mitglied ist, bestimmt wird, müssen Mechanismen
zur Verfügung stehen, mit eventuell kleiner werdenden Frame-Größen umzugehen. Daher
erlaubt das IP die Fragmentierung der Datagramme auf ihrem Weg durch das Netz und
das Zusammensetzen von diesen auf der Zielmaschine.
Die Funktionen von IP umfassen:
• Die Definition von Datagrammen, welche die Basiseinheiten für die Übermittlung von
Daten im Internet bilden.
• Definition des Adressierungsschemas.
• Übermittlung der Daten von der Transportebene zur Netzwerkschicht.
• Routing von Datagrammen durch das Netz.
• Fagmentierung und Zusammensetzen von Datagrammen.
IP benötigt deshalb ein hardwareunabhängiges Adressierungsschema; jedem Host (teilnehmender Rechner im ”Internet” wird eine eindeutige 32-Bit-Zahl zugewiesen, die sogenannte IP-Adresse. Die Dargestellung von IP-Adressen erfolgt üblicherweise durch vier
Dezimalzahlen, eine für jeden 8-Bit-Anteil, die durch Punkte voneinander getrennt sind.
IP ist ein verbindungsloses Protokoll, d.h. zur Datenübertragung wird keine Ende-zuEnde-Verbindung der Kommunikationspartner etabliert. Ferner ist IP ein unzuverlässiges
Protokoll, da es über keine Mechanismen zur Fehlererkennung und -behebung verfügt. Unzuverlässig bedeutet aber keinesfalls, daß man sich auf das IP Protokoll nicht verlassen
kann. Unzuverlässig bedeutet in diesem Zusammenhang lediglich, daß IP die Zustellung
der Daten nicht garantieren kann. Sind die Daten aber beim Zielhost angelangt, sind diese
Daten auch korrekt.
7
Das zugehörige OSI-Schichtenmodell ist Thema eines eigenen Kapitels
48
KAPITEL 5. TCP-IP
5.5
Spezifikation
5.5.1
IPv4-Standard
Mit den erfolgten Designüberlegungen und definierten Aufgaben des Internet-Protokolls
sind die wesentlichen Grundlagen gelegt. Nun kann die Spezifikation, d.h. die Festlegung
einzuhaltender Standards, des Protokolls erfolgen. Wie schon mehrfach implizit erwähnt
wurde, ist IP ein paketorientiertes Protokoll.
Die IP-Adresse ist eine 32 bit große Binärzahl, die jedem Host in einem Internet zugewiesen wird und für die gesamte Kommunikation mit jedem anderen Host in diesem Internet
verwendet wird. Dabei wird die Adresse virtuell in zwei Teile aufgespalten in ein Präfix und
ein Suffix, wobei die Aufteilung nicht statisch ist. Das Präfix einer IP-Adresse identifiziert
das Netz, in welchem sich der jeweilige Host mit seiner Adresse befindet.
Das Adress-Suffix identifiziert den Host in dem durch das Präfix bestimmten Netz. Jedes Netz verfügt damit über eine eindeutige Kennung, die Netznummer. Jede Netznummer
bzw. Network Number tritt nur einmal auf. Suffixes können in jedem Netz, dh. mehrfach, verwendet werden. Durch diese Festlegung soll das Routing effizient gestaltet werden
können.
Durch diese Festlegungen wird das wesentliches Designprinzip beschrieben: Jeder Host
erhält eine einheitliche Adresse, diese Adresse kann jeweils nur von einer Maschine verwendet werden. Es erfolgt eine globale Koordination bei der Zuteilung von Netznummern,
jedoch eine lokale Verteilung der Suffixes in den jeweiligen Teilnetzen. Es wird eine Delegationshierarchie geschaffen, die eine leichte Einordnung von Computern ermöglicht: Verschiedene Präfixes bedeutet verschiedene Netze; Gleiches Präfix heisst gleiches Netz. Das
erzwingt dann verschiedene Suffixes.
Das Internet Control Message Protocol (ICMP) ist eine Erweiterung des IP und wird
dazu verwendet, um Fehlermeldungen und ähnliches an andere Hosts weiterzugeben bzw.
die Erreichbarkeit von Hosts zu überprüfen. Neben der Erreichbarkeit von Rechnern gibt es
eine weitere Funktion für die Weitergabe bestimmter Routinginformationen, die Redirect
Messages. Diese wird vom Routing-Modul erzeugt, wenn es erkennt, daß es von einem
anderen Host als Gateway verwendet wird, obwohl es einen wesentlich kürzeren Weg gibt.
Weil dieses aber stark in die Funktionen des Hosts eingreift, ist das Ganze mit Vorsicht zu
geniessen. In einigen Fällen wird ICMP komplett abgeschaltet. Ein weiteres Hilfprotokoll
stellt das Address Resolution Protocol dar. Es dient der Zuordnung von Hardwareadressen
zu IP-Nummern. Beide Protokolle werden später in eigenen Abschnitten behandelt.
5.5.2
Notation
Für die Protokollsoftware ist die Binärdarstellung entscheidend, nur in dieser kann eine
effiziente Analyse der Adressen erfolgen. Jedoch besitzt diese auch Nachteile: Für Menschen,
die diese Adressen in ihren Applikationen verwenden, ist die Binärnotation schwer lesbar
und Verwechselungen leicht möglich.
Deshalb führt man die sogenannte Dotted-Quad-Notation ein. Die IP-Adresse wird
in vier Byte-Blöcke aufgeteilt, z.B. 11000000.10101000.00011001.11111110. Die PunktDezimal-Notierung liefert dann eine für das menschliche Auge leicht erfassbare, Darstellung.
Im Beispiel bleibend schreibt sich die genannte IP-Adresse nun: 192.168.25.254. Jeder Block
besteht dabei aus einem vorzeichenlosen Ganzzahlwert im Bereich 0 - 255.
5.5. SPEZIFIKATION
5.5.3
49
Adressbereiche
Der gesamte IP-Adressbereich erstreckt sich damit von Adresse 0.0.0.0 bis 255.255.255.255.
In der Binärdarstellung bedeutet dieses die Spannbreite von allen 32 Stellen ”Null” gesetzt
bis zu allen Stellen ”Eins” gesetzt. Die zuteilende Stelle für IP-Adressen bzw. -Bereiche
muss für jeden Adressanteil die Zahl der Bits festlegen, welche für das Präfix bzw. das
Suffix reserviert werden.
8 bits
8 bits
8 bits
8 bits
host
host
host
network
host
host
network
network
host
D 11 10
multicast
multicast
multicast
E 11 11
experi
mental
experi
mental
experi
mental
Class
A 0
network
B 10
C
net
work
11 0
net
work
Abbildung 5.3: Adressbereiche des IPv4
Die Zuordnung von einer größeren Zahl von Bits in einem Bereich bedeutet automatisch die Verfügbarkeit von weniger Bits im anderen Teil. D.h. die Verlängerung des Präfixes
liefert mehr definierbare Netznummern, aber weniger Hosts im jeweiligen Netz. Die Vergrößerung der Zahl der Hosts pro Netz geht zulasten der definierbaren Anzahl von Netzen.
Eine übergreifend einheitliche Festlegung ist jedoch kaum sinnvoll, da sehr unterschiedliche
Netze und Anforderungen existieren.
Das Internet-Protokoll ist aus Sicht der Computer- und Netzwerkevolution ein recht altes
Protokoll, d.h. nicht alle Entwicklungen konnten vorausgesehen werden. Der ursprünglich
festgelegte Adressraum erschien gross genug um alle damaligen Anforderungen abdecken zu
können8 . Weiterhin sollten IP-Adressen selbstbezeichnend sein, d.h. ohne weitere Angaben
sollte die Netzgröße, d.h. die Anzahl maximal enthaltener Hosts als Information bereits
beinhaltet sein.
Die frühe IP-Software interpretierte zur Ermittlung einer Adressklasse, die Einteilungsvorschrift des IP-Adressraumes, die ersten vier Bits. Diese wurden in einer Tabelle zur
schnelleren Bearbeitung verwaltet. Mit dieser Festlegung wurde eine Aufteilung des gesamten Adressraumes getroffen:
Die Aufteilung geschieht über die Internet Assigned Number Authority (IANA).
8
Es gab bei der Entwicklung von IP nur eine winzige Anzahl zu vernetzender Rechner und man schätzte
die Weiterentwicklung bei weitem nicht so stürmisch ein, wie sie später erfolgen sollte.
50
KAPITEL 5. TCP-IP
Bezeichnung
Class A
Class B
Class C
Präfix
7 bit
14 bit
21 bit
Suffix
24 bit
16 bit
8 bit
Netze
128
16.38
2.097.152
Hosts pro Netz
16.777.216
65.536
256
Tabelle 5.1: Aufteilung der IP-Adressklassen
5.5.4
Spezielle IP-Adressen
Besondere Adressierungen sollen im gemeinsamen Adressraum abgebildet werden. Deshalb
wurde eine Reihe von Spezialadressen definiert. Dazu zählen die Netzwerkadressen: Um den
Netzen einen ”Namen” zu geben, d.h. um sie direkt ansprechen zu können, erhalten diese
Adressen im Prefix die Netzwerk-Nummer und im Suffix Nullen.
Für den direkter Broadcast, d.h. um alle Rechner in einem gemeinsamen physikalischen
Netz eine Nachricht schicken zu können, wird das Netzwerkprefix verwendet und im Suffix
binäre ”Einsen” eingetragen. Der limitierte Broadcast erlaubt es, allen Rechnern im physikalischen Netz (in dem sich die Maschine gerade befindet) eine Nachricht zu schicken. Im
Netzwerkprefix und im Suffix werden ausschließlich ”Einsen” eingetragen.
”This Computer” stellt auch eine spezielle Anforderung dar: Wenn ein Rechner bootet
und dynamisch eine IP-Adresse erhalten soll, benötigt er eine Adresse zur IP-Kommunikation:
Im Präfix und Suffix ausschließlich Nullen. Diese Situation tritt z.B. bei festplattenlosen
Maschinen auf, die keine Möglichkeit haben, die Adresse irgendwo abzulegen. Dieses gilt
auch für mobile Maschinen, die zwischen verschiedenen Netzen wechseln.
Die ”Loopback Address” bietet eine auf jeder Maschine einheitliche Adresse. Viele Programme verwenden zur Kommunikation TCP/IP, selbst wenn die Maschine nicht an ein
Netzwerk angeschlossen ist. Zur schnellen IP-Kommunikation innerhalb der Maschine ist
als höchstes das Class-A Netzwerk9 definiert. Dieses erscheint aus heutiger Sicht durchaus
als Verschwendung, da in einem solchen Netz mehrere Millionen Rechner Platz finden.
Router erhalten auch IP-Adressen obwohl sie selten Applikationen zur Host-zu-HostKommunikation ausführen. Sie haben Verbindung in verschiedene physikalische Netze und
müssen in jedem dieser Netze adressierbar sein. Jede dieser IP-Adressen eines Routers bezeichnet mit ihrem Prefix das physikalische Netz. Dabei wird folgendes Prinzip angewandt:
IP-Adressen bezeichnen nicht direkt den Host, sondern die Verbindung eines Rechners zu
einem Netzwerk.
Zur Abgrenzung von Routern bezeichnet man Rechner mit mehreren IP-Adressen ohne
Routingfunktionalität als Multi-Homed-Hosts.
Beim Routing spielen einige IP-Adressen mit besonderer Bedeutung eine Rolle, die im
folgenden kurz vorgestellt:
Netzwerkadresse ist definiert durch ein Präfix. Der Teil, welcher den einzelnen Host
bezeichnet, wird mit Nullen am Ende aufgefüllt. So beschreibt die spezielle IP-Nummer,
z.B. 192.168.20.0 ein Klasse-C-Netzwerk mit max. 254 Teilnehmern.
Broadcastadresse für einen direkten Broadcast, d.h. ein Datenpaket an alle Teilnehmer
eines Teilnetzes, besteht aus dem Präfix mit Einsen am Ende, die den Hostteil auffüllen.
Im o.g. Beispiel wäre dieses die spezielle IP-Nummer 192.168.20.255.
9
127.0.0.0
5.5. SPEZIFIKATION
51
Defaultrouter heißt der Standardübergang zu anderen Netzen. Dieses ist eine Maschine,
die den ”Weg” zum restlichen Internet kennt. Der Defaultrouter ist eine Konvention, damit
nicht jeder Router im Netz alle Routen zu allen existierenden Netzwerken listen und verarbeiten muss. Diese Maschine muss aber zwingend Mitglied im jeweilgen Teilnetz sein. Im
Beispielnetz könnte dieses z.B. die IP-Adresse 192.168.20.254 sein. Dieses ist im Gegensatz
zu Netzwerkadresse und Broadcastadresse nicht standardisiert.
Netzwerkmaske wird durch die spezielle IP-Adresse beschrieben, welche mit binären
Einsen beginnt und mit binären Nullen endet. Der Übergang bezeichnet die Grenze zwischen
Prä- und Suffix und sollte eindeutig sein. Für das Beispielnetz lautet diese 255.255.255.0
und ist damit Netzmaske eines Klasse C-Netzes. Binär lautet sie: 1111 1111.1111 1111.1111
1111.0000 0000 Eine Netzwerkmaske für Netze mit nur einem Rechner besteht ausschliesslich aus ”Einsen”, die Netzwerkmaske für das gesamte Internet nur aus ”Nullen”. 0.0.0.0
bezeichnet deshalb die Defaultroute.
Weiterhin lautet die Netzwerkmaske z.B. für ein Klasse B Netz 255.255.0.0 und in der
Binärschreibweise 1111 1111.1111 1111.0000 0000.0000 0000. Häufig wird jedoch die sehr
lange und umständliche Darstellung mit der Angabe der Anzahl der ”Einsen” in ihrer
jeweiligen Darstellung abgekürzt.
Klasse
Class A
Class B
Class C
Beispiel
10.0.0.0
132.230.0.0
192.168.20.0
Anzahl der Einsen
8
16
24
Tabelle 5.2: Kurzdarstellung für Netze
Wenn man classless Routing einführt, dann haben Netze wieder Netzmasken von 0 bis
32. Deshalb sollten als ”Endungen” von Netzmasken nur die dezimalen Zahlen 255, 254,
252, 248, 240, 224, 192, 128, 0 auftreten. Man könnte natürlich versucht sein, kompliziertere
Muster von Netzmasken zu bauen und statt ein Klasse C-Netz in der Mitte zu teilen,
entlang der geraden und ungeraden IP-Nummern spalten. Dieses trägt jedoch extrem dazu
bei, Routingtabellen nicht mehr durchschauen zu können und sei daher nur dem erfahrenen
Netzwerkadministrator als Option genannt. Weiterhin wird man sich nicht immer darauf
verlassen können, dass jede TCP/IP-Implementation sauber mit dieser Art von Netzmasken
umgehen kann.
5.5.5
Private IP-Adressen
Der gesamte Adressbereich 127.b.c.d ist dem Loopback-Netz10 zugeordnet, dabei handelt
es sich um ein per Software simuliertes Netz. Einzige Maschine auf diesem loopback-Netz
ist die eigene; evtl. mit verschiedenen Namen. Die Adresse 127.0.0.1 bezieht sich stets
auf die eigene Maschine; sie kann zu keinen anderen Zwecken gebracht werden, als zur
Definition des ”das sind wir selbst”. Die Adresse a.b.c.0 ist für das lokale Netz (Netz”name”)
reserviert. Die Adresse a.b.c.255 ist für Nachrichten ”an alle” (Broadcast) reserviert11 .
Folgende Adreßbereiche sind zum Aufbau privater, nicht mit dem Internet verbundener
Netzwerke freigegeben:
• 10.0.0.0 - 10.255.255.255
10
siehe hierzu die Anmerkungen im vorherigen Abschnitt
Das Beispiel bezieht sich auf ein Class-C Netzwerk, bei einem Class-B sähe die der Netzname wie a.b.0.0
und die Broadcastadresse wie a.b.255.255 aus.
11
52
KAPITEL 5. TCP-IP
• 172.16.0.0 - 172.31.255.255
• 192.168.0.0 - 192.168.255.255
Diese Adressen werden im Internet nicht geroutet (d.h. die Pakete werden spätestens
am Router des eigenen LAN zum Internet wegegeworfen).
5.6
Der IP-Header
IP hat mehrere Aufgaben, dafür werden einige Informationen benötigt: Die Quell- und
Zieladresse; Informationen zum Weiterreichen an die höhere Netzwerkschicht; Fragmentierung12 ; ”Verfallsdatum”13 ; Länge des Pakets und die Prüfsumme.
32 bit
VERS.
IPHL
TYPE OF SERV.
D M
F F
IDENTIFICATION
TIME TO LIVE
TOTAL LENGTH
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE ADDRESS
DESTINATION ADDRESS
OPTIONS (ZERO OR MORE WORDS)
Abbildung 5.4: IP Paket-Header
Die einzelnen Header-Bestandteile:
• Version (4 bit) - Die Versionsnummer steht für die zu verwendende IP-Protokollversion.
Derzeit üblicherweise verwendet wird IPv4.
• H-Länge (4 bit): Die Header-Länge gibt an, wie viele 32 bit-Zeilen der gesamte IPHeader besitzt. Dadurch, dass das Optionen-Feld unterschiedlich lang werden kann,
ist es sinnvoll zu wissen, ab wo das Protokoll der nächst höheren Schicht beginnt.
• Service-Type (8 bit): Das TOS-Feld (Type of Service) bestimmt, um welche Art von
Daten es sich bei diesem Datagramm handelt. Diese Information ist hauptsächlich zu
Zeiten von überlastetem Netzwerkverkehr nützlich. Hier macht es Sinn die Anwendungsart (HTTP-Typ, FTP-Typ,...) der Daten zu wissen, um entsprechende Prioritäten beim Transport der Datagramme über eine Verbindungsleitung zu setzen.
Wirklich verwendet wird dieses Feld jedoch nicht.
• Länge (16 bit): Dieses Feld gibt an, wie viele Bytes das gesamte Datagramm überhaupt
enthält.
• Fragment-ID (16 bit): Gibt an um welches Paket es sich handelt. Das spielt eigentlich
nur eine Rolle, wenn fragmentiert werden muss. Da jeder Sender eine ID in dieses
Feld einträgt, ist es Dritten durchaus möglich verschiedene Maschinen hinter einem
Masquerading-Router zu identifizieren.
12
13
nicht alle darunterliegenden physikalischen oder logischen Netze haben die gleichen Eigenschaften
Unzustellbare Pakete müssen irgendwann das Netz wieder verlassen - also entsorgt werden
5.7. IP-ROUTING
53
• Flags (3 bit): Flags werden für die Fragmentierung benutzt, auf die im nächsten Abschnitt genauer eingegangen werden soll.
• Fragment-Offset (13 bit): Gibt an, an welcher Stelle das Fragment eingefügt werden
muss.
• TTL (8-Bits): Das Time-To-Live gibt an, wie viele verschiedene Netze (Hops) das
Datagramm auf seiner Reise noch benutzen darf. Somit wird verhindert, dass Datagramme endlos im Netzwerk herumirren.
• Höheres Protokoll (8 bit): Hiermit wir angegeben, um welches Protokoll es sich in der
nächsthöheren Schicht, also der Transportschicht, handelt. Ein Wert von 6 bedeutet,
dass das TCP-Segment über den entsprechenden Port an das TCP weiter verabreicht
werden soll. Ein Wert von 5 deutet hingegen auf das UDP in der Transportschicht
hin. Die Protokollnummer wird im IP-Jargon als der ”Klebstoff” bezeichnet, welcher die Netzwerkschicht mit der Transportschicht verbindet. Die Zuordnungen von
Protokollen und Nummern findet man in der Datei /etc/protocols.
• Prüfsumme (16 bit): Dieses Feld besitzt dieselbe Funktion wie das Prüfsummen-Feld
im TCP/UDP. Sie dient der Detektion von Bit-Fehlern in einem empfangenen Datagramm. Es stellt sich an dieser Stelle nun die Frage, warum sowohl auf der Transportschicht als auch auf der Vermittlungsschicht eine Prüfsumme berechnet wird. Ein
offensichtlicher Grund dafür ist, dass sowohl auf der Vermittlungsschicht als auch auf
der Transportschicht andere, wenn auch nicht häufig verwendete Protokolle existieren, die keine Prüfsummenberechnung durchführen, so dass es sinnvoll sein kann, die
Überprüfung der Korrektheit mittels der Prüfsummenberechnung auf beiden Schichten durchzuführen.
• Quell-IP-Adresse (32 bit): Gibt an, von welcher IP-Adresse das Datagramm ursprünglich kommt.
• Ziel-IP-Adress (32 bit): Gibt an, zu welcher IP-Adresse das Datagramm verschickt
werden soll.
• Optionen (je 32 bit): Diese Felder dienen der Erweiterung des IP-Headers.
5.6.1
Fragmentierung
Manche Teilstrecken im Netzwerk können nicht mit beliebigen Datagrammgrößen hantieren.
Jedes Netzwerkteilstück besitzt deshalb eine maximale Datagrammgröße MTU (Maximal
Transmission Unit). Die Router, die Datagramme zu diesen Routern senden, müssen also
stets überprüfen, ob die Größe der zu sendenden Datagramme die MTU der empfangenden
Router nicht übertreffen. Sollte dies der Fall sein, so werden die jeweiligen Datagramme
fragmentiert. Wenn ein Datagramm fragmentiert wird, so werden mehrere kleinere Datagramme erstellt, die dieselbe ID haben, jedoch ein gesetztes Fragment-Flag enthalten.
Durch das Fragment-Offset wird zudem angegeben, an welcher Stelle das Fragment in das
Datagramm eingefügt werden muss. Beim letzten Fragment ist das Fragment-Flag gelöscht,
um anzuzeigen, dass keine weiteren Fragmente mehr folgen.
5.7
IP-Routing
Eine entscheidende Aufgabe des Internet-Protkolls ist die Verbindung verschiedener Teilnetze untereineinder. Hierzu muss es eine geeignete Paketweiterleitung implementieren. Diese
54
KAPITEL 5. TCP-IP
wird als Routing bezeichnet. Zur Einordnung sei wiederholt, dass IP ein verbindungsloses
paketorientiertes Protokoll ist, welches definiert wurde, um die exklusive Belegung eines
Datenkanals zu verhindern. Erst auf darüberligenden Schichten kann der Nutzer entscheiden, ob er verbindungsorientierte oder -lose Kommunikation wünscht. TCP arbeitet verbindungsorientiert, UDP schafft einen einfachen Datagrammrahmen, der direkt auf IP aufsetzt.
Die Weiterleitungsentscheidung erfolgt beim Internet-Protokoll für jedes einzelne Paket
neu. Damit das Routing möglichst effizient erfolgen konnte, sollten IP-Adressen selbsterklärend sein, d.h. sie besitzen ein Präfix zur Netzwerkkennung. Mit dem Suffix wird der
Host im Teilnetz identifiziert. Deshalb erfolgte ursprünglich eine Klasseneinteilung des gesamten IP-Adressraumes in Klassen. Die Klassen A bis C definierten dabei gültige Adressen
mit fest vorgegebenen Prä- und Suffixlängen. Spezielle Adressen werden für die Netzwerkkennung eingeführt. So sind Netzwerke neben anderen IP-Spezialadressen innerhalb des
Namesraumes zu kennzeichnen. Mit dieser Festlegung ist eine gewisse Hierarchisierung der
Verteilung von IP-Adressen möglich.
5.7.1
Prinzip der IP-Netze
Bei der Planung eines lokalen Netzes gibt es zwei Zielsetzungen:
Direkter Datenverkehr zwischen allen lokalen Maschinen ohne Umweg über den Router
(sonst unnötige Belastung und Verzögerung)
Begrenzung der ”Reichweite” der Datenpakete auf das kleinst-mögliche Teil-Netz
(aus Sicherheitsgründen und zum Schutz anderer Teil-Netze vor unnötiger Belastung)
Die Einstellungen zum Umsetzen dieser Ziele sind:
Bezeichnung
networkaddress
subnet-mask
ip-address
Beschreibung
Adresse des eigenen Teil-Netzes, Vergleich mit IPAdresse gibt an, ob ein Datenpaket zum lokalen Netz
gehört oder nicht
Bitmaske zum Herausstanzen der Netzwerk- Adresse
aus der IP-Adresse einer Maschine
Eigene Adresse der Maschine
Tabelle 5.3: Abgrenzung der ”Reichweite” des lokalen Netzes
address 192.168.25.3
11000000.10101000.00011001.00000011
netmask 255.255.255.0
11111111.11111111.11111111.00000000
network 192.168.25.0
11000000.10101000.00011001.00000000
In diesem Beispiel bilden alle 254 Maschinen mit der Adresse 192.168.25.N ein gemeinsames Netzwerk. Darüberhinaus gibt es noch die ”broadcast-address”, die eine Adresse
für Nachrichten ”an alle” in diesem Teil-Netz ist. Rechnet man die Netzadresse14 und die
Broadcast-Adresse15 hinzu, kommt man für ein Class-C-Netz, wie hier dargestellt, auf 256
IP-Adressen (= 28 ).
14
15
die kleinste Adresse im Teilnetz, dieses ist eine nicht vergebbare IP!
die grösste Adresse im Teilnetz, auch diese IP sollte nicht für Rechner vergeben werden!
5.7. IP-ROUTING
5.7.2
55
Routing (Die Wege im Netz)
Der Datenverkehr findet zwischen den Netzwerkschnittstellen der Internet-Rechner statt.
Ein Linux-PC kann mehrere Netzwerkschnittstellen besitzen und als Vermittlungsstelle zwischen verschiedenen Netzen (Router) dienen. Dann kann es jedoch notwendig sein, die
Routing-(d.h. Paketforwarding-)Fähigkeit des Kernels einzuschalten. Dieses kann für jedes
Interface einzeln definiert werden. Der Name einer Netzwerkschnittstelle hängt von der verwendeten Netzwerktechnik ab (nicht etwa vom Hersteller der Einsteckkarte, wie bei anderen
Systemen).
Der Befehl route zeigt an, wie der Betriebssystemkern Datenpakete an die verschiedenen Empfänger verschickt:
shuttle:~/ > /sbin/route -n
Kernel IP routing table
Destination
Gateway
10.1.1.11
10.2.13.254
10.8.4.0
0.0.0.0
10.2.13.0
0.0.0.0
127.0.0.0
127.0.0.1
0.0.0.0
0.0.0.0
Genmask
255.255.255.255
255.255.255.0
255.255.255.0
255.0.0.0
0.0.0.0
Flags
UGH
U
U
UG
U
Metric
0
0
0
0
0
Ref
0
0
0
0
0
Use
0
0
0
0
0
Iface
wlan0
eth0
wlan0
lo
tun0
Alle gerade aktuellen Routen im Einzelnen kann man sich mit route -C anzeigen lassen.
Diese Liste wird aber in grösseren Netzen bzw. auf Gatewayrechnern sehr schnell sehr lang
werden. Informationen zum Routing können auch mit den Kommandos ip route oder
netstat -r erhalten werden. Jedes dieser Programme greift dabei auf das Kernel-ProcInterface zu.
Eine klassische Konfiguration sieht wie angezeigt aus: Es ist das lokale Ethernet definiert, in dem alle teilnehmenden Systeme ohne Router/Gateway erreicht werden können.
Alles was in diesem Bereich nicht zugestellt werden kann, wird dem Defaultrouter zur weiteren Zustellung überlassen. ”default” hat die IP 0.0.0.0 und meint das ganze Internet,
also den verbleibenden Rest, wenn die erste Route nicht angewendet werden konnte. Der
Defaultrouter (bzw. Defautlgateway) muss bereits in einem darüber definierten Routingeintrag bekannt gemacht worden sein (Mitglied im entsprechenden Subnetz sein), da es sonst
nicht erreicht werden kann! So genügt es zum Transport von IP-Paketen, dass jeder Rechner
im Internet entsprechend seines Horizontes Systeme kennt, die wieder die weiteren Wege im
Netz kennen. Bei den Flags deutet ”G” an, dass es sich um eine Gatewayroute handelt, also
die Pakete nicht im lokalen Subnetz zugestellt werden. ”H” deutet eine Hostroute an, dieses ist eine spezielle Form eines Sub-Netzes, da hier Point-to-Point- Verbindungen definiert
werden.
traceroute dient zur Verfolgung des kompletten Weges, den Datenpakete zu einem
bestimmten Empfänger einschlagen, z.B. zu traceroute www.heise.de:
shuttle:~ # traceroute www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 40 byte packets
1 10.1.1.11 4.992 ms
4.318 ms
6.315 ms
2 132.230.120.142 8.262 ms
10.373 ms *
3 nsc-rz-gwn.fun.uni-freiburg.de (132.230.0.141) 7.938 ms
7.307 ms \
7.639 ms
4 Freiburg1.Belwue.DE (129.143.15.141) 7.641 ms
9.846 ms
10.699 ms
5 Stuttgart1.BelWue.DE (129.143.1.7) 17.109 ms
17.503 ms
17.258 ms
6 Frankfurt1.belwue.de (129.143.1.26) 20.153 ms
20.314 ms
21.000 ms
7 de-cix.ffm.plusline.net (80.81.192.132) 20.998 ms
20.211 ms
\
20.627 ms
8 heise2.f.de.plusline.net (213.83.57.57) 14.674 ms *
13.516 ms
56
9
10
KAPITEL 5. TCP-IP
* heise2.f.de.plusline.net (213.83.57.57) 13.433 ms
13.599 ms
* * heise2.f.de.plusline.net (213.83.57.57)(N!) 13.537 ms
Ein weiteres Tool, auch zur grafischen Visualisierung, ist mtr, ”My Traceroute”.
”Router” leiten Datenpakete an entfernte Maschinen und sorgen für den Datenaustausch zwischen Teilnetzen. U.U. müssen die Pakete bis zum Ziel über mehrere Router
geleitet werden; darauf hat man aber keinen Einfluß. ”Router” oder ”Gateway” wird meist
synonym verwendet, wobei ein ”Gateway” eigentlich grundverschiedene Netze (Protokolle)
miteinander verbindet.
Der Routingeintrag, der zu einem bestimmten Interface gehört (im obigen Beispiel der
erste Eintrag) erfolgt ab dem Kernel Version 2.2 automatisch, wenn der Systemadministrator das Interface konfiguriert. Alle weiteren Routingeinträge müssen manuell über das
Kommando route erfolgen, was für den obigen Fall (ungekürzt) so aussehen würde:
shuttle:~/ # route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.10.156.1
Da man diesen Vorgang nicht jedesmal beim Neustart des Netzwerkes oder des ganzen
Rechners wiederholen möchte, können die weiteren Routingeinträge ublicherweise in der
Netzwerkkonfiguration hinterlegt werden.16
5.7.3
Einfaches Hostrouting
Wie werden Pakete bei einfachen Hosts, d.h. Maschinen mit einer einzigen Netzwerkverbindung zugestellt? Jede Maschine benötigt eine eigene IP-Nummer, z.B. 192.168.20.2. Dieses
ist eine gültige Adresse aus dem Bereich des genannten Beispielnetzes von 192.168.20.1
- 192.168.20.254. Insgesamt können also 254 IP-Nummern vergeben werden, da von den
256 Möglichkeiten die Netzwerknummer und die Broadcastadresse abzuziehen sind. Die
Verwaltung des Netzwerkes erfolgt auf den Routern und durch geeignete IP-Vergabe an
die Hosts. Alle Eintragungen erfolgen manuell. Jedoch sollte man beachten, dass IP nicht
überprüft, ob bestimmte Adressen bereits vergeben wurden. Für die dynamische Zuweisung
von IP-Adressen an Hosts hat sich das Dynamic Host Configuration Protocol als Standard
herausgebildet. Dieses wird in einem weiteren Abschnitt näher beleuchtet.
Jeder Host des Beispielnetzes enthält Routingtabelle. Diese fällt je nach Zahl der Interfaces und angeschlossenen Netzwerke unterschiedlich komplex aus.
Netzwerk
192.168.20.0
127.0.0.1
0.0.0.0
Netzmaske
255.255.255.0
255.0.0.0
0.0.0.0
Router-IP
192.168.20.254
Interface
Ethernet, TokenRing, ...
Loopback-Interface
Defaultroute
Tabelle 5.4: Routingtabelle eines Hosts
Die Defaultroute dient für alle anderen Adressen, die im eigenen Netz nicht zustellbar
sind. Deshalb wurde die Bezeichnung Defaultroute gewählt. Damit Pakete weitergeleitet
werden können, muss jedoch mindestens ein Router Mitglied des jeweiligen Teilnetzes sein.
5.7.4
Routingentscheidung
Routingentscheidungen erfolgen meistens entlang komplexerer Tabellen, als den in Hosts
verwendeten. Viele Pakete an Knotenroutern mit vielen Interfaces und hohen Bandbreiten
legen eine hardwarenahe Implementierung nahe. Durch die Bildung eines “logischen UND”
16
Die Konzepte unterscheiden sich dabei von Distribution zu Distribution durchaus erheblich.
5.7. IP-ROUTING
57
aus Ziel-IP und Netzmaske wird durch den Vergleich mit den Netzadressen ermittelt, ob
eine Route verwendet wird oder nicht.
Z.B. für das Ziel: 192.168.20.5 & 255.255.255.0 ergibt 192.168.20.0. Dieses wird mit
der Netzadresse verglichen. Wenn es passt, schicke auf diese. Andernfalls probiere nächste,
z.B. bei 24.46.192.77 & 255.255.255.0 ergibt 24.46.192.0 ungleich, also nächster Versuch
24.46.192.77 & 0.0.0.0 errechnet sich zu 0.0.0.0 - passt immer auf die Defaultroute.
Dabei startet man bei der kleinsten Netzmaske, also dem Netz mit den wenigsten Hosts.
Dann arbeitet man sich sukzessive bis zur größten Netzmaske17 alle eingetragenen Routen
ab. Die Defaultroute ist dabei eine Konvention zur Vereinfachung der Routingtabellen.
Kein Router kennt alle die Wege zu allen Internet-Adressen direkt, da fast jeder Router nur
einen Bruchteil des Adressbereiches verwaltet. Jeder dieser Router hat eine Route für alle
restlichen Bereiche. Auch ein einfacher Host kann mehrere Routen für verschiedene Netze
kennen, falls mehrere Router in seinem Teilnetz vorhanden sind.
Eine Entscheidungstabelle eines Routers könnte wie im nachstehend gezeigten Beispiel
aussehen. Die Netzmaske entscheidet über Reihenfolge der Einträge in der Routingtabelle.
Im Extremfall kann es also passieren, dass ein Paket gegen jede Regel geprüft wird.
Netz
192.168.20.128
192.168.20.0
10.10.2.0
10.10.0.0
10.4.0.0
10.0.0.0
0.0.0.0
Netzmaske
255.255.255.128
256.255.255.128
255.255.255.0
255.255.0.0
255.252.0.0
255.0.0.0
0.0.0.0
Gateway/Router
192.2.2.2
193.2.2.3
10.10.255.254
10.10.0.254
10.10.0.254
192.168.2.5
10.10.0.254
Interface
#1
#1
#2
#3
#4
#1
#3
Tabelle 5.5: Beispiel einer möglichen Routingtabelle
Eine Verwaltung von Routinginformationen in größeren Netzwerken wird sehr schnell
recht aufwändig. Deshalb wurden Protkolle entwickelt, um einige Aspekte automatisieren
zu können.
Dynamisches Routing soll Ausfälle erkennen und Alternativrouten finden und eintragen.
Hierzu sind verschiedene Strategien möglich:
Hop-Count: Wieviele Router liegen auf dem Weg von A nach B (was ist jedoch, wenn
der Weg über eine langsame ISDN-Leitung viel kürzer ist, als der ”Umweg” über ein viel
schnelleres LAN)
Open Shortest Path First: Routingmetrik nimmt weitere Kennzahlen einer Route auf
BGP: Border-Gateway-Protokolle für Router an den Grenzen großer Netzwerke
Obwohl Adressen zentral vergeben werden, erreicht man kaum eine nähere geografische
Zuordnung18 als auf Länder oder Kontinentebene. Lokal nahe beieinander liegende Firmen
oder Organisationen können durchaus netzwerktopologisch gewaltige Entfernungen besitzen, wenn sie über verschiedene Provider angeschlossen sind. IP-Netze sind eher daher eher
als ”provider-based” zu bezeichnen.
17
0.0.0.0 das gesamte Internet
Auch wenn es Firmen gibt, die zu jeder IP-Adresse eine ungefähre bis genaue geografische Koordinate
liefern können.
18
58
KAPITEL 5. TCP-IP
5.7.5
Subnetting und Supernetting
Frühe Router interpretierten zur Ermittlung der Adressklasse die ersten vier Bits und verwalteten diese in einer Tabelle zur schnelleren Bearbeitung. Dieses Konzept ist nicht mehr
wirklich praktikabel, denn z.B. Uni-Freiburg hat mit Netzadresse 132.230.0.0 und Netzmaske 255.255.0.0 ein Klasse-B-Netz. Aber: Nicht alle Rechner können in einem Ethernet
o.ä. zusammengefaßt werden, damit ist ein Routing wie im Beispiel kaum sinnvoll. Noch
extremer: Besitzer von Klasse-A-Netzen können nicht mehrere Millionen Rechner direkt
verwalten. In diesen Netzen wird üblicherweise ein Subnetting zur besseren Abtrennung
verschiedener Netze untereinander betrieben. Damit reduziert sich die Broadcast-Domain
und es wird eine Strukturierung des Netzes erreicht. Mit der Knappheit der IP-Adressen im
Netzmaske
255.255.0.0
255.255.128.0
255.255.192.0
255.255.224.0
255.255.240.0
255.255.248.0
255.255.252.0
255.255.254.0
255.255.255.0
Bitmuster der Netzmaske
11111111.11111111.00000000.00000000
11111111.11111111.10000000.00000000
11111111.11111111.11000000.00000000
11111111.11111111.11100000.00000000
11111111.11111111.11110000.00000000
11111111.11111111.11111000.00000000
11111111.11111111.11111100.00000000
11111111.11111111.11111110.00000000
11111111.11111111.11111111.00000000
Teilnetze
1
2
4
8
16
32
64
128
256
Anzahl IP’s
65.536
32.768
16.384
8.192
4.096
2.048
1.024
512
256
Tabelle 5.6: Subnetting in ”Klasse-B-Netzwerken”
derzeitigen IPv4-Adressraum von 232 (weniger etlicher Spezialadressen, siehe dazu bisherige
Ausführungen) gab es eine Reihe von Ansätzen das ”Ende” von IPv4 herauszuzögern. Ein
Ansatz ist das ”classless routing” und das ”subnetting”. Netze können nun im Bereich der
Adressen 1.0.0.0 - 223.255.255.255 beliebig zusammengefasst und geteilt werden. Für die
Routinginformationen wird nun jedoch immer die Subnetzmaske mit zu übermitteln sein,
da sich diese nicht mehr aus der ersten Bitfolge der IP ergibt.
Damit: Ein flexibleres Schema ist notwendig. Klassen dürfen beliebig in Subklassen
aufgeteilt werden, z.B. kann das RZ der Uni-Freiburg einzelnen Bereichen sog. Subnetze
zuweisen. Aus der Aufteilung der höheren Klassen entstehen aus einem Klasse B Netz mit
65.535 Rechnern werden dann 256 Klasse C Netze mit 254 Rechnern pro Netz. Trotzdem
müssen sich Router weltweit weiterhin nur 132.230.0.0 als Netzadresse merken, da Netze
mittels Supernetting zusammengefaßt werden können.
Supernetting kann z.B. zwei Klasse C Netze, wie 192.168.2.0 und 192.168.3.0, zu einem
Netz zusammenfassen und für dieses dann die Maske 255.255.254.0 verwenden. Supernetting kann damit ”Adressverschwendung” verhindern: Ausgabe eines Klasse B Netzes für
eine Organisation mit 500 Rechnern. Dann: IP-Adresse ist nicht mehr wie ursprünglich
selbsterklärend deklariert, denn nun muss die Netzmaske zwingend mit übermittelt werden.
Die Netzmaske liefert aus ihrer Folge von ”1” und ”0” die Aufteilung zwischen Netzwerkteil der IP-Adresse und dem Hostteil. Diese Unterteilung bestimmt, welche Adressen
in einem lokalen Netz vergeben werden können. Diese können in diesem Netz ohne Router
miteinander direkt über ARP kommunizieren. Dabei sollten in der Folge nur ”1” gefolgt
von nur ”0” stehen19 , z.B.:
19
Daraus folgt, dass nur die Zahlen 0, 128, 192, 224, 240, 248, 252, 254, 255 in der Netzmaske vorkommen
können. Andere Muster wären möglich aber eventuell ordentlich verwirrend. Siehe Anmerkungen dazu weiter
5.7. IP-ROUTING
netmask 255.255.255.0
netmask 255.255.252.0
netmask 255.255.0.0
59
11111111.11111111.11111111.00000000
11111111.11111111.11111100.00000000
11111111.11111111.00000000.00000000
Die erste Beispielmaske ist eine Class-C-Maske und die letzte, die eines Class-B-Netzes.
Es spielt nun aber keine Rolle mehr, wie das erste Bitmuster der IP-Adresse aussieht. Geht
man z.B. davon aus, dass ein Class-B-Netz aufgeteilt werden soll, dann geschieht das wie
folgt:
Das gezeigte Muster kann natürlich auch ausgehend von einem Class-A-Netz durchgeführt werden, wobei dann der letzte Tabellenwert mit 256 zu multiplizieren ist. Geht
man von einem Class-C-Netz aus, muss der letzte Wert hingegen durch 256 geteilt werden.
Wendet man dieses Beispiel nun auf ein konkretes Teilnetz an, z.B. auf das Class-BNetz 134.76.0.0, dann ergibt sich das Bild (Tabelle 5.7.5) bei gleichmässiger Aufteilung.
Die Tabellen könnten natürlich noch weiter fortgesetzt werden, aber das Prinzip sollte klar
Teilnetze
1
2
4
8
Netzadresse(n)
134.76.0.0
134.76.0.0
134.76.128.0
134.76.0.0
134.76.64.0
134.76.128.0
134.76.192.0
134.76.0.0
134.76.32.0
134.76.64.0
134.76.96.0
134.76.128.0
134.76.160.0
134.76.192.0
134.76.224.0
Netzmaske
255.255.0.0
255.255.128.0
255.255.128.0
255.255.192.0
255.255.192.0
255.255.192.0
255.255.192.0
255.255.224.0
255.255.224.0
255.255.224.0
255.255.224.0
255.255.224.0
255.255.224.0
255.255.224.0
255.255.224.0
Broadcastadresse(n)
134.76.255.255
134.76.127.255
134.76.255.255
134.76.63.255
134.76.127.255
134.76.191.255
134.76.255.255
134.76.31.255
134.76.63.255
134.76.127.255
134.76.159.255
134.76.191.255
134.76.191.255
134.76.223.255
134.76.255.255
Zahl der IP’s
65.536
32.768
32.768
16.384
16.384
16.384
16.384
8.192
8.192
8.192
8.192
8.192
8.192
8.192
4.096
Tabelle 5.7: Beispiele einer Aufteilung in bis zu acht Teilnetze
geworden sein. Es ist jedoch nicht erforderlich ein Netz in gleiche Teile zu untergliedern,
sondern es können auch unterschiedlich grosse Teilbereiche definiert werden, wobei sich
jedoch jeder Teilbereich in die seinem Bitmuster passenden Blöcke einfügen muss20 . Das
angegebene Beispiel könnte also auch so aussehen, wie in Tabelle ?? gezeigt. Subnetting
und Supernetting haben wesentlich dazu beigetragen, dass IPv4 immer noch reicht. Dadurch wird Routing aufwändiger, da Router nicht mehr anhand der ersten vier Stellen
der Adresse über deren Maske entscheiden können. Router benötigen mehr Speicher für
die Kombination aus Netznamen und Netzmaske. Adressklassen sind nun von eher historischer Bedeutung. Problem: Wie werden ehemals ”reservierte” Adressen, wie Broadcast und
Netznamen behandelt, die nun evtl. reguläre Adressen in zusammengefaßten Netzen sind?
oben
20
Das bedeutet z.B. im Beispiel, dass eine Netzadresse wie 134.76.60.3.0 bei einer Netzmaske von
255.255.248 ungültig ist. Die Startadresse kann 134.76.[0,7,15,23,...].0 sein.
60
KAPITEL 5. TCP-IP
Teilnetze
16
Netzadresse(n)
134.76.0.0
134.76.16.0
134.76.32.0
134.76.48.0
134.76.64.0
134.76.80.0
134.76.96.0
134.76.112.0
134.76.128.0
134.76.144.0
134.76.160.0
134.76.176.0
134.76.192.0
134.76.208.0
134.76.224.0
134.76.240.0
Netzmaske
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
255.255.240.0
Broadcastadresse(n)
134.76.15.255
134.76.31.255
134.76.47.255
134.76.63.255
134.76.79.255
134.76.95.255
134.76.111.255
134.76.127.255
134.76.143.255
134.76.159.255
134.76.175.255
134.76.191.255
134.76.207.255
134.76.223.255
134.76.239.255
134.76.255.255
Zahl der IP’s
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
4.096
...
Tabelle 5.8: Beispiele einer Netzaufteilung mit verschiedenen Subnetzmasken
5.7.6
QoS-Routing
IP selbst und die meisten Netzwerktechnologien kennen kein oder nur sehr beschränktes
Quality of Service (QoS). Paketorientierte Netzwerke sind zuallererst für gleichberechtigten
Zugriff ohne Ressourcen-Monopolisierung ausgelegt. ATM unterstützt zwar QoS, jedoch
keine einfache Verknüpfung mit IP über Schichtgrenzen hinweg. IP ist verbindungslos, mit
dem Verlassen des Paketes der Maschine ist kein Einfluss mehr möglich.
IP-Header enthält ein Optionenfeld für QoS-Flags (dieses wird jedoch nur selten ausgelesen):
• Minimum Delay
• Maximum Throughput
• Maximum Reliability
• Minimize Costs
Kombinationen aus diesen Feldern sind möglich. Verschiedene Dienste können so unterschiedliche Merkmale realisieren (Sprache, FTP, SSH,...).
Probleme: Verletzung des Schichtenmodells, da Applikation den IP-Header mitbestimmen muss; alle Router müssen Felder auswerten; Prioritäten können sich auf dem Weg
ändern (z.B. Einschätzung des Kostenfaktors von Leitungen); Pakete können auf ihrem
Weg umgeschrieben werden. Trotzdem kann QoS-Routing beim Anschluss von LANs an
das Internet über schmale Uplinks (Bsp. WG-oder Firmen-Router an DSL) sinnvoll sein.
Router sind bereits mit ”normalem” Routing stark belastet - zusätzliche Regeln können
die Belastung nur erhöhen. Deshalb: Meistens ist es wieder ”einfacher” die Bandbreite zu
erhöhen, als aufwändiges QoS-Routing einzusetzen. Im LAN-Bereich gibt es Überlegungen
zu QoS bei Ethernet - IPv6 soll einiges mehr an QoS implementieren.
5.8. ADDRESS RESOLUTION PROTOCOL
5.8
61
Address Resolution Protocol
Jede Ethernet-, Funk- TokenRing-Karte besitzt eine eindeutige Hardware-Adresse, die auch
als MAC-Adresse bezeichnet wird. LAN-Karten bedienen sich dieser MAC-Adresse, die für
die Aussendung und den Empfang von Datagrammen über das Netzwerk unerlässlich ist. Sie
können nur auf Datagramme antworten, die im Empfänger-Feld eine Rundsende-Adresse,
eine bekannte Verteilsende-Adresse oder eine auf die betreffende LAN-Karte hinweisende
Individual-Adresse aufweisen.
Die MAC-Adresse steht bereits beim Erwerb des Netzwerkgeräs fest. Sie ist fest einkodiert z.B. in einer Netzwerk-Karte. Sie ändert sich nicht und ist weltweit theoretisch 100 %
eindeutig. Der flache Adressraum umfasst 48 bit und die Adressen werden traditionell hexadezimal dargestellt. Man werfe einfach mal einen Blick auf die Unterseite des eigenen Laptops oder den Aufdruck auf einer Netzwerkkarte und wird dort eine typische Darstellung
der Form: 00:0a:e4:35:34:6a finden. Ethernet verwendet ein ganz eigenes Adressierungsschema, das nach komplett anderen Kriterien funktioniert, als beispielsweise vom Internet
Protokoll gewohnt. Es gibt lediglich eine Aufteilung der Adresse in ein Hersteller-Prefix und
ein eindeutiges Suffix für jede Karte eines Herstellers.
5.8.1
ARP - Hilfsprotokoll des IP
Das Address Resolution Protocol wird als Bindeglied zwischen der eigentlichen NetzwerkHardware einerseits und dem Internet Protokoll (IP) anderseits benötigt. Anders als bei
Punkt-zu-Punkt-Verbindungen, wie beispielsweise ISDN agieren in einem Ethernet viele
Maschinen gleichberechtigt. Damit reicht es nicht, einfach das Paket an einem Ende der
Leitung ”abzuliefern” und nach kurzer Verzögerung am anderen Ende zu erwarten.
IP-Adressen kann man nicht einfach nehmen, da man ja beim Kauf einer Ethernet-Karte
noch gar nicht wissen kann, in welchem Netz eine Maschine betrieben wird. Ebenso wollte
sicherlich keiner einsehen, dass ein Laptop entweder nur zu Hause oder im Firmennetz an
einer bestimmten Stelle angeklemmt werden kann,oder dass man sich einen neuen Netzwerkadapter kaufen muss, wenn sich die IP ändert. Deshalb verwendet man beim Ethernet
einen eigenen Adressraum mit Eigenschaften, die sich zum IP-Adressraum stark unterscheiden.
Die IP-Adresse ist, wie bereits oben erläutert, im OSI-Schichtenmodell der Vermittlungsschicht zugeordnet und von der individuellen MAC-Adresse unabhängig. Jede Kommunikation mittels TCP/ IP wird durch die IP-Adresse eingeleitet, wodurch für den Aufbau des
Dialogs die MAC-Adresse als sekundär zurückgestuft wird. End-zu-End-Kommunikationen
bedienen sich also der IP-Adresse, wohingegen bei den dazwischen liegenden Knotenpunkten (Hops) in den genannten Netzwerktypen die MAC-Adresse genutzt wird.
Jedem Host im Netz wurde aber nun auch noch eine IP-Adresse zugeordnet und damit
hat das darunterliegende broadcastfähige LAN ein Problem: Mit der IP-Adresse 172.16.23.1
weiß es nichts anzufangen, mit der MAC-Adresse 00:08:74:46:DC:9C allerdings schon. Ein
Vermittlungsdienst muss her: Das Adress Resolution Protocol (ARP) übersetzt die IPAdressen in Ethernet-Adressen. So gesehen gehört es eigentlich auch nicht vollständig in
den Link Layer, sondern ist irgendwo zwischen Link und Network Layer einzuordnen. In den
ersten beiden 16 bit Feldern des ARP-Paketes stehen der Hardwaretyp und die benutzten
Protokolladressen. Im Falle von IP auf der Basis von Ethernet steht im ersten Feld eine 1
für Ethernet und im zweiten Feld 0x0800 für das IP-Protokoll, wie es auch im EthernetRahmen markiert wird. Die beiden 8 bit Felder zu Beginn der nächsten Zeile bestimmen die
Anzahl der Bytes für die Hardware- und Protokolladressen, in diesem Fall 6 Byte für die
Ethernetadresse und 4 Byte für die IP-Nummer. Das sich anschließende ”Operation”-Feld
62
KAPITEL 5. TCP-IP
32 bit
HARDWARE ADDRESS TYPE
HADDR LENGHT
PADDR LENGHT
PROTOCOL ADDRESS TYPE
OPERATION
SENDER HARDWARE ADDRESS (first 4 Byte)
SENDER HADDR (last 2 Byte)
SENDER PROTOCOL ADDRESS (first 2 Byte)
SENDER PROTOCOL ADDRESS (last 2 Byte)
TARGET HADDR (first 2 Byte)
TARGET HARDWARE ADDRESS (last 4 Byte)
TARGET PROTOCOL ADDRESS (all 4 Byte)
Abbildung 5.5: Aufbau eines ARP Pakets
bestimmt, ob es sich um eine Anfrage (Wert 1) oder eine Antwort (Wert 2) handelt. ARP
beinhaltet Felder für zwei Adressbindungen, wobei eine dem Sender und die andere dem
Empfänger entspricht, die in den ”Target”-Feldern genannt wird.
In den ersten TCP/IP-fähigen Rechnern wurde eine manuell erstellte Tabelle verwen21
det , die die Zuordnung zwischen MAC- und IP-Adresse indirekt automatisieren sollte.
In den meisten broadcast-fähigen Netzen werden davon losgelöst zusätzlich oder ersetzend
Routing-Informationen komplett automatisch mittels dem Adress Resolution Protocol ausgetauscht, welches in RFC 826 (An Ethernet Address Resolution Protocol) definiert wird.
Jeder Host verwaltet dabei dynamisch den sogenannten ARP-Cache mit den relationalen
IP-/MAC-Einträgen.
5.8.2
Funktionsweise
ARP arbeitet dabei ziemlich geräuschlos im Hintergrund. Man muss nichts extra installieren, da diese Fähigkeit eigentlich in jeden Linuxkernel schon hineinkompiliert ist. Die
Programme zur Konfiguration und Abfrage des ARP-Caches sind auf fast jedem LinuxRechner installiert:
mobile:~ # ip neighbor show
10.8.4.1 dev eth0 lladdr 00:0a:e4:35:33:7a REACHABLE
10.8.4.2 dev eth0 lladdr 00:0c:6f:45:03:0d REACHABLE
10.8.4.254 dev eth0 lladdr 00:09:37:31:3a:13 REACHABLE
In einem gegebenen Subnetz, hier 10.8.4.0/255.255.255.0, werden alle Pakete, die eine Maschine verlassen sollen über das lokale Ethernet ausgetauscht. Dieses trifft auf fast alle
Maschinen mit Internet-Verbindung zu, welche nicht ausschliesslich an einer Modem- oder
ISDN-Verbindung hängen. Maschinen in diesem Subnetz verfügen meist über genau eine
Netzwerkkarte, ausser sie stellen Gateway-Funktionen in andere Netze bereit. Dann bezeichnet man sie üblicherweise als Router. So gibt es zwei Szenarien:
1. Die Maschine A will mit einer Maschine B im selben Subnetz kommunizieren. Die
Pakete können ohne die Beteiligung weiterer Maschinen direkt über das Ethernet
hin- und hergeschickt werden.
21
Diese Fähigkeit ist heute noch vorhanden: Mit dem Kommando arp können der Kernel-ARP-Tabelle
statische Einträge hinzugefügt oder welche gelöscht werden.
5.8. ADDRESS RESOLUTION PROTOCOL
63
2. Die Maschine A will ein Paket an irgendeine Maschine ausserhalb des Subnetzes schicken. Da nur der Router R, der deshalb auch als Default-Gateway bezeichnet wird,
den Weg in die weite Welt kennt, liefert A die Daten an R. R kümmert sich dann
um die Weitersendung und leitet A eventuell zurückommende Antwortpakete oder
Fehlermeldungen zu.
Die Art der Daten, die ausgetauscht werden, spielt auf den unteren Netzwerkschichten
unterhalb von IP keine Rolle. Jedes IP-Paket wird an den Data-Link Layer weitergereicht,
um dort versendet zu werden. Mit der IP-Adresse von B, die als bekannt vorausgesetzt
wird, kommt A hier nicht weiter und muss deshalb die MAC-Adresse von B in Erfahrung
bringen. Der Ablauf einer ARP-Sitzung folgt normalerweise einem strikten Protokoll:
10.8.4.1
A
00:01:AA
10.8.4.2
B
00:01:BB
ARP-Reply:
"10.8.1.2 is at 00:01:BB..."
Abbildung 5.6: Die Station mit der passenden IP-Adresse schickt ein ARP-Reply
1. Zu allererst schaut A in seinem ARP-Cache nach, ob es nicht vielleicht bereits dasgesuchte Adress-Paar bzw. die gesuchte MAC-Adressen kennt. In diesem Cache werden
festgestellte Paarungen aus früheren Sitzungen für eine Weile vorgehalten, um nicht
ständig wieder neu fragen zu müssen. Dieses würde unnötigen Netzwerk-Verkehr produzieren.
2. Falls kein Eintrag vorhanden ist, wird vom Initiator mit Hilfe von ARP die MACAdresse der fraglichen IP-Adresse zu ermitteln versucht. In der Hoffnung diese Frage
wenigstens temporär aus der Welt zu schaffen, sendet A ein ARP-Datagramm inklusive der zu erfragenden IP-Adresse und einer sogenannte ARP-Anforderung an alle
LAN-Karten mittels der bekannten MAC-Broadcast-Adresse (0xFFFF FFFF FFFF).
ARP setzt in dieser verhältnismässig globalen Anforderung seinen eigenen EthernetTyp 0x08086 ein, damit der Schrei von allen vermeindlich betroffenen Knotenpunkten
wahrgenommen wird. Dieses Rundschreiben ”Ich kenne die MAC-Adresse X, die IPAdresse A und ich suche die MAC-Adresse desjenigen, der die IP-Adresse B hat.” wird
von allen aktiven Maschinen im Netzwerk bemerkt. Falls innerhalb eines definierten
Timeouts im Sekundenbereich keine Antwort auf die Broadcast-Anfrage eingeht, so
wird die Anforderung erneut gestellt.
3. Der Rechner B, und nur dieser, wird auf dieses Broadcast-Request antworten: ”Die
IP-Adresse von B ist unter der MAC-Adresse Y zu erreichen”. In der ARP-Antwort
sind dann alle Felder entsprechend gesetzt.
4. Für eine gewisse Zeit notiert sich A dieses Paar in seinem Cache. Da es den anderen Teilnehmern den Aufwand spart, später ebenfalls nach dieser Paarung fragen zu
müssen, merkt sich die befragte Maschinen ebenfalls diese Paarung, solange der Cache
nicht aufgrund potentieller Überfüllung überschrieben wird. Sie tut es auf ”Vorrat”
für den Fall, dass sie später ebenfalls Pakete an B schicken will. Bei einer eventuell nachfolgenden Anforderung ist es daher auch nicht mehr nötig den ARP-Dialog
64
KAPITEL 5. TCP-IP
in umgekehrter Richtung walten zu lassen, da die relevanten Daten beim Zielsystem
bereits bekannt sind.
10.8.4.1
10.8.4.2
B
A
00:01:AA
00:01:BB
Ethernet-Kommunikation
00:01:AA <-> 00:01:BB
IP-Kommunikation
10.8.4.1 <-> 10.8.4.2
Abbildung 5.7: Nach dem Austausch der MACs erfolgt die IP-Kommunikation
ARP-Datagramme werden von Routern nicht weitergeleitet, da sie in der IP-Schicht operieren und auf MAC-Broadcasts grundsätzlich nicht reagieren können und dürfen. Router
stellen daher verwertbare Puffer zwischen einzelnen Rundsende-Subnetzen dar. Mit ihrer
Hilfe kann überflüssiger Traffic im gesamten Netzwerk eingedämmt und auf effektiv betroffene Subnetze minimiert werden.
5.8.3
ARP unter Linux
Unter Linux erfährt man die MAC-Adresse mit:
linux02:~ # ip link show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:81:55:06:01 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:e0:81:55:06:00 brd ff:ff:ff:ff:ff:ff
4: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
Die beiden Ethernet-Interfaces haben eine gültige Adresse, Loopback (lo) und das TunnelInterface (sit0) benötigen keine. Zum Netzwerkgerät zugeordnete IP-Adressen haben das
bekannte Format bestehend aus vier durch drei Punkte getrennte Blöcke von Dezimalzahlen 10.8.4.254. Zwar arbeiten die Rechner intern mit der Binärdarstellung, trotzdem
sind die Unterschiede zwischen MAC- und IP-Adresse groß. ARP arbeitet beim Dolmetschen geräuschlos im Hintergrund. Man muss nichts extra installieren, da diese Fähigkeit
im Linux-Kernel vorhanden ist. Die Programme arp und ip zur Konfiguration und Abfrage
des ARP-Caches sind auf fast jedem Linux-Rechner installiert.
mobile root # arp -n
Address
HWtype
10.8.4.222
ether
10.8.4.204
ether
10.8.4.254
ether
mobile root # arp -d 10.8.4.204
mobile root # arp -n
Address
HWtype
10.8.4.222
ether
10.8.4.204
10.8.4.254
ether
HWaddress
00:03:47:B9:DE:36
00:02:B3:C2:55:91
00:0C:6E:15:03:0E
Flags Mask
C
C
C
Iface
eth0
eth0
eth0
HWaddress
00:03:47:B9:DE:36
(incomplete)
00:0C:6E:15:03:0E
Flags Mask
C
Iface
eth0
eth0
eth0
C
5.8. ADDRESS RESOLUTION PROTOCOL
mobile root # arp -n
Address
HWtype HWaddress
10.8.4.222
ether
00:03:47:B9:DE:36
10.8.4.204
ether
00:02:B3:C2:55:91
10.8.4.254
ether
00:0C:6E:15:03:0E
mobile root # arp -s 10.8.4.204 00:11:22:33:44:55
mobile root # arp -n
Address
HWtype HWaddress
10.8.4.222
ether
00:03:47:B9:DE:36
10.8.4.204
ether
00:11:22:33:44:55
10.8.4.254
ether
00:0C:6E:15:03:0E
mobile root # ping 10.8.4.204
PING 10.8.4.204 (10.8.4.204) 56(84) bytes of data.
65
Flags Mask
C
C
C
Iface
eth0
eth0
eth0
Flags Mask
C
CM
C
Iface
eth0
eth0
eth0
--- 10.8.4.204 ping statistics --1 packets transmitted, 0 received, 100% packet loss, time 0ms
mobile root # arp -s 10.8.4.204 00:02:B3:C2:55:91
mobile root # ping 10.8.4.204
PING 10.8.4.204 (10.8.4.204) 56(84) bytes of data.
64 bytes from 10.8.4.204: icmp_seq=1 ttl=64 time=0.164 ms
--- 10.8.4.204 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.164/0.164/0.164/0.000 ms
ARP verlässt sich auf die MAC-Adresse des Ethernet-Adapters, so wie sie vom Betriebssystem mitgeteilt wird. Wenn man die MAC-Adresse eines Interfaces ändern will, kann man
als Administrator dazu das Kommando ip link set verwenden:
linux:~ # ip link set eth0 down
linux:~ # ip link set eth0 address 00:20:AA:20:AA:20
linux:~ # ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:20:AA:20:AA:20 brd ff:ff:ff:ff:ff:ff
Das Ganze geht auch mit ifconfig:
linux:~ # ifconfig eth1
eth1
Protokoll:Ethernet Hardware Adresse 00:00:0E:7D:71:DF
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
linux:~ # ifconfig eth1 down
linux:~ # ifconfig eth1hw ether 00:4F:0E:7D:71:DF
linux:~ # ifconfig eth1
eth1
Protokoll:Ethernet Hardware Adresse 00:4F:0E:7D:71:DF
inet6 Adresse: fe80::24f:eff:fe7d:71df/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 Sendewarteschlangenlänge:0
RX bytes:0 (0.0 b) TX bytes:70 (70.0 b)
Das bedeutet schlicht und einfach, dass man sich nicht darauf verlassen kann, dass die im
Netz sichtbare MAC-Adresse wirklich die auf dem Netzwerkadapter programmierte ist. Im
66
KAPITEL 5. TCP-IP
WLAN lässt sich die MAC-Adresse scheinbar auch auf diese Weise ändern. Da sie jedoch
von der Firmware der Karte noch in anderen Schichten benutzt wird, kommt nach dieser
Art der Änderung keine Funkverbindung mehr zustande. Es gibt jedoch Programme, mit
denen sich per Firmware die MAC-Adresse von WLAN-Karten ändern lässt.
5.8.4
Eingebaute Sicherheitslücken
Normalerweise sind keine Kontrollmechanismen vorhanden, die eine MAC-Adresse im Namen mehrerer IP-Adressen kompetent verifizieren kann. Angreifer können sich diese Eigenheit von ARP zunutze machen.
Die Schwäche von ARP liegt in seiner Vertrauensseligkeit. ARP stammt aus den frühen
Zeiten der IP-Kommunikation, wo ein ”es geht” und möglichst schonender Umgang mit
Netzwerkresourcen wichtiger waren, als eine sauber implementierte und unter umständen
sehr aufwändige Authentifikation. Wenn ein Endsystem ein ARP-Reply aufschnappt, dann
wird dieser im Cache abgelegtt, unabhängig davon, ob zuvor nach dieser Adresse gefragt
wurde. Hierin verbirgt sich die grundlegende Sicherheitslücke. Aber auch ein scheinbar folgerichtiger Ansatz, eine Adresse nur dann zu speichern, wenn vorher genau nach dieser
Adresse gefragt wurde, lässt sich leicht austricksen, indem ein potenzieller Angreifer einfach schneller antwortet, als der Inhaber der Adresse. So kann der Angreifer natürlich eine
beliebige Antwort geben, wie beispielsweise seine eigene Adresse. Ausgangssituation für das
00:b0:11:11:11:11
00:b0:11:22:22:22
10.8.4.2
10.8.4.1
B
A
ARP-Reply:
"10.8.1.1 is at 00:b0:11:33..."
10.8.4.50
ARP-Reply:
"10.8.1.1 is at 00:b0:11:33..."
P
00:b0:11:33:33:33
Abbildung 5.8:
im folgenden beschriebene ARP-Spoofing sei die folgende: Die beiden Hosts A und B kommunizieren miteinander. A benutzt die IP-Adresse 10.8.4.1 und die MAC 00:b0:11:11:11:11,
B 10.8.4.2 und MAC 00:b0:11:22:22:22. Der angreifende Host P hat die IP 10.8.4.3 und
dazugehörige MAC 00:b0:11:33:33:33. Er möchte ablauschen, was A und B miteinander zu
schnacken haben.
Host P startet seinen Angriff, indem er die ARP-Caches der Opfer A und B ”vergiftet”22 ,
d.h. er injiziert gefälschte ARP-Antworten in das lokale Subnetz. P schickt an A ein ARPReply, dass die Information enthält, dass der Rechner B mit der IP-Adresse 2 unter der
MAC-Adresse 00:b0:11:33:33:33 zu erreichen ist. In Wirklichkeit bekomm nun aber P die
Pakete von A für B zugeschickt. Ebenso erhält B gefälschte Pakete von P, dass beinhalten,
dass A mit der IP-Adresse 1 unter der MAC-Adresse 00:b0:11:33:33:33 angesprochen wird.
In Zukunft schickt also A seinen Verkehr für B statt direkt zu B in Wirklichkeit zu P. Bei
B gestaltet es sich genauso, er schickt seinen Verkehr für A zu P. Der Angreifer P muss nun
einfach die Pakete korrekt weiterreichen, indem im Kernel IP-Forwarding eingeschltet wird.
Die korrekten IP-Adressen stehen ja in den Paket-Headern, P kennt auch die korrekten
MAC-Adressen. Wenn P noch ein wenig cleverer ist, dann passt er noch den HOP-Count
im IP-Header an, bevor das Paket sein Interface verlässt.
Da jeder Router im IP-Header den Hop-Counter um eins reduziert, muss dieser wieder
erhöht werden. Andernfalls würde auffallen, dass der Weg von A nach B plötzlich um
22
hiervon stammt der Ausdruck ”Poisioning”
5.8. ADDRESS RESOLUTION PROTOCOL
00:b0:11:11:11:11
10.8.4.1
67
00:b0:11:22:22:22
IP-Kommunikation
10.8.4.1 <-> 10.8.4.2
A
10.8.4.50
Ethernet-Kommunikation
00:b0:11:11... <->
00:b0:11:33...
P
10.8.4.2
B
Ethernet-Kommunikation
00:b0:11:33:33:33 <->
00:b0:11:22:22:22
00:b0:11:33:33:33
Abbildung 5.9:
mindestens einen Router länger geworden ist. Im Zuge der Weiterleitung der Pakete können
diese bequem mitgelesen werden. Dabei kann der Angreifer möglicherweise Passwörter und
andere geheime Daten auslesen. Zudem können Pakete auch problemlos manipuliert werden,
was die Attacke noch mächtiger macht. Da der Angreifer sozusagen direkt auf dem logischen
Verbindungspfad zwischen den Opfern sitzt, wird diese Art eines Angriffs auch als ”ManIn-The-Middle” bezeichnet.
00:b0:11:11:11:11
00:b0:11:22:22:22
10.8.4.2
10.8.4.1
IP-Kommunikation
10.8.4.1 <-> 10.8.4.2
A
B
Paketlaufzeit2
Paketlaufzeit1
10.8.4.50
Hop-Count: TTL-1
P
00:b0:11:33:33:33
Abbildung 5.10:
Wenn der Angriff wieder beendet wird, muss der ARP-Cache der Opfer wieder aufgeräumt werden, d.h. es müssen erneut gefälschte ARP-Replies an A und B geschickt werden, zur Abwechslung nun mit den korrekten Paarungen von MAC- und IP-Adressen. Passiert dies nicht und P entfernt sich aus dem Netz oder deaktiviert sein IP-Forwarding, dann
schicken A und B weiterhin ihren Verkehr an P. Dieser leitet ihn aber nicht mehr weiter:
Die ganze Sache fällt wegen der Netzwerkunterbrechung unter Umständen auf.
Insgesamt kann man festhalten, dass man nur an der ARP-Reply allein keine Auffälligkeit feststellen kann. Die Sender MAC Address stimmt überein mit der Absender-Adresse
des umgebenden Ethernet-Frames, so dass es sich bei diesem Paket auch durchaus um ein
echtes ARP-Reply handeln könnte. Tatsächlich ist dieses Paket aber gefälscht und Teil einer
ARP-Poison-Attacke. Beim Beenden der Attacke verrät sich der Angreifer. Denn er schickt
von seiner MAC-Adresse aus eine ARP-Reply, die angibt, dass seine IP-Adresse jetzt unter einer anderen MAC-Adresse zu erreichen ist. D.h. die Sender MAC Address stimmt in
diesem Fall nicht überein mit der Absender-Adresse des umschließenden Ethernet-Frames.
Hier kann man den Angreifer entdecken und seine MAC-Adresse ablesen.
Das ”Standardwerkzeug” für ein ARP-Angriff ist das Programm ettercap. Das kann
inzwischen eine ganze Reihe von ”Man-in-the-Middle” Angriffe durchführen. Hier interessieren jedoch nur die ARP-Angriffe. Ettercap ist ein Projekt, welches auf Sourceforge gehostet ist. Ettercap kennt drei verschiedene Benutzerinterfaces, eine Kommandozeilenversion,
die mit ”-T” aktiviert wird, eine ncurses-basierte Textoberfläche (”-C”) und eine grafische
GTK-Version. Möchte man nun den Verkehr zwischen den beiden Maschinen 10.8.4.204
und 10.8.4.204 mitschneiden, dann erreicht man das über den Aufruf: ettercap -C -M arp
68
KAPITEL 5. TCP-IP
Abbildung 5.11: Ettercap in der Ncurses-Ausführung
/10.8.4.222/ /10.8.4.204/.
Mit
ettercap -T -M arp:remote /192.168.1.1/
/192.168.1.2-10/ kann man das ARP Poisoning für das Gateway und die Rechner im
Ethernet zwischen 2 und 10 laufen lassen. Die Remote-Option wird benötigt, damit man
den Traffic mitbekommt, der über das Gateway geroutet wird.
Ettercap dient nicht nur als Cracker-Werkzeug, es kann ebenso Administratoren eingesetzt werden, um Schwachstellen im eigenen Netz aufzuspüren. Die Illusion, dass sich
Programme wie ettercap oder dsniff fernhalten lassen, kann man getrost vergessen, wo
sie schon im Standardumfang vieler Von-CD-Distributionen enthalten sind.
5.8.5
Gefahrenabwehr
Wie man sieht, bemerkt man einen solchen ARP-Angriff, wenn er geschickt ausgeführt
wird, also wenn der HOP-Count manipuliert wird, kaum bzw. höchstens, wenn er beendet
wird. Es gibt Möglichkeiten, ARP-Angriffe zu entdecken, aber es gibt kein wirksames Mittel
gegen einen solchen Angriff außer einer Verschlüsselung.
Das ändert natürlich auch nichts an der Tatsache, dass P immer noch die IP-Pakete
abfangen und mitlesen kann, die zwischen A und B hin- und hergeschickt werden, aber
wenn sie gut verschlüsselt sind, kann P nicht mehr viel damit anfangen. Für den Fall, dass
P den Inhalt manipulieren will, insofern das überhaupt Sinn macht, wenn er den Inhalt nicht
lesen kann, wird das auch auffallen. Verschlüsselung ist die einzige wirksame Möglichkeit.
In kleinen Netzwerken, mit seltenen Änderungen der angeschlossenen Maschine ist es sogar
mit vertretbaren Aufwand möglich, ARP-Angriffe komplett auszuschliessen, indem man
ARP gar nicht erst verwendet.
Die einfachste Variante ist die manuelle und statische Zuweisung von IP-Adressen zu
MAC-Adressen. Der Admin trägt in einer Tabelle die Paarungen ein und vergibt entsprechend dieser Tabelle freie IP-Adressen. Diese Informationen stehen allen Endsystemen zum
Routing zur Verfügung und sie können, außer durch den Admin, durch niemanden geändert
5.8. ADDRESS RESOLUTION PROTOCOL
69
werden. Die Verwendung von ARP wird schlichtweg überflüssig und damit fällt auch die
Sicherheitslücke komplett weg.
Der große Nachteil dieser Methode ist allerdings, dass sie nur sehr schlecht skalierbar
ist, d.h. sobald das Netzwerk eine gewisse Größe erreicht hat, ist es einfach nicht mehr
praktikabel. Dann gibt es häufige Änderungen, die zum einen kommuniziert werden müssen,
aber zum anderen vor allem überhaupt erstmal vorgenommen werden müssen. Angenommen
der Admin ist gerade nicht da, dann kann man z.B. keine Netzwerk-Karte auswechseln, weil
man für die neue Karte keine IP-Adresse hat. Deshalb wurde ARP ja erfunden.
In großen Netzwerken fällt diese Ausweichmöglichkeit also weg, weil es zu umständlich
und schlecht wartbar ist. Verwendet man dann doch wieder ARP, kann man aber wenigstens
die Paarungen von MAC- und IP-Adressen im Auge behalten. Zum einen fällt es natürlich
auf, wenn ständig ARP-Replies geschickt werden, zumal es für diese Replies nie ein Request
gab. Die gefälschten Replies müssen ja auch ständig neu geschickt werden, denn der ARPCache wird nicht ewig vorgehalten, irgendwann fällt der Eintrag von alleine wieder heraus.
Eine zur statische Festlegung der der ARP-Tabelle mindestens gleichwertige Alternative
stellt der Einsatz von arpwatch von Craig Leres dar, welches nach Veränderungen der IP/Ethernet-Mappings Ausschau hält. Werden Änderungen bemerkt, findet eine Alarmierung
per E-Mail statt. Zudem werden die Manipulationen für eine spätere Analyse protokolliert.
5.8.6
ARP und doppelte IP-Adressen
Wird einem Client-Rechner aus Versehen die gleiche IP-Adresse wie dem zur Verbindung
aufgeforderten Host-System zugeteilt, können diverse Benutzer für kurze Zeit nicht auf die
Dienste des Hosts zugreifen. Die verschiedenen Komponente und Eigenheiten des spezifischen Netzwerks lassen dieses Problem polymorph erscheinen, denn die Architektur des
Netzes, der Einsatz von Routern, Hubs oder Bridges und die verwendete Hard- und Software haben einen entscheidenden Einfluss auf die Reaktionszeiten von ARP und dadurch
auf das ganze Szenario.
In deiner zur letzten Darstellung ähnlichen Situation haben der Host B und der Rechner
P die gleiche IP-Adresse. Versucht nun Host A eine Verbindung zu P herzustellen, welche
eine ARP-Anforderung zur Folge hat, erhält er durch das Adress Resolution Protokoll die
IP-Adresse von Host B, da sowohl der Host als auch Host B antworten. Host A kann die
Verbindung kaum erfolgreich herstellen, da Host B kaum in der Lage ist, mit der korrekten
Dienst-Software aufzutrumpfen. Beim zweiten Versuch erhält Host A vielleicht die korrekte
Antwort des Hosts, kann jedoch noch immer keine Verbindung herstellen.
Handelt es sich beim Host B um einen normalen Arbeitsplatzrechner, wird dieser sehr
wahrscheinlich bei längerem Nichtgebrauch ausgeschaltet. In diesem Fall taucht das Problem nur gelegentlich, zum Beispiel während den Arbeitszeiten des Benutzers am Host B,
auf. Dies kann für genervte Benutzer zwischenzeitlich zum Vorteil werden, behindert jedoch
die Fehlersuche des Netzwerkadministrators erheblich.
Das letzte Szenario beschreibt sich einfacherweise wie folgt: Zwei Host-Rechner bedienen
sich einer identischen IP-Adresse. In diesem Fall werden die Client-Maschinen gelegentlich
eine Verbindung zum falschen Host herstellen, was ein korrekter Ablauf der Kommunikation
unterbindet. Dieser Machtkampf ist selten anzutreffen, da es zu den Hauptaufgaben eines
kompetenten Administrators zählt, bei jeder Phase des Netzwerkdesigns auf individuelle
IP-Adressen zu achten. Hierbei hilft beispielsweise die Verwendung von DHCP.
70
5.8.7
KAPITEL 5. TCP-IP
Proxy-ARP
Mit Proxy ARP wird eine von IP-Routern genutzte Technik betitelt, die mit der Entwicklung von TCP/IP spezifiziert wurde. Der Sinn der Methode liegt in der Beseitigung einiger
Probleme des begrenzten IP-Adressraums von IPv4. Durch dieses Verfahren können Router
unsichtbar gemacht werden und Teilnetze bequem auf andere Interfaces geroutet werden.
Der Linuxkernel unterstützt Proxy-ARP, womit sich recht komplexe Router aufbauen lassen.
Nicht nur aufgrund des Wachstums eines Netzwerkes kann relativ schnell und verhältnismässig unerwartet der Punkt der physikalischen Beschränkung einer Einführung zusätzlicher Host in das System erreicht werden. In diesem Falle kann das Netz nur durch ein
zweites unabhängiges physikalisches Kabelsystem erweitert werden. In den Kinderjahren
von TCP/IP, vor dem Erfinden von Netzmasken und Brücken, konnten zwei Kabelsysteme
nur mit einem für zwei verschiedene IP-Ranges konfigurierten Router verbunden werden.
Repeater waren aufgrund des Fehlens der Notwendigkeit von Filterungsfunktionen für diese
Arbeit nicht geeignet. IP-Adressen wurden damals rigoros und verschwenderisch vergeben
- man konnte es sich ja damals auch noch leisten.
Wenden wir uns einem illustren Beispiel zu: Ein Unternehmen ergatterte sich die registrierte IP-Adresse der Klasse B 130.1.2.3. Die Firma benutzt die Ethernet-Technologie
und möchte 2’048 Host-Rechner mit der Hilfe von TCP/IP untereinander agieren lassen.
Mit der Adresse der Klasse B stehen dem Unternehmen 65’534 mögliche Hostadressen zur
freien Verfügung. Da man jedoch Ethernet einsetzt, können maximal 1’024 Host in einem
Segment eingebunden werden. Die Implementierung weiterer Systeme erfordert das Nutzen
eines Routers oder einer Bridge. Um nun trotzdem die erste angestrebte Anzahl Host zu
erreichen, muss ein zweites autonomes Kabelsystem angelegt werden, welches aufgrund des
regen Datenverkehrs mittels Router an das erste angeschlossen wird. Konventionelle Router erfordern, dass den jeweiligen Schnittstellen differente IP-Adressen zugeteilt werden.
Obwohl von den 65’534 Adressen der Klasse B nur 1’024 gebraucht wurden, können die
restlichen 64’510 Adressen nicht verwendet werden; also offenbahrt sich eine Vergeudung
in höchstem Maße. Damit der Router einwandfrei arbeiten kann, muss ihm eine zweite IPAdresse der Klasse B zugeteilt werden, und damit sind erneut ganze 65’510 IP-Adressen
verschwendet. Dieses Vorgehen ist aus technischer Sicht in keinster Weise akzeptabel; abgesehen von privaten autonomen Netzwerksystemen ohne registrierte IP-Adressen.
Das Internet Protokoll bedient sich ARP, um die MAC-Adresse einer Einheit zu ermitteln, sofern die Netznummer in der eigenen IP-Adresse der des Empfängerknotens entspricht. Andernfalls kommt ein routendes Element (Router oder Gateway) zum Einsatz.
Damit möglichst wenige IP-Adressen verschleudert werden, ist es aus technischer Sicht
wünschenswert den beiden Interfaces des routenden Systems die gleiche Netznummer zuzuteilen. Wird jedoch dieselbe Netznummer verwendet, muss man ein Verfahren finden,
mit dem man die Richtung der Weiterleitung von Datagrammen eindeutig erkennen kann.
Proxy ARP ist in diesem Fall einer der Schlüssel.
Proxy ARP kann auf verschiedenste Weisen implementiert werden. Als die effizienteste Methode ist die Zuordnung von Bits in der IP-Adresse, anhand derer unterschiedliche
Subnetze identifiziert werden können, anzusehen. Das Relais kann als eine Art Puffer die
unnötigen ARP-Rundsende-nachrichten abblocken, da nur die an andere Subnetze adressierten Broadcasts weitergeroutet werden müssen. Damit kann der überschüssige Netzwerkverkehr eingedämmt und die Performance gewahrt werden. Die einzigen Hops, die die elementaren Bits zur Kennzeichnung der verschiedenen Subnetze erkennen können müssen,
sind die Proxy ARP-Geräte. Natürlich erfordert das erreichen dieses Ziels eine durchdachte
Zuweisung des richtigen Adressbereichs von seiten des Netzwerkadministrators. Beispiels-
5.8. ADDRESS RESOLUTION PROTOCOL
71
weise könnten die ersten vier Bits des Host-Anteils der IP-Adresse zur Identifizierung der
verschiedenen Subnetze eingesetzt werden. Dabei wird jedoch nicht, wie von vielen vielleicht vermutet, mit Subnetz-Masken gearbeitet oder die Adressenstruktur des Endknotens
bekannt. Es können nun also 14 Subnetze dadurch definiert werden (Die Subnetze 0 und 15
finden in diesem Beispiel aus Gründen der Einfachheit keine Verwendung!). Empfängt nun
die Schnittstelle 1 eine ARP-Anforderung, überprüft die Proxy ARP-Vermittlungseinheit
die Bits in der Hostadresse darauf, ob die Nachricht ein anderes Subnetz kennzeichnet.
Wird der Gutfall erkannt, findet eine Weiterleitung an die Schnittstelle 2 statt. Dort wird
dann die Absenderadresse durch jene der Proxy ARP-Schnittstelle 2 ersetzt und als üblicher
ARP-Broadcast ins Neuland geblasen. Die jüngst von der ganzen Aktion betroffene Proxy
ARP-Einheit speichert die in der ARP-Antwort vermerkte MAC-Adresse des Absenders, sowie des Empfängerknotens und vermerkt an welcher Schnittstelle sich diese befinden.
Wird vom Absender nun nocheinmal ein Datagramm an die Schnittstelle 1 des Routers gesandt, enthält dieser bereits die Empfängeradresse der Proxy ARP-Einheit. Das Datagramm
wird daher direkt von der Proxy ARP-Einheit angenommen. Die Proxy ARP-Einheit ersetzt nun wiederum die tatsächliche MAC-Adresse des Empfängerknotens und sendet das
modifizierte Datagramm an die Schnittstelle 2. Diese Methode funktioniert nur, wenn die
beiden Endknoten die Gültigkeit der MAC-Adressen in den jeweiligen ARP-Antworten
nicht überprüfen. Es ist durch dieses ganze Prozedere möglich, mit einer beliebigen MACAdresse zu antworten, die als Ersatz eines anderen Hosts fungiert. Der ARP-Cache eines
Endknotens, der sich in einem Proxy ARP-System befindet, enthält die MAC-Adresse der
Proxy ARP-Einheit, die vielen IP-Adressen zugeordnet ist. Diverse Firewall-Systeme erlauben das Verwerfen von durch Proxy ARP modifizierten Datagrammen, um so entfernte
Manipulationen am ARP-Cache zu unterbinden.
5.8.8
Probleme durch Proxy-ARP
Viele Router verwenden per Default-Einstellung Proxy ARP, auch wenn keine SubnetzAdressierungs-schema zum Einsatz kommen. Das Router-Element greift insofern beim Empfang einer ARP-Anfor-derung für ein anderes Netz oder Subnetz manipulativ in das Geschehen ein, indem es seine eigene MAC-Adresse in der ARP-Antwort zurückschickt. Zur
Übermittlung des Datagramms an den Empfänger werden die herkömmlichen RoutenwahlMechanismen eingsetzt. Dieser Fall kann jedoch nur eintreten, wenn ein verwirrter oder
falsch konfigurierter Rechner das Gefühl des Sich-in-einem-anderen-Netz-Befinden hat und
der Router sich an ein anderes Bild der Adressenstruktur klammert. Es läge also ein klassischer Adressierungs-Fehler vor, da zwei Geräteeinheiten die IP-Adresserungsschematas
komplett anders interpretieren. Grund dafür kann die Wahl unterschiedlicher SubnetzMasken sein. Die beiden Geräte würden so mit einer Netzstruktur arbeiten, die für die
Opposition nicht erkennbar und verständlich ist.
Denial of Service durch ARP-Stürme Der Denial of Service-Angriff mittels ARPSturm hat die Überlastung einer Netzwerkkomponente oder eines Netz(abschnitt)es zur
Folge, was unter Umständen einen weiteren weniger destruktiven Angriff erst ermöglicht
(z.B. IP-Spoofing). Die Extremsituation tritt ein, wenn ARP-Broadcasts eine non-existente
IP-Adresse in Erfahrung bringen versuchen. Alle an das Netzwerk angeschlossenen Gateways beginnen alsdann mit dem Weiterleiten der Anfrage an die Nachbarnetze. Ganz extrem
wird dieser Angriff, wenn nach dem ersten Briadcast-Sturm synthetische ARP-Rückantworten der nicht existierenden Adresse versendet werden, die wiederum von den Gateways per
Broadcast zur finalen Verstopfung des Netzes weiterverbreitet werden. Solche Broadcast-
72
KAPITEL 5. TCP-IP
Stürme belegen rasch einen Grossteil der Netzwerkkapazität und lassen die Performance in
den Keller sinken. Wichtig ist in sensiblen Umgebungen im Vorfeld das sogenannte MediaSpeed-Verhalten durch experimentell simulierte Extremsituationen in Erfahrung zu bringen.
HAVOC für UNIX/Linux ist ein beliebtes Tool zum Erzwingen von ARP-Stürmen.
Denial of Service durch ARP-Fehlimplenetierungen Auch auf Fehlimplementierungen der ARP-Funktionalität können Denial of Service-Attacken abzielen, wie im NetBSD
Security Advisory 1999-010 (ARP table vulnerability) berichtet wird: obsd fun.c schickt
übergrosse ARP-Pakete an eine OpenBSD 2.6-Maschine, und zwing sie so zur Kernel-Panik.
Aber nicht nur UNIX-Derivate sind von solchen Schlampereien betroffen. Auch Microsot
Windows, welches eine Menge Code von BSD direkt übernommen haben muss, kann mit
den C-Scripts winarp.c und poink.c auf die Pelle gerückt werden. Diese Angriffs-Form wird
im Thread von Joel Jacobson in Bugtraq erstmals vorgestellt. Ähnliche Diskussionen finden
sich in den beiden Threads von Andrew Lancashire und Lisa Napier über DoS-Attacken
auf Cisco-Systeme, und von Scott Blake über Cabletron-Router, durch das Überfluten der
ARP-Tabelle.
5.9
ICMP - Internet Control Message Protocol
Das ICMP dient zur Übermittlung von Fehler- und Statusinformationen. ICMP wird auch
von IP selbst verwendet, um beispielsweise Fehler zu melden. ICMP ist daher zwingend in
IP vorhanden; funktional gesehen ist es Teil von IP, technisch setzt es jedoch auf IP auf.
ICMP kann aber auch direkt von Applikationen verwendet werden.
ICMP Pakete werden verwendet, wenn beispielsweise der Zielrechner oder das Zielnetzwerk nicht erreichbar ist. In diesem Fall gibt ein TCP/IP Router beispielsweise ein ”host
unreachable” bzw. ”network unreachable” Paket zurück. ICMP ist im Network Layer angesiedelt, ist aber eigentlich kein wirklich eigenständiges Protokoll, da die Übermittlung
von ICMP-Nachrichten durch IP-Pakete erfolgt und dazu dient, die Übertragung von den
eigentlichen Daten zu steuert. ICMP ist damit kein Datenfluss sondern ein Kontrollfluss,
der den Datenfluss steuert.
Durch seine Vielseitigkeit bietet ICMP aber auch leider die Möglichkeit versteckte Nachrichten zu übermitteln. Ein Stichwort ist hier das sogenannte ”ICMP-Tunneling”. Beim
ICMP-Tunneling wird das Datenfeld eines ICMP-Paketes genutzt, um Informationen zwischen Rechnern auszutauschen. ICMP-Tunneling ist aber keine Technik, die es eventuellen
Datenspionen ermöglicht, in einen Rechner oder ein Netz einzubrechen. Dennoch stellt das
Tunneling eine Bedrohung für das Sicherheitskonzept eines Netzes dar.
Eine recht bekannte Anwendung von ICMP ist das Programm ping, mit dem man die
Erreichbarkeit eines anderen Rechners prüfen kann. Dazu wird ein ICMP echo request an
den Zielrechner geschickt, dieser sendet ein ICMP echo reply zurück, wenn er denn verfügbar
ist. Ping ist ein einfaches Shell-Kommando und wird mittels ”ping Zieladresse” aufgerufen.
dirk@linux:~/nwak> ping 134.76.60.86
PING 134.76.60.86 (134.76.60.86) from 132.230.9.124 : 56(84) bytes of data.
64 bytes from 134.76.60.86: icmp_seq=1 ttl=47 time=21.1 ms
64 bytes from 134.76.60.86: icmp_seq=2 ttl=47 time=23.2 ms
64 bytes from 134.76.60.86: icmp_seq=4 ttl=47 time=20.9 ms
--- 134.76.60.86 ping statistics --4 packets transmitted, 3 received, 25% loss, time 3019ms
rtt min/avg/max/mdev = 20.952/21.774/23.243/1.041 ms
5.10. DOMAIN-NAME-SERVICE (DNS)
73
ICMP wird meistens von IP für den Benutzer unsichtbar verwendet, zum Beispiel um
herauszubekommen, wie groß ein Paket sein kann, das von Link Protokoll übertragen werden
kann, oder um Fehler zu melden.
ICMP hat sehr unterschiedliche Informationen zu transportieren. Deshalb ist nur der
Grundaufbau des ICMP-Headers immer gleich, die Bedeutung der einzelnen Felder im Protokollkopf wechselt jedoch. Jeder ICMP-Nachrichtentyp wird in einem IP-Datengramm eingekapselt.
Die derzeit wichtigsten ICMP-Nachrichtentypen sind:
• Destination Unreachable (Ziel nicht erreichbar) - Diese Nachricht wird verwendet,
wenn ein Netzwerk, Host, Protokoll oder Port nicht erreichbar ist, ein Paket nicht
fragmentiert werden kann, weil das DontFragment-Bit gesetzt ist oder die Source
Route Option nicht erfolgreich verwendet werden konnte.
• Parameter Problem - Verständigt den Absender eines Datengramms darüber, dass das
Paket aufgrund einer fehlerhaften Angabe im IP-Header verworfen werden mußte.
• Redirect - Wird ausgesendet, wenn ein Router feststellt, dass ein Paket falsch weitergeleitet wurde. Der sendende Host wird damit aufgefordert, die angegebene Route zu
ändern.
• Time Exceeded (Zeit verstrichen) - Diese Nachricht wird an den Absender eines Datengramms gesendet, dessen Lebensdauer den Wert 0 erreicht hat. Diese Nachricht
ist ein Zeichen dafür, dass Pakete in einem Zyklus wandern, dass Netz überlastet ist
oder die Lebensdauer für das Paket zu gering eingestellt wurde.
• Echo Request und Reply - Mit diesen Nachrichten kann festgestellt werden, ob ein
bestimmtes Ziel erreichbar ist. Ein Echo Request wird an einen Host gesendet und
hat einen Echo Reply zur Folge (falls der Host erreicht wird). Das Ping-Kommando
nutzt diese Eigenschaft des ICMP.
• Timestamp Request und Reply - Diese beiden Nachrichten sind ähnlich den zuvor beschriebenen Nachrichten, außer dass die Ankunftszeit der Nachricht und die Sendezeit
der Antwort mit erfaßt werden. Mit diesen Nachrichtentypen kann die Netzleistung
gemessen werden.
Eine ICMP-Nachricht wird immer als Antwort auf ein Datengramm verschickt. Entweder ist ein Datengramm auf ein Problem gestoßen, oder das Datengramm enthält eine
ICMP-Anfrage, auf die eine Antwort versendet werden muss. In beiden Fällen sendet ein
Host oder Router eine ICMP-Nachricht an die Quelle des Datengramms zurück.
5.10
Domain-Name-Service (DNS)
Der Domain-Name-Service ist ein auf TCP/IP basierender Dienst und kein Bestandteil
der Vermit-tlungs- bzw. Transportschicht. Jedoch werden vielfach Maschinen nicht primär
über ihre Netzwerkadresse, sondern ihren Hostnamen und evtl. Domainnamen, die zusammen den Full Qualified Domain Name ergeben, angesprochen. Deshalb wird dieser Dienst
an dieser Stelle bereits kurz vorgestellt. In der Benutzung hat man meistens clientseitig mit
DNS zu tun, die Serverseite wird in einem eigenen Abschnitt gesondert vorgestellt. Fast jede Maschine im Internet besitzt neben der numerischen Adresse (IP-Nummer) mind. einen
sybolischen Namen (Hostname). ”Nameserver” kennen die zu den symbolischen Namen
gehörenden IP-Adressen und umgekehrt. Wenn man Nameserver direkt abfragen will, kann
74
KAPITEL 5. TCP-IP
Kürzel
gov
de
net
Bedeutung
governemental
Deutschland
Netzwerk
Kürzel
com
edu
org
Bedeutung
Unternehmen (”commercial”)
Ausbildungseinrichtung
Organisation
Tabelle 5.9: Die traditionellen Domänenendungen
Kürzel
name
eu
ws
Bedeutung
Privatpersonen
Europa
”WebSite”
Kürzel
biz
info
int
Bedeutung
Unternehmungen
Informational
Internationale Organisationen
Tabelle 5.10: Die von der IANA beschlossenen/vorgesehenen neuen Domänenendungen
man das mit den Kommandos host oder nslookup machen. Mittels DNS (Domain-NameService) werden die Hostnamen in einen hierarchischen Namensraum eingegliedert, wobei
geografische Gesichtspunkte (Länderdomains, wie ”de”) oder organisatorische Gründe (Firmen) Ausrichtungskriterien abgeben können.
Die Organisation von Namen in einer Hierarchie von Domains schafft gleichzeitig die
Schwierigkeit der Eindeutigkeit von Namen aus der Welt. Bei DNS muß ein Hostname nur
innerhalb einer (Sub-)Domain eindeutig sein, und schon ist sichergestellt, dass er sich von
allen anderen Hosts weltweit unterscheidet (Sonst wäre der beliebte Aliasname ”www” nicht
möglich!). Mehr noch, voll qualifizierte Namen sind einfacher zu merken.
Der FQDN (Full Qualified Domain Name), die Kombination aus Hostnamen und der
Domain (incl. evtl. Subdmomainnamen) wird durch Punkte in Bestandteile gegliedert, die
über den Namen und die Zugehörigkeit des Rechners Auskunft geben.
Das erste Wort des FQDN ist der sogenannte ”hostname”, der hintere Teil des FQDN
ist der ”domainname”. Während der ”domainname” vorgegeben ist, hat man bei der Taufe
des Rechners freie Wahl. Neben Namen, die in Zusammenhang mit der domain stehen (s.o.)
sind außerdem Comic-Helden, Romanfiguren, berühmte Personen, antike Götter usw. sehr
beliebt. Dem Rechner kann man auch weitere Namen verpassen, sogenannte Aliase, die
meistens die Funktion der Maschine ausdrücken, z.B. www.goe.net, ftp.gwdg.de ...
Zu befragende Nameserver unter Linux werden in der Datei /etc/resolv.conf fest vermerkt oder dynamisch per Bootp/DHCP oder durch die Modem- bzw. ISDN-Skripten nach
dem Bezug per PPP eingetragen. Diese Datei hat folgendes Format:
search kolosseum.local goe.net gwdg.de
nameserver 10.10.156.1
nameserver 134.76.60.21
Die ”search” Order definiert, welche Domainnamen an Hostnamen angehangen wurden, die ohne Domainkürzel angesprochen wurden: ”ping test” würde versuchen zuerst
”test.kolosseum.local”, dann ”test.goe.net” und zum Schluss ”test.gwdg.de” zu ergänzen
und aufzulösen. So kann man sich beim Bewegen in der eigenen Domain viel Tipparbeit
sparen. Es können maximal zehn Ergänzungen der Suchreihenfolge und maximal drei Nameserver angegeben werden. Der zweite und dritte DNS werden nur befragt, wenn der erste
nicht reagierte, nicht jedoch, wenn die Anfrage auf dem ersten keinen Erfolg brachte.
5.11. TRANSMISSION CONTROL PROTOCOL (TCP)
5.11
75
Transmission Control Protocol (TCP)
Mit der Übertragung von Datagrammen (IP-Paketen) von einem Netzwerkknoten zum anderen ist es nicht getan. Wenn man sich remote einloggen möchte, z.B. mit dem Kommando
ssh oder Daten von einem Webserver bezieht, ist hierfür eine zuverlässige Verbindung die
Voraussetzung. Der Datenstrom wird zum Transport in Pakete aufgeteilt, da grosse Dateien
32bit
SOURCE PORT
DESTINATION PORT
SEQUENCE NUMBER
ACKNOWLEDGEMENT NUMBER
TCP-H
Length
U A
R C
G K
unused
P R
S S
H T
S
Y
N
F
I
N
CHECKSUM
WINDOW SIZE
URGENT POINTER
OPTIONS (0 or more 32bit words)
BEGINNING OF DATA
(optional)
Transmission Control Protocol (TCP)
Abbildung 5.12: TCP Paket-Header
nicht ”in einem Stück” transferiert werden können und interaktive Verbindungen zeitnah
laufen sollen, d.h. nicht ewig gewartet werden kann, bis ein grosses Paket ”voll” ist. IP ist
(absichtlich) nicht zuverlässig. Überlastungen im Netzwerk werden durch das ”Vergessen”
von Paketen gelöst. Die Verantwortung für die Integritätsprüfung und die Vollständigkeit
der Daten übernehmen die beiden kommunizierenden Rechner, die fehlerhafte Daten erkennen sollen und diese im Fehlerfall erneut anfordern.
Diesen Part übernimmt ein weiteres Protokoll, das Transmission Control Protocol (TCP).
Dieses stellt einen zuverlässigen Dienst über IP-Verbindungen her. Da es auf IP aufsetzt,
muss sich TCP um den ”Weg”, das Routing durchs Netz, keine Gedanken machen. TCP
bringt seine Informationen wiederum in einem Header unter: Dieser ist 20 Bytes lang. Eine
TCP-Verbindung kann man sich am besten wie ein Telefonat vorstellen.
TCP identifiziert die Endpunkte einer solchen Verbindung anhand der IP-Adressen der
beiden Rechner und der Nummer eines sogenannten Ports auf jedem Host. Ports können
Sie sich als eine Art Ein- und Ausgang für Netzwerkverbindungen vorstellen. Diese Adressierung kann man mit einem Haus (IP-Nummer) und den verschiedenen Türklingeln (PortNummern) vergleichen. Auf einer Unix-Maschine kann man sich die Zuordnung von Diensten zu Ports in der Datei /etc/services ansehen.
In TCP/IP-Suite übernimmt das Transmission Control Protocol die Aufgaben der Transportschicht. Es etabliert ein verbindungsorientiertes Protokoll, welches auf dem verbindungslosen Internet-Protokoll aufsetzt. Dadurch gelingt es, einen zuverlässigen Bytestromes
in einer End-zu-End-Ver-bindung auf einem unzuverlässigen Netzverbund aufzubauen.
TCP nimmt Datenströme von Benutzerapplikationen entgegen und teilt diese in maximal 64 kByte grosse Blöcke auf. Diese Datenblöcke, Datagramme23 genannt, werden wiederum mit einem Header versehen. Das so gebildete Datagramm wird dann an die IP-Schicht
23
zur Unterscheidung von den Datenblöcken der Hardwareschicht ”Frames” und den Datenblöcken der
Vermittlungsschicht ”Packet”
76
KAPITEL 5. TCP-IP
weitergeleitet.
Da IP selbst keine Zustellbestätigung kennt muss TCP diese implementieren und bei
Bedarf ein Neuverschicken verlorengegangener oder beschädigter Pakete veranlassen. Weiterhin muss die Reihenfolge der Pakete kontrolliert und evtl. korrigiert werden.
Da auf einem Host mehrere Datenströme möglich sein sollen und nur eine IP-Adresse
vergeben wird, erfolgt die Definition von speziellen Endpunkten. Diese Endpunkte werden als Sockets bezeichnet. Jedes Socket hat eine Socketnummer. Diese besteht aus der
IP-Adresse des Hosts und einer 16 bittigen Portnummer. Ein Socket kann mehrere Verbindungen verwalten, wobei jedoch jedes Quadrupel aus Quelladresse und -port und Zieladresse
und -port eindeutig sein muss.
Portnummern unterhalb von 256 bzw. 1024 sind für sogenannte ”well-known services”
reserviert. Hier findet man die Standarddienste Weitere sechs Ein-Bit-Felder des HeaService
ftp
ssh
telnet
smtp
http
ldap
Port-Nummer
21
22
23
25
80
389
Service
pop3
ntp
rsync
imaps
pop3s
ldaps
Portnummer
110
123
873
993
995
636
Tabelle 5.11: TCP-basierte Standardservices
ders sind für diverse Flags vorgesehen. Sie steuern das Verbindungsverhalten eines TCPDatenkanals. Das Flag Push signalisiert, dass keine Datenpufferung stattfinden soll, d.h.
dass die Datagramme nicht vollständig aufgefüllt werden sollen. Dieses ist bei interaktiven Verbindungen, wie ssh, telnet und dem Steuerkanal von ftp sinnvoll. Sonst müßte man
warten bis z.B. der User an die eintausend Zeichen getippt hat, um ein Paket zu verschicken.
Synchronize, Acknowledge, Reset und Finish dienen der Verbindungssteuerung. Mit
Urgend kann das ”Dringlichkeitsflag” gesetzt werden. Dann zeigt der Urgendpointer, der
in einem weiteren Datenfeld des Headers untergebracht ist, auf das Paket welches sofort
behandelt werden soll. Damit kann eine ”Out-of-Band” Signalisierung erfolgen.
Das Feld für die Header-Länge gibt die Zahl der verwendeten 32 bit-Worte an. Damit
ist das Startfeld der Daten bekannt. Ein Analogon findet man im Fragment Offset des
Internet-Protokolls.
Sequence- und Acknowledgenummern dienen der Kontrolle der Paketreihenfolge und
sollen die Sicherheit einer Verbindung erhöhen. Letzteres darf jedoch nicht dazu verführen,
anzunehmen, dass eine TCP-Sitzung sicher vor bewußter Manipulation oder Mitlauschen
ist. Da alle Daten offen, d.h. unverschlüsselt, übertragen werden, können Angreifer versuchen die Acknowledge- und Sequencenummern zu raten und damit einen Datenstrom
übernehmen.
Diese Nummern werden quasizufällig beim Verbindungsaufbau gesetzt24 und dann jeweils um eins (bzw. in späteren Implementationen auch andere zufällige Integer-Beträge)
erhöht.
Die Window-Size, ein weiteres Feld des TCP-Headers, erlaubt Flusskontrolle. Damit
kann die Geschwindigkeit einer Verbindung gesteuert werden, in dem die Datenmenge bestimmt wird, nach der Paketbestätigungen verschickt werden. Hierbei findet das Sliding24
Da das Verfahren möglichst schnell und effizient arbeiten soll, wurde bei früheren TCPImplementationen die Zahl einfach erhöht, aus dem Zeittakt abgeleitet etc.
5.12. USER DATAGRAM PROTOCOL (UDP)
77
Window-Verfahren Anwendung. Damit wird ein Zeitfenster eröffnet, in dem eine Paketbestätigung eingegangen sein muss.
TCP benutzt eine aufwendige ”State-Machine” für die eindeutige Charakterisierung des
jeweiligen Verbindungszustandes.
Der Verbindungsaufbau erfolgt mittels des sogenannten ”Three-Way-Handshakes”. Erst
nach einem erfolgreichen Verbindungsaufbau kann ein Datentransfer stattfinden. Für Verbindungsabbau erfolgt ein ”geordneter Abschluss” analog zum Aufbau.
5.12
User Datagram Protocol (UDP)
In vielen Fällen der Netzwerkkommunikation genügt die Übertragung eines einzigen Paketes zur Informationsübermittlung in jede Richtung. Der Aufwand würde durch das vorgeschaltete 3-Wege-Handshake, welches TCP implementiert, und den geordneten Abbau der
Verbindung gewaltig angehoben. Dadruch entstünde eine unnötige Belastung des Netzwerkes. Ein weiteres in IP-Netzwerken verwendetes Protokoll ist das im Gegensatz zu TCP
ungesicherte User Datagram Protocol (UDP). Mit UDP werden einzelne Pakete an den
entsprechenden Dienst gesandt, ohne dafür eine Verbindung aufzubauen. Klassischerweise
verwenden NFS, SNMP und RWHO UDP. Die Grösse des Paketheaders beträgt bei UDP
8 Byte und ist damit gegenüber TCP erheblich geringer.
Beispiele für die Anwendung eines solchen sparsamen Protokolls sind das DHCP (Dynamic Host Configuration Protocol) oder DNS (Domain Name System). Die genannten
Protokolle finden nur (DNS sehr viel) im LAN statt - dieses zeichnet sich üblicherweise
durch sehr geringe Fehlerraten aus.
Mit UDP wurde das Design eines sehr einfachen Protokolls der Transportschicht geschaffen, welches IP mit Transportfunktionalität ausstattet. Das User Datagramm Protocol ist
verbindungslos und implementiert nur einen einfachen Header.
32 bit
Source Port
Destination Port
UDP Length
UDP Checksum
User Datagram Protocol
Abbildung 5.13: UDP Paket-Header
UDP verwendet wie TCP 16 bittige Portnummern, womit 65.536 UDP-Ports auf einer
Maschine verfügbar sind. Diese können komplett parallel zu den TCP-Ports verwendet
werden. Weiterhin wird die Paketlänge und eine Prüfsumme vermerkt. UDP kennt keine
Bestätigungsmeldungen und keine Prüfung auf Reihenfolge. Der UDP-Header ist immer
8 Byte lang25 . Deshalb erhält man sehr geringe Latenzzeiten. Es eignet sich gut für Broadcasts. Alle weiteren Aufgaben, die TCP zusätzlich implementiert, müssen bei der Verwendung von UDP von der Applikation übernommen werden.
UDP-Pakete können auch per Broadcast an alle Hosts des lokalen Netzes versandt werden, die IP-Adresse des Empfängers ist dann 255.255.255.255. Das Programm rwhod verwendet dieses Verfahren, um eingeloggte Benutzer und die Uptime der Maschinen in einem
Netzwerk zu ermitteln. Auf diese Weise können recht einfach Systeme realisiert werden, die
bestimmte Listener suchen. Diese melden sich auf einen solchen Broadcast dann mit einem
25
zum Vergleich: TCP hat 20 Byte plus evtl. Optionen
78
KAPITEL 5. TCP-IP
entsprechenden Paket; alle anderen bekommen das Paket erst gar nicht oder müssen sich
einfach an ”alle” wenden. Broadcast-Pakete gehen nur einmal über die Netzwerk-Leitung.
Es wird also nicht für jeden Teilnehmer ein getrenntes Paket verschickt. Die LeitungsBelastung ist also gleich der beim Versenden eines Pakets an nur einen Peer.
5.13
Ports
Ports wurden im Zusammenhang der Transportprotokolle UDP und TCP bereits kurz
erwähnt, aber kaum erklärt. Dies soll an dieser Stelle nachgeholt werden. Über das TCP
und UDP Protokoll können Daten zu einem anderen Rechner übertragen werden. Nun hat
man aber häufig mehrere Dienste auf einem Rechner, und möchte gleichzeitig mit mehreren Diensten kommunizieren können. Da also ein Rechner in der Regel mehr als einen
Dienst anbietet (z.B. FTP, Telnet, POP, ...), muß man neben der IP-Adresse ein weiteres
Adressierungsmerkmal finden. Dies sind die sogenannten Ports. So erreicht man z.B. den
Dienst FTP auf einem Rechner in der Regel über TCP Port 21, Telnet läuft über TCP
Port 23, DNS auf UDP Port 53. Hinter jedem Port steht auf dem Rechner ein Prozeß, der
auf Anfragen wartet, hinter Port 21 entsprechend der FTP-Daemon. Solche üblichen und
allgemein bekannten Ports nennt man ”well-known ports”.
Man sollte die Informationen nicht verwechseln. Adressen sind Teile von IP. Ports sind
Teile von UDP und TCP. Es gibt damit also keine IP-Ports, sondern nur UDP Ports und
TCP Ports.
In der Datei /etc/services sind etliche ”well-known ports” aufgeführt.
5.14
Aufgaben
5.14.1
Internets
1. Warum wurde ein weiteres (hardwareunabhängiges) Netzwerk-Protokoll mit TC/IP
geschaffen?
2. Welche anderen Netzwerkprotokolle sind auf der gleichen OSI-Schicht anzusiedeln,
wie TCP/IP? Warum spielen die meisten eigentlich keine Rolle mehr?
5.14.2
Internet Protokoll / Header
1. Wozu dient das TTL-Feld im IP-Header?
2. Man ergänze mindestens vier IP-Header-Felder!
3. Anhand welchen IP-Header-Felds kann man unter Umständen erkennen, wieviele Maschinen hinter einer maskierenden Firewall (NAT) laufen?
4. Ein Rechner hat ein IP-Datagramm empfangen und erfolgreich ausgewertet. Woher
weiss die Maschine, an welche höhere Netzwerkschicht der Inhalt dieses Pakets (die
sog. Payload) weitergereicht werden soll?
5.14. AUFGABEN
79
5. Welches Protokoll auf welcher Schicht des TCP/IP-Stacks benutzt das Kommando
ping (zur Feststellung der Erreichbarkeit von Rechnern)?
6. Was macht das ToS (Type of Service) Feld im IP-Header? Weshalb wird es meistens
ignoriert?
5.14.3
IP-Netze
1. Was unterscheidet die folgenden IP-Nummern im Netz 134.76.60.0/24: 132.230.4.0,
132.230.4.232, 132.230.4.255, 132.230.4.254, 132.230.4.1 voneinander?
2. Wie konnte ein Router früher schon an der IP-Adresse erkennen, um was für ein Netz
(Netzmaske) es sich handelt? Weshalb hat man dieses Konzept aufgegeben?
3. Wenn man ein Class-C-Netzwerk (Netzmaske 255.255.255.0 in vier Subnetze aufspaltet, wieviele Maschinen können dann in jedem Netz adressiert werden? Erkläre die
Entscheidung!
4. Einem ISP wurde der Nummernblock 82.17.23.0/17 zugeteilt. Nun soll dieser Bereich
in vier gleiche Subnetze aufgeteilt werden. Wie lauten diese?
5. Ein Netzwerk habe die Subnetzmaske 255.255.248.0. Wievele Maschinen können maximal in diesem Netz adressiert werden?
6. Ist eine Subnetzmaske der Form a) 255.255.255.128 oder b) 255.255.213.0 zulässig?
Man begründe die Entscheidung!
7. Was versteht man unter IP-Spoofing? Läßt es sich verhindern; warum oder warum
nicht?
8. Man bastele eine (hypothetische) Netzmaske, die Rechner mit geraden IP-Adressen
in ein und mit ungeraden Adressen in ein anderes Subnetz legt!
5.14.4
Fragmentierung
1. Warum bietet IP die Möglichkeit Pakete zu fragmentieren?
2. Was versteht man unter Path MTU Discovery (PTMUD)? Die MTU (Maximum
Transfer Unit) gibt die maximale Paketgröße auf dem Data Link/physikalischen Layer
an.
3. Wodurch kann PMTUD von Routern (ungewollt) verhindert werden?
80
KAPITEL 5. TCP-IP
4. Warum arbeitet man bei der Fragmentierung mit Offsets und schreibt nicht einfach
die Größe des Fragments in das Feld?
5. Man betrachte die Verschickung eines 4000 Byte Datagramms über ein Netzwerk mit
einer MTU von 900 Byte. Dabei sei das Original mit der Identifikationssnummer 345
bezeichnet worden. Wieviele Fragmente werden generiert? Für jedes Fragment gebe
man die Identifikation, die Payload ohne IP-Header, Offset und den Inhalt des ”More
Fragments” Flags an!
5.14.5
IP-Routing
1. Ein Router hat die folgenden Einträge in seiner (statischen) Routing-Tabelle:
Address/Netmask
135.46.56.0/22
135.46.60.0/22
192.53.40.2/23
87.23.16.0/20
0.0.0.0/0
Next Hop
Interface 0 (direkt)
Interface 1 (direkt)
Router 1
Router 2
Router 3
Wo schickt der Router Pakete mit folgenden Zieladressen lang: 135.46.63.10,
192.53.45.12, 87.23.33.189, 135.46.52.2, 87.23.19.55, 192.53.40.7?
5.14.6
ARP
1. Warum wird eine ARP-Anfrage in einem Broadcast-Frame (Ethernet, TokenRing, ...)
geschickt? Wie sieht so ein spezielles Frame aus?
2. Warum kommt die ARP-Antwort in einem Frame mit einer spezifischen Zieladresse
zurück?
3. Braucht man ARP bei der Modem/ISDN-Einwahl?
Kapitel 6
Linux im Netzwerk
Linux hat sich im Laufe der Zeit zu einem der führenden Betriebssysteme entwickelt, welches
auch und gerade wegen seiner vielfältigen Eigenschaften auch auf Routern1 eingesetzt wird.
Router sind die zentralen Vermittlungs- und Weiterleitungsstellen im verbindungslosen,
paketorientierten Internet.
Linux kann neben TCP/IP auch in AppleTalk, IPX/SPX, Decnet und weiteren Netzwerken betrieben werden. Die folgenden Ausführungen werden sich jedoch nur am Rande mit anderen Netzen als dem Internet-Protokoll (IP) auseinandersetzen. Die folgenden
Ausführungen zum OSI-Modell und TCP/IP haben natürlich nicht nur mit Linux zu tun,
sondern betreffen alle Rechner, die über Netzwerke miteinander (mittels TCP/IP) kommunizieren können.
IP-Netzwerke sind inzwischen die dominierende Form der Rechnervernetzung. Der Komplexitätsgrad und die Anforderungen an diese Netze haben stark zugenommen. Während
lange Zeit die einfache Einbindung einer Linux-Maschine in bestehende Netzwerke durch
Ethernet oder Modem/ISDN im Vordergrund stand, geht mit den aktuellen Kernels bedeutend mehr.
6.1
IP-Konfiguration unter Linux
Die Einbindung von Linux in ein IP-Netzwerk geschieht durch die Zuweisung einer eindeutigen Adresse. Diese ist entweder weltweit erreichbar oder zumindest im lokalen Netzwerk
nur einmal vorhanden.
6.1.1
Die traditionellen Tools
Die Konfiguration der Netzwerkschnittstellen unter Linux erfolgt mit dem Kommando ifconfig. Aufgerufen ohne Optionen liefert es die konfigurierten Schnittstellen:
shuttle:~/ > /sbin/ifconfig
eth0
Link encap:Ethernet HWaddr 00:60:08:38:C7:29
inet addr:10.10.156.2 Bcast:10.10.159.255 Mask:255.255.252.0
inet6 addr: fe80::240:c7ff:fe99:35ad/10 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3841 errors:0 dropped:0 overruns:0 frame:0
TX packets:2437 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:448759 (438.2 Kb) TX bytes:804 (804.0 Kb)
Interrupt:9 Base address:0xe400
1
beispielsweise im Consumer-Bereich auf DSL- oder WLAN-Routern
81
82
KAPITEL 6. LINUX IM NETZWERK
lo
Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:3840 Metric:1
RX packets:26 errors:0 dropped:0 overruns:0 frame:0
TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:118360005 (12.8 Mb) TX bytes:118360005 (12.8 Mb)
In der Ausgabe sieht man je nach Interface die Angaben zur definierten IP, die Hardwareadresse, wenn es sich um ein Ethernetinterface handelt, sonst den Point-to-Pointpartner
(z.B. bei Modem und ISDN). Weiterhin wird angezeigt, welche Protokolle auf dem Interface
registriert sind (z.B. Appletalk und IPv6 sind neben dem klassischen IPv4 denkbar), wieviel
Byte die maximale Paketgrösse transportiert und die ”Kosten” (Metrik) des Interfaces. In
den folgenden Zeilen gibt es Angaben zu den empfangenen und gesendeten Paketen, sowie
den evtl. aufgetretenen Fehlern. Handelt es sich um ein Ethernetanschluss wird in einer
weiteren Zeile die Zahl der Kollisionen vermerkt und die Länge der Queue für ausgehende
Pakete.
Mit dem Befehl: ifconfig eth0 10.10.156.2 netmask 255.255.255.0 broadcast
10.10.56.255 wird z.B. die erste Netzwerkkarte mit der IP-Nummer 10.10.156.2 versehen. Ist eine weitere Netzwerkkarte im Rechner enthalten und soll diese auch eingerichtet
werden, dann spricht man sie mit ifconfig eth1 ... an. Möchte man auf einer Netzwerkkarte mehrere Netze bzw. IP-Nummern konfigurieren, kann dafür ein IP-Alias definiert
werden, wenn in der Kernelkonfiguration ”IP-Aliasing” aktiviert wurde: ifconfig eth0:0
... erlaubt es nun eine weitere IP auf der ersten Netzwerkkarte einzutragen. Dieses Interface wird vom Kernel getrennt von ”eth0” verwaltet, d.h. wenn ich Pakete zwischen
den beiden Interfaces routen möchte, muss ich dieses im Kernel einschalten (echo "1"
>/proc/sys/net/ipv4/conf/ ip forward). Ein Alias auf einer Netzwerkkarte kann man
jedoch nur konfigurieren, wenn diese Netzwerkkarte bereits eingerichtet wurde.
6.1.2
Routing
Im Internet geht es an jeder Stelle um die Weiterleitung von Paketen von einer Quellzur Zieladresse. Jedem Netzknoten, die Internet-Router, müssen für jedes IP-Paket neu
entscheiden, wo sie es langschicken. Routingentscheidungen müssen jedoch schon auf dem
Quellrechner eines Paketes getroffen werden. Dieses gilt für jede Linux-Maschine mit installiertem TCP/IP-Stack. Ist das Paket
• für das Loopback-Interface bestimmt
• soll es im lokalen Ethernet zugestellt werden
• soll es über ein Interface laufen, an dem ein Modem hängt
• soll es an das Default-Gateway im Netz weitergeleitet werden.
Der Linux-Kernel muss also für alle ausgehenden Pakete entscheiden, in welches Netzwerk
er die Pakete schicken soll. Hierzu verwaltet der Kernel eine eigene Routing Tabelle. Diese
enthält Informationen über Routen zu anderen Netzwerkknoten speichert. Jeder Eintrag
einer Route besitzt dabei einen eindeutigen Schlüssel bestehend aus der Netzwerkadresse
und der Netzmaske des verbundenen Netzwerks. Der nächste Hop für ein Paket welches
nicht lokal zugestellt wird, ist das Default-Gateway. Dieses Gateway muss in einem der
angeschlossenen Subnetze liegen, da es sonst nicht erreicht werden kann. Üblicherweise läßt
sich der Admin diese Tabelle durch route -n oder netstat -rn:
6.1. IP-KONFIGURATION UNTER LINUX
linux:~ # route -n
Kernel IP Routentabelle
Ziel
Router
10.8.1.0
0.0.0.0
192.168.15.0
0.0.0.0
169.254.0.0
0.0.0.0
127.0.0.0
0.0.0.0
0.0.0.0
192.168.15.1
Genmask
255.255.255.0
255.255.255.0
255.255.0.0
255.0.0.0
0.0.0.0
83
Flags
U
U
U
U
UG
Metric
0
0
0
0
0
Ref
0
0
0
0
0
Use
0
0
0
0
0
Iface
eth0
eth1
eth1
lo
eth1
ausgeben.
In den SuSE-Linux-Distributionen werden die IP-Einträge unterhalb des Konfigurationsverzeichnisses /etc/sysconfig/network gespeichert und über das Runlevel-Skript /etc/init.d/
network start2 mittels ip aktiviert. Bezieht der Rechner seine IP dynamisch per DHCP, so
wird statt ip ein DHCP-Client-Tool, wie dhclient, pump oder dhcpcd ausgeführt. Diese
Dienste beziehen die IP-Konfiguration über das lokale Ethernet und tragen die Ergebnisse
direkt oder per Skript dhclient-script in die Netzwerkkonfiguration ein.
6.1.3
Next Generation IP-Config
Die meisten Administratoren kennen und arbeiten immer noch ausschliesslich mit den traditionellen Werkzeugen ifconfig und route. Das IProute2-Paket erlaubt jedoch eine weit
höhere Flexibilität. IProute2 ist seit Kernel-Version 2.2 standardmässig für das Routing
von IP-Paketen zuständig. Es beherrscht eine ganze Reihe neuer Fähigkeiten:
• des Weiterleitens
• des Filterns
• der Klassifikation
von IP-Paketen. Hierzu zählen beispielsweise das Einrichten von Backup-Gateways und das
Verwenden von mehreren Default-Gateways. Wo früher nur die Zieladresse eines Paketes
bei der Routing-Entscheidung eine Rolle spielte, können nun auch die Absendeadressen
hierfür in Betracht gezogen werden. Ebenfalls lassen sich verschiedene Wege und Prioritäten
anhand von eingesetzten höher liegenden Protokollen (TCP und UDP) und deren Ports
festlegen. Auf diese Weise erhält der ”best-effort” Service IP eine Quality of Service (QoS)
Komponenten verpasst. Diese ist deutlich mächtiger als die meist sporadische Verwendung
der Type of Service (ToS) Flags des IP-Headers.
IProute2 führt neue Kommandos ein: ip und tc sind die beiden wichtigsten. Das erste
Kommando dient zur Bearbeitung der Kernel-Routing-Tabelle. Das zweite zur Manipulation verschiedener Verkehrsklassen. Letzteres ist Thema an anderer Stelle im Skript. Die
Tool-Suite enthält weitere Kommandos, wie nstat, ifstat, routel, rtstat. Sie generieren
Statistiken und Überblicke.
6.1.4
Das Kommando ip
IProute2 stammt von Alexey Kuznetsov entwickelt. Das Projekt besteht seit 1999 und wird
seit Kernel 2.2 für das lokale Routing von IP-Paketen benutzt. Folgende Aktionen kann ein
Sysadmin mit IProute2 vornehmen:
• Management von IP-Adressen (IPv4, IPv6)
2
Die Runlevel-Skripten sind auch direkt mit rcnetwork aufrufbar, da dieses Links aus dem Verzeichnis
/usr/sbin auf die entsprechenden Runlevelskripten sind.
84
KAPITEL 6. LINUX IM NETZWERK
• ARP Tabellen Management
• Routing Tabellen Management
• Routing Policy Database Management
• IP Tunnel Konfiguration
• Paket und Routen Monitor
• Traffic Shaping (QoS)
ip ist ein zusammengesetztes Kommando. Seine Funktion wird durch das zu bearbeitende Objekt bestimmt. Allgemein setzt sich der Aufruf von ip wie folgt zusammen: ip
[OPTIONS] OBJECT [COMMAND[ARGUMENTS]|help]
Die OPTIONS beeinflussen wie bei gewohnten Kommandos auch das generelle Verhalten
und die Ausgabe die ip Befehls. Optionen folgen direkt nach dem Kommando und sind mit
dem ”-” Zeichen eingeleitet. Sie können nicht hinter dem Objekt stehen.
• -V[ersion] - gibt die aktuelle ip-Version aus.
• -s[tatistics] zeigt passend zum Objekt ausführlichere Informationen an.
• -f[amily] inet, inet6, link legt die die Protokollfamilie fest.
• -o[neline] sorgt für die Ausgabe aller Informationen in einer Zeile. So läßt sich die
Ausgabe in Skripten oft besser bearbeiten.
• -r[esolve] schaltet die Namensauflösung von IP-Adressen und Netzen ein.
OBJECT bezeichnet den Objekttyp. Zu diesem lassen sich Informationen ausgeben.
Oder es wird eine Operation auf ihn angewendet. Das Objekt
• link bezeichnet ein physikalisches oder logisches Interface bzw. Netzwerkadapter.
• address ist die IPv4 oder IPv6 Adresse eines Adapters.
• neighbour greift auf den Kernel ARP Cache zu.
• route gibt Routing Tabellen aus und erlaubt deren Bearbeitung
• rule bezeichnet eine Regel in der Routing Policy Database.
• maddress dient zur Bearbeitung von Multicast Adressen.
• mroute ist für Multicast Routing Cache Einträge
• tunnel definiert IP-in-IP Tunnel.
COMMAND spezifiziert die Aktion, die mit dem OBJECT veranstaltet werden soll.
Die Art und Menge der möglichen Aktionen hängt dabei vom Objekttyp ab. Üblicherweise
lassen sich Objekte hinzuzufügen (add), entfernen (delete) oder anzeigen (show). Einige
Objekte kennen weniger andere weitere Aktionen.
ARGUMENTS sind Kommando-Optionen. Sie hängen von der Art des Kommandos
und vom Objekttyp ab. Es existieren zwei Typen von Argumenten:
• flags - können durch einzelnes Schlüsselwort abgekürzt werden.
• parameters - bestehen aus einem Schlüsselwort gefolgt von einem Wert.
help liefert immer eine Kurzhilfe für das Kommando generell oder die Anwendung des
Kommandos auf einzelne Objekte, z.B. ip help oder ip route help.
6.1. IP-KONFIGURATION UNTER LINUX
6.1.5
85
Erste Schritte mit ip
Die folgenden Beispiele sollen demonstrieren, wie ip die Standardaufgaben von route, arp
und ifconfig übernimmt, die ein Sysadmin üblicherweise damit ausführt. Dazu sollte man
sagen, dass bereits seit einiger Zeit die beiden traditionellen Kommandos ifconfig und
route im Hinterground ip verwenden. Das Anzeigen aller Interfaces mit darauf definierten
IP-Adressen erfolgt durch:
linux02:~ # ip addr show
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:29:0b:f9:38 brd ff:ff:ff:ff:ff:ff
inet 10.8.4.254/24 brd 10.8.4.255 scope global eth0
inet 10.2.13.248/32 scope global eth0
inet6 fe80::2e0:29ff:fe0b:f938/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:0c:6e:15:03:0e brd ff:ff:ff:ff:ff:ff
4: sit0: <NOARP> mtu 1480 qdisc noqueue
link/sit 0.0.0.0 brd 0.0.0.0
11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1412 qdisc pfifo_fast qlen 10
link/[65534]
inet 132.230.129.2/32 scope global tun0
Die Informationen zur Routing Tabelle liefert das Kommando ip wie folgt:
linux02:~ # ip route show
10.1.1.11 via 10.8.4.1 dev eth0 src 10.2.13.248 mtu 1500 advmss 1460 \
fragtimeout 64
10.8.4.0/24 dev eth0 proto kernel scope link src 10.8.4.254
169.254.0.0/16 dev eth0 scope link
10.0.0.0/14 via 10.8.4.1 dev eth0 src 10.2.13.248
127.0.0.0/8 dev lo scope link
default dev tun0 scope link
Das Bild sieht etwas anders als von route gewohnt aus. Administratoren mit langer IPErfahrung werden sich schnell zurecht finden und die Vorteile von ip schätzen lernen.
Das Setzen einer IP-Adresse auf ein Interface oder das Hinzufügen einer weiteren, durchaus auf dasselbe, geschieht mit:
linux02:~ # ip addr add 10.8.1.10/24 broadcast 10.8.1.255 dev eth0
linux02:~ # ip addr add 10.8.2.10/24 broadcast 10.8.2.255 dev eth0
linux02:~ # ip addr show eth0
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:5a:b3:d6 brd ff:ff:ff:ff:ff:ff
inet 10.8.1.10/24 brd 10.8.1.255 scope global eth0
inet 10.8.2.10/24 brd 10.8.2.255 scope global eth0
86
KAPITEL 6. LINUX IM NETZWERK
Die Angabe der Netzwerkmaske ist einigen vielleicht etwas ungewohnt. Statt in der klassischen Form einer IP-Adresse (hier wäre es die 255.255.255.0) erfolgt die Beschreibung
durch die Zahl der Einsen im Präfix (hier 24). Die (Hardware-)Daten zu einem einzelnen
Interface zeigt:
linux02:~ # ip link show eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0c:29:5a:b3:d6 brd ff:ff:ff:ff:ff:ff
linux02:~ # ip link set eth0 down
linux02:~ # ip link set eth0 address 00:20:AA:20:AA:20
linux02:~ # ip link set eth0 mtu 1400
linux02:~ # ip link set eth0 name dsl0
linux03:~ # ip link show dsl0
2: dsl0: <BROADCAST,MULTICAST> mtu 1400 qdisc pfifo_fast qlen 1000
link/ether 00:20:aa:20:aa:20 brd ff:ff:ff:ff:ff:ff
Abschalten läßt es sich mit dem darauf folgenden Befehl. Wenn der Admin die MAC-Adresse
des Interfaces ändern will, kann er dazu ebenfalls das Subkommando ”set” verwenden. Nur
diesmal ist es nicht ein einfaches Flag (down) sondern ein Parameter gefolgt durch einen
Wert (die neue Hardwareadresse). Eben dieses gilt für die Reduktion der MTU um 100 Byte
oder für das Setzen eines anderen Interface-Namens. Das macht dann Sinn, wenn der Admin
Interfaces beispielsweise nach ihrer Funktion kennzeichnen möchte. Anschliessend erfolgt die
Anzeige der Konfiguration mit dem neuen Interface-Namen (hier dsl0). Das Interface ist
abgeschaltet - zu sehen daran, dass in der Anzeige bei den Flags ”UP” fehlt. In jedem
der gezeigten Aufrufe wurde das Interface direkt hinter dem Kommando (set oder show)
angegeben.
Mit der gesetzten Option ”-s” gibts etwas mehr zu sehen:
linux02:~ # ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:e0:29:0b:f9:38 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
162342126 915844
0
0
0
0
TX: bytes packets errors dropped carrier collsns
1020902001 1147698 0
0
0
0
Die Statistiken zum Interface kennt man schon von ifconfig. ip zeigt sie in einer Tabelle,
was die skriptbasierte Auswertung erleichtert. Mehr Informationen gibt es bei Wiederholung
der Option (”-s -s”). Dann schlüsselt ip noch die Art der aufgetretenen Fehler auf.
Der ARP-Cache kann mit:
linux02:~ # ip neighbor show
10.8.4.220 dev eth0 lladdr 00:10:a4:8d:56:0a nud delay
10.8.4.1 dev eth0 lladdr 00:0f:66:c7:73:e8 nud stale
10.8.4.204 dev eth0 lladdr 00:08:74:4d:6f:3f nud stale
ausgelesen werden.
6.2
Weitergehende Anwendungen von IProute2
In den ersten Abschnitten wurden einige IP- und Routingkonfigurationen gezeigt. Mit den
IProute2-Kommandos ist jedoch noch einiges mehr drin.
6.2. WEITERGEHENDE ANWENDUNGEN VON IPROUTE2
6.2.1
87
Weitere Tools
Das IProute2-Paket enthält einige weitere nützliche Programme. So liefert das Kommando
nstat Statistiken des Kernels zum IP-Verkehr.
linux02:~ # nstat
#kernel
IpInReceives
IpForwDatagrams
IpInUnknownProtos
IpInDelivers
IpOutRequests
IpReasmReqds
IpReasmOKs
IpFragOKs
IcmpInErrors
IcmpInDestUnreachs
IcmpInTimeExcds
IcmpInParmProbs
IcmpInEchoReps
IcmpInTimestamps
IcmpOutErrors
IcmpOutTimeExcds
IcmpOutTimestamps
TcpActiveOpens
TcpPassiveOpens
[ ... ]
1011352
48960
3
953958
1255516
16824
8412
2
5437
5
222
4736
476
3
26789
26313
476
1258
323
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
0.0
Diese Informationen kennen einige vielleicht schon von der SNMP-Standard-MIB. Letztendlich macht beispielsweise NetSNMP unter Linux nichts anderes, als diese Kernel-Informationen auszulesen. So erhält der Admin Informationen zu empfangenen und gesendetet
IP-Paketen (IpInReceives, IpOutRequests), wieviele davon geroutet wurden (IpForwDatagrams), unroutebare Pakete (IpOutNoRoutes). Ebenfalls gibt es Statistiken zum Internet
Control Message Protocol (ICMP). ICMP liefert IP-Fehlermeldungen, wenn Netzwerke,
Maschinen, höherschichtige Protokolle oder Ports nicht erreichbar sind (IcmpInDestUnreachs). Ping benutzt mit Echo und Reply diesen Dienst für Tests auf Erreichbarkeit von
IP-Adressen (IcmpInEchoReps). Weiterhin gibt es Statistiken zu IPv6, UDP und TCP.
routel ist ein Shell-Skript und gibt eine ausführliche Kernel-Routing-Table aus. ifstat
fasst die Statistiken zu Datenraten der einzelnen Netzwerkinterfaces zu einer Tabelle zusammen:
linux02:~ # ifstat
ifstat: history is aged out, resetting
#kernel
Interface RX Pkts/Rate
TX Pkts/Rate
RX Errs/Drop
TX Errs/Drop
lo
3905 0
3905 0
0 0
0 0
eth0
915949 0
1120K 0
0 0
0 0
tun0
9071 0
13359 0
0 0
0 0
RX Data/Rate
RX Over/Rate
393392 0
0 0
158546K 0
0 0
3535K 0
0 0
TX Data/Rate
TX Coll/Rate
393392 0
0 0
996987K 0
0 0
1090K 0
0 0
Der Befehl ss zeigt die aktuell bestehenden TCP-Verbindungen an:
linux02:~ # ss
State
Recv-Q
Send-Q
Local Address:Port
Peer Address:Port
88
ESTAB
ESTAB
ESTAB
KAPITEL 6. LINUX IM NETZWERK
0
0
0
0
0
0
132.230.129.7:56946
10.8.4.254:57051
132.230.129.7:56687
132.230.1.142:ssh
10.8.4.205:microsoft-ds
134.76.63.80:ssh
Zu weiteren Kommandos und ausführlicheren Beschreibungen sei auf die mitgelieferte Dokumentation oder weiterführende Literatur verwiesen.
6.2.2
Routing Policy Database
Klassisches TCP/IP Routing wertet auf dem Weg eines Paketes nur dessen Zieladresse aus.
Erst am Ziel wird im Falle einer Antwort die Quelladresse benutzt. Oftmals ist jedoch
Routing auf der Basis von anderen IP-Header Daten wie beispielsweise der Quelladresse,
des höherschichtigen Protokolls oder ToS erwünscht. Da sich einzelne Dienste gut an ihren
Portnummern untscheiden lassen, soll vielfach auch der nächste Header in Betracht gezogen
werden. Der Port steht im TCP oder UDP-Kopf. Diese Art des Routings bezeichnet man
als Policy Routing. Viele Admins kennen dieses Konzept bereits von der Einrichtung einer
Firewall.
In IProute2 wird das Policy Routing durch eine Routing Policy Database (RPDB) und
einem Set von Regeln implementiert. Die RPDB besteht aus 255 Tabellen, mit denen IPPakete die bestimmten Mustern folgen, geroutet werden können. Die Muster lassen sich mit
dem Befehl ip rule und die Routing Tabellen mit ip route manipulieren.
Immer eingerichtet sind drei vorkonfigurierte Tabellen ”local”, ”main” und ”default”.
Dazu gehören drei Regeln, die bestimmen wann diese Tabellen für das Routing aufgerufen werden sollen. Die Regeln werden in der Reihenfolge ihrer Priorität abgearbeitet. Die
Priorität ist der Wert vor dem Doppelpunkt.
linux02:~ # ip rule show
0:
from all lookup local
32766: from all lookup main
32767: from all lookup default
In der vorkonfigurierten Einstellung wird für jedes ankommende Paket die Route zuerst in
der Tabelle local nachgeschlagen. Falls sie dort nicht steht, werden die Tabellen main und
danach default befragt.
Mit Hilfe der RPDB lassen sich nun Fragestellungen, wie das Routing in Abhängigkeit
von der Absendeadresse oder das Routing mit mehreren Gateways einfach realisieren. Das
Routing nach Quelladresse demonstriert das erste Beispiel. Sei ein kleines Firmennetz über
zwei Provider an das Internet angeschlossen. Ein Provider bietete eine schnelle Leitung, die
jedoch relativ teuer sei. Der andere Provider sei billig, hat aber eine deutliche Verzögerung.
Es sollen daher nur Pakete vom Voice-over-IP-Gateway der Beispielfirma (IP-Adresse
192.168.100.100) über den schnellen Provider 192.168.1.254 geleitet werden. Alle anderen
Pakete nehmen den verzögerten Weg über das Gateway 192.168.2.254:
Alle Maschinen im privaten Subnetz 192.168.100.0 benutzen ein gemeinsames Linux
Default-Gateway. Auf diesem Gateway soll anhand der Quelladresse entschieden werden,
über welchen Router (das können beispielsweise kleine integrierte DSL/ISDN-Router sein)
ein Paket seinen weiteren Weg nimmt.
Für dieses Regelset wird zuerst eine neue Tabelle ”SourceRouting” in der Datei /etc/
iproute2/rt tables eingetragen. Hierfür muss eine Regel erstellt werden, die für alle Pakete
mit der Quelladresse 192.168.100.100 die Routing Tabelle ”SourceRouting” befragt.
linux02:~# echo 100 SourceRouting >> /etc/iproute2/rt_tables
linux02:~# ip rule add from 192.168.100.100 table SourceRouting
linux02:~# ip rule show
6.2. WEITERGEHENDE ANWENDUNGEN VON IPROUTE2
89
Abbildung 6.1: Default-Gateway mit zwei Wegen zu verschiedenen Routern
0: from all
32765: from
32766: from
32767: from
lookup local
192.168.100.100 lookup SrcRouting
all lookup main
all lookup default
Zum Schluss wird noch das schnelle Gateway als Standard Route in die Tabelle SourceRouting eingetragen. Ab dann werden alle Pakete von der IP-Adresse 192.168.100.100 über
den schnellen Weg geschickt.
linux:~# ip route add default via 192.168.1.254 dev eth0 table SourceRouting
6.2.3
Generelle 2-Wege-Routen
Das folgende Beispiel befaßt sich wieder mit dem Routing über zwei Gateways. Es können
auch mehrere sein, das spielt hier aber keine Rolle. Die Fragestellung ist etwas modifiziert:
• Wie kann man ausgehenden Verkehr gleichmässig auf beide Strecken verteilen (Load
Balancing)?
• Wie lassen sich Pakete, die über eine Leitung kommen wieder über dieselbe verschickt
werden (Split Access)?
• Wie kann eine Backup-Default-Route definiert werden, die nur bei Ausfall der DefaultRoute benutzt wird?
In einem ersten Schritt legt man zwei neue Routing Tabellen Route1 und Route2 in
/etc/iproute2/rt tables an, identisch zum eben beschriebenen Verfahren. Route1 sei dabei
die Tabelle für Provider 1 und entsprechend Route2 die für Provider 2.
linux02:~#
linux02:~#
linux02:~#
linux02:~#
ip
ip
ip
ip
route
route
route
route
add
add
add
add
132.230.129.0/28 dev eth0 src 132.230.129.1 table Route1
default via 132.230.129.15 table Route1
80.168.20.0/25 dev eth1 src 80.168.20.125 table Route2
default via 80.168.20.126 table Route2
Die Routing Rules legen fest, welche Tabelle für welche IP herangezogen wird.
90
KAPITEL 6. LINUX IM NETZWERK
Abbildung 6.2: Szenario mit zwei Routen über Provider 1 und 2
linux02:~# ip rule add from 132.230.129.1 table Route1
linux02:~# ip rule add from 80.168.20.125 table Route2
Im folgenden Schritt wird die Main Routing Tabelle für das lokale Routing in beide Netzwerke konfiguriert.
linux02:~# ip route add 132.230.129.0/28 dev eth1 src 132.230.129.1
linux02:~# ip route add 80.168.20.0/25 dev eth2 src 80.168.20.125
Zum Abschluss wird die Default-Route für die ”main” Routing Table gesetzt. Da der
Verkehr gleichmäßig auf beide Anschlüsse verteilt werden soll, muss die Route jetzt als
Multipath-Route angelegt sein. Der ”weight” Parameter dient dazu die Verteilung über die
einzelnen Verbindungen zu gewichten. Man kann bei Bedarf auch einen Provider stärker als
den anderen belasten.
linux02:~# ip route add default scope global nexthop via 132.230.129.14 dev eth1 \
weight 1 nexthop via 80.168.20.126 dev eth2 weight 1
Im letzten Beispiel wurden die beiden Default-Routen gleichmäßig oder gewichtet benutzt.
Wenn eine immer verwendet werden soll und die andere nur beim Ausfall der ersten den
Datenverkehr komplett übernimmt, kann man das über die Angabe einer Metrik3 regeln.
Der Kernel benutzt Gateway immer die Route mit der kleinsten Metrik, solange er sie
erreichen kann. Falls diese nicht mehr verfügbar ist, greift er automatisch auf die Route
mit der nächstkleineren Priorität zurück. Für das Beispiel soll Gateway 80.168.20.126 als
Gateway für eventuelle Ausfälle von Gateway 132.230.129.14 dienen. Für diese Aufgabenstellung genügt es, die Route zum Router 1 mit einer Metrik 1 zu definieren. Die Route
zum Backup-Gateway erhält eine höhere Metrik von beispielsweise 5. Die reinen Zahlenwerte sind dabei nicht so interessant. Alle vorherigen Routingeinstellungen sind vorher zu
löschen. Das Beispiel nutzt dazu das Kommando ”flush”. Mit der Option ”-4” legt man fest,
dass flush nur auf IPv4-Adressen wirkt. Damit bleiben eventuell vorhandene IPv6-Einträge
unberührt.
linux02:~# ip -4 addr flush label "eth0"
linux02:~# ip route add default via 132.230.129.14 dev eth0 metric 1
linux02:~# ip route add default via 80.168.20.126 dev eth0 metric 5
3
”Kosten” oder Präferenz einer Route - je kleiner der Wert desto besser
6.3. ÜBERPRÜFUNG DER KONFIGURATION
6.2.4
91
Dienste-basiertes Routing
Wenn sich Dienste und deren Administratoren an Standards halten, kann man sie anhand
ihrer verwendeten Portnummern identifizieren. Die Datei /etc/services listet die Zuordnung
von Portnummern zu Diensten auf. ip hat selbst keine Möglichkeit direkt in folgende Header,
TCP oder UDP eines Datenpaketes zu schauen. Das können entweder tc oder besser das
Netfilter Paket übernehmen. Letzteres ist oft sowieso schon als Firewall im Einsatz. So lassen
sich IP-Pakete klassifizieren und ihre Header manipulieren. Man markiert Pakete, die an
einen bestimmten Port geschickt werden, mit einer Nummer. Auf Basis dieser werden dann
wieder Routing Tabellen erstellt.
Das Beispiel sei wie das eingangs beschriebene. Diesmal sollen nur SSH Pakete die
schnelle Verbindung passieren und alle anderen den kostengünstigeren Weg nehmen.
Als erstes, werden alle ausgehenden SSH-Pakete mit dem Netfilter-Tool iptables durch
eine ”1” gekennzeichnet. Das Label kann eine beliebige Zahl sein.
linux02:~#
--set-Mark
linux02:~#
linux02:~#
linux02:~#
iptables -A OUTPUT -i eth0 -t mangle -p tcp --dport 22 -j MARK \
1
echo 200 ssh >> /etc/iproute2/rt_tables
ip rule add fwmark 1 table ssh
ip route add default via 192.168.1.254 dev eth0 table ssh
Dann wird wieder eine Regel in der RPDB erstellt, die besagt, dass für alle Pakete, die
mit einer 1 markiert sind, die Tabelle ssh befragt wird. Zuletzt muss eine Default Route
zur schnellen Verbindung in der Routing Tabelle ssh erzeugt werden. Ab dann gehen alle
SSH-Pakete über den schnellen Router 1.
6.3
Überprüfung der Konfiguration
Den Erfolg einer IP-Konfiguration kann man am besten im Netz mit dem Befehl ping testen
(das setzt einen weiteren Rechner mit garantiert funktionierender Netzwerkkonfiguration
voraus!). ping IP-Adresse/Hostname sendet Datenpakte im Sekundenabstand an die
angegebene IP-Adresse oder Rechnernamen4 . Ping5 kennt einige interessante Kommandoparameter, die sich auch zum Testen der Leistungsfähigkeit eines LAN’s eigenen. So lässt
sich mit ”-c Zahl” die Anzahl der verschickten Pakete festlegen, ”-f” lässt den Systemadministrator so viele Pakete versenden, wie nur irgendwie geht und mit ”-s Zahl” lässt sich die
Paketgrösse, die zum Test verschickt wird, variieren.
Meldet ping keinen Erfolg6 , kann man mit dem Kommando tcpdump überprüfen, ob
überhaupt Datenpakete auf dem Netzwerkinterface eintreffen und vom Kernel registriert
werden.
6.4
6.4.1
Aufgaben
IP-Konfiguration und Erreichbarkeit
1. Wie bekommt man folgende Informationen heraus: IP Adresse, Routing Tabelle, eigene MAC-Adresse(n)?
2. Wie lautet die Netzwerkmaske des eigenen Subnetzes und wie kann diese verändert
werden?
4
Dieses setzt jedoch einen funktionierenden Nameservice voraus!
weitere Informationen kann man sich über den Aufruf der Manualseiten mit man ping anzeigen lassen.
6
das meint eine Meldung wie ”100” packet loss”
5
92
KAPITEL 6. LINUX IM NETZWERK
3. Warum muss die eigene Netzwerkmaske zu den Einstellungen des Subnetzes passen,
in dem man sich befindet? Was passiert, wenn die Maske des Subnetzes kleiner oder
größer als die auf der eigenen Maschine eingestellte ist?
4. Man organisiere sich die IP vom Nachbarn und versuche diesen per Ping zu erreichen.
Wie erfährt man seine eigene Default-Gateway-Adresse?
5. Wie erfahre ich die MAC-Adressen meiner Kommunikationspartner? Wie lauten die
MAC-Adressen für goe.net oder www.spiegel.de?
6.4.2
Datenverkehr zählen
1. Welche ganz einfachen Möglichkeiten hat man, um festzustellen, wieviel Datenverkehr
von einer Maschine ins Netz geschickt oder empfangen wurde?
Kapitel 7
DHCP
7.1
Automatische IP-Zuweisung
Administratoren sind für ihren zugewiesenen IP-Bereich selbst zuständig RZ teilt z.B. das
Uni Class-B-Netz von 132.230.0.0/ 255.255.0.0 mittels Subnetting in 256 Class-C Netze
auf. In diesen Netzen sind bis zu 254 Rechner zu verwalten. Ziel ist die Rezentralisierung
der netzwerkseitigen Konfiguration - der Einsatz des DHCP (Dynamic Host Control Protocol) als Netzwerkprotokoll der Anwendungsschicht, mittels dessen grundlegende Daten zur
Konfiguration eines Clientsystems übertragen werden können.
Dynamic Host Configuration Protocol kann zur automatischen und dynamischen IPZuweisung verwendet werden. Damit kann die Konfiguration auf einem zentralen Rechner
des Teilnetzes erfolgen (bzw. weitere lassen sich aus Redundanzgründen einfügen). Die Rechner lassen sich fest konfigurieren, aber es kann auch ein Pool von Adressen für wechselnde
Hosts verwaltet werden.
Damit kann eine weit höhere Anzahl von Maschinen als vorhandene IP-Nummern bedient werden. DHCP verwendet spezielle IP-Nummern 0.0.0.0 (Host ohne IP-Information)
und 255.255.255.255. Lokaler Broadcast an alle Teilnetze sind durch Router voneinander
abgegrenzt, damit werden Broadcastpakete nur im eigenen Subnetz sichtbar. 0.0.0.0 wird
nach IP-Bezug sofort wieder frei.
7.2
Implementation
DHCP1 , das ”Dynamic Host Control Protocol” stellt eine Erweiterung und Ergänzung des
BOOTP dar. Die Einschränkungen im BOOTP einerseits und seine anerkannten Vorteile
zur Konfiguration großer Rechnerzahlen andererseits mündeten in der Entwicklung von
DHCP.
Weiterentwicklungen, wie z.B. dynamisches DNS, finden in erster Linie beim dhcpd
statt, die verwendeten bootpd Implementierungen stammen aus den Anfängen der 90er
Jahre und werden nur noch im Fall grober Sicherheitsverletzungen gepatcht. Das InternetSoftware-Consortium2 entwickelte eine Beispielimplementation des DHCP und einiger anderer Internetprotokolle. Der Sourcecode liegt in den meisten Fällen auch in einer Linuxanpassung vor, so dass eine einfache Übersetzung für die Zielplattform erfolgen kann. Im
1
Die grundlegenden RFCs für DHCP sind:
RFC1541 : ”Dynamic Host Configuration Protocol”, Oktober 1993
RFC2131 : ”Dynamic Host Configuration Protocol”, März 1997
RFC2132 : ”DHCP Options and BOOTP Vendor Extensions”, März 1997
2
siehe dazu [W6], wobei das ISC neben der DHCP-Implementierung weitere Internet-Standards betreut.
93
94
KAPITEL 7. DHCP
Weiteren bezieht sich daher die Beschreibung auf die DHCP-Implementierung des ISC.
Diese liegt inzwischen in der dritten Version vor und unterstützt eine ganze Reihe neuer
Eigenschaften, wie die Unterstützung von Dynamischen DNS oder Vendor Code Identifier.
32 bit
OP
HTYPE
HLEN
HOPS
TRANSACTION IDENTIFIER
SECONDS ELAPSED
FLAGS
CLIENT IP ADDRESS
YOUR IP ADDRESS
SERVER IP ADDRESS
ROUTER IP ADDRESS
CLIENT HARDWARE ADDRESS (16 OCTETS)
.
.
SERVER HOSTNAME (64 OCTETS)
.
.
OPTIONS (VARIABLE)
.
.
DHCP Message Format
Abbildung 7.1: Aufbau eines DHCP-Paketes
DHCP arbeitet auf Port 67 zur Anfrage an den Server und auf Port 68 zur Rückantwort
an den Client. Solche Informationen findet man in der /etc/services. Das vorgestellte Protokoll läßt sich nur sinnvoll in broadcastfähigen Netzen3 einsetzen. Es ist nicht (bzw. nur
über den Umweg eines DHCP-Gateway-Servers) routebar. DHCP verwendet als Transportprotokoll UDP, da 3-Wege-Handshake mit den IP-Spezialadressen4 kaum sinnvoll realisiert
werden kann. In den meisten Fällen genügt ein Datenpaket pro Konfigurationsschritt in
jede Richtung. DHCP ist eine Erweiterung des Bootp, welches weniger komplex im Leasehandling ist. Es kennt nur statische Adresszuweisungen und weniger vordefinierte Konfigurationsoptionen.
DHCP arbeitet im vierstufigen Verfahren bei der Adresszuweisung:
• Client schickt DHCPDISCOVER an 255.255.255.255 Port 67 um Server zu ermitteln
• Server schickt einen Vorschlag mit Parametern als DHCPOFFER an 255.255.255.255
Port 68
• Client sucht sich aus evtl. mehreren ”Offers” nach bestimmten Kriterien eine passende
aus (z.B. nach der Länge der ”Lease”) und schickt DHCPREQUEST gerichtet an den
passenden Server
• Server bestätigt mit DHCPACK gerichtet an Client
3
4
Ethernet bzw. TokenRing
255.255.255.255 für den lokalen Broadcast im Netz als Anfrage mit der eigenen IP 0.0.0.0
7.2. IMPLEMENTATION
95
Server
1
Konfiguration
festlegen
Client
DHCPDISCOVER
Beginn der
Initialisierung
DHCPOFFER
2
DHCPREQUEST
Konfiguration
wählen
3
Konfiguration
annehmen
DHCPACK
4
Initialisierung
abgeschlossen
5
DHCPRELEASE
Sauberes
Beenden
Lease
entfernen
Abbildung 7.2: Ablauf einer DHCP-Anfrage
• Server kann ein Request eines Clients ablehnen und ein NAK schicken
• Wenn der Client ein Problem mit der zugewiesenen Adresse hat, sendet er ein DECLINE
• Der Client kann die erhaltene Adresse vor Ablauf zurückgeben und hierfür ein RELEASE senden
• Der Client kann die erhaltene Adresse vor Ablauf verlängern und hierfür ein RENEW
schicken
Der DHCP-Server verwaltet den Adresspool und versieht jede Adresse mit der ”Verleih”Zeit. Er kennt eine Reihe fest definierter Optionen und bei Bedarf können weitere eigene
Optionen definiert werden.5
Im Ethereal-Mitschnitt kann man gut den Aufbau eines DHCP-(Request)-Paketes sehen,
wie er schematisch im Bild (DHCP-Paket) gezeigt ist. Das erste Feld gibt den Typ des
Paketes an - hier Boot-Request. Die verwendete Hardware ist ein Ethernet, weshalb die
MAC-Adressen 6 Byte lang sind. Es traten keine Hops auf, da die Aktion im selben LAN
stattfand. DHCP arbeitet mit dem verbindungslosen UDP. Deshalb muss es Transaktionen
zuordnen können. Hierfür gibt es einen 32 bittigen Identifier. Darauf folgten die verstrichene
Zeit und Flags.
5
insgesamt sind 255 Optionen möglich
96
KAPITEL 7. DHCP
Abbildung 7.3: DHCP-Session unter der Lupe
Interessant sind dann wieder die Blöcke der IP-Adressen. Der Client kann eine Adresse von einer noch gültigen Zuweisung besitzen (Client IP). Die vom Server zugewiesene
Adresse steht in ”Your IP”. Next Server kann die Adresse des nächsten zu kontaktierenden
Servers beispielsweise TFTP enthalten. Sonst steht hier die Adresse des DHCP-Servers.
Die Adresse des Relay-Agent enthält die IP des beteiligten Routers, wenn die Anfrage über
ein DHCP-Relay zum Server gelangte. Im Beispiel sind alle Adressen leer (0.0.0.0). Diese
Informationen entnimmt der DHCP-Client nicht dem IP-Header. So können ”Next Server”
und die Absendeadresse des DHCP-Servers durchaus differieren.
Weitere Felder sind für den Serverhostnamen und ein Bootfile (das dann per TFTP
geholt werden könnte - nützlich für Diskless Clients) reserviert. Ab dann geht es weiter mit
den verschiedenen DHCP-Optionen. Interessant ist vielleicht noch die Option 50 (Requested
IP Address). Da der Client schoneinmal eine Lease bezogen hatte, versucht er die gleiche
IP-Nummer wieder anzufordern. Das hat den Vorteil, dass die Maschine bestehende IPVerbindungen nicht durch Adressenwechsel kappt. Die meisten anderen Optionen erklären
sich selbst. Eine Liste aller dem ISC-Server bekannten Optionen liefert die Manpage: man
dhcp-options.
7.3
DHCP-Server
Konfiguriert wird der DHCP-Dämon (dhcpd) mittels /etc/dhcpd.conf. Es stehen etliche
weitere Einstellungen zur Verfügung; diese können mit man dhcp-options angezeigt werden.
Die DHCP-Konfigurationsdatei hängt in ihrer Ausgestaltung vom verfolgten Einsatzziel
ab: So werden für Diskless X-Stations bzw. Linux-Workstations vielleicht eine Reihe zusätz-
7.3. DHCP-SERVER
97
licher Daten übertragen, die für den Betrieb von Windowsmaschinen nicht relevant sind.
Entsprechende benutzerdefinierte Optionstrings werden eingeführt, um bestimmte Textfelder6 z.B. zur Konfiguration des X-Servers zu kopieren.
Es gibt eine Reihe von Möglichkeiten, um die /etc/dhcpd.conf zu strukturieren. Zusätzlich zum ”subnet”-Statement hilft das ”group”-Statement dabei - neben der Unterteilung
nach Subnetzen - Konfigurationsblöcke mit gleichen Parametern zusammenzufassen. So
muss nicht für jeden Host die gesamte Palette wiederholt werden.
Eine Beispielkonfiguration könnte wie folgt aussehen:
option domain-name "subdomain.domain.site second.domain";
filename "/tftpboot/bootimg";
use-host-decl-names on;
default-lease-time 72000;
max-lease-time 144000;
subnet 10.16.60.0 netmask 255.255.252.0 {
option domain-name-servers 10.16.60.21, 10.16.60.100;
option ntp-servers ntps1.domain.site, ntps2.domain.site;
option font-servers fontserver.domain.site;
option x-display-manager x1.domain.site, x2.domain.site;
# option netbios-name-servers 10.16.63.252;
option routers 10.16.63.254;
option broadcast-address 10.16.63.255;
# range 10.16.60.201 10.16.60.253;
}
group {
option lpr-servers 10.16.60.2;
host dxs02 {
hardware ethernet 00:00:1C:D2:87:DF;
fixed-address 10.16.60.64; }
[...]
7.3.1
DHCP-Standardoptionen
DHCP kann aufgrund seiner Flexibilität zum zentralen Konfigurationstool avancieren. Man
kann versuchen, über diesen Dienst alle relevanten Informationen zum Betrieb von Linux
Thin-Clients zu übertragen. Neben den klassischen Parametern, wie Hostname, IP-Adresse,
Netzmaske und Gateway, zählt dazu eine Reihe von Server-IP’s: X-Display-, Time-, Swap-,
NIS-Server und weitere.
Die DHCP-Konfigurationsdatei /etc/dhcpd.conf hängt in ihrem Umfang vom Einsatzziel ab: So werden für Diskless X-Stations vielleicht eine Reihe zusätzlicher Daten, z.B.
über Informationen zum Font-, Print-, Swap- und NIS-Server übertragen, die für den XTerminalbetrieb nicht erforderlich sind.
# -- global options -default-lease-time 160000;
max-lease-time 200000;
use-host-decl-names on;
ddns-update-style none;
subnet 192.168.2.0 netmask 255.255.255.192 {
option broadcast-address 192.168.2.63;
option domain-name-servers 192.168.2.22;
option domain-name "test.site, test2.site";
option nis-domain "chnsmi20";
6
Variablentyp ”string”
98
KAPITEL 7. DHCP
option nis-servers 192.168.2.3;
option log-servers 192.168.2.4;
option netbios-name-servers 192.168.2.5;
option routers 192.168.2.1;
range 192.168.2.50 192.168.2.62;
#
}
# -- client specific -group {
host test1 {
hardware ethernet 00:80:48:C2:DD:6A;
fixed-address 192.168.2.41; }
host test2 {
hardware ethernet 00:E0:4C:39:10:21;
fixed-address 192.168.2.42; }
}
Das ”group” Statement hilft hierbei - neben der Unterteilung nach Subnetzen - Konfigurationsblöcke mit gleichen Parametern zusammenzufassen. So muss nicht für jeden Host die
gesamte Palette wiederholt werden.
Das Beispiel zeigt bereits einige typische Konfigurationsparameter des ISC-DHCPServers. Die ”default-lease-time” und ”max-lease-time” sind Ganzzahlwerte, die in Sekunden angeben, wie lange eine herausgegebene Adresse standardmäßig und maximal gültig ist.
Dieses spielt besonders eine Rolle in dynamischen Netzen mit potenziell mehr verwalteten
Maschinen als vorhandenen IP-Adressen. Mittels ”use-host-decl-names” wird gesteuert, ob
der Rechnername anhand des ”host”-Statements übermittelt oder in einer eigenen Option
definiert werden soll. Der ”ddns-update-style” bestimmt über die Zusammenarbeit mit dem
Domain Name Server. Soll keine stattfinden, weil alle Rechnernamen fest im DNS verankert
sind, wird wie im Beispiel ”none” gesetzt.
Die meisten DHCP-Optionen sind selbsterklärend. Die komplette Liste aller definierbaren Optionen kann der Manpage zu ”dhcp-options” entnommen werden. Die innerhalb
der dhcpd.conf definierten Subnetze müssen innerhalb der gültigen Netzwerkkonfiguration
des Servers liegen. Ausserhalb liegende Netze können nicht bedient werden. Innerhalb des
”subnet”-Statements legt die ”range” fest, welche Adressen im definierten Bereich dynamisch verwaltet werden. Der Server merkt sich herausgegebene IP-Adressen in einer gesonderten Datei, den dhcpd.leases, welche sich unterhalb der /var Verzeichnisstruktur in
Abhängigkeit der verwendeten Distribution befindet.
7.3.2
DHCP-DNS-Verbindung
Damit der ISC-DHCP-Server dynamische Updates im DNS-Server - es funktioniert nur die
Zusammenarbeit mit BIND - vornehmen kann, sind einige Vorbereitungen nötig. In der
Zonendefinitionsdatei /etc/named.conf habt man die Möglichkeit dieses zu konfigurieren:
acl mynetwork {
10.16.10.0/24;
127.0.0.1;
};
[ ... ]
zone "mydomain.site" in {
type master;
allow-update { WERT; };
file "master/mydomain.site";
};
zone "239.168.192.in-addr.arpa" {
7.4. BENUTZERDEFINIERTE OPTIONEN
99
type master;
file "master/10.16.10.rev";
allow-update { WERT; };
};
Dabei kann ”allow-update” verschiedene Werte annehmen: none - keine Updates sind erlaubt. 127.0.0.1 - Updates sind nur von der Maschine selbst (localhost) gestattet. ”allowupdate mynetwork; ” konfiguriert, dass aus dem eingangs definierten Quellen UpdateInformationen akzeptiert werden.
In der dhcpd.conf sollten mindestens die folgenden globalen Optionen auftauchen:
ddns-updates on;
ddns-domainname "mydomain.site";
ddns-update-style ad-hoc;
allow unknown-clients;
[ ... ]
subnet 10.16.10.0 netmask 255.255.255.0 {
range dynamic-bootp 10.10.10.10 10.16.10.250;
option subnet-mask 255.255.255.0;
option routers 10.16.10.254;
allow unknown-clients;
}
Beide Dienste müssen Sie nach erfolgter Konfiguration neu starten. Im Anschluss können
Sie beispielsweise eine Windowsmaschine eine IP-Adresse vom Server beziehen lassen. Dann
sieht man im Logfile die Interaktion von DHCP und DNS:
[ ... ]
Jan 12 21:05:52 hermes named[16798]: client 10.16.10.254#33708: updating\
zone ’mydomain.site/IN’: adding an RR
Jan 12 21:05:52 hermes named[16798]: journal file master/mydomain.site. \
zone.jnl does not exist, creating it
Jan 12 21:05:52 hermes dhcpd: if zx-spektrum.mydomain.site IN A rrset
\
doesn’t exist add zx-spektrum.mydomain.site 80000 IN A 10.16.10.250:\
success.
Jan 12 21:05:52 hermes named[16798]: client 10.16.10.254#33708: updating\
zone ’239.168.192.in-addr.arpa/IN’: deleting an rrset
Jan 12 21:05:52 hermes named[16798]: client 10.16.10.254#33708: updating\
zone ’239.168.192.in-addr.arpa/IN’: adding an RR
Jan 12 21:05:52 hermes named[16798]: journal file master/10.16.10.rev.jnl\
does not exist, creating it
[ ... ]
Vielen reicht eine Zugriffssteuerung anhand der IP-Nummer nicht. Diese kann oft zu einfach gefälscht werden. Seit einiger Zeit bietet BIND zur Absicherung sogenannte Transaction Signatures (TSIG). Sie basieren auf einer Einwege-Hashfunktion. Sie werden über die
komplette DNS-Nachricht berechnet und als Resource Record an die Nachricht angehängt.
7.4
Benutzerdefinierte Optionen
DHCP bietet die Möglichkeit bestimmte, sogenannte Vendoroptionen aufzunehmen, d.h.
es können zusätzliche Optionen zu den bereits vorhandenen definiert werden. Hierfür kann
der Codenummernbereich von 128 - 255 verwendet werden. Wenn man umfangreiche Informationen übertragen will, sollte man die Paketgröße des BOOTP-Reply-Pakets über
100
KAPITEL 7. DHCP
den Standard7 hinaus erhöhen. Die Option kann nur Ganzzahlwerte enthalten, die jedoch
die MTU-Size des Netzwerkes nicht überschreiten soll, da die meisten Clients keine fragmentierten DHCP-Antworten verarbeiten können. Diese Optionen werden zu Beginn der
Konfigurationsdateien8 des dhcpd bzw. dhclient definiert. Die folgende Liste ist eher als
Beispiel denn als vollständige Aufzählung zu verstehen, da für gegebene Aufgaben die notwendigen Felder auch völlig anders aussehen können.
# -- lot of information to be transferred -dhcp-max-message-size 1200;
# -- user defined options -option o128 code 128
= string;
option o129 code 129
= string;
option menudflts code 160
= string;
option motdline1 code 184
= string;
option menuline1 code 192
= string;
option menuline2 code 193
= string;
option menuline3 code 194
= string;
Wobei folgende Variablentypen verwendet werden können: string, integer, boolean, text, ipnumber. Diese lassen sich auch zu Arrays zusammenfassen. Das ist das klassische Verfahren,
welches für die vordefinierten Optionen für Listen von IP-Nummern zum Einsatz kommt.
Die Option 128 definiert ein ”Magic-Packet”, welches die Auswertung von Menu-Optionen
für Etherboot einschaltet. Standardwerte für die Menü-Auswahl, d.h. welches Feld nach
einem gewissen Timeout gestartet werden soll, werden mit der Option 160 festgelegt. Die
Zusammensetzung des Menüs, welches nach dem Kontakt von Etherboot mit dem DHCPServer angezeigt wird, geschieht durch die Optionen 192 und folgende. Hierbei wird für jede
Menü-Zeile ein eigenes Feld benötigt. Mittels der Option 129 sind Parameter zum Kernelstart übermittelbar, die z.B. auch den Root-Verzeichnispfad enthalten . Eine ”Message of
the day”9 kann durch das Setzen der Option 184 erfolgen.
7.5
Die Verwendung von Vendor-Code-Identifiern
Vendor-Code-Identifier sind als feste Optionen für DHCP definiert: ”vendor-class-identifier”
für die Identifizierung des Clients durch den Server und ”vendor-encapsulated-options” zur
Identifizierung des Servers seitens des Clients.
Auf diese Weise lassen sich die DHCP-Anfragen verschiedener bootender Rechner voneinander differenzieren, so dass es gelingt an eine Maschine in Abhängigkeit vom anfragenden Client verschiedene Werte für die gleiche Option zurückzuliefern. Dieses ist zwingend
notwendig, wenn PXE und Etherboot hintereinander verkettet booten sollen, da PXE zwar
die identische IP-Konfiguration erhält, aber anstelle des Kernel-Images das Etherboot-PXEImage zur Ausführung laden soll. Dieses sieht man am unten stehendem Beispiel: Es werden
bestimmte Optionen nur gesetzt bzw. die Default-Option überschrieben, wenn in der Anfrage des Clients ein bestimmter String identifiziert werden kann.
Die Interaktion mit PXE und Etherboot mittels VCI ist im folgenden Beispiel demonstriert.
# -- vendor identifier dependend settings -class "Etherboot" {
match if substring (option vendor-class-identifier,0,9)="Etherboot";
7
Die Standardgröße des Bootp-Paketes beträgt 572 Byte. Eine Erhöhung auf z.B. 1024 Byte kann durch
”dhcp-max-message-size 1024” erreicht werden.
8
üblicherweise /etc/dhcpd.conf für den Server-Dämon sowie /etc/dhclient.conf für den Client
9
Hier das Textfeld über der Menu-Auswahl
7.6. DHCP-CLIENT
101
option o128 E4:45:74:68:00:00;
option motdline1 = "Welcome to Testlabs";
option vendor-encapsulated-options 3c:09:53:74:75:64:69:6e:65:74:7a:ff;
}
class "PXEClient:" {
match if substring (option vendor-class-identifier,0,10)="PXEClient:";
filename "/nfsroot/dxs/boot/eb-3c905c.pxe";
}
[...]
host dxs03 {
hardware ethernet 00:00:B4:72:D2:4E;
if substring (option vendor-class-identifier,0,3)="PXE"
{ filename "/nfsroot/dxs/boot/rtl8139.pxe"; }
fixed-address 10.8.4.13;
}
[...]
Die ”class”-Statements zeigen globale Definitionen. Es können aber auch hostspezifische
Einstellungen getroffen werden, wie das untenstehende Beispiel zeigt.
7.6
DHCP-Client
Von schlanken Implementierungen für Embedded Devices mal abgesehen10 gibt es eigentlich
nur eine wesentliche Serverimplementierung. Dafür gibt es aber verschiedene DHCP-Clients.
Ein Client ist beim ISC-Paket dabei, das Programm dhclient. Mit den Kommandos dhcpcd, dem DHCP-Client-Daemon, und pump stehen alternative Clients zur Verfügung. Letztere verwendet man, wenn nur eine kleine Anzahl von Standardeinstellungen mittels DHCP
vorgenommen werden soll. Im Gegensatz zu dhclient, welches auf ein externes Skript zum
Anwenden der DHCP-Netzwerkkonfiguration angewiesen ist, arbeiten die beiden letztgenannten Kommandos direkt auf den betroffenen Dateien, wie z.B. auf der resolv.conf zur
Einstellung der DNS-Client-Konfiguration.
dhclient verwendet eine eigene Konfigurationsdatei. Die Konfiguration sollte passend
zum DHCP-Server erfolgen, wenn mit benutzerdefinierten Optionen gearbeitet wird. Die
Einstellungsdatei lautet /etc/dhclient.conf:
# /etc/dhclient.conf
#
send dhcp-max-message-size 1200;
send dhcp-lease-time 18000;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name;
require subnet-mask, domain-name-servers;
timeout 60;
retry 60;
reboot 10;
select-timeout 5;
initial-interval 2;
script "/sbin/dhclient-script";
dhclient schreibt, wenn er eine IP-Konfiguration von einem Server erhalten hat, die Daten
in die Datei /var/lib/dhcp/dhclient.leases:
lease {
10
”dnsmasq” ist ein solches Programm
102
KAPITEL 7. DHCP
interface "eth1";
fixed-address 10.16.10.12;
option subnet-mask 255.255.255.0;
option dhcp-lease-time 3600;
option dhcp-message-type 5;
option domain-name-servers 10.16.10.1;
option dhcp-server-identifier 10.16.10.254;
option broadcast-address 10.16.10.255;
option domain-name "mydomain.site";
renew 5 2004/12/31 16:31:33;
rebind 5 2004/12/31 17:00:14;
expire 5 2004/12/31 17:07:44;
}
Nachdem dhclient die DHCP-Informationen vom Server bezogen hat, geschieht die
Eintragung bzw. Anwendung dieser mittels dhclient-script, welches im Anhang als ShellSkript beispielhaft angeführt ist. dhclient-script wird von dhclient mittels Temporärskript
in /tmp mit allen erhaltenen Variablen gestartet. Diese werden als Shell-Variablen in der
aufrufenden Kommandozeile übergeben. Wärend es mit dhclient nicht möglich ist zwei un-
Abbildung 7.4: DHCP-Client unter Windows98
abhängige Instanzen für zwei verschiedene Ethernet-Interfaces zu starten, bietet sich dhcpcd
ethN11 für eine solche Betriebsart an. Die Lease-Datei des dhcpcd sieht etwas anders aus.
Jedoch finden sich die gleichen Konfigurationsdaten wieder:
11
ethN steht für das Interface auf dem die Anfrage geschickt werden soll, beispielsweise dhcpcd eth1 oder
dhcpcd wlan0
7.6. DHCP-CLIENT
103
IPADDR=10.16.10.12
NETMASK=255.255.255.0
NETWORK=10.16.10.0
BROADCAST=10.16.10.255
DOMAIN=’mydomain.site’
DNS=10.16.10.1
DHCPSID=10.16.10.254
DHCPGIADDR=0.0.0.0
DHCPSIADDR=10.16.10.254
DHCPCHADDR=00:0C:29:5A:B3:E0
DHCPSHADDR=00:50:56:ED:BC:96
DHCPSNAME=’’
LEASETIME=60
RENEWALTIME=720
REBINDTIME=1575
INTERFACE=’eth1’
CLASSID=’Linux 2.6.8-24.11-default i686’
CLIENTID=00:0C:29:5A:B3:E0
Hier können Admins kontrollieren, welche Daten der Client vom Server bezogen hat. dhcpcd kennt eine Reihe von Optionen, die sein Verhalten steuern:
Option
-d
-i VCID
-k
Bedeutung
Generieren von Debug-Output
Schicken eines Vendor Class Identifiers. Andere Möglichkeit
Clients anstatt mit der MAC-Adresse auseinanderzuhalten.
Schicken eines SIGHUP an laufende dhcpcd Prozesse
Tabelle 7.1: Optionen zur Steuerung des Verhaltens von dhcpcd
Abbildung 7.5: Erneuern einer Lease unter Windows-XP
Unter Windows gibt es das grafische Programm winipcfg für Windows 98/ME. Mit dem
Klick auf ”Aktualisieren” beschafft sich der Benutzer eine neue Lease vom DHCP-Server.
Die Gültigkeit und andere Daten findet man im erweiterten Bereich. ipconfig -renew in
der Kommandozeile regelt die dynamische IP-Beschaffung für die professionelleren Systeme,
wie Windows2000 und XP.
104
7.7
KAPITEL 7. DHCP
DHCP mit LDAP-Backend
In sehr großen Netzen ist die Verwaltung von sehr vielen Maschinen in einer einfachen
Textdatei (dhcpd.conf) irgendwann nicht mehr zeitgemäß. Es kommt der Wunsch auf alle
relevanten Informationen zu den einzelnen Maschinen in einer Datenbank zu verwalten. Das
Ganze sollte dann auch noch dynamisch funktionieren: Nach einem Update der Datenbank
sollte der DHCP-Server ohne Neustart mit den aktualisierten Informationen arbeiten.
Hierzu hat Brian Masney12 einen Patch für den aktuellen ISC DHCP der Version 3
gebastelt. Dieser ermöglicht eine Integration mit einem LDAP-Server. Die Struktur der
DHCP-Konfiguration eignet sich von sich aus gut mit ihren Gruppen- und Subnetz-Abschnitten in einer hierarchischen Datenbank abgebildet zu werden.
Der DHCP-Server der aktuellen SuSE-Distributionen ist bereits angepasst, bei Debian
Testing oder Unstable Releases muss der Patch noch eingefahren werden. Ob das LDAPBackend bereits Bestandteil des Servers ist, zeigt das Logfile beim Start:
Jan 12 20:47:26 s2 dhcpd: Internet Systems Consortium DHCP Server V3.0.1
[ ... ]
Jan 12 20:47:26 s2 dhcpd: Not searching LDAP since ldap-server, ldap-port
and ldap-base-dn were not specified in the config file
[ ... ]
Um dann Ihren DHCP-Server zur Zusammenarbeit mit LDAP zu motivieren, sind einige
Eintragungen in der globalen Sektion der Konfigurationsdatei notwendig. Dafür können
dann die ”subnet”, ”group” und ”host” Statements entfallen. Diese Informationen wandern
in die Datenbank.
ldap-server 10.8.4.254;
ldap-port 389;
ldap-username "cn=dhcpd,ou=users,dc=mydomain,dc=site";
ldap-password "GeheiM";
ldap-base-dn "ou=computers,dc=mydomain,dc=site";
ldap-method dynamic;
Die ersten fünf Deklarationen legen den Zugriff auf den LDAP-Server fest. IP-Nummer
oder alternativ der Rechnername und die Portnummer sind selbsterklärend. Der ”ldapusername” gibt an, mit welchem Account sich der DHCP-Server an den LDAP-Server
bindet. Dieser Account muss über entsprechende Leserechte auf dem ihm zugewiesenen
Abschnitt der Datenbank haben. Üblicherweise gehört zum LDAP-Benutzer auch ein Passwort (ldap-passwort).
Die ”ldap-base-dn” ist die Basis für Suchanfragen auf dem LDAP-Baum. Dann müssen
keine langen Distinguished Names (dn) angegeben werden, sondern der Teil in der Base kann
entfallen. Die letzte Option bestimmt mit dem Flag dynamic, dass der DHCP-Server bei
jeder Anfrage den LDAP-Server befragt. Steht hier ”static” holt er sich die Informationen
genau einmal vom LDAP-Server und kappt dann die Verbindung zu diesem.
Der LDAP-Server in der Standard-Konfiguration kennt zwar schon eine Reihe von Objektklassen, für die Daten des DHCP-Servers sind jedoch weitere notwendig, z.B. dhcpHost,
dhcpdGroup, dhcpOptions, dhcpServer, ...
Auf die Konfiguration eines LDAP-Servers wird hier nicht weiter eingegangen. Mit LDAP beschäftigt sich ein eigener Abschnitt des Skriptes.13 Für das Beispiel existiere bereits
12
http://www.newwave.net/ masneyb
Wenn dieser Teil nicht in der aktuellen Ausgabe enthalten ist, kann dieser über http://goe.net beschafft
werden.
13
7.7. DHCP MIT LDAP-BACKEND
105
ein lauffähiger Server, der für den Bereich ”dc=mydomain, dc=site” eingerichtet ist. Ein
LDIF zum Bestücken eines LDAP-Servers mit DHCP-Daten könnte so aussehen:
# Anlage eines DHCP-Servers im LDAP-Baum
dn: dc=myserver, dc=mydomain, dc=site
objectClass: top
objectClass: dhcpServer
cn: myserver.mydomain.site
dhcpServiceDN: cn=Network, dc=myserver, dc=mydomain, dc=site
# Definieren eines Knotens "Network" unterhalb dieses Servers
dn: cn=Network, dc=myserver, dc=mydomain, dc=site
cn: Network
objectClass: top
objectClass: dhcpService
objectClass: dhcpOptions
dhcpPrimaryDN: cn=myserver.mydomain.site, dc=myserver, dc=mydomain,
dc=site
dhcpOption: domain-name "myserver.mydomain.site mydomain.site"
dhcpOption: domain-name-servers 10.16.60.1,10.10.10.10
dhcpStatements: default-lease-time 21600
dhcpStatements: max-lease-time 43200
dhcpStatements: ddns-update-style ad-hoc
# Unterhalb des Knotens "Network" Eintrag für das Netz 10.16.60.0
# schaffen
dn: cn=10.16.60.0, cn=Network, dc=myserver, dc=mydomain, dc=site
cn: 10.16.60.0
objectClass: top
objectClass: dhcpSubnet
objectClass: dhcpOptions
dhcpNetMask: 24
dhcpOption: routers 10.16.60.254
dhcpOption: subnet-mask 255.255.255.0
# In diesem Netz einzelne Maschinen eintragen: ldaphost1
dn: cn=ldaphost1, cn=10.16.60.0, cn=Network, dc=myserver, dc=mydomain,
dc=site
cn: ldaphost1
objectClass: top
objectClass: dhcpHost
dhcpHWAddress: ethernet 00:c0:26:31:6a:13
dhcpStatements: fixed-address 10.16.60.11
# In diesem Netz einzelne Maschinen eintragen: ldaphost2
dn: cn=ldaphost2, cn=10.16.60.0, cn=Network, dc=myserver, dc=mydomain,
dc=site
cn: ldaphost2
objectClass: top
objectClass: dhcpHost
106
KAPITEL 7. DHCP
dhcpHWAddress: ethernet 00:c0:26:31:6a:14
dhcpStatements: fixed-address 10.16.60.12
Nach dem Neustart des DHCP-Servers sollte dieser in der Lage sein, die Daten per LDAP zu
beziehen. Für die Fehlersuche empfielt es sich die Debug-Level sowohl des LDAP-Servers als
auch des dhcpd hoch einzustellen. Aus Sicht des Autors ist die Anbindung des DHCP an LDAP nicht wirklich optimal. Die Art der Datenbank wird kaum ausgenutzt. So gibt es für alle
DHCP-Optionen ein einziges Attribut, welches letztendlich nur eine Zeile der Konfigurationsdatei ohne Semikolon speichert. Wenn in der dhcpd.conf: option domain-name-servers
10.16.60.1,192.168.10.10; stand, so steht in der LDAP-Datenbank im Attibut ”dhcpOption”: ”domain-name-servers 10.16.60.1,192.168.10.10”
In vielen Fällen würde man die Computer gerne in einer einheitlichen Liste unterhalb eines Knotens, beispielsweise ”ou=computer” verwalten14 und alle DHCP-spezifischen Daten
in einem eigenen Knoten halten. Das ist derzeitig nicht möglich. So erfüllt LDAP lediglich
die Funktion eines dynamischen Backends, kann aber nicht wirklich seine Stärken zu einer
sinnvollen Maschinenverwaltung ausspielen.
7.8
7.8.1
Aufgaben
DHCP
1) Worin besteht der Vorteil von DHCP gegenüber BOOTP? Nennen Sie einige Eigenschaften des ISC DHCPv3!
2) Bauen Sie einen DHCP-Server auf, der IP-Adressen dynamisch vergibt!
a) Wie sieht der entsprechende Eintrag in der /etc/dhcpd.conf aus?
b) Warum bekommt ein Rechner häufig dieselbe IP zugeteilt, die dieser schon einmal hatte?
Wo werden diese Informationen abgelegt?
c) Client-Seite: Verändern Sie die MAC-Adresse Ihrer Netzwerkkarte (Tip: ifconfig ethX hw
ether 00:00:B4:34:35:XY, wobei X, Y Hexadezimalzahlen sein sollten, die sich von der Wahl
der anderen Kursteilnehmer unterscheiden.) und starten Sie den Dienst zum dynamischen
Bezug von IP-Nummern neu. Warum bekommen Sie nun eine andere IP als vorher zugeteilt?
3) Wenn man sehr viele Daten (z.B. eine grosse Reihe von Server-IP-Nummern) übergeben
möchte, könnte der Platz im DHCP-Antwort-Paket nicht mehr ausreichen. Wäre es sinnvoll
deshalb TCP statt UDP einzusetzen, um eine gesicherte Übertragung mehrerer Pakete zu
erreichen? Welche anderen Möglichkeiten gibt es noch?
4) Nennen Sie verschiedene Hierarchielevel der definierten Optionen! Welche Level überschreiben welche? Wozu kann dieses nützlich sein?
14
Siehe das Beispiel Samba-LDAP für PDC
Kapitel 8
DNS
8.1
Einstieg
Das Domain Name System (DNS) hatte es zu Zeiten des Internet-Booms bis in die Hauptnachrichten geschafft: Immer dann, wenn es juristische Auseinandersetzungen über bekannte Namen und Marken gab. Wenn jemand im Internet was zu Göttingen sucht, probiert
er es am besten unter dem Namen der Stadt, also www.goettingen.de. Keiner kennt die
IP-Adresse des Auftritts - 134.76.251.205.
Auch wenn es an der gerichtlichen Front ruhiger geworden ist, kommen täglich neue
Domains hinzu. Viele haben sich vielleicht schon vor einiger Zeit eine eigene Webpräsenz
mit eigenem Namen bei irgendeinem Provider einrichten lassen oder denken darüber nach
eine Domain zu registrieren. Man frage einfach mal im eigenen Umfeld herum - bestimmt
finden sich Bekannte und Verwandte als Inhaber einer Internet-Domain.
Ebenfalls erweitert sich die Zahl der sogenannten Toplevel-Domains ständig. So ist die
Landes-Toplevel-Domain de die weltweit zweitgrößte nach der generischen Domain com.
Irgendjemand muss diese ganzen Namen auch verwalten. Darum kümmert sich der Domain
Name Server. Auch für diese Aufgabe bietet sich Linux an.
8.1.1
Enstehungsgeschichte
DNS ist inzwischen untrennbar mit dem Internet verknüpft. Rechner im weltweiten Internet werden in der überwiegenden Zahl über ihren Namen und nicht über ihre IP-Adresse
angesprochen. Es ist jedoch so, dass das Internet-Protokoll ohne Probleme ohne DNS klarkommt, DNS jedoch als Dienst direkt auf IP angewiesen ist.
Menschen können sich schliesslich Namen besser merken als Telefonnummern. Wenn
auch das Beispiel sich nicht direkt übertragen lässt, zeigt es die Bedeutung. Jeder kennt
www.google.de. Kaum aber jemand weiss, dass beim Ansurfen der Seite aus Deutschland1
der Browser eine Verbindung zu IP 66.102.9.99 oder 66.102.9.104 aufbaut. Wer wissen
möchte, wie der Browser den Namen zur Adresse mit Hilfe der Systembibliotheken auflöst,
gibt einfachmal das Kommando host ein.
dirk@linux:~> host www.google.de
www.google.de is an alias for www.google.com.
www.google.com is an alias for www.google.akadns.net.
www.google.akadns.net has address 66.102.9.99
www.google.akadns.net has address 66.102.9.104
Das Netz kann aber ausschliesslich mit Binäradressen umgehen - auch die besser lesbare
Dotted Quad Notation aus dem Beispiel ist nur eine Übersetzung für den menschlichen
1
je nach Provider, da es oft erstmal ein Proxy ist
107
108
KAPITEL 8. DNS
Benutzer. Deshalb wird ein System für die Zuordnung von Namen zu Adressen - und umgekehrt benötigt. Am Anfang ging es mit einer einfachen Textdatei los. Diese Textdatei gibt
es immer noch. In kleinen Netzen oder zu Zeiten in denen Ihre Maschine keine Netzwerkverbindung zu einem DNS-Server hat, soll sie trotzdem Namen und IPs zuordnen können:
# /etc/hosts
# Syntax:
# IP-Address
::1
fe00::0
ff00::0
ff02::1
ff02::2
Full-Qualified-Hostname Short-HostnamePv6 addresses
ipv6-localhost ipv6-loopback
ipv6-localnet
ipv6-mcastprefix
ipv6-allnodes
ipv6-allrouters
127.0.0.1 localhost
10.8.4.101 dionysos.mydomain.site dionysos
# resolv other machines without DNS
10.8.4.205
aphrodite.wg.site
10.8.4.206
athene.wg.site
[ ... ]
10.8.4.250
thetis.wg.site
aphrodite
athene
thetis
Üblicherweise steht da nur noch die eigene Maschine drin, im Beispiel dionysos. Diese Einstellung landet in dieser Datei, wenn man die Maschine mit dem Installationstool der gerade verwendeten Distribution einrichtet Alle anderen Einträge gelten für spezielle Adressen,
wie das lokale Loopback (127.0.0.1). In einem kleinen Netzwerk, in dem sich wenig ändert,
könnte man einfach weitere Rechner in diese Datei eintragen und diese anschliessend auf
alle Maschinen verteilen. Im Beispiel lassen sich so aphrodite, athene ... ohne Zurhilfenahme
von DNS auflösen.
Da gehen dann schnell die Probleme los: Nicht immer sind alle Rechner gleichzeitig
an. Dann ist die Verteilung unvollständig. Bei häufigen Updates steigt mit der Zahl der
Rechner und der Einträge die Fehlerwahrscheinlichkeit und ziemlich schnell hat der Admin
keine Lust mehr. Das ging den Betreibern der frühen IP-Netze genau so. Das frühe Internet
bestand aus wenigen Hosts und die Administratoren dieser Maschinen kannten sich alle
persönlich.
Das hörte mit der steigenden Zahl vernetzter Rechner irgendwann auf. Das Konzept
einer einzigen ”flachen” Datei liess nicht mehr aufrecht erhalten. Fragen der Übersichtlichkeit, Ausfallsicherheit und Redundanz liessen sich mit dem Dateikonzept nicht überzeugend
lösen. Ein weiteres Problem tritt auf, wenn die User in gewissem Rahmen ihre Rechnernamen selbst verwalten wollen.
Informatiker an der University of California in Berkeley machten sich Gedanken, wie sich
das Problem lösen liesse. Das neue System sollte dabei dezentral verteilt, ausfallsicher sein
und die Datenbestände schnell konvergieren. Die Berkeley Internet Name Domain Software
- daher der Name BIND - ist der Standard auf den meisten Linux-/Unix-Systemen. Die
Software ist OpenSource und derzeit in der Version 9.X verfügbar. Die aktuelle Version
verrät einem das Kommando /usr/sbin/named -v.
DNS war nicht der einzige Versuch. Viele Admins kennen sicherlich WIN¿, das Windows Name System. Dieses kann im P2P- oder Servermodus arbeiten, kennt aber nur eine
flache Namenshierarchie, welche in früheren Versionen auf 255 Maschinen beschränkt war.
WINS ist ein System für LANs - ohne große Benutzereingriffe verständigen sich die beteiligten Maschinen über ihre Namen. Sie verursachen dabei aber einen nicht unerheblichen
8.1. EINSTIEG
109
Netzwerkverkehr. Mit Windows2000 und dem Active Directory, welches als unterliegende
Struktur DNS verwendet, verliert WINS weiter an Bedeutung.
8.1.2
DNS - Das virtuelle IP-Telefonbuch
DNS ist ein hierarchisches System mit einer einzigen gemeinsamen Wurzel. Diese wird durch
einen Punkt ”.” symbolisiert. Dann folgen die sogenannten Toplevel-Domains. Hiervon gibt
es zwei Typen: generische Domains und Länderkürzel. Die generischen Toplevel Domains,
wie org, gov, com, mil, arpa und edu wurden schon im Herbst 1984 vorgeschlagen. net folgte
ein Jahr später. Hinzu kamen auf dem obersten Level die zweibuchstabigen Länderkürzel
nach ISO 3166. Eine vollständige Liste ist unter [1] erhältlich. Unterhalb dieser Hierarchiestufe kann man selbst, Organisationen oder Firmen Domains registrieren. Ab den folgenden
Hierarchiestufen habt der Admin dann fast volle Freiheit, wenn er sich nur an die Benennungsstandards hält.
Das Konzept des umgekehrten hierarchischen Baumes kennt man von den gängigen
Dateisystemen her. Verfolgt man einen Pfad von Wurzel zu einem Knoten, so ergibt sich
der jeweilige Verzeichnis- bzw. Dateinamen. Die einzelnen Ebenen werden beispielsweise
bei Unix durch einen Schrägstrich (/), durch einen Backslash () bei Windows voneinander getrennt. Diese Struktur findet sich in weiteren Bereichen. Telefonnummern folgen international einem ähnlichen Prinzip: Zuerst findet man den Ländercode (+49), dann die
Orts-Vorwahl (551) und schliesslich die Anschlussnummer (654321).
Genauso setzt sich der komplette Rechnername2 aus mehreren Teilen zusammen. Ausser
dass als Trennelement der einzelnen Ebenen der Punkt (.) verwendet wird. Anders als in
den beiden vorgenannten Beispielen dreht sich die Reihenfolge von Allgemein zu Speziell
um: Der Rechnername steht links, gefolgt von den Zwischenebenen bis zur Wurzel, die
rechts steht. So ist beispielsweise in www.goe.net ”www” ein Name für einen konkreten
Rechner. Dieser Rechner ist Mitglied in der Second-Level-Domain ”goe”, die unterhalb der
Toplevel-Domain ”net” registriert wurde.
8.1.3
Regeln für die Namensgebung
Damit am Ende die selbstgetauften Rechner der eigenen Domain im weltweiten Netz auch
gefunden werden können, geht es nicht ohne Standards ab. Für die Zusammensetzung eines
gültigen FQDN gelten einige Regeln:
• Jeder Teilname (label) umfasst maximal 63 Zeichen. Es muss mindestens ein Buchstabe enthalten sein, damit ein Verwechseln mit IP-Adressen ausgeschlossen wird.
• Die Gesamtlänge des FQDN darf 255 Zeichen inklusive der Punkte nicht überschreiten.
• Erlaubt sind die alphanumerischen Zeichen 0-9 und a-z. Groß- und Kleinschreibung
spielt keine Rolle. Zusätzlich möglich ist die Verwendung des Bindestrichs ”-”. Er
kann im Gegensatz zu den anderen Zeichen nicht am Anfang oder Ende eines Namens stehen. Inzwischen sind auch Umlaute im Namen erlaubt. Hierfür gelten jedoch
spezielle Regeln.
• Jeder FQDN endet mit einem Punkt. Das macht normalerweise keiner und ist ausserhalb der Zonendateien des BIND auch kein Problem.
2
in der Fachsprache mit FQDN - Full Qualified Domain Name bezeichnet
110
KAPITEL 8. DNS
Für Umlautdomains, sogenannte International Domain Names (IDN) wird die sogenannte
ACE-Umschrift verwendet. Anwender geben in ihrem Browser beispielsweise jörg.hänßler.de
ein. Diesen String wandelt der Browser dann intern in ACE für die Abfrage an den Nameserver um. Das Ergebnis des Beispiels sieht dann so aus xn–jrg-sna.xn–hnssler-5wa.de.
Viele Web-Browser beherrschen inzwischen den Umgang mit IDN, viele andere ClientProgramme jedoch nicht. So liefert zwar www.müller.de ein Ergebnis im Konqueror, ein
ping www.müller.de jedoch nur ein lapidares ”unknown host www.müller.de”.
Ein ping auf die ACE-Umschrift (hier www.xn–mller-kva.de) klappt natürlich. Die Längenbegrenzung des Teilstrings bleibt bestehen. So können Umlautdomains nicht die Länge
von 63 Zeichen erreichen, da noch Platz für die Umschrift einzuplanen ist.
Für nicht öffentliche Netze ist man nicht zwangsläufig an vorgegebene Toplevel-Domains
gebunden, man kann sich einfach eine aussuchen. Wenn man jedoch für sein privates Netz
einfach eine offizielle Domain wählt, wie beispielsweise testnetz.de, dann könnten Nutzer
verwirrt werden. Sie würden dann unter Umständen versucht sein, diese Domain auch von
anderen Orten als dem eigenen privaten nach aussen abgeschotteten Netz zu erreichen.
Ein Name, wie hermes.wg.site macht durch den Toplevel ”.site” klar, dass es diese Domain
nicht offiziell gibt. Bis vor einiger Zeit war stattdessen die Pseudo-Toplevel-Domain ”.local”
Quasistandard. Sie ist aber für selbstkonfigurierende lokale Netze3 gedacht
8.1.4
Registrieren und Verwalten von Domains
Organisationen, Privatpersonen, Firmen registrieren immer eine Second-Level-Domain, die
unterhalb einer dieser Toplevel-Namen liegt. Mit der Registrierung beispielsweise von ”goe”
unterhalb von ”net” wurde dem Autor die Domain goe.net zugeordnet. Damit folgt nicht
automatisch auch die Existenz von Domains, wie goe.org oder das Nutzungsrecht darauf. So
musste beispielsweise die Firma Google die verschiedenen Domains google.com, google.net,
google.de oder google.us einzeln registrieren. Die Abbildung zeigt einen symbolischen Auscountry
generic
Toplevel
Domains
de
fr
Second Level
Domains
gwdg
net mil
uk
goe
org
com
kernel
edu
google
uni-freiburg
ftp
www
www
ftp
www
ftp
www
linux
ks
Part of Domain Name Space
www
Abbildung 8.1: Ausschnitt aus dem Namensraum
schnitt aus dem DNS-Namensraum des Internets. Neben den ursprünglich festgelegten dreibuchstabigen generischen Toplevel-Domains und den Länderkürzeln sind in jüngster Zeit
weitere Domain-Endungen hinzugekommen. Durch die Moderation von ICANN wurden
weitere Toplevel-Domains vorgeschlagen: aero, biz, coop, info, museum, name, pro oder eu.
Unterhalb dieser neuen Toplevel-Domains können zum Teil schon (mindestens info, biz,
name) Domains über verschiedene Registrare eingetragen werden.
3
Apple nennt diesen Dienst Rendevouz. Unter Linux gibt es dafür den mdnsd Dienst, der dynamisches
DNS in lokalen Netzen bereitstellt.
8.2. IMPLEMENTATION
111
Für die einzelnen Toplevel-Domains ist nicht eine Organisation oder Firma zuständig.
Für die Toplevel-Domain de regelt dieses DENIC. Sie ist eine eingetragene Genossenschaft.
In ihr sind beispielsweise große Internet-Service-Provider und Diensteanbieter Mitglied.
Diese können im Auftrag ihrer Kunden Domains registrieren. Die Informationen wem eine
Domain gehört, wer für den Betrieb des Nameservers dieser Domain zuständig ist und
weitere Daten sind in der sogenannten whois-Datenbank gespeichert. Früher liessen sich
diese Informationen per Kommandozeilen-Tool direkt abfragen, nun geht es nur noch über
die Webschnittstellen der Registrare oder auch direkt bei www.denic.de. Domain-Inhaber,
administrativer oder technischer Ansprechpartner und Zonenverwalter können durchaus
verschiedene Personen sein.
Die meisten Registrare stellen zwei Möglichkeiten zur Verfügung eine Domain zu ”konnektieren”, d.h. im Internet erreichbar zu machen. Der übliche Weg ist die ”Delegation”.
Das bedeutet, dass in den DENIC-Datenbanken die Adressen von mindestens zwei (maximal fünf) Nameservern vermerkt werden. Üblicherweise stellen die Registrare bei der Ersteintragung von Nameservern sicher, dass diese funktionieren. Die Daten des zugehörigen
SOA-Records (SOA=Start Of Authority) des Nameservers sollten ich deshalb in folgendem Spektrum bewegen (Angaben in Sekunden): Eine alternative Möglichkeit eine Domain
Variable
refresh
retry
expire
ttl
Geforderte Zeiten in Sekunden
10000 - 86400
1800 -28800
604800 - 3600000
180 - 345600
Tabelle 8.1: Einstellungen im SOA
zu konnektieren besteht darin, dass auf dem Nameserver des Registrars ein bis zu einige
”Dienste”, die mit dieser Domain zusammenhängen direkt eingetragen werden. So können
beispielsweise www.¡Name der Domain¿.de oder ftp.¡Name der Domain¿.de direkt mit einer
IP-Adresse registriert werden. Dieses Verfahren wird als Konnektierung mittels NSentryEinträgen bezeichnet. Das spart den eigenen Nameserver und macht bei kleinen Domains
mit wenigen Diensten Sinn.
8.2
Implementation
Ein Nameserver ist niemals für das gesamte Internet verantwortlich, sondern verwaltet lediglich einen Teil des Namensraumes. Bevor es jedoch um die Frage geht, welcher Nameserver
sich um welchen Bereich des Namensraumes kümmert, sind einige Begriffe zu klären. Bisher kam der Ausdruck ”Domain”, deutsch ”Domäne” schon häufiger vor. Diesen sollte man
nicht mit einer (Windows-)NT-Domäne verwechseln. Eine solche fasst auch Gruppen von
Rechnern organisatorisch zusammen. Es stecken jedoch komplett andere Prinzipien hinter
einer DNS- oder Windows-Domain.
8.2.1
Nameserver und Zuständigkeiten
Bezogen auf den DNS-Namensraum ist ein Domain ein Knoten des Baumes mit allen darunter folgenden Verzweigungen. So sind die Maschinen ftp.uni-freiburg.de und www.ks.unifreiburg.de Teile der Domain uni-freiburg.de. Die Rechner mit der gemeinsamen Domain
können, müssen aber nicht in einem gemeinsamen IP-Subnetz liegen. Sie haben auch sonst
nicht viel gemein oder müssen in irgendeiner weitergehenden Beziehung zueinander stehen.
112
KAPITEL 8. DNS
Im Beispiel stehen der Rechner ftp.uni-freiburg.de und die Subdomain ks.uni-freiburg.de auf
einer Hierarchiestufe. Unterhalb von ”ks” können wiederum Rechner (im Beispiel ”www”)
eingetragen sein oder weitere Subdomains folgen. Der Begriff Domian ist eine Frage der Organisation: ”Welche Hosts beinhaltet die DNS-Domain D?” oder ”Unter welcher Domain
ist die Person P oder Organisation O erreichbar?”
Ist man nun für eine solche Domain zuständig oder deren Eigentümer, betreibt man
einen Nameserver. In diesem kann man dann beliebige Rechnernamen eintragen oder SubDomains festlegen. So ist ks.uni-freiburg.de eine Subdomain von uni-freiburg.de. Wenn man
sich diese Organisation näher anschaut, stellt man fest, dass die Domainnames hierarchisch
aufgebaut sind. Trotzdem ist nur ein Nameserver für diese Domain verantwortlich. Dieser Nameserver ist ”autoritativ”. Die bis zu vier weiteren Nameserver, die man bei der
Registrierung angeben kann, erfüllen Backup- und Redundanzfunktionen.
Ein zentrales Konzept des DNS ist die Delegation. Die hierarchische Struktur des DNS
erlaubt die Verteilung von Informationen. Das hat einige Vorteile: Die Daten werden an den
Stellen gepflegt, wo sie bekannt sind. Oft kommunizieren in lokalen Netzen gerade die lokalen Maschinen direkt miteinander. Namensanfragen können direkt vor Ort mit kürzester
Verzögerung beantwortet werden. Durch Delegation wird die Autorität für Subdomains auf
andere Nameserver übertragen. Das passiert bei der Registrierung einer DE-Domain beim
DENIC, wenn man eigene Nameserver angibt. Die neu eingetragene Domain ist eine Subdomain von DE. Bei der Delegation kann der Administrator entscheiden, welche Bereiche
seiner Domain auf andere Nameserver übertragen werden sollen. In solchen Fällen spricht
man von Zonen. Eine Zone ist allein durch Delegation definiert. Dieser Begriff bezeichnet
deshalb meist die physikalischen Realisierung. An der Universität Freiburg ist beispielsweise die Subdomain informatik.uni-freiburg.de an einen eigenen Nameserver delegiert. Alles
innerhalb dieser Subdomain bildet eine eigene Zone. Die Subdomain ks.uni-freiburg.de wird
auf dem zentralen Nameserver der Domain uni-freiburg.de verwaltet. ”ks” ist also Bestandteil der Zone uni-freiburg.de.
Die Nameserver der Domain uni-freiburg.de wissen um ihre Schäfchen oder kennen jemanden, der um Teilmengen weiss (delegierte Subdomains). Was ist aber, wenn ganz allgemein irgendeine Domain aufgelöst werden soll? Die oberste Ebene bei den Nameservern
bilden die sogenannten Root-Nameserver. Sie sind gleichzeitig autoritativ für die Top Level
Domains. Diese kennen wiederum die verantwortlichen Nameserver für die zweite Ebene,
z.B. goe.net oder uni-goettingen.de. Soll ein beliebiger Hostnamen aufgelöst werden, kommt
einer der Root-Nameserver ins Spiel. Nur dieser kennt den autoritativen Nameserver der
Second-Level Ebene. Die Erreichbarkeit der Root-Nameserver ist zentrales Element des
DNS. Ein Ausfall dieser zentralen Maschinen hätte katastrophale Auswirkungen auf die
Funktion des Internets. Diese mag dann zwar immer noch wie vorher funktionieren. Aber
in dem Augenblick, wo IP-Adressen nicht mehr von Namen ermittelt werden können, ist
die Kommunikation schnell nicht mehr möglich. Deshalb werden Root-Nameserver durch
Caching entlastet und arbeiten ausschliesslich iterativ.
Bisher ging es immer um die Auflösung von Namen zu IP-Adressen. Im Beispiel oben
wurde auch schon kurz der umgekehrte Fall angesprochen. Was macht man aber, wenn man
die IP-Adresse kennt und den zugehörigen Hostnamen oder die Domain wissen möchte?
IP-Adressen in der ”dotted-quad-notation”, also sowas wie 134.76.60.86 ähneln sich vom
Aufbau her den Domainnames. Das gilt ebenfalls für eine gewisse Hierarchie (solange die
Subnetzaufteilung entlang der Punkte erfolgt) der IP-Adressen: 134.76.0.0 ist als IP-Netz
an die Universität Göttingen zugewiesen. Innerhalb dieses Netzes lassen sich beispielsweise
Subnetze der Form 134.76.0.0 - 134.76.255.0 festlegen.
Das wird einfach dazu benutzt auch für die umgekehrte Auflösung das Konzept der hier-
8.3. DNS-SERVER MIT LINUX
113
archischen Datenbank und Delegation zu nutzen. Es stößt aber schneller an seine Grenzen
in dem Augenblick, wo ein Netz der Form 134.76.60.0/255.255.255.0 in mehrere Teilnetze
aufgeteilt werden soll, die unterschiedlichen Subdomains zugeordnet sind.
8.2.2
Caching
Nameserver können selbstständig Anfragen weiterleiten, falls sie nicht selbst für die nachgefragte Zone autoritativ sind. Trotzdem ist es in den meisten Fällen ineffektiv, wenn bei
gleichen Anfragen jedes Mal eine Weiterleitung erfolgt. Deshalb speichert der Server Namensauflösungen für eine gewisse Zeit zwischen (Caching). Die Aufbewahrungsdauer für
einen Eintrag ist jedoch nicht trivial zu bestimmen. Es gibt Server deren IP-Adressen sich
jahrelang nicht ändern. Es gibt aber auch Maschinen, die beispielsweise per DHCP eine dynamische Adresse beziehen und nur für eine gewisse (kurze) Zeit aktiv sind. Oder
Site-Betreiber nutzen DNS zur Lastverteilung verschiedene Server und reichen deshalb verschiedene IPs für dieselbe Adresse heraus4 .
Wie lange dieser Eintrag beibehalten werden soll, legt der verantwortliche Serverbetreiber der Zone mit der Time-To-Live (TTL) fest. Welche Möglichkeiten einem hier zur
Verfügung stehen, klärt der Abschnitt zur Einrichtung eines BIND DNS-Servers. Darüber
hinaus merkt sich der anfragende Server den autoritativen Nameserver für die jeweiligen
Zonen. So vermeidet er, dass bei der Auflösung nicht alle Instanzen der Hierarchie durchlaufen werden müssen. Das hat den Vorteil bei unterschiedlichen Hosts der gleichen Zone
sofort der verantwortlichen Server zu kennen. DNS kennt auch negatives Caching: In diesem Fall werden nicht existierende FQDN für einen bestimmten Zeitraum gemerkt, damit
nicht jedes Mal auf ein Timeout gewartet werden muss - diese Zeit wird allerdings vom
ursprünglich befragten Nameserver selbst vorgegeben.
8.2.3
Primärer und sekundäre Nameserver
Beim Entwurf von DNS wurde sehr viel Wert auf Ausfallsicherheit gelegt. Aus diesem
Grund ist es üblich, statt eines einzigen gleich mehrere Nameserver für eine Zone zu betreiben. Sekundäre Nameserver werden bei Änderungen der Zonendaten durch den primären
benachrichtigt. Sie holen sich dann die aktuellen Zoneninformationen (Zonentransfer). Generell gilt: Es gibt immer nur ein primärer aber bis zu vier sekundäre Nameserver.
Heute haben sich allerdings für den primären Master-Nameserver die Bezeichnung Master und für die sekundären Master-Nameserver die Bezeichnung Slaves durchgesetzt. ”Slave”
klingt etwas nachgeordnet. Trotzdem verbirgt sich hinter dieser Bezeichnung ein vollwertiger Nameserver. Da ein einzelner physikalischer Nameserver sowohl Master als auch Slave
für unterschiedliche Zonen sein kann, ist diese Unterscheidung nicht immer eindeutig.
8.3
DNS-Server mit Linux
Nameserver gehören zu den wichtigsten Diensten des Internets. Anders als Webserver agieren sie jedoch im Hintergrund. Wer irgendwelche Dienste im Netz anbietet, ist nicht nur
darauf angewiesen, dass der Webauftritt attraktiv gestaltet ist und die Wartezeiten kurz
sind, sondern auch, dass der Server überhaupt gefunden wird. Damit ist nicht der Eintrag
in Suchmaschinen gemeint, sondern die Auflösung des Domain-Namens in eine IP-Adresse.
Für eine ganze Reihe von Anwendungen, wie Mail ist auch die umgekehrte Auflögung von
einer IP zu einem FQDN erwünscht.
4
siehe das Eingangsbeispiel für google.de
114
KAPITEL 8. DNS
Ein Großteil der weltweiten DNS-Server laufen inzwischen auf einer Kombination von
Linux und BIND. Bind9 besteht aus mehreren Paketen und ist für alle aktuellen LinuxDistributionen verfügbar.
8.3.1
Der Dämon
Üblicherweise wird für den DNS der Bind verwendet. Der Dienst, der später als Daemon
im Hintergrund läuft heisst named. Das dazugehörige Startskript /etc/init.d/bind9 unter
Debian und /etc/init.d/named für anderen Distributionen. Oft findet man noch weitere
Dateien im Sysconfig- oder Defaultsverzeichnis, die das Verhalten des Daemons steuern,
ihn beispielsweise mit einer anderen UserID als ”root” starten. Konfiguriert wird der named durch die /etc/named.conf bzw. /etc/bind/named.conf. Im folgenden bezieht sich die
Beschreibung auf eine Debian-Installation.5
named.conf ist die zentrale Konfiguration zum Verhalten des Servers und der Definition
der verschiedenen Master- und Slave-Zonen. Die Server-Optionen sind für die bessere Übersichtlichkeit in eine weitere Datei named.conf.options oder ähnliche ausgelagert. In dieser
Datei kann man beispielsweise die Forwarder definieren und ACLs für den Zugriff auf den
Server festlegen.
Auf diese Weise legt beispielsweise das Keyword ”listen-on” für das üblicherweise benutzte IPv4 fest, auf welchem Port und auf welchen IP-Adressen der Server auf Anfragen
lauscht. So läßt verhindern, dass ein lediglich interner Server, der auf einem Gateway läuft
auch für externe Anfragen offen ist. So können Angreifer nicht per DNS erfahren, wie das interne Netz strukturiert sein könnte. Statt der Angaben von IP-Adressen oder Netzen lassen
sich vor dem ”options”-Block auch Access Control Lists (ACLs) definieren: acl localnet
10.8.4.0/24; 10.8.10.0/24; ; Diese trägt man dann direkt ein: listen-on port 53 localnet; ; Das Keyword ”listen-on-v6” regelt das Ganze für IPv6.
”forwarders” definiert eine Liste von Servern, an die Anfragen weitergeleitet werden,
wenn der Server diese nicht selbst beantworten kann. So kann man vom Cache Ihres Internetproviders profitieren. Normalerweise sucht ein Nameserver das Internet rekursiv ab,
bis er die gesuchte Antwort findet. Durch diese Option wird stets der Nameserver Ihres
Internetproviders zuerst befragt. Wenn es sich dabei um einen schnellen, viel benutzten
Nameserver handelt, kann dies zu einer Geschwindigkeitssteigerung führen.
; /etc/bind/named.conf
include "/etc/bind/named.conf.options";
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
5
Andere Distributionen legen die Konfigurationsdateien und Daten oft woanders ab, beispielsweise unterhalb von /var/lib/named. Wenn man sich an der named.conf orientiert, findet man alle weiteren Dateien
schnell, weshalb in der Darstellung nicht weiter auf Spezialitäten einzelner Distributionen eingegangen wird.
8.3. DNS-SERVER MIT LINUX
115
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
include "/etc/bind/named.conf.local";
In der named.conf sind eine Reihe spezieller Zonen bereits definiert. So enthält die Datei
db.root die Liste aller 16 Root-Nameserver. Ein Großteil dieser Maschinen steht in den USA,
einige in Europa und eine Maschine in Japan. Ihre IP-Adressen sind fix. Diese Server werden
iterativ befragt, wenn der eigene DNS eine Adresse nicht auflösen kann. Die Zone ”.” ist
deshalb vom Typ ”hint” - der Nameserver ist für diese Zone nicht authoritativ, erfährt hier
aber, wo er weiterfragen kann.
Weiterhin gibt es einige spezielle Zonen, wie localhost oder ”127.in-addr.arpa”. Für diese
Zonen ist ein Server immer authoritativ. Das verhindert, dass von schlecht konfigurierten
Maschinen Anfragen auf einen Namen wie localhost oder eine IP aus 127.0.0.0/255.0.0.0
überhaupt ins Netz gelangen. Jeder Rechner mit installiertem IP-Stack hat auf dem Loopback-Interface üblicherweise die IP-Adresse 127.0.0.1 definiert. Auch mit solchen Anfragen
sollten keine entfernten Nameserver behelligt werden. Das gilt ebenfalls für IP-Adressen, die
mit einer 06 und mit 255 beginnen. So fangen die lokale Broadcast-Adresse oder die meisten
Netzmasken an. Alle diese speziellen Zonenfiles werden bei der Installation automatisch
angelegt.
Die eigenen Zonen definieren Sie der Übersichtlichkeit halber am besten in der Datei
/etc/bind/named.conf.local oder dem Konzept der gewählten Distribution entsprechend.
8.3.2
Die DNS-Datenbank
Es gibt zwei Arten von Zonen: Für die Master-Zonen ist der Server authoritativ, die SlaveZonen kopiert er definiert durch die Update-Festsetzungen vom für die Zone authoritativen
Server.
zone "wg.site" in {
type master;
file "/etc/bind/db.wg.site";
allow-update { 127.0.0.1; 10.8.4.254; };
};
zone "4.8.10.in-addr.arpa" in {
type master;
file "/etc/bind/db.10.8.4";
allow-update { 127.0.0.1; 10.8.4.254; };
};
Die DNS-Datenbanken enthalten recht unterschiedliche Einträge: Zum einen muss eine
Auflösung von FQDN in Richtung IP-Adressen und umgekehrt möglich sein, weiterhin
sollten Informationen zu Nameservern vermerkt sein. Unter Umständen legt man ebenfalls Zonenfiles für die Rückwärtsauflösung von IPv6-Adressen und Telefonnummern nach
ENUM an.
Die Informationseinheit in einer DNS-Datenbank wird Resource Record (RR) genannt.
Zu jedem Eintrag korrespondiert ein Typ, der die Art der enthaltenen Daten beschreibt, und
eine Klasse, die den Netzwerktyp beschreibt, für den der Record gilt. Der Prototyp eines
RR ist der A-Record, bei dem ein voll qualifizierter Domainname mit einer IP-Adresse
assoziiert ist.
6
0.0.0.0 ist eine spezielle Adresse zur DHCP-Anfrage
116
KAPITEL 8. DNS
Wie bereits erwähnt wurde, ist es möglich einem Host mehr als einen Namen zuzuordnen
(Aliasing). Einer dieser Namen ist der offizielle Hostname, während alle weiteren nur Aliase
sind, die mit dem offiziellen Namen verknüpft werden. Der Unterschied in der Eintragung
liegt in der Bezeichnung: Der kanonische Hostname besitzt einen A-Record, während die
anderen nur einen Record vom Typ CNAME verwenden.
Ein Beispieleintrag für die Auflösung von Hostnamen nach IP-Nummern:
; /etc/bind/wg.site
$TTL 360
; 6 minutes
@
IN SOA
IN NS
10 mail.wg.site.
IN MX
ns
IN A
nameserver
IN CNAME
$TTL 86400
; 1 day
mail
IN A
mail-backup
IN A
anphrodite
IN A
dionysos
IN A
$TTL 360
; 6 minutes
demeter
IN A
hermes
IN A
IN HINFO
IN TXT
ns.wg.site. dirk.wg.site. (
2005011002 ; serial
28800
; refresh (8 hours)
1800
; retry (30 minutes)
3600000
; expire (5 weeks 6 days \
16 hours)
86400
; minimum (1 day)
)
ns.wg.site.
IN MX
20 mail-backup.wg.site.
10.8.4.25
ns
10.8.4.21
10.8.4.22
10.8.4.203
10.8.4.204
10.8.4.251
10.8.4.252
"AMD Opteron" "Linux"
"WG-DNS for PE28"
In den Zonendateien ist jeder mit einem Punkt ”.” endende Rechnername ein exakter Rechnername. Alles, was ohne den abschließenden Punkt geschrieben wird, bezieht sich auf den
Ursprung (hier wg.site). Damit würde aus dem Namen ns.wg.site für BIND ns.wg.site.wg.site
werden, sicherlich nicht die Intention des Zonenadmins.
hermes steht daher für ”hermes.Ursprung”. In der Beispielzonendatei ist wg.site. der Ursprung, damit wird aus hermes hermes.wg.site.
Ein Beispieleintrag für die umgekehrte Auflösung:
$TTL 360
@
254
$TTL 86400
21
22
203
; 6 minutes
IN SOA ns.wg.site. dirk.goe.net. (
2005011002 ; serial
28800
; refresh (8 hours)
1800
; retry (30 minutes)
3600000
; expire (5 weeks 6 days 16 hours)
86400
; minimum (1 day)
)
IN NS
ns.wg.site.
IN PTR ns.wg.site.
; 1 day
IN PTR mail.wg.site.
IN PTR mail-backup.wg.site.
IN PTR aphrodite.wg.site.
8.3. DNS-SERVER MIT LINUX
204
$TTL 360
251
252
117
IN PTR dionysos.wg.site.
; 6 minutes
IN PTR demeter.wg.site.
IN PTR hermes.wg.site.
TTL gibt die Lebensdauer aller Einträge in der Zone an, die kein ausdrückliches TTL
besitzen, welches vor dem IN als Integer-Sekunden-Wert eingetragen werden würde.
8.3.3
Starten und Anhalten des Nameservers
Nachdem Sie Ihre Zonendateien für die Vorwärts- und Rückwärtsauflösung angelegt und
diese in der named.conf(.local) eingetragen haben, steht nun der Start des Servers an:
linux04:/etc/bind# /etc/init.d/bind9 start
Das Stoppen des Dienstes oder den Neustart regeln Sie entsprechend über ”stop” oder
”restart”. Eventuell auftretende Fehlermeldungen liefert named in der Datei /var/log/syslog
ab. Hier überprüft man, ob alle Ihre Zonenfiles ohne Beschwerden akzeptiert wurden. Im
Logfile liefert named Informationen auf welchen Interfaces er lauscht, wieviele Prozessoren er
in Anspruch nimmt und welche Zonenfiles er erfolgreich eingelesen hat. Wenn Sie den Dienst
automatisch beim Hochfahren der Maschine starten wollen, sollten Sie einen entsprechenden
Link in den Runlevelverzeichnissen auf das Startskript /etc/init.d/bind9 anlegen.
Feb 11 21:17:57 linux04 named[13692]: starting BIND 9.2.4 -u bind
Feb 11 21:17:57 linux04 named[13692]: using 1 CPU
Feb 11 21:17:57 linux04 named[13694]: loading configuration from
’/etc/bind/named.conf’
Feb 11 21:17:57 linux04 named[13694]: no IPv6 interfaces found
Feb 11 21:17:57 linux04 named[13694]: listening on IPv4 interface lo,
127.0.0.1#53
Feb 11 21:17:57 linux04 named[13694]: listening on IPv4 interface eth0,
10.8.4.254#53
Feb 11 21:17:57 linux04 named[13694]: listening on IPv4 interface eth0:1,
192.168.1.2#53
Feb 11 21:17:57 linux04 named[13694]: zone ’wg.site’ allows updates by
IP address, which is insecure
Feb 11 21:17:57 linux04 named[13694]: zone ’4.8.10.in-addr.arpa’ allows
updates by IP address, which is insecure
Feb 11 21:17:57 linux04 named[13694]: command channel listening on
127.0.0.1#953
Feb 11 21:17:57 linux04 named[13694]: zone 0.in-addr.arpa/IN: loaded
serial 1
Feb 11 21:17:57 linux04 named[13694]: zone 4.8.10.in-addr.arpa/IN: loaded
serial 2002100405
Feb 11 21:17:57 linux04 named[13694]: zone 127.in-addr.arpa/IN: loaded
serial 1
Feb 11 21:17:57 linux04 named[13694]: zone 255.in-addr.arpa/IN: loaded
serial 1
Feb 11 21:17:57 linux04 named[13694]: zone localhost/IN: loaded serial 1
Feb 11 21:17:57 linux04 named[13694]: zone wg.site/IN: loaded serial
2002100405
Feb 11 21:17:57 linux04 named[13694]: running
8.3.4
Slave-Server
Bisher beschäftigte sich die Darstellung mit dem Aufsetzen eines primären DNS und dem
Anlegen der Zonen-Dateien. Wenn nicht lediglich ein privater DNS betrieben wird, sollte
118
KAPITEL 8. DNS
man unbedingt aus Gründen der Redundanz Slaves vorsehen. Hier fällt der Aufwand jedoch
bedeutend geringer aus, da man lediglich die namd.conf.local anpassen muss. Trägt man hier
alle Zonen ein, für die diese Maschine als Slave zuständig sein soll.
zone "wg.site" IN {
type slave;
masters { 10.8.4.254; };
file /etc/named/secondary/db.wg.site;
}
Man starte den Slave neu, nachdem der Master bereits läuft. Damit alles klappt muss named
im Verzeichnis /etc/named/secondary über Schreibrechte verfügen. Hier landen die Daten
eines erfolgreichen Domain-Transfers. Im Logfile des Masters findet sich ein Hinweis auf
diesen Vorgang:
Feb 11 22:18:02 linux04 named[13722]: client 132.230.4.44#36606: transfer of
’wg.site/IN’: AXFR started
Anhand der Seriennummer der Datei stellt der Slave fest, ob sich Daten auf dem Server
geändert haben (sollten). Sie muss daher stets inkrementiert werden, wenn eine Änderung
vorgenommen wurde. Quasistandard ist ein JJJJMMTTRR-Format, um die Seriennummer
festzulegen. 2005011002 steht also für den 10.01.2005, die beiden letzten Stellen für die
zweite Modifikation der Zonendatei an diesem Tag. Nun ist diese Zahl oft nicht so übersichtlich, als dass man nicht versehentlich einen Fehler macht und eine Stelle zuviel drin hat.
Wenn die Slaves eine solche Seriennummer übernommen haben und anschliessend auf dem
Master wieder eine korrigierte Nummer eingetragen ist, bekommen sie kein Update mehr
mit. Ihre Nummer ist immer größer als die des Masters. Um dieses Dilemma in den Griff
zu bekommen, kann man den folgenden Trick anwenden: Man trage 231 − 1 (=2147483647)
ein. BIND arbeitet mit vorzeichenbehafteten 32 bit Zahlen. So ist diese der größtmögliche
Wert und in der nächsten Runde wird wieder jede beliebige Seriennummer von den Slaves
als Grund für ein Update akzeptiert.
In den Beispielen wurde eine strenge Trennung von Master- und Slave-Servern angenommen. Das muss natürlich in der Realität nicht so sein. Hier sind viele Server authoritativ
für eine Reihe von Zonen und sekundär für eine Anzahl anderer Zonen.
8.3.5
Delegation einer Subdomain
In den bisherigen Beispielen stimmte eine Zone immer mit einer Domain überein. Ein Nameserver war für den gesamten Namensraum zuständig. Dieser war einfach strukturiert:
maschinenname.domain.topleveldomain, z.B. hermes.wg.site. Nun erlaubt DNS aber Teile
seines Namensraumes an andere Nameserver zu delegieren. So können Admins bestimmter
organisatorischer Einheiten ”ihre” Zone verwalten. Mit folgendem Eintrag in der Zonendatei des Beispiels (/etc/bind/db.wg.site) delegiert der Nameserver die Zone, in diesem Fall
die Subdomain sub.wg.site an die Server ns1.sub.wg.site und ns2.sub.wg.site.
[ ... ]
sub
ns1.sub
ns2.sub
[ ... ]
IN
IN
IN
IN
NS
NS
A
A
ns1.sub.wg.site.
ns2.sub.wg.site.
10.8.5.1
10.8.5.2
Der Resource-Record NS regelt die Delegation. Damit weiss der Nameserver, dass Anfragen
auf *.sub.wg.site an die dafür zuständigen Server ns1 und ns2.sub.wg.site weitergereicht
werden. Deren Namen müssen natürlich ebenfalls zu IP-Adressen aufgelöst werden können.
Deshalb sind die beiden Nameserver ebenfalls mit einem A-Record vertreten.
8.4. DYNAMISCHE UPDATES DER ZONENDATEIEN
8.4
119
Dynamische Updates der Zonendateien
Mit steigender Anzahl verwalteter Zonen und Hosts wird das Verfahren der händischen
Manipulation der Zonendateien für Admins schnell aufwändig. Nebenher hat sich die Zahl
mobiler Endgeräte deutlich ausgeweitet. Das sind Hosts, die oft in verschiedenen Netzen
betrieben. Zudem sind sie oft nicht sehr lange angemeldet. Hier wünscht man sich ein
Verahren, was ähnlich zu WINS dynamisch arbeitet.
Mit BIND seit Version 8 kann man dynamische Änderungen an den Resource Records
vornehmen (lassen), ohne dafür Dateien editieren und diese neu laden zu müssen. Solche
Änderungen können auch durch externe Dienste, wie DHCP angestoßen werden. Um dieses
zu erlauben, muss der Admin eine zusätzliche Zeile in die Zonendefinition einfügen:
zone "wg.site." IN {
...
allow update { 172.0.0.1; };
}
Im Beispiel ist nur das Update von der Loopbackadresse erlaubt. Man kann natürlich auch
Listen von IP-Adressen oder ACLs angeben. Dabei ist jedoch zu beachten, dass bei der
Datenübertragung über das Netz DNS nicht automatisch verschlüsselt. Wie man dieses
einschaltet, wird im folgenden Abschnitt erklärt.
Um das neue Feature gleich mal auszuprobieren, kann nsupdate verwendet werden.
Dieses Programm ist im BIND-Paket enthalten. Es arbeitet interaktiv ähnlich wie nslookup. Man gebe zuerst den DNS-Server an und dann einen Eintrag der hinzugefügt oder
gelöscht werden soll. Nach dem Eintrag ist ein zweimaliges ”Enter” erforderlich.
linux:~ > nsupdate
> server 127.0.0.1
> update add newhost.wg.site 300 A 10.8.4.51
>
> update delete newhost.sg.site 300 A 10.8.4.51
Damit die ganze Geschichte auch funktioniert, muss der Nameserver das Recht haben das
Verzeichnis der Zonendateien und diese selbst zu schreiben. Im Beispiel wurde eine Datei
/etc/bind/db.wg.site.jnl beim Hinzufügen eines Eintrages angelegt. Alle 15 Minuten macht
BIND einen Dump der Zonendatei mit den neuen oder ohne die zwischendurch entfernten
Einträge und erhöht dabei die Seriennummer automatisch.
8.4.1
Sicherheit
Wie man im Beispiel sehen konnte, benötigte nsupdate keine besondere Authentifizierung, um Änderungen an den DNS-Daten vorzunehmen. Eine Absendeadresse ist leicht
zu fälschen, weshalb man sich schnell einen besseren Schutz wünscht. Ebenfalls will kein
Administrator ernsthaft, dass jeder beliebige Host im Internet vom eigenen DNS ein Zonentransfer anfordern kann. Dieser ist normalerweise den Slaves vorbehalten, um ihre Daten
zu aktualisieren.
Ebenfalls seit Version 8 implementiert BIND zur Erhöhung der Sicherheit sogenannte Transaction Signatures (TSIGs). Dieses sind digitale Signaturen, die HMAC-MD5 als
Einwege-Hashfunktionen benutzt. Die Signatur ist dabei nicht nur von der Nachricht, sondern auch von einem Schlüssel abhängig. Der Hashwert wird über die komplette binäre
Nachricht berechnet und als Resource Record (Typ TSIG) angehängt. Zur Verhinderung
von Replay-Attacken ist das Datum Bestandteil der Signatur.
120
KAPITEL 8. DNS
Das Bastelset zum Erzeugen der Schlüssel liefert BIND mit dnssec-keygen. Der Aufruf
dnssec-keygen -b 128 -a HMAC-MD5 -n HOST hermes.wg.site generiert einen 128bitSchlüssel, der genau einer Maschine zugeordnet ist.
linux04:~# dnssec-keygen -b 128 -a HMAC-MD5 -n HOST hermes.wg.site
Khermes.wg.site.+157+23873
linux04:~# ls Khermes.wg.site.+157+23873.*
Khermes.wg.site.+157+23873.key Khermes.wg.site.+157+23873.private
linux04:~# cat Khermes.wg.site.+157+23873.key
hermes.wg.site. IN KEY 512 3 157 ynhDhu8MM0vNsdWivlTFow==
linux04:~# cat Khermes.wg.site.+157+23873.private
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: ynhDhu8MM0vNsdWivlTFow==
Das Kommando legt zwei Dateien im Arbeitsverzeichnis an. In der Datei mit der Endung
*.key findet man den öffentlichen Schlüssel in der anderen *.private den privaten. Den
öffentlichen Schlüssel läßt sich nun in die entsprechende Zonendatei integrieren. So kann er
beispielsweise mit host -t KEY hermes.wg.site abgefragt und zur Verifikation des privaten Schlüssels herangezogen werden. Den privaten Schlüssel hinterlegt man in der Datei
mit den Zonendefinitionen /etc/bind/named.conf.local:
key hermes.wg.site. {
algorithm hmac-md5;
secret "Geq/RRYhuAIrlUzJKj49MQ==";
};
und sorgen dafür, dass nur noch ein Update unter Angabe des Schlüssels erfolgen darf:
zone "wg.site" in {
type master;
file "/etc/bind/db.wg.site";
allow-update { key hermes.wg.site.; };
};
Nach den Änderungen muss der Server neu gestartet werden. Ausprobieren kann man das
Ganze nun mit dem Aufruf von nsupdate mit der Angabe der Datei mit dem privaten
Schlüssel: nsupdate -k Khermes.wg.site.+157+23873.private Die Transaktionen werden
nun
mit
dem
Schlüssel signiert. Ohne Angabe des Schlüssels würde die Aktion mit einem ”REFUSED”
fehlschlagen.
nsupdate ist sicherlich nicht die alltägliche Anwendung. Bei den Fragen der Sicherheit
geht es eher um Zonentransfers. Hierzu muss der private Schlüssel sowohl auf dem Masterals auch auf dem Slave-DNS-Server eingetragen sein. Für Zonentransfers heisst die Option
statt ”allow-update” ”allow-transfer” unter Beibehaltung der restlichen Syntax. Auf dem
Slave sehen die Eintragungen nun wie folgt aus:
key hermes.wg.site. {
algorithm hmac-md5;
secret "Geq/RRYhuAIrlUzJKj49MQ==";
};
server 10.8.4.254 {
keys { hermes.wg.site.; };
};
zone "wg.site" IN {
type slave;
masters { 10.8.4.254; };
file /etc/named/secondary/db.wg.site;
}
8.5. DNS BEKOMMT NEUE AUFGABEN
8.5
8.5.1
121
DNS bekommt neue Aufgaben
ENUM
Voice-over-IP hat im zweiten Anlauf nach den ersten Startversuchen Ende der 90er Jahre
richtig Schwung bekommen. Spätestens seit der letzten Cebit 2004 hat der Hype um die Telefonie über das Internet die breite Öffentlichkeit erreicht. Nun waren Telefonie und IP-Netze
lange Zeit zwei völlig getrennte Dienste, ein Zustand mit dem große Telefonie-Anbieter, wie
die Telekom gut leben konnten. Wärend im Hintergrund beide Dienste konvergieren, steht
nach aussen noch ein entscheidender Unterschied: International erreicht man jeden Teilnehmer am öffentlichen Telefonnetz über die 1-3 stellige Ländervorwahl gefolgt von einer
maximal 15-stelligen nationale Telefonnummer. Letztere besteht aus einer Vorwahl und
Anschlußnummer, wobei das Vorwahlkonzept in unterschiedlichen Ländern verschieden gehandhabt wird. Rechner im Internet werden hingegen durch ihre weltweit eindeutige IP
angesprochen.
ENUM schlägt hier nun die Brücke und führt beide Systeme unter Zurhilfenahme von
DNS zusammen. Definiert ist die Abbildung von Telefonnummern im Domain Name System
in RFC2916 zu ENUM E.164. ENUM kann noch mehr, nämlich beliebige Kommunikationsformen (Mail, Webseite, ...) auf eine Telefonnummer abbilden und diese hierarchisch
anordnen. DNS ist deshalb für ENUM interessant, da es seit Jahren etabliert ist und damit
eine schnelle Umsetzung erlaubt.
Die Vergabe von Telefonnummern ist in jedem Land ein hoheitlicher Akt, in Deutschland
übernimmt das die Regulierungsbehörde für Telekommunikation. Sie hatte beispielsweise
Ende letzten Jahres mit der Entscheidung über die ortsunhabhängige Vorwahl 032 für SIPTelefonanschlüsse von sich hören lassen.
Damit Telefonnummern im DNS-System darstellbar sind, werden sie in eine eindeutige
Domain verwandelt. Hierzu wurde die Domain ”e164.arpa” eingeführt analog zu ihrem IPPendant ”in-addr.arpa” der Reverse-Auflösung. Unterhalb dieser Domain trägt man nun
einfach Subdomains für jede Ziffer einer Telefonnummer ein. Anders als bei IP-Adressen
und Telefonnummern steht bei DNS die spezifischte Information ganz links: Die ToplevelDomain ist immer die ganz rechte, die Secondlevel-Domain die zweite von Rechts und
Subdomains sind dann weitere bis der Rechnername ganz links kommt.
Deshalb dreht man die die Telefonnummer um. So wird aus +49-551-654321 ein Eintrag
der Form 1.2.3.4.5.6.1.5.5.9.4.e164.arpa.
1. Zunächst entferne man alle optischen Strkturierungen, wie ”+”, ”-”, Leerzeichen:
49551654321
2. Man ordne die Ziffernfolge um: Aus 49551654321 erhält man 12345615594
3. Man setze Punkte zwischen die Ziffern: 1.2.3.4.5.6.1.5.5.9.4
4. Am Ende fügt man noch die ENUM-Domain ”e164.arpa” an: 1.2.3.4.5.6.1.5.5.9.4.
e164.arpa
Den nun generierten vollständigen Domainnamen kann DNS nun ganz normal wie eine
IP auch im Nameservicebetrieb verwenden. RFC2915 definiert für das ENUM-Protokoll
spezielle Nameserver-Einträge, um auf die einzelnen Kommunikationsadressen (Telefon,
Mail...) zu verweisen. Zum Einsatz kommen sogenannte ”Naming Authority Pointer Records” (NAPTR). Für jede Domain lassen sich mehrere dieser NAPTR-Einträge angeben.
Sie erlauben ebenfalls Prioritäten (Preferenzen) festzulegen.
122
KAPITEL 8. DNS
Mit ENUM ändert sich der Charakter eines Anrufes grundsätzlich: Zunächst wird über
das DNS-System die Telefonnummer bis zum NAPTR-Eintrag ermittelt. Diese weist dann
auf eine Nummer eines Telefons oder Faxes, eines Handys oder weiterer Geräte. ENUM gestattet so dem Inhaber einer Telefonnummer, quasi beliebig viele Dienste auf seine Nummer
abzubilden. Das vereinfacht in Zukunft das Verfahren alternative Dienste durch Telekommunikationsendgeräte und ¿Applikationen anzusprechen.
8.5.2
IPv6
Die nächste Generation der IP-Adressen steht schon länger vor der Tür. Für den Endbenutzer sicherlich noch nicht relevant, so tut sich jedoch schon hinter den Kulissen einiges.
Entsprechend schreitet auch die Auf- und Umrüstung der IP-Dienste auf IPv6 voran. So ist
BIND seit einiger Zeit in der Lage IPv6-Adressen genauso wie Ihre IPv4-Pendants vorwärts
und rückwärts aufzulösen. Für IPv6 wurde ein neuer Ressourcentyp eingeführt: AAAA repräsentiert eine IPv6 Adresse (A entsprach 32bit, 4*A entsprechend 128bit).
Einträge in der Zonen-Datei zur Vorwärtsauflösung könnten also so aussehen:
[ ... ]
aphrodite
aphrodite-ipv6
dionysos
dionysos-ipv6
IN
IN
IN
IN
A
AAAA
A
AAAA
10.8.4.203
3ffe:701:10:200:22:feb5:3456
10.8.4.204
3ffe:701:10:200:22:feb5:3457
Die Rückwärtsauflösung landet in einer eigenen Zonendatei (beispielsweise 5.b.e.f.2.2.0.0.
0.0.2.0.0.1.0.0.4.e.f.f.3.ip6.arpa):
[ ... ]
3456
3457
IN PTR
IN PTR
aphrodite-ipv6.wg.site.
dionysos-ipv6.wg.site.
Ein Problem entsteht nun natürlich bei der Auflösung von Namen zu IP: Welche Informationen sollen zurückgeliefert werden: Beide IP-Adressen oder jeweils die eine oder andere?
Darüberhinaus gibt es noch einige weitere Stolperfallen: Angenommen, man betreibt eine
Maschine ausschliesslich mit einer IPv6 Adresse. Dann lässt sich nicht einfach im Resolver eine IPv4 Adresse für den Nameserver angeben. Die Maschine wäre in den meisten
Fällen nicht in der Lage ihre Anfragepakete dorthin zu routen. Der IPv4 DNS Ihres Netzes kann aber Proxy-Funktionen übernehmen. Er lauscht nicht nur wie gewohnt auf den
IPv4-Interfaces sondern bekommt auch eine IPv6-Adresse zugeteilt, die von den Clients im
eigenen Netz erreicht werden kann. Der Server empfängt dann die Anfragen vom Client
über das IPv6-Interface und holt seinerseits Erkundigungen über das klassische IPv4 Netz
ein.
8.5.3
DNS als Bannerfilter
Wie sehr es auf einen funktionierenden Nameservice ankommt, sieht man, wenn man einfach mal eine häufig benutzte Domain falsch auflöst. Wenn man im eigenen LAN einen DNS
betreibt, den alle Maschinen benutzen (müssen), kann man diesen für alle möglichen Zonen als authoritativ deklarieren. Hierzu trägt man einfach eine Zone für die entsprechende
Domain nach und verweisen auf ein dafür speziell definiertes Master-File.
zone "google.de" in {
type master;
file "master/empty.zone";
};
8.6. AUFGABEN
123
zone "falkag.de" in {
type master;
file "master/empty.zone";
};
zone "doubleclick.net" in {
type master;
file "master/empty.zone";
};
Dabei spielt es überhaupt keine Rolle, wenn alle diese Zonen die identische Datei benutzen.
In dieser wird lediglich dafür gesorgt, dass auf jede Anfrage eine 127.0.0.1 zurückgeliefert
wird.
; NULL Zone File for Ad Servers and other unwanted services ;
@
IN SOA mydomain.site. me.mydomain.site. (
131
; serial number
28800
; refresh
1800
; retry
432000
; expire
18000
) ; minimum TTL
; Zone NS records
@
NS
mydomain.site.
A
127.0.0.1
*
IN
A
127.0.0.1
Das Beispiel zeigt die Nutzung eines Wildcards ”*”. Es muss nicht für jeden Namen ein
Eintrag existieren, diese können so einfach zusammengefaßt werden.
Wenn man den Nameserver beispielsweise für doubleclick.net authoritativ macht, dann
schlägt das Laden aller Banner und Webbugs fehl, die als Quelle eine Maschine dieser
Domain angeben. Je nach Browser können dann einige Seiten etwas verändert aussehen, da
plötzlich Seitenelemente von denen man nie vermutet hätte, dass sie von extern kommen,
fehlen. Dies ist kein Allheilmittel. Jeder Anbieter kann natürlich statt eines FQDN auch
eine IP in seine Webadressen schreiben. Trotzdem ist es ein recht einfaches probates Mittel,
um seine Datenspur bei sehr großen Diensteanbietern einfach zu reduzieren. Es zeigt aber
auch, dass wenn die wenigen zentralen Root-Server nicht erreichbar sind, nicht mehr viel
funktionieren würde.
8.6
8.6.1
Aufgaben
Rechnernamen im Internet
1. Welche Aufgabe hat der DNS?
2. Warum kann man nicht einfach bei der alten /etc/hosts als einfache Zuordnung zwischen IP und Hostnamen bleiben?
3. Warum kann man zwar auf der lokalen Maschine den Hostnamen ändern; es hat aber
keine Auswirkungen für alle anderen Rechner?
4. Man änder den Hostnamen! Wo müsste die dauerhafte Änderung eingetragen sein?
Man ändere nun einen Eintrag für einen Rechner in der /etc/hosts, warum kann man
124
KAPITEL 8. DNS
diesen Rechner nun unter dem neuen Namen anpingen, obwohl der “Besitzer” dieses
Rechners den Namen nicht geändert hat?
5. Wo trägt man auf einem Linuxrechner die IP-Nummern von Nameservern ein? Warum
kann man da nicht einfach den Namen des (Nameserver-)Rechners eintragen?
6. Warum macht es Sinn, mehrere DNS-Server einzutragen? Wo trägt man diese ein?
8.6.2
Domain Name Service (DNS)
1. Was ist eine sogenannte Toplevel-Domain? Welche gibt es traditionell, welche sind
erst in jüngerer Zeit hinzugekommen?
2. Worin besteht der Unterschied zwischen DNS Resolver und DNS Nameserver?
3. Welche Resource Records (RR) gibt es? Welche Bedeutung haben diese jeweils?
8.6.3
DNS Server
1. Worin unterscheiden sich rekursive und iterative Namensauflösung? Warum antworten die Root-Nameserver immer nur iterativ? Mit welchem Kommando kann man das
geschilderte Phänomen am besten nachvollziehen?
2. Wieviele Root-Nameserver gibt es? Wo stehen diese? Wodurch ist deren Zahl begrenzt?
Kapitel 9
Webserver
Viele Internet-Benutzer sehen dieses nur als WWW. Jedoch ist es nur eine Teilmenge der
TCP/IP-Suite. Das Protokoll des World Wide Web heisst HTTP. Es ist die Standardsprache
des modernen WWW.
Der für den Anwender sichtbare Vorgang des Abrufs eines Dokuments besteht in der
Regel aus der Eingabe einer URI oder dem Anklicken eines Links, gefolgt von der Darstellung der Daten oder einer Fehlermeldung. Diese einfache Art und Weise der Benutzung hat
viel zur breiten Akzeptanz des Internets beigetragen.
9.1
Überblick
Im Zusammenhang mit WWW und dem dafür hauptsächlich zuständigen Protokoll der
Applikationsschicht HTTP spielen einige Bezeichnungen eine Rolle:
• Ressource - ist die Quelle eines Webinhalts, der durch eine URI identifiziert werden
kann. Der einfachste Typ der Ressource ist eine statische Datei im Filesystem des
Web-Servers. Typ und Inhalt der Datei sind beliebig. Außerdem kann die Ressource
auch ein Programm sein, welches bei Aufruf einen bestimmten Inhalt generiert und
ausliefert.
• URI - Uniform Resource Identifier bezeichnet den weltweit eindeutigen Name für eine
Ressource. z.B http://www.goe.net/index.php)
• URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name für die
Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar.
• URN - Uniform Ressource Name, ein spezialer Typ von URI, auch weltweiter eindeutig. z.B. urn:isbn:0-596-00962-3
Die Enwicklung des WWW begann mit HTTP/0.9, einer Prototyp-Version, die von Tim
Berners-Lee am CERN in den Jahren 1990/1991 entwickelt wurde. HTTP /0.9 kennt lediglich die GET-Methode. HTTP/1.0 war die erste Version, die weit entwickelt zum Standard
wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DELETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wird genauer spezifiziert.
HTTP/1.0 ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Es handelt sich
jedoch nur um eine rudimentäre Authentifizierung, da das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann.
125
126
KAPITEL 9. WEBSERVER
Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich
auf die Korrektur der Designfehler, das Spezifizieren von Semantik, einigen PerformaceOptimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher für jede Resource
eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads
fortgesetzt werden. Über Cookies in den Header-Informationen können Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, ...) zuordnen können. Dadurch
können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Die Methoden sind auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver
überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver
über die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene.
HTTP/1.1 umfasste auch die Unterstützung für die höher entwickelten Netzanwendungen
und Entwicklungen, die in den späten neunziger Jahren waren.
9.2
HTTP-Kommunikation
user@linux02:~> telnet 10.30.4.100 81
Trying 10.30.4.100...
Connected to 10.30.4.100
Escape character is ’^]’.
GET /hallo.html HTTP/1.1
Host 0.30.4.100:81
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Test-Seite</title>
</head>
<body>
<H1> Haupt&uuml;berschrift </H1>
</body>
</html> Connection closed by foreign host.
Zwischen GET- und POST-Anfragen bestehen folgende wesentliche Unterschiede: Bei
der GET-Methode werden die übergebenen Daten in die URL einkodiert und sind somit
für jeden sofort lesbar, ein Beispiel sind Suchanfragen bei Google:
http://www.google.de/search?q=http+get+post&start=0&start=0&ie=\
utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:de-DE:official
Bei POST werden die Daten im Header übergeben. Dabei lassen sich wesentlich mehr Daten übergeben als in einer GET-Anfrage. Das Versenden der Daten an den Server geschieht
für den Nutzer auf den ersten Blick scheinbar unsichtbar. Ein wesentlich größerer Unterschied ist allerdings, dass GET-Anfragen idempotent sind, was bedeutet, das sich die Seite
aufgrund einer GET-Anfrage nicht ändert. Daraus ergibt sich auch, dass solche Seiten im
Cache angelegt werden können. Mit POST-Seiten ist es jedoch genau andersherum, diese
sind nicht idempotent und werden deshalb nicht im Cache abgelegt.
9.3. WAS IST EIN WEBSERVER?
9.3
127
Was ist ein Webserver?
Ein Server ist ein Programm, das bestimmte Anfragen auf einem bestimmten Port annimmt
und verarbeitet.
Ein Webserver liefert Dateien aus bestimmten Verzeichnissen (mit der Angabe von welchem Type 1 diese Dateien sind) über Netzwerk aus. Unter Umständen wird bei der Entscheidung, welche Dateien ausgeliefert werden, nach der angefragten Adresse unterschieden.
Grundsätzlich wird auf die Anfrage http://host.domain/directory/example.html
mit der Auslieferung von “Content-Type Text-html” und dem Inhalt der Datei:
/usr/local/httpd/htdocs/directory/example.html2
von dem Webserver auf host.domain reagiert.
9.4
Apache 2
Der Apache 2 ist der weltweit meist-verbreitete Webserver. Ein Kernbestandteil des Erfolges
ist die Tatsache, dass Apache ein Open-Source-Projekt ist. Der Aufbau ist modular, d.h. der
Webserver hat einen schlanken Kern, welcher die Grundfunktionalität enthält und Erweiterungen können zusätzlich eingebunden werden (teilweise mit und teilweise ohne Neustart
des Apache).
Vielfach sind noch eine ältere Version des Servers 1.3.X im Einsatz. Neu in der Version
2.0 ist z.B. dass plattformspezifischer Code (z.B. Schreib- Lesezugriffe auf die Festplatte)
in eine APR (Apache Portable Runtime) ausgelagert wurde. Dies ermöglicht es, dass für
jedes Betriebssystem eine eigene Version der APR geschrieben und optimiert werden kann,
was der Geschwindigkeit und Stabilität zu Gute kommt.
Einheiten zur Abbildung von HTTP-Anfragen auf reale Ausführungseinheiten wurden
ebenso ausgelagert. (Diese nennen sich MPMs [Multi Processing Modules].) Dies macht
Sinn, da dieser Vorgang ebenso vom Betriebssystem abhängt (genauso wie von der konkret
betrachteten Anwendung natürlich auch).
Ebenso neu eingeführt in der Version 2.0 wurden Multi-Protokoll-Unterstützung auf
Transportebene und IPv6-Unterstützung.
9.4.1
Erweiterte Funktionalität
Virtual Hosts (IP- oder Name-basiert)
SSL, sichere Verbindungen
Authentifizierung
CGI (Common Gateway Interface)
Ausführen von Scripten und Programmen
PHP
SSI (Server Side Includes)
9.5
Konfiguration
In den aktuellen Versionen hat Apache nur noch die Konfigurationsdatei httpd.conf. Allerdings machen viele Distributionen von der Möglichkeit gebrauch, andere Dateien mit
Include einzubinden.
1
2
zB.: Content-Type Text-html
Wenn DocumentRoot auf ’/usr/local/httpd/htdocs’ gesetzt ist. Dazu später mehr.
128
KAPITEL 9. WEBSERVER
Die Konfiguration besteht aus drei Abschnitten.
• Section 1: Global Environment
• Section 2: ’Main’ server configuration
• Section 3: Virtual Hosts
Das Verhalten des Servers wird innerhalb dieser Sektionen mit sogenannten Direktiven
gesteuert. Diese Direktiven stehen innerhalb von Konfigurationskontexten.
globaler Kontext In der Konfigurationsdatei ausserhalb von Containern
Container-Kontext Innerhalb von Container-Tags (zB.: ¡Directory¿...¡/Directory¿). Der
Gültigkeitsbereich ist auf die Container beschränkt.
Verzeichniskontext In zusätzlichen Konfigurationsdateien innerhalb der Verzeichnisstruktur. Der Name dieser Dateien kann mit AccessFileName festgelegt werden 3 .
Direktiven können in unterschiedlichem Kontext stehen, aber nicht jede Direktive kann
in jedem Kontext verwendet werden. Die Apache-Dokumentation gibt für jede Direktive
an, in welchem Kontext sie verwendet werden kann.
Einige der wichtigsten Direktiven der Main Server Konfiguration sind:
ServerType standalone — inetd
ServerRoot Das Verzeichnis, das für den Webserver die unterste Verzeichnisebene darstellt.
ServerName Der Name des Webservers ist die URL unter der er erreichbar ist.
DocumentRoot Das Verzeichnis in dem sich die Webseiten befinden, bzw. aus dem der
Webserver Dateien ausliefern darf.
User / Group Benutzer- bzw. Gruppenrechte, mit denen der Webserver läuft.
ServerAdmin E-Mail-Adresse des Administrators. An diese Adresse werden Servermeldungen geschickt und sie wird unter Umständen Benutzern mitgeteilt.
9.5.1
Optionen
Eine wichtige Direktive ist die Options-Direktive mit der man festlegen kann, welche ServerFeatures verfügbar sind. Optionen können im Konfiguration-, Container- und VerzeichnisKontext gesetzt werden.
ExecCGI :
Ausführbarkeit von CGI-Programmen
Includes :
Ausführung von ServerSideInclude-Befehlen (SSI)
Indexes :
Verzeichnislisting anzeigen
9.5. KONFIGURATION
129
<Directory /home/www/>
Options +Indexes -Includes
</Directory>
Abbildung 9.1: Options hinzugügen/entfernen
Optionen können gesetzt, hinzugefügt(+) oder entfernt(-) werden. Im Beispiel 9.1 wird
für das Verzeichnis /home/www/ die Option Indexes zu den allgemein gültigen Optionen
hinzugefügt und die Option Includes von den allgemein gültigen Optionen entfernt (abgezogen).
Im Beispiel 9.2 werden für das Verzeichnis /home/www2/ nur die Optionen Indexes und
Includes gesetzt. Unabhängig von den allgemein gültigen Optionen.
<Directory /home/www2/>
Options Indexes Includes
</Directory>
Abbildung 9.2: Options setzen
9.5.2
Module
Zusätzliche Funktionalitäten können in Form von Modulen hinzugefügt werden. Module
können mit
LoadModule cgi_module /usr/lib/apache/mod_cgi.so
AddModule mod_cgi.c
im Global-Kontext geladen werden. Module bringen ihre eigenen Direktiven mit, die nach
dem Laden verfügbar sind. Mit der Direktive IfModule kann man Container erzeugen, deren
Direktiven nur ausgeführt werden, wenn das entsprechende Modul geladen ist (siehe 9.3, S.
130). Module können auch direkt in den Apache einkompiliert werden und sind dann ohne
geladen werden zu müssen verfügbar.
Für Apache gibt es eine Vielzahl Module, die nicht zur Standard-Distribution gehören.
Wünscht man sich eine zusätzliche Funktion für seinen Webserver, lohnt es sich im Internet
nach einem Modul zu suchen, das diese Funktionalität bereitstellt. Sollte man nicht fündig
werden, kann man sich dank der offenen Quelltexte daran machen, selber ein solches Modul
zu schreiben.
9.5.3
User-WWW
Das Userdir-Modul ermöglicht es für jeden Benutzer ein Verzeichnis einzurichten, das bei
einer Anfrage der Form http://server/~username vom Webserver ausgeliefert wird.
Die Direktive UserDir legt den Namen des Verzeichnisses innerhalb der Home-Verzeichnisse fest, dessen Inhalt der Webserver ausliefern darf. Innerhalb eines DirectoryContainers bezüglich /home/*/public html kann man das Verhalten des Webservers innerhalb dieses Verzeichnisses steuern. Beide Anweisungen sind unabhängig voneinander,
man muss selber darauf achten, dass man das Verzeichnis konfiguriert, dass mit UserDir
gesetzt ist.
3
Standard ist AccessFileName .htaccess
130
KAPITEL 9. WEBSERVER
<IfModule mod_userdir.c>
UserDir public_html
</IfModule>
<Directory /home/*/public_html>
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>
Abbildung 9.3: User-Webdirectory
Bei SuSE-Linux sind die Direktiven bezüglich mod userdir in die Datei
/etc/httpd/suse public html.conf ausgelagert.
9.6
Webserver Erweiterungen
Die Anforderungen an den Apache Webserver sind in den letzten Jahren gestiegen, so
dass das eigentliche ausführbare Programm permanent erweitert werden muss. Die ApacheFoundation4 hat sich hier einer modernen Methode des Softwaredesigns bedient, bei der
nicht das eigentliche Kernprogramm aufgebläht wird, sondern zusätzliche Funktionalität in
externe Module ausgelagert wird.
Der Kern-Server (core-server) bietet nur die notwendige Basisfunktionalität, wie die
Implementierung eines TCP/IP-Servers. Alle zusätzlichen Features werden durch Module
hinzugefügt. Durch diese Möglichkeit bleibt der Webserver ”schlank” und verwendet je nach
Konfiguration nur die Module, welche wirklich gebraucht werden. Dieses vermeidet unnötige
Sicherheitslücken. In der Apache Modul Datenbank sind momentan (November 2005) über
400 Module gelistet bei steigender Anzahl. Zur Integration von Zusatzfunktionen kann man
zwischen zwei Modularten unterscheiden:
• Ein statisches Modul wird zusammen mit dem Kern zu einem einheitlichen Paket
kompiliert und damit fester Bestandteil des Webserver-Programms. Beim Hinzufügen
oder Entfernen eines solchen Moduls kommt der Admin um eine Neukompilierung
des Webservers nicht herum. Durch die feste Integration kann sich die Ausführungsgeschwindigkeit beim Starten des Apache und wärend der Laufzeit erhöhen, da keine
zusätzlichen Initialisierungen für jedes Modul notwendig sind und der interne CodeOverhead sinkt.
• Ein Shared-Module kann dynamisch durch eine entsprechende Direktive in der Konfigurationsdatei httpd.conf hinzugefügt oder entfernt werden. Da die Konfigurationsdateien nur bei einem Start des Apache Webserver eingelesen werden, ist hier also
lediglich ein Neustart des Webservers erforderlich. Diese Methode bringt zwar Einbußen der Performance des Webservers mit sich, jedoch ist es so sehr einfach möglich
ein Modul schnell und ohne zeitaufwendige Neukompilierung des Webservers hinzuzufügen.
4
Der erste Apache-Webserver entstand aus dem damals aktuellen NCSA httpd 1.3 und zusätzlichen
Erweiterungen und Patches (a patchy-webserver). Im Sommer 1999 begann die Entwicklung des Apache 2,
welcher komplett neu geschrieben wurde. Die Apache Gruppe entwickelt heute sehr erfolgreich Erneuerungen
am Apache Webserver.
9.6. WEBSERVER ERWEITERUNGEN
9.6.1
131
Die Benutzer-Homepage - mod userdir
In klassischen Multi-User-Umgebungen wie Universitäten und Schulen haben Benutzer mit
Linux-Account üblicherweise auch die Möglichkeit eine eigene Homepage in ihrem HomeVerzeichnis anzulegen. Das Modul kümmert sich darum, dass der Webserver mit geeigneten
Rechten auf ein Unterverzeichnis im User-Home, welches sonst ja vor unauthorisiertem
Zugriff geschützt sein sollte, hineinschauen darf.
Das Modul muss lediglich einmal konfiguriert werden. Anschliessend sind sämtliche
Homepage-Verzeichnisse über den Webserver von außen erreichbar. Klassischer Weise erreicht man die Seiten der einzelnen Benutzer unter der URL http://www.mywebserver.site/
username. Das hierfür bestimmte Verzeichnis im jeweiligen Home-Verzeichnis des Benutzers
lässt sich in der Konfigurationsdatei mit der Direktive UserDir Unterverzeichnisname
definieren. In den meisten Fällen heisst dieses Verzeichnis public html
9.6.2
URL-Umschreiber mod rewrite
Dieses Modul erlaubt Manipulationen der URL, durch sogenannte Regular Expressions, wie
man sie auch von anderen Linux-Tools, wie sed oder grep kennt. Hierdurch kann der Webadmin ”unschöne” URLs verändern, um sie zum Beispiel für Suchmaschinen freundlicher
zu gestalten. Viele der Suchmaschinen können zwar dynamische Webinhalte indizieren, jedoch wird eine Internetseite sichtlich besser indiziert, wenn diese statisch ist. Deshalb wird
recht häufig mod rewrite eingesetzt, um den Suchmaschinen Spidern eine dynamische Seite
als statisch unterzuschieben.
Dynamische Seiten sind oft durch URLs mit Parametern charakterisiert: http://www.ks.
uni-freiburg.de/php veranstaltungsdetail.php?id=7. Mittels mod rewrite kann man die URL
so umschreiben, so dass die Seite auch Intern wandelt das Modul die URL wieder um, so
dass die dynamische Seite mit sämtlichen Parametern aufgerufen wird.
Dieses lässt sich durch eine einfache Direktive in der Apache Konfigurationsdatei
httpd.conf umsetzen, wie die Abbildung von ”praxis-seminar.html” auf ”php veranstaltungsdetail.php?id=7”.
RewriteEngine On
RewriteRule ^(praxis-seminar7[0-9]+).html$ php_veranstaltungsdetail.php?id=$1
Die erste Zeile schaltet das Modul durch die Direktive ”RewriteEngine On” ein. In der
zweiten Zeile folgt dann die Regel für die Umschreibung. Der erste Parameter bildet das
Suchmuster und der zweite Parameter das Ersetzungsmuster. Das Suchmuster lässt soch
mittels regulärer Ausdrücke formulieren. Beim Ersetzungsmuster kann es sich um einfachen
Text, aber auch Variablen des regulären Ausdrucks enthalten. Im gezeigten Beispiel steht
$1 für das erste Klammerpaar im Suchmuster.
9.6.3
Zugriffskontrollen
Die Module mod auth basic und mod auth digest erlauben die Einrichtung einer einfache
Zugriffskontrolle über das HTTP Protokoll. Erfolgt ein Zugriff auf eine zugriffsbeschränkte
Resource, dann schickt der Server den Status 401 und verlangt eine Authentifizierung des
Benutzers durch Eingabe eines Benutzernamens und Passworts. Die Eingabe gleicht der
Server mit den Einträgen der Passwort- und Gruppendatei ab. Besitzt der Benutzer die
nötigen Rechte, gewährt der Webserver dem Benutzer den Zugriff.
Um ein Verzeichnis auf dem Webserver vor unauthorisiertem Zugriff zu schützen, gibt
es zwei Möglichkeiten: Zentral in der httpd.conf oder mit Hilfe von .htaccess-Dateien in
den zu schützenden Verzeichnissen. Für den zentralen Ansatz muss der Webadmin in der
httpd.conf die nachfolgenden Zeilen hinzufügen.
132
KAPITEL 9. WEBSERVER
<Directory "/srv/www/htdocs/secure">
AuthType Digest
AuthName "privat"
AuthDigestFile /srv/www/.htpasswd
Require valid-user
</Directory>
Dabei handelt es sich bei /srv/www/htdocs/secure das zu schützende Verzeichnis, das mit
der Digest-Methode abgesichert wird. Für einen Passwortschutz mittels .htaccess-Datei(en)
sind die folgenden Schritte zu unternehmen. Man erstellt die Datei im Verzeichnis mit dem
entsprechenden Inhalt.
<Directory>
AuthType Digest
AuthName "Mit MD5/Digest gesicherter Bereich"
AuthDigestFile /srv/www/.htpasswd
Require valid-user
Require Group webadmins
</Directory>
Mit der Direktive AuthType wird die Authentifizierungsmethode festgelegt, wobei der Webadmin zwischen Basic und Digest wählen kann. Der Unterschied zwischen beiden Module
liegt in der Art der Datenübertragung. Während die Basic Authentifizierung (mod auth basic)
die Daten im Klartext überträgt und damit ein recht hohes Risiko eingeht, verschlüsselt
das Modul mod auth digest die Daten vor der Übertragung mittels MD5. Da jedoch das
Chiffrat abgefangen und mittels Bruteforce-Attacke interpretiert werden kann, empfiehlt
sich bei sensiblen Bereichen die Übertragung zusätzlich mit Hilfe von SSL zu sichern.
<Directory>
AuthType Basic
AuthName "Mit BasicAuth nicht wirklich gesicherter Bereich"
AuthUserFile /srv/www/.htpasswd
Require valid-user
</Directory>
AuthName definiert den Namen des geschützten Bereichs. Der hier definierte String wird
dem Benutzer bei der Passwort-Abfrage präsentiert. Mit den Direktiven AuthUserFile
und AuthGroupFile, beziehungsweise im Fall der Digest Authentifizierung AuthDigestFile
und AuthDigestGroupFile wird der Pfad zu der Passwort- und Gruppendatei definiert.
Die letzte Zeile des Beispiels legt zusätzlich fest, welche Benutzer berechtigt sind in das
Verzeichnis zu wechseln. Hierzu verwendet man die Direktive Require, welche wie bei der
Basic Authentifizierung einen gültigen Benutzer verlangt.
# .htpasswd
user01:secure_section01:fnxpraouunko3Ocasde1cdf0l1ases1a
user02:secure_section01:basd2w49eq0eab5wehz1sdf2r44f24cd
user03:secure_section02:lse35aa81ca43dc8dsecdbe83382121f
Die in den Beispielen genannten Passwort- und Gruppendateien sind Textformate, die
sich mit einem ganz normalen Editor bearbeiten lassen. Die Passworte muss man dabei nicht selbst erstellen, dieses regelt das Programm mit dem Namen htpasswd2 für
die Basic Authentifizierung und htdigest2 für die Digest Authetifizierung. Durch den
Aufruf htpasswd2 -c datei username oder entsprechend htdigest2 -c datei bereich
username wird man zur Eingabe des Passwortes aufgefordert und anschliessend die Datei
erzeugt. Das Hinzufügen von Benutzern in bestehende Dateien geschieht durch das Weglassen des Parameters ”-c”.
# .htgroup
webadmins:user01 user02
normal_user:user03
9.6. WEBSERVER ERWEITERUNGEN
133
Bei sehr vielen Benutzern wird es wie bei der normalen Linux-User-Administration auch,
irgendwann aufwändig die Informationen in einzelnen Dateien zu verwalten. Als Alternative
bietet sich LDAP an.5 Eine Basic Authentication kann auch gegen eine LDAP-Quelle laufen,
die .htaccess zeigt die entsprechenden Einträge:
AuthType Basic
AuthName "Gegen LDAP authentifizierter Bereich"
LDAP_Server localhost
LDAP_Port 389
Base_DN "ou=user,dc=mydomain,dc=site"
Require valid-user
9.6.4
Kompression
Das Modul mod deflate wurde mit der Apache Version 2 eingeführt und erlaubt die Kompression von Webinhalten durch Angabe eines Filters. Das Modul kann ausgehende, sowie
auch eingehende Daten komprimieren. Der Datenverkehr wird hierzu über diesen Filter
umgeleitet. Um dieses Modul zu aktivieren, trägt ein Admin die folgende Direktiven in der
Apache-Konfigurationsdatei ein:
SetOutputFilter DEFLATE
<Directory "/srv/www/htdocs"
AddOutputFilterByType DEFLATE
Text/html
</Directory>
9.6.5
Das Web-DAV Modul
Das Modul mod dav ermöglicht es dem Apache Webserver ein Verzeichnis nach dem DAVStandard6 bereit zu stellen. Dieses ermöglicht DAV-Clients, wie Subversion7 Adobe Golive,
Macromedia Dreamweaver oder dem Windows Explorer, auf das Verzeichnis zuzugreifen,
als wären die Dateien auf der Festplatte der lokalen Maschine abgelegt.
WebDAV ist eine Erweiterung des HTTP/1.1 Protokolls, welche bestehende Beschränkungen aufhebt. Mit dem HTTP Protokoll ist es theoretisch möglich mit einem HTTP-PUT
einzelne Dateien hochzuladen. Diese Möglichkeit wird jedoch von den meisten Webservern
mit der Fehlermeldung 405 quittiert. Durch die Erweiterung des Protokolls mit WebDAV ist
es möglich ganze Verzeichnisse hochzuladen und dies gleichzeitig an eine Revisionskontrolle
zu koppeln. Das WebDAV Protokoll setzt also auf das HTTP/1.1 Protokoll auf, übernimmt
dessen Methoden für die Kommunikation und erweitert diese um seine eigenen Methoden:
• COPY - kopiert Collections (Web DAV für Verzeichnis) und Ressourcen innerhalb
eines zusammenhängenden Namensraumes.
• LOCK - setzt eine Sperre auf eine Ressource oder Collection um einen Überschreibschutz zu implementieren.
• MKCOL - erzeugt eine Collection.
• MOVE - verschiebt eine Collection oder Ressource innerhalb eines zusammenhängenden Namensraumes.
• PROPFIND - ermöglicht es Metadaten, Eigenschaften einer Ressource zu lesen.
5
siehe hierzu ...
Web-based Distributed Authoring and Versioning
7
Siehe hierzu den Abschnitt Softwareentwicklung
6
134
KAPITEL 9. WEBSERVER
• PROPPATCH - kann diese Metadaten ändern und löschen.
• UNLOCK - entfernt diesen Überschreibschutz wieder
Nachfolgend sei ein einfaches Beispiel für WebDAV Freigabe demonstriert:
DAVLockDB /usr/local/apache2/webdav
<Location /srv/htdocs/>
Dav On
ForceType text/plain
</Location>
Mit der ersten Direktive legt man den Pfad zu der Lock-Datenbank fest. In dieser Datei
wird abgespeichert, welche der vorhandenen Ressourcen gerade gesperrt sind. Dann folgt ein
Location-Container mit dem wir das Verzeichnis definieren, für welches man individuelle
Einstellungen vornehmen möchte. Mit der Direktive Dav On, wird die WebDAV Funktionalität für das Verzeichnis eingeschaltet. Beim Einsatz von WebDAV sollte der Admin
unbedingt auf die notwendigen Sicherheitsvorkehrungen achten. Hierzu gehört mindestens
ein Verzeichnisschutz. Am besten eignet sich jedoch die Verwendung eines virtuellen Host
in Verbindung mit SSL-Absicherung und einer mod auth digest Authentifizierung.
9.6.6
Vrituelle Webserver
Wenn man sich überlegt, wieviele Domains Webseiten bereitstellen, wird schnell klar, dass
nicht für jede dieser Domain ein Webserver läuft. Oder womöglich für jede ein Rechner. Auch
würde es für die wenigsten Privatpersonen Sinn machen, auf ihrem Computer zu hause einen
öffentlichen Webserver zu betreiben, denn der sollte rund um die Uhr verfügbar sein. Da
erscheint es auf Anhieb sinnvoll mehrere Domains über einen Webserver zu betreiben.
Für Betreiber eines Webservers, also beispielsweise diverse große Webhoster, wäre es
ziemlich aufwändig für jede Domain eine eigene Instanz des Webservers auf unterschiedlichen Ports einer Maschine oder auf verschiedenen IP’s laufen zu lassen. Deshalb unterstützt
Apache schon seit der Vorgängerversion virtuelle Server.
Bei namensbasierten virtuellen Servern verwaltet der Apache mehrere Domains, welche
alle die gleiche IP-Adresse besitzen. Eingehende Anfragen können nur deshalb an die richtige
Domain weitergeleitet werden, weil der Domainname in der GET-Anfrage enthalten ist. Um
den Apache für virtuelle Server zu konfigurieren, muss die httpd.conf oder die entsprechende
Include-Datei8 geändert werden.
NameVirtualHost Schaltet Name Virtual Host ein und gibt an, auf welcher IP-Adresse
auf entsprechende Anfragen reagiert werden soll. Gibt man anstatt einer IP ein ’*’
an, wird auf jeder an den Rechner gebundenen IP-Adresse Name Virtual Host eingeschaltet.
ServerName Legt die URL fest, auf die sich der VirtualHost-Container bezieht.
ServerAlias Alternative URL’s, auf die sich der VirtualHost-Container bezieht.
DocumentRoot Das Verzeichnis in dem sich die Dokumente befinden, die von diesem
VirtualHost ausgeliefert werden dürfen.
8
Das hängt von der Konfiguration ab, die die jeweilige Distribution für den Apachen vorsieht. Anstatt
diese Konfigurationen fest in die httpd.conf zu schreiben, ist es häufig so angelegt, dass virtuelle Server
dynamisch generiert werden können, ohne den Apache jedes Mal neu starten zu müssen. SuSE verwendet
beispielsweise ein eigenes Unterverzeichnis /etc/apache2/vhosts.d
9.7. SSL (SECURE SOCKET LAYER)
135
NameVirtualHost *:80
<VirtualHost *:80>
ServerName www.my-domain.site
ServerAlias my-domain.site *.my-domain.site
DocumentRoot /srv/www/my-content
</VirtualHost>
<VirtualHost *:80>
ServerName www.otherdomain.site
DocumentRoot /srv/www/othercontent
</VirtualHost>
Diese Konfiguration besagt, dass die virtuellen Server auf Port 80, egal auf welche IP,
angesprochen werden. Es werden jeweils gültige Domainnamen definiert, sowie Stammverzeichnisse festgelegt.
Alternativ wird bei einem IP-basierten virtuellen Webserver jeder Domain, die der Server bedienen soll eine eigene IP zugeordnet. Da IP-Adressen jedoch meistens knapp sind,
wird dieses oft nur für SSL-gesichterte Sites eingesetzt.
Möchte ein Client auf eine Domain zugreifen, dann muss er beim zuständigen DNSServer nach der IP Adresse des Domainnamens fragen und kann den Webserver dann über
diese IP Adresse ansprechen.
Um diese Art virtuelle Webserver einzurichten, muss ein Webserver-Admin in der Konfigurationsdatei httpd.conf, oder je nach Distribution in der passenden Include-Datei, einen
VirtualHost Container anlegen:
<VirtualHost 192.168.45.32>
ServerName www.my-first-domain.site
DocumentRoot /srv/www/my-first-domain/htdocs
</VirtualHost>
<VirtualHost 192.168.56.23>
ServerName www.my-second-domain.site
DocumentRoot /srv/www/my-second-domain/htdocs
</VirtualHost>
Im obigen Beispiel wurden zwei VirtualHost Container angelegt, welche als Attribut die
IP-Adresse mit führen. Bei einem IP basierten virtuellen Webserver müssen diese natürlich
verschieden sein. Mit der Direktive ServerName wird DomainNamen konfiguriert, also unter
welchem DNS-Namen der Server erreichbar sein soll. Die Direktive DocumentRoot legt die
Dokumentenwurzel des virtuellen Webservers fest. Sie ist der Pfad zu dem Verzeichnis in
dem die entsprechenden Webseiten lagern.
9.7
SSL (Secure Socket Layer)
Daten werden über das HTTP Protokoll standardmäßig im Klartext übertragen und stellen
gerade in Bezug mit vertraulichen Daten ein Sicherheitsrisiko dar. Gerade in Bereichen mit
persönlichen oder wirtschaftlich relevanten Daten sollten gesicherte Verbindung zum Einsatz kommen. SSL ist eine Technik um Verbindungen zu verschlüsseln. Diese Verschlüsselung setzt oberhalb von TCP an und kann deshalb auch für andere TCP-basierte Dienste
eingesetzt werden.
Für die verschlüsselte Übertragung sensibler Daten von oder zu einer Webseite ist
das HTTPS (HyperText Transfer Protokol Secure) definiert. Bei einer Anfrage, die mit
https:// beginnt, wird eine sichere, d.h. verschlüsselte, Verbindung vom Client zum Webserver aufgebaut. Die HTTPS-Anfragen nimmt der Webserver, wenn nichts anderes eingestellt
ist, auf Port 443 entgegen.
136
KAPITEL 9. WEBSERVER
9.7.1
Funktionsweise
Für eine verschlüsselte Verbindung muss zumindest ein Kommunikationsschlüssel ausgetauscht werden, mit dem beide Seiten dann arbeiten. Zur Kommunikation wird aus Performanzgründen ein symetrisches Verschlüsselungsverfahren eingesetzt. Der Kommunikationsschlüssel wird über ein Public-Key-Verfahren ausgetauscht. Dazu benötigt mindestens der
Webserver einen öffentlichen und einen privaten Schlüssel. Bei einem Verbindungsaufbau,
schickt der Webserver ein x509-Certificate, das seinen öffentlichen Schlüssel und seinen Namen beinhaltet, an den Client. Anhand dieses Certificates kann der Client einen Webserver,
dem er einmal vertraut hat, wiedererkennen und mit Hilfe des öffentlichen Schlüssels einen
Vorschlag für einen Kommunikationsschlüssel machen. Ist das Certificate von einer Instanz
signiert, der der Client vertraut, kann er auch einem Webserver vertrauen, den er noch
nicht kennt.9 Abbildung ?? zeigt, wie dem Webserver sein Certificate übergeben wird. Dabei müssen das zu verschickende Certificate mit dem öffentlichen Schlüssel und (! in einer
anderen Datei) der private Schlüssel angegeben werden.
SSLCertificateFile
SSLCertificateKeyFile
9.7.2
/etc/httpd/ssl.crt/server.crt
/etc/httpd/ssl.key/server.key
Zertifikate
Zertifikate10 sind signierte Informationen über eine Instanz. Ein Certificate enhält mindestens einen eindeutigen Namen und den öffentlichen Schlüssel der Instanz.
Damit eine andere Instanz das Certificate anerkennen kann, muss es von einer dritten
Instanz, der beide Vertrauen, unterzeichnet sein. Das gilt als Beglaubigung, dass das Certificate “echt” ist. Eine solche vertrauensvolle Instanz nennt man Certificate Authorisation
(CA).
Der Name der Instanz wird in dem Certificate in der von LDAP bekannten Objektorientierten schreibweise angegeben (zB.: ”C=de, O=uni-math, CN=www.uni-math.gwdg.de”).
Dabei ist es für das Certificate eines Webservers wichtig, dass der Eintrag CN (CommonName) die URL des Webservers beinhaltet.
Mit dem Paket openssl kommt das Perl-Skript CA.pl, das bei der Erzeugung und
Verwaltung von Certificaten hilft.
/usr/share/ssl/misc/CA.pl -newcert|-newreq|-newca|-sign|-verify
CA.pl benutzt openssl zur Bearbeitung von Certificaten. Eine ausgiebige Lektüre der
Manpage von openssl kann dieses Skript überflüssig machen und versetzt in die Lage, Certificate feiner zu beeinflussen.
Eine umfangreiche und gute Beschreibung des Umganges mit Certificaten findet man
unter http://www.tldp.org/HOWTO/SSL-Certificates-HOWTO/.
9.7.3
Zertifikate erzeugen
Folgende Schritte führen zu einem Server-Certificate in der Datei newreq.pem und dem
entschprechenden privaten Schlüssel in wwwkeyunsecure.pem.
CA.pl -newcert Certification Authority und ca-Certificat erstellen
9
10
So ist das Prinzip, in Wirklichkeit ist das Ganze ein bischen komplizierter.
engl. certificates
9.8. CGI (-MODUL)
137
CA.pl -newreq Certificate-Request. Erzeugt ein neues Certificate. Für ein WebserverCertificate ist darauf zu achten, als CN den Namen der Webseite anzugeben.
CA.pl -sign das neue Certificat mit dem ca-Certificat signieren
openssl rsa -in newreq.pem -out wwwkeyunsecure.pem Passphrase aus dem Certificat entfernen und den Privat-Key in eine eigene Datei auslagern
Es ist zu empfehlen, für die ersten Versuche ein Verzeichnis anzulegen, in das man CA.pl
kopiert und dort die entsprechenden Befehle aufruft.
9.7.4
Integration
Hat man den Schlüssel erfolgreich erstellt, kann man in der Konfigurationsdatei httpd.conf
oder je nach Distribution der passenden Include-Daten das Modul für ein Verzeichnis aktivieren. Dieses geschieht in der Regel mit einem IP-basierten11 virtuellen Host:
Listen 443
<VirtualHost *:443>
DocumentRoot /srv/www/htdocs/ssl-gesichert
ServerName 192.168.2.1:443
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key
</VirtualHost>
Durch die Listen-Direktive in der ersten Zeile sagt ein Admin dem Apache Webservern,
dass er auf dem Port 443 antworten soll. Dann wird in einem VirtualHost-Container eingerichtet. In diesem schaltet die Direktive ”SSLEngine on” die SSLUnterstützung für diesen
virtuellen Server an. Mit den beiden Direktiven SSLCertificateFile und SSLCertificateKeyFile gibt man den Pfad zu dem SSL-Zertifikat und SSL-Schlüssel an.
Die Pfade in denen sich diese beiden Dateien befinden sollten natürlich ausreichend
geschützt sein, damit ein potenzieller Angreifer keine Möglichkeit hat an den SSL-Schlüssel
zu gelangen - ansonsten wäre diese Verschlüsselung wertlos.
9.8
CGI (-Modul)
CGI (Common Gateway Interface) definiert eine Schnittstelle, die die Kommunikation zwischen Webservern und Programmen erleichtert. HTML-Dokumente können Variablen mittels Form-Tags über CGI an Programme übergeben. Diese sogenannten CGI-Progamme
generieren oft wieder ganze Webseiten. So kann man ganze Internetauftritte über CGIProgramme steuern.
Für die Variablenübergabe gibt es zwei Methoden.
GET-Methode Die Variablen werden als Teil der URL übergeben. Man hat die Möglichkeit, einen Aufruf mit den Variablendefinitionen selbst zu formulieren, zB. direkt in
die Adresszeile des Browsers einzugeben. Dabei werden die Variablen mit Wertzuweisung nach einem ’ ?’ an die URL angehängt. Mehrere Variablen-Wert-Paare werden
dabei durch ein ’&’ getrennt.
11
Mit der namensbasierten Variante stößt man hier an die Grenzen, denn bevor der Browser in dem
HTTP-Header den Domainnamen sendet, erfolgt das SSL Handshake. Zu diesem Zeitpunkt ist jedoch nur
die IP Adresse und die Portnummer bekannt, welche bei den namensbasierten virtuellen Webservern zu
mehreren Domains führen kann.
138
KAPITEL 9. WEBSERVER
POST-Methode Die Variablen werden im Request-Header übergeben, sind also für den
Benutzer nicht sichtbar. Das macht es für dritte zumindest schwerer, etwas über das
Programm oder die Übertragenen Variablen heraus zu finden.
http://www.example.com/cgi-bin/script.cgi?var1=value1&var2=value2
Abbildung 9.4: Variablenübergabe per GET-Methode
Grundsätzlich kann jede Art von Programm oder Skript vom Webserver Apache ausgeführt werden. Es ist dem Webserver aber nicht erlaubt, beliebige Programme auszuführen.
Man muss für Verzeichnisse in denen CGI-Programme ausgeführt werden sollen, die Option
ExecCGI setzen12 und eine (oder mehrere) Dateiendungen definieren. Nur Dateien, die die
eingetragene Endung haben und sich in einem Verzeichnis befinden, für das ExecCGI gesetzt
ist, werden vom Webserver als CGI-Script aufgerufen.
Aus Sicherheitsgründen sollte man die Ausführung von Programmen nur ausserhalb
von DocumentRoot erlauben. Oft wird die Ausführung nur für ein cgi-bin genanntes
Verzeichnis erlaubt, das sich ausserhalb von DocumentRoot befindet.
In Abbildung 9.5 wird erst ein Alias auf das cgi-bin Verzeichnis gesetzt. Mit AddHandler
wird definiert, dass Dateien mit der Endung .cgi als cgi-script interpretiert werden.
Innerhalb eines Directory-Containers bezüglich /usr/local/httpd/cgi-bin/ wird die Option ExecCGI zu den geltenden Optionen hinzugefügt.
ScriptAlias
/cgi-bin/
AddHandler
cgi-script
.cgi
<Directory /usr/local/httpd/cgi-bin/>
Options +ExecCGI
</Directory>
/usr/local/httpd/cgi-bin/
Abbildung 9.5: mod cgi
9.9
PHP
Bei den statischen Webinhalten sind die HTML-Seiten, welche der Webserver ausliefern
soll, üblicherweise als Datei abgelegt. Der Webserver liefert einfach die komplette Datei
aus, wenn ein Client die entsprechende Resource anfragt.
Bei den dynamischen Webinhalten dagegen wird die HTML-Ausgabe erst mit Hilfe einer
Skriptsprache zur Laufzeit erzeugt. Hier gibt es wieder zwei unterschiedliche Techniken, die
Clientseitigen und die Serverseitigen.
Die clientseitigen Skriptsprachen werden auf dem Clients selbst ausgeführt. Hierzu zählt
zum Beispiel die Eingabe von Formularfeldern. Die HTML Seite, welche vom Webserver
ausgeliefert wird, enthält den Quelltext der jeweiligen Skriptsprache, der dann vom Client
geparst und ausgeführt wird. Das bekannteste und eines der ältesten Beispiele einer clientseitigen Skriptsprache ist Javascript. Die Auswahl wuchs im Laufe der Zeit, so dass Flash,
Java oder ActiveX inzwischen von vielen Browsern oder ihren Erweiterungen unterstützt
werden. Damit der Client den Quelltext ausführen kann, ist natürlich die Unterstützung
12
siehe Kapitel 9.5.1
9.9. PHP
139
der Skriptsprache erforderlich. Dies geschieht mit Hilfe von Plugins, die der Benutzer im
Client installieren muss. Hier fangen dann oft die Probleme an:
• Die Performance ist da ein entscheidender Faktor. Bei den clientseitigen Skriptsprachen muss der Client selbst die Rechenleistung, welche für die Ausführung des Codes
notwendig ist, bereitstellen.
• Unter Sicherheitsaspekten schneiden clientseitige Implementierungen oft schlecht ab,
da ein Skript auf dem Client-Rechner oft beliebigen Code ausführen kann und damit
auch Manipulationen am System selbst vornehmen könnte.
• Die Browserunterstützung zählt zu den weiteren Problemen, mit welchem sich die
clientseitigen Skriptsprachen befassen müssen. Denn nicht für jeden Web-Browser
existiert ein passendes Plugin.
• Der Netzwerktraffic schafft oft ein weiteres Problem. Man stelle sich vor, dass man ein
clientseitiges Flash-Skript, welches mehrere Megabyte groß ist, hat. Auch wenn man
nur einen kleinen Teil des Flashskriptes benötigt, muss man das komplette Skript
vor der Ausführung herunterladen, was einen u.U. unverhältnismässig hohen Netzwerktraffic mit sich bringt, der gerade für kleine mobile Endgeräte problematisch sein
kann.
Diese Art der Probleme tritt nicht auf, wenn man auf serverseitige Skriptsprachen setzt.
Diese verändern oder generieren die HTML-Seite noch vor der Auslieferung an den Client.
Wird also eine Anfrage an einen Webserver gestellt, dann wird der Quelltext des Skripts
noch auf dem Webserver geparst und ausgeführt. Die serverseitigen Skriptsprachen können
wiederum ihre Daten aus Datenbanken beziehen, wie das oft bei den Content Management
Systemen (CMS) der Fall ist.
Ist das komplette Skript abgearbeitet, dann wird die erzeugte HTML-Seite an den Client
ausgeliefert. Hier wird natürlich die Unterstützung der Skriptsprache durch den Webserver
vorausgesetzt. Das bedeutet, dass nur Netztraffic in Höhe der generierten Seite anfällt
und sich die Sicherheitsrisikten für die Endanwender in Grenzen halten. Sie bekommen ja
statisches HTML zu sehen.
Diese Erweiterungen werden üblicherweise durch Module integriert. Bekanntestes Beispiel dürfte bei den serverseitigen Skriptsprachen PHP mit deinem Apache Modul mod php4
sein. Weitere gängige serverseitige Programmiersprachen stehen mit ASP und JSP zur
Verfügung.
Auch bei serverseitigen Skriptsprachen sollten einige Aspekte beim Einsatz beachtet
werden. Das permanente Generieren von Seiten ”on-demand” kann die komplette Rechenleistung auf dem Webserver beanspruchen, was je nach Zugriffscharakteristik zu Einbußen
in der Performance führen kann.
9.9.1
Das Apache-PHP-Modul
Das Modul mod php bietet die Möglichkeit, PHP-Code innerhalb von HTML-Seiten auszuführen. Für Dateien, die vom PHP-Interpreter geparst werden sollen, muss eine Endung
definiert werden (Abbildung 9.6).
Der PHP-Interpreter gibt den eingelesen HTML-Code unverändert an den Client weiter.
PHP-Code wird interpretiert und das Ergebnis direkt an den Client weiter gegeben. Für
den Client sieht das so aus, als würde er eine reine HTML-Seite erhalten.
140
KAPITEL 9. WEBSERVER
<IfModule mod_php4.c>
AddType
AddType
AddType
</IfModule>
application/x-httpd-php
application/x-httpd-php
application/x-httpd-php-source
.php
.php4
.phps
Abbildung 9.6: mod php
<html>
<body>
<?php
print ’’<h1>’’.$titel.’’ ’’.$number.’’</h1>’’;
?>
..
.
Abbildung 9.7: PHP-Code
9.10
SSI (Server Side Includes)
Apache stellt mit SSI eine Möglichkeit zur Verfügung, Internetseiten mit dynamischen Inhalten zu versehen. Um SSI verfügbar zu machen, muss zumindest für einen Teil der Dateihierachie innerhalb von DocumentRoot die Option Include (siehe Kapitel 9.5.1) gesetzt
sein. Ausserdem muss ein Dateityp an die Funktionalität gebunden werden (Abbildung 9.8).
<Directory /home/www/ssi_here/>
AddHandler
server-parsed
AddType
text/shtml
Options +Include
</Directory>
.shtml
.shtml
Abbildung 9.8: mod ssi
SSI-Befehle werden innerhalb des HTML-Codes mit <!--# eingeleitet und mit --> abgeschlossen. SSI-Dateien werden vom Server geparst und die SSI-Befehle entsprechend interpretiert. Das Ergebniss der Interpretation wird an der Stelle des Befehls in die HTML-Seite
eingesetzt. SSI definiert eine Vielzahl von Umgebungsvariablen, bietet die Möglichkeit Systemprogramme auszuführen und beinhaltet Befehle zur Flusskontrolle (Abbildung 9.9).
Viele Internet-Benutzer sehen dieses nur als WWW. Jedoch ist es nur eine Teilmenge der
TCP/IP-Suite. Das Protokoll des World Wide Web heisst HTTP. Es ist die Standardsprache
des modernen WWW.
Der für den Anwender sichtbare Vorgang des Abrufs eines Dokuments besteht in der
Regel aus der Eingabe einer URI oder dem Anklicken eines Links, gefolgt von der Darstellung der Daten oder einer Fehlermeldung. Diese einfache Art und Weise der Benutzung hat
viel zur breiten Akzeptanz des Internets beigetragen.
9.11. ÜBERBLICK
141
<html>
<!--#echo "$DOCUMENT_NAME last modified: $LAST_MODIFIED" -->
...
<!--#exec cmd="ls -la" -->
...
</html>
Abbildung 9.9: SSI-Code
9.11
Überblick
Im Zusammenhang mit WWW und dem dafür hauptsächlich zuständigen Protokoll der
Applikationsschicht HTTP spielen einige Bezeichnungen eine Rolle:
• Ressource - ist die Quelle eines Webinhalts, der durch eine URI identifiziert werden
kann. Der einfachste Typ der Ressource ist eine statische Datei im Filesystem des
Web-Servers. Typ und Inhalt der Datei sind beliebig. Außerdem kann die Ressource
auch ein Programm sein, welches bei Aufruf einen bestimmten Inhalt generiert und
ausliefert.
• URI - Uniform Resource Identifier bezeichnet den weltweit eindeutigen Name für eine
Ressource. z.B http://www.goe.net/index.php)
• URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name für die
Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar.
• URN - Uniform Ressource Name, ein spezialer Typ von URI, auch weltweiter eindeutig. z.B. urn:isbn:0-596-00962-3
Die Enwicklung des WWW begann mit HTTP/0.9, einer Prototyp-Version, die von Tim
Berners-Lee am CERN in den Jahren 1990/1991 entwickelt wurde. HTTP /0.9 kennt lediglich die GET-Methode. HTTP/1.0 war die erste Version, die weit entwickelt zum Standard
wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DELETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wird genauer spezifiziert.
HTTP/1.0 ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Es handelt sich
jedoch nur um eine rudimentäre Authentifizierung, da das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann.
Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich
auf die Korrektur der Designfehler, das Spezifizieren von Semantik, einigen PerformaceOptimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher für jede Resource
eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads
fortgesetzt werden. Über Cookies in den Header-Informationen können Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, ...) zuordnen können. Dadurch
können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Die Methoden sind auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver
überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver
142
KAPITEL 9. WEBSERVER
über die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene.
HTTP/1.1 umfasste auch die Unterstützung für die höher entwickelten Netzanwendungen
und Entwicklungen, die in den späten neunziger Jahren waren.
9.12
HTTP-Kommunikation
Viele Internet-Benutzer sehen dieses nur als WWW. Jedoch ist es nur eine Teilmenge der
TCP/IP-Suite. Das Protokoll des World Wide Web heisst HTTP. Es ist die Standardsprache
des modernen WWW.
Der für den Anwender sichtbare Vorgang des Abrufs eines Dokuments besteht in der
Regel aus der Eingabe einer URI oder dem Anklicken eines Links, gefolgt von der Darstellung der Daten oder einer Fehlermeldung. Diese einfache Art und Weise der Benutzung hat
viel zur breiten Akzeptanz des Internets beigetragen.
9.13
Überblick
Im Zusammenhang mit WWW und dem dafür hauptsächlich zuständigen Protokoll der
Applikationsschicht HTTP spielen einige Bezeichnungen eine Rolle:
• Ressource - ist die Quelle eines Webinhalts, der durch eine URI identifiziert werden
kann. Der einfachste Typ der Ressource ist eine statische Datei im Filesystem des
Web-Servers. Typ und Inhalt der Datei sind beliebig. Außerdem kann die Ressource
auch ein Programm sein, welches bei Aufruf einen bestimmten Inhalt generiert und
ausliefert.
• URI - Uniform Resource Identifier bezeichnet den weltweit eindeutigen Name für eine
Ressource. z.B http://www.goe.net/index.php)
• URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name für die
Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar.
• URN - Uniform Ressource Name, ein spezialer Typ von URI, auch weltweiter eindeutig. z.B. urn:isbn:0-596-00962-3
Die Enwicklung des WWW begann mit HTTP/0.9, einer Prototyp-Version, die von Tim
Berners-Lee am CERN in den Jahren 1990/1991 entwickelt wurde. HTTP /0.9 kennt lediglich die GET-Methode. HTTP/1.0 war die erste Version, die weit entwickelt zum Standard
wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DELETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wird genauer spezifiziert.
HTTP/1.0 ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Es handelt sich
jedoch nur um eine rudimentäre Authentifizierung, da das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann.
Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich
auf die Korrektur der Designfehler, das Spezifizieren von Semantik, einigen PerformaceOptimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Antworten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher für jede Resource
eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads
fortgesetzt werden. Über Cookies in den Header-Informationen können Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, ...) zuordnen können. Dadurch
9.14. HTTP-KOMMUNIKATION
143
können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Die Methoden sind auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver
überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver
über die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene.
HTTP/1.1 umfasste auch die Unterstützung für die höher entwickelten Netzanwendungen
und Entwicklungen, die in den späten neunziger Jahren waren.
9.14
HTTP-Kommunikation
Viele Internet-Benutzer sehen dieses nur als WWW. Jedoch ist es nur eine Teilmenge der
TCP/IP-Suite. Das Protokoll des World Wide Web heisst HTTP. Es ist die Standardsprache
des modernen WWW.
Der für den Anwender sichtbare Vorgang des Abrufs eines Dokuments besteht in der
Regel aus der Eingabe einer URI oder dem Anklicken eines Links, gefolgt von der Darstellung der Daten oder einer Fehlermeldung. Diese einfache Art und Weise der Benutzung hat
viel zur breiten Akzeptanz des Internets beigetragen.
9.15
Überblick
Im Zusammenhang mit WWW und dem dafür hauptsächlich zuständigen Protokoll der
Applikationsschicht HTTP spielen einige Bezeichnungen eine Rolle:
• Ressource - ist die Quelle eines Webinhalts, der durch eine URI identifiziert werden
kann. Der einfachste Typ der Ressource ist eine statische Datei im Filesystem des
Web-Servers. Typ und Inhalt der Datei sind beliebig. Außerdem kann die Ressource
auch ein Programm sein, welches bei Aufruf einen bestimmten Inhalt generiert und
ausliefert.
• URI - Uniform Resource Identifier bezeichnet den weltweit eindeutigen Name für eine
Ressource. z.B http://www.goe.net/index.php)
• URL - Uniform Resource Locator ist eine Unterart von URI, lokaler Name für die
Ressource, sie bleiben anhand ihres Pfades voneinander unterscheidbar.
• URN - Uniform Ressource Name, ein spezialer Typ von URI, auch weltweiter eindeutig. z.B. urn:isbn:0-596-00962-3
Die Enwicklung des WWW begann mit HTTP/0.9, einer Prototyp-Version, die von Tim
Berners-Lee am CERN in den Jahren 1990/1991 entwickelt wurde. HTTP /0.9 kennt lediglich die GET-Methode. HTTP/1.0 war die erste Version, die weit entwickelt zum Standard
wurde. Es kamen Versionsnummern, HTTP-Header, zusätzliche Methoden (Head, Post, DELETE, LINK, UNLINK) und die Behandlung von Multimedia-Inhalten hinzu. Das Nachrichtenformat von Antworten und Anfragen wird genauer spezifiziert.
HTTP/1.0 ermöglicht die Beschränkung des Zugriffes auf Ressourcen. Es handelt sich
jedoch nur um eine rudimentäre Authentifizierung, da das Passwort unverschlüsselt übertragen wird und der Server sich dem Client gegenüber nicht authentifizieren kann.
Die Weiterentwicklung endete 1997 mit HTTP/1.1. Diese Version konzentrierte sich
auf die Korrektur der Designfehler, das Spezifizieren von Semantik, einigen PerformaceOptimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Ant-
144
KAPITEL 9. WEBSERVER
worten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten Bildern wird so nur eine TCP-Verbindung benötigt, wo vorher für jede Resource
eine separate aufgebaut wurde. Zudem können bei HTTP/1.1 abgebrochene Downloads
fortgesetzt werden. Über Cookies in den Header-Informationen können Anwendungen realisiert werden, die Statusinformationen (Benutzereinträge, ...) zuordnen können. Dadurch
können Webanwendungen, die Status- bzw. Sitzungseigenschaften erfordern, realisiert werden. Auch eine Benutzerauthentifizierung ist möglich. Die Methoden sind auch weiter entwickelt. HTTP/1.1 bietet eine TRACE-Methode, mit der man den Weg zum Webserver
überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver
über die verschiedenen Proxies hinweg zu ermitteln, ein Traceroute auf Anwendungsebene.
HTTP/1.1 umfasste auch die Unterstützung für die höher entwickelten Netzanwendungen
und Entwicklungen, die in den späten neunziger Jahren waren.
9.16
HTTP-Kommunikation
9.17
Dokumentation
Eine umfangreiche und gut strukturierte Dokumentation findet man unter:
http://www.apache.org.
Der wohl am meisten verbreitete Webserver (nicht nur in der Linux-/Unixwelt) ist der
Apache httpd. Er unterstützt eine ganze Reihe von Skriptsprachen, wie Perl und PHP über
Module, Sicherungsmechanismen, wie SSL und weitere Plugins. Die Konfigurationsdateien
(Hauptdatei: httpd.conf und SSL-Keys sind unterhalb von /etc/httpd zu finden.
Kapitel 10
Mail
Elektronische Post (E-Mail) ist sicher eine der wichtigsten und beliebtesten Anwendungen
im Internet. Der Austausch von Nachrichten ist dabei gleichzeitig einer der ältesten Dienste
im Netz. Um mit einer Linux-Maschine Mail versenden und empfangen zu können, reicht
es im einfachsten Fall aus, die passenden Einstellungen in einem der vielen Mail-Clients
vorzunehmen. Inzwischen stehen hierfür eine ganze Reihe von Programmen zur Verfügung;
angefangen mit den ausschliesslich konsolenbasierten Programmen, wie pine oder mutt bis
hin zu ”ausgewachsenen” grafischen Anwendungen, wie kmail, thunderbird bzw. mozilla
oder evolution. Diese Programme, die zum Einliefern von Mails an Server und zum Empfang dienen, werden als MUA (Mail User Agent) bezeichnet. Manchmal findet man noch
die Bezeichnung MRA (Mail Retrieval Agent). Dieses sind Programme die automatisiert
Mails von einem Server holen und für den lokalen Zugriff auf dem System des Benutzers
ablegen. Hierzu zählt beispielsweise fetchmail.
Serverpgrogramme, die Mails weiterverschicken und in den lokalen Mailboxen der Emfänger ablegen, nennt man MTA (Mail Transfer Agent). Für letzteres kommen oft externe Programme zum Einsatz, die dann MDA (Mail Delivery Agent) heissen. MTAs lassen
sich selbstverständlich mit Linux als Server aufsetzen. Es stehen dabei mehrere Implementierungen des SMTP (Simple Mail Transfer Protocol) zur Verfügung. Das älteste und
umfangreichste Paket ist sicherlich ”Sendmail” (sendmail), wobei wegen der kryptischen
Bedienbarkeit sich weitere Implementationen, wie ”Exim” (exim) oder auch ”ProcMail”
(procmail) durchsetzen konnten.
Dies ist jedoch nur die eine Seite des Postamtes. Der User holt sich seine ”postlagernden”
Sendungen entweder mit POP3 (Post Office Protocol) ab und sieht sie ein bzw. verwaltet
sie mit IMAP4.
• SMTP (Simple Message Transfer Protocol) Es ist das Übertragungsprotokoll der Server untereinander und wird von den Clients zun Einliefern der Post benutzt.
• POP (Post Office Protocol; derzeit aktuell in der Version 3) Die Clients benutzen es,
um ihre Post vom Server abzuholen. Entgegen dem SMTP besteht dabei die Möglichkeit, die Mail auch teilweise auf dem Server zu verwalten (allerdings nur in beschränktem Maße).
• IMAP (Internet Mail Access Protocol; derzeit aktuell in der Version 4) IMAP wird
wie POP 3 von den Clients benutzt, um Mails vom Server abzuholen. Es bietet aber
gegenüber POP wesentlich mehr Flexibilität bei der Verwaltung der Post, so z.B. die
Möglichkeit, Eingangskörbe auf dem Server zu verwalten oder auch Roaming Users,
also Anwender, die von verschieden Orten aus auf den Server zugreifen wollen.
145
146
KAPITEL 10. MAIL
• LDAP (Lightweight Directory Access Protocol) Eine “leichte” Variante des DAP (Directory Access Protocol), welches von X.500 für den Zugriff auf die Datenbasis benutzt wird. LDAP wird derzeit von den neueren Mailclients (Outlook, Netscape) unterstützt, um auf globale Verzeichnisdienste zuzugreifen (Netcenter, VeriSign, Bigfoot
etc.)
10.1
SMTP
Im Folgenden geht es um das Prinzip hinter Mail Transfer Agents - Programme, die E-Mail
entgegennehmen und weiterleiten. SMTP (Simple Mail Transfer Protokol) ist ein Protokoll
zur Übertragung von E-Mail zwischen zwei MTAs. Ein MTA kann als Client (SMTP-Client)
oder als Server (SMTP-Server) an einer SMTP-Kommunikation beteiligt sein1 . Der SMTPClient baut über Netzwerk eine Verbindung zu dem SMTP-Server auf, um an diesen EMail zu übertragen. Das Übertragen einer E-Mail, inklusive der relevanten Daten, wird als
Mailtransfer bezeichnet. Eine abgeschlossene Kommunikation per SMTP wird als SMTPSitzung bezeichnet. Während einer SMTP-Sitzung können mehrere E-Mails übertragen
werden.
SMTP definiert Befehle und Antwort-Codes. Befehle werden vom SMTP-Client an den
SMTP-Server gesendet. Mit diesen SMTP-Befehlen kann der Client die Kommunikation
steuern. Antwort-Codes werden vom SMTP-Server als Reaktion auf die empfangenen Befehle an den SMTP-Client gesendet.
SMTP enthält mittlerweile deutlich mehr Funktionalitäten, als zum einfachen Übertragen von E-Mail nötig sind.
HELO hostname|domain Mit HELO leitet der SMTP-Client die Kommunikation ein. Als
Parameter soll der Hostname des Clients gesendet werden. Der Parameter muss vorhanden sein, wird aber nicht überprüft. 2
EHLO hostname|domain Identisch zu HELO, nur dass der Client damit zu verstehen gibt,
dass er einen erweiterten SMTP-Befehlssatz (des ESMTP) unterstützt. Der Server soll
daraufhin mitteilen, welche Erweiterungen des Befehlssatzes für die Kommunikation
zur Verfügung stehen.
MAIL Dieser Befehl leitet das Übertragen einer E-Mail ein. Als Parameter muss die Absenderadresse übergeben werden.
RCPT Dieser Befehl kann beliebig oft auf MAIL folgen. Mit jedem Aufruf wird eine
Empfängeradresse übergeben. Es muss mindestens ein Aufruf von RCPT erfolgen.
DATA Mit DATA signalisiert der SMTP-Client, dass er den Inhalt (Mail-Body) der EMail übertragen möchte. Nach einer positiven Antwort des Servers wird die E-Mail
zeilenweise übertragen. Ein Zeile, die ausschliesslich einen Punkt (’.’) enthält, beendet
die Übertragung des Inhalts der E-Mail.
QUIT Um die Kommunikation zu beenden, sendet der SMTP-Client den Befehl QUIT.
Eine erschöpfende Beschreibung von SMTP liefert RFC 2821. RFCs (Requests for Comments) sind öffentlich zugängliche Dokumente, die Standartprotokolle (in IP-basierten Net1
2
siehe Client-Server-Modell
Zu den Begriffen Host und Domain siehe Kapitel DNS.
10.1. SMTP
147
zen) definieren. Diese Dokumente werden von der Internet Engineering Task Force (IETF)
veröffentlicht und sind über verschiedene Webseiten verfügbar3 .
Die Übertragung von E-Mail ist einer der ältesten und meist genutzten NetzwerkDienste. 1971 entwickelte Ray Tomlinson ein Verfahren zur Übertragung von Textnachrichten über ein Netzwerk. Mit den Programmen SNDMSG und READMAIL war die erste
Komunikation per E-Mail möglich. Im Laufe der Jahre entwickelte sich das Verfahren stark
weiter.
Jonathan B. Postel veröffentlichte 1981 die erste Spezifikation von SMTP als RFC 788.
1982 wurde diese durch RFC 821 (auch von Postel) ersetzt. Anfang der 90er Jahre (19931995) wurden mehrere Erweiterungen zu SMTP spezifiziert, die 2001 schliesslich zu RFC
2821 führten, welches die vorherigen ersetzt.
10.1.1
E-Mail-Adresse
Eine E-Mail-Adresse besteht aus einem Local Part und einem Domain Part. Beide werden durch ein ’@’-Zeichen voneinander getrennt. Der Local Part besteht aus dem - auf
dem empfangenden System bekannten - Namen des Empfängers. Der Domain Part bezeichnet die Empfänger-, bzw. die Absenderdomain. Er besteht aus einer weltweit eindeutigen
Domainbezeichnung. Diese Domainbezeichnung identifiziert das empfangende System und
muss über DNS auflösbar sein (siehe DNS). (RFC 2142)
10.1.2
Versenden einer E-Mail
Am Versand einer E-Mail sind mehrere sogenannte Agenten beteiligt. Ein Programm zum
Lesen und Verfassen von E-Mail wird als Mail User Agent (MUA) bezeichnet. Eine EMail kann während des Transfers mehrere Mail Transfer Agents (MTA, siehe Kapitel
SMTP) durchlaufen. Als Mail Delivery Agent (MDA) bezeichnet man ein Programm,
das E-Mail lokal für den Empfänger verfügbar macht. Ein MDA bekommt eine E-Mail von
dem lokalen MTA übergeben und speichert diese in der Inbox4 des Empfängers.
Als Outgoing-SMTP-Server einer Domain bezeichnet man einen MTA, an den alle zu
versendenden E-Mails einer Domain per SMTP übertragen werden. Dieser übernimmt die
weitere Auslieferung.
Ein Mailexchanger ist ein MTA, der für die Annahme von E-Mail für eine bestimmte Domain zuständig ist. Der Name und damit die IP-Adresse des Mailexchangers einer
Domain muss über DNS in einem MX-Record verfügbar sein (siehe Kapitel DNS). Der
Mailexchanger verfügt über Informationen zur weiteren Auslieferung einer E-Mail innerhalb seiner Domain. Diese kann per SMTP an einen weiteren MTA oder an einen lokalen
MDA erfolgen.
Eine in einem MUA verfasste E-Mail wird an den lokalen MTA übergeben, der sie
per SMTP an den Outgoing-SMTP-Server seiner Domain übermittelt5 . Dieser wiederum
sendet sie an den Mailexchanger der Empfängerdomain, welcher für die lokale Zustellung
der E-Mail in die Inbox des Empfängers zuständig ist.
Tabelle 10.1 zeigt eine typische einfache SMTP-Sitzung zum Übertragen einer E-Mail.
Der SMTP-Client nimmt Kontakt zum SMTP-Server auf, der die Kontaktaufnahme mit
dem Antwort-Code 220 und Informationen über sich selbst bestätigt. Daraufhin leitet der
Client die Kommunikation mit HELO ein. Die mit HELO übergebene Zeichenkette soll der
Identifikation dienen, wird aber an dieser Stelle ungeprüft übernommen. Wie es sich für
3
http://www.ietf.org/rfc, http://www.faqs.org/rfcs u.a.
Im Deutschen oft einfach als Posteingang bezeichnet.
5
Viele MUAs sind in der Lage, die Aufgabe eines SMTP-Clients selbst zu übernehmen.
4
148
KAPITEL 10. MAIL
Server:
Client:
S:
C:
S:
C:
S:
C:
S:
C:
220 golem.ehlers-schwichtenberg.info ESMTP Postfix
HELO schwichtenberg.net
250 golem.ehlers-schwichtenberg.info
MAIL FROM: <fschwic@schwichtenberg.net>
250 Ok
RCPT TO: <fschwic@ehlers-schwichtenberg.info>
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Der Mail-Body
.
S: 250 Ok: queued as C1AD92BC346
C: QUIT
S: 221 Bye
Tabelle 10.1: Einfache Übertragung eine E-Mail mit SMTP
einen höflichen Server gehört, antwortet dieser mit seiner eigenen Identifikation. Mit dem
Befehl MAIL wird die Übertragung der eigentlichen E-Mail - der Mailtransfer - begonnen.
Als Parameter werden ’FROM:’ und die Absenderadresse in spitzen Klammern übergeben.
Nun kann der Client wiederholt Empfängeradressen mit dem Befehl RCPT und ’TO:’ und
der Empfängeradresse in spitzen Klammern übertragen. Sowohl der Befehl MAIL als auch
jeder Aufruf von RCPT wird bei Erfolg von dem Server mit dem Antwort-Code 250 OK
beantwortet. Einige SMTP-Server überprüfen die Existenz der Absenderadresse. In jedem
Fall sollte der Server überprüfen, ob er für die Zustellung von E-Mail für die Empfängeradressen zuständig ist. Bei negativem Ergebnis sendet der Server einen Fehler-Code, um
die Annahme der E-Mail abzulehnen. 4xy bezeichnet einen temporären Fehler; der Client
kann zu einem späteren Zeitpunkt erneut versuchen, die Mail an diesen Server auszuliefern. 5xy bezeichnet einen permanenten Fehler; der Client braucht keine erneute Zustellung
dieser Mail an diesen Server zu versuchen. Einen SMPT-Server, der E-Mail für jegliche
Empfängeradresse annimmt, bezeichnet man als Open-Relay (siehe Kapitel 10.1.5).
Sind alle Empfängeradresse übermittelt, wird die eigentliche Nachricht, der Mail-Body
(siehe Kapitel 10.1.3) übertragen. Der Client teilt dem Server mit dem Befehl DATA mit,
dass er den Mail-Body übertragen möchte. Der Server sendet den Antwort-Code 354, um
zu signalisieren, dass der Client mit dem zeilenweisen Übertragen der Nachricht fortfahren kann. Diese Übertragung wird mit einer Zeile, die einen einzelnen Punkt (’.’) enthält,
beendet, woraufhin der Server den Empfang mit 250 OK und der Identifikationsnummer,
unter der er die Mail verwaltet, bestätigt. Damit ist der Mailtransfer beendet. Nun kann
der Client mit MAIL einen weiteren Mailtransfer einleiten oder die Verbindung mit QUIT
beenden.
10.1.3
Mail-Body
Der Mail-Body besteht aus Headerzeilen mit Informationen über die E-Mail und - getrennt
durch eine Leerzeile - dem eigentlichen Text der Nachricht. Die meisten Headerzeilen werden
von MUAs nicht angezeigt6 . Die während der SMTP-Sitzung übertragen E-Mail-Adressen
dienen in erster Linie den MTAs zur Auslieferung bzw. zur Rückführung einer E-Mail.
6
Meistens ist es möglich, die Darstellung des kompletten Haeders einzuschalten.
10.1. SMTP
149
Return-Path: <fschwic@schwichtenberg.net>
X-Original-To: fschwic@ehlers-schwichtenberg.info
Delivered-To: fschwic@golem.ehlers-schwichtenberg.info
Received: from schwichtenberg.net (shani.schwichtenberg.net [10.1.1.1])
by golem.ehlers-schwichtenberg.info (Postfix) with SMTP id
C1AD92BC346
for <fschwic@ehlers-schwichtenberg.info>; Tue, 9 Mar 2004
21:05:52 +0100 (CET)
Message-Id: <20040309200552.C1AD92BC346@golem.ehlers-schwichtenberg.info>
Date: Tue, 9 Mar 2004 21:05:52 +0100 (CET)
From: fschwic@schwichtenberg.net
To: undisclosed-recipients:;
Der Mail-Body
Tabelle 10.2: Die E-Mail aus Tabelle 10.1
Steht nach einem Mailtransfer in dem Mail-Body noch keine mit ’From:’ beginnende
Zeile, kann der MTA diese Zeile mit der Absenderadresse einfügen. Date, Subject, To,
From oder Äquivalente sollten in einer E-Mail von vornherein vorhanden sein (RFC 822);
sie können schon bei der ersten Auslieferung der E-Mail per SMTP im Mail-Body stehen.
Die SMTP-Sitzung aus Tabelle 10.1 führt dazu, dass die E-Mail aus Tabelle 10.2 in der
Inbox des Empfängers abgespeichert wird, wobei der Empfänger in dem MUA, mit dem er
seine E-Mail liest, normalerweise nur die Zeilen “Date: ...”, “From: ...”, “To: ...” und den
Text der Nachricht angezeigt bekommt.
Ein MTA fügt zu jeder empfangenen E-Mail Haederzeilen hinzu, die bei weiteren Übertragungen per SMTP Bestandteil des Mail-Body sind.
10.1.4
E-Mail Header
Der Header einer E-Mail besteht aus mehreren Headerzeilen. Eine Headerzeile ist ein Eintrag, der mit einem Bezeichner gefolgt von einem Doppelpunkt und einem Leerzeichen
beginnt. Besteht eine Headerzeile aus mehreren Textzeilen, so müssen die folgenden Textzeilen mit einem Whitespace beginnen.
Bezeichner für Headerzeilen, die in keinem Standart definiert sind, müssen mit ’X-’
beginnen (RFC 2821).
Return-Path
Ein MTA, der eine E-Mail endgültig zustellt7 , muss die Zeile Return-Path: <adresse> an
den Anfang der E-Mail setzen. Die einzutragende Adresse ist die während des Mailtransfers
mit MAIL übergebene Absenderadresse (RFC 2821).
Received
Jeder MTA, der eine E-Mail angenommen hat, muss vor der weiteren Auslieferung eine
Received-Zeile an den Anfang des Mail-Body schreiben. Eine solche Zeile ist in drei Bereiche
7
“final delivery”; wenn der MTA die E-Mail an einen MDA übergibt oder in anderer Form aus dem
SMTP-System nimmt.
150
KAPITEL 10. MAIL
unterteilt:
1. Informationen über den SMTP-Client eingeleitet mit “from”. Dieser Bereich enthält
die Identifikation des Clients. In der Regel ist das die mit HELO oder EHLO übergebene Zeichenkette. Zusätzlich sollen in runden Klammern TCP-Informationen über den
Client eingefügt werden. Die meisten MTAs fügen die IP-Adresse des SMTP-Client
(in eckigen Klammern) und den daraus resultierenden Hostnamen ein.
2. Informationen über den SMTP-Server selbst. Beginnend mit “by” werden der Hostname des Servers und Informationen über den Empfang (meistens Art der Software,
Empfangsprotokoll und Identifikationsnummer der E-Mail im Server) eingefügt.
3. Informationen über den Empfang der E-Mail mit “for”, gefolgt von der mit RCPT
übergebenen Empfängeradresse und - getrennt durch ein Semikolon - der Zeitpunkt
des Empfangs.
Weitere Headerzeilen
“Massage-Id:” soll von dem System erzeugt werden, das die E-Mail erstellt. Diese Zeile ist
nicht zwingend erforderlich.
Date, From, To und Subject sollen von vornherein Bestandteil einer E-Mail sein (RFC
822). Der MUA in dem die E-Mail erstellt wurde sollte diese Headerzeilen eintragen. Wenn
diese nicht vorhanden sind, kann ein MTA sie einfügen.
Die Einträge “X-Original-To:” und “Deliverd-To:” aus Tabelle 10.2 werden speziell von
dem MTA Postfix eingefügt. Sie widersprechen dem Standart nicht, sind aber auch nicht
verlangt.
10.1.5
Open-Relay
Ein Open-Relay ist ein Mailexchanger oder ein Outgoing-SMTP-Server, der E-Mail von
beliebigen MTAs für beliebige Empfängeradressen annimmt und weiterleitet. Da die Angabe der Absenderadressen während einer SMTP-Sitzung nur unzureichend oder gar nicht
überprüft wird, ermöglicht ein Open-Relay jedermann das anonyme Versenden von E-Mail
(siehe Kapitel 10.1.6).
Ein Mailexchanger sollte nur E-Mail annehmen, deren Empfängerdomain in seinem
Zuständigkeitsbereich liegt.
Ein Outgoing-SMTP-Server sollte E-Mail nur von authorisierten MTAs zur Weiterleitung annehmen.
10.1.6
Sicherheit
Die Tatsache, dass unverschlüsselt übertragene E-Mail quasi öffentlich lesbar ist, wird mittlerweile häufig diskutiert und soll hier nicht erneut aufgegriffen werden. An dieser Stelle
interessant ist die Betrachtung der Zuverlässigkeit der Informationen, die in einer E-Mail
vorhanden sind, wenn sie beim Empfänger ankommt (siehe Kapitel 10.1.3) und wie SMTP
mißbraucht werden kann.
Das Abholen von E-Mail eines Benutzers von seiner Inbox ist nicht Bestandteil der
SMTP-Übertragung. Der Benutzer kann direkten Zugriff auf seine Mailbox haben oder
Protokolle wie POP oder IMAP benutzen. In diesem Bereich geht es hauptsächlich darum,
dass kein Unbefugter auf die Mailbox zugreifen kann.
10.1. SMTP
151
Hat ein Benutzer eine E-Mail verfasst, wird er diese in der Regel per SMTP an den
Outgoing-SMTP-Server seiner Domain oder seines Providers übertragen. Die Übermittlung an einen Outgoing-SMTP-Server des Providers ist unproblematisch, da der Provider
seine Kunden kennt und den Zugriff über die Kenntnis der IP-Adresse des Kundenrechners
oder über die Vergabe eines Passwortes einschränken kann. Gleiches gilt für den OutgoingSMTP-Server einer Domain, wobei hier die SMTP-Kommunikation sogar über ein geschlossenes internes Netzwerk erfolgt.
In Bereichen, wo eingehende E-Mail in einem internen Netzwerk verteilt werden muss,
gibt es einen (oder auch mehrere) Mailexchanger, der E-Mail aus dem Internet annimmt. Die
interne Weiterleitung erfolgt in einem abgeschlossenen Netzwerk, in dem sich alle Rechner
vertrauen können.
In den frühen Zeiten des Internet war es notwendig, E-Mail über eine Kette von SMTPServern zu übertragen, da sich nicht alle Rechner direkt erreichen konnten. Aus dieser Zeit
stammt der Begriff des Mailrouting. Heutzutage ist die Entwicklung der Netzwerktechnologie und des Internet so weit, dass sich alle im Internet befindlichen Rechner gegenseitig
erreichen können8 .
Man kann also die sicherheitskritische Betrachtung des E-Mail-Verkehrs auf die Kommunikation zwischen Outgoing-SMTP-Server, in der Rolle des SMTP-Client, und Mailexchanger als SMTP-Server reduzieren. Es sind durchaus Systemarchitekturen denkbar, die
von einem so einfachen Modell abweichen. Diese lassen sich aber darauf zurückführen.
Die Angaben, die von einem SMTP-Client während einer SMTP-Sitzung gemacht werden, sind fast beliebig. Nicht einmal an Stellen, an denen eine E-Mail-Adresse erwartet wird,
muss wirklich eine übertragen werden. Enthält eine Zeichenkette, die als E-Mail-Adresse
interpretiert wird, kein ’@’-Zeichen, geht der SMTP-Server normalerweise davon aus, dass
es sich um einen Benutzernamen innerhalb seines Systems handelt und hängt ein ’@’ gefolgt von seinem Domainnamen an. Die Identifikation des HELO oder EHLO-Befehls ist
vollkommen beliebig.
Empfängeradressen zu fälschen macht wenig Sinn. Jeder möchte, dass eine von ihm
verschickte E-Mail irgendwo ankommt.
Ein ehrlicher Benutzer hat keinen Grund, eine falsche Absenderadresse anzugeben. Er
hat Interesse daran, dass der Empfänger der E-Mail ihm antworten kann und möchte auch
benachrichtigt werden, wenn bei der Übertragung der Nachricht etwas schief geht.
Ein Versender von unerwünschter E-Mail wird seine Identität verschleiern. Er verschickt
in der Regel sehr viele solche Nachrichten. Er muss damit rechnen, dass die Empfänger auf
seine Nachricht negativ antworten und so aufgrund ihrer Vielzahl sein Mailsystem lahmlegen9 . Auch wäre es unter bestimmten Bedingungen möglich, ihn juristisch zur Verantwortung zu ziehen.
Alle anderen Werte einer E-Mail sind schon während der Übertragung Bestandteil des
Mail-Body (siehe Kapitel 10.1.3). Der Versender einer E-Mail kann sich Werte für Absender
(“From:”), Empfänger (“To:”), Betreff (“Subject:”) usw. und beliebige “Received:”-Zeilen
ausdenken.
Die einzigen verlässlichen Angaben sind die in der Received-Zeile des letzten MTA. Da
dieser das System ist, von dem man seine E-Mail direkt bezieht, kann man diesen Einträgen
8
Rechner hinter einem maskierenden Gateway muss man durchaus als “nicht im Internet befindlich”
ansehen. Und solche, die sich hinter einer Firewall befinden, sind unter Umständen nicht erreichbar, obwohl
sie sich im eigentlichen Sinn im Internet befinden. Nur bedeutet die Tatsache, dass ein Rechner einen
Verbindungsaufbau ablehnt, natürlich nicht, dass man ihn nicht erreichen kann.
9
Was für einen Nutzen das Versenden einer solchen Nachricht für den Absender haben kann, soll hier
nicht diskutiert werden. Es reicht aus, dass sowohl die Betreiber von Mailservern als auch die Empfänger
maßgeblich belästigt werden.
152
KAPITEL 10. MAIL
vertrauen.
Kommando
HELO
MAIL
RCPT
DATA
HELP
VRFY
EXPN
RSET
NOOP
QUIT
Argument
Systemname
From: Absenderadresse
To: Empfängeradresse
Daten...
Topic
Mailadresse
Mailadresse
Beschreibung
Beginn, Name des sendenden Systems
Beginn der Übermittlung
Adressat der E-Mail
Brieftext, Ende durch eine Zeile mit ”.”
Hilfestellung
Mailadresse verifizieren
Mailadresse expandieren (z. B. Liste)
Senden abbrechen, Zurücksetzen
nichts tun
Verbindung beenden
Tabelle 10.3: Grundsätzliche SMTP-Befehle
10.2
sendmail
Das Paket sendmail ist eines der ältesten INTERNET-Programme und wohl auch das mit
dem schlechtesten Ruf. Am Anfang war es aufgrund diverser Sicherheitslücken ein beliebtes
Einfalltor für Hacker und Co.; bei den Administratoren ist es wegen seiner schwierigen Konfiguration gefürchtet. Dennoch hat es sich zum Standard für UNIX/LINUX-MTAs erhoben
und verdient auf jeden Fall eine genauere Betrachtung. Mit den Jahren ist sendmail, was
die Sicherheit anbelangt, wesentlich besser geworden. Da es als OpenSource zur Verfügung
steht, hatten Gott und die Welt Zeit und Muße, den Quellcode auf Fehler abzuklopfen und
diese auszumerzen. Sendmail ist daher bei anständiger Konfiguration nicht unsicherer als
andere Dienste auf einem UNIX-Server. Was die Konfiguration angeht, so haben sich die
Programmierer die Kritik zu Herzen genommen und ein Tool entwickelt, welches die Arbeit
erleichtert. Dieses Tool namens IDA ist bei SuSE im sendmail-Paket bereits enthalten und
wird intern von YaST aufgerufen.
10.3
exim
Die Installation eines eigenen Mailservers auf einer Linux-Maschine hat den entscheidenden
Vorteil, dass man die von selbst oder von anderen erstellten Mails jederzeit abschicken
kann. Somit muss nicht jeder einzelne Client mit einem externen Mailserver die Verbindung
aufbauen, sondern es lassen sich firmen-/organisationseigene Maildienste realisieren. Dazu
muss aber zunächst z.B. exim neu konfiguriert werden (z.B. mittels eximconfig. Hierfür
muss man über SuperUser-Rechte verfügen.):
hermes:/# eximconfig
You already have an exim configuration. Continuing with eximconfig
will overwrite it. It will not keep any local modifications you have made.
If that is not your intention, you should break out now. If you do continue,
then your existing file will be renamed with .O on the end.
[---Press return---]
10.4. POP
153
Kommando
USER
PASS
QUIT
Argument
Name
String
Beschreibung
Das Argument identifiziert eine Mailbox
Der String enthält ein Mailbox-spezifisches Passwort
Beendet die Verbindung
Tabelle 10.4: Kommandos im ”Authorization State”
Kommando Argument
STAT
LIST
Nummer
RETR
Nummer
DELE
NOOP
Nummer
RSET
QUIT
Beschreibung
Liefert die Anzahl der gespeicherten Mails und die Größe
der Mailbox zurück (in Byte)
Liefert die Nummer und Größe (in Bytes) aller Mails
zurück Wird als Argument eine Mail-Nummer angegeben,
wird nur die Größe dieser Mail ausgegeben
Gibt die Mail mit der als Argument übergebenen Nummer
aus
Löscht die Mail mit der übergebenen Nummer
Bewirkt die Antwort ”+OK”. Dient zur Aufrechterhaltung der Verbindung, ohne daß ein Time-Out auftritt
Setzt die aktive Verbindung zurück. Noch nicht ausgeführte Änderungen werden verworfen
Beendet die Verbindung und führt alle gespeicherten
Änderungen aus
Tabelle 10.5: Kommandos im ”Transaction State”
10.4
POP
Für den Transport bis zum Server mit dem E-Mail Postfach findet i.d.R. das SMTPProtokoll Anwendung. Da Benutzerrechner, auch in Zeiten totaler Vernetzung, nicht permanent im Netz sind wird die Übertragung zum Client des Empfängers getrennt geregelt.
Häufig findet, seiner Einfachheit wegen, das Post Office Protocol in Version 3 (POP3) Einsatz.
Auf der Seite des Servers bearbeitet der POP3-Daemon, entweder durch (x)inetd oder
permanenten Daemon realisiert, auf Port 110 eingehende Verbindungen und stellt die EMails eines, durch Postfachname und Kennwort authentifiziertes Postfach, den Clients zur
Verfügung. Eine komfortable Verwaltung der E-Mails bereits auf dem Postfach-Server ist
mit POP3 nicht möglich. So muß eine E-Mails vor dem lesen komplett vom Client geladen werden und wird in Regelfall nach der Übertragung vom Server gelöscht. Dies führt
zu inkonsistenzen beim gleichzeitigen Einsatz verschiedener Clients für ein Postfach. Denn
Mails, welche bereits abgerufen wurden, sind für die anderen Clients nicht mehr erreichbar.
Das vollständige Abrufen aller E-Mails vom Server hat Vorteile wenn eine Verbindung per
Modem realisiert ist, da diese nach erfolgter Übermittlung wieder getrennt werden kann
und keine weitere Kosten verursacht.
Da das POP3 Protokoll sehr einfach aufgebaut ist kann man ein Postfach ggf. auch per
Telnet bedienen:
user@linux:/> telnet pop3.postfachserver.de 110
Trying a.b.c.d...
<-- IP Adresse des POP3-Servers
Connected to pop3.postfachserver.de.
Escape character is ’^]’.
+OK (rwcrpxc13) POP3 server
USER username
<-- Nutzer-/ Postfachname
154
+OK
PASS password
+OK Maildrop ready
LIST
KAPITEL 10. MAIL
<-- Kennwort
<-- Liste der E-Mails
im Postfach anfordern
+OK scan listing follows
1 961
<-- Laufende Nummer der E-Mails
2 3452
und deren Gr201ı̈¿ 21 [7m201ı̈¿ 21 in Byte
.
RETR 1
<-- Anfordern von Mail Nummer 1
+OK Message follows
Return-Path: <user@absender.net>
Received: from mail.postfachserver.de ([unix socket])
by srv1 (Cyrus v2.1.15) with LMTP; Mon, 10 May 2004 12:05:43 +0200
X-Sieve: CMU Sieve 2.2
Received: from absender.net (absender.net [a.b.c.d])
by pop3.postfachserver.de (8.12.10/8.12.6/SuSE Linux 0.6) with ESMTP
id i4H55hqd028136
for <user@postfachserver.de>; Mon, 10 May 2004 12:05:43 +0200
Message-ID: <40A845E4.4070400@sender.de>
Date: Mon, 17 May 2004 06:56:04 +0200
From: "Nutzername" <user@absender.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: de-de, en-us
MIME-Version: 1.0
To: user@postfachserver.de
Subject: test
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=-4.6 required=4.8
tests=AWL,BAYES_10,USER_AGENT_MOZILLA_UA
version=2.55
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)
test
.
STAT
+OK 2 4413
DELE 1
+OK message deleted
LIST
+OK scan listing follows
2 3452
.
QUIT
+OK
Connection closed by foreign host.
<-- Anzahl der E-Mails im Fach
und deren Gesamtgröße
<-- Löschen von E-Mail Nummer 1
<-- Liste der E-Mails im Postfach
<-- Verbindung beenden
Verbleibt noch die Nennung der Befehle RSET, welches Markierungen (als gelesen) einzelner
E-Mails rückgängig macht, und TOP #msg #lines (optional) um von #msg die #lines
angezeigt zu bekommen.
An dieser Stelle ist auch ersichtlich, dass Benutzername und Kennwort in Klarschrift
übertragen werden. Um das Postfach über eine verschlüsselte Verbindung abzurufen kann
POP3 über SSL/TLS, auf Port 995, realisiert werden.
10.5. IMAP
155
Auf dem Server werden die E-Mails in zwei Ablageformaten verwaltet. Entweder im
Mailbox-Format, wo alle Mails in einer fortlaufenden Datei je Nutzer im Verzeichnis
/var/spool/mail gehalten werden oder im Maildir-Format, wo i.d.R. in einem Verzeichnis im Homevezeichnis des Nutzers je einer Datei pro E-Mail abgelegt wird.
Das Mailbox-Format kann viele kleine E-Mails, wie dies in der vorkommerziellen Ähra des
Internets noch üblich war, ohne große Belastung der Server-Festplatten verarbeiten, verbraucht aber bei großen E-Mails viel Speicher. Beim Maildir-Format sind die Ansprüche
an die Massenspeicher höher dafür die Speicherbelastung geringer, da nur einzelne Dateien
verarbeitet werden müssen.
Um mit POP3-Servern eine Filterung der Mails zu ermöglichen muß dies beim MTA
implementiert werden. Denn der MTA stellt ankommende E-Mails direkt in die lokale Mailbox.
10.5
IMAP
Für eine komfortable Verwaltung von E-Mails bereits auf dem Postfach-Server wurde das
Internet Message Access Protocol (IMAP) entwickelt. Im Gegensatz zu POP3 verbleiben
die E-Mails auf dem Server. Damit kommt IMAP vorallem den Bedürfnissen mobiler Benutzern entgegen, denn auch bei gleichzeitiger Verwendung verschiedener Mail-Client-Software
und/oder Webfrontend bleiben die Daten konsistent. Die aktuelle Versionsnummer ist 4 und
hat einen Komplexitätsgrad erreicht, welcher durch kaum einen IMAP-Client vollständig
unterstützt wird.
Um die E-Mails eines Postfaches lesen zu können wird, analog dem zum POP3 Protokoll, eine Verbindung zum Server aufgebaut. Bei IMAP werden im ersten Schritt nur die
Headerinformationen der Mails im Postfach abgerufen und erst bei Bedarf, wenn der Inhalt
der Mail beim Nutzer von Interesse ist (angezeigt durch Auswahl), der Body nachgeladen
wird. Dies hat den Vorteil, dass eine E-Mail mit großem Anhang nicht unnötig über eine
langsame Modemleitung gesendet wird, denn bei Bedarf kann eine große E-Mail von einem Terminal mit schnellerer Netzanbindung geladen werden ohne auf die Verwaltung und
Beantwortung der verbleibenden Mails verzichten zu müssen. Ein weiterer Vorteil ist die
Organisation des Postfaches mittels Unterverzeichnisse.
Für IMAP sind Erweiterungen möglich, so z.B. der Zugriff auf Ordner durch verschiedene
Nutzer. Damit lassen sich Arbeitsprozesse für Gruppen vereinfachen und Datenaufkommen
durch Versenden von Kopien vermeiden. Diese Methode läßt sehr differenzierte administrative Einstellungen zu.
Der Preis des Komforts ensteht durch aufwendige Serverimplementationen mit deutlich
höheren Anforderungen an CPU und Speicher gegenber POP3-Servern. Desweiteren dauert
eine IMAP-Sitzung bis der Nutzer diese beendet (oder Time-outs beim Server die Verbindung trennen). Damit sind die Kosten für Einwahlverbindungen i.d.R. höher. Dies läßt sich
aber durch den Wechseln zwischen POP3 und IMAP, was durch die meisten IMAP-Server
unterstützt wird, kompensieren.
Drei der beliebtesten IMAP-Server fr Unix/Linux sind Courier-, Cyrus- und UW-IMAP.
Alle bieten sehr umfangreiche Funktionen und Erweiterungsmöglichkeiten und sind für eine große Anzahl an Postfächern (¿20k) geeignet. So lassen sich z.B. die Postfach-Nutzer
von den Systemnutzern trennen, Mailfilter-Sprachen einbinden und Quotas festlegen (was
dringend empfohlen wird, da die Nutzer die Mailboxen meist als privaten File-Server missbrauchen).
Es gibt daneben auch noch imap-Daemonen welche IMAP, sehr rudimentär und ohne Funktionen welche über POP3 hinaus gehen, bereitstellen.
156
KAPITEL 10. MAIL
Leider unterstützt kaum ein Client die Funktionen z.z. vollständig. Mulberry und pine
sind zwei der seltenen Ausnahmen mit sehr umfangreichen IMAP-Funktionen.
Die E-Mails werden entweder in einem Verzeichnis im Homeverzeichnis des Servers bereitgestellt oder unter /var/spool/imap in Nutzerverzeichnissen. Im Gegensatz zu POP3 ist nicht
der MTA für die Abspeicherung neuer Mails zuständig, sondern der IMAP-Server selbst.
Deshalb hat i.d.R. auch nur der IMAP-Server zugriff auf die entsprechenden Verzeichnisse, welche dieser u.a. mit separaten Index- und Quota-Tabellen für schnelleren Zugriff
verwaltet. Die Haltung der E-Mails als quasi File-Server stellt erhöhte Ansprüche an die
Festplatten und Speicherausstattung. Zum Einen müssen die Speicherkapazitäten wachsen,
da die durchschnittlich auf dem Server gehaltenen Datenmenge gegenber POP3 drastisch
ansteigt. Zum Anderen sind die Zugriffzeiten ausschlaggebend für die Gesamtperformance
des Servers, da die Anzahl der Dateien steigt. Dies sind ausschlaggebenden Gründe warum
IMAP-Server immer noch selten betrieben werden.
Der Standard-Port für IMAP ist 443 und für IMAPS, die Variante über SSL/TLS, ist
993 reserviert.
10.6
Aufgaben
10.6.1
Dienste
1. Welche IP Adresse hat der Server www.stud.uni-goettingen.de? Womit wird diese
ermittelt?
2. Wie heisst der Server 134.76.62.220 mit vollständigem Rechner- und Domainnamen?
3. Welche TCP und UDP Ports sind auf dem Dozentensystem offen? Welchen Diensten
sind diese zuzuordnen?
Kapitel 11
Fileserver
11.1
Unix-Netzwerkdateisystem - NFS
NFS, das Network File System, ist wahrscheinlich der populärste und am häufigsten eingesetzte RPC basierende Netzwerkdienst. Er erlaubt, entfernte Verzeichnisse auf anderen
Hosts so zu benutzen, als lägen diese Dateien lokal vor. Dies wird durch eine Mischung
aus Kernel-Funktionalität auf der Client- und Server-Seite realisiert. Der Dateizugriff ist
für den Client völlig transparent und funktioniert für eine ganze Reihe von Server- und
Host-Architekturen.
NFS bildet jede Art des Zugriffs auf Verzeichnisse und Dateien über einen Remote Procedure Call ab. Das erlaubt auf der einen Seite den gemeinsamen schreibenden Zugriff von
mehreren Clients auf ein Dateisystem. Auf der anderen Seite generieren die verschiedenen
Remote Procedure Calls gerade auf kleinen Dateien einen nicht unerheblichen Overhead.
Dieses kann man sehr leicht ausprobieren in dem man einfach mal die Zeit misst, die es
braucht ein Verzeichnis mit sehr vielen kleinen Dateien auf einer NFS-Quelle zu kopieren
oder dasselbe mit einer einzigen gleichgrossen Datei anzustellen.
NFS wird traditionell über das Transportprotokoll UDP abgewickelt, die Version 3
erlaubt eine alternative Verwendung von TCP. Es arbeitet als Remote Procedure Call
(RPC) Dienst und erfordert für seinen Einsatz das Vorhandensein des Portmap-Daemonen
(portmap). Die beiden ”alten” Daemonen, die im Userspace agieren, heissen deshalb auch
rpc.nfsd und rpc.mountd. Sie werden üblicherweise über ein gemeinsames Startskript bei
SuSE /etc/init.d/nfsserver gestartet, welches bei seiner Einrichtung darauf achtet, dass der
Portmapper vorher aufgerufen wird. Die Daemonen des Kernelspaces werden mittels analogen Startskriptes aufgerufen, wobei für den NFS-Daemon standardmäßig vier Threads
gestartet werden. Die Zahl kann für hohe Anforderungen jedoch stark gesteigert werden.
In den wenigsten Fällen lassen sich beide NFS-Implementationen problemlos nebeneinander installieren, da gemeinsame Dateien, wie das Startskript einge wesentliche Unterschiede
aufweisen. Für wechselnde Experimentierumgebungen mit beiden Servertypen sind Anpassungen mindesten der Init-Skripten notwendig.
Die Unterstützung für das Network Filesystem muss sowohl im Server- Kernel als auch
im Kernel der Clients aktiviert sein. Im Kernel des Servers sollte für Test- und Überwachungszwecke auch die Clientunterstützung aktiviert sein. So kann über ein einfaches Loopbackmounten von NFS-Freigaben sehr leicht überprüft werden, ob diese korrekt eingerichtet
sind.
NFS bietet eine Reihe nützlicher Features:
• Daten, auf die von allen Benutzern zugegriffen wird, können auf einem zentralen Host
gehalten werden - zentraler Fileserver für Home-Verzeichnisse. Clients mounten dieses
157
158
KAPITEL 11. FILESERVER
Verzeichnis während der Bootphase bzw. wärend des Logins des Benutzers.
• Daten, die sehr große Mengen an Plattenspeicher einnehmen, können auf einem einzigen Rechner vorgehalten werden. So könnten etwa die Office-Pakete Star- oder OpenOffice an einer Stelle gespeichert und administriert werden.
• Administrative Daten können auf einem Host gehalten werden. So kann die Mühe
entfallen bestimmte Datensätze nach ihrer Aktualisierung auf viele
Homeverzeichnisse. Clients mounten dieses Verzeichnis während der Bootphase bzw.
wärend des Logins des Benutzers. Die besondere Stärke liegt hier in der Verbindung
mit NIS. So können sich die Benutzer dann an jedem System einloggen und arbeiten
dennoch mit nur einem Satz von Dateien.
• Daten, die sehr große Mengen an Plattenspeicher einnehmen, können auf einem einzigen Rechner vorgehalten werden. So könnten etwa die Office-Pakete Star- oder OpenOffice an einer Stelle gespeichert und administriert werden.
• Administrative Daten können auf einem Host gehalten werden. So kann die Mühe
entfallen bestimmte Datensätze nach ihrer Aktualisierung auf viele Rechner zu verteilen.
NFS kann sowohl auf das Transportprotokoll UDP als auch TCP zurückgreifen. Die
Verwendung von TCP ist jedoch erst in den neueren Versionen 3 und 4 ünterstützt. Es
arbeitet als Remote Procedure Call (RPC) Dienst und erfordert deshalb für seinen Einsatz das Vorhandensein des Portmap-Daemonen (portmap). Die Daemonen zur Bereitstellung von NFS-Diensten werden üblicherweise über ein gemeinsames Startskript, bei
SuSE /etc/init.d/nfsserver gestartet, welches bei seiner Einrichtung darauf achtet, dass der
Portmapper vorher aufgerufen wird. Die Zahl der NFS-Daemonen liegt standardmäßig bei
vier Threads. Die Zahl kann für hohe Anforderungen jedoch stark gesteigert werden.
Die Unterstützung für das Network Filesystem muss sowohl im Server-Kernel als auch im
Kernel der Clients aktiviert sein. Alternativ zur statischen Variante kann die NFS-Fähigkeit
des Kernels auch mittels Module nachgeladen werden.
Sein Alter merkt man NFS jedoch auch an: Es verfolgt ein generalistischen Ansatz und
versucht es jedem Anwendungszweck einigermassen recht zu machen. Bis einschliesslich
Version 3 muss das Sicherheitskonzept von NFS als weitgehend nichtexistent bezeichnet
werden, da die IP-basierte und überhaupt nicht nutzerbasierte Authentifizierung, Angriffe
auf die Daten in Benutzer-Homeverzeichnissen kaum abhalten konnte.
11.1.1
NFS im Einsatz
Eine Freigabe, bei NFS ”export” genannt, definiert man auf dem Server in der Datei
/etc/exports:
/home
/home
10.18.40.0/255.255.254.0(rw,async)
*.my-domain.site(rw,async)
Im Beispiel wurde das Home-Verzeichnis aller Benutzer für alle Maschinen im Subnetz
10.18.40.0 mit der Netzmaske 255.255.254.0 freigegeben. Freigaben lassen sich auf einzelne
Maschinen oder auch auf Rechnernamen vornehmen. Letzteres zeigt die zweite Freigabe an
alle Rechner deren IP-Adresse aufgelöst Mitglied der Domain my-domain.site sind. Der Beispielexport legt fest, dass das Clients auf der Freigabe schreiben dürfen, der Benutzer ”root”
jedoch davon ausgenommen ist. Für alle Schreibvorgänge wird eine sofortige Bestätigung
11.1. UNIX-NETZWERKDATEISYSTEM - NFS
159
angefordert. Mit der Option async für asynchrones Schreiben kann man das Schreib- und
Leseverhalten verbessern, jedoch sinkt damit die Datensicherheit beim Schreiben. Dass der
Systemadministrator vom Zugriff ausgeschlossen wurde, ist jedoch nur eine minimale Hürde
Angreifern gegenüber. Es hindert keiner diese daran, einfach die passenden Benutzer-IDs
auf seinem lokalen System anzulegen und sich dann mit diesen IDs in den interessierenden
Verzeichnissen zu bewegen.
Ein NFS-Server muss je nach Einsatzgebiet und Anzahl der zugreifenden Clients einges
leisten. Von ihm hängt die Performance des Zugriffs auf entfernt liegende Dateien auf den
Clients ab. Eine leistungsfähige CPU, viel Hauptspeicher, nicht zu langsame Festplatten
und eine gute Netzwerkverbindung sind entscheidende Faktoren. Mit der heute üblichen
Leistung auch der Einstiegsprozessoren, die man auf vielen Clients finden wird, kann eine
100 Mbit-Leitung durchaus bis an ihre theoretische Transfergrenze von über 10 Mbyte/s
ausgelastet werden.
Soll es nicht zu unnötigen Wartezeiten auf den Clients kommen, sollte der Server über
ein oder mehrere Gigabit-Netzwerkinterfaces verfügen, die idealerweise an der Switch angeschlossen sind, welche die Verteilung an die Endgeräte übernimmt. Damit nicht alle Daten
erneut von der Festplatte in den Hauptspeicher und dann über das Netzwerk geschaufelt
werden müssen, macht ein großer Arbeitsspeicher Sinn. Durch diesen wird ein Cache häufig
angeforderter Festplattenblöcke angelegt, welche dann direkt aus dem Hauptspeicher an
den anfragenden Client ausgeliefert werden können.
11.1.2
NFS und Portmapper
Das Network File System benötigt Remote Procedure Calls (RPC). Der Portmapper - repräsentiert durch den Dienst portmap - ordnet RPC-Anfragen den korrekten Dienste zu.
RPC-Prozesse benachrichtigen portmap, wenn sie starten. Des Weiteren teilen die Anfragen die überwachte Port-Nummer sowie die Nummern des RPC-Programms mit, die aufgerufen werden. Der Client kontaktiert den Portmapper auf dem Server mit einer bestimmten
RPC-Programmnummer. Dieser leitet dann den Client zur richtigen Port-Nummer um,
damit er mit dem gewünschten Dienst kommunizieren kann.
Da RPC-basierte Dienste für die Verbindungen mit ankommenden Client-Anfragen von
portmap abhängig sind, muss er gestartet sein, bevor einer dieser Dienste gestartet wird.
Andernfalls beobachtet man sehr lange Wartezeiten zum Beispiel bis zum Abschluss eines
NFS-Mounts. Für die Zugriffssteuerung auf RPC-basierte Dienste des Servers kann man
die Host-Zugriffsdateien (/etc/hosts.allow und /etc/hosts.deny) verwenden. Will man im
Bereich RPC-Dienste debuggen, ist eine Zugeordnung der Portnummern sehr nützlich.
Der Befehl rpcinfo zeigt jeden RPC-basierten Dienst mit Port-Nummer, RPC-Programmnummer, Version und dem Typ des Transport-Protokolls (TCP oder UDP) an. Die
Ausgabe im folgenden Beispiel-Listing zeigt den Portmapper auf einer Maschine, die den
kernelbasierten NFS-Dienst verwendet:
s01:~ # rpcinfo -p
program vers proto
100000
2
tcp
100000
2
udp
100003
2
udp
100003
3
udp
100227
3
udp
100003
2
tcp
100003
3
tcp
100227
3
tcp
100024
1
udp
port
111
111
2049
2049
2049
2049
2049
2049
34607
portmapper
portmapper
nfs
nfs
nfs_acl
nfs
nfs
nfs_acl
status
160
KAPITEL 11. FILESERVER
100021
100021
100021
100024
100021
100021
100021
100005
100005
100005
100005
100005
100005
1
3
4
1
1
3
4
1
1
2
2
3
3
udp
udp
udp
tcp
tcp
tcp
tcp
udp
tcp
udp
tcp
udp
tcp
34607
34607
34607
32778
32778
32778
32778
783
786
783
786
783
786
nlockmgr
nlockmgr
nlockmgr
status
nlockmgr
nlockmgr
nlockmgr
mountd
mountd
mountd
mountd
mountd
mountd
Die erste Spalte gibt die Dienstnummer an, wobei dem Portmapper mit 100000 die
niedrigste zugeordnet ist. Der NFS-Dienst erhielt die Nummer 100003 und der MountDienst die 100005. Diese Zahlen sind so festgelegt.
Die zweite Spalte gibt Auskunft über die verwendete Protokollversion des Dienstes.
Die gleiche Versionsnummer taucht zweimal auf, wenn der Dienst auf zwei verschiedenen
Transportprotokollen, UDP und TCP, angeboten wird.
Dabei hat die Protokollnummer des Portmappers nichts mit den Protokollnummern
der anderen Dienste zu tun. Die Dienste selbst müssen jedoch in der Lage sein, mit dem
jeweiligen Port-Mapper zusammenzuarbeiten.
Der NFS-Server unterstützt die Versionen 2 und 3, der Mount-Server zusätzlich NFSVersion 1. Da Letzterer seine Dienste sowohl auf TCP als auch auf UDP anbietet, taucht
er sechsmal in der Liste auf.
Die Art des Transportprotokolls, auf dem ein Dienst arbeitet, kann der dritten Spalte
entnommen werden. Die vierte Spalte liefert die Portnummer und die fünfte den Namen
des gestarteten Dienstes, wie er auch in der Prozesstabelle (z.B. durch ps aux) angezeigt
werden würde.
Das nächste Beispiel zeigt eine Maschine, die NFS über den klassischen UserspaceDienst ausschließlich in den NFS-Protokollversionen 1 und 2 anbietet. Solche Maschinen
wird man jedoch zunehmend seltener finden, da die Implementierung von NFS im LinuxUserspace nicht mehr weiterentwickelt wird. Zusätzlich läuft ein weiterer RPC-Dienst zur
NIS-Authentifizierung, der aber ebenfalls kaum noch irgendwo Verwendung findet.
s05-alt:~ # rpcinfo -p
Program Vers Proto
Port
100000
2
tcp
111
100000
2
udp
111
100021
1
udp 32768
100021
3
udp 32768
100021
4
udp 32768
100007
2
udp
803
100007
1
udp
803
100007
2
tcp
806
100007
1
tcp
806
100005
1
udp
829
100005
2
udp
829
100005
1
tcp
833
100005
2
tcp
833
100003
2
udp
2049
100003
2
tcp
2049
100011
1
udp
855
portmapper
portmapper
nlockmgr
nlockmgr
nlockmgr
ypbind
ypbind
ypbind
ypbind
mountd
mountd
mountd
mountd
nfs
nfs
rquotad
11.1. UNIX-NETZWERKDATEISYSTEM - NFS
100011
100011
100011
11.1.3
2
1
2
udp
tcp
tcp
855
858
858
161
rquotad
rquotad
rquotad
NFS-Clients
Ein Client versucht, ein Verzeichnis von einem entfernten Host an sein lokales Verzeichnis
zu mounten, genau wie er dies mit einem physikalischen Gerät machen würde. Allerdings
ist die für ein entferntes Verzeichnis zu verwendende Syntax anders. Soll zum Beispiel
das Verzeichnis /opt/applix vom Host ”server” an /opt/office auf der Maschine gemountet
werden, führt man folgenden Befehl aus:
mount -t nfs -o ro,rsize=8192 server:/opt/openoffice /opt/office
11.1.4
NFS-Server
Die Freigaben, welche der NFS-Server zur Verfügung stellen soll, werden in der Datei
/etc/exports definiert:
/usr
/opt/applix
/tmp/users
172.19.100.0/255.255.255.0(ro)
172.19.100.0/255.255.255.0(ro)
10.10.156.0/255.255.255.0(rw,no_root_squash)
Der jeweilige NFS-Server muss je nach Einsatzgebiet und Anzahl der angeschlossenen
Clients einges leisten. Von ihm hängt die Performance der Anwendungen auf den plattenlosen Geräten ab, da alle Zugriffe auf Dateien, Bibliotheken und Programme über ihn abgewickelt werden. Eine leistungsfähige CPU, viel Hauptspeicher, nicht zu langsame Festplatten
und eine gute Netzwerkverbindung sind entscheidende Faktoren. Mit der heute üblichen
Leistung auch der Einstiegsprozessoren, die man auf vielen Clients finden wird, kann eine
100 Mbit-Leitung durchaus bis an ihre theoretische Transfergrenze von über 10 Mbyte/s
ausgelastet werden.
Soll es nicht zu unnötigen Wartezeiten auf den Clients kommen, sollte der Server über
ein oder mehrere Gigabit-Netzwerkinterfaces verfügen, die idealerweise an der Switch angeschlossen sind, welche die Verteilung an die Endgeräte übernimmt. Damit nicht alle Daten
erneut von der Festplatte in den Hauptspeicher und dann über das Netzwerk geschaufelt
werden müssen, macht ein großer Arbeitsspeicher Sinn. Durch diesen wird ein Cache häufig
angeforderter Festplattenblöcke angelegt, welch dann direkt aus dem Hauptspeicher an den
anfragenden Client ausgeliefert werden können.
11.1.5
NFS und (Un)Sicherheit
Der Einsatz von NFS bis einschliesslich Version 3 ist unter Sicherheitsaspekten nicht problemfrei. Die Überprüfung ob ein bestimmtes Gerät auf den NFS-Server zugreifen darf oder
nicht erfolgt lediglich anhand der IP-Nummer. Es werden keinerlei andere Credentials, wie
Benutzerkennung oder Passwort abgefragt. Das vereinfacht den Einsatz von NFS im Umfeld von Diskless Clients oder zur Verteilung gemeinsamer Daten in nur lesbarem Zugriff.
Sensible Daten sollten deshalb nicht mittels NFS-Freigaben bis zur Version 3 bereitgestellt
werden. Hierfür sollten andere Netzwerkdateisysteme, wie Samba oder das Andrew File
System (AFS) eingesetzt werden.
Die Weiterentwicklung von NFS in der Version 4 bringt einige Fortschritte in Richtung
Authentifizierung und Verschlüsselung der Daten.
162
KAPITEL 11. FILESERVER
Auf jeden Fall sollten Administratoren nur NFS-Freigaben in das lokal zu bedienende Sub-Netz einrichten und einen NFS-Server nicht gleichzeitig als Gateway ins Internet
oder ähnliches einsetzen. NFS-Zugriffe kann man nur teilweise per Firewall beschränken,
da NFS und zusätzliche Dienste we gen der RPC-Architektur nicht mit bestimmten fest
vorgegebenen Portnummern verknüpft sind.
11.2
Andrew Filesystem (AFS)
11.2.1
Die Clientseite
Das Kürzel AFS steht für Andrew File System oder A distributed File System. AFS wurde
ursprünglich von der Carnegie-Mellon University entwickelt. Kommerzialisiert wurde AFS
später von Transarc. Diese Firma wurde 1994 von IBM gekauft. IBM ihrerseits stellte im
Jahre 2000 AFS als Open Source zur Verfügung. Seit dieser Zeit wird AFS von der OpenAFS
Community gepflegt. AFS wird nicht mehr offiziell von IBM weiterentwickelt. Das Andrew
File System (AFS) ist ein Netzwerk-Dateisystem, welches Dateien netzwerk- und weltweit
zur Verfügung stellen kann. Dieses Dateisystem arbeitet nach dem Client-Server-Prinzip:
Daten werden auf dem Fileserver gespeichert, der Zugriff erfolgt von Seiten der Clients.
Die AFS-Unterstützung wird über ein Kernelmodul realisiert, welches alle benötigten
Bibliotheksfunktionen zur Verfügung stellt. Zu diesem Modul werden Kernelprozesse gestartet, welche die Netzwerkinteraktion realisieren. Ausschnitt der Anzeige aller geladenen
Module und AFS-Prozesse:
linux:~/test # lsmod
Module
Size Used by
Tainted: PF
[...]
nls_cp437
4316
1 (autoclean)
nls_iso8859-1
2812
1 (autoclean)
smbfs
34384
1 (autoclean)
snd-pcm-oss
45888
1 (autoclean)
snd-mixer-oss
13560
0 (autoclean) [snd-pcm-oss]
videodev
5600
0 (autoclean)
libafs
442528
2
[...]
linux:~/test # ps aux | grep afs
root
2001 0.0 0.0
0
0 ?
SW
Aug11
0:08 [afs_rxlistener]
root
2003 0.0 0.0
0
0 ?
SW
Aug11
0:00 [afs_callback]
root
2005 0.0 0.0
0
0 ?
SW
Aug11
0:00 [afs_rxevent]
root
2007 0.0 0.0
0
0 ?
SW
Aug11
0:00 [afsd]
root
2009 0.0 0.0
0
0 ?
SW
Aug11
0:00 [afs_checkserver]
root
2011 0.0 0.0
0
0 ?
SW
Aug11
0:01 [afs_background]
root
2013 0.0 0.0
0
0 ?
SW
Aug11
0:01 [afs_background]
root
2015 0.0 0.0
0
0 ?
SW
Aug11
0:00 [afs_cachetrim]
AFS besitzt gegenüber anderen verteilten Dateisystem wie z.B. Samba oder NFS einige
Vorteile. Es arbeitet plattformunabhänig und verwendet zur Beschleunigung des Zugriffs
auf jedem Client ein Cache von bis zu 2 GByte. Dieser dient zur Entlastung des Netzwerkes,
zur Beschleunigung von Zugriffen und zur Überbrückung von Schwankungen, da AFS auf
die Verwendung in Wide Area Networks angelegt ist. Für eine grössere Ausfallsicherheit
können Volumes über mehrere Fileserver repliziert werden.
Der Integrationsaufwand in das jeweilige Betriebssystem fällt jedoch höher aus, als
für die meisten bereits genannten Filesysteme. Es existieren Implementationen für Win-
11.2. ANDREW FILESYSTEM (AFS)
163
dows1 , MacOS X und diverse UNIXe inklusive Linux. AFS kennt einen weltweit eindeutigen Namensraum. Egal wo und an welcher Maschine ein Benutzer arbeitet, der Pfad
für einen Benutzer stellt sich immer identisch dar. Der Pfadname beginnt mit /afs (dem
sogenannten Top Level). Auf der nächsten Hierarchieebene (Second Level) kommt der sogenannte Cell-Name. Die Zellennamen für bereits bestehende AFS-Zellen finden sich auf:
www.central.org/dl/cellservdb/CellServDB.
Für die darin enthaltenen Unterverzeichnisse darunter existieren ebenfalls Konventionen, die eingehalten werden sollten. vgl. hierzu Tabelle 11.2.1 auf S. 163
Name
common
public
service
sys type
usr
wsadmin
Beschreibung
Systemunabhängige Daten
Öffentliche Daten
Koordination und Konfiguration der Zelle
Systemspezifische Daten z.B. i586 linux
Home-Verzeichnisse für Benutzer
Konfiguration von Clients
Jedem Benutzer kann ein eigenes Volume zugeordnet werden. Sie bilden die Basis des
ganzen Konzeptes, ihre Lage ist für den Client völlig transparent. Die Volumes können
während des Betriebes von Fileserver zu Filserver verschoben werden. Auf diesem Volume
wird ein Quota definiert. AFS implementiert eine ausgefeiltere Kontrolle über die Zugriffsberechtigungen mit Access Control Lists (ACLs), die anstelle der Unix-Rechte-Bits auf
Verzeichnisebene zum Einsatz kommen.
Jeder Benutzer kann eigene Gruppen erzeugen und verwalten. Wenn ein normaler Benutzer ohne Systemrechte eine Gruppe erzeugen will, muss er als Präfix seinen eigenen Namen
verwenden. Dieses kann so aussehen: user:group Ausserdem sind die folgenden drei SystemGruppen schon definiert: system:anyuser, system:authuser und system:administrators, diese
Gruppen sind in allen AFS Systemen vorhanden. system:anyuser sind alle Benutzer (mit
oder ohne gültigem Token), system:authuser alle Benutzer mit gültigem Token und system:administrators Benutzer mit Administrator-Privilegien.
Eine weitere Eigenschaft von AFS ist, dass es einen eigenen Login für die Freigabe seines
Inhaltes benötigt. NFS in den Versionen 2 und 3 arbeitet mit einer IP-basierten Freigabe,
die wenig Einschränkungen gegen geplanten Missbrauch bietet. Durch die Verwendung von
Kerberos 4 bzw. 5 Authentifizierung kann es deshalb bedenkenloser als andere Netzwerkdateisysteme zur weltweiten Verteilung eingesetzt werden.
Kommando
kpasswd
klog
tokens
pts
fs
Beschreibung
wird benutzt um das AFS-Passwort zu ändern
Erwerben eines Tokens
Überblick der gültigen Tokens
kann Benutzer und Gruppen anzeigen und verwalten
kann ACLs und Quotas anzeigen/verwalten
Tabelle 11.1: Einige wichtige AFS-Kommandos
Mit der Authentifizierung gegenüber AFS, beim Login über PAM oder durch das Kommando klog <afs-username> erhält der angemeldete Benutzer ein Token. Dieses Token
gestattet den Zugrif auf das AFS-Filesystem. Das Token hat aber nur eine begrenzte Gültigkeitsdauer. Nach Ablauf der Gültigkeit ist der Zugrif auf die AFS-Dateien wieder gesperrt.
1
für die “Consumerwindows” - Spielkonsolen Win95/98/ME - jedoch nur der Client
164
KAPITEL 11. FILESERVER
Mit dem Befehl tokens kann man anschauen, welche Token gerade gehalten werden und
wie lange die einzelnen Token noch gültig sind.
Die Syntax der AFS-Kommandos ist etwas ungewohnt, da im Gegensatz zu den StandardUNIX Kommandos die AFS-Kommandos nicht nur einem Zweck dienen, sondern mehrere
Kommandos zu sogenannten Command Suites zusammenfassen. Die Syntax ist bei allen
AFS Kommandos identisch: command suite operation code -switch <value> -flag
Kommando
fs help
fs lq <dir>
fs la <dir>
fs sa <dir> <user> <rights>
fs q
Beschreibung
erklärt alle zur Verfügung stehenden Optionen
zeigt definiertes Quota für ein Verzeichnis an
listet die gesetzten Rechte
setzt Rechte für ein Verzeichnis
Prozentangabe der Quotaauslastung
Tabelle 11.2: Setzen und Ansehen der Zugriffsrechte
Zur Anzeige der Rechte auf ein AFS-Verzeichnis (nur auf diese können AFS-Rechte
gesetzt werden, auf einzelne Dateien nicht) verwendet man folgendes Kommando:
dirk@lsfks02:/afs/.uni-freiburg.de/www/ks/htdocs/systeme> fs la
Access list for . is
Normal rights:
webadmins rlidwka
system:administrators rlidwka
www rl
www.ks rl
dsuchod rlidwka
Die Ausgabe zeigt, dass die Benutzer-IDs der eingeloggten Person an der Maschine nicht
zwingend mit der AFS-Benutzer-ID übereinstimmen müssen. An der Linux-Maschine ist
dirk eingeloggt, mit dem Kommando klog dsuchod und anschliessender Passwort-Eingabe
hat sich der angemeldete Benutzer ein AFS-Token für den Zugriff auf die dsuchod freigeschalteten AFS-Bereiche geholt.
Durch Eingabe des Kommandos fs quota oder kürzer fs q im AFS-Baum bekommt
man die Meldung, wieviel Prozent des eigenen Quotas aufgebraucht sind:
dirk@login02:/afs/.uni-freiburg.de/www/ks/htdocs/> fs q
74% of quota used.
Eine ausführlichere Information mit Angabe des zur Verfügung stehenden und verbrauchten
Speicherplatzes bekommt man mit:
dirk@login02:/afs/.uni-freiburg.de/www/ks/htdocs/> fs lq
Volume Name
Quota
Used %Used
Partition
www.ks
400000
295334
74%
73%
Die Zugriffsberechtigungen von AFS beziehen sich immer auf ein ganzes Verzeichnis und
alle darin enthaltenen Dateien. Sie beziehen sich nicht automatisch auf enthaltene Unterverzeichnisse. Wenn die Zugriffsberechtigung für eine einzelne Datei geändert werden soll,
muss diese ein anderes Verzeichnis mit den gewünschten Zugriffsrechten verschoben werden.
Die Zugriffsberechtigung wird dabei vom übergordneten Verzeichnis geerbt. AFS definiert
insgesammt sieben Rechtearten, dabei beziehen sich vier Zugriffsrechte auf das Verzeichnis.
Drei weitere Berechtigungen beziehen sich auf die Dateien innerhalb des Verzeichnisses
11.2. ANDREW FILESYSTEM (AFS)
Kürzel AFS-Recht
a
administer
d
delete
i
insert
l
lookup
r
read
w
k
write
lock
165
Beschreibung
die ACLs ändern
Dateien und Verzeichnisse
löschen oder verschieben
Neue Dateien und Verzeichnisse anlegen
Inhalt des Verzeichnis kann
aufgelistet werden und ein
Wechsel in dieses Verzeichnis
ist erlaubt
Inhalt der Dateien lesen. Dazu
gehört z.B. auch ls -l
Ändern von Dateien
Ermöglicht das Ausführen
von Programmen die über
Systemcalls Dateien sperren
(locks)
Tabelle 11.3: AFS Rechteschema
Beim Setzen des Rechtelevels lookup kann in das Verzeichnis gewechselt werden. Der
Inhalt der Dateien kann nur dann auch gelesen werden, wenn ebenfalls die Berechtigung
read zur Verfügung steht. Die wichtigsten Berechtigungen lassen sich zusammenfassen, wie
in der Tabelle zur AFS Rechtegruppierung gezeigt.
Zusammenfassung
all
none
read
write
Beschreibung
alle Berechtigungen (rlidwka)
keine Berechtigung
nur lesen (rl)
lesen und schreiben (rlidwk), d.h. alle ausser a
Tabelle 11.4: AFS Rechtegruppierung
Ein nettes Feature ist, dass Rechteinhaber im AFS selbst Verzeichnisse für andere Benutzer bzw. Gruppen freigeben können. Hierzu dient zuerst einmal das Kommando pts.
pts creategroup dsuchod:systeme
group dsuchod:systeme2 has id -754
pts adduser user01 dsuchod:systeme
fs sa testdir dsuchod:systeme rliwka
Das Ergebnis des Gruppenanlegens ist eingerückt dargestellt. Anschliessend kann ein User
(hier: user01) oder mehrere dieser Gruppe hinzugefügt werden. Mit dem AFS-Kommando
fs sa testdir dsuchod:systeme rliwka wird dann ein Rechtemuster auf das Verzeichnis
testdir für die Gruppe dsuchod:systeme eingetragen. Dieses Kommando muss entsprechend
für alle gewünschten Verzeichnisse wiederholt werden. Dabei sollte man bedenken, dass
auch übergeordnete Verzeichnisse zumindest ein Lookup-Recht für die Gruppe bekommen
sollten. Das Anzeigen der Rechte im Verzeichnis testdir liefert dann folgendes:
dirk@linux02:/afs/.uni-freiburg.de/www/ks/htdocs/systeme> fs la
Access list for . is
Normal rights:
dsuchod:systeme rliwka
166
KAPITEL 11. FILESERVER
webadmins rlidwka
system:administrators rlidwka
www rl
www.ks rl
dsuchod rlidwka
11.3
File Transfer Protocol
11.3.1
Dateiarchiv - FTP-Server
Eine der ältesten Internet-Anwendungen ist der Transport von Dateien. Hierfür wurde
ein eigenes Protokoll geschaffen. FTP-Server haben heutzutage die Aufgabe große Datenmengen, meistens Softwarebestände einfach zugänglich zu machen. Meistens wird unter
Linux der proftpd eingesetzt. Dieser wird über die Datei /etc/proftpd.conf eingerichtet.
Der FTP-Server kann als standalone Prozess immer im Hintergrund laufen oder über den
Internet-Superdämon inetd oder xinetd bei Bedarf gestartet werden. Ersteres bedeutet
höheren Speicherverbrauch, die zweite Lösung benötigt durch den Start mehr Resourcen
und braucht etwas längere Antwortzeiten.
11.3.2
FTP-Clients
Nach dem Einloggen befindet man sich auf der Kommandoebene von FTP. Hier steht
nicht der gesamte UNIX-Befehlswortschatz, sondern nur einige Befehle zur Dateiverwaltung
und zum Datentransport zur Verfügung. Im folgenden sei mit Arbeitsrechner der Rechner
gemeint, auf dem FTP gestartet wurde, und Zielrechner sei der Rechner, mit dem man per
FTP die Verbindung hergestellt hat.
11.4
Das Minimal-FTP (TFTP)
Das Trivial File Transfer Protocol (TFTP)2 dient in erster Linie zur Übertragung von zu
bootenden Netzkernels3 oder eines PXE-Bootimages4 für spezielle Programme zu einem
sehr frühen Zeitpunkt des Rechnerstarts.
Das Protokoll wird zu Beginn des Bootvorganges ausgeführt und muss meistens neben der BOOTP-Implentation auf einem 16 kByte bzw. 32 kByte EPROM Platz finden.
Deshalb ist es auf geringen Codeumfang optimiert. tftp, die Client-Applikation, braucht
man inzwischen häufiger mal wieder auf seiner Maschine, da viele Embedded Devices einen
eingebauten TFTP-Server zum Update ihres Flash-ROMs haben. Es lässt sich ählich wie
ftp interaktiv bedienen, wenn auch der Funktionsumfang vorgebenermassen ziemlich eingeschränkt ist.
2
TFTP wird in den folgenden RFCs beschrieben:
• RFC1350 : ”The TFTP Protocol (REVISION 2)”, Juli 1992
• RFC2090 : ”TFTP Multicast Option”, Februar 1997
• RFC2347 : ”TFTP Option Extension”, Mai 1998
• RFC2348 : ”TFTP Blocksize Option”, Mai 1998
• RFC2349 : ”TFTP Timeout Interval and Transfer Size Options”, Mai 1998
3
Welche Optionen dieser enthalten muss, welche Anpassungen notwendig sind und wie man ihn mit einer
entsprechenden Bootsignatur versieht, wird in den folgenden Abschnitten erklärt
4
Die notwendigen Erweiterungen von TFTP im Zusammenhang mit PXE finden sich im RFC2349
11.4. DAS MINIMAL-FTP (TFTP)
Kommando
cd
Verzeichnis
mkdir Verzeichnis
rmdir Verzeichnis
lcd
Verzeichnis
dir
ldir
!Kommando
put
Dateiname
mput Dateiname(n)
get
Dateiname
mget Dateiname(n)
ascii
bin
? oder help
quit
Funktion
Verzeichnisse wechseln
Verzeichnisse anlegen
Verzeichnisse löschen auf dem Zielrechner
Verzeichnis auf Arbeitsrechner wechseln
zeigt das Directory des Zielrechners an
zeigt das Directory des Arbeitsrechners an
aktiviert eine Shell auf dem Arbeitsrechner und führt Kommando aus
kopiert Dateiname auf den Zielrechner
wie put, nur sind hier die Wildcards ** und ? erlaubt
kopiert Dateiname vom Zielrechner auf den Arbeitsrechner
entspricht get mit Platzhaltern
schaltet auf den für den Transport von ASCII-Dateien notwendigen ASCII-Modus um, Voreinstellung von MickeyFTP
schaltet auf den für den Transport von binären Daten notwendigen Binärmodus um
zeigt eine Liste der zur Verfügung stehenden Befehle an
beendet FTP
Tabelle 11.5: Einige wichtige FTP-Kommandos
167
168
KAPITEL 11. FILESERVER
In aktuellen Linux-Distributionen stehen oft mehrere Implementierungen zur Auswahl.
Der in.tftpd ist die klassische Version, der atftpd kann mehr und kommt besser mit
PXE klar. Die optimale Konfiguration in der jeweiligen Umgebung bekommt man wohl am
besten durch Tests heraus. Es kann jedoch immer nur ein Dienst gleichzeitig auf einem Port
betrieben werden. Der TFTP-Standard-Port ist UDP 69.
TFTP bietet keinen Schutz durch Passwortauthentifizierung und sollte deshalb mit
Vorsicht, d.h. mindestens durch Beschränkung des Hauptverzeichnisses auf den benötigten Bereich, aufgesetzt werden. Dazu kann durch den (x)inetd ein TFTP-Root angegeben
werden, was einen Zugriff auf höhere Verzeichnis-Ebenen des Servers verhindert. Zur Illustration dienen die nachfolgenden Ausschnitte aus den jeweiligen Konfigurationsdateien.
Der folgende Ausschnitt zeigt ein Teil der /etc/inetd.conf.
[...]
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers".
#
tftp dgram udp wait nobody /usr/sbin/tcpd in.tftpd /boot
bootps dgram udp wait root /usr/sbin/bootpd bootpd -c /nfsroot
#
[...]
Oder: (Ausschnitt der /etc/xinetd.conf)
[...]
# disabled = bootps
# disabled = tftp
[...]
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = nobody
only_from = 172.16.0.0/16 10.0.0.0/8
server = /usr/sbin/in.tftpd
server_args = /nfsroot
}
Eine moderne Implementation von TFTP ist der atftpd, welcher auch im StandaloneBetrieb eingesetzt werden kann. Die Einstellungen erfolgen in den neueren Linux-Distributionen
mittels Sysconfig-Datei: /etc/sysconfig/atftpd. Hier entnimmt das Runlevel-Skript üblicherweise die Startoptionen. Der erfolgreiche Start des TFTP-Servers (/etc/init.d/atftpd
start) zeigt sich im System-Logfile auf diese Weise:
Oct 6 21:50:39 hermes atftpd[25183]: Advanced Trivial FTP server started (0.7)
...
Oct 6 21:55:12 hermes atftpd[25184]: Serving /nfsroot/10.0/boot/vmlinuz to \
10.20.0.1:41470
Angenommen, das Kernel-Image liegt im Verzeichnis /nfsroot/10.0/boot und trägt den Namen vmlinuz. Dann könnte der Test auf ein funktionierendes TFTP so aussehen:
11.5. WEITERE FILESERVER-KONZEPTE
169
rechner02:~ # atftp bootserver.mydomain.site
tftp> get /nfsroot/10.0/boot/vmlinuz
tftp> quit
rechner02:~ # ls -lha vmlinuz
-rw-r--r-1 root
root
1.5M Oct 6 17:38 vmlinuz
Liegt dann der Kernel in der richtigen Größe in dem Verzeichnis, aus dem man den TFTPClient heraus gestartet hat, ging alles glatt. Der Eintrag im Logfile sieht dann wie oben
gezeigt aus.
11.5
Weitere Fileserver-Konzepte
Die Idee, Festplattenkapazitäten zu zentralisieren und einer ganzen Reihe verschiedener Maschinen übers ein Netzwerk zu Verfügung zu stellen, existiert schon lange. Im kommerziellen
Umfeld haben sich neben den Lösungen mit sogenannten Network Attached Storage (NAS),
die dateibasierte Dienste wie NFS oder SMB bereistellen, Storage Area Networks (SAN)
etabliert, die meistens auf einer eigenen vom klassischen LAN unabhängigen Fibre-Channel
Fabric basieren.
Die Preise der einzelnen Komponenten liegen dabei weit über dem Gewohnten im privaten Bereich. Für den Anschluss von preiswerteren und leistungsärmeren Endgeräten versucht die Industrie den iSCSI-Standard zu verbreiten. Linux-Maschinen können iSCSI benutzen, da der Kernel die notwendige Treiberunterstützung mitbringt. Der Overhead ist
für den einfachen Standardarbeitsplatz jedoch immer noch sehr hoch, weshalb sich die Verbreitung noch sehr in Grenzen hält. Die Abbildung zeigt, dass Dateien oder Blöcke auf
Server
Anwendung
Netzwerk
ftp, scp, http
VFS
Client
Anwendung
VFS
LUFS
Dateisystem
Blockgerät
NFS, SMB
iSCSI, AoE, NBD
Dateisystem
Blockgerät
Abbildung 11.1: Arbeitsweise von Blockgeräten und Dateisystemen
verschiedenen Ebenen ausgetauscht werden können. Es wird hier nicht berücksichtigt wo
Server und Client letztendlich implementiert sind, sondern auf welcher Ebene sie die Daten interpretieren. Das Linux Userland Filesystem (LUFS) spielt eine Sonderrolle - es kann
beispielsweise die Dateien eines FTP-Servers als Dateisystem einhängen.
Dieser durchaus sinnvolle Ansatz lässt sich mit einigen Einschränkungen auch weitaus
günstiger realisieren. Parallel zu den kommerziellen Implementierungen von SANs haben
sich Kernel-Entwickler darangemacht, Ähnliches auch für Linux zu implementieren. Seit vier
Jahren liegt der Code für das Network Block Device dem Mainstream-Kernel bei. Ausgehend von diesem hat es weitere Entwicklungen auch für durchaus besondere Anforderungen
gegeben.
170
KAPITEL 11. FILESERVER
11.6
Network Block Devices
Netzwerkblockgeräte und Netzwerkdateisysteme unterscheiden sich deutlich voneinander,
selbst wenn der Einsatzzweck am Ende recht ähnlich sein kann. Dateisysteme kümmern sich
um den Zugriff auf Dateien - Blockgeräte abstrahieren in der Regel Hardware (z.B. Festplatten) und erlauben den Datenaustausch in Blöcken. Eine Verbindung zwischen beiden
ergibt sich, wenn gewöhnliche Dateisysteme auf blockbasierte Geräte aufgebracht5 werden,
um die Dateien in Form von Blöcken festzuhalten.
Ein modernes Betriebssystem steigert die Performance, indem es Blocktransfers zwischenspeichert, d.h. Blöcke werden nicht sofort auf Platte geschrieben, sondern zuerst noch
im Speicher festgehalten.
In dem sich ein Administrator auf ein Netzwerkdateisystem festlegt, bestimmt er die
erlaubten Dateienarten, -größen und Zugriffssteuerungen. So kennt beispielsweise Samba
in der Default-Konfiguration keine speziellen Unix-Dateien wie Sockets und Named Pipes,
welches einige Applikationen und grafische Linux-Desktops stolpern lässt. Blockdevices erlauben prinzipiell den Einsatz beliebiger blockbasierter Dateisysteme, völlig unabhängig
davon, ob sie lokal eingebunden werden oder per Netzwerk zur Verfügung stehen. Das erweitert die Auswahl ganz erheblich und erlaubt es speziellen Anforderungen, wie Kompression
der Daten, zu berücksichtigen.
Netzwerkblockgeräte lassen sich wie Netzwerkdateisysteme sowohl nur lesbar als auch
schreibbar exportieren. Der wesentliche Unterschied ergibt beim gemeinsamen Schreiben auf
eine Ressource. Netzwerkdateisysteme stellen hier beispielsweise Locking-Mechanismen bereit oder koordinieren Dateizugriffe so, dass keine Daten beschädigt werden. Netzwerkblockgeräte betreiben deutlich weniger Aufwand, d.h. ein Block wird gelesen oder geschrieben.
Sicherheitsmechanismen beschränken sich darauf, dass Blocktransfers atomar durchgeführt
werden. Blockgeräte interessieren sich insbesondere nicht dafür, ob die Blöcke mit einem
Dateisystem in Verbindung stehen, d.h. sie haben keine Ahnung von der darüberliegenden
Datenschicht und ihrer Organisation, was der verteilten Nutzung eines Netzwerkblockgeräts
zusammen mit einem gewöhnlichen blockbasierten Dateisystem einige Schwierigkeiten bereit.
Würden mehrere Clients gemeinsam ein Netzwerkblockgerät ausgestattet mit einem
Dateisystem beschreiben, so gäbe es keine Instanz, die den verteilten Zugriff regelt. Die
Dateisysteme, die letztendlich ein gemeinsames Blockgerät benutzten, wüssten nichts von
ihrer gegenseitigen Existenz und keines davon würde es ”begreifen” bzw. berücksichtigen,
dass sich Blöcke plötzlich wie von Zauberhand verändern. Durch lokales Caching (und damit
noch weniger Synchronisation) ist dann das Wirr-Warr perfekt und die Dateisysteme auf
den unterschiedlichen Clients sehen bald nur noch uninterpretierbaren Müll, welches in den
meisten Fällen fatale Auswirkungen haben dürfte. Dieses Problem spielt jedoch für spezielle
Szenarien, wie beispielsweise den Betrieb von Linux Diskless Clients nur eine untergeordnete
Rolle.
Bei Netzwerkdateisystemen werden viele dieser Probleme vom Kernel abgenommen. Die
Server für die ”einfachen” Netzwerkdateisysteme, wie NFS oder Samba operieren direkt auf
den normalen Verzeichnissen, wie sie an irgendeiner Stelle im Serverdateisystem eingehängt
wurden. Damit kann ein und dasselbe Unterverzeichnis in verschiedenen Arten über das
Netzwerk exportiert werden. Oft findet man diese Anwendung bei der Bereitstellung von
Home-Verzeichnissen für Windows- und Unix-Clients. Das hat den wesentlichen Vorteil,
dass Schreibvorgänge sowohl auf dem Server als auch unterschiedlichen Clients transparent
sichtbar werden. So kann der Admin auf dem Server beispielsweise ein Software-Update
5
Dieser Vorgang wird gemeinhin als ”formatieren” (einer Festplatte oder Partition, ...) bezeichnet
11.7. NBDS IM EINSATZ
171
einspielen, welches sich recht schnell auf alle angeschlossenen Clients auswirkt.
11.7
NBDs im Einsatz
Zu den ältesten netzwerktransparenten Blockgeräten zählt das Network Block Device NBD,
welches seit dem späten 2.1er Kernel in den Code-Baum aufgenommen wurde. In den modularen Kernels der meisten Mainstream-Distributionen ist NBD deshalb üblicherweise als
Modul enthalten. Es lässt sich einfach mit modprobe nbd laden. Es sollte keine Fehlermeldung erscheinen, andernfalls ist es nicht korrekt installiert.
Die notwendigen Userspace-Tools liefern die meisten Distributionen als eigenes Paket
mit.
hermes:~ # modprobe nbd
hermes:~ # which nbd-server
/usr/bin/nbd-server
hermes:~ # rpm -q nbd
nbd-2.7.4-2
11.7.1
Erste Versuche mit NBD
Um Netzwerkprobleme auszuschliessen, führt man Tests zuerst am besten auf derselben
Maschine durch. Am einfachsten operiert man mit einer weiteren Partition auf der nicht das
Root-Filesystem des Servers liegt. Hat man diese nicht zur Verfügung kann man alternativ
eine Container-Datei anlegen und diese mit einem Dateisystem der Wahl, welches vom
Serverkernel unterstützt wird, formatieren. Erfolgreich getestet wurden an dieser Stelle die
Dateisysteme ReiserFS, ext2 und XFS. Jedes Formatwerkzeug weist darauf hin, dass es sich
bei der Datei nicht um ein Blockgerät handelt, was aber ohne Folgen ignoriert werden kann.
hermes:~ # mkdir /exports
hermes:~ # dd if=/dev/zero of=/exports/nbd-export bs=1024 count=100000
100000+0 Datensätze ein
100000+0 Datensätze aus
102400000 bytes (102 MB) copied, 0,987222 seconds, 84 MB/s
hermes:~ # mke2fs nbd-export
mke2fs 1.38 (30-Jun-2005)
/exports/nbd-export ist kein spezielles Block-Gerät.
Trotzdem fortsetzen? (y,n) y
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=1024 (log=0)
[ ... ]
hermes:~ # nbd-server 5000 /exports/nbd-export
hermes:~ # nbd-client 127.0.0.1 5000 /dev/nbd0
Negotiation: ..size = 100000KB
bs=1024, sz=100000
hermes:~ # mount /dev/nbd0 /mnt
hermes:~ # ls /mnt
. .. lost+found
hermes:~ # df
Dateisystem
1K-Blöcke
Benutzt Verfügbar Ben% Eingehängt auf
[ ... ]
/dev/nbd0
96828
13
91815
1%
/mnt
hermes:/ # time dd if=/dev/zero of=/mnt/text count=8192 bs=1024
8192+0 Datensätze ein
8192+0 Datensätze aus
172
KAPITEL 11. FILESERVER
8388608 bytes (8,4 MB) copied, 0,038112 seconds, 220 MB/s
real
user
sys
0m0.046s
0m0.008s
0m0.036s
Im Beispiel agiert der NBD-Server auf einer 100 MByte grossen Datei. Er bietet seine Dienste auf Port 5000 an. Die Portnummer kann frei gewählt werden. So lassen sich
auch mehrere Server für verschiedenen Container starten. Der NBD-Client setzt das geladene Kernelmodul voraus und benötigt als Parameter beim Aufruf die IP-Adresse und
Portnummer des Servers gefolgt vom Namen des lokal anzusprechenden Blockdevices.
Zum (Performance-)Vergleich kann man die Datei einfach ”loopback” mounten:
hermes:/ # mount -o loop /exports/nbd-export /mnt
hermes:/ # time dd if=/dev/zero of=/mnt/text count=8192 bs=1024
8192+0 Datensätze ein
8192+0 Datensätze aus
8388608 bytes (8,4 MB) copied, 0,034517 seconds, 243 MB/s
real
user
sys
0m0.040s
0m0.008s
0m0.024s
Der Performance-Verlust, zugegebenermaßen ist die Messmethode eher grob, hält sich bei
der Verwendung des Netzwerkblockgerätes in Grenzen. Wenn alles auf einer Maschine geklappt hat, kann man darangehen und auf einer entfernten Maschine das Blockdevice einbinden. Dazu muss im Aufruf lediglich die Localhost-Adresse gegen die IP-Adresse des
Servers getauscht werden.
Möchte man eine Partition oder ein LVM-Volume an Stelle einer Datei exportieren,
tauscht man den Dateinamen gegen den Namen des speziellen Devices aus:
linux01:/ # nbd-server 5001 /dev/sda4
Nachdem der Server läuft, kann sich der Client auf diesen mit IP-Adresse und Portnummer
verbinden. Die Verbindung wurde erfolgreich initialisiert, wenn nbd-client keine Fehlermeldung ausgibt.
Die Verbindung zum Server kann vom Client durch den Aufruf von nbd-client -d
/dev/nbd0 gelöst werden. Vorher sollte jedoch das eingehängte Blockdevice ausgemountet
werden:
linux01:/ # umount /mnt
linux01:/ # nbd-client -d /dev/nbd0
NBD ist recht einfach gestrickt: Es überlässt die Integritätsprüfung der übertragenen Daten
dem darunterliegenden TCP.
11.7.2
NBD und Filesysteme
In der bisher geschilderten Anwendung des Blockdevices gelten die identischen Einschränkungen für eine Festplatte bzw. eine Partition auf dieser: Nur eine Maschine kann gleichzeitig lesend und schreibend darauf zugreifen. Es gibt anders als bei Netzwerkdateisystemen
keinen eingebauten Mechanismus der sich um Locking oder den Abgleich der Buffer der
verschiedenen Maschinen kümmert.
Nun spielt dieses Szenario des gemeinsamen schreibenden Zugriffs in vielen Fällen, wie
beispielsweise für das Root-Filesystem von Diskless Clients oder das Bereitstellen eines gemeinsamen Applikationsverzeichnisses keine Rolle. Dann kann man den Blockdevice-Server
11.7. NBDS IM EINSATZ
173
mit der Option ”-r” im nur lesbaren Modus starten: Nun kann kein Client Änderungen am
Blockdevice vornehmen. Bei Verwendung dieser Option sind Journaling-Filesysteme ausgeschlossen. Weder ext3, noch ReiserFS oder XFS liessen sich per nur lesbarem Blockdevice
erfolgreich mounten. Die Fehlermeldungen fielen dabei je nach Dateisystem unterschiedlich
harsch aus:
hermes:~ # mount -t reiserfs /dev/nbd0 /mnt
Kernel call returned: Connection reset by peerClosing: que, sock, done
mount: wrong fs type, bad option, bad superblock on /dev/nbd0,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
hermes:~ # mount -t xfs /dev/nbd0 /mnt/
Kernel call returned: Connection reset by peerClosing: que, sock, done
mount: /dev/nbd0: Konnte den Superblock nicht lesen
Auch der Einsatz der Mount-Option ”-o ro” brachte keine Entspannung. Die Dateisysteme
SquashFS und ext2 hatten jedoch keine Schwierigkeiten.
Eine Alternative beschreiben die Autoren mit der Option ”-c”. Dann kann der NBDServer ein Copy-on-Write ausführen. Dazu legt er für jeden Client eine Datei an, in die alle
Änderungen geschrieben werden.
hermes:~ # nbd-server 5000 /exports/nbd-export -c
hermes:~ # nbd-client 127.0.0.1 5000 /dev/nbd0
hermes:~ # mount -t xfs /dev/nbd0 /mnt
hermes:~ # ls -al /exports
insgesamt 100008
drwxr-xr-x
2 root root
60 2006-04-03 12:39
drwxr-xr-x 23 root root
4096 2006-03-25 21:16
-rw-r--r-1 root root 102400000 2006-04-03 12:33
-rw------1 root root
270336 2006-04-03 12:39
.
..
nbd-export
nbd-export-127.0.0.1-7812.diff
Hier sieht man nun, dass eine separate Datei für die Änderungen angelegt wird. Nach
einem Disconnect des Clients gehen diese Änderungen verloren, obwohl die Datei selbst erhalten bleibt. Macht man nun das Experiment das Blockdevice unter einem der JournalingDateisysteme Readonly einzubinden, sieht man, dass trotzdem etwas auf das Device geschrieben wird. Das erklärt die vorher beschriebenen Probleme.
Die ”-c” Option wird von den Entwicklern des Network Block Device als nicht besonders performant beschrieben, weshalb sich hier besser clientseite Lösungen, wie UnionFS
oder das COW-Modul anbieten. Generell muss auch beim NBD gesagt werden, dass das Sicherheitskonzept alles andere als ausgefeilt ist. Ähnlich zu NFS, jedoch deutlich unflexibler,
kann man eine Liste von Rechnern angeben, denen der Zugriff auf das Device gestattet wird.
Abhilfe könnten hier verschlüsselte Dateisysteme schaffen. Andernfalls hat man zumindest
auf der Ebene der Sicherheit gegenüber einem NFS der Version 2 oder 3 nichts gewonnen.
11.7.3
DNBD - eine spezialisierte Alternative
Neben NBD gibt es weitere freie Implementierung eines Netzwerkblockgeräts, wie beispielsweise ENBD, GNBD oder ANBD. Da die jeweiligen Blockgerätetreiber aber (noch) nicht
Bestandteil des Kernels sind, sucht man ein installierbares Paket bei vielen Distributionen
oft vergeblich. In diesem Fall müssen die Quellen von den unten angegeben Adressen selbst
bezogen werden. Für den Mehraufwand bekommt man beispielsweise bei ENBD eine Fehlerbehandlung mit dem automatischen Wiederaufbau einer abgebrochenen Verbindung, der
gleichzeitigen Benutzung mehrerer Kanäle und vieles mehr.
174
KAPITEL 11. FILESERVER
Für ein recht spezifisches Umfeld, nämlich für den Diskless-Betrieb in Funknetzen,
gibt es DNBD, welches hier auftretende Probleme auf besondere Art und Weise handhabt. In einem typischen Funknetz-Szenario assozieren sich Clients mit einem Access Point
und benutzen dabei dieselbe Frequenz, was natürlich bedeutet, dass für eine funktionierende Kommunikation nur ein Client zu einem bestimmten Zeitpunkt senden darf. Hinzu
kommt die niedrige Bandbreite, die bei den heute verwendeten Technologien, wie dem IEEE 802.11b/a/g Standard, auf 54 Mbit/s begrenzt ist. Manche Hersteller versprechen zwar
Datenraten von 108 Mbit/s - bei allen ist der effektive Durchsatz aber meist viel niedriger.
Unabhängig von der Datenrate sind aber die Kosten für neue Clients, was die Größe der
transferierten Datenmengen betrifft. Verdoppelt man die Anzahl der Clients, so lässt im
Durchschnitt in einem bestimmten Zeitintervall nur noch die halbe Datenmenge je Client
übertragen.
Die Frage ist nun, ob es denn überhaupt möglich und sinnvoll ist, das Konzept festplattenloser Rechner zum Beispiel auf mobile Pools in Funknetzen auszuweiten. Das Problem
der begrenzten Bandbreite und schlechten Skalierbarkeit zusammen mit dem Wunsch einer Fehlerbehandlung (z.B. mit Failover auf replizierte Server) und das in unzuverlässigen
Netzen mit Paketverlusten, sprechen nicht gerade für einen solchen Einsatz.
DNBD versucht deshalb, im Unterschied zu den bisher vorgestellten Netzwerkblockgeräten anfallende Datenmengen so weit wie möglich zu minimieren und dabei die Besonderheiten eines Funknetzes auszunutzen. Zuerst wird für ein vereinfachtes Protokoll auf
Locking-Mechanismen verzichtet und nur lesbarer Zugriff erlaubt, was clientseitig beispielweise mit cowloop wieder aufgehoben werden kann. Zweitens werden Blöcke, die von einem
Client angefordert werden und schließlich vom Server geliefert werden, von anderen Clients gecachet, falls diese später selbst Bedarf dafür haben sollten. Drittens wird UDP als
verbindungsloses Protokoll verwendet und Paketverluste und andere Kommunikationsprobleme werden von DNBD selbst bearbeitet.
Jetzt stellt sich nur noch die Frage, wie Blöcke abgefangen und gecachet werden können.
Das gemeinsam benutzte Medium bei Funknetzen erlaubt zwar prinzipiell das Mithören
der Kommunikation anderer Clients - leider unterstützen aber nicht alle Karten einen
so genannten Promiscuous- bzw. Monitor-Modus. Und falls doch, so muss dieser für die
jeweiligen Chipsätze meist auf unterschiedliche Art und Weise aktiviert werden. DNBD
benutzt deshalb IP-Multicast, um eine Gruppe von Clients gleichzeitig zu adressieren. Eine IP-Multicast-Adresse liegt hier im Netz 224.0.0.0/4 - für Experimente sollte das Netz
239.0.0.0/8 benutzt werden. Bevor bei DNBD ein Client auf ein Netzwerkblockgerät zugreifen kann, versucht er vorhandene Server zu finden, indem er bestimmte Pakete an
die gegebene Multicast-Adresse schickt. Die Server beantworten die Anfrage und liefern
gleichzeitig Informationen über das vorhandene Blockgerät. Die Clients benutzen diese Daten zu Konfiguration und können fortan Blöcke anfragen. Die komplette Kommunikation
funktioniert mit UDP aus mehreren Gründen: Das einfach gestrickte UDP (im Vergleich
zu TCP) ist völlig ausreichend um Blöcke anzufordern und bietet die Möglichkeit eigene
(meist zeitgesteuerte) Methoden für den Datenfluss etc. zu realisieren; außerdem ist Multicast mit TCP beim Linux-Netzwerkstack nicht implementiert und seine Verwendung wäre
überhaupt nicht möglich gewesen.
Für eine hohe Verfügbarkeit lassen sich Server zusätzlich replizieren. Neue Server werden von den Clients dabei automatisch gefunden, indem dauernd statistische Daten gesammelt werden, und Server mit niedrigen Antwortzeiten ausgesucht werden. Für den
Einsatz von DNBD in kabelgebundenen Netzen wird wegen des Overheads der MulticastKommunikation allerdings noch abgeraten bis DNBD auch Unicast-Kommunikation unterstützt.
11.8. SPEZIELLE BLOCKDEVICE-ERWEITERUNGEN
175
Natürlich werden immer für sinnvolles Caching Lokalitätseigenschaften vorausgesetzt,
d.h. in unserem Fall sollten unterschiedliche Clients in einem gewissen Zeitraum auf dieselben Blöcke zugreifen. Dies ist zum Beispiel beim simultanen Start von verschiedenen
Diskless Clients in Funknetzen gegeben. Eine weitere Anwendung ist die Bereitstellung von
Multimedia-Inhalten in Funknetzen: Mehrere Clients können eine DVD über ein WLAN
abspielen, wobei dank des Caches auch Zeitdifferenzen erlaubt sind, ohne dass ein neuer
Stream gestartet werden muss.
11.8
Spezielle Blockdevice-Erweiterungen
In Umgebungen von Diskless Clients spielt die Beschreibbarkeit des Dateisystems eine besondere Rolle. Einerseits soll das Dateisystem auf dem Server ”sauber” bleiben, d.h. Clients bekommen keinen Zugriff, Systemdateien zu verändern. Andererseits setzen Clients
voraus, dass Dateien, die für den Betrieb notwendig sind, angelegt oder verändert werden können, z.B. /etc/resolv.conf. Bei einem nur lesbaren Blockgerät ergibt sich hier eine
Möglichkeit, indem es mit cowloop (Copy-on-Write-Loopback Device) schreibbar gemacht
wird. Geänderte Blöcke werden getrennt in einem so genannten ”sparse file” aufbewahrt,
welches sich wiederum in einer Ramdisk befinden kann. Anders als bei UnionFS, wo selbst
bei kleinsten Änderungen an einer Datei diese schon komplett in die beschreibbare Schicht
kopiert werden muss, geht cowloop sparsamer mit dem Platz um und vermerkt nur wirklich geänderte Blöcke. Es setzt dafür jedoch ein schreibbares Dateisystem voraus: Ein mit
dem RO-Filesystem SquashFS formatiertes Netzwerkblockgerät wird auch durch spezielle
Write-Loopback-Devices nicht veränderbar.
Ein Nachteil bei dieser Benutzung von Netzwerkblockgeräten ist, dass sich die Clients
nicht transparent updaten lassen. Änderungen am Blockdevice auf dem Server erfordern
einen Neustart der Clients oder zumindest einen komplizierten Remount Mechanismus. Da
Änderungen am System in der Praxis meist nur bei Sicherheitsupdates oder einem Umstieg
auf eine neuen Ausgabe der Distribution wirklich notwendig sind, hält sich der Aufwand in
Grenzen.
Wurde ein Network Block Device wie im letzten Abschnitt beschrieben aufgesetzt, so
lässt sich cowloop wie folgt einsetzen:
linux01:~ #
linux01:~ #
/dev/cow/0
linux01:~ #
linux01:~ #
modprobe cowloop
cowdev -a /dev/nbd0 /tmp/nbd.cow
mkdir /mnt/nbd-rw && mount /dev/cow/0 /mnt/nbd-rw
umount /mnt/nbd-rw && cowdev -d /dev/cow/0
In diesem Beispiel wird ein Netzwerkblockgerät mit der schreibbaren Datei /tmp/nbd.cow
verknüpft und das neue Blockgerät dann gemountet. Schreibvorgänge in nbd-rw wirken sich
deshalb nicht auf das zu Grunde liegende Netzwerkblockgerät aus. Falls sich cowloop über
ein fehlendes /dev/cow/ctl oder /dev/cow/0 beschwert, so hilft
linux01:~ # mkdir /dev/cow && mknod /dev/cow/ctl b 241 255
linux01:~ # ln -s /dev/cowloop0 /dev/cow/0
176
KAPITEL 11. FILESERVER
Dateisystem
copy-on-write
Blockgerät
Lesen
nur lesbares
Blockgerät
Lesen und Schreiben
schreibbare
Datei
Abbildung 11.2: Das Cowloop-Blockgerät basiert auf einem weiteren Blockgerät und hält
geänderte Blöcke in einer Datei fest
Kapitel 12
Samba
12.1
Samba - Brücke zwischen Microsoft- und Unix-Welt
Für viele gehören Samba und Linux einfach zusammen - der Anteil von Samba an der Popularisierung von Linux ist nicht zu unterschätzen. Samba bildet eine der wichtigsten Brücken
zwischen der Linux/Unix und Windowswelt. Dieses beginnt bei einfachen Verzeichnis- und
Druckerfreigaben und läßt sich fortsetzen bis zu Single-Password- oder Single-Sign-OnLösungen und komplexen Domaincontroller-Aufgaben, die ein Linux-Rechner übernehmen
kann. ”Samba” steht für die freie Implementierung eines Server Message Block Protokollservers. Samba spricht sich einfach besser aus und klingt netter als die Abkürzung des
Protokollnamens ”SMB”.
Microsoft-Rechner benutzen dieses Protokoll untereinander, um auf Dateien und Drucker über ein Netzwerk zuzugreifen. In dieses Netzwerk können sich auch Linux oder Unixrechner dank Samba einklinken. Sie können dabei dank Samba als Client agieren oder auch
tragendere Rollen übernehmen.
Samba ist ein Open-Source-Projekt welches im Jahre 1991 von Andrew Tridgell an der
Canberra University in Australien gestartet wurde. Entsprechend steht der in C geschriebene Source-Code jedem zur Verfügung. Jeder kann ihn anpassen, untersuchen und testen.
Für Administratoren in Firmen und Organisationen das Wichtigste: Samba ist frei. Anders
als für jede Microsoft Installation fallen für das Aufsetzen eines Samba-Servers oder die
Benutzung der Samba-Dienste unter Linux keinerlei Lizenzgebühren an.
12.1.1
Einsatzgebiete von Samba
SMB beschränkt sich nicht auf die Funktion als Netzwerkdateisystem oder Remote-Printer.
Allein schon für diese beiden Aufgaben gibt es in der Unixwelt zwei verschiedene Dienste:
Beispielsweise LPD für Drucker und NFS für Netzwerkdateisysteme. SMB kann eine ganze
Menge mehr:
• Das Samba-Paket enthält SMB-Clients, mittels derer Unix-Rechner auf freigegebene
Dateien oder Drucker anderer SMB-Server zugreifen können. Ein Linuxclient kann
so Druckjobs an einen Windowsdrucker absetzen oder ein gemeinsames Dokumentenverzeichnis von einer Windowsmaschine einbinden. Diese Funktionalität stellt eine
Bibliothek zur Verfügung, die von anderen Programmen genutzt werden kann, bsp.
dem KDE-Konqueror. Für die Kommandozeile liefert Samba die Tools smbmount,
smbclient und mount.cifs mit.
• Samba realisiert einige Erweiterungen des SMB-Dateisystems, damit bestimmte UnixDateien auf entfernten SMB-Freigaben abgelegt werden können.
177
178
KAPITEL 12. SAMBA
• Samba kann die Aufgaben des Windows-Namens-Dienstes (WINS) übernehmen: Als
NetBIOS-Nameserver kann es Namen auf IP-Nummern und umgekehrt abbilden.
Zusätzlich unterstützt es NetBIOS-Browsing und Browse-Master-Auswahl.
• Samba kann ein Single-Sign-On realisieren: Der Zugriff auf den Linux-Account und
die Einbindung des Linux-Homeverzeichnisses unter Windows laufen mit identischen
IDs und Passwort.
• Samba kann als primärer Domänen-Controller für Windows-Clients eingesetzt werden.
• Samba bringt Werkzeuge für entfernte Administrationsaufgaben für Windows-NTund Samba-Server mit.
12.2
Erste Versuche
Wenn Samba schon auf der Maschine installiert ist, kann der Anwender schonmal erste
Schritte wagen. Wenn nicht, überspringt er diesen Abschnitt und kümmert sich ersteinmal
um die Installation. Samba funktioniert in ”beide Richtungen”: Es stellt Client- und Serverfunktionalität bereit. Für viele, die von der Windows-Seite her kommen, ist es bekannt, wie
Freigaben unter Windows erfolgen. Man gibt einfach mal ein Unterverzeichnis mit Klicken
der rechten Maustaste auf den Ordner frei. Dann definiert man die Einstellungen in der
Registerkarte ...
Abbildung 12.1: Freigeben eines Verzeichnisses unter WindowsXP und Setzen der Zugriffsrechte
12.2.1
Windows-Server - Linux-Client
Diese Freigabe oder ”Share” kann nun von Linux aus eingebunden werden. Hierzu gibts
das Kommando smbmount oder sein Nachfolger mount.cifs. Mounts können aus Sicherheitsgründen unter Linux nur vom Benutzer ”root” ausgeführt werden.
Jedoch gibt es auch Möglichkeiten dieses normalen Usern zu erlauben. In der Standardinstallation liefert smbmount bei unpriveligiertem Aufruf die Fehlermeldung smbmnt must
be installed suid root for direct user mounts (500,500). Dem kann man unter
12.2. ERSTE VERSUCHE
179
Verzicht auf etwas Sicherheit abhelfen: chmod u+s /usr/bin/smbmnt /usr/bin/smbumount.
Anschliessend bindet der Aufruf
smbmount //10.8.4.204/SharedFiles win -o username=dirk
die Windows-Freigabe ”ShraredFiles” an das Unterverzeichnis win. Die Verbindung erfolgt
mit der Windows-UserID ”dirk”, das Passwort fragt smbmount dann interaktiv ab. Anschliessend gibt das Kommando mount das eingebundene Verzeichnis in seiner Liste mit
an:
dirk@linux:~> mount
/dev/hdb2 on / type ext3 (rw)
proc on /proc type proc (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/hdc2 on /home type ext3 (rw)
//10.8.4.204/SharedFiles on /home/dirk/win type smbfs (0)
Der Inhalt des Verzeichnisses win sind die Dateien, die sich auf der Windows-Maschine
im freigegebenen Ordner befinden. Es gibt jedoch einige Einschränkungen: Dateien und
Ordner kann der Nutzer wie gewohnt anlegen. Die Dateien gehören immer ihm, das UnixRechtemuster wird nur zum Teil abgebildet. Nicht möglich sind spezielle Dateien, wie Links,
Sockets oder Named Pipes. Der Vorteil von Samba: Anders als mit NFS oder Geräten muss
kein passender Eintrag in der /etc/fstab stehen, um Benutzern das Einbinden von WindowsFreigaben zu erlauben.
Umgekehrt wird der Nutzer das eingebundene ”Share” durch den Befehl smbumount
wieder los: smbumount win meldet die Freigabe ab und die Liste des Mount-Kommandos
reduziert sich um den entsprechenden Eintrag. Für diese kleinen Experimente ist es nicht
notwendig, dass die beiden Samba-Dämonen smbd und nmbd gestartet sind.
Mit der Weiterentwicklung von Windows und Samba wird das lange Zeit vorherrschende
SMB-Filesystem (smbfs) zunehmend durch das mächtigere CIFS (Common Internet File
System) ersetzt. Dieses drückt sich auch im Mount-Kommando für die Client-Seite aus:
mount.cifs //10.8.4.204/SharedFiles win -o username=dirk bindet mit identischer
Syntax ein Windows-Share an ein Linuxverzeichnis. Bisher ist dieses jedoch nur ”root”
vorbehalten oder man räumt auch hier mittels SUID-Bit Usern das Recht ein. Leider fehlt
dazu noch ein passendes Pendant zum Ausmounten. Das Eintrag in der Mount-Liste sieht
ein wenig anders aus:
//10.8.4.204/SharedFiles on /home/dirk/SharedFiles type cifs (rw,mand,nosuid,nodev)
Ein weiteres Tool ist smbclient. Es kann neben anderen Funktionen dem Nutzer ein FTPähnliches Interface zum Verbinden auf SMB-Dienste bieten.
dirk@linux:~> smbclient -U dsuchod //dsuchod.files.uni-freiburg.de/windows
Password:
Domain=[PUBLIC] OS=[Unix] Server=[Samba 3.0.9-2.3-SUSE]
smb: \> ls
.
D
0 Mon Sep 26 18:02:51 2005
..
D
0 Sat Sep 24 01:44:53 2005
.AbiSuite
D
0 Sat Jun 5 02:41:49 2004
[ ... Haufen weitere versteckte Dateien mit Punkt am Anfang ... ]
Bilder
D
0 Thu Apr 21 13:32:38 2005
Desktop
D
0 Thu Jun 30 22:28:19 2005
Eigene Bilder
D
0 Tue Aug 16 11:35:58 2005
Eigene Musik
D
0 Wed Sep 8 17:27:06 2004
GNUstep
D
0 Thu Jan 8 12:46:33 2004
180
KAPITEL 12. SAMBA
IM01OLYM
D
0 Mon Nov 17 16:37:14
Mail
D
0 Mon Sep 26 18:07:45
OpenOffice.org1.1
D
0 Wed Oct 20 09:44:31
PDFs
D
0 Mon Jan 10 19:06:34
PostScripts
D
0 Wed Mar 31 13:41:28
Slides
D
0 Fri Sep 10 14:28:28
artikel
D
0 Wed Dec 22 14:48:45
[ ... Haufen weitere Dateien und Verzeichnisse ... ]
32784 blocks of size 262144. 8028 blocks available
smb: \>
smb: \> put einstieg.txt
putting file einstieg.txt as \einstieg.txt (1488,4 kb/s) (average
1488,5 kb/s)
smb: \> get ToDo
2003
2005
2004
2005
2004
2004
2004
Dieses Beispiel benutzt einen Standard-Fileserver auf Samba-Basis. Eine Die Verbindung
zu einer Freigabe erfolgt in der bekannten Windows-Syntax: //Rechnername/Freigabe oder
//IP-Adresse/Freigabe, wobei einfach die Backslashes in Slashes umgeändert werden. Erstere haben in der Shell eine besondere Bedeutung. Wenn die Verbindung unter einer vorgegebenen UserID erfolgen soll, kann der Anwender diese mit der Option -U mitteilen. Bei
der Verbindungsaufnahme fragt dann smbclient nach dem Passwort. Eine Verbindung auf
eine Windows-Maschine unterscheidet sich bis auf die Statuszeile nicht:
dirk@linux02:~> smbclient -U dirk //10.20.90.60/SharedFiles
Password:
Domain=[MYLAPTOP] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
smb: \> quit
Nach erfolgter Verbindung liefert das Kommanod ls Dateien und Verzeichnisse in der Freigabe. Der Verzeichniswechsel erfolgt wie gewohnt mit cd. Mit put lassen sich Dateien auf
das ”Share” hochladen, mit get welche in das lokale Verzeichnis kopieren, von wo aus
smbclient gestartet wurde. Am Ende verlässt man die Samba-Shell mit quit.
12.2.2
Linux-Server - Windows-Client
Dieser Fall ist der in der Realität sicherlich häufigere: Warum im Serverraum eine Maschine
mit aufwändiger grafischer Benutzeroberfläche und nicht zu vernachlässigenden Lizenzkosten stellen, wenn es stabile und günstige Alternativen gibt? Die Serverfunktionalität stellen
zwei Hintergrundsdienste, die Dämonen smbd und nmbd bereit. Letzterer kümmert sich
dabei um den Windows-Namensdienst (WINS) und muss nicht zwingend laufen.
Der Administrator konfiguriert beide Dienste mit der gemeinsamen Datei smb.conf.
Diese befindet sich je nach Distribution üblicherweise im Unterverzeichnis /etc/samba. Für
einen ersten Test legt der Admin eine Minimalkonfiguration dieser Datei an oder ändert
die Vorgabe der liefernden Distribution passend ab. Für erste Versuche soll das Verzeichnis
vorher frisch angelegte Verzeichnis /win-export benutzt werden. Auf dieses sollen die beiden
Benutzer ”test1” und ”test2” nach Eingabe ihres Passworts zugreifen können.
[global]
workgroup = SAMBA
netbios name = MYSMB
os level = 2
unix extensions = Yes
encrypt passwords = Yes
map to guest = nobody
socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
hosts allow = ALL
12.3. WEITERGEHENDE KONFIGURATION
181
log level = 10
[winshare]
comment = Testfreigabe fuer Windows-Clients
path = /win-export
locking = No
read only = Yes
valid users = test1 test2
create mask = 0600
directory mask = 0750
Nach aussen bietet sich die Freigabe mit dem Namen ”winshare” an. Dieser Name muss in keiner
Weise mit dem Verzeichnis, welches exportiert wird, übereinstimmen. Im Übrigen ist die Groß- oder
Kleinschreibung in der smb.conf mit Ausnahme der Pfadangaben unter Linux irrelevant. Die beiden
Benutzer ”test1” und ”test2” müssen lediglich als System-Accounts existieren. User benötigen für
Samba nicht zwingend Linux-Loginrechte oder einen Eintrag in der /etc/shadow. Da Linux und
Windows verschiedene Verschlüsselungsverfahren für Passwörter benutzen, muss selbst bei Existenz
eines gültigen Linux-Passworts ein neues Windows-Passwort generiert werden. Dieses triggert der
Systemadministrator durch:
linux:/win-export # smbpasswd -L -a test1
New SMB password:
Retype new SMB password:
Passwörter, die auf diese Weise generiert wurden, landen in der Datei /etc/samba/smbpasswd. Anschliessend steht der (Neu-)Start des Dienstes durch rcsmb restart oder /etc/rc.d/smb restart
an.
Anschliessend greift sich der Anwender eine Windowsmaschine, die mit dem gleichen Netzwerk,
wie der frisch aufgesetzte Linux-Samba-Server verbunden ist und versucht am besten erstmal durch
Eingabe der IP-Nummer die neue Freigabe unter Windows einzubinden.
Wenn der Nutzer unter einer anderen UserID an seiner Windows-Maschine angemeldet ist,
kann er diesen bei Windows-XP beim Anmelden an die Freigabe wechseln. Auch das Passwort
muss nicht mit dem der Windows-Anmeldung übereinstimmen. Soll der Samba-Server automatisch
beim Start der Linuxmaschine hochfahren, kann der SuSE-Admin diesen Dienst durch insserv
smb,start=3,5; insserv nmb,start=3,5 für die Runlevel 3 und 5 aktivieren. Alternativ können
auch Links in den entsprechenden Runlevel-Unterverzeichnissen /etc/init.d/rc3.d und /etc/init.d/
rc5.d angelegt werden.
Der Sambaserver sollte dann auch im ”Microsoft Windows-Netzwerk” auftauchen (Abb. xpsambatestnetz). Wenn der Anwender dann auf ”Samba” klickt, sieht er in diesem Netz mindestens
den Samba-Server ”Mysmb”. Im Kommentar steht die Versionsbezeichnung von Samba. Wenn da
etwas anderes erscheinen soll, fügt der Admin server string = Kommentar mit seinem Kommentar
in der [global] Sektion ein.
12.3
Weitergehende Konfiguration
Im gezeigten ersten Beispiel bekamen die beiden Benutzer ”test1” und ”test2” ein Verzeichnis auf
einer Linux-Maschine nur lesend nach Eingabe ihres Benutzernamens und Passwortes zur Verfügung
gestellt. Soll eine Anmeldung für diese Freigabe auch ohne Passwort möglich sein, kann der Admin
das Schlüsselwort ”public = Yes” definieren. Dann sollte er jedoch die Option ”valid users” leeroder weglassen.
Im Fall von Fehlern und zur Kontrolle des korrekten Starts des Samba-Servers sollte der Admin
das Logfile des Dienstes kontrollieren. Standardmäßig wird dieses bei einer SuSE-Distribution unterhalb von /var/log/samba angelegt. Das Logfile des smbd heisst einfach log.smbd, das des nmbd
entsprechend.
[2004/11/10 16:09:36, 0] smbd/server.c:main(757)
smbd version 3.0.4-SUSE started.
Copyright Andrew Tridgell and the Samba Team 1992-2004
182
KAPITEL 12. SAMBA
Abbildung 12.2: Durch die direkte Eingabe der IP-Nummer umgeht der Anwender eventuelle Probleme bei der Windows-Namensauflösung
[2004/11/10 16:09:36, 5] lib/debug.c:debug_dump_status(369)
INFO: Current debug levels:
all: True/10
tdb: False/0
printdrivers: False/0
lanman: False/0
smb: False/0
rpc_parse: False/0
rpc_srv: False/0
rpc_cli: False/0
passdb: False/0
sam: False/0
auth: False/0
winbind: False/0
vfs: False/0
idmap: False/0
quota: False/0
acls: False/0
doing parameter veto files = /*.eml/*.nws/riched20.dll/*.{*}/
[2004/11/10 16:09:36, 2] param/loadparm.c:do_section(3396)
Processing section "[winshare]"
doing parameter comment = Testfreigabe fuer Windows-Clients
doing parameter path = /win-export
doing parameter locking = No
doing parameter read only = Yes
12.3. WEITERGEHENDE KONFIGURATION
183
doing parameter valid users = test1 test2
doing parameter create mask = 0600
doing parameter directory mask = 0750
[2004/11/10 16:09:36, 4] param/loadparm.c:lp_load(3913)
pm_process() returned Yes
[2004/11/10 16:09:36, 7] param/loadparm.c:lp_servicenumber(4026)
lp_servicenumber: couldn’t find homes
[2004/11/10 16:09:36, 3] param/loadparm.c:lp_add_ipc(2363)
adding IPC service
[2004/11/10 16:09:36, 3] param/loadparm.c:lp_add_ipc(2363)
adding IPC service
[ ... ]
Mit dem im Beispiel eingestellten Loglevel von 10 ist der Dienst ziemlich geschwätzig. Das
macht bei funktionierendem Normalbetrieb weniger Sinn. Je nach Sicherheits- und Informationsbedürfnis genügt ein Loglevel von 0 bis 3 für die wichtigsten Ereignisse. Meldungen
über Fehler in der Konfigurationsdatei landen in jedem Fall hier.
Eine weitere Möglichkeit der Überprüfung des Server-Zustandes bietet das Kommando
smbstatus. Einfach aufgerufen liefert es eine Liste der aktuell gültigen Verbindungen:
linux:~ # smbstatus
Samba version 3.0.9-SUSE
PID
Username
Group
Machine
------------------------------------------------------------------30208
test2
testgroup
zxs (10.8.4.160)
Service
pid
machine
Connected at
------------------------------------------------------winshare
30208
zxs
Wed Sep 21 18:33:58 2004
No locked files
12.3.1
Homeverzeichnisse für Windows und Linux
Sollen Benutzer ein gemeinsames Homeverzeichnis unter Linux und Windows benutzen, erlaubt
dieses die spezielle Sektion [homes] in der Konfigurationsdatei /etc/samba/smb.conf:
[homes]
comment = Home Directories
valid users = %S
browseable = Yes
read only = No
create mask = 0640
directory mask = 0750
Möchte man einer Benutzergruppe das gemeinsame Zugriffsrecht auf eine Freigabe einräumen, muss diese vorher in /etc/group definiert sein.
[gruppenfreigabe]
comment = Beispiel einer Gruppenfreigabe
read only = No
browseable = No
valid users = @testgroup
force group = testgroup
path = /gruppenfreigabe
create mask = 0770
force create mode = 0770
directory mask = 0770
force directory mode = 0770
184
KAPITEL 12. SAMBA
In diesem Beispiel dürfen alle Mitglieder der Gruppe ”testgroup” sich mit dem Share verbinden. Alle Dateien und Verzeichnisse werden so angelegt, dass nur Gruppenmitglieder sie
ändern dürfen. Die Maske 0770 erzwingt Gruppenschreibrechte und verhindert gleichzeitig,
dass Dateien nur vom Erzeuger selbst geändert werden dürfen. Die Option browseable =
No sorgt dafür, dass die Freigabe nicht in der Netzwerkumgebung auftaucht.
12.3.2
Druckerfreigaben
Bis zu diesem Punkt wurden verschiedene Arten der Verzeichnisfreigaben diskutiert. Das
SMB-Protokoll erlaubt es aber auch, Drucker im Netz gemeinsam zu benutzen. Hierzu gibt
es die Sektion [printers] in der /etc/samba/smb.conf.
[printers]
comment = All Printers
path = /var/tmp
printable = Yes
create mask = 0600
browseable = No
writable = yes
public = yes
Viele der Optionen sind nun schon von den anderen Beispielen bekannt. Die Pfadangabe
dient nun nicht als Freigabe, sondern als Spoolverzeichnis. In diesem landen die abzuarbeitenden Jobs der berechtigten Benutzer. In den Globaleinstellungen der smb.conf sind zwei
weitere Variablen zu definieren. Der Admin legt fest, welches Drucksystem Verwendung
findet. Auf modernen Distributionen greift er üblicherweise auf das Common Unix Printer
System (CUPS) zurück:
printing = CUPS
printcap name = CUPS
Der Dienst CUPS muss vor Samba gestartet werden. Dieses überprüft insserv beim Anlegen
der Runlevel-Links. Die Installation von Druckern unter Linux erledigt der Admin am
einfachsten mit den mitgelieferten Konfigurationswerkzeugen, beispielsweise YaST2 von
SuSE. Nach einem Neustart von Samba stehen die frisch definierten Druckerwarteschlangen
auch Windows-Clients zur Verfügung.
12.3.3
Nachrichtendienst auf Linux-Clients
Der Windows-Nachrichtendienst ist bei Anwendern, die mit ihrer Windows-Maschine direkt ins Internet gehen vielleicht etwas in Verruf geraten. Vielfach meldeten sich unaufgefordert explizite Damen, um ihre Services irgendwo im Netz anzubieten. Im abgeschlossenen privaten Netz kann der Dienst jedoch ganz nützlich sein. Damit auch ein LinuxClient Windows-Nachrichten empfangen kann, muss ein Samba laufen. Dieses wurde in
der [global]-Sektion um den Eintrag message command = sh -c ‘/opt/kde3/bin/kpopup
’’%s’’ ’’%f’’‘ erweitert. Das Programm kpopup ist meistens ein eigenes Paket, welches unter Umständen nachinstalliert werden muss. Je nach Distribution können Pfad und
Paketname variieren.
12.4
Die zentrale Samba-Konfigurationsdatei
In den bisherigen Abschnitten kamen schon Beispiele für mögliche Varianten der smb.conf
vor. Da es eine ziemlich große Zahl an Konfigurationsparametern, sollen die wichtigsten
hier zusammengestellt werden. Eine gute Hilfe ist auch die Manpage (man smb.conf).
12.4. DIE ZENTRALE SAMBA-KONFIGURATIONSDATEI
12.4.1
185
Struktur
Die Datei smb.conf wird durch Konfigurationsblöcke strukturiert. Der Block [global] - er
steht am besten immer am Anfang der Datei - ist immer vorhanden und definiert generelle Servereinstellungen. Daneben existiert eine weitere Gruppe von optionalen Blöcken,
deren Namen fest vorgegeben sind. Der Block [homes] definiert die Freigabe der Homeverzeichnisse der auf einem Linuxsystem eingetragenen Benutzer. So können Admins dafür
sorgen, dass ihre Nutzer sowohl unter Linux als auch unter Windows auf das selbe Homeverzeichnis zugreifen können. Mit [printers] erfolgt die Freigabe der auf einem Linuxrechner
verfügbaren Drucker. [print$] ist eine spezielle Freigabe, die es Administratoren erlaubt,
Druckertreiber bereit zu stellen. So müssen diese dann nicht mittels CD eingespielt werden, wenn ein Windows-Client auf einen Linuxdrucker zugreift für den dieser noch keinen
Treiber installiert hat. Die Sektion [netlogon] spielt dann eine Rolle, wenn Samba über
Datei- und Druckerfreigaben hinaus reichende Aufgaben übernehmen soll. Zusätzlich kann
ein Samba-Administrator weitere Blöcke definieren. Die Namen dieser Blöcke entsprechen
den Freigabenamen, die ein Windows-Client sieht oder anspricht.
Die Zuweisung von Inhalten an eine Konfiguration erfolgt mittels simplem ”=” - links
steht der Variablenname und rechts die Zuweisung. Zuweisungen von mehr als einem Wert
sind durch einfache Abstände voneinander getrennt.
12.4.2
Wichtige Optionen in der Sektion [global]
• workgroup = SAMBA - ordnet den Linux-Samba-Server in die Windows-Arbeitsgruppe
oder Domain ”SAMBA” ein. Diese Maschine erscheint sodann in der Windows-Netzwerkumgebung in einem Unterordner mit diesem Namen.
• netbios name = MYSMB - legt fest, dass die Maschine unter dem Windows-Namen
”MYSMB” in der Netzwerkumgebung auftaucht und angesprochen werden kann. Dieser Name muss nicht identisch zum FQDN des TCP/IP Domain Name System sein.
Soll Samba einfach den Linux-Rechnernamen benutzen, kann dieser Eintrag entfallen.
• os level = 64 - bestimmt darüber mit welchem Wert sich Samba für Browse-Wahlen
anbietet. Das entscheidet beispielsweise über die Chance ein lokaler Masterbrowser
einer Arbeitsgruppe zu werden.
• unix extensions = Yes - dieser Parameter stellt ein, ob Samba die CIFS Extensions für Unix unterstützt. Damit stehen dann Symbolische Links, Hard Links, ... zur
Verfügung. Nur interessant für Unix-Clients.
• encrypt passwords = Yes - neuere Windows-Clients erwarten verschlüsselte Passwörter. Deshalb kann nicht die klassische Unix-Shadow zum Einsatz kommen. Damit
Samba korrekt authentifizieren kann, hat es entweder Zugriff auf eine lokale smbpasswd Datei oder kann gegen einen entsprechenden Dienst authentifizieren.
• log file = /var/log/log.%m - überschreibt die einkompilierte Default-Position des
Logfiles. %m wird durch den Dienst nmbd oder smbd ersetzt, welcher Log-Informationen generiert.
• log level = 10 - steigende Werte generieren umfangreichere Logfiles. Es können
einzelnen Komponenten unterschiedliche Loglevel zugeordnet werden: log level =
3 passdb:4 auth:8 winbind:3.
186
KAPITEL 12. SAMBA
• bind interfaces only = Yes - definiert, auf welchen Netzwerkschnittstellen der
Samba-Server seine Dienste anbietet. Diese Option arbeitet mit der folgenden eng
zusammen.
• interfaces = 127.0.0.1 10.8.4.254/24 - legt fest, dass sowohl das LoopbackInterface und das Interface mit der IP 10.8.4.254 bedient werden. Letzeres umfasst
ein Netzwerk von 256 Maschinen (Netzmaske 255.255.255.0).
• hosts allow = All - legt keine Beschränkungen auf bestimmte Maschinen fest. Hier
könnte sonst auch eine leerzeichengetrennte Liste von IP-Nummern stehen, die auf
den Service zugreifen dürfen.
• message command = /bin/bash -c ‘/usr/X11R6/bin/xterm -T ’’WinPopup
Message’’ -e /usr/bin/vim %s; rm %s’ & - erlaubt es unter Linux ebenfalls
Windows-Popup-Messages zu empfangen. Die Nachrichten reicht Samba an ein externes Programm - hier ein einfaches xterm mit vi weiter. %s enthält den Inhalt der
Nachricht, %t ist der Zielname, an den die Nachricht ging. %f bezeichnet den Client,
von dem die Nachricht kam.
12.4.3
Wichtige Optionen der anderen Abschnitte
• comment = All Printers oder comment = Gemeinsame Daten - setzen ein Kommentar für eine Freigabe fest, die an die Clients übermittelt wird.
• path = /win-export - legt für Dateifreigaben fest, welches Verzeichnis im LinuxDateibaum Samba bereitstellen soll. Für Drucker definiert diese Variable das Spoolverzeichnis.
• create mask = 0600 - definiert das Rechtemuster beim Anlegen von Dateien. Hierzu
werden die Permissions vom Mapping von DOS oder Linux bestimmt und diese dann
mit dem Muster UND-verknüpft. Das Muster entspricht dem von chmod bekannten.
• force create mask = 0600 - erzwingt das Setzen eines bestimmten Bitmusters für
die Zugriffsrechte. Im Bespiel würde eine Datei auf jeden Fall die Rechte -rw-----bekommen.
• directory mask = 0750 - stellt das Analogon zu ”create mask” dar. Es legt fest mit
welchem Rechtemuster Samba neu angelegte Verzeichnisse versieht. Auch hier gibt es
die Option ”force directory mask”.
• valid users = test1 test2 - nimmt eine Leerzeichenseparierte Liste von Benutzern auf, die auf diesen Dienst verbinden dürfen. In der Sektion [homes] findet man
hier valid users = %S. %S wird durch den Namen des sich anmeldenden Nutzers
automatisch ersetzt. Deshalb muss nicht für jeden der vielleicht viele hundert oder
tausend Benutzer umfassenden Maschine eine eigene Freigabe definiert werden.
• browseable = No - kontrolliert, ob die Freigabe in einer Browse-Liste der Netzwerkumgebung angezeigt wird oder nicht.
• read only = No oder writable = Yes - erlaubt dem Benutzer eines Services Dateien
oder Verzeichnisse anzulegen und zu verändern.
• printable = Yes - erlaubt dem Client auf das Drucker-Spooler-Verzeichnis zu schreiben.
12.5. CONTROLLER-FUNKTIONALITÄT
187
• public = Yes alternativ guest ok = Yes - legen fest, ob eine Verbindung ohne Passwort möglich ist. Die Rechte sind dann die des Gast-Accounts.
12.4.4
Virtuelle Samba-Server
Der Apache-Webserver macht es seit einiger Zeit vor: Ein Server sollte in der Lage sein, mehr
als eine Identität gleichzeitig anzunehmen. Auch das SMB-Protokoll kann namensbasierte
virtuelle Server anzubieten. Dabei befinden sich alle in der gleichen Arbeitsgruppe. Sinn und
Zweck dieser Übung - eine Maschine ist unter mehreren Namen in der Netzwerkumgebung
sichtbar. Der Admin konfiguriert dieses Verhalten durch die Option netbios aliases =
VIRTUAL01 VIRTUAL02 VIRTUAL03.
Ein solcher Eintrag steht in der smb.conf in der Sektion [global]. Die Anzahl der Aliases (hier drei) schreibt Samba nicht vor. Kommt die Option ”netbios aliases” zum Einsatz, muss auch der ”netbios name” eingestellt sein. Das ist jetzt noch nicht besonders
spannend: Schaut man sich nun in der Netzwerkumgebung auf dem Client die Freigaben von VIRTUAL01, so unterscheiden diese sich nicht von den anderen. Will man einem
virtuellen Server nun eine angepasste Einstellung verpassen, braucht man eine separate
smb.conf für diesen. Der Name der Datei lautet am besten auf smb.conf + Servername =
smb.conf.virtual01. Hierin können nun wieder beliebige Freigaben eingestellt werden. Damit
Samba weitere Konfigurationsdateien beim Start berücksichtigt, fügt man ein include Statement ein: include = /etc/samba/smb.conf.%L". %L setzt den Servernamen ein, der beim
NetBIOS-Verbindungsaufbau angeforder wurde. Beim Aufsetzen der verschiedenen Dateien
ist zu beachten, dass alle Freigaben der Hauptdatei auch für alle virtuellen Server gelten.
12.5
Controller-Funktionalität
Die bisher vorgestellten Beispiele demonstrierten nur einen Teil der Sambafähigkeiten. Solche Konfigurationen sind eher in sehr kleinen und kleinen Netzwerken mit wenigen Rechnern und Nutzern sinnvoll. In vielen Fällen kann es für Administratoren attraktiv sein, den
Samba-Server auch zur Namensauflösung als WINS-Server oder als Ersatz eines Primary
Domain Controllers zu verwenden. Dann möchte er jedoch häufig auch Ziele, wie SingleSign-On verwirklichen. Hierzu läßt sich Samba mit dem Directory-Dienst LDAP verbinden.
Die notwendigen Konfigurationen sind dann jedoch deutlich komplexer.
12.5.1
Der Windows Namensdienst
Viele werden sich fragen, wozu ein weiterer Namensdienst, wo es doch schon das Domain
Name System (DNS) gibt. DNS ist fest mit TCP/IP verknüpft - SMB jedoch nicht, auch
wenn es heute kaum noch jemand anders als zusammen mit diesem einsetzt. Viele kennen
das Problem: Den Namen einer Person können sich viele noch merken, mit den dazugehörigen Telefonnummern wird es schwieriger. Dann zieht diese Person um und die Nummer
ändert sich. Hier möchte man ein Telefonbuch haben, welches Namen Nummern zuordnen
kann. Diese Aufgabe übernimmt der Windows Internet Name Service. Dieser unterscheidet
sich signifikant vom klassischen DNS. So könnte man ja mal versuchen einer WindowsMaschine per DHCP einen Hostnamen zuzuweisen, was unter Linux/Unix kein Problem
darstellt. Auch habt man sicherlich schnell festgestellt, dass Microsoft unter dem Konzept
ein Windows-Domäne etwas ganz anderes sieht als ein Domain-Name, wie in Web-Adressen.
Der NetBIOS-Name-Service wird in den RFCs 1001 und 1002 beschrieben. Er bietet Clients eine vergleichbare Art von Dienst wie DNS. Es bestehen jedoch einige wesentliche Hauptunterschiede. NetBIOS-Namen existieren in einem flachen Namensbereich.
188
KAPITEL 12. SAMBA
Das ist beim DNS völlig anders. Keiner hindert einen daran, einen Rechner in der Subdomain pool01.lehrpools.rechenzentrum.uni-freiburg.de mit dem Namen dozenten-rechnervorne-links zu betreiben. Die Namenskomponenten zwischen den Punkten dürfen 63 und
der Gesamtname nicht 255 Zeichen überschreiten. Damit lassen sich einige Hierarchiestufen
erreichen.
Unter WindowsXP gibt es zwei Möglichkeiten einen WINS-Server einzutragen. Zum
einen kann der Admin des Netzes diese Information mittels DHCP an alle Clients verteilten: Abfragen lässt sich diese Information beispielsweise mit ipconfig -all in der ”Eingabeaufforderung”. Alternativ kann man die IP für WINS auch fest bei der Alternativen
Konfiguration von TCP/IP eintragen.
Abbildung 12.3: Zwei Wege der Zuweisung der WINS-Server-Adresse
12.5.2
NetBIOS Namen
NetBIOS-Namen bestehen aus 16 alphanumerischen Zeichen, wobei a bis z, A bis Z und
ˆ
0 bis 9 erlaubt sind. Zusätzlich dürfen die Sonderzeichen !@#$%&()-’{}.
vorkommen.
Die ersten 15 Zeichen dienen der Benennung, das sechzehnte Zeichen ist eine Zahl von
0x00 bis 0xFF hexadezimal, die den Ressourcentyp des Namens bestimmt. Es gibt zwei
Namenstypen: Entweder sie sind exklusiv einem Benutzer oder einer Maschine zugeordnet
oder sie sind Gruppennamen. Letztere können gemeinsam benutzt werden. Der NetBIOS-
12.5. CONTROLLER-FUNKTIONALITÄT
ID
< 00 >
< 03 >
< 06 >
< 1B >
< 1F >
< 20 >
< 21 >
< BE >
< BF >
189
Bedeutung
NetBIOS Name eines Rechners (Freigabename einer Workstation)
Messenger Service Name - verwendet zum Empfangen und Übertragen
von Nachrichten, sowohl für User- als auch Rechnernamen
Routing und Remote Access Service (RAS) - Name des Servers
Domain Masterbrowser Name - wird von Maschinen im Netz genutzt,
um den Primary Domain Controller (PDC) einer Windows-Domain zu
kontaktieren
Network Dynamic Data Exchange (NetDDE) Dienst
Server-Dienstname - Zugriffspunkte für freigegebene Dateien und Verzeichnisse
RAS-Client
Network Monitor Agent
Network Monitor Utility
Tabelle 12.1: Eindeutige Namen
Name MYSMB< 00 > aus dem Beispiel des vorangegangenen Abschnitts ist ein eindeutiger
Name. Er beschreibt den Computer ”MYSMB”. Die Bezeichnung SAMBA-TESTNETZ<
1e > hingegen ist ein Gruppenname. Ihn benutzen Browsing-Clients, um einen MasterBrowser unter sich zu bestimmen.
NetBIOS-Namen spannen nur einen flachen Namensbereich auf. Trotzdem sind in einm
gleichen logischen Subnetz mehrere Namensbereiche erlaubt. Diese werden durch den
NetBIOS-Scope unterschieden. Der NetBIOS-Scope ist ein String, der zusammen mit dem
NetBIOS-Namen 256 Zeichen nicht überschreiten darf.
ID
< 1D >
< 1E >
Bedeutung
Masterbrowser-Name - wird vom Client benutzt, um auf den Masterbrowser zuzugreifen (je nach Netz lokaler Masterbrowser)
Gruppenname - kommt bei der Wahl von Browse-Mastern zum Einsatz
Tabelle 12.2: Gruppenressourcen
Die Namensvergabe im NetBIOS geht anders als bei DNS vom Client aus: Eine Maschine versucht beim Start einen Namen zu registrieren. Dieses ist erfolgreich, wenn der
Client-Rechner ein erfolgreiches Namensangebot gemacht und vom Server den Namen für
sich erhalten hat. Versucht eine Maschine A einen im Scope schon vergebenen Namen zu
registrieren, antwortet der Besitzer mit dem Hinweis, dass er den Namen behält. Dieses
Verfahren ist eine Methode inaktive Hosts zu entdecken, die den Besitz eines Namens nicht
offiziell aufgegeben haben.
ID
< 00 >
< 1C >
< 1E >
< 20 >
Bedeutung
Zum Empfang von Browser-Broadcasts
Arbeitsgruppenname - wird vom Domain Controller registriert und
enthält eine Liste von Computern, die sich unter dieser Gruppe registriert haben Internet Gruppe
Gleiche Bedeutung, wie bei Gruppenressourcen
Identifikation eine Gruppe von Rechnern für administrative Zwecke
Tabelle 12.3: Domänennamen
190
KAPITEL 12. SAMBA
NetBIOS kennt zwei Methoden für die Registrierung und Auflösung von Namen: Broadcast und Point-to-Point. Die Point-to-Point-Registrierung und -Auflösung geschieht mittels
eines eigenen Dienstes - NetBIOS-Nameserver (NBNS).
Broadcast-Registrierung oder -Auflösung heißt, dass die Anfrage an alle Hosts im gleichen logischen Subnetz mit dem gleichen Scope gesendet wird. Router können diese Broadcasts weitergeben. Das ist in der Regel in größeren Netzen mit vielen Windwosmaschinen
nicht sehr clever, da sehr viel Datenverkehr generiert wird. Diese Methode kam implizit in
den Konfigurationsbeispielen der vorangegangenen Abschnitte zum Einsatz.
12.5.3
Der Nameserver (WINS)
Ein WINS macht nicht nur zur Reduzierung der Menge des Broadcast-Datenverkehrs Sinn,
die durch eine große Anzahl von NetBIOS-Clients erzeugt werden kann. Ein weiteres Problem in NetBIOS-Netzen ist die übliche Beschränkung der Broadcasts auf ein logisches
Subnetz. Das führt dazu, dass Rechner in verschiedenen Subnetzen nicht über die Namen
miteinander kommunizieren können. WINS löst beide Probleme. Die Aufgabe eines WINS
übernimmt im Samba-Paket der nmbd.
Die Aktivierung erfolgt durch die Option wins support = Yes. Ist bereits ein solcher
Dienst im Subnetz vorhanden, steht in ”wins server” die IP des entsprechenden Rechners.
”wins support” sollte dann auf ”No” gesetzt sein. Da die Namensvergabe durch die Clients initiiert wird, sind keine wesentlichen Einstellungen neben ”workgroup” und eventuell
”netbios name” in der smb.conf notwendig.
Samba erlaubt es DNS und WINS miteinander zu verknüpfen. Wenn Samba als WINSServer (wins support = Yes) agiert, kann der nmbd alle Namensanfragen im DNS versuchen zu finden, wenn er keinen entsprechenden Eintrag in der lokalen WINS-Datenbank
gefunden hat. Der Parameter ”dns proxy” bestimmt dieses Verhalten. Samba befragt standardmäßig den DNS, wenn ein Name nicht in WINS gefunden wird. Dieses Verhalten entspricht: dns proxy = Yes. Gibt es kein DNS im eigenen Netzwerk, macht Sambas ”dns
proxy” nicht viel Sinn. Mittels dns proxy = No läßt er sich deaktivieren.
Eine Methode zur Namensauflösung in sehr kleinen Netzwerken ist der Weg über eine Textdatei. Das Konzept der lmhosts Datei kennt der Admin vielleicht schon WindowsRechnern. Sie kann auch von Samba verwendet werden und entspricht funktionell der von Linux bekannten Datei /etc/hosts. Der einzige Unterschied: Sie ordnet IP-Adressen NetBIOSNamen zu anstelle von Hostnamen. Samba schaut in der lmhosts nur für eigene Fragen nach,
nicht für die Anfragen von anderen Maschinen im Netzwerk. Der Parameter ”name resolve order” bestimmt dieses Verhalten. Wenn also die Reihenfolge name resolve order =
lmhosts wins eingestellt ist, würde Samba selbst keine Namensanfragen per Broadcast aussenden und nicht versuchen, Namen über den DNS aufzulösen. Es würde nur in der lokalen
lmhosts Datei nachschauen und bei Misserfolg den konfigurierten WINS-Server befragen.
Eine NetBIOS-Namensanfrage macht nmblookup -R -U localhost MYSMB. Die Optionen
sorgen dafür, dass ein WINS-Server befragt wird, anstatt lediglich ein Broadcast in das
lokale Subnetz zu machen.
Sambas lmhosts Datei und eine, die von Windows-Clients verwendet wird, unterscheiden
sich im Format etwas. Es kann Sinn machen hier den PDC einzutragen, da manchmal sonst
eine Verbindung auf diesen über Router hinweg fehlschlägt. Unter WindowsXP liegt diese
Datei in /WINDOWS/system32/drivers/etc. Üblicherweise sieht ein Eintrag so aus:
10.8.4.254 MYSMB #PRE #DOM:SAMBA
Für einfache Hosts reicht die Kombination aus IP-Nummer und NetBIOS-Name.
12.6. SAMBA ALS PDC
12.6
191
Samba als PDC
Zur großen Form läuft Samba auf, wenn es nicht nur einfache Freigaben bereitstellt und
Namen auflöst. Windowsnetze erlauben seit Windows-NT eine zentralisierte Steuerung. So
können beispielsweise Benutzer zentral an einer Maschine authentifiziert werden, ohne dass
sie auf dem lokalen Endgerät eingetragen sind. Hierzu führte Microsoft das Konzept der
Domäne ein. Eine Domäne definiert eine Gruppe von Rechnern, die eine gemeinsame Benutzerdatenbank verwenden. Diese Benutzerdatenbank stellen sogenannte Primary (PDC)
und Backup Domain Controller (BDC) zur Verfügung. Für jedes Domänenmitglied - dieses
können Benutzer und Rechner sein - wird ein zentrales Konto angelegt. Für jedes Domänenmitglied muss ein Benutzerkonto, auch Computerkonto genannt, auf dem PDC existieren.
Samba kann die Rolle des PDC, bisher jedoch noch nicht die eines BDC übernehmen.
Hierzu stellt der Admin in der globalen Sektion der smb.conf zuerst folgende Optionen ein:
workgroup = SAMBA
netbios name = MYSMB
os level = 64
domain master = Yes
domain logons = Yes
preferred master = Yes
wins support = Yes
wins proxy = Yes
Einige Optionen sollten aus dem bisher gesagten bekannt sein. Der hohe OS-Level sorgt
dafür, dass die Maschine die Wahl der Browser gewinnt. Nun sollte der Samba-Server neu
gestartet werden: rcsmb restart; rcnmb restart.
Die Sache mit Win9x-Clients ist einfach: Man kann den Samba-PDC sofort ohne weitere Konfiguration als Anmeldeserver verwenden. Beim Einsatz der professionellen Windowsvarianten NT, 2000 oder XP sind noch einige Nacharbeiten notwendig. Es müssen
erst Computer-Konten existieren (Im Beispiel die Maschine zxs) und ein Benutzer ”root”
in die Samba-Passwort-Datenbank aufgenommen sein, bevor die Aufnahme einer solchen
Maschine gelingt.
useradd -d /var/tmp -s /bin/false zxs\$
smbpasswd -a -m zxs\$
smbpasswd -a root
Nun sind auf der Windows-Maschine einige Schritte dran: Zuerst legt man einen Key in
der Windows-Registry an. Das geschieht beispielsweise mittels Datei, die in die Registry
geladen wird:
Windows Registry Editor Version 5.00
[HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
"requiresignorseal"=dword:00000000
Anschliessend startet man die Systemsteuerung und wählt dort den Unterpunkt ”System”.
In den nun angezeigten Systemeigenschaften geht es zur Karteikarte mit den Computernamen. Hierin erlaubt der Knopf ”Ändern” die Aufnahme der Maschine in eine WindowsDomäne. Im nun erscheinenden Dialog legt man den NetBIOS-Namen der Maschine fest
und tritt der Domäne bei. Dafür muss der Radio-Button ”Mitglied von Dommäne” aktiviert und der Name der beizutretenden Domäne daneben eingetragen werden. Nach dem
192
KAPITEL 12. SAMBA
Abbildung 12.4: WindowsXP-Maschine in eine Domäne aufnehmen
Bestätigen durch ”OK” erscheint ein Anmeldedialog für den Domain-Administrator. Das
ist der Benutzer ”root”, dem mittels smbpasswd ein Sambapasswort verpasst wurde.
Wenn nun alles glatt ging, erscheint eine kurze Willkommensmeldung, die den Domänenbeitritt bestätigt (Siehe Abb. 12.6). Anschliessend muss der Client neu starten. Nach erfolgtem Start kommt nun der klassischen Anmelde-Dialog. Unter ”Optionen” können Benutzer
jetzt auswählen, ob sie sich lokal an der Maschine oder durch Authentifizierung gegen die
Domain ”SAMBA” anmelden wollen. Nun können sich alle Benutzer anmelden, die Samba bekannt sind. Wenn die Beispiele aus den vorangegangenen Abschnitten beibehalten
wurden, sind das die Benutzer ”test1” und ”test2”.
12.6.1
Benutzerprofile und Logon-Skripten
Beim ersten Test-Login sehen die Benutzerprofile der beiden ”test1” und ”test2” noch
sehr nackt aus. Es erscheint lediglich die Windows-Voreinstellung des Desktops. Damit ein
Benutzer an verschiedenen Workstations stets das gleiche Profil vorfindet, läßt sich das
Profil serverbasiert speichern. Es wird dann wärend des Anmeldevorganges auf die ClientMaschine kopiert, vor der der Benutzer sitzt. Dieses kann nicht einfach umgangen werden,
da viele Anwendungsprogramme ein lokales Profil verlangen, das nicht einfach, wie von
Linux gewohnt, im Homeverzeichnis liegt.
Da sich die Einstellungen im Laufe einer Sitzung ändern können, müssen sie auch wieder
zurückgesichert werden. Das geschieht beim Abmelden von der Arbeitsstation.
Will der Administrator ganz neue Benutzer hinzufügen, muss er diese erst als LinuxAccounts anlegen und anschliessend mit smbpasswd -a UserID in die Samba-Benutzerdatenbank kopieren. Nun müssen noch einige Eintragungen in der smb.conf vorgenommen
werden. Mit dem Eintrag
12.6. SAMBA ALS PDC
193
Abbildung 12.5: Domänen-Aufnahme - Passwortdialog
logon path = \\%N \%U\profile (für NT/2000/XP)
; alternativ:
logon home = \\%N \%U\profile (für Windows 9x)
in der [global]-Section der smb.conf wird im Heimatverzeichnis des Benutzers ein Verzeichnis namens profile erstellt und das Profil dort gespeichert. Der Service erhält eine
eigene Sektion in der Konfigurationsdatei:
[profiles]
comment = Network Profiles Service
path = %H
read only = No
store dos attributes = Yes
create mask = 0600
directory mask = 0700
Zur Aktivierung dieses Features ist ein Neustart des Servers erforderlich. Damit bei der
Benutzeranmeldung noch Anpassungen seiner Umgebung vorgenommen werden können,
kann ein Logon-Skript ausgeführt werden. Dieses definiert der Admin mittels logon script
= scripts/default.bat
Dieses Skript wird unter Windows ausgeführt, sollte also die richtigen Zeilenschaltungen besitzen. Entweder der Admin editiert es unter Windows selbst und kopiert es in das
Netlogon-Verzeichnis. Oder man konvertiert die Datei entsprechend. Auch dieser Dienst
besitzt einen eigenen Abschnitt:
[netlogon]
comment = Network Logon Service
path = /hom/netlogon
write list = @ntadmin
force group = ntadmin
194
KAPITEL 12. SAMBA
Abbildung 12.6: Begrüßung in der neuen Domäne
create mask = 0664
directory mask = 0775
browsable = No
Ein Beispielskript für NT findet sich je nach eingesetzter Linux-Distribution im SambaDoku-Paket unter: .../doc/.../samba/examples/ntlogon/ntlogon.conf.
12.7
Samba und LDAP
Was in kleinen Netzen noch per Hand zu managen ist, will der Admin in großen Netzen
professioneller regeln. Das Anlegen von Benutzern nach dem soeben beschriebenen Verfahren ist für große Netze mit vielen Linux- und Windows-Rechnern, an denen sich ein Nutzer
anmelden kann, zu umständlich. Hier hilft eine hierarchische Datenbank weiter, die sich für
solche Zwecke geradezu anbietet. LDAP - das Lightwight Directory Access Protocol (vgl.
Kap. 13.3) ist ein verabschiedeter Internet-Standard. Microsoft verwendet dieses als Grundlage für seine Active Directory Service. OpenLDAP ist eine OpenSource-Implementierung,
die standardmäßig bei Ihrer Linuxdistribution dabei sein sollte. LDAP arbeitet im ClientServer-Modell über TCP/IP. Samba kann als LDAP-Client agieren und alle Informationen,
die es für seinen Betrieb braucht aus dem Directory beziehen und veränderte Daten wieder zurückschreiben. Diese Daten landen sonst in den *.tdb, die sich unter /etc/samba und
/var/lib/samba finden.
Sollte noch kein LDAP-Server auf der Samba-Maschine installiert sein, sollte man diesen
Schritt nun nachholen. Neben den Basispaketen für den Server und die Client-Programme
benötigt die Installation zusätzlich ”pam ldap”, ”nss ldap” und ”ldapsmb”, wenn auch die
Verwaltung der Linux-Benutzer mittels LDAP erfolgen soll.
12.7. SAMBA UND LDAP
12.7.1
195
Konfiguration des LDAP-Servers
Es gibt ein eigenes Kapitel dieses Skriptes 1 . Im nächsten Schritt erweitert man die Liste
der standardmäßig benutzten Schemas um eines für Samba3. Dieses installiert SuSE bereits
automatisch in das richtige Verzeichnis. Kümmert sich Ihre Distribution nicht darum, findet
man sicherlich das Schema als Beispiel in der Dokumentation des Samba-Paketes.
Minimalkonfiguration der /etc/openldap/slapd.conf
inlcude
[ ... ]
suffix
rootdn
rootpw
/etc/openldap/schema/samba3.schema
"dc=my-domain,dc=site"
"cn=Manager,dc=my-domain,dc=site"
GeheiM
Zusätzlich passen Sie die Benennung Ihrer LDAP-Wurzel an (suffix), definieren entsprechend den Datenbank-Manager (rootdn) und setzen für diesen ein Passwort (rootpw). Einige dieser Einstellungen finden Sie auch in der neuen smb.conf wieder (ldap *).
12.7.2
Die neue Samba-Konfiguration
Für den Schritt hin zu einem LDAP-Backend sichern Sie am besten Ihre bisherige Konfiguration und starten mit einer neuen. Eine sehr gute Hilfe und Bauanleitung liefert auch der
Samba-Guide, der als PDF und HTML in der Samba-Dokumentation mitgeliefert wird.
[global]
unix charset = LOCALE
workgroup = SMB-LDAP
netbios name = MYSMBLDAP
passdb backend = ldapsam:ldap://132.230.4.178/
#
username map = /etc/samba/smbusers
log level = 1
smb ports = 139 445
domain logons = Yes
preferred master = Yes
wins support = Yes
name resolve order = wins bcast hosts
time server = Yes
ldap suffix = dc=my-domain,dc=site
ldap machine suffix = ou=user
ldap user suffix = ou=user
ldap group suffix = ou=group
ldap idmap suffix = ou=idmap
ldap admin dn = cn=Manager,dc=my-domain,dc=site
idmap backend = ldap:ldap://10.8.4.254/
idmap uid = 10000-20000
idmap gid = 10000-20000
map acl inherit = Yes
add user script = /var/lib/samba/sbin/smbldap-useradd.pl -a -m ’%u’
delete user script = /var/lib/samba/sbin/smbldap-userdel.pl %u
add group script = /var/lib/samba/sbin/smbldap-groupadd.pl -p ’%g’
delete group script = /var/lib/samba/sbin/smbldap-groupdel.pl ’%g’
add user to group script = /var/lib/samba/sbin/smbldap-groupmod.pl -m ’
delete user from group script = /var/lib/samba/sbin/smbldap-groupmod.pl
1
zumindest in den meisten Kompilationen. (vgl. Kap. 13.3) Sonst gibt es das evtl. extra oder über
http://goe.net per CVS zu beziehen.
196
KAPITEL 12. SAMBA
set primary group script = /var/lib/samba/sbin/smbldap-usermod.pl -g ’%
add machine script = /var/lib/samba/sbin/smbldap-useradd.pl -w ’%u’
logon script = scripts\logon.bat
logon path = \\%L\profiles\%U
logon drive = H:
printcap name = CUPS
printing = cups
printer admin = Administrator
[homes]
comment = Home Directories
valid users = %S
read only = No
inherit permissions = Yes
browseable = No
[profiles]
comment = Network Profiles Service
path = %H
read only = No
create mask = 0600
directory mask = 0700
store dos attributes = Yes
[users]
comment = All users
path = /home
read only = No
inherit permissions = Yes
[groups]
comment = All groups
path = /home/groups
read only = No
inherit permissions = Yes
Vor dem Neustart des Samba-Servers mit der umgebauten Konfiguration entfernt der Admin am besten noch die alten *.tdb und *.dat Dateien aus den beiden oben angebenen
Verzeichnissen. Da der Samba-Server mit dem LDAP-Server kommuniziert und Einträge
anlegt, benötigt Samba das Manager-Passwort:
linux2:/etc/samba # smbpasswd -w GeheiM
Setting stored password for "cn=Manager,dc=my-domain,dc=site" in
secrets.tdb
Dann wird es Zeit die Server mit:
rcsmb (re)start; rcnmb (re)start; rcldap (re)start; - oder passend zur jeweiligen Distribution - neu zu starten. Am besten wirft man einen kurzen Blick ins Logfile /var/log/samba/log.smbd, ob keine Fehler aufgetreten sind. Der Befehl smbclient -L
localhost -U% sollte nun eine Serverstatusmeldung generieren. Mit dem Kommando
linux2:/etc/samba # net getlocalsid
[2004/11/22 19:51:17, 0] lib/smbldap.c:smbldap_search_suffix(1101)
smbldap_search_suffix: Problem during LDAP search: (No such object)
SID for domain MYSMBLDAP is: S-1-5-21-2420552454-2742262544-3303448865
linux2:/etc/samba # ls -la secrets.tdb
-rw------- 1 root root 8192 Nov 22 19:45 secrets.tdb
erzeugt man einen eindeutigen Idenfier für die Maschine. Anschliessend gibts auch wieder
eine secrets.tdb.
12.7. SAMBA UND LDAP
12.7.3
197
Die IDEALX-Skripten
Nun braucht mal die idealx.com Samba-LDAP-Skripten. Die muss sich der Admin meistens nicht irgendwoher organisieren. Sie sollten Bestandteil des Samba-Doc-Paketes sein.
Die Autoren des Samba-Guide schlagen vor die Skripten und ein zu kompilierendes mkntpwd in ein Unterverzeichnis /var/lib/samba/sbin zu verschieben. Auf einem SuSE-Linux
ist mkntpwd bereits unter /usr/sbin installiert. Der Compile-Schritt kann entfallen. Also
führt man in
linux2:/usr/share/doc/packages/samba/examples/LDAP/smbldap-tools #
cd mkntpwd
make
cd ..
mkdir /var/lib/samba/sbin
cp *.pl *.pm mkntpwd/mkntpwd /var/lib/samba/sbin
chmod 755 /var/lib/samba/sbin/smb*.pl
chmod 644 /var/lib/samba/sbin/smb*.pm
aus. Nun steht eine kleine Konfigurationsorgie der Datei smbldap conf.pm an. Diese im
Lieblingseditor öffnen und los gehts:
[ ... ]
# Put your own SID
# to obtain this number do: "net getlocalsid"
$SID=’S-1-5-21-2420552454-2742262544-3303448865’;
[ ... ]
# LDAP Suffix
# Ex: $suffix = "dc=IDEALX,dc=ORG";
$suffix = "dc=my-domain,dc=site";
[ ... ]
# Where are stored Users
# Ex: $usersdn = "ou=Users,$suffix"; for ou=Users,dc=IDEALX,dc=ORG
$usersou = q(user);
$usersdn = "ou=$usersou,$suffix";
# Where are stored Computers
# Ex: $computersdn = "ou=Computers,$suffix";
#
for ou=Computers,dc=IDEALX,dc=ORG
$computersou = q(user);
$computersdn = "ou=$computersou,$suffix";
# Where are stored Groups
# Ex $groupsdn = "ou=Groups,$suffix"; for ou=Groups,dc=IDEALX,dc=ORG
$groupsou = q(group);
$groupsdn = "ou=$groupsou,$suffix";
[ ... ]
# Bind DN used
# Ex: $binddn = "cn=Manager,$suffix"; for cn=Manager,dc=IDEALX,dc=org
$binddn = "cn=Manager,$suffix";
# Bind DN passwd used
# Ex: $bindpasswd = ’secret’; for ’secret’
$bindpasswd = "GeheiM";
[ ... ]
# Login defs
# Default Login Shell
# Ex: $_userLoginShell = q(/bin/bash);
$_userLoginShell = q(/bin/bash);
# Home directory prefix (without username)
# Ex: $_userHomePrefix = q(/home/);
198
KAPITEL 12. SAMBA
$_userHomePrefix = q(/home/);
[ ... ]
$_userSmbHome = q(\\\\MYSMBLDAP\\homes);
[ ... ]
$_userProfile = q(\\\\MYSMBLDAP\\profiles\\);
[ ... ]
$_userHomeDrive = q(H:);
[ ... ]
# Allows not to use smbpasswd (if $with_smbpasswd == 0 in
# smbldap_conf.pm) but prefer mkntpwd... most of the time, it’s
# a wise choice :-)
$with_smbpasswd = 0;
$smbpasswd = "/usr/bin/smbpasswd";
$mk_ntpasswd = "/usr/sbin/mkntpwd";
Die Einträge für $usersou und $groupsou müssen natürlich mit den Definitionen in der
smb.conf übereinstimmen. Man ist jedoch nicht auf ”user” und ”group” festgelegt und
können geändert werden. Ähnliches gilt für den NetBIOS-Namen des Samba-Servers und
den Buchstaben für das Home-Laufwerk.
Für die meisten der derzeit aktuelle Samba-Versionen und Idealx-Skripten müssen Computer und Benutzer unterhalb eines gemeinsamen LDAP-Knotens angelegt sein. In diesem
Beispiel wurden die Computer in ”user” aufgenommen. Bei unterschiedlich gewählten Ablagen schlägt ein Domänenbeitritt fehl, da eine Maschine zwar sauber in den LDAP eingetragen, danach aber nicht wiedergefunden wird. Dieses Problem scheint mit den neuesten
Samba-Versionen und Idealx-Skripten2 behoben. Ebenfalls entfallen die Ergänzungen der
Objektklassen. Dafür muss dann jedoch die LDAP Schema-Datei von Idealx und nicht die
von Samba eingesetzt werden, da sonst einige Objekte nicht korrekt initialisiert werden.
Am Ende der Datei muss der Pfad zu mkntpwd stimmen. Befinden sich LDAP- und
Samba-Server nicht auf einer Maschine sind für den Netzwerkzugriff des Samba auf LDAP
natürlich noch IP und Port oben in der Datei anzugleichen. Generell fügt das Skript umfangreichere Informationen ein, als für ein reines Samba-Backend benötigt würden. Zusätzlich
sind auch alle Informationen für Unix-Benutzer enthalten.
Leider sind die Skripten je nach eingesetzter Linux-Distribution nicht ganz passend zu
einigen neueren LDAP-Versionen, so dass bei smbldap-populate.pl folgende oder ähnliche
Fehlermeldung mehrfach auftreten kann:
failed to add entry: no structural object class provided at
./smbldap-populate2.pl line 323, <GEN1> line 8.
Diese läßt sich in den Griff bekommen durch das Einfügen zweier struktureller LDAPObjektklassen in die Datei smbldap-populate.pl Zeilen 323 und folgende:
dn: cn=Domain Admins,$groupsdn
objectClass: posixGroup
+objectClass: top
+objectClass: namedObject
objectClass: sambaGroupMapping
gidNumber: 512
cn: Domain Admins
Das Ergebnis sieht dann so aus:
linux2:/var/lib/samba/sbin # ./smbldap-populate.pl
Using builtin directory structure
2
www.idealx.org - Version 0.8.5, die 0.8.4 funktioniert nicht korrekt
12.7. SAMBA UND LDAP
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
adding
new
new
new
new
new
new
new
new
new
new
new
new
new
new
new
new
new
new
new
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
entry:
199
dc=my-domain,dc=site
ou=user,dc=my-domain,dc=site
ou=group,dc=my-domain,dc=site
ou=computer,dc=my-domain,dc=site
uid=Administrator,ou=user,dc=my-domain,dc=site
uid=nobody,ou=user,dc=my-domain,dc=site
cn=Domain Admins,ou=group,dc=my-domain,dc=site
cn=Domain Users,ou=group,dc=my-domain,dc=site
cn=Domain Guests,ou=group,dc=my-domain,dc=site
cn=Administrators,ou=group,dc=my-domain,dc=site
cn=Users,ou=group,dc=my-domain,dc=site
cn=Guests,ou=group,dc=my-domain,dc=site
cn=Power Users,ou=group,dc=my-domain,dc=site
cn=Account Operators,ou=group,dc=my-domain,dc=site
cn=Server Operators,ou=group,dc=my-domain,dc=site
cn=Print Operators,ou=group,dc=my-domain,dc=site
cn=Backup Operators,ou=group,dc=my-domain,dc=site
cn=Replicator,ou=group,dc=my-domain,dc=site
cn=Domain Computers,ou=group,dc=my-domain,dc=site
Nach erfolgreichem Durlauf von smbldap-populate.pl muss der LDAP-Server neu gestartet werden: rcldap restart. Als nächstes benötigt der LDAP-Server ein Container-Objekt
für IDMAP-Informationen. Dieser ist überlicherweise nicht vorhanden und muss per Hand
erzeugt werden. Dazu legen Sie eine Datei idmap.ldif mit folgendem Inhalt an:
dn: ou=Idmap,dc=my-domain,dc=site
objectClass: top
objectClass: organizationalUnit
ou: Idmap
Diese Datei liegt im sogenannten LDIF vor - ein Austauschformat zwischen LDAP-Datenbanken. Mit dem Kommando
ldapadd -x -D "cn=Manager,dc=my-domain,dc=site"-w GeheiM -f idmap.ldif
fügt man den Eintrag der LDAP-Datenbasis hinzu. Zur Kontrolle ob der LDAP-Server
korrekt läuft und auf Requests antwortet, kann das Kommandozeilentool ldapsearch verwendet werden. Es funktioniert analog zu ldapadd zum Auslesen der Datenbank.
linux2:/var/lib/samba/sbin # ldapsearch -x -b "dc=my-domain,dc=site"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=site> with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# my-domain.site
dn: dc=my-domain,dc=site
objectClass: dcObject
objectClass: organization
dc: my-domain
o: my-domain
[ ... ]
# Idmap, my-domain.site
200
KAPITEL 12. SAMBA
dn: ou=Idmap,dc=my-domain,dc=site
objectClass: top
objectClass: organizationalUnit
ou: Idmap
# search result
search: 2
result: 0 Success
# numResponses: 21
# numEntries: 20
Es sollte eine ziemlich lange Liste liefern. Dann wird es Zeit sich um den Name Service
Switch zu kümmern, so dass dieser auch LDAP-Benutzer auflösen kann. Andernfalls kann
Ihr System Samba-Usern keine System-User zuordnen.
/etc/nsswitch.conf
passwd: compat
group: compat
passwd_compat: ldap
group_compat:
ldap
[ ... ]
# oder alternativ
passwd: files ldap
group: files ldap
Die Einstellungen in dieser Datei als auch die LDAP-Client-Konfiguration kann ebenfalls
mit YaST2 vorgenommen werden (Abb. yast2-ldap-client Erreichbar in YaST2 über Netzwerkdienste LDAP-Client).
# /etc/ldap.conf
host
127.0.0.1
base
ou=user,dc=my-domain,dc=site
ldap_version
3
ssl
no
nss_map_attribute
uniqueMember member
pam_filter
objectclass=posixAccount
nss_base_passwd ou=user,dc=my-domain,dc=site
nss_base_shadow ou=user,dc=my-domain,dc=site
nss_base_group ou=group,dc=my-domain,dc=site
Wenn alles geklappt hat, liefert getent nun auch die Samba-Accounts und Gruppen:
linux2:/var/lib/samba/sbin # getent passwd
[ ... ]
Administrator:x:998:512:Netbios Domain Administrator:/home:/bin/false
nobody:x:999:514:nobody:/dev/null:/bin/false
linux2:/var/lib/samba/sbin # getent group
[ ... ]
Domain Admins:x:512:Administrator
Domain Users:x:513:
Domain Guests:x:514:
12.7. SAMBA UND LDAP
201
Administrators:x:544:
[ ... ]
Nun wäre es nur noch ein kleiner Schritt auch den Zugriff auf die Linuxmaschine mittels
PAM-LDAP einzurichten. Dieses würde aber den Rahmen des hier Beschriebenen sprengen.
Auf diesem Wege können Administratoren jedoch ein ”single-password” realisieren. Bisher
waren nur Systembenutzer automatisch angelegt worden. Mit den entsprechenden Tools
können nun weitere hingezufügt werden:
linux2:/var/lib/samba/sbin #
linux2:/var/lib/samba/sbin #
Changing password for test1
New password :
Retype new password :
linux2:/var/lib/samba/sbin #
linux2:/var/lib/samba/sbin #
Changing password for test1
New password :
Retype new password :
./smbldap-useradd.pl -m -a test1
./smbldap-passwd.pl test1
./smbldap-usermod.pl -u 0 Administrator
./smbldap-passwd.pl Administrator
Der Administrator hat vorerst noch eine UID ungleich null. Das ändert man mit smbldapusermod.pl wie im Beispiel gezeigt. Für ihn brauchen Sie auch noch ein Passwort für den
späteren Domänenbeitritt. Mittels - der im smb.conf Beispiel auskommentierten - ”username
map” kann der Administrator auch auf den Unix-Admin ”root” abgebildet werden. Diese
Nutzer stehen sofort auch unter Linux zur Verfügung, wie getent passwd oder id test13
zeigen. Dass der User auch für die Windowswelt sichtbar wird, zeigt:
linux2:/var/lib/samba/sbin # pdbedit -Lv test1
Searching for:[(&(objectClass=sambaDomain)(sambaDomainName=SMB-LDAP))]
smbldap_open_connection: connection opened
Searching for:[(&(objectClass=sambaDomain)(sambaDomainName=SMB-LDAP))]
smbldap_open_connection: connection opened
init_sam_from_ldap: Entry found for user: test1
Unix username:
test1
NT username:
test1
Account Flags:
[U
]
User SID:
S-1-5-21-3516781642-1962875130-3438800523-3000
Primary Group SID:
S-1-5-21-3516781642-1962875130-3438800523-513
Full Name:
System User
Home Directory:
\\MYSMBLDAP\homes
HomeDir Drive:
H:
Logon Script:
test1.cmd
Profile Path:
\\MYSMBLDAP\profiles\test1
Domain:
SMB-LDAP
Account desc:
System User
Workstations:
Munged dial:
Logon time:
0
Logoff time:
Fri, 13 Dec 1901 21:45:51 GMT
Kickoff time:
Fri, 13 Dec 1901 21:45:51 GMT
3
siehe hierzu auch den Teil zur Benutzerverwaltung mit LDAP
202
KAPITEL 12. SAMBA
Password last set:
Password can change:
Password must change:
Last bad password
:
Bad password count :
Logon hours
:
Tue, 23 Nov 2004 01:49:59 GMT
0
Fri, 07 Jan 2005 01:49:59 GMT
0
0
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Nun könnte der Admin noch eine Gruppe ”testgroup” wie im einführenden Beispiel des
letzten Abschnitts anlegen: smbldap-groupadd.pl -a testgroup. Hatte man schon das
Problem, dass smbldap-polulate.pl gepatcht werden musste, bleibt es einem für smbldap tools.pm nicht erspart: Ab Zeile 283 müssen zwei Zuweisungen hinzugefügt werden:
objectClass => ’top’,
objectClass => ’namedObject’,
die die Objektklasse ”posixGroup” ergänzen. Treten weitere Probleme mit einem der anderen Tools auf, liegt es häufig an den Einstellungen zu den LDAP-Objekten. Ein letzter
Test überprüft die korrekte Zuweisung der Gruppen: net groupmap list.
Damit sollte nun das Setup abgeschlossen und ein PDC mit verändertem Backend aufgesetzt worden sein. Nun können Sie die Schritte wie im Abschnitt ”Samba als PDC”
beschrieben wiederholen. Die Domäne heisst nun etwas anders, um den Unterschied herauszustellen. Für den Windows-Client ändert sich nicht viel (Abb. smbldap-domain ”Einfügen
einer Windows-XP Maschine in eine Domäne mit Samba/LDAP-Backend” und ”Anmeldung an der neuen Domäne” Abb. xp-sambatestnetz).
12.7.4
Fazit von Samba-LDAP-Aktionen
Der Aufwand für eine solche Aktion ist deutlich höher als ohne Verwendung von LDAP, da
eine ganze Reihe von Schritten durchzuführen sind. Wegen der höheren Komplexität schleichen sich schneller Fehler ein. Ein Admin braucht schon eine Menge Geduld, um eventuell
nicht passende Skripten anzupassen oder Software-Bugs zu umschiffen. Nicht jede Kombination von Samba und LDAP-Skripten funktioniert. Bei vermutlich jeder Distribution ist mit
händischer Nach- und Anpassungsarbeit zu rechnen. Belohnt wird der Administrator am
Ende jedoch von einer komfortablen Lösung zum bequemen Management einer WindowsDomäne ohne hierfür teure Microsoft-Server-Lizenzen beschaffen zu müssen. Fast nebenbei
fällt ein elegantes ”single-password” für Windows- und Linuxmaschinen ab. Zusätzlich kann
LDAP dazu benutzt werden zentrale Adressbücher bereitzustellen oder eine generelle Verwaltung bestimmter IT-Ressourcen zu realisieren.
Kapitel 13
Ressourcenverwaltung
13.1
Einleitung
In sehr grossen Netzen mit vielen gleichartigen Maschinen und vielen Benutzern, die sich
an fast allen Maschinen anmelden können, ist die klassische dezentrale Verwaltung von
Benutzern und Resourcen nicht mehr leistbar.
13.2
NIS
13.2.1
Zielsetzung
Wenn ein lokales Netzwerk betrieben wird, besteht ein Ziel üblicherweise darin, allen Benutzern eine Umgebung zur Verfügung zu stellen, die überall gleich konfiguriert ist. Die Benutzer sollen ein einheitliches Homeverzeichnis vorfinden und überall den gleichen Account
verwenden, für den das gleiche Passwort gültig ist. Hierzu sind die lebenswichtigen Daten
wie Account-Informationen zwischen allen Hosts zu synchronisieren. Darüberhinaus lassen
sich auch weitere Dateien synchronisieren, wie die /etc/hosts, /etc/services, /etc/groups ...
Deshalb entwickelte Sun vor einiger Zeit NIS, das Network Information System. NIS bietet einfache Datenbank-Zugriffseinrichtungen, die verwendet werden können, um Informationen, wie sie in den Dateien passwd und groups enthalten sind, an alle Hosts im Netzwerk
zu verteilen.
NIS basiert auf RPC (Remote Procedure Call und besteht aus einem Server, einer
Bibliothek für die Client-Seite und verschiedenen administrativen Tools. Bekannt wurde
NIS unter dem Namen Yellow Pages (”Gelbe Seiten”), kurz YP, der heute immer noch
häufig verwendet wird. Andererseits ist ”Yellow Pages” ein eingetragenes Warenzeichen,
so daß Sun den Namen fallen ließ. Da der Begriff aber gut merkbar war, bleiben manche
Namen einfach hängen, und so lebt YP als Präfix für die Namen der meisten NIS-Befehle
wie ypserv, ypbind, ypset etc. weiter.
13.2.2
NIS-Datenbanken
NIS hält seine Datenbank-Informationen in sogenannten Maps (etwa: Zuordnungen), die
Key/Value-Paare in Hashtables speichern. Die Maps werden auf einem zentralen Host vorgehalten, auf dem der NIS-Server läuft. Clients können die Informationen dann von diesem
Server über verschiedene RPC-Calls abrufen.
Die Maps selbst werden normalerweise aus Master-Textdateien wie /etc/hosts oder
/etc/passwd generiert. Aus manchen Dateien werden mehrere Maps generiert, jeweils eine
pro Suchschlüssel. Zum Beispiel können Sie die Datei hosts nach einem Hostnamen ebenso
203
204
KAPITEL 13. RESSOURCENVERWALTUNG
wie nach einer IP-Adresse durchsuchen. Entsprechend werden zwei NIS-Maps daraus erzeugt: hosts.byname und hosts.byaddr. Im folgenden wird eine Aufstellung der gängigen
Maps sowie der Dateien, aus denen sie generiert werden, gezeigt:
Master-Datei
/etc/hosts
/etc/networks
/etc/passwd
/etc/group
/etc/services
/etc/rpc
/etc/protocols
/etc/aliases
Mapfile(s)
hosts.byname, hosts.byaddr
networks.byname, networks.byaddr
passwd.byname, passwd.byuid
group.byname, group.bygid
services.byname, services.bynumber
rpc.byname, rpc.bynumber
protocols.byname, protocols.bynumber
mail.aliases
Tabelle 13.1: NIS-Maps
13.2.3
NIS-Server
13.2.4
NIS-Client
Die Konfigurationsdatei für NIS ist yp.conf.
# Syntax:
# ypserver <Name_of_ypserver>
ypserver 134.76.60.23
Der NIS-Domain-String enthalten in der DHCP-Variablen ”option-domain ”dxs”;” wird
mittels des Kommandos ”domainname name der nis domain” eingetragen. Alternativ kann
dieser Eintrag auch direkt nach /proc/sys/kernel/domainname geschrieben werden.
13.3
Hierarchische Datenbank: LDAP
13.3.1
Intro
In verteilten Umgebungen werden Informationen über Personen, Anwendungen, Dateien,
Drucker und andere, über das Netz zugängliche Ressourcen oft in einer speziellen Datenbank, einem sogenannten Directory gespeichert. Ein Directory Service ist ein Name Service,
der neben der Zuordnung Name-Objekt auch Metadaten enthält.
LDAP ist ein Kommunikationsprotokoll, das den Zugriff auf und die Aktualisierung von
Directory Informationen regelt. Es ist ein offener Industriestandard und eine vereinfachte
Alternative zum X.500 Standard. Die Netzwerkkommunikation wird mittels TCP/IP standardmäßig auf Port 389 abgewickelt. Es kann Bestandteil von Browsern, wie z.B. Netscape
sein. Ursprünglich wurde die Entwicklung von Netscape vorangetrieben, um den eigenen
Kunden ein übergreifendes Directory für Mail- und Webanwendungen anbieten zu können.
Das Protokoll arbeitet im klassischen Client-Server-Modell und verwendet Strings zur Datendarstellung.
X.500 wurde 1988 von der CCITT spezifiziert als ”eine Menge offener Systeme, die
gemeinsam eine Datenbank halten, in der Informationen über Objekte der realen Welt
abgelegt sind”. Die CCITT spezifiziert im wesentlichen drei Protokolle: DAP (Directory
Access Protocol), das zum Zugriff auf die Informationen dient, DSP (Directory Service
Protocol), mit dem die Kommunikation zwischen Servern durchgeführt wird, und DISP
13.3. HIERARCHISCHE DATENBANK: LDAP
205
(Directory Information Shadowing Protocol). Allerdings setzt X.500 auf einem vollständigen
ISO/OSI-Stack auf, was einen durchschlagenden Erfolg unmöglich machte.
X.500 kann als vollständig bezeichnet werden: Nichts, was nicht in ihm gespeichert werden könnte. Das Verzeichnis stellt eine Objektdatenbank dar. Zu speichernde Informationen werden in Objektklassen beschrieben: Attributnamen, Typen und deren Wertebereich.
Wesentliche Nachteile sind der hohe Implementationsaufwand und der ”schwergewichtige”
Zugriff: die Kommunikation zwischen Client und Server erzeugt eine recht hohe Netzlast, die
einer allgegenwärtigen Nutzung hinderlich ist - denn schließlich spielt ein Verzeichnisdienst
erst mit der allgemeinen Verwendung seine Stärken aus. LDAP schlägt eine Brücke.
13.3.2
Was kann mit LDAP abgebildet werden
LDAP speichert seine Informationen in einer Baumhierarchie. Diese Hierarchie kann diverse
Informationen enthalten. Einen Überblick verschafft RFC 2307, in dem mögliche Inhalte
der LDAP Hierarchie spezifiziert sind:
• Benutzer
• Gruppen
• IP-Dienste
• IP-Protokolle
• RPC’s
• NIS-Netzwerkgruppen
• Boot-Informationen
• Einhängepunkte für Dateisysteme
• IP-Hosts und Netzwerke
• RFC 822 konforme Mail-Aliase
Hat man Daten in Datenbanken, so ist es wichtig, diese Informationen zu strukturieren.
Besonders, wenn viele verschiedene Clients auf die Datenbank zugreifen wollen, zum Beispiel
Netscape, Outlook und andere, muss die Struktur genau definiert sein. Wenn ein Mailclient
eine eMail-Adresse braucht, muss er wissen, wie er diese bekommt.
Eine zentrale Benutzerverwaltung setzt das Vorhandensein einer geeigneten Authentifizierungsinfrastruktur auf jeder Maschine voraus. Hierfür wurde ursprünglich von SUN
vor inzwischen knapp 15 Jahren das Network Information System (NIS) entwickelt, welches lange Zeit den Standard einer verteilten Benutzerauthentifizierung und -verwaltung
im Unix-Umfeld darstellte. Dieses wird in einem eigenen Abschnitt kurz erklärt.
Mit den heute üblichen heterogenen Umgebungen, deren vielfältigen Authentifizierungsanforderungen (z.B. die Anmeldung an einem Radius-Server für Modem- oder ISDN-Einwahl) und den gestiegenen Sicherheitsforderungen konnte NIS nicht mehr mithalten. Neben den inzwischen recht umfänglichen Daten, die die Verwaltung eines Benutzers erfodert,
kommen weitere Wünsche nach einer zentralisierten Organisation von Rechner-Pools hinzu.
Diese Daten sollen meist ebenfalls geeignet abgelegt und komfortabel zugänglich gemacht
werden. Solche Aufgaben übernehmen ab einem bestimmten Umfang der Anforderungen
Datenbanken.
206
13.3.3
KAPITEL 13. RESSOURCENVERWALTUNG
Das Datenmodell
Bevor eine Datenbank mit Inhalten bestückt wird, sollte sich der Administrator mit ihrer
Funktionsweise grob vertraut machen. Das betrifft den Aufbau und die Ablage der Daten sowie das zugrundeliegende Kommunikationsmodell. Es gibt immer eine einzige Wurzel “root”
eines Directories. Diese kann später weder verschoben noch verändert werden. Unterhalb
von Root kann entweder ein Country-Objekt ’c’ oder oder eine Organisation ’o’ angelegt
werden. Ein Country-Objekt muss nicht, darf aber nur einmal existieren. Unterhalb von
Country oder Root muss ein Organisationsobjekt ’o’ stehen. Davon kann es mehrere geben.
Unterhalb von ’o’ folgen Blattobjekte, die Einträge oder Organisationsuntereinheiten ’ou’.
Einzelne Einträge werden vielfach durch ihren Common Name ’cn’ bezeichnet.
Alternativ zur beschriebenen Hierarchie hat sich die Bezeichnung durch Domain Components durchgesetzt. Die Wurzel wird beginnend mit der Toplovel-Domain des Domain
Name Service bezeichnet, in den darunterliegenden Hierachien folgen Second-Level-Domain
und vergleichbar mit den Organizational Units Sublevel-Domain-Namen.
Jedes Objekt im Verzeichnis muss einen eindeutigen Namen, den “Distinguished Name” ’dn’ haben. Der ’dn’ setzt sich aus den ’dn’ von der Wurzel aus zusammen, häufig
wird der Common Name zur Benennung verwendet. Einträge in einem Objekt werden als
Attribute bezeichnet. Ein Attribut ist der bereits angesprochene Common Name. Für eine
einfache Benutzerverwaltung benötigt ein Linux-Sytem, wenn der Common Name den Realnamen einer Person oder Dienstes bezeichnet, noch einen eindeutigen String, welcher die
User-ID bezeichnet, eine eindeutige Benutzer- und Gruppennummer, ein Homeverzeichnis,
eine Loginshell und eventuell ein Passwort. Zusätzliche Daten, wie Telefonnummer, Emailadresse, persönliche Webseite, Büro und weiteres können gespeichert werden, wenn aus der
Datenbank auch die Adressbücher der Mitarbeiter gefüttert werden sollen.
Ist der übergeordnete Container für das jeweilige Objekt bereits bestimmt, genügt zur
Angabe auch ein “Relative Distinguished Name” ’rdn’. Der Distinguished Name kann mit
dem Primärschlüssel einer relationalen Datenbank verglichen werden.
Jeder Directory-Eintrag beschreibt ein Objekt, welches eine Person, eine Verwaltungseinheite oder auch ein Server, Drucker usw. sein kann. Jeder Eintrag hat einen ausgezeichneten bzw. herausgestellten Namen, den distinguished name abgekürzt dn. Ein Eintrag kann
eine Reihe weiterer Attribute besitzen, die einen Typ und einen bzw. mehrere Werte haben.
Syntax
bin
ces
cis
tel
dn
Bedeutung
Daten im Binärformat, Bilder, Ausführbare Dateien
CaseSensitive, Textfelder
CaseInSensitive, Textfelder
Telefonnummer
Distinguished Name
Tabelle 13.2: Attribute im LDAP
Auf Basis dieser Attribute sind allgemeine Eintragsschemata definierbar. Hierbei implementiert LDAP folgendes Namensmodell: Jeder ausgezeichnete Name (dn) besteht aus einer
Sequenz von Teilen, die als relativ ausgezeichnete Namen bezeichnet werden. Alle Einträge
sind hierarchisch eingeordnet. Ein Beispiel eines dn:
cn=Sandra Buchfing, ou=Informatik,o=Universität Freiburg,c=DE.
Diese Informationen bzw. Teilbäume können dann über mehrere Server verteilt sein.
Es gibt viele Definitionen, an die man sich halten muss, soll am Ende auch etwas funktionieren. Bei LDAP werden Objekte mit Eigenschaften verwendet. Jedes Objekt hat zunächst
13.3. HIERARCHISCHE DATENBANK: LDAP
Attribute
CommonName
Alias
cn
surname
sn
TelephoneNumber
organizationalUnit ou
Organization
o
Country
Owner
c
dn
Syntax
cis
Beschreibung
Name eines Eintrages
cis
Nachname
einer
Person
tel
Telefonnummer
cis
Name einer Abteilung
cis
Name der Organisation
cis
Name des Landes
Ausgezeichneter cn=Sandra BuchName des Ein- fink, o=Universität
tragbesitzers
Freiburg,c=DE
207
Beispiel
Sandra Buchfink
Buchfink
01-12345
Informatik
Universität Freiburg
Deutschland, DE
Tabelle 13.3: Beispiel
einen eindeutigen Namen, an dem es von allen anderen unterschieden werden kann (“distinguished name”, kurz: DN). Die Eigenschaften eines Objekts hängen davon ab, zu welcher
Klasse es gehört (es kann sogar zu mehreren Klassen gehören).
Klassen von Objekten Es sind nun Klassen für Personen definiert. Zu einer Person
(”person”) gehören zwingend objectClass (die Objektklasse selbst), sn (der Nachname)
und cn (commonName, etwa: üblicher Name, hier wird üblicherweise Vor- und Nachname
verwendet). Zusätzlich gibt es optionale Attribute, die nicht unbedingt angegeben werden
müssen. Diese sind hier description (beliebige Beschreibung), seeAlso (verweist auf ein anderes Objekt), telephoneNumber (Telefonnummer), userPassword (ein Password). Da häufig
noch mehr Attribute mit einer Person verknüpft sind, gibt es auch eine Objektklasse organizationalPerson. Diese hat die gleichen geforderten Eigenschaften wie Person, aber erlaubt
viele optionale Eigenschaften, wie zum Beispiel Felder der Adresse und eine FAX-Nummer.
Es gibt noch mehr Klassen, zum Beispiel newPilotPerson (die als optionale Eigenschaft eine
eMail-Adresse mail einführt) und natürlich Klassen für Organisationen/Firmen, Abteilungen, Bilder, Dokumente, Geräte und so weiter.
Eigenschaften von Klassen Wenn man also irgendwo eine Person im Verzeichnis hat,
ist klar, dass diese ein cn haben muss, und eine Telefonnummer haben kann (und dass diese
genau telephoneNumber heißt). Soll ein Programm eine eMail-Addresse suchen, muss es nur
nachschauen, ob es ein Attribut mail gibt. Es kann eben nicht sein, dass diese Eigenschaft
email oder anders heißt. mail ist vorgeschrieben, und nichts anderes.
An diesem Beispiel kann man zeigen, dass eine natürliche Person zu mehreren Klassen gehört: person, organizationalPerson und newPilotPerson. Eine weitere Klasse ist top.
Im Prinzip gehört so ziemlich jedes Objekt auch zur Klasse top, die lediglich vorschreibt,
dass die Eigenschaft objectClass gesetzt sein muss (was bei allen Personenklassen ohnehin
gefordert ist).
Durch das Verwenden der Klassen definiert man, welche Eigenschaften vorhanden sein
müssen, und welche vorhanden sein können. Eine Person darf zum Beispiel keine Farbtiefe
haben, ein Bild hingegen schon. Verwendet man mehrere Klassen, so muss das entsprechende
Objekt alle von mindestens einer Klasse geforderten Eigenschaften haben, und kann alle
insgesamt erlaubten Eigenschaften haben.
208
KAPITEL 13. RESSOURCENVERWALTUNG
Typen von Eigenschaften Den Eigenschaften sind Typen zugeordnet. Es gibt Typen,
die eine Zeichenkette enthalten, und andere, die eine Telefonnummer enthalten. Diese Typen definieren weiterhin, wie Werte verglichen (und damit sortiert und gesucht) werden.
Zeichenketten beispielsweise kann man abhängig von Groß- und Kleinschreibung vergleichen oder auch nicht. Bei Telefonnummer spielen gewisse Füllzeichen möglicherweise keine
Rolle. Passwörter hingegen müssen genau übereinstimmen.
Es gibt nun also Objekte (die zu bestimmten Klassen gehören). Diese werden nun anderen Objekten untergeordnet (beziehungsweise werden anderen Objekte viele zugeordnet,
dies ist die richtige Reihenfolge). Diese baumartige Struktur kann man (mit etwas Phantasie) auch in der Realität finden: In Ländern gibt es Firmen, in Firmen gibt es Abteilungen
und in Abteilungen letztlich Personen. So wird das in LDAP auch gesehen. Die Baumstruktur wird hier “Directory Information Tree” genannt, kurz DIT. Es gibt Länder (also
Objekte der Klasse country [Land]) mit u.A. der Eigenschaft c (kurz für country), Firmen
(organisations mit der Eigenschaft o), Abteilungen (Organisations Einheit, organisationalUnit mit der Eigenschaft ou). Hierbei enthalten diese Objekte normalerweise viele weitere
Eigenschaften; eine Firma hat zum Beispiel eine Postanschrift.
Schema Ein Schema ist eine Sammlung von Strukturdefinitionen. Dazu gehören die Beschreibungen vieler Klassen und der verwendeten Typen. Es gibt verschiedene Schemata,
und es ist möglich, eigene zu definieren (oder bestehende zu erweitern) was jedoch nicht interoperabel mit anderen Diensten sein muss. Das liegt außerhalb der Betrachtungen dieses
Textes.
Der LDAP-Server speichert seine Informationen in einer baumartigen Struktur. Diese
wird auch “Directory Information Tree” genannt, kurz DIT.
Root
dn: dc=local
dn: dc=wg,dc=local
rdn: ou=user
rdn: ou=group
rdn: ou=devices
dn: uid=test01,ou=user,dc=wg,dc=local (rdn: uid=test01)
dn: uid=test02,ou=user,dc=wg,dc=local (rdn: uid=test02)
dn: uid=...
Abbildung 13.1: Aufbau der LDAP-Datenstruktur für die Beispielkonfiguration
Zum Speichern benutzt der LDAP-Server Objekte, die er mit Attributen versehen kann.
Dadurch kann man die Struktur flexibel an die eigenen Bedürfnisse anpassen. Das RFC
2256 spezifiziert die Standard-Objekte des LDAP-Servers. Man wird zwar von niemandem
gezwungen, diese Vorgaben auch zu benutzen. Um aber eine möglichst große Konformität
zu erzielen, sollte man diese Vorgaben einhalten.
13.4. LDAP PRAKTISCH
13.3.4
209
Das Protokoll
LDAP ist ein Kommunikationsprotokoll, das den Zugriff auf und die Aktualisierung von
Directory Informationen regelt. Es ist ein offener Industriestandard und eine vereinfachte
Alternative zum X.500 Standard. Die Netzwerkkommunikation wird mittels TCP/IP standardmäßig auf Port 389 abgewickelt. Es kann Bestandteil von Browsern, wie z.B. Netscape
sein. Ursprünglich wurde die Entwicklung von Netscape vorangetrieben, um den eigenen
Kunden ein übergreifendes Directory für Mail- und Webanwendungen anbieten zu können.
Das Protokoll arbeitet im klassischen Client-Server-Modell und verwendet Strings zur Datendarstellung.
Das Protokoll definiert insgesamt neun Operationen:
1. bind - Verbinden mit einem LDAP-Server
2. authenticate - Anmeldung mit einer bestimmten ID, sonst erfolgt eine anonyme Bindung (welche üblicherweise den niedrigsten Privilegienlevel hat)
3. unbind - Verbindung mit dem Server geregelt beenden
4. abandon - Verbindung mit dem Server (ungeregelt) abbrechen
5. add - Hinzufügen von Objekten und Attributen
6. search - Suchen
7. modify - Ändern von Objekten und Attributen
8. compare - Vergleich
9. delete - Löschen von Objekten oder Attributen
Die ersten vier Operationen dienen zum Verbinden, Abmelden und wechseln des Benutzerlevels. Mit verschiedenen Benutzerleveln sind üblicherweise verschiedene Zugriffsrechte
verknüpft. Der Datenbank-Administrator, der mit rootdn in der Konfigurationsdatei angegeben wird, hat immer alle Rechte.
LDAP erlaubt die Vergabe von Zugriffsrechten auf bestimmte Einträge und Attribute seiner Datenbasis. ’None’ erteilt keine Rechte, ’compare’ erlaubt Vergleiche. Es liefert
wahr oder falsch für den Passwort-Check zurück, so muss das Passwort zum Vergleich die
Datenbank nie verlassen. ’search’ gestattet das Suchen. ’read’ für Lesen ist die Kombination von ’compare’ und ’search’, ’write’ erlaubt das Schreiben und ’delete’ das Löschen von
Attributen und Einträgen.
13.4
LDAP praktisch
13.4.1
Server- und Clientprogramme unter Linux
Es existieren eine ganze Reihe von verfügbaren Produkten, die hierarchische Verzeichnisdienste nach dem LDAP-Standard definieren. Wie bei fast allen offenen Standards existiert
mit dem OpenLDAP eine freie Implementierung, welche unter der GPL zur Verfügung steht.
Der Daemon unter Linux heisst slapd und findet sich je nach Distribution unterhalb
des Diensteverzeichnisses /usr/sbin. Die zentrale Konfigurationsdatei des LDAP-Servers
slapd.conf befindet sich üblicherweise unterhalb von /etc/openldap. Die Datenbankdateien
210
KAPITEL 13. RESSOURCENVERWALTUNG
landen üblicherweise unterhalb von /var/lib/ldap. Dieses Verzeichnis wird in der slapd.conf
spezifiziert und kann dort entsprechend geändert werden.
Mit dem LDAP-Paket werden eine Reihe von Userspace-Utilities mitinstalliert. Die beiden Programme slapadd und slapcat eignen sich für direkte Transformation des LDIFFormats in das Datenbankformat und umgekehrt. Dazu wird kein laufender Server benötigt.
Für Operationen auf der LDAP-Datenbank finden sich die Werkzeuge ldapsearch, ldapadd, ldapdelete und ldapmodify. Diese implementieren die im Abschnitt zum Protokoll
genannten Operationen.
13.4.2
Eine einfache Beispielkonfiguration
Damit ein erster kleiner Eindruck gewonnen werden kann wie LDAP funktioniert, folgt ein
einfaches Beispiel für eine kleine Benutzerverwaltung. Dazu wird ein LDAP-Server auf der
Maschine eingerichtet, auf der sich die beiden Benutzer test01 und test02 anmelden sollen.
Dieses Setup erfordert keine verschlüsselten Verbindungen, da die gesamte Kommunikation
über das Loopback-Interface1 abgewickelt wird.
Die Serverkonfigurationsdatei /etc/openldap/slapd.conf könnte wie folgt aussehen:
# LDAP Server Konfigurationsdatei: /etc/openldap/slapd.conf
include
/etc/openldap/schema/core.schema
include
/etc/openldap/schema/cosine.schema
include
/etc/openldap/schema/nis.schema
pidfile
argsfile
/var/run/slapd/slapd.pid
/var/run/slapd/slapd.args
access to attr=userpassword
by anonymous auth
by self write
access to attr=objectclass,entry,mail,cn,sn,loginShell,userPassword
by self write
by * read
access to attr=objectclass,entry,uid,mail,cn,sn,uidNumber,gidNumber,\
homeDirectory,loginShell
by * read
access to *
by users read
by anonymous auth
database
ldbm
directory
/var/lib/ldap
suffix
"dc=wg,dc=local"
rootdn
"cn=Manager,dc=wg,dc=local"
rootpw
nicht-weitersagen
Nachdem die Konfigurationsdatei angelegt, die Existenz des Datenverzeichnisses und
dessen Rechte überrüft wurden, kann der Dienst einfach einmal gestartet werden:
1
Interfacename: lo, IP-Adresse: 127.0.0.1
13.4. LDAP PRAKTISCH
211
/usr/lib/openldap/slapd -f /etc/openldap/slapd.conf -h ldap://127.0.0.1:389
-u ldap -g ldap
In der Log-Datei /var/log/message kann der Erfolg der Aktion überprüft werden. Hier
landen Meldungen zu Fehlern in der Konfigurationsdatei.
Die Datei für die Einrichtung der Clientkommandos und das PAM-Modul:
/etc/openldap/ldap.conf sollte die folgenden Zeilen enthalten:
# LDAP Client Konfigurationsdatei: /etc/openldap/ldap.conf
BASE
dc=wg,dc=local
URI
ldap://127.0.0.1:389
Nun verbindet sich das Suchkommando ldapsearch -x schon mit der Datenbank. Es
liefert jedoch noch keine Daten zurück, solange die Datenbank noch nicht gefüllt wurde. Am
schnellsten geht die Bestückung der Datenbank durch das Anlegen einer Datei im LDAPAustauschformat LDIF (Lightwight Directory Interchange Format). Die Objekte werden
von der Wurzel aus folgend definiert und eingetragen:
# LDIF-Datei zur Definition von zwei Beispielnutzern: user.ldif
dn: dc=wg, dc=local
objectClass: organization
o: wg
dn: ou=user, dc=wg, dc=local
ou: user
objectclass: organizationalUnit
dn: ou=group, dc=wg, dc=local
ou: group
objectclass: organizationalUnit
dn: cn=user, ou=group, dc=wg, dc=local
objectClass: posixGroup
objectClass: top
cn: user
userPassword: crypt
gidNumber: 100
dn: uid=test01, ou=user, dc=wg, dc=local
uid: test02
cn: Test-User Nr. 1
sn: Test-User 1
objectclass: person
objectclass: posixAccount
objectclass: shadowAccount
objectclass: top
userPassword: secret
shadowLastChange: 11472
shadowMax: 99999
shadowWarning: 7
uidNumber: 1001
212
KAPITEL 13. RESSOURCENVERWALTUNG
gidNumber: 100
homeDirectory: /home/test02
loginShell: /bin/ksh
dn: uid=test02, ou=user, dc=wg, dc=local
uid: test02
cn: Test-User Nr. 2
sn: Test-User 2
objectclass: person
objectclass: posixAccount
objectclass: shadowAccount
objectclass: top
userPassword: topsecret
shadowLastChange: 11472
shadowMax: 99999
shadowWarning: 7
uidNumber: 1002
gidNumber: 100
homeDirectory: /home/test02
loginShell: /bin/bash
Die Übertragung des LDIFs in die laufende Datenbank geschieht mittels des Kommandos: ldapadd -c -x -D ”cn=Manager,dc=wg,dc=local” -W -f user.ldif. Hier findet
man den Datenbank-Manager-Account wieder, der in der Serverkonfigurationsdatei angegeben wurde. Beim Aufruf des Kommandos folgt die Frage nach dem zugehörigen Passwort.
Nun liefert ldapsearch -x bereits einiges mehr. Die Daten, die zu sehen sind, sind
diejenigen, welche für den anonymen Zugriff freigeben sind. Soll der vollständige Datensatz
angezeigt werden, gibt man die Datenbank-Manager-Credentials mit: ldapsearch -x D ”cn=Manager,dc=wg,dc=local” -w nicht-weitersagen. Dabei fällt auf, dass die
Ausgabe im bereits bekannten LDIF-Format erfolgt.
Der nächste Schritt ist nun die Einrichtung der PAM-Authentifizierung gegen die frisch
eingerichtete LDAP-Datenbank. Dazu wird als Beispiel das PAM-Modul für den SSH-Login
angepasst:
# /etc/pam.d/sshd
auth
required
auth
sufficient
auth
required
account required
password required
password required
password required
session required
session required
session required
session optional
pam_nologin.so
pam_ldap.so
pam_unix2.so
pam_unix2.so
pam_pwcheck.so
pam_ldap.so
pam_unix2.so
pam_unix2.so
pam_limits.so
pam_env.so
pam_mail.so
use_first_pass # set_secrpc
use_authtok
use_first_pass use_authtok
Weiterhin muss nun noch dem Name Service Switch die alternative zu den klassischen
Dateien passwd und shadow mitgeteilt werden:
# /etc/nsswitch.conf
13.4. LDAP PRAKTISCH
213
[ ... ]
passwd: files ldap
group: files ldap
[ ... ]
Anschliessend benötigt der Name Service Caching Daemon (nscd) eventuell noch einen
Neustart und ein einfacher Test mit einem SSH-Login-Versuch kann erfolgen. Dieses sollte
nun funktionieren, jedoch steht noch kein Homeverzeichnis zur Verfügung.
Die Liste der mittels LDAP zur Verfügung gestellten Benutzerkennungen kann mittels
getent angezeigt werden. Diese Einträge erscheinen nach den Daten aus der /etc/passwd.
13.4.3
Absicherung durch SSL
Wenn die Datenkommunikation über das Loopback-Interface direkt auf der Maschine stattfindet, ist die Sicherheit der übertragenen Daten ausreichend gewährleistet. Anders sieht
es aus, wenn LDAP-Pakete über ein Ethernet gehen. Deshalb kann eine LDAP-Verbindung
analog zu einer HTTP-Verbindung den Secure-Socket-Layer (SSL) verwenden. Wegen der
notwendigen Zertifikats- und Schlüsselerstellung bzw. -verwaltung gestaltet sich dieses etwas
aufwändiger.
Der schnellste Weg ginge über die Generierung eines selbstunterschriebenen Serverzertifikats. Da jedoch eine Reihe von Fehlern auftreten können und LDAP selbstunterschriebene
Zertifikate bemängelt, wird von diesem Weg abgeraten.
Besitzt man bereits ein von einer Certificate Authority (CA) unterschriebenes Serverzertifikat, kann man den nächsten Schritt überspringen. Da diese Zertifikate Geld kosten
und in regelmäßigen Abständen verlängert werden müssen, besitzen meistens nur Betreiber
großer Webserver solche. Das OpenSSL-Paket liefert die Lösung für dieses Problem mit ein Shell-Skript führt durch die Einrichtung einer eigenen CA.
Dazu wird ein eigenes Verzeichnis angelegt, z.B. /etc/LocalCA. In diesem Verzeichnis
startet der Aufruf von /usr/share/ssl/misc/CA.sh -newca (der angegebene absolute
Pfad kann je nach Distribution variieren) die Einrichtung der CA:
CA certificate filename (or enter to create)
Making CA certificate ...
Using configuration from /etc/ssl/openssl.cnf
Generating a 1024 bit RSA private key
...........++++++
...........................................................++++++
writing new private key to ’./demoCA/private/./cakey.pem’
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ’.’, the field will be left blank.
----Country Name (2 letter code) [AU]:DE
214
KAPITEL 13. RESSOURCENVERWALTUNG
State or Province Name (full name) [Some-State]:BaWue
Locality Name (eg, city) []:Freiburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:WG
Organizational Unit Name (eg, section) []:WG-LDAP
Common Name (eg, YOUR name) []:wg.local
Email Address []:.
Für den Dateinamen kann mit Enter einfach ein Defaultwert übernommen werden, alle anderen Abfragen können wie oben gezeigt ausgefüllt und mit entsprechenden Werten
übernommen werden. Das Passwort zur Absicherung der Schlüssel sollte sich für später
gemerkt werden. Im definierten Verzeichnis finden sich unter demoCA/cacert.pem und demoCA/private/cakey.pem das Zertifikat unserer CA und der private Schlüssel.
Im nächsten Schritt wird das Serverzertifikat generiert: openssl req -newkey rsa:1024
-nodes -keyout newreq.pem -out newreq.pem
Using configuration from /etc/ssl/openssl.cnf
Generating a 1024 bit RSA private key
............................++++++
..........................................................++++++
writing new private key to ’newreq.pem’
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ’.’, the field will be left blank.
----Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:BaWue
Locality Name (eg, city) []:Freiburg
Organization Name (eg, company) [Internet Widgits Pty Ltd]:WG
Organizational Unit Name (eg, section) []:WG-LDAP
Common Name (eg, YOUR name) []:wg.local
Email Address []:.
Please enter the following ’extra’ attributes
to be sent with your certificate request
A challenge password []:<passwort>
An optional company name []:.
Im großen und ganzen wiederholen sich die Abfragen der CA-Erstellung. Die zusätzlichen
Attribute können leer gelassen werden. Dieses geschieht durch die Angabe eines Punktes
”.”. Als Ergebnis existiert nun eine Datei newreq.pem im aktuellen Verzeichnis.
Nun muss der neuerzeugte Schlüssel noch von unserer CA signiert werden. Hierzu kommt
das bereits von der CA-Erstellung bekannte Skript zum Einsatz:
/usr/share/ssl/misc/CA.sh -sign
Using configuration from /etc/ssl/openssl.cnf
Enter PEM pass phrase:<passwort der CA>
Check that the request matches the signature
13.4. LDAP PRAKTISCH
215
Signature ok
The Subjects Distinguished Name is as follows
countryName
:PRINTABLE:’DE’
stateOrProvinceName
:PRINTABLE:’BaWue’
localityName
:PRINTABLE:’Freiburg’
organizationName
:PRINTABLE:’WG’
organizationalUnitName:PRINTABLE:’WG-LDAP’
commonName
:PRINTABLE:’wg.local’
Certificate is to be certified until Jun 16 09:07:05 2004 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=DE, ST=BaWue, L=Freiburg, O=WG, OU=WG-LDAP, CN=wg.local
Validity
Not Before: Jun 17 09:07:05 2003 GMT
Not After : Jun 16 09:07:05 2004 GMT
Subject: C=DE, ST=BaWue, L=Freiburg, O=WG, OU=WG-LDAP, CN=wg.local
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:a4:03:ef:1b:5d:20:2b:bd:03:f7:ce:9e:5a:f2:
f4:58:9a:f1:7f:9c:20:fc:ab:a7:b6:b7:41:4c:7f:
14:e8:79:20:ba:1c:c6:1a:26:ad:d1:28:6e:60:99:
c7:99:1f:3d:7c:9c:77:6a:f9:5a:63:f7:b1:e7:94:
dc:10:66:8b:a6:8f:11:4d:17:7b:98:85:ce:a4:bc:
e9:1c:24:f8:ee:eb:3e:c7:50:7f:68:53:be:b5:7a:
e8:cb:d3:db:34:31:eb:04:67:96:8c:e5:6c:d0:7b:
e7:cb:21:0a:a3:97:7c:e3:9c:73:53:1d:8e:c1:6d:
61:58:9c:c6:f5:df:94:f9:63
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
95:5F:39:05:C4:99:9A:FC:83:26:B2:F8:8E:2E:55:CC:D6:65:C2:9F
X509v3 Authority Key Identifier:
keyid:DC:B2:AA:81:3C:96:A4:1D:8A:8C:BE:A8:79:85:62:22:BF: \
F1:3B:FF
216
KAPITEL 13. RESSOURCENVERWALTUNG
DirName:/C=DE/ST=BaWue/L=Freiburg/O=WG/OU=WG-LDAP/CN=wg.\
local serial:00
Signature Algorithm: md5WithRSAEncryption
64:2f:46:48:e2:2b:e9:d4:99:47:5e:35:69:d2:1c:8f:33:c5:
[ ... einige weitere Zeilen ... ]
7c:9f:b2:ee:da:dc:26:fc:08:6f:2e:e6:07:4c:72:b0:88:89:
d8:3a
-----BEGIN CERTIFICATE----MIIDJTCCAo6gAwIBAgIBATANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJERTEO
MAwGA1UECBMFQmFXdWUxETAPBgNVBAcTCEZyZWlidXJnMQswCQYDVQQKEwJXRzEQ
[ ... etliche Zeilen ... ]
1qZZj7c5u5UJHrngC/fRUr5nCgI0fJ+y7trcJvwIby7mB0xysIiJ2Do=
-----END CERTIFICATE----Signed certificate is in newcert.pem
Damit liegt nun mit newcert.pem das Server Zertifikat unterschrieben von der eigenen CA
mit dem privaten Schlüssel newreq.pem vor. Nun ist alles soweit vorbereitet und das Zertifikat kann in das entsprechende Verzeichnis für den Zugriff des LDAP-Servers verschoben
werden.
Dazu wird das Verzeichnis /etc/openldap/certificates erzeugt und die Zertifikate dort
hineinkopiert oder -bewegt.
cp demoCA/cacert.pem /etc/openldap/certificates/cacert.pem
mv newcert.pem /etc/openldap/certificates/servercrt.pem
mv newreq.pem /etc/openldap/certificates/serverkey.pem
chmod 400 /etc/openldap/certificates/serverkey.pem
chown -R ldap.ldap /etc/openldap/certificates
Das letzte Kommando übergibt dem LDAP-Nutzer die Rechte für das Verzeichnis, da
sonst der Serverschlüssel vom LDAP-Daemon nicht gelesen werden kann. In einem solchen
Fall öffnet der Server keinen SSL-Port und hinterläßt eine Fehlermeldung in der Log-Datei.
Nun müssen noch drei Zeilen am Anfang der Server-Konfigurationsdatei slapd.conf eingefügt werden:
TLSCertificateFile
/etc/openldap/certificates/servercrt.pem
TLSCertificateKeyFile /etc/openldap/certificates/serverkey.pem
TLSCACertificateFile /etc/openldap/certificates/cacert.pem
Der Aufruf des LDAP-Daemon sieht nun etwas anders aus: /usr/lib/openldap/slapd
-f /etc/openldap/slapd.conf -h ldaps://10.8.4.254:636 -u ldap -g ldap
Zum einen wird mittels ldaps://10.8.4.254:636 das abgesicherte Protokoll gewählt und
zum anderen kann nun der Server für die netzweite Benutzung zur Verfügung gestellt werden. Damit wie eingangs gezeigt die LDAP-Client-Programme wieder bequem funktionieren, wird eine Anpassung der ldap.conf erforderlich:
BASE
ou=user,dc=wg,dc=local
URI
ldaps://10.8.4.254:636
SASL_SECPROPS noactive
TLS hard
TLS_REQCERT allow
13.4. LDAP PRAKTISCH
217
Nun liefert der Aufruf der Kommandos ldapsearch -x oder getent passwd wieder die
eingangs gezeigten Ausgaben. Dabei beschränkt sich dieses nicht mehr auf den Server selbst,
sondern kann von jeder beliebigen Maschine im Netzwerk geschehen, wenn die Dateien
ldap.conf und nsswitch.conf entsprechend eingerichtet wurden.
218
KAPITEL 13. RESSOURCENVERWALTUNG
Kapitel 14
Drucken im Netz
14.1
Einleitung
Zum Drucken unter Unix gibt es verschiedene Ans”atze:
• BSD-System
• System V
• CUPS
Das BSD-System ist historisch gesehen das ”alteste und war lange bei SUN-Systemen
im Einsatz. Das System V Drucksystem sollte mehr den Bed”urfnisse grosser Unternehmen
gerecht werden, ist aber sehr kompliziert. Cups (Common UNIX Printing System) versucht
die beiden Ans”atze zu verbinden und implementiert das Internet Printing Protocol, das
als neuer Standard entwickelt wurde.
14.1.1
Anforderungen
Folgende Anforderungen werden an ein Drucksystem gestellt? Zum einen sollten alle lokal
anschließbaren Drucker funktionieren:
• USB
• Parallel
• Seriell
• Irda
• Bluetooth
Zum anderen sollten alle Drucker im Netz verwendbar sein:
• Ethernet-Drucker
• Lokale Drucker an anderen LINUX/UNIX/MAC-Systemen
• Lokale Drucker an Windows-Systemen
Desweitern sollte ein Drucker m”oglichst viele Dateiformate annehmen und direkt verarbeiten k”onnen. Hier besteht ein wesentlicher Unterschied zu MS-Windows-Systemen. Dort
gibt es nur das Programm print im Kommandomodus, das direkt Textdateien ausdruckt.
Das Kommando lpr unter Linux war urspr”unglich auch nur f”ur Textdateien ausgelegt,
wurde aber durch Erweiterung um Filter flexibel. (s. Kap. 14.2.4)
219
220
KAPITEL 14. DRUCKEN IM NETZ
14.1.2
Grundlagen
Das Linuxdrucksystem basiert auf einem Filtermechanismus, an dessen Anfang das Dokument, am Ende das Device (z. B. /dev/lp0 = parallele Schnittstelle) steht.
Das Druckkommando ist lpr (Line Printer). Mit lpr textdatei wird eine Textdatei
auf den Standarddrucker gedruckt. Mit export PRINTER=color wird der Standarddrucker
auf color gesetzt. Falls man einen anderen als den Standarddrucker verwenden möchte,
kann kann man den gewünschten Drucker beim Aufruf mitangeben: lpr -Pdruckername
textdatei
Aber was genau passiert nach einem solchen Aufruf? Beim Aufruf von lpr werden die
angegebenen Optionen interpretiert und angewendet. Anschliessend sorgt lpr dafür, dass
die Datei in das Spoolverzeichnis des angegebenen Druckers geschickt wird. Der Spooler
(früher lpd, heute meist LPRng nimmt den Druckauftrag entgegen und gibt einen Druckjob
aus. In diesem Prozess werden die Ausgabeformate der jeweiligen Anwendung durch die
Filter in ein Druckformat umgewandelt. Welches Druckformat der Drucker verwendet geht
aus der PPD-Datei (PostScript Printer Description) hervor. Die PPD-Datei ist eine Textdatei, in der die anzuwendenden Filter gelistet sind. Die PPD-Dateien werden meist schon
beim Installieren des Betriebssystems zur Verfügung gestellt. Auch CUPS stellt eine Reihe
von PPD-Dateien zur Verfügung. Die Arbeit der Filter besteht darin, das Ausgabeformat
automatisch zu erkennen und ein geeignetes Konvertierungsprogramm aufzurufen, um die
Datei in PostScript umzuwandeln.
Nachdem der Spooler den Druckauftrag entgegengenommen hat und die Filter die Datei
in das Druckformat umgewandelt haben, befindet sich der Druckjob in der Warteschlage,
der sogenannten Queue. Mit dem Befehl lpq kann man sich alle Druckjobs ausgeben lassen.
Der Drucker bekommt die Druckjobs aus der Queue und druckt den PostScript-Code.
Hierzu bedarf es eines Raster-Image-Prozessors (RIP), der für die Ausgabe des PostScriptCodes sorgt. Bei PostScript-fähigen Druckern ist der RIP im Drucker integriert, bei nichtPostScript-kompatiblen Druckern wird ein Post-Script-Interpreter benötigt, der aus den
PostScript-Informationen ein Datenformat erzeugt, das vom jeweiligen Drucker verstanden
wird. Dieser Interpreter wird durch den druckerspezifischen Treiber zur Verfügung gestellt.
Die Funktionsweise des Treibers geht aber natürlich über das Erzeugen des richtigen Datenformates weit hinaus. Aufgabe des Treibers ist es, die zu druckende Datei mit all den
Informationen zu ergänzen, die für die optimale Nutzung der Hardware nötig sind.
Diese Beschreibung der Funktionsweise des Drucksystems ist natürlich stark vereinfacht. Anhand der genaueren Betrachtung des CUPS (Common Unix Print System) werden die Zusammenhänge detailliert beschrieben werden. Unter den verschiedenen Systemen
zur Konfiguration und Administration des Drucksystems unter Linux wird das CUPS am
häufigsten verwendet. Es eignet sich sowohl für die Konfiguration von Einzelplatz Rechnern/Druckern, als auch für komplizierte Systeme im Netzwerk.
14.2
CUPS
Im CUPS (Common Unix Printing System) übernimmt der cupsd die Aufgaben des lpd:
Annehmen der Druckaufträge, ggf. Weiterleiten an die entsprechenden Filter, Einreihen in
die Warteschlage und Aufruf des passenden Backends, das die fertigen Jobs in passender
Form an den Drucker gibt. Der cupsd implementiert den neuen Standard IPP (Internet
Printing Protocol) und stellt somit folgende zusätzliche Funktionalität zur Verfügung:
• Authentifizierung von Benutzern
14.2. CUPS
221
• Verschlüsselung der Druckdaten bei der Übertragung
• Bekanntgabe verfügbarer Drucker im Netz
IPP ist ein Protokoll der Anwendungsschicht und kann für verteiltes Drucken im Interund Intranet verwendet werden. Das Protokoll definiert die Interaktion zwischen CUPSServer und -Client und ermöglicht dem Client Abfragen von Druckerinformationen.
14.2.1
Client-Server-Architektur
Im CUPS ist jeder Rechner, an den ein Drucker angeschlossen ist, ein Server. Rechner, die
entfernte Drucker nutzen wollen, sind Clients. Ein Standalone-Rechner, an dem ein Drucker
angeschlossen ist, der mit CUPS verwaltet wird, ist sozusagen ein Client, der sein eigener
Server ist.
Jeder Server ist selbst für die Aufbereitung der Druckjobs zuständig, d.h. jeder Server
muss sowohl die für das Druckformat des Druckers nötigen Filter, als auch den entsprechenden Treiber selber zur Verfügung stellen. Sämtliche gerätespezifischen Informationen gehen
aus der PPD-Datei hervor (PostScript Printer Description), die mit dem Druckertreiber
mitgeliefert wird.
Durch die Verwendung des IPP, lässt sich der CUPS Dämon wie ein Webserver ansprechen. CUPS-Rechner kommunizieren über den IPP-Port 631. Der Zugriff auf das Webinterface erfolgt folglich über den Browser durch den Aufruf http://localhost:631/. An diesen
Port werden nicht nur die Druckdaten geschickt, sondern auch viele weitere Informationen.
Da IPP auf HTTP 1.1 beruht, ist die Konfigurationsdatei /etc/cups/cupsd.conf der
httpd.conf sehr ähnlich. Die wichtigsten Einstellungen werden in Kapitel 14.2.5 erläutert.
Eine weitere Besonderheit von CUPS sind die Backends. Sie sorgen für den Versand von
Druckdaten zu den Ausagbegeräten oder anderen Servern. Die CUPS-Backends ermöglichen
die Verbindung über verschiedene Schnittstellen und Protokolle mit dem Server. Für jedes
Protokoll (parallel, seriell, USB oder Neztwerk) ist ein eigenes Backend zuständig. Die
CUPS-Backends erlauben so, Druckjobs an alle herkömmlichen Drucker zu schicken.
Abbildung 14.1: Cupsdiagramm
14.2.2
IPP
IPP ist ein Protokoll der Anwendunsschicht und wird in erster Linie für verteiltes Drucken
im Netz verwendet. Das Protokoll definiert die Interaktion zwischen IPP-Client und IPPServer, d.h. es wird definiert, wie die Daten für die Steuerung des Druckvorgangs verwendet
werden, wie die Daten kodiert und wie sie transportiert werden. Der Datentransport mit IPP
ist generell verschlüsselt. Desweiteren definiert IPP das s.g. Verzeichnisschema, über das ein
222
KAPITEL 14. DRUCKEN IM NETZ
Verzeichnisserver nach verfügbaren Ausgabegeräten gefragt werden kann. Ausserdem bietet
IPP die Möglichkeit, den Zugriff auf Drucker einzuschränken.
14.2.3
Funktionsweise
Die Kommunikation zwischen Client und Server erfolgt gemäß dem bekannten RequestResponse-Verfahren. Diese Anfragen und Antworten sind durch ASCII Code definiert und
werden mittels des HTTP 1.1 Postmechanismus durchgeführt.
Ein Request des Clients sieht wie folgt aus:
ipp:druck.server/meindrucker/meindruckauftrag
und führt dazu, dass der Client eine Verbindung zu Port 631 des Servers druck.server aufbaut und folgende Daten übermittelt:
POST /meindrucker/meindruckauftrag
HTTP/1.1
Host: druck.server:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
“printer-url”
“ipp://druck.server/meindrucker/meindruckauftrag”
...
14.2.4
Filter
Die Filter findet man in /usr/lib/cups/filter/. Meist ersieht man schon aus dem Namen
der Filter, welche Konvertierung er vornimmt. CUPS erkennt automatisch, welche Filtermechanismen angewendet werden müssen, d.h. welche Filter hintereinander angewandt werden
müssen. Lediglich das Ausgabeformat muss man eintragen, sofern man ein anderes Format
als PostScript verwenden möchte. (PostScript ist standardmässig vordefiniert.)
14.2.5
Konfiguration
Die Konfiguration von CUPS kann - wie bereits erwähnt - über den Browser durch einen
Aufruf von http://localhost:631 geschehen. Eine weitere Möglichkeit zur Kofiguration
des CUPS bietet Yast2. Es gibt aber auch schicke Webfrontends, die speziell für die Konfiguration von CUPS entwickelt wurden. Eine der bekanntesten Schnittstellen ist das KUPS
(s. http://cups.sourceforge.net/kups/index.htm)
Möchte man die Konfiguration von Hand machen, beschränkt sich dies fast ausschliesslich auf folgende Dateien:
In /etc/cups:
cupsd.conf und mime.types
In /var/log/cups:
error log page log access log (f. Netzwerke)
Die zwei wichtigsten Designentscheidungen bei der Konfiguration von CUPS sind “Browsing On” und “Browse Poll”.
Sofern in der cupsd.conf eines CUPS-Rechners “Browsing On” gesetzt ist, stellt der
Rechener per UDP-Broadcast den Namen des Druckers, Statusinformtionen und andere
Zusatzinformationen zur Verfügung. Hierbei sollte man nicht ausser Acht lassen, dass die
Broadcasts (entsprechend der TCP/IP-Spezifikation) nur bis zum nächsten Router oder
14.3. ALTERNATIVEN
223
Gateway weitergegeben werden. Wenn bei einem bestimmten Client nur die BrowsingInformationen eines bestimmten Servers verwendet werden sollen, kann man das in der
Konfigurationdatei des Client durch Einträge der folgenden Art erreichen: BrowseAllow
134.76.82.10, BrowseDeny 134.76.82.11.
Das Gegenstück zum Browsing (per Broadcast) ist das Polling. In diesem Fall, warten die
Clients nicht passsiv auf die Informationen über zur Verfügung stehende Drucker, sondern
besorgen sich diese aktiv bei einem bestimmten Server. Hierzu verwendet man eine Angabe
in Form von BrowsePoll 134.76.82.10:631, die dazu führt, dass der genannte Server
nach verfügbaren Druckern gefragt wird, sobald gedruckt werden soll. Beim Polling gilt
allerdings dieselbe Einschränkung des Broadcasts: Es könne nur Server im gleichen LAN
angesprochen werden.
Die Lösung diesen Problems ist, einen Router oder Gateway des eigenen LANs zum
so.g. Browse-Relay zu machen.
14.3
Alternativen
Zu den heute gängigen Alternativen zu CUPS zählen:
• TurboPrint: Ein kommerzielles Drucksystem, mit dem man bestmögliche Druckqualität erreichen kann. Nähere Informationen unter www.turboprint.de
• KDEPrint: Ein Modul der KDE-Oberfläche unter Linux. Es ermöglicht einen einfachen und intuitiven Zugriff auf sämliche CUPS-Funktionalitäten. Nähere Informationen unter printing.kde.org
224
KAPITEL 14. DRUCKEN IM NETZ
Kapitel 15
Wichtige Netzwerkkommandos
15.1
Offene Dateien und Netzwerkverbindungen
Das Kommando lsof (ListOpenFiles) zeigt die geöffneten Dateien (zum Lesen oder Schreiben) an und die dazugehörenden Prozesse. Weiterhin werden offene Sockets (Netzwerkverbindung mit Portadresse), sowie verwendete Pipes und Filesockets angezeigt.
15.2
netstat
netstat hat sich auf das Anzeigen offener Sockets, sowohl des Filesystems, als auch von
Netzwerkverbindungen spezialisiert. Die Ausgabe von netstat -a hat folgendes Aussehen,
wobei die Protokolle TCP, UDP und unix (Socket im Filesystem) in dieser Reihenfolge
sortiert aufgeführt werden.
dirk@shuttle:~/ > netstat -a |more
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp
0
0 *:nfs
*:*
LISTEN
tcp
0
0 *:mysql
*:*
LISTEN
udp
0
0 *:who
*:*
udp
0
0 *:nfs
*:*
...
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags
Type
State
I-Node Path
unix 9
[ ]
DGRAM
613
/dev/log
unix 2
[ ACC ] STREAM LISTENING 3810
/tmp/.X11-unix/X0
unix 2
[ ACC ] STREAM LISTENING 6332
/tmp/.ICE-unix/1051
...
Mit netstat -M kann man sich einen Überblick verschaffen, welche Netzwerkverbindungen gerade maskiert werden:
root@server:/ # netstat -M
IP masquerading entries
prot expire source
tcp
0:40.46 1234.test.local
tcp
0:45.64 1234.test.local
tcp
0:49.43 1234.test.local
destination
210.24.30.216
210.24.30.216
210.24.30.216
225
ports
3592 -> 2183 (64155)
3593 -> 2187 (64156)
3594 -> 2188 (64157)
226
KAPITEL 15. WICHTIGE NETZWERKKOMMANDOS
tcp
tcp
...
1:03.12 1234.test.local 210.24.30.216 3596 -> 2195 (64159)
0:54.57 1234.test.local 210.24.30.216 3595 -> 2192 (64158)
Wird die Option “-n” beim Aufruf des Kommandos aufgeführt, wird keine Namensauflösung durchgeführt, was die Anzeige stark beschleunigen kann, gerade bei IP-Nummern,
die nicht im Nameserver bekannt sind.
netstat -r liefert die Kernel-Routingtabelle in ähnlicher Weise, wie sie auch vom Kommando route angezeigt wird. Wenn Sie netstat mit dem Flag -i aufrufen, gibt es die Statistiken für die gerade aktiven Netzwerk-Schnittstellen aus. Geben Sie außerdem das Flag
-a mit an, werden alle im Kernel vorhandenen Schnittstellen ausgegeben, nicht nur die
konfigurierten Schnittstellen. An der Konsole produziert netstat -i in etwa folgendes:
root@server:/ # netstat -i
Kernel Interface table
Iface
MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR
TX-DRP TX-OVR Flags
lo
0
0
3185
0
0
0
3185
0
0
0 BLRU
eth0
1500
0 972633
17
20
120 628711
217
0
0 BRU
Die Spalten MTU und Met geben die aktuelle MTU und Metrik des Interface an. Die
mit RX bzw. TX überschriebenen Spalten geben an, wie viele Pakete:
• RX-OK/TX-OK fehlerfrei empfangen bzw. gesendet wurden
• RX-ERR/TX-ERR wie viele beschädigt waren
• RX-DRP/TX-DRP wie viele wegeworfen werden mußten
• RX-OVR/TX-OVR wie viele aufgrund eines Overruns verlorengingen
Die letzte Spalte zeigt wieder die Liste der Flags, die für die Schnittstelle gesetzt sind. Das
sind einbuchstabige Versionen der langen Flagnamen, die ifconfig ausgibt:
Buchstabe
B
L
M
O
P
R
U
Bedeutung
BROADCAST
LOOPBACK
PROMISC
NOARP
POINTOPOINT
RUNNING
UP
Tabelle 15.1: Bezeichner
15.3
Systemprogramme
15.3.1
Dämonen
xinit, init, rinted, nfsd, smbd, nmbd, proftpd, httpd, dhcpd
15.4. NETZWERKKONFIGURATION
15.4
227
Netzwerkkonfiguration
ifconfig, route, ip, ping, nslookup, dig, tc, ifuser
tcptraceroute
ttcp (Throughput of UDP / TCP traffic)
tcptrack (per connection bandwidth monitor)
tcpstat tcpick, tcpflow,
15.4.1
Netzwerktests
ping traceroute mtr
netdiag
Net-Diagnostics (trafshow,strobe,netwatch,statnet,tcpspray,tcpblast) Netdiag contains
a collection of small tools to analyze network traffic and configuration of remote hosts
(strobe). It is of invaluable help if your system is showing strange network behaviour and
you want to find out what your network is doing.
nictools-nopci
nictools-pci
Diagnostic tools for many PCI ethernet cards These tools can help you to diagnostic
problems with your ethernet cards or - in some cases - give those cards the final hint, to work
in your network. alta-diag : Diagnostic and setup for the Sundance ”Alta” NIC eepro100diag : Diagnostic and setup for the Intel EEPro100 Ethercards epic-diag : Diagnostics
and EEPROM setup for the SMC EPIC-100 myson-diag : Diagnostic and setup for the
Myson mtd803 Ethernet chip natsemi-diag : Diagnostic and setup for the NatSemi DP83815
Ethernet chip ne2k-pci-diag : Diagnostics and EEPROM setup for PCI NE2000 clones
ns820-diag : Diagnostic and setup for the NatSemi DP83820 Ethernet chip pcnet-diag :
Diagnostic and setup for the AMD PCnet/PCI Ethernet chip rtl8139-diag : Diagnostics
and EEPROM setup for RealTek RTL8129/8139 chips starfire-diag : Diagnostic and setup
for the Adaptec Starfire DuraLAN tulip-diag : Diagnostic and setup for the Digital DC21x4*
Ethercards chips via-diag : Diagnostic and setup for the VIA Rhine vt86c100 and vt3043
Ethernet chips vortex-diag : Diagnostics and EEPROM setup for the 3Com Vortex series
winbond-diag : Diagnostic and setup for the Winbond w89c840 ethercards yellowfin-diag:
Diagnostic and setup for the Packet Engines Yellowfin chip
Das Kommando ping ist Teil jeder Linux-Distribution. Das Programm sendet ein spezielles Datagramm über das Netzwerk an einen anderen Rechner. Wenn dieser eingeschaltet
ist und es empfängt sendet er es wieder zurück und man weiß, dass Rechner und Netzwerk
in Ordnung sind. In der einfachsten Form sieht das so aus:
dirk@randy2:~/vorlesung/lak> ping login
PING login (132.230.1.143) from 132.230.9.124 : 56(84) bytes of data.
64 bytes from login3 (132.230.1.143): icmp_seq=1 ttl=63 time=4.44 ms
64 bytes from login3 (132.230.1.143): icmp_seq=2 ttl=63 time=0.219 ms
64 bytes from login3 (132.230.1.143): icmp_seq=3 ttl=63 time=0.217 ms
64 bytes from login3 (132.230.1.143): icmp_seq=4 ttl=63 time=0.218 ms
^C
--- login.ruf.uni-freiburg.de ping statistics --4 packets transmitted, 4 received, 0% loss, time 3030ms
rtt min/avg/max/mdev = 0.217/1.275/4.448/1.831 ms
228
KAPITEL 15. WICHTIGE NETZWERKKOMMANDOS
ping sucht zunächst die richtige IP-Adresse zu dem angegebenen Rechnernamen heraus1
und sendet dann in regelmäßigen Abständen ein bestimmtes Datagramm an diese Adresse.
Für jeden dieser icmp echo requests wird der andere Rechner dann ein icmp echo reply
als Antwort zurücksenden. Jede der Zeilen 64 bytes from ... stellt eine solche empfangene
Rückantwort dar. In jeder Zeile ist auch die Adresse des Absenders dieses Paketes angegeben, die Nummer des echo requests, auf den mit diesem Paket geantwortet wurde, die
time to live (Lebensdauer) sowie die round trip time, das ist die Zeit in Millisekunden zwischen Absendung des request und Empfang des entsprechenden echo reply. Damit ist dies
in gewissen Grenzen ein Maß für die Geschwindigkeit des Netzwerkes.
ping würde endlos weiter seine Pakete senden, deshalb muß es abgebrochen werden.
Dies geschieht durch gleichzeitiges Drücken der Tasten Control (Strg) und C. Danach gibt
ping noch eine Statistik der gesendeten Pakete aus. In den letzten beiden Zeilen ist es: Die
Anzahl der gesendeten, empfangenen, sowie unbeantworteten Pakete. Außerdem kürzeste,
längste und mittlere Antwortzeit. Eine hohe Verlustrate an Paketen deutet auf Probleme
mit der Verbindung hin, diese können durch schlechte Verbindungen, überlastete Router
oder Kollisionen im lokalen Ethernet verursacht werden. Man kann mit ping die schadhafte
Stelle lokalisieren, indem man nacheinander alle Knotenpunkte der Verbindung an-pingt
und nachsieht, ab welchem Punkt die Verlustrate stark ansteigt.
Mit traceroute (auch bei jeder Distribution dabei) kann man den Weg, den die Datagramme bei einer Verbindung zwischen zwei Rechnern zurücklegen, testen und anzeigen.
Wie auch ping verwendet traceroute dazu das icmp Protokoll. Es verwendet jedoch einen
Trick, um von jeder durchlaufenen Knotenstelle eine Rückmeldung zu bekommen, und das
geht so: Das Feld time to live eines icmp-Datagramms dient eigentlich dazu, zu verhindern,
dass das Datenpaket ewig im Netz herumgeschickt wird, z.B. wenn es in eine RoutingEndlosschleife gerät. Zu diesem Zweck verringert jeder Router, der das Paket weiterleitet,
den Zähler in diesem Datenfeld um eins. Wird dabei der Wert Null erreicht, so wird der
Router, bei dem dies geschehen ist, eine “icmp time to live expired Meldung” an den ursprünglichen Absender des Datagramms senden um ihm mitzuteilen, dass das Datagramm
‘abgelaufen’ ist. traceroute sendet nun nacheinander Datagramme ab, deren time to live
(beginnend bei eins) jeweils um eins erhöht wird. Indem es nun die eingehenden “icmp
time to live expired Meldungen” auswertet, kann es genau den Weg, den die Datagramme
nehmen, verfolgen - bis der wirkliche Zielrechner erreicht ist. Das sieht dann so aus:
dirk@test:~/vorlesung/lak> /usr/sbin/traceroute goe.net
traceroute to goe.net (134.76.60.86), 30 hops max, 40 byte packets
1 132.230.22.254 2.735 ms
5.013 ms
7.667 ms
2 132.230.223.254 0.707 ms
0.832 ms
0.721 ms
3 nsc-rz-gwn.fun.uni-freiburg.de (132.230.0.141) 0.386 ms 0.355 ms \
0.307 ms
4 Freiburg1.Belwue.DE (129.143.15.141) 0.576 ms 0.545 ms 0.496 ms
5 Stuttgart1.BelWue.DE (129.143.1.7) 3.813 ms 4.605 ms 0.573 ms
6 Stuttgart2.BelWue.DE (129.143.1.34) 4.523 ms 4.521 ms 4.520 ms
7 Frankfurt1.BelWue.DE (129.143.1.26) 8.393 ms 8.335 ms 8.304 ms
8 ffm-b2-geth0-1.telia.net (213.248.79.41) 8.592 ms 8.668 ms 8.713 ms
9 ffm-b2-geth0-1.telia.net (213.248.68.33) 8.558 ms 8.531 ms 8.503 ms
10 ffm-bb2-pos2-3-0.telia.net (213.248.64.177) 8.745 ms 8.692 ms 8.662 ms
11 hbg-bb2-pos1-1-0.telia.net (213.248.65.2) 18.104 ms 18.057 ms 18.129 ms
12 hbg-b1-pos1-0.telia.net (213.248.68.6) 18.047 ms 18.000 ms 17.993 ms
13 dante-01616-hbg-b1.c.telia.net (213.248.103.98) 17.439 ms 17.800 ms \
17.487 ms
14 cr-hannover1.g-win.dfn.de (188.1.18.178) 199.467 ms 199.447 ms \
199.511 ms
1
Voraussetzung ist natürlich, dass /etc/hosts und der Nameserver richtig konfiguriert sind
15.4. NETZWERKKONFIGURATION
15
16
17
18
229
ar-goettingen1.g-win.dfn.de (188.1.88.74) 20.239 ms 20.192 ms 20.162 ms
c12012-int.gwdg.de (134.76.249.201) 20.786 ms 20.738 ms 20.705 ms
134.76.249.204 20.406 ms 20.352 ms 20.323 ms
stud9.stud.uni-goettingen.de (134.76.60.86) 20.806 ms 20.758 ms \
20.730 ms
Die erste Spalte gibt die ‘Entfernung’ an, also der wievielte Knoten (Hop) in der Verbindung
der bezeichnete Rechner ist. Dies entspricht dem Eintrag im time to live Feld des Datagramms, das vom angegebenen Rechner als expired gemeldet wurde. Der nächste Eintrag
ist der Rechnername (falls dieser anhand der IP-Adresse herausgefunden werden kann) und
dessen IP-Adresse. Dann kommen drei Einträge mit den Antwortzeiten für drei aufeinanderfolgende Datagramme an diesen Rechner. Der erste Punkt in der Verbindung ist also
der Rechner gw. Seine Antwortzeiten sind sehr kurz, die Verbindung ist ein lokales Ethernet. Der nächste Router ist gw.uts - von dort kommen die Datagramme sehr viel langsamer
zurück als von gw. Der Grund ist hier eine sehr langsame Verbindung über eine Funkstrecke.
Der nächste Knoten ist bereits der gesuchte Rechner, minnie.vk1xwt. Auch hier kommen
die Antworten nur sehr langsam. Dies liegt aber daran, dass die Antwortzeit jedes Rechners
natürlich die Summe der Verbindungszeiten aller dazwischenliegenden Teilstrecken ist. In
diesem Falle also vom eigenen Rechner zu gw; von dort zu gw.uts; und schließlich von gw.uts
zu minnie.vk1xwt. Berücksichtigt man diese Aufsummierung der Zeiten, so sieht man, dass
die letzte Verbindung von gw.uts zu minnie.vk1xwt ebenfalls sehr schnell ist. Diese beiden
Rechner hängen also vermutlich auch an einem lokalen, schnellen Netzwerk.
Taucht bei einem traceroute Aufruf hinter den Zeiten ein !N auf so weist dies auf ein
nicht erreichbares Netzwerk hin. Es ist ein Zeichen dafür, dass ein Router nicht wußte, wohin
er das Datagramm weiterleiten soll. Er sendet dann ein network unreachable Datagramm
an den Absender zurück. Meist deutet es darauf hin, dass eine Netzverbindung (zeitweise)
zusammengebrochen ist. Anhand der letzten angegebenen Adresse vor dieser Fehlermeldung
kann man die defekte Stelle lokalisieren.
Ebenfalls auftauchen kann ein !H als Hinweis darauf, dass ein Rechner (Host) nicht
erreicht werden konnte. Dies bedeutet i.A. dass man bis in das lokale Netzwerk des Zielrechners gelangt ist, dieser sich aber nicht meldet (weil er z.B. abgeschaltet ist).
15.4.2
Netzwerküberwachung
netstat, tcpdump, ethereal, nmap, ntop, iptraf, xnetload, arpwatch, fping, ipgrab
tcpdump kann die gesamte Aktivität auf dem Netzwerk überwachen indem es sämtlich
Datagramme auf dem Weg in den eigen Rechner hinein oder heraus abhört. Damit lassen
sich vom erfahrenen Administrator auch schwer zu identifizierende Netzwerkprobleme lokalisieren. tcpdump dekodiert jedes abgefangene Datagramm und zeigt es - in einer etwas
kryptischen Form - als Text an. tcpdump bietet sich an, um Protokollfehler oder plötzliche
Verbindungsabbrüche aufzuspüren. Denn man kann damit sehen, was auf dem Netzwerk
passiert. Um es jedoch sinnvoll einsetzen zu können, bedarf es eines tieferen Verständnisses der Protokolle und wie sie arbeiten. Doch es kann auch einfach dazu benutzt werden,
um sicherzustellen, dass z.B. Datagramme den eigenen Rechner wirklich über die richtige
Schnittstelle verlassen oder, um zu überprüfen, ob irgendwelche Datagramme von außerhalb
empfangen werden. Eine typische Ausgabe von tcpdump sieht etwa so aus:
test2:/root # tcpdump -i eth0
tcpdump: listening on eth0
18:25:50.646507 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\
77:52
230
KAPITEL 15. WICHTIGE NETZWERKKOMMANDOS
pathcost 0 age 0 max 20 hello 2 fdelay 15
18:25:52.649154 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\
77:52
pathcost 0 age 0 max 20 hello 2 fdelay 15
18:25:54.648119 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\
77:52
pathcost 0 age 0 max 20 hello 2 fdelay 15
18:25:56.650810 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\
77:52
pathcost 0 age 0 max 20 hello 2 fdelay 15
18:25:58.182266 132.230.9.254 > OSPF-ALL.MCAST.NET: OSPFv2-hello 44: rtrid 132.\
230.200.141
backbone dr 132.230.9.254 [ttl 1]
18:25:58.183882 randy2.rz.uni-freiburg.de.32895 > dns0.fun.uni-freiburg.de.domain:
25558+ PTR? 254.9.230.132.in-addr.arpa. (44) (DF)
18:25:58.186580 dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895:
25558 NXDomain* 0/1/0 (137)
18:25:58.187051 randy2.rz.uni-freiburg.de.32895 > dns0.fun.uni-freiburg.de.domain:
25559+ PTR? 5.0.0.224.in-addr.arpa. (40) (DF)
18:25:58.189666 dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895:
25559 1/4/4 PTR [|domain]
18:25:58.207177 randy2.rz.uni-freiburg.de.32895 > dns0.fun.uni-freiburg.de.domain:
25560+ PTR? 141.200.230.132.in-addr.arpa. (46) (DF)
18:25:58.210175 dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895:
25560 NXDomain* 0/1/0 (141)
18:25:58.210747 randy2.rz.uni-freiburg.de.32895 > dns0.fun.uni-freiburg.de.domain:
25561+ PTR? 200.200.230.132.in-addr.arpa. (46) (DF)
18:25:58.213119 dns0.fun.uni-freiburg.de.domain > randy2.rz.uni-freiburg.de.32895:
25561* 1/2/2 (173)
18:25:58.649731 802.1d config 8000.00:20:da:e7:77:52.8087 root 8000.00:20:da:e7:\
77:52
pathcost 0 age 0 max 20 hello 2 fdelay 15
14 packets received by filter
0 packets dropped by kernel
Wenn tcpdump ohne Argumente gestartet wird, wird das Netzwerk-Device mit der kleinsten Nummer, das kein Loopback-Device ist, überwacht. Es kann aber - wie im Beispiel auch ein spezielles Device angegeben werden. tcpdump dekodiert dann jedes Datagramm
das über diese Device übertragen wird und zeigt es in einer lesbaren Form an. Der erste
Eintrag ist - wie leicht zu ersehen - der Zeitpunkt, zu dem das Datagramm gesendet oder
empfangen wurde. Der weitere Inhalt der Zeile hängt dann von der Art des Datagramms ab.
Die ersten beiden Zeilen im Beispiel zeigen, einen arp request. tcpdump gibt dabei auch die
genaue Art des icmp Datagramms an. Das Größer-Zeichen (¿) gibt die Richtung an, in der
das Datagramm übermittelt wurde (es zeigt vom Sender zum Empfänger). Die restlichen
Zeilen protokollieren den Aufbau einer telnet Verbindung von albert.vk2ktj zu gw.vk2ktj
Die Zahl am Ende jeden Rechnernamens gibt die verwendete Socket Nummer an, zu
diesem Zweck wertet tcpdump die Datei /etc/services aus.
Beispiel:
tcpdump -i eth1 host 1.2.3.4 and not port ssh
Zwei Kommandos spielen mit tcpdump zusammen: Wenn man mit tcpdump -w capture.log ein Logfile in einem speziellen Binärformat geschrieben hat, kann man dieses
später mit tcptrace oder tcpflow auswerten. Beispiel: tcptrace -n -r capture.log >
session.file
Kapitel 16
Netzwerküberwachung
16.1
Überblick
Inzwischen ist der Rechnerarbeitsplatz in Firmen und Organisationen zum Standard avanciert. Viele Dienste, wie der Druck- oder Fileserver, die Firewall, der Mail- und Webserver
werden üblicherweise auch in kleineren Firmennetzwerken angeboten. Die Zahl der Maschinen hat damit einen so großen Umfang angenommen, dass sich nicht mehr durch einfaches
”Draufgucken” ihre vielfältigen Aufgaben überwachen lassen.
Mit diesem Wachstum der LANs (Local Area Networks) entsteht die Notwendigkeit sich
einen schnellen und umfassenden Überblick über den Zustand eines Netzes und der angeschlossenen Maschinen verschaffen zu können. Deshalb existieren inzwischen einige, teilweise
konkurrierende Protokolle zur Überwachung von Workstations und aktiven Netzwerkkomponenten. Das am häufigsten verwendete Verfahren zur Überwachung und Konfiguration
eingesetzter Komponenten ist das Simple Network Management Protocol (SNMP).
Eine Reihe ernsthafter Leute hat sich eine Reihe wichtiger Gedanken für ein ernsthaftes
Problem gemacht und SNMP erfunden: Wie kann eine Organisation Hunderte oder Tausende (wenn nicht noch mehr) aktiver Netzwerkkomponenten und Maschinen sowie das
zugrunde liegende Netzwerk beobachten und steuern?
SNMP basiert auf der TCP/IP Protokoll-Suite. Es etabliert durch seine starke Standardisierung ein einheitliches Modell zur Kontrolle und Verwaltung von Netzwerken. Ein
wesentlicher Vorteil dieses Protokolls liegt neben seiner weiten Verbreitung in der flexiblen
Erweiterbarkeit. SNMP erlaubt die schnelle und einfache Übertragung von Datenpaketen
zur Zustandsbeschreibung von Netzwerkgeräten. Jedoch genügt es in einigen Fällen nicht,
festzustellen, dass ein bestimmter Dienst aktiv ist, indem man überprüft, ob der entsprechende Prozess in der Liste laufender Programme auftaucht. Es geht nicht darum, eine
Innenansicht einer Maschine festzustellen, sondern den Zustand zu überprüfen, wie er sich
aus Sicht des Benutzers darstellt. Vielfach ist erst dann eine Aussage sinnvoll, wenn ein
Testzugriff über das Netzwerk erfolgreich durchgeführt wurde. Für diese Art des Monitoring bieten sich Web-, FTP- und Mailserver sowie Authentifizierungsdienste an, da nur so
eine Nutzbarkeit aus Sicht des Users emuliert werden kann.
16.2
SNMP - Das Simple Network Mangement Protocol
16.2.1
Überblick
Das Konzept von SNMP beinhaltet eine verteilte Management Architektur. Das Managementproblem wird in zwei Teile aufgespalten und es werden für jeden Teil separate Stan231
232
KAPITEL 16. NETZWERKÜBERWACHUNG
dards definiert. Der erste Teil befaßt sich mit dem Austausch von Informationen. SNMP
basierende Netzwerkmanagementlösungen arbeiten im Client-Server-Modell. Anwendungen
welche zum Sammeln von Daten oder zur Steuerung von Geräten dienen, werden Agenten
genannt. Der Management Host kann diese Daten von den Agenten abfragen. Das Protokoll
bestimmt zum einen, wie die Client-Software funktioniert und die Austauschformate zwischen Management Host und Agenten aussehen, sowie die Form der Namen und Adressen.
Zum zweiten wird festgelegt, welche Daten ein gemanagtes Gerät vorhalten muss, wie diese
benannt sind und welche Syntax zum Ausdruck bestimmter Werte und Zustände verwendet
wird. SNMP verfolgt einen minimalistischen Ansatz: Das Set der zugelassenen Operationen
ist sehr beschränkt, ein paar Befehle verschaffen die gesamte Funktionalität.
SNMP wurde von der IETF in etlichen RFC’s standardisiert (ua. 1155, 1157, 1212,
1213, 1441-46, 1450). Hierin wurde festgelegt, dass SNMP mittels des verbindungs- und
quittungslosen Unified Data Protocol (UDP) kommuniziert. Der Austausch zwischen Agent
und Monitor erfolgt dabei standardmäßig auf Port 161. Die Management Station kann Daten von den zu überwachenden Agenten (zyklisch) pollen, welche als Server fungieren. Die
MIB-Informationen können dann grafisch aufbereitet, dargestellt oder anders verarbeitet
werden. Die Host sind jedoch auch in der Lage, gewisse Ereignisse mittels sogenannter Traps
(”Falltüren”) an die Management Station über Port 162 zu melden. Der Informationsaustausch zwischen den Agenten und dem Überwachungs-Client läuft im Hintergrund ab und
versucht die Netzwerkbelastung gering zu halten.
SNMP liegt inzwischen in der dritten Version (SNMPv3) vor, jedoch sind die Unterschiede zu den Vorgängern gering und die meisten Befehle und Strukturen abwärts kompatibel.
16.3
Die Datendefinition
Ein überwachtes Objekt muss bestimmte Zustands- und Kontrolldaten vorhalten, da sie
vom Manager abgefragt werden können. Dazu gehören bei Routern sicherlich die Routingtabellen, sowie einkommender und ausgehender Datenverkehr. Switches werden bestimmte
Portstatistiken zu transferierten Paketmengen und dabei aufgetretenen Fehlern vorhalen;
ein Drucker kann die Zahl der ausgeworfenen Seiten und die Länge der Druckerwarteschlange bereithalten. Obwohl dem Manager der Zugriff auf diese Daten erlaubt wird, sagt SNMP
nichts Genaueres darüber aus, welche Informationen auf welchem Gerätetyp erhältlich sind.
Stattdessen definiert ein weiterer Standard die Details. In der Management Information Base (MIB) werden die Informationen vermerkt, sowie welche Bedeutung sie haben, welche
Operationen auf ihnen ausgeführt werden können und welche Werte sie annehmen können.
So hat ein Paketzähler für einen Switchport einen Integerwert, der nur lesbar ist und nicht
verändert werden kann. Eine Variable, die den Zustand desselben Ports beschreibt (ob dieser
ein- oder abgeschaltet ist) wird den Zustandswert enthalten und les-/schreibbar sein.
Der Vorteil MIBs unabhängig von SNMP zu definieren, liegt darin, dass Hersteller
von Netzwerkkomponenten neue Variablen einführen können. Ein Benutzer kann dieselbe
Netzwerkmanagementsoftware, wie für die bekannten MIBs verwenden. Natürlich wird kein
Gerät die Daten liefern, die in ihm unbekannten MIBs definiert sind. Trotzdem bleibt die
Sprache und das Protokoll von SNMP gleich.
Zu Zeiten von SNMPv1 und v2 waren alle Daten in einer einzigen MIB festgelegt.
SNMPv3 erlaubt verschiedene MIBs zu definieren. In der System-MIB (MIB-II) sind grundlegende Verwaltungsdaten abgelegt, wovon einige in der Tabelle gezeigt sind. Die MIB-II
wird von den meisten Herstellern unterstützt. Darüberhinaus definiert jeder Anbieter von
netzwerkfähiger Hardware weitere MIBs, z.B. die Host-MIB (MIB für Endgeräte).
16.3. DIE DATENDEFINITION
MIB
system
interfaces
ip
tcp
udp
snmp
host
233
Informationen zu/über
Überwachtes Gerät, Standort, Eigentümer, Software, Uptime, Ansprechpartner ...
Eingebaute reale und virtuelle Netzwerkinterfaces: Mehrere bei
Routern und Switches, meistens eines bei Rechnern, Druckern ...
IP-Daten, wie Routingtabelle, Paketzähler ...
TCP-Daten, wie offene Verbindungen, Paketzähler
UDP-Daten, wie offene Ports, Paketzähler
Statistiken und Zähler des SNMP-Agenten
Statistiken und Daten klassischer Workstations, wie Speicher,
Festplatten, Zahl der Nutzer ...
Tabelle 16.1: Einige Standard-MIBs
16.3.1
Der SNMP-Namensraum und die Management Information Bases
Der SNMP-Datenraum ist großzügig und universell erweiterbar angelegt. Große Teile sind
für zukünftige Ergänzungen reserviert und für die evtl. Migration mit anderen baumartigen
Datenstrukturen freigehalten.
Ein weiterer Standard definiert das Regelwerk zum Festlegen und Identifizieren der MIB
Variablen. Dieses grundlegende Format heißt SMI (Structure of Management Information).
Um das Protokoll einfach zu halten, legt SMI einige Restriktionen zu den in den MIBs
erlaubten Variablen fest, bestimmt deren Benennung und die Definition von Variablentypen. Hierzu gehören z.B. der Zähler (Counter, Integervariable im Bereich von 0..23̂2-1)
oder die IP-Adresse (4 Oktets). Die Datentypen können wiederum zu Tabellen oder Folgen
kombiniert werden.
Zur Bennenung der MIB-Variablen und deren Referenzierung verwendet SMI den ASN.1Standard (Abstract Syntax Notation der ISO). Dieses ist eine formale Sprache mit zwei
Ausprägungen: Einem kompakten maschinen-lesbaren Teil für die Verwendung im Kommunikationsprotokoll und einer für Menschen lesbaren Form der Daten zur Beschreibung
in Dokumenten. ASN.1 fordert dabei eine sehr hohe Präzision (z.B. die Angabe des Wertebereichs einer Variablen), um eine gute Interoperabilität zu gewährleisten.
Die Variablen der MIBs sind in einer baumartigen Struktur abgelegt, dem Object Identifier Namespace, welcher von ISO und ITU verwaltet wird. Der Aufbau ähnelt ein wenig dem
vom Domain Name System oder Dateisystemen bekannten. Der Namensraum ist global, d.h.
alle eingetragenen Zweige sind eindeutig. Subnamensräume können jedoch delegiert werden,
so dass nicht jeder neue Eintrag bei den o.g. Organisationen beantragt werden muss.
Die Wurzel des Bauses ist unbenannt, danach folgen die managenden Organisationen
(ISO, ITU und ISO+ITU gemeinsam). Das Trennzeichen zwischen den Hierarchieebenen
ist der Punkt. Angesprochen werden kann jeder Host über eine Nummer, wobei zur Vereinfachung des Zugriffes auch Namen erlaubt sind. Diese dienen jedoch wie beim DNS eher
der Bequemlichkeit; sie sind keine Eigenschaften des Hierarchiebaumes und werden nicht
bei der Client-Server-Kommunikation verwendet.
Der für SNMP interessanteste Teil des Namensraums wird mittels der sogenannten
MIBs aufgespannt. Sie definieren die unterschiedlichen Daten-Domains, die mittels SNMP
abgefragt werden können. Sie beinhalten das Schema der abfragbaren Informationen und
die Übersetzung der OIDs in ihre jeweiligen Namen. Dabei sind die obersten Ebenen
des Datenbaumes für die Definition der Berechtigungen an einzelne Gruppen reserviert.
Der spannendere Abschnitt des SMI-Baumes startet mit OID 1.3.6.1, welcher den Namen
234
KAPITEL 16. NETZWERKÜBERWACHUNG
”iso.org.dod.internet” trägt. Hier finden sich die System-, Interface-, TCP/IP, hostspezifische und weitere (herstellerdefinierte) MIBs.
Ansehen kann man sich die MIBs mit einem Texteditor, komfortabel wird es jedoch
erst mit grafischen Tools. Cheops und TKined haben eingebaute Funktionen um MIBs
zu visualisieren, richtig komfortabel wird es mit Mbrowser (siehe [7]), welcher auf NetSNMP aufsetzt und ein GTK-GUI verwendet. Mit mbrowser lassen sich auch die StandardSNMP-Kommandos, wie get, set, walk absetzen, die weiter unten in ihrer Kommandozeilenausführung besprochen werden.
16.3.2
Die SNMP-Agenten
Jeder einzelne Knoten im Netz - Netzwerkkomponenten oder auch Endgeräte, welche sich
mittels SNMP verwalten lassen, verfügen über einen Management Agenten. Dieser stellt Informationen in strukturierter Form zur Verfügung. Anhand dieser erfolgt die Überwachung
und Konfiguration des jeweiligen Gerätes. Die Datenstruktur wird als Management Information Base (MIB) bezeichnet. Die Agenten sind üblicherweise als Softwarelösung in den
Netzknoten und Endgeräten umgesetzt. Diese Implementation erfolgt bei den Anbietern
aktiver Netzwerkkomponenten meistens herstellerspezifisch. Auf einer Linux- bzw. UnixWorkstation stehen dafür mehrere Implementationen zur Verfügung. Die Lösungen reichen
von C++-Implementationen, wie dem Open-SNMP, die in C geschriebene Toolsuite des
CMU bzw. Net-SNMP, Bibliotheken die TCL/TK zu Grunde legen, wie ”scotty” bis hin zu
Java- oder Perl-basierten Umsetzungen. Ihre Funktionalität unterscheidet sich in den von
den Agenten unterstützten MIBs sowie den Werkzeugen zur Erlangung und Visualisierung
der Daten.
16.3.3
Der Kommunikations-Code der Agenten
Nun sind die Datentypen und die Struktur der zur Verfügung stehenden Daten definiert.
Jetzt sollen diese zwischen dem Agenten und dem Management System ausgetauscht werden. Hierzu sind vier grundlegende Operationen und ihre Erweiterungen definiert:
Jede Bitte um einen Satz von Daten muss einen vollständigen Pfad für die erwünschte
Information beinhalten. Das Schreiben und Lesen von Feldern auf einem Knoten der SMIHierarchie erfolgt mit set und get. Mittels get-next lassen Tabelleninformationen schrittweise anfordern. Die Berechtigung zum Lesen bzw. Schreiben der einzelnen OIDs erfolgt bei
SNMPv1 bzw. v2 mittels ”Communitystring” und die Angabe der zum Lesen berechtigten
Hosts oder Netzwerke.
Die Funktion ”set” ist nicht ganz unkritisch, da es die eine Steuerung von Geräten
erlaubt, wie z.B. das Abschalten von Ports auf Switches oder Routern. Dieses ist jedoch
unter Sicherheitsaspekten nicht unproblematisch, da die Daten meistens unverschlüsselt
übertragen werden und erst die Spezifikation von SNMPv3 komplexere Authentifizierung
erlaubt.
Eine Trap (Kommando trap) geht den umgekehrten Weg. Sie erlaubt es Benachrichtigung unabhängig von einer Anfrage des Clients an diesen zu übermitteln. Dieses kann
für das Auftreten bestimmter Ereignisse oder Bedingungen festgelegt werden, läßt sich jedoch nicht für beliebige Felder definieren. Standard-Traps sind z.B. die Information zum
Start des Servers, Traps, die Ausfälle oder Wiederbelebungen von Netzwerkverbindungen
kundgeben und einige Authentifizierungsprobleme. Der Mechanismus zur Definition von
Trap-Nachrichten hängt von der jeweiligen Server-Implementierung ab. Switches und Router kennen andere und meistens weitaus mehr verschiedene Traps als Endgeräte, die jedoch
16.4. SNMP-IMPLEMENTIERUNGEN UNTER LINUX
235
meistens nicht genormt sind. Auf einer Linux-Workstation ist es schließlich einfacher andere
Konzepte als SNMP-Traps zur Behandlung von Ausnahmesituationen umzusetzen.
16.4
SNMP-Implementierungen unter Linux
Wie bereits kurz erwähnt stehen unter Linux einige Implementierungen von SNMP zur
Verfügung. Jedoch soll sich der Artikel auf die aus Sicht des Autors beste und vollständigste Umsetzung beziehen: Net-SNMP. Nachdem die Entwicklung des bisher im Linuxumfeld
recht weit verbreiteten Paketes der Carnegie Mellon University (CMU) etwas eingeschlafen
ist, genießt das Projekt ”Net-SNMP” zunehmende Beachtung. Es ist aus einem Projekt
der University of California in Davis hervorgegangen. Das Paket steht unter der GPL und
kann über die Projekthomepage (siehe [] netsnmp.org) bezogen werden. In den meisten
Fällen wird man es nicht mehr selbst kompilieren müssen, da es Bestandteil vieler Linuxdistributionen ist. Gründe es selbst zu übersetzen, könnten in notwendigen Bugfixes oder
experimentellen neuen Features liegen.
Das Net-SNMP-Paket beinhaltet eine C-Bibliothek mit den wesentlichen Funktionen,
den Agenten (SNMP-Server, d.h. snmpd) und Programme zur Datenbeschaffung, welche
die vier Standardkommandos ”get”, ”get-next” und ”trap” enthalten. Die Syntax und die
Namen der Standardkommandos sind festgelegt, die der von verschiedenen SNMP-Paketen
mitgelieferten Programme jedoch nicht! Bei der Vorstellung des Monitoring-Tools Nagios
im zweiten Teil sieht man, das dieses eine eigene SNMP-Umsetzung mitbringt. Auch Programm MRTG zur Darstellung der Auslastung von Netzwerkinterfaces (siehe []) beziehen
ihre Daten vom SNMP-Agenten, verwenden aber die Aufrufe aus ihrer eigenen Bibliothek.
Net-SNMP implementiert die Funktionalität von SNMPv3 und is modular mittels AgentX
erweiterbar.
16.5
Kommandos zur Datenbeschaffung
Das Beste zum Ausprobieren der verschiedenen SNMP-Kommandos ist eine Maschine oder
Netzwerkkomponente im eigenen Subnetz. Der ”Communitystring” zur Authentifizierung
gegenüber dem Agenten sollte bekannt und die eigene IP-Nummer als zugelassen auf der
entsprechenden Maschine eingetragen sein. Handelt es sich beim beobachteten Gerät um
einen Net-SNMP-Agenten, werden diese Informationen im Bereich [A]-[D] (siehe Beispiel
weiter unten) der Konfigurationsdatei angegeben.
snmpget target-host community sysDescr.0
liefert z.B. die Beschreibung des Gerätes:
system.sysDescr.0 = 3Com SuperStack II
snmpget target-ip community .1.3.6.1.2.1.1.1.0
liefert das identische Ergebnis.
Die Kommandos von Net-SNMP gehorchen dabei folgender Syntax:
Programmname [Optionen...] <hostname> {<community>} [<OID> ...]
Die Object ID kann immer als Nummer und so als Definition in einer installierten MIB
angegeben, als Name angegeben werden. Mittels der Optionen lassen sich die SNMP-Version
(1,2 oder 3) für die Anfrage angeben sowie Spezifika für einzelne Versionen setzen. Daüberhinaus kann bestimmt werden, wie die Ein- und Ausgabe und die Darstellung der MIB
formatiert werden soll oder Debuginformationen generiert werden. Snmpget, snmpgetnext
und die abgeleiteten Tools wird man selten direkt einsetzen. Sie eignen sich für Tests und
236
KAPITEL 16. NETZWERKÜBERWACHUNG
einfache Shellskripten. Für die visuelle Darstellung z.B. der Auslastung einzelner Ports eines
Linuxrouters oder eines Switch kommt MRTG (Multi Router Traffic Grapher, siehe Kap.
16.8) in Frage, da hier neben dem momentanen Zustand auch Zeitreihen gut darzustellen
sind.
Mit dem Programm snmptranslate läßt sich vergleichbar mit ”nslookup” im Domain
Name System eine Übersetzung zwischen Nummer und Name auslesen. Darüberhinaus bekommt man weitere Informationen, z.B. eine Beschreibung der Variablen und ihren Typ
angezeigt.
Kasten:
Ausgabe des Kommandos ”snmptranslate -Td -OS system.sysDescr”
.1.3.6.1.2.1.1.1
sysDescr OBJECT-TYPE
-- FROM SNMPv2-MIB,
RFC1213-MIB
-- TEXTUAL CONVENTION
DisplayString
SYNTAX OCTET STRING
(0..255)
DISPLAY-HINT
"255a"
MAX-ACCESS
read-only
STATUS
current
DESCRIPTION
"A textual description of the entity. This value should
include the full name and version identification of the
system’s hardware type, software operating-system, and
networking software."
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) 1 }
Programme, wie snmpnetstat, snmpstatus oder snmpdf vereinfachen wichtige Standardanfragen, z.B. nach offenen TCP-Verbindungen und UDP-Ports, dem Gerätetyp und seinen Interfaces oder dem freien Speicherplatz. Hier sind im Gegensatz zu snmpget, snmpgetnext, snmptable keine OIDs anzugeben.
Da es recht aufwändig ist, sich mittels snmpget oder snmpgetnext einen umfassenden
Überblick über den Baum verfügbarer Daten eines Endgerätes oder Netzwerkknotens zu
verschaffen, bringt snmpwalk Erleichterung. Dieses Programm erlaubt es den gesamten
Datenbaum eines Agenten sukzessive abzufragen oder Unterbäume vollständig abzulaufen.
Letzteres geschieht über die Angabe eines Teils des OID. Je länger der Object Identifier
wird, desto genauer wird der abzufragende Teil des Baumes eingegrenzt und kürzer wird
die Ausgabe.
16.6
Konfiguration des UCD-SNMP
16.6.1
Der Kopf definiert die Zugriffs-Policies
Der Server ”snmpd”, welcher als Softwareagent auf der zu beobachtenden Maschine läuft
wird mittels /etc/ucdsnmpd.conf gesteuert und üblicherweise durch ein Runlevel-Skript in
/etc/init.d gestartet.
Die ersten vier Abschnitte ([A]-[D]) der Konfigurationsdatei dienen der Authentifizierung, wobei jeweils zu überlegen ist, welche Hosts welche Daten pollen dürfen. In den
meisten Fällen genügt eine Beschränkung auf das lokale Subnetz, wobei jedoch auch ausschließlich die Management Station (also der Rechner, von dem die Überwachung läuft)
eingetragen werden kann. Der Agent kann mehrere unterschiedliche Access-Regeln definieren. Eine solche Regel besteht aus einer MIB, die alle Bereiche der MIB enthält, auf welche
16.6. KONFIGURATION DES UCD-SNMP
237
ein Zugriff für die Nutzergruppe gestattet ist. Festgelegt wird weiterhin der Zugriffsmodus,
welcher im Beispiel für Anfragen aus dem Netzwerk nur lesend erfolgen darf.
Die Gesamtheit der Verwaltungsrechte wird in einem Community Profile zusammengefaßt. Anhand des vom Client mitgelieferten Community Passworts (hier immer mit ”community” bezeichnet) bestimmt der Agent, ob MIB Objekte für die aktuelle Anfrage sichtbar
sind oder modifiziert werden dürfen. Wird das eigene LAN als unsicher eingeschätzt, kann
eine Authentifizierung nach SNMPv3 eingestellt werden. Die Steuerung erfolgt mit den
Kommandos snmpusm für die Benutzer- und snmpvacm für Zugriffsrechteverwaltung. Jedoch sind Probleme mit Clients zu erwarten, welche nicht SNMPv3 beherrschen.
Ohne weitere Konfiguration stellt Net-SNMP die meisten der üblichen Variablen der
Standard-MIB unter Linux zur Verfügung. Abschnitt [E] erlaubt das Setzen der Standardvariablen Location- und Kontakt OID. Wer einen näheren Blick auf die unterschiedlichen MIBs werfen möchte, kann unterhalb des Verzeichnisses /usr/share/mibs/(ietf ) bzw.
/usr/share/snmp/mibs nachsehen. Zum Standard gehören auch die Netzwerkinformationen
zu den konfigurierten Interfaces, Daten zu ARP, ICMP, TCP, jeweils inklusive der Anzahl
der transferierten Pakete in verschiedenen Kategorien.
16.6.2
Parameter der ”Enterprise”-Erweiterungen
Über den Standard hinaus schafft Net-SNMP eine Schnittstelle, festzustellen, ob bestimmte
Prozesse laufen. Die MIB befindet sich im ”Enterprises” Unterbaum (1.3.6.1.4.1) und wird
mit der ID 2021 als UCD-SNMP-MIB eingehangen. Die Prozesstabelle wiederum findet
sich unterhalb der ID 2, zusammengesetzt numerisch unterhalb 1.3.6.1.4.1.2021.2. In der
Konfiguationsdatei wird nach dem Schlüsselwort ”proc” das zu überwachende Programm
und dann die Zahl der minimal und maximal erlaubten Instanzen eingetragen werden.
Abgefragt werden kann diese Tabelle z.B. mit:
snmptable target-host community .1.3.6.1.4.1.2021.2
welches als Ausgabe in Abhängigkeit der gezeigten Konfigurationsdatei folgendes produziert:
SNMP table: enterprises.ucdavis.prTable
prIndex
prNames prMin prMax prCount
1 automount
2
2
2
2
X
1
2
1
3
kdm
1
1
2
4
ypbind
1
4
4
5
sshd
1
10
1
6
axnet
0
1
1
7
rwhod
0
1
1
8
cron
0
1
1
9
xinetd
0
1
1
10
chooser
0
1
0
16.6.3
Erweiterung durch externe Skripten und Programme
Abschnitt [G] beschäftigt sich mit einem speziellen, weil flexiblen Zweig des Unterbaumes
”enterprises.ucdavis” (hier 1.3.6.1.4.1.2021.8). Hier wird dem Agenten erlaubt ein externes
Skript auszuführen und das Resultat zurückzumelden. Dieser Bereich wird nicht fest vorgegeben, sondern kann vom Administrator in der Konfigurationsdatei definiert werden. Jede
weitere Zeile erzeugt einen weiteren Indexeintrag in die MIB-Tabelle.
snmpwalk target-host public enterprises.ucdavis.extTable.extEntry.extResult
238
KAPITEL 16. NETZWERKÜBERWACHUNG
liefert eine Ergebnisliste zurück, wobei die Ergebnisse die Shell-Variable des Rückgabewertes ($?) repräsentieren:
enterprises.ucdavis.extTable.extEntry.extResult.1 = 34
enterprises.ucdavis.extTable.extEntry.extResult.2 = 33
enterprises.ucdavis.extTable.extEntry.extResult.3 = 28
enterprises.ucdavis.extTable.extEntry.extResult.4 = 0
enterprises.ucdavis.extTable.extEntry.extResult.5 = 0
enterprises.ucdavis.extTable.extEntry.extResult.6 = 0
enterprises.ucdavis.extTable.extEntry.extResult.7 = 252
enterprises.ucdavis.extTable.extEntry.extResult.8 = 253
enterprises.ucdavis.extTable.extEntry.extResult.9 = 254
enterprises.ucdavis.extTable.extEntry.extResult.10 = 255
enterprises.ucdavis.extTable.extEntry.extResult.11 = 153
Dieses Ergebnis läßt sich auch mit dem Kommando ”snmpbulkget -v2c ...” erziehlen,
wobei mit der Option ”-v2c” eine Session nach SNMPv2c zwischen dem Client und dem
Agent generiert wird.
Die MIB (bzw. ein Teilzweig dieser) wurde im vorliegenden Fall dazu eingesetzt, externe
Shellskripten auszuführen, welche wiederum das /proc-Device des Kernels auslesen und
die evtl. erhaltenen Daten über den Returnwert zurückgeben. Die Erweiterung hier dazu
benutzt, Informationen des System Management Busses (SMB, spezieller Bus moderner
Mainboards zur Steuerung und Überwachung von Komponenten) zu CPU-Temperatur und
Drehzahl der verschiedenen Lüfter auszuwerten:
Listing des Bash-Skriptes:
# script for reading lm_sensor information from procfs to pass
# them via net-snmp
#
case "$1" in
*temp*)
EXIT=( ‘cat /proc/sys/dev/sensors/*/$1 2>/dev/null|| echo 20‘ )
EXIT3=${EXIT[2]}
EXIT=${EXIT3%.*}
if test ! $EXIT ; then EXIT=25 ; fi
;;
*fan*)
EXIT=( ‘cat /proc/sys/dev/sensors/*/$1 2>/dev/null|| echo 200‘ )
EXIT=${EXIT[1]}
;;
esac
exit $EXIT
Eine Einschränkung besteht jedoch im maximalen Return-Wert, welcher 255 nicht überschreiten kann. Vorsicht ist auch geboten, wenn man versucht, temporäre Daten auf der
Festplatte zwischenzuspeichern, da diese potentiellen Angreifern einen Einstieg erlauben
könnten. Den Weg der Daten bis zur Anzeige im Monitoring-Tool kann man sich so veranschaulichen:
16.7
Überwachung weiterer Parameter
Der anschließende Abschnitt ([H]) definiert das Verhalten eines weiteren Astes in der UCDSNMP-MIB. Mit den Object Identifiers diesen Bereiches läßt sich der verbleibende Festspeicherplatz nach Lage im Dateisystembaum beobachten. Der Zahlenwert definiert die untere
16.7. ÜBERWACHUNG WEITERER PARAMETER
239
Grenze, ab der eine Warnmeldung in die Ergebnistabelle eingetragen wird. Das nächste Beispielkommando liefert die z.B. prozentuale Belegung der als ”Rootfilesystem” gemounteten
Festplatte:
dirk@linux:~/kurs> snmpget target-host public .1.3.6.1.4.1.2021.9.1.9.1
enterprises.ucdavis.dskTable.dskEntry.dskPercent.1 = 37
Das Programm snmpgetnext kann man benutzen, um den zweiten Wert der Liste (die
prozentuale Auslastung von /tmp) zu erhalten. Auch [I] konfiguriert einen Unterbaum
der UCD-SNMP-MIB: Die LoadTable (1.3.6.1.4.1.2021.10). Die Ganzzahlwerte nach dem
Schlüsselwort geben die Maximalwerte an, bis zu denen kein Warneintrag analog zur Dateisystembelegung generiert wird.
Die vorhergehenden Beispiele bezogen sich auf die Net-SNMP-Implementation, eine Zusammenarbeit mit anderen Komponenten ist natürlich angestrebt und klappt entsprechend.
Z.B. lässt sich mit dem Befehl:
dirk@linux:~/kurs> snmpset 10.10.1.1 private interfaces.ifTable.ifEntry.
ifAdminStatus.101 i down
der Port Nummer 1 auf einer 3COM SuperStack3 abschalten. Analog funktioniert dieses
auch mit einem Cisco C3500X, wobei die Portnummern hier von 1 - n durchnummeriert
sind (n statt 101, wie im obigen Beispiel).
16.7.1
Weitergehende Ergänzungen
Wem die einzeilige Ausgabe nur des Rückgabewertes in Abschnitt [G] nicht genügte, findet seine Vorstellungen evtl. in [J] gelöst. Mit diesem MIB-Bereich ist es möglich mehrzeilige Ausgaben zuzulassen, die als entsprechende Tabelleneinträge zurückgeliefert werden. In der Beispielkonfigurationsdatei werden die OIDs (1.3.6.1.4.1.2021.51 - 53) definiert.
Diese generieren verschiedene Ausgaben zur Hardwareausstattung und angemeldeten lokalen Benutzern der Maschine aus dem Aufruf von externen Programmen. Auf diese Weise
kann Informationsbeschaffung auf SNMP abgebildet werden, welches dann ein Einloggen
auf dem Zielsystem unnötig macht. Eine Konfigurationszeile ist so aufgebaut, dass nach
dem Schlüsselwort ”exec” die OID des Objektes angegeben wird, gefolgt vom Namen des
Objekts, dem Aufruf des korrespondierenden externen Programms oder Skriptes inklusive
eventueller Optionen.
Eine ganze Reihe weiterer Laufzeitinformationen ließe sich auf diesem Wege beschaffen.
Jedoch gibt es einige Einschränkungen bezüglich der verwendeten Datenfelder (nur TextFelder oder Return-Codes bis zum maximalen Wert von 255 sind erlaubt), so dass nach
einer Testphase (z.B. der Auswertung der Meldungen des SMB) über eine feste Einbindung
als Modul nachgedacht werden sollte. Eine Anleitung, wie ein Modul für den UCD-SNMP
zu schreiben ist und wie die dazugehörige MIB designt werden muss, findet sich auf der
Projekt-Homepage.
In der Tutorial-Sektion findet sich die Beschreibung eines Toolkits, welches das Programmieren eigener Erweiterungen mittels C erlaubt. Enthalten sind in der Schritt-fürSchrittanleitung ein Makefile, der Beispiel-Code einer SNMP-Applikation und eine TutorialMIB mit Headerdatei und eine C-Sourcedatei. Header und C-Source sind zum größten Teil
mit mib2c erstellt worden, was einen guten Ausgangspunkt für eigene Versuche liefert. Beim
Neuübersetzen des Agenten kann das experimentelle Modul eingefügt werden.
Auf diesem Wege könnte der Umweg über das oben beschriebene Shellskript zugunsten einer festen Implementierung abgelöst werden. Damit würden sich weiterhin die Beschränkungen der Variablen aufheben lassen, da man deren Deklaration mittels MIB selbst
in der Hand hat.
240
KAPITEL 16. NETZWERKÜBERWACHUNG
16.7.2
Parameter der Host-Ressource-Erweiterungen
Wurden die SNMP-Bibliotheken und der Agent mit der Unterstützung für die HOSTRESOURCES-MIB übersetzt, stehen weitere Informationen zur Verfügung.
Unterhalb des Datenbaumes .1.3.6.1.2.1.25, wird diese MIB eingehängt und (unter der Voraussetzung, dass die Werte beschafft werden können) werden die Variablen ausgegeben.
Siehe Tabelle 14.4
Beispielkonfiguration, Listing von /etc/ucdsnmpd.conf:
# [A] Access Control
com2sec local
localhost
public
com2sec mynetwork 172.16.30.0/22 public
com2sec mynetwork 10.0.0.0/8
public
# [B]
group
group
group
group
group
group
Second, map the security names into group names:
MyRWGroup v1
local
MyRWGroup v2c
local
MyRWGroup usm
local
MyROGroup v1
mynetwork
MyROGroup v2c
mynetwork
MyROGroup usm
mynetwork
# [C] Third, create a view for us to let the groups have rights to:
view all
included .1
# [D] Finally, grant the
# write permissions:
#
context
access MyROGroup ""
access MyRWGroup ""
2 groups access to the 1 view with different
sec.model sec.level match
any
noauth
exact
any
noauth
exact
# [E] System contact information
syslocation Internet-AG Universitaet Goettingen
syscontact <dirk@goe.net>
# [F] Process checks.
proc automount 2 2
proc X 2 1
proc kdm 1 1
proc ypbind 4 1
proc sshd 10 1
proc axnet 1 0
proc rwhod 1 0
proc cron 1 0
proc xinetd 1 0
proc chooser 1 0
# [G] Executables/scripts
exec sensors /bin/sh /usr/share/snmp/sensors
exec sensors /bin/sh /usr/share/snmp/sensors
exec sensors /bin/sh /usr/share/snmp/sensors
exec sensors /bin/sh /usr/share/snmp/sensors
exec sensors /bin/sh /usr/share/snmp/sensors
exec sensors /bin/sh /usr/share/snmp/sensors
exec empty /bin/echo 252
exec empty /bin/echo 253
temp1
temp2
temp3
fan1
fan2
fan3
read
all
all
write
none
all
notif
none
none
16.8. MRTG ALS FRONTEND ZUR ANZEIGE VON ZEITREIHEN
241
exec empty /bin/echo 254
exec empty /bin/echo 255
exec user_activity /bin/sh /usr/share/snmp/uabic
# [H] disk checks
disk /
100000
disk /tmp 20000
# [I] load average checks
load 5 4 4
# [J] Extensible sections
exec .1.3.6.1.4.1.2021.51 users /usr/bin/who
exec .1.3.6.1.4.1.2021.52 pci_devices /sbin/lspci
exec .1.3.6.1.4.1.2021.53 cpuinfo /bin/cat /proc/cpuinfo
16.8
MRTG als Frontend zur Anzeige von Zeitreihen
Der Multi Router Traffic Grapher ist nun eine Anwendung, welche es ermöglicht auf Basis
von SNMP Netzwerkgeräte zu überwachen. Zur Visualisierung erzeugt MRTG HTML-Code.
In diesen Code werden PNG-Grafiken eingebunden, welche die Belastung einer bestimmten
Einheit (Netzwerkinterface, Zahl der Benutzer, Load der Maschine) visualisieren. MRTG
erzeugt diese Grafen fortlaufend mit jedem Aufruf des Programms.
Das Tool basiert auf einem Perl-Skript, das das Simple Network Management Protocol
(SNMP) benutzt, um die Daten von den Netzwerkkomponenten oder Endgeräten zu pollen.
Ein C-Programm protokolliert die Werte mit, um erzeugt daraus Auslastungsstatistiken und
Auslastunggrafen. In Ergänzung zur der detaillierten, täglichen Ansicht, erzeugt MRTG
Grafen, die den Duchsatz der letzten sieben Tage, der letzten vier Wochen und der letzten
zwölf Monate wiedergeben. Dies ist möglich, da MRTG allen Daten, die es aus dem Router
ausließt, in eine Log-Datei schreibt. Für die Beobachtung längerer Zeiträume bietet sich
eine Kombination mit dem RRD-Tool an. Dieses ist eine spezielle Datenbank, welche ihre
Einträge im Round-Robin-Verfahren speichert.
MRTG speichert die Informationen über die zu üeberwachenden Systeme in der Datei
mrtg.cfg. In dem MRTG-Paket befindet sich ein Perl-Skript, welches das Erzeugen einer
Konfigurationsdatei erheblich vereinfacht: cfgmaker. Falls man MRTG selbst übersetzt
hat, findet man cfgmaker in dem Unterverzeichnis ./run. Ein Aufruf zur Erzeugung der
Konfigurationsdatei könnte so aussehen:
cfgmaker --global ’WorkDir: /www/mrtg’ --output /etc/mrtg.cfg --global \
’Options[_]: bits,growright’ <community>@<target-host.domain>
Listing einer Beispielkonfigurationsdatei mrtg.cfg:
######################################################################
# Multi Router Traffic Grapher -- Sample Configuration File
######################################################################
# This file is for use with mrtg
# Global configuration
WorkDir: /var/www/mrtg
WriteExpires: Yes
Title[^]: Traffic Analysis for
242
KAPITEL 16. NETZWERKÜBERWACHUNG
# 2048kBit leased line
# ---------------#Title[leased]: a 2048kBit leased line
#PageTop[leased]: <H1>Our 2048kBit link to the rest of the internet</H1>
#Target[leased]: 1:public@router.my.domain
#MaxBytes[leased]: 200000
16.9
Einige abschließende Worte zu SNMP
Während SNMP recht einfach und flexibel einzusetzen ist, hat es jedoch auch einige Nachteile. Das Sicherheitsmodell der Version 1 und 2 ist schwach. Verwendet man SNMP zum
Setzen von Variablen kann leicht etwas schief gehen, so dass man z.B. den Switchport
abschaltet über den man mit dem Netzwerk verbunden ist. Schwierig wird es auch aufkommende objektorientierte Ansätze, wie die Beschreibung mittels XML in SNMP umzusetzen.
SNMP war lange Zeit die Spezialität weniger Netzwerkadministratoren und Programmierer,
so dass das Wissen darüber immer noch nicht sehr weit verbreitet ist. Inzwischen wurde
die erdrückende Vormacht der Kommandozeile durch eine Reihe grafischer Erweiterungen
aufgelöst, so dass auch SNMP-Neulingen ein zügiger Einstieg gelingen kann.
Trotz der genannten Probleme ist SNMP aus Sicht des Autors das beste Protokoll
zur Netzwerküberwachung. Es ist universal, bandbreitenschonend und wirklich plattform
unabhängig. Die Hersteller von Netzwerkkomponenten setzen weiterhin auf SNMP, alle
neuen Gerätetypen die herauskommen, wie z.B. Access-Points für Wireless LAN, verfügen
über eine entsprechende Schnittstelle. SNMP in der dritten Version, wie es vor einiger
Zeit spezifiziert wurde, erlaubt bessere Authentifizierungsverfahren und Verschlüsselung der
Daten. Darüberhinaus ist es mittels Modularisierung über Sub-Agenten flexibler geworden.
Die Popularität von Linux und die inzwischen mit Net-SNMP und anderen frei zur
Verfügung stehenden Implementationen haben ihren Betrag zur Verbreitung von SNMP erbracht. Alle großen Linux Distributionen enthalten eine ganze Reihe von SNMP Software,
mit der sich viele anstehende Probleme bereits lösen lassen. Ein attraktives Tool zur Visualisierung spezieller SNMP-Variablen, wie die Auslastung eines Endgerätes oder einzelner
Schnittstellen von Netzwerkknoten, wurde mit MRTG bereits vorgestellt. NetSaint, welches
neben anderen Überwachungsfunktionen SNMP zum Sammeln der Daten einbezieht, soll
im zweiten Teil dieses Artikels besprochen werden.
16.10
Weiterführende Literatur
[1] Homepage des Net-SNMP: http://netsnmp.sourceforge.net
[2] Scotty-SNMP-Bibliothek: http://wwwsnmp.cs.utwente.nl/ schoenw/scotty
[3] MRTG-Homepage: http://www.mrtg.org
[4] Projektbericht zur Überwachung großer Netzwerke an der Universität Göttingen http://www.stud.uni-goettingen.de/ dsuchod/dgsvgr
[5] Cheops der Klassiker: http://www.marko.net/cheops
[6] Cheops Next-Generation: http://cheops-ng.sourceforge.net
[7] MIB-Browser: http://goldplated.atlcartel.com/mbrowse.html
[8] Douglas E. Comer, TCP/IP
16.10. WEITERFÜHRENDE LITERATUR
OID
Standard-OIDs (MIBII)
system.sysDescr
Datentyp Beschreibung
system.sysLocation
system.sysUpTime
system.syscontact
system.sysName
text
int
text
text
interfaces.ifNumber
interfaces.ifTable
int
table
at.atTable
ip.ipforwarding
table
int
ip.ipAddrTable
table
icmp.*
tcp.tcpConnTable
int
table
udp.udpTable
snmp.*
OIDs der UCD-SNMPMIB
prTable.*
table
int
memory.memTotalReal
int
extTable.*
table
laTable.*
int
systemStats.*
int
ucdExperimental.*
text
table
243
Geräteinformation: Hersteller, Name des Modells, Version der SOftware o.ä.
Aufstellungsort des Gerätes
Millisekunden seit dem Start des Agenten
Kontakt zum Admin des Gerätes
Name der Maschine; üblicherweise der DNSName
Zahl der vorhandenen Netzwerkschnittstellen
Array der verschiedenen Infos pro Schnittstelle
(Name, Typ, Geschwindigkeit, MTU)
ARP-Tabelle
Bei Geräten mit mehreren Interfaces: 1, falls
IP-Forwarding stattfindet, sonst 2
IP-Informationen der versch. Interfaces
(Broadcast-, Routeradressen, Netzmasken und
Metrik)
Eine Menge von ICMP-Statistiken
Liste der bestehenden TCP-Verbindungen mit
Status
Liste der offenen UDP-Sockets
Eine Menge von SNMP-Statistiken
Tabelle der auf minimal und maximal laufende
Instanzen zu überwachende Prozesse
Menge des zur Verfügung stehenden Arbeitsspeichers
Ausbaubare Spezial-MIB zur Ausführung von
Programmen und Skripten
Load Average Werte (1, 5, 15 Minuten Intervall)
Eine Menge systemspezifischer Variablen und
Maximalwerte
Eintrag für die später beschriebene eigene
MIB-Erweiterung
Tabelle 16.2: Beispieldaten (OIDs) der Standard-MIBs
244
KAPITEL 16. NETZWERKÜBERWACHUNG
Kommando
get-request
get-nextrequest
get-bulkrequest
response
set-request
inform-request
trap
Bedeutung
Ermittele den Wert einer bestimmten Variablen
Ermittele den Wert der nächsten Variablen ohne
ihren genauen Namen zu kennen
Ermittele einen Block von Variablen (z.B. Tabellen)
Anwort auf o.g. Requests
Speichere einen bestimmten Wert in eine Variable
Referenz zu weiteren z.B. Proxy-Daten
Antwort, ausgelöst durch einen Event-Trigger
Tabelle 16.3: Das SNMP-Kommando-Set
OID
hrSystem
hrStorage
hrDevice
hrSWRun
hrSWRunPerf
hrSWInstalled
Bedeutung
Zahl der laufenden Prozesse und angemeldeten Benutzer
Speicher der verschiedensten Form, wie Real Memory, Swap, Memory Buffers
Liste verfügbarer Geräte, wie Drucker, Prozessor,
Mainboardchipset
Liste der laufenden Prozesse (wie ”ps”)
CPU-Verbrauch der laufenden Prozesse
Liste der installierten RPM-Pakete (setzt ein System auf Basis des Redhat-Package-Managers voraus) mit Installationsdatum
Tabelle 16.4: Variablen der Host-MIB
Kapitel 17
Systemsicherheit
17.1
Generelle Überlegungen
Sichere Rechner bzw. Betriebssysteme kann es nicht geben. Diese werden von Menschen
geschaffen und die Ideen zur Sicherheit werden meistens durch Bequemlichkeit, Unaufmerksamkeit oder Schlampigkeit wieder ausgehebelt. Weiterhin möchte kein Administrator Tag
und Nacht vor einer Maschine hocken und nachsehen, was die Benutzer, Services (Dienstprogramme) und die verschiedenen Prozesse so treiben.
Generell gibt es zwei Sicherheitsbereiche, die man unterscheiden kann: Die (physikalische) Sicherheit der Maschine selbst und Angriffsmöglichkeiten aus dem Netzwerk bzw.
Internet.
Eine weitere Möglichkeit sich aktiv gegen Angreifer aus dem Netz zu schützen und auch
nur bestimmte Kanäle aus dem eigenen Netz zuzulassen, ist das Aufsetzen einer Firewall
(“Schutzwand”); vgl. Kap.19.1
17.2
Sicherheit auf dem Rechner
17.2.1
Einleitung
Ein Angriff eines Hackers war bereits im ersten Schritt erfolgreich, wenn er sich unerlaubt
als ganz normaler Benutzer Zugriff auf einer Maschine verschaffen konnte. Dann sind seine
Rechte schon weit höher als wenn er noch von “aussen” versuchen muss, auf das Gerät
einzudringen.
Deshalb sollte es immer Politik bei der Vergabe von Dateirechten geben, normalen Systembenutzern immer gerade soviele Rechte einzuräumen, wie sie zum Arbeiten benötigen.
Deshalb laufen inzwischen auch viele Dienste, wie z.B. der Nameserver Bind (Daemon: named) oder der X-Displaymanager gdm unter einer eigenen BenutzerID und nicht mehr
mit Rootrechten. So bedeutet ein erfolgreicher Einbruch in diese Dienste noch nicht eine
automatische “Übernahme” der Maschine.
17.2.2
Passwörter
Das Passwort sollte nicht trivial sein! Worte, die in einem Lexikon zu finden sind, haben
als Passwort keinen Wert. Knackprogramme benutzen genau solche Lexika, um bekannte
Worte vorwärts, rückwärts und in Kombinationen durchzuprobieren.
Der Einwand “man habe keine schützenswerte Daten in seinem Account und müsse
darum nicht so viel Aufwand treiben” ist vordergründig verständlich, aber dennoch nicht
richtig. In einem Beispiel versteht man es besser: Möglicherweise hat ein Mieter in einem
245
246
KAPITEL 17. SYSTEMSICHERHEIT
Mietshaus tatsächlich keine Wertgegenstände, die ihm schützenswert erscheinen, doch es
ist nicht akzeptabel, dass er darum die Haustüre offen stehen läßt und damit das Eigentum
der Mitbewohner gefährdet. Obendrein, wenn die Bude abbrennt, wird auch dieser Mieter
gewahr, dass das Gebäude, sein Dach über dem Kopf, doch ein schützenswertes Objekt
darstellt. Um im Bild zu bleiben, auch die Weitergabe von Schlüsseln (Passwörtern) an
Dritte ist in diesem Rahmen nicht akzeptabel! Deshalb genügt es auch nicht, wenn das
Rootpasswort besonders sicher ist. Bereits mit den Rechten eines normalen Benutzers hat
man mehr Möglichkeiten des Einbruchs als mit gar keinem Account auf einer Maschine.
Die Konfiguration zur Passwortsicherheit (Gültigkeitsdauer von User-Passwörtern, Fehlversuche beim Login, Länge des Passwortes) werden in der Datei /etc/login.defs eingestellt.
17.2.3
Der Admin-Account
Den Account des Administrators “root” nur so lange verwenden, wie unbedingt notwendig,
z.B. für die Installation von Software, die allen Benutzern zur Verfügung gestellt werden soll.
Keinesfalls als “root” die tägliche Arbeit machen. Dafür existieren die gewöhnlichen Benutzeraccounts, deren Rechte für die Standardaufgabenstellungen ausreichen. Administrative
Aufgaben sollten niemals müde oder in Eile ausgeführt werden, da mit “root”-Rechten
leicht irreversible Schäden angerichet werden können.
17.2.4
/etc/passwd und /etc/shadow
Ein System sollte das Passwort der Benutzer unbedingt nicht in /etc/passwd speichern! Die
Datei /etc/passwd ist für die Welt lesbar und muss es auch sein, damit der eine oder andere
Dienst funktioniert. Das Problem dabei ist, dass somit jeder mit einem Cracker bewaffnet
auf Passwortsuche gehen kann, solange die Passwörter in dieser Datei stehen. Es leuchtet
ein, dass ein Passwort, das in einer Datei steht, die nur “root” lesen kann, diese Hintertüre
schließt. Also: Shadow-Passwort (in /etc/shadow) benutzen!
17.2.5
Locken oder ausloggen
Aus demselben Grund wie zuvor, ist beim Verlassen einer Maschine darauf zu achten, dass
man bei allen Konsolen ausgeloggt ist oder diese gelockt hat. Arbeiten mehrere Leute an
der Konsole, dann sollte man so nett sein und die Sitzung beenden (und nicht nur den
Bildschirm sperren).
17.2.6
Setuid und Verzeichnisse
Es ist darauf zu achten, dass normale Benutzer in System-Verzeichnissen wie /etc, /bin,
/usr/bin, /sbin usw. keine Schreibberechtigung besitzen. Sollten sie es doch haben, so
können sie dort ein Programm unterbringen (z.B. Verschreiber zu ls oder cd (ls-al ld la ks xs
vf ...)). Das Programm wartet, bis es einmal ausversehen von “root” aufgerufen wird ... und
Voila! Es wird ein Programm z.B. mit dem Namen gainr nach /tmp, /var/tmp oder sonst
wo hin geschrieben, das nichts anderes als eine Shell mit setuid ROOT ist. Ruft man dann
als normaler Benutzer gainr auf, so ist man plötzlich “root” - ganz ohne Passwort. Erste
Konsequenz: Ein normaler Benutzer soll NUR Zugriff auf sein Home-Verzeichnis und auf
/tmp haben! Zweite Konsequenz: Die Variable PATH des Benutzers “root” muss restriktiv
gehalten werden. Das aktuelle Arbeitsverzeichnis hat im PATH von “root” nichts verloren!
Dritte Konsequenz: Die Liste der “setuid root” (-rwsr-xr-x) Programme regelmäßig mit der
Frage nach Wachstum kontrollieren.
17.3. LITERATUR
17.2.7
247
Setuid und Mounting
Mit dem Mounten ist es genauso, nur noch einfacher für den Hacker. Ein wechselbares
Medium darf nie und nimmer setuid-fähig sein! Ansonsten stellt sich der Hacker zuhause
ein Medium her mit einer Shell, die “root” gehört und das setuid-bit gesetzt hat (vergl.
gainr. Dieses mountet er im Zielsystem (oder läßt es vom Admin mounten...) und ...Voila!
Einfach aufrufen und fertig!
Das Mountkommando kann aus Sicherheitsgründen nur vom Superuser aufgerufen werden. Sollen normale User dazu in die Lage versetzt werden, ist die /etc/fstab bzw. die
Konfiguration des Automounters anzupassen. Dann sollte man darauf achten, dass für diese Bereiche keine Ausführungsrechte für Programme gesetzt werden (Option: noexec).
17.2.8
Browser, CGI / Java-Applet und Binaries, per Mail
Grundsätzlich sind alle Programme, die über einen grauen Kanal von außen kommen, als
hoch gefährlich einzustufen. Ein Binary, das per Mail kommt und zur Ausführung gebracht
wird, kann alles enthalten, wovor sich der Admin in schlimmsten Fieberträumen fürchtet.
Auch ein Java-skript kann im Prinzip tun was es will, auch die Datensicherheit korrumpieren. Ein einfaches CGI-Skript einer Suchmaschine ist ein echtes Risiko. Wie in der CT 4’98
beschrieben, reicht es aus, ein Semikolon gefolgt von einem subversiven Befehl als Suchbegriff einzugeben und schon steht da anstelle eines grep-Parameters ein falsch abgesetzter
grep-Befehl gefolgt von einem Befehl frei nach Hackers Wahl. Auf Grund der Vielzahl von
Schwachstellen und Programmierfehlern sollten Web-Browser an sich für den User “root”
tabu sein und nur unter der ID normaler User ausgeführt werden!!
17.2.9
Physikalischer Zugriff
Derjenige, der physikalischen Zugriff zu einer Maschine hat, ist eigentlich auch schon “root”!
Das liegt daran, dass die Konsole zugreifbar ist. Um es nicht ganz so einfach zu machen,
sollten bootfähige und wechselbare Laufwerke (z.B. floppy) von der Boot-Fähigkeit abgehalten werden. Der Durchschnitts-Hacker braucht aber diese Laufwerke ohnehin nicht. Dieser
ist mit einer Reset-Taste oder einem Netzstecker, sowie einer Konsole vollkommen zufrieden. Der lilo ohne Passwortschutz erlaubt einfachste Angriffe! Abhilfe: Die Maschine unter
Verschluss halten. Keiner Maschine, die nicht unter Verschluss ist oder mit dem Internet
verbunden ist, kann man vertrauen.
17.3
Literatur
Einschlägige Mailing-Listen abonnieren und Webseiten untersuchen
http://internet-security.de
http://www.cert.org/
http://www.ers.ibm.com/
http://www.ccc.de/
THE DENIAL OF SERVICE PAGE Linux-Mailinglisten
http://www.diabolo666.com/tools/Tutorial.htm
Monografien gibt es inzwischen auch einige zum Thema ... z.B.:
Simson Garfinkel, Gene Spafford, Practical Unix and Internet Security 2.Edition, O’Reilly,
2000, ISBN 1-56592-148-8
248
KAPITEL 17. SYSTEMSICHERHEIT
17.4
Sicherheit im Netzwerk
17.4.1
Einleitung
Die erste Hürde, die sich Angreifern stellt, ist üblicherweise der lokale Zugang auf ein
System. Dazu benötigen sie meistens eine gültige UserID mit Passwort bzw. den Zugriff
über einen auf der Maschine verfügbaren Netzwerkdienst, wie den Web-, NFS-, Nameserver
etc. Dieser Zugriff kann durch das ablauschen von Verbindungen, wie z.B. ”telnet”, ”ftp”,
”pop3”, ... Anfragen erfolgen, die keine verschlüsselten Passwörter verwenden. Die andere
Möglichkeit ist die Ausnutzung von Sicherheitslücken in verfügbaren Diensten.
Deshalb sollten beim Aufsetzen eines Servers immer überlegt werden, welche Dienste
überhaupt notwendig sind und aus welchem Bereich der Zugriff erfolgen können soll. So
wird z.B. der Webserver weltweit erreichbar sein, das Login, NFS, bzw. Samba für den Zugriff der Webadministratoren meistens jedoch nur aus einem beschränkten Netzwerkbereich
erforderlich sein.
17.4.2
Gesicherte Verbindungen
Das Internet-Protokoll IP und die Transportprotokolle UDP und TCP bringen keinerlei
Sicherheit mit. Die Pakete können auf dem Transportweg verfälscht und der Inhalt leicht
abgelauscht werden. Hiergegen sind Vorkehrungen zu treffen, die an verschiedenen Stellen
der Verbindung ansetzen können:
Host 1
Anwendung
Transport
Netzwerk
Datensicherung
Sicherung
S-HTTP, PGP, eCASH
SOCKS, SSL
IPSec
PAP, CHAP, PPTP
Host2
Anwendung
Transport
Netzwerk
Datensicherung
Tabelle 17.1: Verschiedener Ansatz von Absicherung
Bekannt sind inzwischen sicherlich die Kryptosoftware zum Mailversand, PGP und der
Telnetersatz SSH. Diese setzen an der Anwendungsschicht an. Die Absicherung der Transportschicht kann durch SSL (Secure Sockets Layer) erfolgen, was von verschlüsselten HTTPVerbindungen bekannt sein sollte. IPSec setzt an der Netzwerkschicht an und soll zum einen
die Herkunft der Pakete sicherstellen und zum Anderen das Mitlesen der Daten verhindern
und diese vor unerkannter Manipulation schützen. Ausführliche Erläuterungen zu IPsec
erfolgen im nächsten Kapitel.
17.4.3
ssh und scp
Es ist immer damit zu rechnen, dass irgendwo hinter den nächsten beiden Ecken ein Hacker
sein Laptop genau in das Netz-Segment eingeklinkt hat, in dem man sich befindet. Die
Folge davon ist, dass alles, was man Klartext über das Netz schickt oder was man geschickt
bekommt, mitgelesen werden kann. Das betrifft TCP genau so wie UDP! Der Hacker muss
also nur warten, bis sich irgend ein Benutzer auf einer anderen Maschine einloggt (telnet,
pine, ftp ...) und dann genau die folgenden Pakete dieser beiden Maschinen mitprotokollieren. In der Folge erhält er einen Account-Namen und ein Passwort, das dazu paßt. ...
Abhilfe schafft man hier durch Verwendung der ssh (SecureShell) und SecureCopy scp zum
Kopieren von Dateien über Rechnergrenzen hinweg. Damit baut man einen verschlüsselten
17.4. SICHERHEIT IM NETZWERK
249
Kanal zwischen zwei Rechnern auf:
dsuchod@s14:~ > ssh dirk@s1.goe.net
dsuchod@s14:~ > ssh -l dirk s1.goe.net
dsuchod@s14:~ > ssh -l dirk s1.goe.net Netscape
Auch wenn man dann X-Anwendungen startet, benutzen diese den verschlüsselten Kanal (Hier spart man sich sogar gegenüber telnet das Setzen der DISPLAY-Variablen).
Das Setzen von Umgebungsvariablen wird im Abschnitt zur Shell erörtert. Im letzten der
Beispiele, die oben gezeigt wurden, hat man sich nicht mehr auf der Maschine eingeloggt,
sondern nur noch ein Kommando abgesetzt, welches remote ausgeführt wird.
Möchte man sich regelmässig auf verschiedenen Rechnern einloggen und nicht jedesmal
sein Passwort für diese Verbindung angeben, kann man einen Schlüssel auf dem entsprechenden Rechner generieren und den Public-Teil in der Datei:
/.ssh/authorized keys (im Homeverzeichnis unterhalb des versteckten Verzechnisses .ssh)
speichern.
dsuchod@s14:~ > ssh-keygen -t dsa
Mit dem Tool ssh-agent kann man sich das Leben noch erleichtern: Dieser fragt zu
begin einer Sitzung die Passphrase für die gesammelten Schlüssel ab und authentifiziert
jede bereits einmal aufgebaute Verbindung automatisch ohne weitere Nachfrage.
17.4.4
Der Intenet-”Super”-Daemon (x)inetd
Viele Dienste, die nicht sehr häufig nachgefragt werden, wie z.B. ”telnet”, ”talk” und ”ftp”
müssen nicht permanent im Hintergrund laufen und die CPU, sowie den Arbeitsspeicher
belasten. Sie werden auf Anforderung durch den (x)inetd gestartet und nach Beendigung
der Verbindung wieder geschlossen.
Der xinetd stellt die weiterentwickelte Form des inetd dar und kann die oben genannte
Forderung nach der Beschränkung des Zugriffs von sich aus erfüllen. In der Konfigurationsdatei des Dienstes der /etc/xinetd.conf können Bereiche angegeben werden, von denen der
Zugriff auf einen bestimmten Dienst erlaubt wird:
service ftp
{
socket_type
protocol
wait
user
server
server_args
only_from
}
=
=
=
=
=
=
=
stream
tcp
no
root
/usr/sbin/proftpd
-p 0
172.16.0.0/16
Der inetd benötigt hierzu noch den TCP-Wrapper tcpd, welcher über die Dateien
/etc/hosts.deny und /etc/hosts.allow gesteuert wird.
Generell gilt natürlich, dass alle Dienste, die nicht benötigt werden, auf jeden Fall deaktiviert werden sollten. Gerade diese bergen häufig die Gefahr, dass (weil man nicht an sie
denkt) hierüber der erfolgreiche Angriff stattfindet.
250
17.4.5
KAPITEL 17. SYSTEMSICHERHEIT
xhost + und das unsichtbare Fenster
Mit ”xhost +” serviert man potentiellen Einbrechern die gewünschten Informationen auf
einem goldenen Tablett! Das einzige, was der Hacker zu tun hat, ist ein unsichtbares Fenster
auf dem Bildschirm zu platzieren. Dieses bekommt natürlich, weil es zu oberst liegt, alle
Informationen von Maus und Keyboard exklusiv. Je nach Gutdünken des Hackers werden
diese Informationen an die Fenster, an die sie eigentlich gerichtet sind, weitergeleitet oder
eben auch nicht. Der Hacker kann alles mitprotokollieren oder das keyboard/maus toten
Mann spielen lassen oder alles andere, was das Herz begehrt, mit dem Bildschirm anstellen.
Ein Login-Bildschirm über Nacht auf’s Display gezaubert, bringt am nächsten Morgen ein
sicheres Passwort.
17.4.6
.rhosts
Es ist grundsätzlich abzulehnen, den eigenen Account gegenüber einem Benutzer zu öffnen, der behauptet, sich auf einer Maschine zu befinden, die ihrerseits behauptet, einen
bestimmten Namen zu tragen. Man sieht schon jetzt wie fragil das Konstrukt ist... Jeder
kann irgendetwas behaupten, aber darum ist demjenigen noch kein Account zu öffnen.
Das Konzept der R-Tools (Steuerung über die .rhosts im eigenen Homeverzeichnis) wie
sie einmal von Sun eingeführt wurden, ist in der heutigen Zeit obsolet geworden. Dazu gibt
es SecureShell und -Copy und den SSH-Agent, wenn man vermeiden will, bei jedem Login
auf einer anderen Maschine immer wieder ein Passwort eingeben zu müssen.
17.4.7
Überprüfung der Netzwerksicherheit eigener und anderer Rechner
Es gibt inzwischen eine ganze Reihe von Programmen, mit denen sich der Netzwerkverkehr
überwachen und überprüfen lässt. Dieses sind zum einen die Tools zum ”Mitlauschen”
des Datenverkehrs tcpdump, ntop und ethereal. Gerade das letzte Tool ist besonders
zu empfehlen, da es über ein komfortables grafisches Frontend, gute Packetviewer und
Filterfunktionen verfügt. ntop ist ein textbasiertes interaktives Programm, welches aktuelle
Verbindungen und die dabei umgesetzten Datenmengen nach Verbindung und Protokollart
aufzeigt. tcpdump arbeitet an der Kommandozeile und schneidet Pakete mit, welche an
der Netzwerkschnittstelle angenommen werden. Bei allen Tools lassen sich auch Nicht-IPProtokolle registrieren.
Die Untersuchung auf bestimmte Dienste, d.h. offene Ports von Rechnern oder in Netzwerken, lässt sich mit dem Portsniffer nmap bewerkstelligen.
nmap -O 172.16.0.0/16
nmap -sP 172.16.1.0/24
nmap -sT 172.16.1.1
nmap -sU www.goe.net
Feststellen des Betriebssystems im
Class-B-Subnetz
Ping-Scan (Erreichbarkeit von Rechnern Class-C-Subnetz
Scan auf offene TCP-Ports der Maschine mit der IP 172.16.1.1
Scan auf offene UDP-Ports der Maschine mit dem FQDN www.goe.net
Tabelle 17.2: NMAP im Einsatz
17.5. AUFGABEN
17.4.8
251
Firewall
Inzwischen gibt es drei Firewallimplementationen für den Linuxkernel: Das ipfwadm führte
diese Funktionalität in den 2.0.er Kernel als ein wichtiges neues Feature ein. Die Firewallingfähigkeit wurde mit ipchains im Kernel der 2.2.er Serie stark verbessert und wird
deshalb in einem eigenen Kapitel beschrieben. Der Kernel 2.4 bringt eine weiter verbesserte Firewall mit netfilter mit sich, ist aber abwärtskompatibel über Kernelmodule zu
ipfwadm und ipchains.
17.5
Aufgaben
17.5.1
Secure Shell
1. Wie sieht das Kommando aus, wenn man sich auf eine entferne Maschine (RemoteLogin) mit dem Rechnernamen test.domain.local verbinden will und man die BenutzerID ”userid” auf der entfernten Maschine verwenden will und unter einer anderen ID
auf der Ausgangsmaschine angemeldet ist?
2. Wie könnte der SCP-Kopierbefehl aussehen, wenn eine Datei namens unterlagen.txt
vom Rechner test.domain.local unter der UserID ”root” in das lokale Verzeichnis auf
dem eigenen Rechner kopiert werden soll?
3. Welches Problem liegt vor, wenn ich folgende Meldung zu sehen bekomme?
user@linux:~/SharedFiles/kurs/klausur> ssh 10.30.4.44
8014: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
8014: @
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
@
8014: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
8014: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
8014: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
8014: It is also possible that the RSA host key has just been changed.
8014: The fingerprint for the RSA key sent by the remote host is
53:8c:4b:13:f6:df:2e:d1:e5:cf:21:12:a4:c2:ea:c5.
8014: Please contact your system administrator.
8014: Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
8014: Offending key in /home/user/.ssh/known_hosts:11
8014: RSA host key for 10.30.4.44 has changed and you have requested strict checking.
8014: Host key verification failed.
4. Wie kann ich mich auf anderen Maschinen per SSH unter Vermeidung der Eingabe
eines Passwortes anmelden? Wann benötigt man dieses?
5. Wie tunnele ich eine POP3-Verbindung (Port 143) von meiner Maschine (z.B. mymachine.dyndns.org) auf den POP3-Server (z.B. pop3.mydomain.local), wo ich über
einen SSH-Zugang verfüge?
252
KAPITEL 17. SYSTEMSICHERHEIT
Kapitel 18
Sicheres IP
18.1
Sicherheitsprobleme des derzeitigen IP-Standards
18.1.1
Intro
Die Idee und erste Implementationen des Internet Protokolls gehen auf die Anfänge der
70er Jahre zurück. Sicherheitserwägungen spielten bei der Entwicklung des IP zu begin
nur eine nachrangige Rolle bzw. wurde bewußt auf höhere Protokollschichten verlagert.
Die Datenpakete, in die Datenströme aufgeteilt werden, passieren auf ihrem Weg zwischen
Sender und Empfänger eine ganze Reihe von Routern. Der Weg selbst ist in den meisten
Fällen nicht vorherbestimmt (von besonderen Ausnahmen einmal abgesehen). So können
Pakete, obwohl sie zwischen Partnern innerhalb einer Stadt ausgetauscht werden, durchaus mehrfach Landesgrenzen überschreiten. An der Weiterleitung dieser Datenströme sind
dann meistens mehrere Provider beteiligt, die über sehr unterschiedliches Know-How und
Sicherheitsvorstellungen verfügen können.
18.1.2
Offener Datentransport
Für den Transport von Daten in einem Netzwerk, d.h. eine Kommunikation zwischen zwei
Rechnern A und B, benötigt man offene und gemeinsame Standards, damit eine Verbindung
zustande kommen kann. Hierfür reicht es aus, dass jeweils die Datenheader der verwendeten
Protokolle genormt und für alle am Transport Beteiligten interpretierbar sind.
Da Empfänger und Absender nicht direkt miteinander kommunizieren, sondern ihre
Pakete nur an den nächsten Router (meistens einfach an das Default-Gateway) ausliefern,
lassen sich Aussagen über die Authentizität und die Richtigkeit des Inhaltes von Paketen
nicht machen. Für erfahrene Anwender bzw. Benutzer einschlägiger Programme ist es überhaupt kein Problem IP-Pakete mitzulesen (z.B. dsniff, ethereal, ...). Dieses kann bereits im
eigenen LAN geschehen. Jedoch kann auch jede Maschine auf dem Weg der Datenpakete diese mitlesen. Beides läßt sich in den seltensten Fällen feststellen. Selbst wenn Pakete
auf ihrer Reise verändert werden, kann man dies nicht einfach feststellen, da die Prüfsummen von IP- und TCP-Header natürlich auch vom Fälscher korrekt eingetragen werden.
Genausowenig läßt sich feststellen, ob der Absender wirklich der erwartete Kommunikationspartner ist oder ob sich der Man-in-the-Middle eingeschaltet hat.
Viele Benutzer werden sicherlich sagen, dass andere mit ihren Daten nichts anfangen
können und dass sie nicht relevant sind. Trotzdem möchte man sicherlich nicht, dass jemand seine Mailbox bei einem Webmailer ausräumt oder Mails unter dem eigenen Namen
verschickt. Wenn vielleicht mit einer einfachen Mailadresse noch keine kostenpflichtigen
Dienste aufgerufen werden können, so lassen sich doch Mails mit sehr üblen Inhalten ver253
254
KAPITEL 18. SICHERES IP
Abbildung 18.1: Snapshot einer Ethereal-Analyse
fassen, die den oder die AccountinhaberIn in Schwierigkeiten bringen können. Oder aber
jemand verwendet mitgehörte Ebay-Daten dazu, Gebote auf eigene Artikel zu platzieren.
Das folgende Listing zeigt einen Ausschnitt einer Google-Sitzung; viele Informationen kann
man sofort und ohne großen Aufwand direkt entnehmen.
0040
0050
0060
0070
0080
0090
00a0
00b0
00c0
00d0
00e0
00f0
0100
0110
0120
0130
0140
0150
0160
0170
29
77
69
38
3d
2d
35
20
6e
74
2e
78
2c
67
74
69
74
65
75
3d
0d
69
6e
35
20
41
2e
4b
75
74
64
74
20
65
2d
70
79
74
74
30
b5
47
65
2b
39
48
67
30
6f
78
70
65
2f
69
2f
45
2c
0d
3a
66
2e
48
45
2b
6e
2d
54
65
20
6e
29
3a
2f
2a
6d
2a
6e
20
0a
20
2d
35
00
54
68
65
31
54
6e
28
71
0d
2f
0d
2c
61
2c
63
67
41
69
38
0d
00
20
61
74
26
50
74
63
75
0a
2f
0a
20
67
20
6f
7a
63
73
3b
0a
01
2f
63
7a
68
2f
3a
6f
65
52
77
41
69
65
2a
64
69
63
6f
71
41
01
73
6b
26
6c
31
20
6d
72
65
77
63
6d
2f
2f
69
70
65
2d
3d
63
08
65
65
69
3d
2e
4d
70
6f
66
77
63
61
70
2a
6e
2c
70
38
30
63
0a
61
2b
65
64
31
6f
61
72
65
2e
65
67
6e
0d
67
20
74
38
2e
65
11
72
69
3d
65
0d
7a
74
2f
72
67
70
65
67
0a
3a
69
2d
35
35
70
df
63
63
49
26
0a
69
69
33
65
6f
74
2f
2c
41
20
64
43
39
2c
74
06
68
68
53
6d
55
6c
62
3b
72
6f
3a
6a
20
63
78
65
68
2d
20
2d
9c
3f
2b
4f
65
73
6c
6c
20
3a
67
20
70
69
63
2d
6e
61
31
2a
4c
42
71
6d
2d
74
65
61
65
4c
20
6c
74
65
6d
65
67
74
72
2c
3b
61
97
3d
65
38
61
72
2f
3b
69
68
65
65
67
61
70
7a
69
73
20
71
6e
-@5H.... ..._..B.
).GET /search?q=
wie+hacke+ich+me
in+netz&ie=ISO-8
859-1&hl=de&meta
= HTTP/1.1..User
-Agent:Mozilla/
5.0 (compatible;
Konqueror/3; Li
nux)..Referer: h
ttp://www.google
.de/..Accept: te
xt/*, image/jpeg
, image/ png,ima
ge/*, */*..Accep
t-Encodi ng:x-gz
ip, gzip ,identi
ty..Accept-Chars
et: iso-8859-1,
utf-8;q= 0.5,*;q
=0.5..Accept-Lan
18.1. SICHERHEITSPROBLEME DES DERZEITIGEN IP-STANDARDS
0180
0190
01a0
01b0
01c0
01d0
01e0
01f0
67
20
43
35
3a
37
37
38
75
77
6f
66
4c
31
30
53
61
77
6f
35
44
37
3a
59
67
77
6b
31
3d
30
53
7a
65
2e
69
34
64
3a
3d
51
3a
67
65
38
65
4c
35
0d
20
6f
3a
31
3a
4d
49
0a
65
6f
20
33
54
3d
4b
0d
6e
67
50
30
4d
31
57
0a
0d
6c
52
35
3d
30
55
0a
65
45
35
31
33
36
48
2e
46
64
30
38
38
6f
64
3d
62
33
38
68
73
65
49
62
38
32
50
74
0d
44
38
38
37
58
3a
0a
3d
32
32
31
73
255
guage: en..Host:
www.google.de..
Cookie:PREF=ID=
5f514813055dbb82
:LD=de:TM=103882
7170:LM=10388271
70:S=5IKWU68hPXs
Darüberhinaus gelingt es leicht, Pakete zu modifizieren. So kann die Absende- oder
Empfangsadresse eines Datenpaketes umgeschrieben werden. Dies geschieht gewollt z.B.
bereits beim Passieren einer Firewall mit Network Address Translation (NAT), oder durch
sogenannte Bouncer und Redirecter. Die Modifikation des Absenders kann auch aus weniger
ehrenhaften Gründen, wie DoS-Attacken erfolgen.
Weiterhin gibt einem die Tatsache, dass bei vielen klassischen Protokollen (wie Telnet,
Pop3, Imap4, ftp, http) Passwörter im Klartext übertragen werden und damit sehr einfach
abzufischen sind, kein gutes Gefühl. Der Inhalt der Pakete ist auch vor Fälschungen nicht
sicher. Zwar bildet der IP-Stack Prüfsummen über den Header und den Paketinhalt1 , jedoch
sind die Routinen einfach auf veränderte Pakete anwendbar.
Die Verteilung des IP-Adressraumes liefert vielerlei Anhaltspunkte in Bezug auf die Lage
bestimmter Maschinen und Netzwerkstrukturen. Ein genaues Wissen über solche Strukturen erleichtert das Eindringen in Netze. So wird vielleicht das Zielsystem nicht direkt angegriffen, sondern mittelbar über weitere Rechner, die ”näher an dieser Maschine liegen”,
korrumpiert.
18.1.3
Absicherung - Lösungsansätze
Die geschilderten Probleme erzwangen Lösungen, ohne die sichere private und geschäftliche
Kommunikation nicht denkbar wäre. Dabei gibt es eine Reihe verschiedener Ansätze, die an
unterschiedlichen Stellen des Protokollstacks implementiert sind. Von der Implementierung
hängt dann jedoch ab, welche Daten und Protokolle sich mit diesen sicheren Verbindungen
abwickeln lassen und welche Stufe von Sicherheit erreicht wird. Die Komplexität der einzelnen Lösungen variiert: Einige Konzepte kann man bereits mit normalen Userprivilegien
ausführen, die anderen erfordern zusätzliche Kernelmodifikationen und Root-Rechte.
Netzwerk-Level Pakete, die zwischen Rechnern auf dem Netzwerk transportiert werden,
sind verschlüsselt. Die Verschlüsselung erfolgt in der Nähe des Netzwerktreibers, wo die
Daten auf die Reise geschickt werden. Der Vorteil dieses Verfahrens liegt darin, dass es
transparent arbeitet. Änderungen oder Zusätze zu den einzlenen Netzwerkapplikationen
sind unnötig. In dem Augenblick wo IP-Pakete verschlüsselt werden, kann diese Funktion in
Router eingebaut werden. Diese werden üblicherweise sowieso als ”BlackBoxes” betrachtet,
da sie den Verkehr zwischen Hosts transparent weiterleiten und selbst nicht für den normalen
Anwender sichtbar werden. So sieht ein Verschlüsselungsrouter für den Endanwender wie
ein nichtverschlüsselnder Router aus. Ein Beispiel hierfür ist z.B. die SonicWall Pro. Dieser
Ansatz lohnt sich besonders dann, wenn eine Verschlüsselung auf Applikationsebene nicht
möglich oder äußerst aufwändig scheint und sehr viele verschiedene Anwendungen sicher
kommunizieren sollen. Beispiele für diesen Ansatz sind Microsofts ”Microsoft Point-to-Point
1
IP merkt sich die Paketgesamtlänge und eine Headerprüfsumme, TCP die Headerlänge und eine Datenprüfsumme
256
KAPITEL 18. SICHERES IP
Tunnel Protocol” (PPTP), die Crypto IP Encapsulation (CIPE), OpenVPN und IPsec. Die
beiden letzteren Ansätze werden als freie Software im Sinne der GPL entwickelt.
Für das Microsoft-Protokoll existiert ein Linux-Client, um Verbindung mit entsprechenden Microsoftsystemen aufnehmen zu können. Den Client, die Dokumentation und Installationsanleitungen findet man bei den nachstehenden Literaturhinweisen. Inzwischen sind
etliche Anmerkungen zu diesem Protokoll veröffentlicht, die einige Schwächen des Konzeptes aufzeigen. Trotzdem sollte es der Vollständigkeit halber genannt werden, da es noch
an vielen Stellen zum Einsatz kommt. Da es an der Transport- und Sicherungsschicht ansetzt, sind verschiedene höhere Protokolle, also nicht nur IP-Pakete darüber zu tunneln.
So können auch IPX und NetBIOSPakete verschickt werden. Der Einrichtungsaufwand für
dieses Protokoll muss wegen einiger Kernel- und Systemanpassungen als recht hoch eingeschätzt werden. Es gibt verschiedene Versionen und widersprüchliche Anleitungen im
Netz, so dass je nach eingesetztem System mit Problemen gerechnet werden muss. Wenn
möglich sollte der Einrichtungsaufwand lieber auf eine aus Sicht des Autors bessere Technologie, wie CIPE oder IPsec verwandt werden.
Jedoch haben alle Low-level-Verschlüsselungen den gemeinsamen Nachteil, dass sie keinen Schutz gegen Einbrüche und Attacken auf höheren Protokollebenen bieten. Trojaner per
Email oder durch eine Webanwendung, Exploits auf der Betriebssystemebene sind auf diese
Weise nicht zu unterbinden. Sie erfordern spezielle Maßnahmen, wie die PGP-Verschlüsselung und Signierung von Emails oder Zertifikate für Webinhalte und Programme.
Socket-Level Für eine ganze Reihe von Anwendungen sind sichere Protokolle entwickelt
worden. So wird der chronisch unsichere Telnet-, Remote-Login bzw. Remote-Copy-Dienst
zur Anmeldung an entfernten Maschinen durch die Secure Shell (SSH) ersetzt. Sie arbeitet
auf TCP-Ebene, verschlüsselt aber den Inhalt von Paketen. So können die übertragenen
Passwörter und Daten nicht von Dritten mitgehört und modifiziert werden. Mittels SSH
lassen sich einfache TCP-Tunnel realisieren, dieses wird in [lmssh] beschrieben.
Für webbasierte Kommunikation wurde der Secure Socket Layer eingeführt, der es
ermöglicht die HTTP-Kommunikation zwischen Server und Webbrowser zu verschlüsseln.
Diese Verbindung arbeitet auf der logischen Verbindungsebene der kommunizierenden Programme. In beiden geschilderten Fällen wird zwar verhindert, dass die Pakete mitgelesen
und modifiziert werden können, jedoch bleibt dem Aussenstehenden die - der Kommunikation zugrundeliegende - Netzstruktur nicht verborgen. Der Aufwand der Konfiguration hält
sich sowohl für SSH, als auch für SSL in Maßen. Es werden keine Kernelmodule benötigt
und die Verschlüsselung kann vom normalen Benutzer ohne spezielle Rechte durch den
Aufruf bzw. die entsprechende Konfiguration der Applikation erfolgen.
Applikationsebene In jede Applikation kann eine Verschlüsselung eingebaut werden,
welche die Daten - bevor sie in die Transportschicht gelangen - geeignet einpackt. Ein
Beispiel sind Emailprogramme: Emails werden standardmäßig unverschlüsselt übertragen.
Dabei könnte prinzipiell jeder Administrator eines Servers, der von der Mail durchlaufen
wird, die Mail lesen. Natürlich wäre auch ein Geheimdienst oder Wirtschaftsspion in der
Lage die Leitungen anzuzapfen und könnte jede Mail mitlesen. Um dieses zu verhindern
wird den Mailprogrammen ein Plugin hinzugeführt, bzw. die Fähigkeit Emails vor dem
Versenden zu verschlüsseln und auf der Empfängerseite zu entschlüsseln.
Viele Mailprogramme haben Verschlüsselungsmöglichkeiten bereits eingebaut. Spezielle
Verschlüsselungsprogramme wie Pretty Good Privacy (PGP) stehen zum Download bereit.
Installations- und Gebrauchsanweisungen sind allenthalben zu finden. Die Installationsroutinen und Bedienoberflächen sind ausgereift; sie können auch ohne tiefgreifende technische
18.2. VPNS - SICHERE NETZE ÜBER DAS INTERNET
257
Vorkenntnisse genutzt werden.
18.2
VPNs - Sichere Netze über das Internet
Ein VPN ”Virtual Private Network2 ” verbindet entweder zwei Netzwerke oder einen Computer mit einem Netzwerk oder zwei Computer - und das jeweils auch über öffentliche,
unsichere Verbindungen (z.B. das Internet). Der Ausdruck ”privat” bedeutet, dass die Verbindung zwischen zwei Rechnern genauso gut gesichert ist, als wenn sie zusammen in einem
lokalen Netzwerk kommunizieren würden. Obwohl die Rechner räumlich durch das öffentliche Netz getrennt sind, hat man durch das Tunneling-Verfahren eine Situation geschaffen,
welche die Rechner ”virtuell” wie Mitglieder des lokalen Netzwerkes erscheinen läßt.
Öffentliches
unsicheres
IP-Netzwerk
202.38.21.24
lisa.dyndns.org
Right Subnet
62.137.15.134
rainer.dyndns.org
192.168.4.0/24
192.168.2.0/24
Left Subnet
Internet
192.168.2.254
192.168.4.254
Abbildung 18.2: Eine typische VPN-Situation
Folgende Ziele sollen durch VPN’s erreicht werden:
• erweitertes Routing - IP-Netze können von dritten unsichtbar über öffentliche Netze
getunnelt werden. Dadurch läßt sich die zugrundeliegende Netzwerkstruktur verdecken und die Identität der kommunizierenden Rechner verbergen.
• Sicherstellung der Absenderauthenzität
• Verschlüsselung des Inhaltes unabhängig von der Paketart
• Vereinfachung des netzwerkinternen Routings. Räumlich und infrastrukturell weit
auseinanderliegende Teile einer Organisation erscheinen auf der logischen Netzwerkebene nahe beieinander
18.3
CIPE
18.3.1
Idee
Einen einfachen und dynamischen Ansatz für Verschlüsselungstunnel bietet die Crypto IP
Encapsulation. Dieses Protokoll ist so angelegt, dass IP-Pakete in verschlüsselten UDPPaketen übertragen werden. Der Vorteil UDP als Transportprotokoll zu verwenden, liegt
2
zu deutsch: Virtuelles Privates Netzwerk
258
KAPITEL 18. SICHERES IP
in der leichten Unterscheidbarkeit verschiedener Endpunkte. Bei einer einfachen IP-zu-IPKapselung ist man auf die eigene eingetragene IP-Adresse beschränkt und kann schwer
mehrere Tunnel voneinander unterscheiden. Weiterhin wird der Transport über dynamische Adressen, Network Address Translation und SOCKS Proxies ermöglicht, die keine
spezielle Anpassung für CIPE benötigen. CIPE kann damit komplett auf der bestehenden IP-Infrastruktur aufsetzen, ist allerdings nicht kompatibel zu den in RFCs publizierten
Prinzipen von IPsec.
Es existieren Implementationen für Linux und Windows. Die Linuximplementation erfordert ein spezielles Kernelmodul, das jedoch bei den meisten Distributionen mit CIPE bereits mitgeliefert wird. Das Kernelmodul regelt das Senden und Empfangen der IP-Pakete.
Es definiert ein Netzwerkdevice cipcb*, z.B.
ifconfig cipcb0
cipcb0
Link encap:IPIP Tunnel HWaddr
inet addr:192.168.2.254 P-t-P:192.168.4.254 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (70.6 Mb) TX bytes:0 (813.0 Mb)
oder mittels des IP-Route2-Tools ip:
ip addr show dev cipcb0
9: cipcb0: <POINTOPOINT,NOARP,UP> mtu 1442 qdisc pfifo_fast qlen 100
link/ipip 00:00:5e:b2:00:43 peer 00:00:00:00:00:00
inet 192.168.2.2 peer 192.168.2.1/32 scope global cipcb0
Definierte CIPE-Interfaces tauchen als Hostrouten in der Kernelroutingtabelle auf. Die
Devices können analog zu anderen Netzwerkdevices angesprochen und benutzt werden, z.B.
um weitere Routen darüber mittels /etc/cipe/ip-up einzutragen oder Firewall-Regeln darauf
anzuwenden. Im Namen des Netzwerkinterfaces wird der Verschlüsselungsalgorithmus (im
Beispiel ”b” für blowfish) kodiert, der zum Zeitpunkt der Übersetzung von CIPE angegeben
werden kann.
Im ”user space” läuft der Hintergrunddienst ciped. Dieser kann mit dem pppd verglichen werden. Er regelt das Aufsetzen und Schliessen des Netzwerkinterfaces anhand der in
den entsprechenden Konfigurationsdateien vorhandenen Einstellungen.
Verschlüsselungsrouter auf Basis von CIPE weisen eine herausragende Leistung auf,
mit Datentransferraten, die nur zwei bis drei Prozent unter denen des unverschlüsselten
Verkehrs liegen. Ein Teil der Performanz von CIPE kommt durch die Verwendung von
UDP als Transport Protokoll. Es vermeidet verschiedene Formen subtiler Interaktionen, die
durch mehrere TCP-Layer entstehen können. Diese Beeinflussungen tragen dazu bei, dass
die Leistung von MPPE/PPTP 15 % bis 20 % unter der reinen Verbindungsgeschwindigkeit
liegen. CIPE Tunnel sind sehr robust. Sie können durchaus mehrere Wochen laufen, ohne
wieder neu aufgebaut werden zu müssen (wenn sich die IP-Daten der Verbindung nicht
ändern).
18.3. CIPE
18.3.2
259
Aufsetzen von CIPE
Meistens wird CIPE mit der jeweiligen Linuxdistribution mitgeliefert. Dann wird üblicherweise ein Startskript und das Konfigurationsverzeichnis /etc/cipe angelegt. Das Kernelmodul cipcb.o wird entweder automatisch mit dem Start des CIPE-Daemons geladen oder
kann per insmod cipcb eingefügt werden. Für jeden CIPE-Tunnel wird eine eigene Konfigurationsdatei angelegt. Bei SuSE wird dem Dateinamen ”option” die Bezeichnung der
Verbindung nach einem Punkt angehängt, so dass alle Verbindungen mit dem Init-Skript
gestartet werden, die mit ”option.*” beginnen.
Für das Beispiel-VPN im Bild würden die Konfiguratinsdateien für beide Tunnelendpunkte wie folgt aussehen:
# option.example-vpn right side
#
# the peer’s IP address
ptpaddr
192.168.4.254
# our CIPE device’s IP address
ipaddr
192.168.2.254
# my UDP address. Note: if you set port 0 here, the system will pick
# one and tell it to you via the ip-up script. Same holds for IP 0.0.0.0.
me
62.137.15.134:10000
# ...and the UDP address we connect to. Of course no wildcards here.
peer
202.38.21.24:10001
# The static key. Keep this file secret!
# The key is 128 bits in hexadecimal notation.
key
0219e5bfcae114c9203e2e26f048e21d
Sowie für die Gegenstelle:
# option.example-vpn left side
#
# the peer’s IP address
ptpaddr
192.168.2.254
# our CIPE device’s IP address
ipaddr
192.168.4.254
# my UDP address. Note: if you set port 0 here, the system will pick
# one and tell it to you via the ip-up script. Same holds for IP 0.0.0.0.
me
202.38.21.24:10001
# ...and the UDP address we connect to. Of course no wildcards here.
peer
62.137.15.134:10000
# The static key. Keep this file secret!
# The key is 128 bits in hexadecimal notation.
key
0219e5bfcae114c9203e2e26f048e21d
In diesem Beispiel wird davon ausgegangen, dass die routebaren Internet-Adressen
62.137.15.134 und 202.38.21.24 statisch sind. Eine solche Situation betrifft Firmen, die mit
festen IP-Nummern ans Netz angebunden sind. Für den Privatanwender mit der InternetEinwahl und dynamischer IP-Vergabe kann man eine Seite so konfigurieren, dass sie in
Abhängigkeit von der eingehenden Verbindung die Gegenstelle erkennt:
# option.example-vpn right side
260
KAPITEL 18. SICHERES IP
#
[ ... ]
me
134.34.80.5:10001
peer
127.0.0.1:9
maxerr -1
Hierin besteht der Trick, dass als Gegenstelle einfach die Maschine selbst mit dem DiscardPort angegeben wird, der alle eintreffenden Pakete verwirft. Damit der ciped nicht abbricht,
wird die Zahl der erlaubten Fehlversuche mit ”-1” auf unendlich gesetzt. Die Gegenstelle,
d.h. der Rechner mit der dynamischen IP-Adresse erhält folgende Einstellungen:
# option.example-vpn left side
#
[ ... ]
me
0.0.0.0:10000
peer
134.34.80.5:10001
dynip
Nur dieser Rechner kann eine Verbindung initiieren. Wenn zwei Maschinen mit dynamischer IP miteinander kommunizieren, kann auch der DNS-Name statt einer festen IP
eingetragen werden. Probleme könnten jedoch auftreten, wenn sich die IP-Nummer ändert.
Mit CIPE 1.5 ist die Möglichkeit hinzugekommen, Schlüssel über ein Public-Key-Verfahren
analog zu SSH auszutauschen. Dieser Prozess wird mittels des Zusatzprogrammes pkcipe
abgewickelt.
Einfacher und weniger fehleranfällig, sowie unter Sicherheitsaspekten meistens ausreichend, ist es in den Konfigurationen einen gemeinsamen Schlüssel von 128 bit Länge zu
verwenden. Diesen kann man z.B. mittels echo ”this is my keyphrase”—md5sum generieren und an die beiden Tunnelenden kopieren. Dieser Schlüssel dient zur Generierung
des häufiger gewechselten dynamischen Schlüssels mit dem die Daten tatsächlich gecryptet
werden.
Die realen routebaren Adressen und die virtuellen Tunneladressen müssen sich in jedem
Fall unterscheiden. Zusätzlich definierte Routen und Firewallregeln sollten nur mittels ipup Skript eingetragen und mittels ip-down abgebaut werden. Wenn Firewalls eingesetzt
werden, sollte daran gedacht werden, dass die für CIPE benutzten Ports freigegeben sind.
pkcipe benutzt andere als die Tunnelportnummern und muss gesondert betrachtet werden.
Die Einschränkung, dass sich mittels CIPE ausschliesslich 2er Tunnel aufbauen lassen, führt
zur Beschäftigung mit IPsec.
18.4
IPsec-Theorie
IPsec ist ein Versuch, sämtlichen3 Internet-Verkehr automatisch zu verschlüsseln. Damit
dies ohne Veränderung der bestehenden Anwendungen geschehen kann, wird die Verschlüsselung und Authentifizierung auf IP-Ebene, also unterhalb von TCP, UDP und anderer Protokolle durchgeführt.
IPSec wird als Internet Standard entwickelt. Es kann in zwei verschiedenen Betriebsarten
eingesetzt werden: Im Tunnelmode werden die Pakete - wie bei anderen Tunnelingverfahren
auch - komplett mit IP-Header verschickt. So lassen sich vollständig virtuelle Netze schaffen, die unabhängig von der darunterliegenden Infrastruktur kommunizieren können. Im
3
oder zumindest einen großen Teil des
18.4. IPSEC-THEORIE
261
Authentication
Header
IP Header
Next Header
Data (variable)
Payload Length
RESERVED
Security Parameters Index (SPI)
Sequence Number Field
Authentication Data (variable)
32 bit
Abbildung 18.3: Aufbau und Einsatz im IP eines Authentication-Header
Transportmode - dem einfacheren Verfahren - werden nur die Daten der Transportschicht
beachtet. Bei beiden Typen werden die Daten verschlüsselt und es wird jeweils gegenüber
der anderen Maschine bzw. dem Tunnelendpunkt authentifiziert.
Original
IP Header
IP-Datagramm
Data (variable)
Getunneltes
Neuer
IP Header
IP Header
IP-Datagramm
Data (variable)
Datagramm mit Auth-Header im Tunnelmodus
Neuer
IP Header
Auth.
Header
IP Header
Data (variable)
authentifiziert
Abbildung 18.4: Einfügen des AH im Tunnelmodus
Zur Realisierung der Paketintegrität sind dem Internet-Protokoll zwei weitere Headertypen (AH und ESP) in der Transportschicht hinzugefügt worden. Beide Header sind prinzipiell unabhängig von möglichen kryptographischen Verfahren, um Anpassungen an konkrete
Einsatzgebiete und den Stand der Kryptografie zu erlauben. Mittels Authentication Header
(AH) wird die Integrität der übertragenen Daten geschützt und die Authentizität sichergestellt. Selbst wenn die Daten nicht verschüsselt werden, erlaubt AH die Überprüfung
der Daten. Dies erfolgt mittels Prüfsumme über den Datenblock durch SHA-1 oder MD5Verfahren.
ESP steht für Encapsulated Security Payload und sorgt durch Verschlüsselung für: Die
Vertraulichkeit der Daten, deren Integrität und die Authentifizierung der Datenquellen
von IP. Der ESP-Header ist selbst nicht verschlüsselt, der ESP-Trailer teilweise. Der ESPHeader enthält: Sicherheitsparameterindex (SPI), den Verschlüsselungsalgorithmus, die Authentifizierung und den Modus. Im Trailer sind eine Seriennummer, eine Prüfsumme zur
Sicherstellung der Datenintegrität und weitere SPI.
262
KAPITEL 18. SICHERES IP
Security Parameters Index (SPI)
Sequence Number Field
Payload Data (variable)
Padding
Pad Length
Padding (0-255 byte)
Next Header
e
n
c
r
y
p
t
e
d
a
u
t
h
e
n
t
i
c
a
t
e
d
Authentication Data (variable)
32 bit
Abbildung 18.5: Aufbau eines ESP Paketes
Original
IP Header
IP-Datagramm
Data (variable)
Getunneltes IP-Datagramm
Neuer
IP Header
IP Header
Data (variable)
Datagramm mit ESP im Tunnelmodus
Neuer
IP Header
ESP
Header
IP Header
Data (variable)
ESP
Trail
ESP
Auth
verschlüsselt
authentifiziert
Abbildung 18.6: Einsatz des ESP im IP-Datagramm
Ergänzt werden die beiden Header-Typen durch das Internet Security Association and
Key Management Protocol (ISAKMP). Dieses wird dazu verwendet, eine Security Association zwischen den beteiligten Kommunikationspartnern zu etablieren und Schlüssel auszutauschen. Es definiert hierzu Formate und Methoden zur Generierung, Modifikation und
Entsorgung von SAs. Unter dem Internet Key Exchange (IKE) versteht man ein konkretes
Schlüsselaustauschverfahren, welches speziell auf die Benutzung mit ISAKMP abgestimmt
ist.
IPSec wird sich vermutlich auf Dauer durchsetzen. Durch seine Aufnahme als Internetstandard besteht die Hoffnung, dass sich VPN’s einem gemeinsamen Standard annähern und
später produktübergreifend interoperabel werden. Unter Linux erweitert das FreeSWANProjekt [fs] den Linux-IP-Stack um die Fähigkeiten von IPsec. Es gibt Lösungen für Windows2000 und XP, sowie einige proprietäre kommerzielle Produkte, wie die SonicWall Pro.
Zur Zeit funktioniert die Zusammenarbeit zwischen verschiedenen Security-Gateways
und -Lösungen jedoch nur eingeschränkt. Als Beispiel wird die erfolgreiche Zusammenarbeit
von Linux/FreeSWAN mit der SonicWall Pro genannt. Jedoch funktionieren hier nicht alle
vom Standard vorgeschlagenen Features.
18.5
IPsec praktisch - FreeSWAN
Die Konfigurationsmöglichkeiten und Fähigkeiten von IPsec übersteigen die von anderen Sicherheitslösungen erheblich. Das impliziert jedoch eine Modifikation des Kernels. Aufgrund
sehr komfortabler Skripte gelingen die notwendigen Anpassungen auch weniger erfahrenen
18.5. IPSEC PRAKTISCH - FREESWAN
263
Kernelbauer. Vielen Linuxdistributionen liegt inzwischen die FreeSWAM IPsec-Suite bei.
Die FreeSWAN IPSec Authentifizierung und Verschlüsselung kann entweder SSL oder
RSA (public/private Schlüsselpaare) oder statische PSK (Pre-Shared Keys) verwenden.
IPSec Verschlüsselungstunnel gibt es in verschiedenen Formen, die drei üblichsten sind:
Netz-Netz, Netz-Host, Host-Host.
18.5.1
Konfigurationsmöglichkeiten von IPsec
Verschlüsselter Internet-Verkehr zwischen Rechnern oder ganzen Netzen kann auf vielerlei
Arten genutzt werden. Hier sollen einige Beispiele für den Einsatz von IPsec im täglichen
Leben gezeigt werden.
• Point-to-Point Verschlüsselung zwischen zwei einzelnen Maschinen - Die einfachste
Art eine IPsec Verschlüsselung zu nutzen besteht darin, den kompletten IP-Verkehr
zwischen zwei Maschinen zu verschlüsseln: die Point-to-Point Verschlüsselung. Hierbei
werden in der Konfiguration keine Netze hinter den vermeindlichen Gateways angegeben. Der Aufwand ist hierbei gering und es wird so auf einfache Weise eine sichere
Verbindung für alle Applikationen aufgebaut.
• Von der WG in die Firma - Bei dieser IPsec Anwendung handelt es sich um eine Netzzu-Netz Konfiguration. Als Beispiel soll hier die heimische WG (alternativ: das Netz
im Einfamilienhaus mit Vater, Mutter und Kindern) auf das Firmeninternet Netzwerk des Arbeitgebers zugreifen. Das WG-Netz ist dabei z.B. über einen Linux-Router
(”meinewg.dyndns.org”) und DSL an das Internet angeschlossen. Hinter diesem Router befindet sich das private Netz der WG (172.16.1.0/255.255.255.0). Die Firma ist
über eine Firewall, die idealerweise über eine IPsec Implementation verfügt4 , mit dem
Internet verbunden (gateway.firma.de). (siehe Abbildung: VPN1.eps)
Nachdem die Konfiguration (siehe unten) vorgenommen wurde, kann man aus dem
einen privaten Netz problemlos auf das andere zugreifen. Die beiden router (meinewg.dyndns.org) und (gateway.firma.de) übertragen die entsprechenden Pakete über
den aufgebauten IPsec Tunnel, was für die Benutzer völlig transparent geschieht.
• “Direktes Erscheinen lassen der Maschine im Firmennetz” - damit ist in diesem Zusammenhang gemeint, dass ein weit entfernter Rechner über IPsec sozusagen in das
Firmennetzwerk integriert wird. Dabei erhält der Rechner eine IP aus dem Pool der
Firma und ist nicht über seine aktuelle (evt. dynamisch vergebene) IP eines Providers
zu erreichen.
Der Vorteil einer solchen Installation besteht darin, dass in IP-Netzen die Zugriffe
auf Resourcen am einfachsten und effektivsten durch IP-Beschränkungen verwirklicht
werden. So ist es beispielsweise möglich - beim Zugriff auf Fileserver, Datenbankserver
oder Arbeitsgruppen - den Zugriff auf das interne Netz einzuschränken, also mögliche
externe IPs zu berücksichtigen.
• Road-Warrior - Die ”Road-Warrior” Konfiguration ist das Paradebeispiel für den reisenden Handels-/Versicherungsvertreter mit dem Notebook unterm Arm. Bei diesem
Setup handelt es sich um eine Rechner-Netz Situation, in der der IPsec-Tunnel dafür
sorgt, dass der Road-Warrior sich über eine öffentliche Leitung ins Internet einwählen
und auf das interne Netz seiner Firma zugreifen kann. Somit entfällt die Notwendigkeit einer Einwahlanlage in der Firma, falls der Vertreter während seiner Reisen auf
4
wie z.B. die SonicWall Pro oder der klassichen Linux-Router
264
KAPITEL 18. SICHERES IP
Firmenrechner zugreifen muß. Ein angenehmer Nebeneffekt ist dabei natürlich auch,
dass potentiell vertrauliche Daten nicht unverschlüsselt durch die Leitungen geschickt
werden müssen.
18.5.2
Einrichtung von IPsec unter Linux
FreeSwan implementiert IPsec unter Linux. Zum Gesamtpaket zählen das Kernelmodul ipsec.o, die Konfigurationsdatei /etc/ipsec.conf, sowie das Userspace-Programm ipsec. Diese
sollten gemeinsam mit der jeweiligen Linux-Distribution installiert sein.
Wenn diese nicht beiliegen oder seitens des Distributors beigelegt werden oder die jeweils
aktuellste Version verwendet werden soll, empfielt sich das Selbstkompilieren. Hierzu lädt
man die Sourcen von der FreeSWAN-Website (siehe [frsw]) herunter und entpackt diese.
Vorher sollten jedoch die Kernelsources zum verwendeten Kernel vorbereitet werden.
Einrichten des Kernels Beispielhaft soll hier die Installation und Übersetzung der Quellen von FreeSWAN auf einem Rechner mit RedHat Linux 8.0 beschrieben werden, wofür
root-Rechte erforderlich sind. Auf SuSE-Systemem kann man sich die Mühe sparen, da eine
fertig übersetze FreeSWAN Version in der Distribution enthalten ist.
Man hat die Möglichkeit entweder die FreeSWAN-Quellen, oder schon kompilierte RedHat Binaries5 zu benutzen. Das RPM-Paket, das man hier findet, beinhaltet allerdings nur
die Userspace Programme - das Kernelmodul muß man trotzdem selber übersetzen. Das
von uns benutzte Testsystem läuft unter RedHat 8.0, wobei die als ”Server” bezeichnete
Installation gewählt wurde. Zusätzlich zu den vorgegebenen Angaben bei der Paketauswahl
wurden aus der Gruppe ”Development”, die ”Development Tools” sowie ”Kernel development” installiert.
Bau des Kernels Werden das Kernelmodul und die Programme des Userspace von der
gewählten Distribution nicht mitgeliefert, so muss die Software aus den Sourcen gebaut
werden. Besitzer der aktuellen SuSE-Distributionen haben es da leichter, auch wenn nicht
immer das aktuellste FreeSWAN mitgeliefert wird.
Der Start der Installation von FreeSWAN beginnt mit dem Download der aktuellen
Quellen in unserem Fall 1.99 vom FreeSWAN-FTP-Server:
ftp://ftp.xs4all.nl/pub/crypto/freeswan
Danach folgt das Entpacken des Pakets mit ”tar xvzf freeswan-1.99.tar.gz”, was einem
als nächstes die Möglichkeit eröffnet, einen Blick in die Datei ”INSTALL” zu werfen (das
sei übrigens jedem empfohlen !). Hierbei fällt bald auf, dass der Makefile vier Möglichkeiten bereithält, wobei in jedem Fall zuerst automatisch mit Hilfe des Pakets ”patch” die
Veränderungen im Baum der Kernelquellen vorgenommen werden:
• make menugo - Wer diesen Weg wählt, hat alle Möglichkeiten, die man auch mit dem
klassischen make menuconfig hat. Falls die Kernel bisher noch nicht konfiguriert
wurde (falls z.B. die Quellen gerade erst entpackt wurden), bietet sich der Weg über
make menugo an.
• make xgo - Das gleiche wie ”menugo” nur dieses mal im graphischen Modus unter
X11.
• make ogo - Für die Puristen unter den Lesern ist diese Möglichkeit besonders interessant, da sie dem guten alten make config entspricht.
5
ftp://ftp.xs4all.nl/pub/crypto/freeswan/binaries/RedHat-RPMs/2.4.18-24
18.5. IPSEC PRAKTISCH - FREESWAN
265
• make oldgo - ”oldgo” entspricht make oldconfig und übernimmt die aktuelle Kernelkonfiguration aus “.config” und wählt alle IPsec Optionen aus, wobei IPsec selber
als Modul ipsec.o übersetzt wird.
Befindet sich auf dem System schon ein fertig konfigurierter Kernel oder hat der Administrator keine Lust alles neu zu übersetzen, dann kann make menumod sehr hilfreich
sein. Dieser Befehl bringt den Benutzer in die Kernelconfiguration mittels make menuconfig und kompiliert ausschließlich die Module des Kernels neu, was natürlich voraussetzt,
dass in der Konfiguration IPsec als Modul ausgewählt wurde (so wie unten gezeigt).
Nachdem der Kernel oder nur die Module kompiliert und installiert sind 6 , befinden
sich die Userspace-Programme unter /usr/local/lib/ipsec und unter /usr/local/sbin. Die
Konfigurationsdateien ipsec.conf und ipsec.secrets liegen im Verzeichnis /etc.
18.5.3
Einschaltbare Optionen
Nach dem Patchen des Kernels stehen dem Anwender mehrere IPsec Optionen im Kernel
zur Verfügung. Hier sei nur kurz auf deren Bedeutung eingegangen. Weitere Details sind
dem entsprechenden RFC2402 [rfc] zu entnehmen.
Übersicht nach make mengo im Bereich ”Networking options”:
01
02
03
04
05
06
07
08
09
10
<M> IP Security Protocol (FreeS/WAN IPSEC)
--- IPSec options (FreeS/WAN)
[*]
IPSEC: IP-in-IP encapsulation (tunnel mode)
[*]
IPSEC: Authenticbation Header
[*]
HMAC-MD5 authentication algorithm
[*]
HMAC-SHA1 authentication algorithm
[*]
IPSEC: Encapsulating Security Payload
[*]
3DES encryption algorithm
[*]
IPSEC: IP Compression
[*]
IPSEC Debugging Option
In der Zeile ”1” wird IPsec als Kernelmodul für den aktuellen Kernel generiert. Es
wäre auch möglich es fest einzubinden für sichere Kernels, die nicht mit ladbaren Modulen arbeiten sollen. Zeile ”3” aktiviert den Tunnelmodus, so dass mit IPsec nicht nur
Punkt-zu-Punkt-Verbindungen verschlüsselt werden, sondern die Linuxmaschinen an den
Tunnelenden als Verschlüsselungsgateway für ganze Netze arbeiten. In der Zeile ”5” wird die
HMAC MD5 Authentifizierung eingeschaltet. Dieses ist notwendig, um eine Linuxmaschine
via IPsec z.B. an eine SonicWall Pro anzubinden.
Das RFC2104 sagt hierzu: “message authentication codes” (MAC): Mechanismen, um
mit “secret keys” die Authentizität von Informationen zu überprüfen, die über ein unsicheres Medium übermittelt wurden. HMAC ist ein Mechanismus zur Authentifizierung von
Nachrichten (ganz allgemein), der cryptogaphische “hash” Funktionen benutzt (“H”). Dabei kann z.B. MD5 oder SHA-1 in Kombination mit einem “secret shared key” zum Einsatz
kommen, welches in Zeile “6” aktiviert wird. Zeile sieben fügt das Transportprotokoll ESP
hinzu, welches zum Beginn des Abschnitts erklärt wurden.
Die Verschlüsselung nach tripple-DES - ebenfalls wichtig für die Anbindung an eine
SonicWall Pro- wird in Zeile “8” zur Verfügung gestellt. Zeile “9” erlaubt das Einschalten
von Kompression im VPN; was vor allem Geschwindigkeitsvorteile bei der Übertragung
normaler ungepackter Dateien, jedoch auch Overhead bei bereits komprimierten Daten mit
6
in /usr/src/linux/ rufe man make modules install auf
266
KAPITEL 18. SICHERES IP
sich bringt. Kompression geht aber auf Kosten der CPU und muss bei der Kalkulation der
Leistung der Verschlüsselungsgateways eingerechnet werden.
“klipsdebug” option: Ohne diesen Schalter gibt es kein Debugging. Es ist nützlich, wenn
alles funktioniert, aber von Nachteil, wenn eine Verbindung aus unbekannten Gründen nicht
zustande kommt. Die Datei “INSTALL” hält dazu folgenden Ratschlag bereit: Turning
“IPSEC Debugging Option” off may look attractive but is unwise. Diese Optionen schaltet
man am besten komplett ein, damit sie später ohne Probleme genutzt werden können. Nicht
alle Optionen werden z.B. gemeinsam mit der Sonic-Wall verwendet (kein IP Compression,
kein HMAC-SHA1 authentication), so dass sie auch weggelassen werden können (wenn nur
eine solche Anwendung erfolgt).
Die INSTALL Datei warnt noch davor bei einem Kernel der Version 2.2.x die Option
”[*] IP: advanced router” unter ”Networking options” zu verwenden. Dieses kann entweder
direkt beim der Konfiguration des Kernels geschehen oder nachträglich mit:
echo′′ 0′′ >/proc/sys/net/ipv4/conf /all/rp filter
geschehen. Bei der verwendeten RedHat Installation wurde eine entsprechende Warnung
auch bei einem 2.4.18er Kernel ausgegeben
ipsec_setup: Starting FreeS/WAN IPsec 1.99...
ipsec_setup: Using /lib/modules/2.4.18-24.8.0custom/kernel/net/ipsec/ipsec.o
ipsec_setup: WARNING: eth0 has route filtering turned on, KLIPS may not work
ipsec_setup: (/proc/sys/net/ipv4/conf/eth0/rp_filter = ‘1’, should be 0)
18.5.4
Konfiguration von IPsec-Verbindungen
Die zentrale Konfigurationsdatei ist ipsec.conf. Hier werden alle Verbindungsdaten für die
einzelnen Verschlüsselungstunnel festgelegt. Aufbau der Konfigurationsdatei - Basiskonfiguration:
# basic configuration
config setup
# THIS SETTING MUST BE CORRECT or almost nothing will work;
# %defaultroute is okay for most simple cases.
#interfaces=%defaultroute
interfaces="ipsec0=eth1"
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=none
plutodebug=none
# Use auto= parameters in conn descriptions to control startup actions.
plutoload=%search
plutostart=%search
# Close down old connection when new one using same ID shows up.
uniqueids=yes
Basiskonfiguration für alle Verbindungen
# defaults for subsequent connection descriptions
# (mostly to fix internal defaults which, in retrospect, were badly chosen)
conn %default
keyingtries=0
disablearrivalcheck=no
authby=rsasig
18.6. KOMMERZIELLE VPN-LÖSUNGEN
#
#
267
leftrsasigkey=%dns
rightrsasigkey=%dns
Einzelne Verbindungen, hier kann es viele Teile geben.
conn freeswan
auth=esp
authby=secret
pfs=yes
#
esp=3des-hamac-md5
esp=hmac-md5-96
# Left security gateway, subnet behind it, next hop toward right.
left=172.16.0.1
leftid=172.16.0.1
#left=10.10.156.2
leftsubnet=10.10.156.0/22
# leftnexthop=10.10.156.1
18.6
Kommerzielle VPN-Lösungen
18.6.1
Cisco-VPN
An vielen Universitäten und in vielen Firmen scheint sich die IPsec-Implementation von
Cisco durchzusetzen. Deshalb soll der Linux-Client an dieser Stelle vorgestellt werden.
Bei der Cisco-Lösung handelt es sich um eine zentrale Hardwarekomponente der Cisco
VPN3000-Serie. Diese agiert als Verschlüsselungs- und Authentifizierungs- Gateway für
Linux-, Windows- oder Macintosh-Clients. Die Clients sind in Software implementiert. Derzeitig ist die Softwareversion 3.7 aktuell, von der Benutzung älterer wird wegen einiger
Sicherheitsprobleme abgeraten.
Um den Client unter Linux nutzen zu können, muss dieser für den aktuellen Kernel
kompiliert werden. Das klingt nach freier Software, die es nicht ist, da einfach nur ein
Wrapper generiert wird, der den mitgelieferten Object-Code für den entsprechenden Kernel
ladbar anpasst. In der Datei interceptor.c lassen sich einige Anpassungen vornehmen, was
das Sperren von Devices nach dem Start des Clients anbetrifft.
Um das Kernelmodul zu übersetzen, müssen die passenden Kernelsources installiert
sein. Anschliessend entpackt man das TAR-Archiv des Clients und wechselt in das Verzeichnis. Mit dem Befehl ./vpn install wird die Installation und das Bauen des Moduls
gestartet. Im dann erscheinenden Dialog wird man aufgefordert das Zielverzeichnis für die
erzeugten ausführbaren Dateien (das betrifft die Programme vpnclient, cisco cert mgr,
cvpnd und ipseclog) anzugeben und die Autostartoption - für das Laden des notwendigen Kernelmoduls - festzulegen. Weiterhin wird das Verzeichnis für die Kernelsources
abgefragt. Überlichweise lassen sich die vorgeschlagenen Einstellungen direkt übernehmen.
Am Ende des Installationsvorganges wird dringend dazu geraten die Zugriffsrechte für das
/etc/CiscoSystemsVPNClient-Verzeichnis restriktiver zu handhaben. Hier liegen nicht nur
die Konfigurationsdateien, sondern eventuelle Zertifikate und auf jeden Fall die Profile.
Mit dem Befehl /etc/init.d/vpnclient init start kann der VPN-Client initialisiert
werden. Es wird sodann das Kernelmodul geladen. Die Vershlüsselungsverbindung wird
mittels des interaktiven Kommandozeilen-Tools (vpnclient connect) vpnprofile initiiert. “vpnprofile” verweist auf eines der unterhalb des Cisco-Konfigurationsverezichnisses
268
KAPITEL 18. SICHERES IP
im Unterverzeichnis Profile abgelegten Benutzungsprofile. Trägt man in diese die Credentials zur Authentifizierung (Benutzername und Passwort) ein, kann die Verbindung auch
automatisch im Hintergrund z.B. nach der DSL-Einwahl im Skript ip-up.local aufgebaut
werden.
Eine typische Profile-Datei (Im Beispiel bleibend vpnprofile.pcf), ist abgelegt im Verzeichnis:
/etc/CiscoSystemsVPNClient/Profile
und sieht wie folgt aus:
[main]
Description=VPN zu einem Cisco IPsec-Gateway
Host=ipsec-gw.mydomain.org
AuthType=1
GroupName=<Gruppenname>
GroupPwd=<Gruppenpasswort>
EnableISPConnect=0
ISPConnectType=0
ISPConnect=
ISPCommand=
Username=<Benuzername>
UserPassword=<RAS-Passwort>
SaveUserPassword=0
EnableBackup=0
BackupServer=
EnableNat=0
CertStore=0
CertName=
CertPath=
CertSubjectName=
CertSerialHash=00000000000000000000000000000000
DHGroup=2
ForceKeepAlives=0
Bei der Option Host muss der entsprechende Cisco-VPN-Server eingetragen werden.
GroupName und GroupPwd erlauben die Unterscheidung von Benutzerkreisen, die auf ein
Verschlüsselungsgateway zugreifen. Mit der Option Username wird der eigene Benutzname eingetragen. Zusätzlich kann man die Option UserPassword einfügen. Dort wird dann
das entsprechende Passwort in Klartext abgelegt. Nach der ersten Verbindung wird dieses
Passwort wieder gelöscht und durch ein Verschüsseltes ersetzt, das gleiche passiert beim
Gruppenpasswort.
Wenn der Cisco VPN-Client auf einem Rechner betrieben werden soll, der hinter einer
Firewall liegt, muss dafür gesorgt sein, dass alle für die IPsec-Verbindung erforderlichen
Datenpakete durchgelassen werden. Dazu zählen das Transportprotokoll ESP mit der Protokollnummer 50 und UDP-Pakete auf Port 500. Wenn das IPsec/UDP verwendet wird,
muss der entsprechende UDP-Port (defaultmäßig 10000) freigeschaltet sein.
Es gibt eine für alle Profile gemeinsam verwendete Konfigurationsdatei (vpnclient.ini),
welche den Umfang der geschriebenen Log-Informationen und die Lage der ausführbaren
Programme bestimmt.
Leider ist die Implementation des Cisco-IPsec nicht besonders schön, so dass die IPsec
Interfaces und entsprechende Routingeinträge nicht mit den üblichen Linux-Tools (ifconfig,
18.6. KOMMERZIELLE VPN-LÖSUNGEN
269
netstat) angezeigt werden. Diese Informationen erhält man mittels vpnclient stat oder bekommt sie bei interaktiver Benutzung auf der Kommandozeile ausgegeben. Der Statusbefehl
liefert weitere Zusatzinformationen wie Angaben zur Verschlüsselung und andere verbindungsspezifische Daten zu bestehenden IPsec-Verbindungen. Genausowenig läßt sich der
Datenverkehr sinnvoll mit ethereal oder tcpdump analysieren: In eine Richtung werden
verschlüsselte, in die andere Richtung unverschlüsselte Datenpakete angezeigt. Das hängt
wohl damit zusammen, dass sich das Kernelmodul sehr tief einklinkt, um bei Bedarf den
Datenverkehr über weitere Interfaces zu unterbinden.
Ein Vor- aber auch Nachteil des Cisco-Clients liegt in seiner zentralen Steuerung, die es
erlaubt vom Benutzer in der vpnclient.ini getroffene Einstellungen zu überschreiben. Das
Verbot eines LAN-Zugriffes und damit implizit das Aufsetzen eines Masquerading-Routers
kann zentral vom Verschlüsselungsgateway erzwungen werden, in Abhängigkeit davon, wie
der zuständige Administrator die Policies einstellt. Durch das Sperren weiterer Interfaces
und den Zugriff auf das lokale Netz erreicht man eine höhere Sicherheit, jedoch kann dann
z.B. schon kein lokaler Netzwerkdrucker mehr verwendet werden, wenn der Verschlüsseltungstunnel aktiv ist. Dieses mag zwar für spezielle Road-Warrior-Einsätze nicht von Bedeutung sein, kann aber in anderen Szenarien für gewaltigen Overhead sorgen, wenn alle
Daten ausnahmslos über das Gateway geschleust werden. Im Extremfall verdoppelt sich der
IP-Traffic im eigenen Netz. Ein weiteres Problem ergibt sich durch die möglichen Benennungen von Interfaces: In einigen Distributionen werden Funk-Karten mit “wlan0” bezeichnet,
die dem Client nicht bekannt sind. Damit ist ein Aufbau einer Verschlüsselungsverbindung
über diese Interfaces unmöglich. Abhilfe für beide Probleme schafft ein Blick in den Code.
Ob die vorgeschlagenen Änderungen auch mit der Cisco-Lizenz vereinbar sind, muss der
Anwender jeweils für sich klären.
Jedoch kann durch einige Änderungen an der interceptor.c die o.g. Problematik umgangen werden wie das nachstehende Diff zeigt:
*** ../test/vpnclient/interceptor.c
2002-10-22 05:47:21.000000000 +0200
--- interceptor.c
2003-03-04 13:39:42.000000000 +0100
*************** static int handle_vpnup()
*** 315,320 ****
--- 315,332 ---if (strcmp(LINUX_VPN_IFNAME, dp->name) == 0) {
continue;
}
+
+
if ((strcmp("eth1", dp->name) == 0) ||
+
(strcmp("eth2", dp->name) == 0) ||
+
(strcmp("ppp0", dp->name) == 0) ||
+
(strcmp("ppp1", dp->name) == 0) ||
+
(strcmp("ipsec0", dp->name) == 0) ||
+
(strcmp("ipsec1", dp->name) == 0) ||
+
(strcmp("ipsec2", dp->name) == 0)) {
+
continue;
+
}
+
+
if (strcmp("lo", dp->name) == 0) {
/*bind to loopback so we can inject UDP packets
*for IPC, but don’t change the xmit function
270
KAPITEL 18. SICHERES IP
*************** static int recv_ip_packet_handler(struct
*** 509,514 ****
--- 521,540 ---struct ethhdr ppp_dummy_buf;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
if ((strcmp("eth1", dev->name) == 0) ||
(strcmp("eth2", dev->name) == 0) ||
(strcmp("ppp0", dev->name) == 0) ||
(strcmp("ppp1", dev->name) == 0) ||
(strcmp("ipsec0", dev->name) == 0) ||
(strcmp("ipsec1", dev->name) == 0) ||
(strcmp("ipsec2", dev->name) == 0))
{
rc2 = original_ip_handler.orig_handler_func(skb, dev, type);
goto exit_gracefully;
}
if (strcmp("lo", dev->name) == 0) {
/* grab the routing entry for loopback packets, in case we need
* to send some later*/
18.6.2
Verwendung der Cisco-Tools
vpnclient ist das Haupttool der Cisco-VPN-Lösung. Ohne Parameter aufgerufen, werden
dem Benutzer gleich mal alle Kommandozeilenparameter mitgeteilt (ja, auch das Linux
übliche “–help” funktioniert; schön, dass Cisco diesen Standard einhält).
Der Client hat drei ”Haupt” Optionen:
connect Hierbei ist es zwingend erforderlich als nächste Option ein Profil anzugeben,
das sich als Datei unter /etc/CiscoSystemsVPNClient/Profiles befindet (in unserem
Beispiel “goemobile”). Wer beim Start nicht nach seinem Benutzernamen und Passwort
gefragt werden möchte, sollte nach dem Profil noch seinen Usernamen übergeben. Man
kann auch noch das Passwort übergeben, was aber nicht zu empfehlen ist, da es auf einer
Maschine mit mehreren Benutzern sehr leich ausspioniert werden kann:
linux:/etc/CiscoSystemsVPNClient/Profiles # ps aux|grep vpnclient
root
2004 0.0 1.0 1756 680 pts/1
S
18:49
0:00
/usr/local/bin/vpnclient connect goemobile user test@realm pwd
<Passwort im KLARTEXT!>
Normalerweise kann man Bentuzernamen und Passwort in der Profildatei speichen, was
aber serverseitig (!) unterbunden werden kann. Wie sinnvoll das ist, bleibt dahingestellt wenn man die oben genannte Sicherheitslücke in Betracht zieht. Der Aufruf von vpnclient
connect <PROFIL >user <USERNAME > führt letztendlich zu:
Cisco Systems VPN Client Version 3.7 (Rel)
Copyright (C) 1998-2002 Cisco Systems, Inc. All Rights Reserved.
18.6. KOMMERZIELLE VPN-LÖSUNGEN
271
Client Type(s): Linux
Running on: Linux 2.4.19 #8 Sat Nov 9 12:20:38 PST 2002 i586
Initializing the IPSec link.
Contacting the gateway at 10.100.0.1
Authenticating user.
Your link is secure.
IPSec tunnel information.
Client address: 134.76.n.n
Server address: 10.100.n.n
Encryption: 168-bit 3-DES
Authentication: HMAC-MD5
IP Compression: None
NAT passthrough is inactive
Local LAN Access is disabled
Wie hier deutlich zu sehen ist, ist die zugewiesene Adresse eine öffentliche Adresse,
während die Gateway Adresse, wie die Adresse der Funklankarte eine private ist. Der Cisco
führt in diesem Beispiel also DirectNAT durch. In diesem Fall sieht man, dass ”local LAN”
ausgeschaltet wurde. Das allerdings nicht anhand der Profildatei sondern von Seiten des
Administrators auf dem Cisco3000. Aber was solls, interceptor.c macht einiges möglich !
Wenn man sich nun in einem Netz hinter einer Firewall befindet und das VPN-Gateway
den Rechner selber direkt nicht erreicht kann, kommt “NAT passthrough” ins Spiel. Das
Ergebnis sieht dann folgendermaßen aus:
IPSec tunnel information.
Client address: 134.76.n.n
Server address: 134.76.n.n
Encryption: 168-bit 3-DES
Authentication: HMAC-MD5
IP Compression: None
NAT passthrough is active on port UDP 10000
Local LAN Access is enabled
disconnect Diese Option ist schnell erklärt: vpnclient disconnect beendet eine bestehende Verbindung.
stat Was man im Hause Cisco “Statistik” zu nennen scheint, hat den Namen eigentlich
nicht verdient:
IPSec tunnel information.
Connection Entry: goemobile
Client address: 134.76.n.n
Server address: 10.100.n.n
Encryption: 168-bit 3-DES
Authentication: HMAC-MD5
IP Compression: None
NAT passthrough is inactive
Local LAN Access is enabled
272
KAPITEL 18. SICHERES IP
VPN traffic summary.
Time connected: 0 day(s), 00:09.31
Bytes in: 84443
Bytes out: 115760
Packets encrypted: 816
Packets decrypted: 671
Packets bypassed: 19
Packets discarded: 7
Configured
Secured
*
*
routes.
Network Destination
10.100.n.n
0.0.0.0
Netmask
255.255.255.255
0.0.0.0
Local
Network Destination
10.100.n.n
Netmask
255.255.0.0
Bytes
0
157753
Neben dem vpnclient Werkzeug existiert ein nettes kleines Programm zum Schreiben
von Logfiles. Dessen Verwendung ist zwar etwas ungewöhnlich, aber das Prinzip funktioniert.
Bevor man sich entscheidet, einen Logfile schreiben zu lassen (eigentlich unklar, warum
nicht gleich an den syslogd übergeben wird), kann man entscheiden, was und wieviel man
mitschreiben lassen möchte. Die Einstellungen hierzu muss man in der Datei:
/etc/CiscoSystemsVPNClient/vpnclient.ini
vornehmen. Die Variable “EnableLog” muss zum erfolgreichen Loggin auf 1 gesetzt sein.
Die einzelnen Optionen sind relativ gut selbsterklärend. Dabei ist ein hoher “level” mit
ausführlichen Mitteilungen des Klienten gleichzusetzen.
Das Schreiben des Logfiles startet man letztendlich mit: ipseclog logname& - nein,
das Programm geht nicht automatisch in den Hintergrund. Auch hier hat sich Cisco ein
eigenartiges Format ausgedacht, was nur etwas gewöhnungsbedürftig ist, aber den Zweck
erfüllt. Wenn man den Cisco Klienten zusammen mit Zertifikaten einsetzt, kommt man
an der Benutzung des “Zertifikate Managers” (cisco cert mgr) nicht vorbei. Dieses kann
nützlich sein, wenn man mit FreeSWAN auf den Cisco-Server zugreifen möchte. Erklärungen
zu Details findet man bei Cisco.
18.6.3
Einsatzszenarien
Der Cisco-VPN-Router wird zur Zeit besonders in Funk-LANs eingesetzt. Diese müssen
um einiges besser gegen Mitlesen des Datenverkehrs abgesichert werden, als drahtgebundene Installationen. Die Ausbreitung der Funkwellen läßt sich bei weitem nicht so gut
überblicken, wie die von TP-Kabeln. Die Funk-LAN-eigenen Sicherungssysteme sind nicht
besonders ernstzunehmen, weshalb ein anderer Ansatz gewählt wird: Man baut ein offenes
privates Netz auf, über das die Teilnehmer nach dynamischer IP-Zuweisung per DHCP
einen Verschlüsselungstunnel über den Cisco-Router aufbauen und erst so in das ”richtige” Netz kommen. Die Maschine bildet den einzigen Übergang und übernimmt neben
den Authentifizierungs- auch Routingaufgaben. Kommunizieren die einzelnen Clients kaum
selbst untereinander, so ist dieses Setup sehr ökonomisch: Es existiert eine einheitliche Software für unterschiedliche Clients, die recht bequem zu benutzen ist. Die Lizenzgebühren
18.7. LITERATUR
273
werden über die Anschaffung der Hardware7 fällig, die Clients können in beliebiger Zahl
benutzt werden.
Ein ähnliches Szenario ergibt sich durch die Anbindung von Aussendienstmitarbeitern
über das unsichere Internet: Sie können auf diese Weise direkt in das jeweilige Netzwerk
ihrer Abteilung oder Firma transparent eingebunden werden.
Wenn man mit Zertifikaten statt der userbasierten Authentifizierung arbeitet, kann
der Cisco-VPN-Server auch mit FreeSWAN zusammenarbeiten. Inwieweit sich der höhere
Einrichtungsaufwand lohnt, muss jeder für sich selbst festlegen. Stellt man keine besonderen
Anforderungen, dann ist der Einsatz der Originalsoftware die einfachere Wahl (besonders
da, wo keine Extrakosten für den Client anfallen).
18.6.4
Fazit
Der Cisco-VPN-Client basiert zwar wie z.B. FreeSWAN auf der identischen Technologie,
jedoch sind die Unterschiede so gross, dass beide nicht interoperabel sind. Beide Verfahren
scheiden sich bereits im Authentifizierungsansatz: FreeSWAN arbeitet mit hostbasierten
Schlüsseln unabhängig von den auf dem jeweiligen Rechner arbeitenden Usern. Der CiscoClient arbeitet mit userbasierten Credentials, die unabhängig von der darunterliegenden
Hardware funktionieren. Im klassischen Road-Warrior-Einsatz spielt dieser Unterschied keine wesentlich Rolle, da Maschine und Benutzer identisch sind. Vom Einsatzszenario eignet
sich der vorgestellte Cisco-Client nur für den Road-Warrior oder den Rechner im lokalen
Netz, die kaum Daten miteinander austauschen, da der gesamte Verkehr jeweils über das
Cisco-IPsec-Gateway abgewickelt wird.
Von der Konzeption her bietet sich deshalb das hier vorgestellte Modell nicht dafür
an, Verschlüsselungstunnel für ganze Netze einzelner Betriebsteile zu bauen. Hierfür gibt es
entweder spezielle Hardware, die diese Aufgabe besser erfüllen kann oder die GPL-basierten
Verschlüsselungstunnel CIPE oder FreeSWAN.
Am Ende bleibt die Frage nach der Sicherheit der Cisco-VPN-Lösung. Der entscheidende Code liegt im Binärformat vor und kann nicht von jedermann eingesehen werden.
Ein weiteres Problem zeigt sich mit der “Öffnung” des Interceptors: Damit lassen sich die
Vorgaben des VPN-Administrators aushebeln, womit zumindest diese Sicherheitsdimension
nicht mehr wirklich gesteuert werden kann. Weiterhin verhält sich der Client mit seinen Interfaces aus Administratorensicht ärgerlich, weil die Standardtools nicht in der gewohnten
Weise eingesetzt werden können.
18.7
Literatur
Cisco:
http://www.cisco.com/univercd/cc/td/doc/product/vpn/client/rel3 7/cli3 7/certs.htm
7
deren Kosten liegen bei ca. 16.000 Euro
274
KAPITEL 18. SICHERES IP
Kapitel 19
Firewall
19.1
Aufbau
Der Begriff ”firewall” bezeichnet einen (speziell konfigurierten) Computer, der mittels entsprechender Software (auch diese wird häufig als firewall bezeichnet) den Strom der Verbindungspakete (durch mehrere Interfaces) regelt. Dieses Konzept ist recht alt (ca. 1985),
daher ist auch Linux seit langer Zeit als firewall nutzbar.
Mit der neuen Kernelgeneration wurde eine neue TCP/IP Stack Implementation eingeführt und einige der bekannten Programme wie ipchains und ipfwadm durch Kernelmodule und Tools aus dem netfilter Paket ersetzt. Vorhandene Skripte lassen sich aber relativ
leicht anpassen.
_____
/
\
Incoming -->[Routing ]--->|FORWARD|-------> Outgoing
[Decision]
\_____/
^
|
|
v
____
___
/
\
/
\
|OUTPUT|
|INPUT|
\____/
\___/
^
|
|
----> Local Process ---Pakete die über ein Netzinterface eintreffen, sind entweder an die firewall selbst gerichtet
(INPUT) oder sollen an einen anderen Rechner weitergeleitet werden (FORWARD); lokal
erzeugte Pakete durchlaufen OUTPUT, bevor sie gesendet werden.
Jedes der angedeuteten Ovale stellt eine ”chain” dar, die jeweils eine Menge von Regeln
enthält. Wenn ein Paketheader auf eine der Regeln zutrifft, gibt diese an, wie weiter mit
dem Paket zu verfahren ist. Passt keine der Regeln einer chain, wird die ”policy” der chain
verwendet. Eine einfache Regel könnte so aussehen:
target
ACCEPT
prot opt source
all -- anywhere
destination
anywhere
Diese recht nutzlose Regel akzeptiert alle Pakete, unabhängig von Protokoll sowie Ursprung und Ziel. Das target könnte auch REJECT, DROP oder FORWARD sein, oder
275
276
KAPITEL 19. FIREWALL
allgemein der Name einer chain (die vordefinierten targets sind in Grossbuchstaben). Alle
anderen Datenfelder zeigen hier ”menschenlesbare” Schlüsselworte (sofern dieses Verhalten
nicht durch Zusatzparameter unterdrückt wird), so fasst z.B. ”all” die Menge aller Protokolle zusammen; alternativ kann man einen einzelnen Namen (z.B. tcp, siehe /etc/protocols)
bzw. den entsprechenden numerischen Wert angeben. Letztlich kann man durch ein vorangestelltes ”!” die Komplementmenge wählen (z.B. !icmp), diese Möglichkeit besteht auch
bei vielen anderen Schaltern. Ebenso ist ”anywhere” nur ein anderer Ausdruck für die
Netzmaske 0.0.0.0/0.
19.2
Ein- und Austragen von chains und Filter-Regeln
iptables wird meistens mit recht vielen Argumenten aufgerufen, zum Beispiel können Regeln
in den verschiedenen chains eingetragen, gelöscht und verändert werden. Die vordefinierten
”chains” (in Großbuchstaben) können jedoch nicht gelöscht werden.
1. Alle Regeln in einer chain listen (-L).
2. Alle Regeln in einer chain löschen (-F).
3. Alle Pakete und Paketzähler in der chain zurücksetzen (-Z).
4. Eine neue chain erzeugen (-N).
5. Die Policy für eine eingebaute chain ändern (-P).
6. Eine leere chain löschen (-X).
Es existieren mehrere Möglichkeiten, eine Regel in einer chain zu verändern:
1. Eine Regel in einer chain einfügen (insert, d.h. oben in die Liste einhängen) (-I).
2. Eine Regel an eine chain anfügen (append, d.h. unten in die Liste einfügen) (-A).
3. Eine Regel in einer chain ersetzen (replace) (-R).
4. Eine (bzw. die erste passende) Regel in einer chain löschen (delete) (-D).
19.2.1
Pakete genauer spezifizieren
Die meisten Regeln bestehen aus einer (beliebigen) Kombination der folgenden Parameter:
19.2. EIN- UND AUSTRAGEN VON CHAINS UND FILTER-REGELN
277
”-p, –protocol [!] protocol”:
”protocol” ist ein Name aus /etc/protocols, der entsprechende numerische Wert oder ’all’
”-s, –source [!] address[/netmask]” und ”-d, –destination [!] address[/netmask]”:
die Adresse kann theoretisch ein hostname sein, um ständige DNS
requests zu vermeiden sollte man jedoch die IP verwenden. Optional kann eine Netzmaske angegeben werden.
”-j, –jump target”:
das Ziel (”target”) der Regel gibt an, wie mit matchenden Paketen verfahren wird, ”target” ist entweder eines der vordefinierten
targets (ACCEPT, DROP, ...) oder der Name einer anderen chain.
”-i, –in-interface [!] name” sowie ”-o, –out-interface [!] name”:
diese Schalter ermöglichen es Pakete durch den Namen des Interfaces zu spezifizieren; einige Kombinationen sind allerdings nicht
möglich, zum Beispiel eine ”-i” Angabe in der OUTPUT chain.
Man kann durch Anhängen eines ”+” mehrere interfaces in einer
Regeln bezeichnen (z.B. ppp0, ppp1).
”[!] -f, –fragment”:
bezieht die Regel auf das zweite und alle folgenden Fragmente
eines fragmentierten Paketes, oder (negiert) auf unfragmentierte
Pakete und erste Fragmente. Fragmentierung von Paketen tritt
zum Beispiel in Ethernet Netzwerken durch die Begrenzung der
Framegrösse auf 1500 Byte (MTU) auf, ein grösseres Paket wird
automatisch zerteilt, gesendet und wieder zusammengesetzt.
Theoretisch kann man auf das Filtern von folgenden Fragmenten
verzichten, da sofern das Erste fehlt, das Zusammensetzen des gesamten Paketes fehlschlagen sollte. Dies setzt aber die Korrektheit
der TCP Stack Implementation voraus, dementsprechend gibt es
viele Angriffe, die spezielle Schwächen verschiedener Betriebssysteme ausnutzen.
19.2.2
”Match Extensions” und Erweiterbarkeit
iptables unterstützt viele weitere Filterspezifikationen durch externe Module (”match extensions”), die implizit durch die Verwendung des ”-p” flags geladen werden (jeweils auf
das Protokoll bezogen), oder explizit durch ”-m modulname” bezeichnet werden müssen.
So wird durch die Angabe ” -p tcp” eine Reihe von TCP bezogenen Filterangaben
verfügbar:
278
KAPITEL 19. FIREWALL
”–tcp-flags [!] mask comp”:
matcht Pakete mit einer bestimmten Kombination gesetzter flags.
Die Maske gibt an, welche der flags betrachtet werden, der zweite
String gibt die eigentliche Kombination an. flags sind durch Komma zu trennen, der erste Parameter darf auch als ”NONE” oder
”ALL” angegeben werden.
”[!] –syn”:
ist eine Kurzform für ”–tcp-flags SYN,RST,ACK SYN” und bezeichnet das jeweils erste Paket einer TCP Verbindung.
”–source-port [!] port[:range]” und ”–destination-port [!]
port[:range]”:
bezeichnen Pakete durch Einschränkung auf einen Port (oder ein
Intervall) an den beiden Enden der Verbindung. Die Parameter
”–sport” und ”–dport” sind Aliasnamen.
Die UDP Filter bieten analog die Angabe von Portadressen an, ICMP kennt keine
Ports und kann daher lediglich mit ”–icmp-type [!] type” spezifiziert werden, wobei type
ein numerischer Wert ist.
Eine weitere wichtige Erweiterung ist das ”limit” Modul, mit dem die Rate der gematchten Pakete pro Zeiteinheit beschränkt werden kann. Damit kann verhindert werden, das eine (entsprechend konfigurierte) firewall sich durch das Loggen von zu vielen Paketen selbst
behindert. Darüber hinaus existieren viele ”Denial of Service” Angriffe (”Überschwemmen
einer Leitung mit vielen Paketen”) die zwar nicht vollkommen ausgeschaltet werden können
(die Bandbreite zur Übertragung ist verloren), deren Auswirkungen (stabiler Betrieb der
Computer, Netzüberlastung durch Antwortpakete) aber erheblich reduziert werden.
Das Modul kann zusätzlich mit den Parametern ”–limit number” und ”–limit-burst
number” aufgerufen werden. Der erste Wert gibt die Rate an (der Zahl kann eine Zeiteinheit
folgen), der zweite einen Schwellenwert, der überschritten werden muss, bevor die –limit
Rate einsetzt.
Im einfachsten fall reicht das Laden des Moduls aus:
iptables -A INPUT -m limit -j LOG
Die Standardwerte sind 3 Pakete pro Stunde mit einem Burstwert von 5, d.h. von einem
ununterbrochenem Strom von ankommenden Paketen würden die ersten 5 gelogt, danach ist
die Regel 20 Minuten inaktiv, bevor auch nur ein Paket verzeichnet wird. Wenn innerhalb
von 20 Minuten kein neues Paket eintrifft, wird eine ”burst-Einheit” zurückgewonnen; nach
100 Minuten ohne Aktivität wäre die firewall wieder im Anfangszustand.
Syn-Flood
Ein bekannter DoS Angriff ist das Senden einer grossen Zahl von Paketen, die den
Zielrechner zum Aufbau einer Verbindung auffordern; der angegriffene Rechner verbraucht
dabei mehr Resourcen als der Angreifer benötigt um die Pakete zu senden.
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
”Ping of Death”
19.3. VON ”MASQUERADING” UND ”PACKET MANGLING”
279
Viele ältere Betriebssysteme reagieren sehr empfindlich auf ICMP Pakete, die grösser
als 65535 byte sind. Da auch von diesem Angriff viele Varianten existieren, blocken manche
Administratoren die entsprechenden Pakete komplett, oder beschränken zumindest die Rate
der eingehenden Pakete.
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s \
-j ACCEPT
Letztlich bleibt noch das ”state” modul, das die Zuordnung von einzelnen Paketen
zu der entsprechenden Verbindung ermöglicht. Durch Laden des Moduls wird ein weiterer
Schalter ”[!] –state STATE” verfügbar, die Angabe ”STATE” kann dabei entweder ”NEW”,
”ESTABLISHED”, ”RELATED” oder ”INVALID” sein. (siehe connection-tracking)
19.3
von ”masquerading” und ”packet mangling”
Neben dem Filtern von (unerwünschten) Paketen sollte eine moderne firewall auch die
Header von bestimmten Paketen verändern können, diese Fähigkeit wird im Allgemeinen
in zwei Bereiche unterteilt. Beide waren bei ipchains noch durch spezielle chains implementiert, sind inzwischen jedoch als eigene Subsystem (table) gekapselt und damit vom
Filtermechanismus getrennt.
Der entsprechende iptables Parameter ist ”-t” gefolgt von dem Namen des anzusprechenden tables: entweder ”nat” oder ”mangle”. Wird der Parameter nicht angegeben, wird
auf dem ”filter” table operiert.
19.3.1
Network Address Translation
Unter diesem Begriff werden Regeln zusammengefasst, die Quell bzw. Zieladresse von Paketen verändern. Anders als bei den normalen Filterregeln, wird hier immer nur das jeweils
erste Paket einer Verbindung betrachtet. Das Ergebnis dieses Paketes wird für alle folgenden
Pakete verwendet.
1. Source NAT (SNAT):
Die Quelladresse des ersten Paketes einer Verbindung wird verändert, bevor es durch
das Netzgerät gesendet wird. Auf der anderen Seite der Verbindung erscheint die
firewall als der Ursprung der Verbindung.
2. Destination NAT (DNAT):
Die Zieladresse des ersten Paketes wird unmittelbar nachdem es empfangen wurde
ver”andert, jedoch bevor die ”Routing Decision” den weiteren Verlauf bestimmt. Hier
erscheint die firewall als das Ziel der Verbindung.
Nun ist es notwendig das ”routing” Diagramm etwas komplexer darzustellen:
280
KAPITEL 19. FIREWALL
--->[1]--->[ROUTE]--->[3]--->[4]--->
|
^
|
|
|
[ROUTE]
v
|
[2]
[5]
|
^
|
|
v
|
Die bereits bekannten targets INPUT (2), OUTPUT (5) und FORWARD (3) werden
durch PRE ROUTING (1) und POST ROUTING (4) ergänzt, allerdings kann nicht jede chain in jedem table verwendet werden. Im ”nat” table dürfen PRE ROUTING sowie
POST ROUTING und OUTPUT verwendet werden.
SNAT wird verwendet, um Zugriffe aus einem Rechnernetz in anderes hinein so zu
maskieren, dass die firewall als Ausgangspunkt der Verbindungen erscheint. Eine firewall
sei durch das Interface eth0 mit dem Internet verbunden und habe die IP 1.2.3.4.
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4
Jedes Paket (aus einem internen Netz), das durch diese firewall ins Internet geroutet
wird, hat als source Adresse die firewall. Eventuelle Antwortpakete werden beim Empfang
automatisch entsprechend manipuliert und an den eigentlichen Quellrechner weitergeleitet.
Da bei Auswahlverbindungen die (externe) Adresse erst beim Verbindungsaufbau bekannt ist, existiert hierfür eine Spezialfall des SNAT: MASQUERADE. Die Angabe der –to
Adresse entfällt hier.
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
DNAT ermöglicht es, eine auf der firewall eingehende Verbindung an einen anderen
Rechner weiterzuleiten. Häufig müssen bestimmte Dienste auch vom Internet her verfügbar
sein, meistens werden dafür einige Rechner in einem (vom eigentlichen lokalen Netzwerk)
getrenntes Netzsegment untergebracht (DMZ, demilitarized zone) das ebenfalls über die
firewall mit dem Internet verbunden ist.
iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT \
--to 5.6.7.8:80
Diese Regel würde auf eth0 eingehenden Traffic (an Port 80) an den Webserver auf
Rechner 5.6.7.8 (in der DMZ) weiterleiten.
19.3.2
packet mangling
Auch die Regeln dieses tables dienen der Veränderung von Paketheadern, insbesondere des
TOS (Type of Service) flags und zum Setzen von eigenen Paketmarkierungen. Seit der
Kernelversion 2.4.18 sind alle bisher genannten targets in diesem table gültig.
iptables wird hier mit den Parameter ”–set-mark” bzw. ”–set-tos” und einem geeigneten Wert aufgerufen.
Der ”Type Of Service” Eintrag eines Paketes hat Auswirkung auf die Routingentscheidung des Kernels, insbesondere wie lange das Paket in einem Cache (exakter: in einer
Queue) warten darf, bzw. wieviel Bandbreite zur Übertragung verwendet werden sollte.
19.4. CONNECTION TRACKING
281
Diese Werte sind jedoch nur als ”Vorschlag” zu verstehen, IPV4 bietet keine Möglichkeit
derartige Zusicherungen wirklich einzuhalten (”Quality of Service” oder kurz QoS).
Der Wert ist als 4-Bit Feld definiert, von dem immer nur ein Bit gesetzt ist:
1000
0100
0010
0001
0000
------
minimize delay
maximize throughput
maximize reliability
minimize monetary cost
normal service
Der ”–set-mark” Parameter wird meistens verwendet, um die Lesbarkeit der firewall
Logdateien durch Schlüsselworte zu verbessern.
19.4
connection tracking
Unter diesem Begriff versteht man die Fähigkeit einer firewall Statusinformationen über alle
aktiven Netzwerkverbindungen zu verwalten, bzw. Pakete einzelnen Verbindungen zuzuordnen. Dabei werden die Quell- und Ziel-adressen, die Portnummern, verwendete Protokolle
und jeweils ein ”Zustand” (state) der Verbindungen im Speicher gehalten. Eine Firewall
mit dieser Eigenschaft wird als ”stateful” bezeichnet.
Zustand
NEW
ESTABLISHED
RELATED
INVALID
allgemeine Bedeutung
bezeichnet Pakete, die eine neue Verbindung aufbauen, bzw. die
zu einer Verbindung gehören, der bisher noch keine Pakete zugeordnet wurden.
eine Verbindung gilt als ESTABLISHED, wenn in beide Richtungen mindestens ein Paket geflossen ist.
auch diese Pakete bauen eine neue Verbindung auf, sind jedoch im
Kontext zu einer existierenden Verbindung zu betrachten (FTP
Datenverbindung, ICMP Fehlermeldung).
bezeichnet Pakete die zu keiner bekannten Verbindung gehören.
Je nach Protokoll der Verbindung haben diese Zustände unterschiedliche technische
Bedeutung, oder sind nur teilweise anwendbar.
UDP Pakete haben keine Sequenznummern, allgemein wird UDP ”stateless” genannt.
Wenn bisher nur ein Paket in eine Richtung geschickt wurde, wird die Verbindung intern als
”UNREPLIED” markiert; wenn innerhalb einer gewissen Zeit (timeout) ein Antwortpaket
eintrifft wird diese Markierung gelöscht und die Verbindung gilt als ”ESTABLISHED”.
Nach einer vorkonfigurierten Anzahl von Paketen (in beide Richtungen) gilt die Verbindung
intern als ”ASSURED” und der timeout Wert wird heraufgesetzt.
TCP Verbindungen werden durch einen ”3-way handshake” aufgebaut, dies ist eine
Folge von Anfrage- und Antwort-paketen, bei denen bestimmte Kombinationen an TCP
flags gesetzt sind. Analog zu UDP gilt eine Verbindung als ”ESTABLISHED” (intern ASSURED) sobald das abschliessende ACK empfangen wurde.
ICMP Verbindungen bestehen entweder aus einer Anfrage (request, NEW) und der
Antwort (reply, ESTABLISHED) oder aus einem einzelnen Paket (RELATED).
Die Beachtung der internen Zustände kann bei Computern mit relativ wenig Hauptspeicher notwendig sein, da die Anzahl der gleichzeitig überwachbaren Verbindungen durch
282
KAPITEL 19. FIREWALL
den verfügbaren Hauptspeicher begrenzt ist. Wenn die Resourcen erschöpft sind und weitere Verbindungen überwacht werden müssen, werden bevorzugt Verbindungen im Zustand
”UNREPLIED” gelöscht und der Verbindungsaufbau damit unterbrochen. Die konfigurierte
Anzahl gleichzeitig verfolgbarer Verbindungen ist in /proc/sys/net/ipv4/ip conntrack max
gespeichert.
Darüber hinaus werden Verbindungen spezieller Dienste (z.B. FTP) durch zusätzliche
Kernelmodule (ip conntrack ftp) überwacht, um damit bestimmte Pakete als ”RELATED”
zu klassifizieren und den Verbindungsaufbau zuzulassen, ohne das die exakten Filterangaben dieser Pakete für die Konfiguration der firewall bekannt sein müssen. So werden
im Fall von FTP (mindestens) zwei Verbindungen (eine Steuerleitung und eine Datenleitung) verwendet. Der client baut zuerst die Steuerleitung zum Port 21 des servers auf.
Danach sendet entweder der client (active ftp) oder der server (passive ftp) eine Portadresse (¿1024) und sein Gegenüber baut die Datenleitung zu der angegeben Portadresse auf.
Der ip conntrack code filtert die Portangabe aus der Steuerleitung heraus und bezeichnet
ein eintreffendes Paket mit den angegebenen Werten als ”RELATED” zu der existierenden
Steuerverbindung.
19.5
Referenzen
1. die iptables man page
2. das netfilter, packet filtering sowie NAT HOWTO
http://www.netfilter.org/documentation/
Index
Übertragungskapazität, 28
A-Record, 91
Abstract Syntax Notation, 175
Acces Point Name, 26
AccessPoint, 18
ACE-Umschrift, 86
Acknowledge, 63
Acknowledgenummer, 64
Active Directory, 85
Adress Resolution Protocol, 53
Adressbereich, 43
Adressierungsschema, 38
ADSL, 11
Agent, 174
Alias, 92
Anwendung, 158
Anwendungsschicht, 9
APN, 26
Applikation, 36
ARP, 51, 53
ASN.1, 175
ATM, 24, 27, 52
Auslöschung, 18
Carrier Sense Multiple Access, 2
Carrierless Amplitude, 29
CDMA, 27
Certificate Authorisation, 106
Chiffrierer, 29
CIFS, 131
CIPE, 200
Circuit Switched Data, 27
Cisco, 211
Clear To Send, 17
Common Internet File System, 131
Common Unix Printer System, 137
Computern, 10
Computersystem, 38
Content-Type, 101
Crypto IP Encapsulation, 200
CSD, 27
CSMA/CD, 14
CTS, 17
CUPS, 137
Darstellungsschicht, 9
Datagramm, 39, 63
Datei, 2, 85, 158
Dateisystem, 85
Datenrate, 11
Bandbreit, 19
Defaultrouter, 43
Bandbreite, 18
Delegation, 87, 88
BDC, 143
dhclient, 75
Benutzer, 143, 189
DHCP, 64, 67, 95
Benutzerkonto, 143
Berkeley Internet Name Domain Software, DHCP-Server, 19
dhcpcd, 75
84
Dienst, 83, 189
Betriebssystem, 8
Directory, 158
Binärzahl, 40
Directory Service, 158
BIND, 84
Discrete Multi-Tone Modulation, 30
Bind, 89
Diskless X-Station, 2, 71
Bitübertragungsschicht, 11
Distinguished Name, 79
Bouncer, 199
DNS, 61, 64, 67, 83
Broadcast, 42
DocumentRoot, 105
CA, 106
Domäne, 143
CA.pl, 106
Domain, 61, 85
283
284
INDEX
Domain Name System, 83, 175
High Speed Circuit Switched Data, 27
Domain-Name-Service, 61
Host, 23, 38
Domaincontroller, 129
host, 83
Domainname, 91
HOST-RESOURCES-MIB, 182
Dotted Quad Notation, 84
Hostname, 61, 71
Dotted-Quad-Notation, 40
hosts, 157
Drucker, 158, 187
hosts.allow, 193
Druckerfreigabe, 129
hosts.deny, 193
Dynamic Host Configuration Protocol, 48, Hostteil, 51
64
HSCSD, 27
Dynamic Host Control Protocol, 3
http, 199
HTTP-Kommunikation, 200
EC, 28
httpd, 101
Echo Cancellation, 28
httpd.conf, 101
Email, 200
HTTPS, 105
Endsystem, 23
ENUM, 97
ICMP, 40, 59
EPROM, 127
imap, 111
ESP, 212
Imap4, 199
Ethernet, 11, 13, 24, 35
inetd, 125, 193
Exploit, 200
Internet, 38
exports, 124
Internet Control Message Protocol, 40
Internet-Protokoll, 38
FDDI, 33
IP, 38, 59, 64, 192, 199
Fehlerrate, 64
IP Virtual Host, 104
Fiber Distributed Data Interface, 33
IP-Adressbereich, 41
Finish, 63
IP-Adresse, 37, 71, 83, 91, 158, 175
Firewall, 199
IP-Adressraum, 46
Flag, 63
IP-Paket, 201
Flusskontrolle, 64
IP-Stack, 199
FQDN, 61, 85, 89
IPsec, 200
Fragment, 45
IPX, 200
Fragment Offset, 64
ISDN, 11, 24
Fragmentierung, 39
Frequency Division Multiplexing, 28
Frequenzspektrum, 18
ftp, 199
Full Qualified Domain Name, 61, 85
Jam-Sequence, 14
Kanalaufteilung, 18
Kanalbündelung, 18
Kernelmodul, 200
Gateway, 71
Klartext, 199
General Packet Radio Service, 26
Koaxialkabel, 15
Generic Flow Control, 32
Kollision, 14, 19
GFC, 32
Global Standard for Mobile Communication, Kommunikation, 46
Konfigurationsdatei, 2
26
GMII, 16
GPRS, 26
groups, 157
GSM, 26
Header, 199
LAN, 7, 36
LDAP, 78, 147, 158
LDAP-Server, 78
ldapadd, 164, 166
ldapdelete, 164
INDEX
ldapmodify, 164
ldapsearch, 164
Leitungskodierer, 29
Lightwight Directory Access Protocol, 147
lilo, 191
Lizenzgebühr, 129
Local Area Network, 3, 13
Logical Link Control, 20
Login, 190
login.defs, 190
Loopback, 84
LPD, 129
MAC, 13
MACA, 17
Management Architektur, 173
Management Information Base, 174
Management Station, 174
Manipulation, 64
Maximal Transmission Unit, 45
Maximum Transfer Unit, 22
MIB, 174
Microsoft Point-to-Point Tunnel Protocol, 200
Mitlauschen, 64
Modem, 11, 24, 35
Modulator, 29
mount.cifs, 130
MRTG, 183
mtr, 48
MTU, 22, 45
Multi Router Traffic Grapher, 183
Multi-Homed-Hosts, 42
Multiple Access with Collision Avoidance, 17
Name Virtual Host, 104, 105
named, 90, 189
named.conf, 90
Namensraum, 87
Nameserver, 62, 87
Naming Authority Pointer Records, 98
NAPTR, 98
NAT, 199
NetBIOS, 130, 200
netstat, 227
Network Address Translation, 199, 202
Network File System, 123
Network Information System, 157, 159
Network Number, 40
Netzmaske, 71
Netznummer, 40
285
Netzwerk, 46, 201
Netzwerkdateisystem, 129
Netzwerkkennung, 46
Netzwerkschnittstelle, 47
Netzwerkteil, 51
Netzwerkverbindung, 227
NFS, 64, 123
NIS, 124, 157, 159
nmbd, 131, 138, 142
nslookup, 61
Nyquist, 28
Object Identifier Namespace, 175
Open Systems Interconnection, 6
openssl, 106
OpenVPN, 200
Paketübertragung, 35
Paketbestätigung, 64
Paketreihenfolge, 64
passwd, 157, 190
Passwort, 189, 190
PATH, 190
PDC, 143
Perl, 3
Personen, 158
Phase Modulation, 29
plain old telephone system, 25
Point-to-Point-Protokoll, 26
Pop3, 199
pop3, 111
Port, 63
Portnummer, 63
POTS, 25
PPP, 26
PPTP, 200
Präfix, 40
Prüfsumme, 199
proftpd, 125
proftpd.conf, 125
Protokoll, 5, 36, 127, 204
Prozess, 189
Prozessor, 187
pump, 75
Punkt-Dezimal-Notierung, 40
Push, 63
PXE, 127
QoS, 52
Quadrature Amplitude Modulation, 29
286
Quality of Service, 52
Quelladresse, 63
Ready To Send, 17
Rechner, 143
Redirect Message, 40
Redirecter, 199
Registrierung, 86
Remote Procedure Call, 157
Remote-Login, 200
Reset, 63
resolv.conf, 61, 75
Resource Record, 91
Ressource, 158
rhosts, 194
Roaming, 17
Round Trip Time, 3
route, 47
route.conf, 48
Router, 44, 47, 174
Routing, 37, 46
Routingtabellen, 49
RPC, 157
RR, 91
RTS, 17
RTT, 3
RWHO, 64
Samba, 129
Schnittstelle, 5
scp, 192
Second-Level-Domain, 86
Secure Shell, 200
Secure Socket Layer, 200
SecureShell, 192
Sendefilter, 29
Sequencenummern, 64
Server, 200
ServerAlias, 105
ServerName, 105
Service, 189
services, 63, 157
shadow, 190
Shannon, 28
Sicherheit, 64
Sicherungsschicht, 200
Signal Noise Ratio, 4
Signalstörung, 18
Signierung, 200
Simple Network Management Protocol, 173
INDEX
Sitzungsschicht, 9
slapd, 163
Sliding-Window, 64
SMB, 129
smbclient, 130, 132
smbd, 131, 138
smbmount, 130
smbpasswd, 145
smbstatus, 135
SMI, 175
SMTP, 111
SNMP, 64, 173, 183
SNR, 4
SOA, 87
Socket, 63, 227
SOCKS, 202
Sourcecode, 67
SSH, 200
ssh, 192
ssh-agent, 193
SSL, 200
Start Of Authority, 87
State-Machine, 64
Structure of Management Information, 175
Subdomain, 88
subnetting, 50
Subnetz, 72
Suffix, 40
Swap, 187
Switch, 14
Synchronize, 63
Systembefehl, 2
TCP, 62, 192, 199, 204, 227
TCP/IP, 6
Telefonnetze, 35
Telnet, 199
telnet, 193
Terminalemulation, 9
TFTP, 127
Thin-Client, 71
Three-Way-Handshake, 64
Time-To-Live, 89
TokenRing, 11, 19
Tokenring, 24
Toplevel-Domain, 85
traceroute, 47
Transmission Control Protocol, 62, 63
Transportprotokoll, 201
Transportschicht, 9
INDEX
Trojaner, 200
TTL, 89
Twisted Pair Kabel, 16
UDP, 64, 192, 201, 204, 227
UDPPaket, 201
Umgebungsvariable, 193
Universal Mobile Telecommunications System, 27
unix, 227
Urgend, 63
Urgendpointer, 63
User Datagram Protocol, 64
User Datagramm Protocol, 64
UTMS, 27
Verarbeitungsschicht, 9, 36
Verbindung, 192, 200–202, 207
Verbindungsverhalten, 63
Vermittlungsschicht, 8
Verzeichnis, 85
Virtual Private Network, 201
Visualisierung, 48, 176, 183
Voice-over-IP, 97
VPN, 201
WAN, 7, 25, 27, 36
Webbrowser, 200
well-known services, 63
whois, 86
Wide Area Network, 25, 27
WIN¿, 84
Window-Size, 64
Windows, 129
Windows-Namensdienst, 132
WINS, 130, 132, 140
Wireless LANs, 16
xhost, 194
xinetd, 125, 193
xinetd.conf, 193
XML, 184
Yellow Pages, 157
ypbind, 157
ypserv, 157
ypset, 157
Zähler, 175, 230
Zertifikat, 200, 211, 216
Zieladresse, 20, 38, 63
Zone, 88
287