Ein Mehrbenutzersystem in der Praxis Netzwerk Linux/Unix

Ein Mehrbenutzersystem in der Praxis 

Netzwerk 

Linux/Unix 

Kursunterlagen 

-Universitäten Göttingen und Freiburg- 

printer 

Internet 

WAN 

hera 

.dom.test 

zeus 

.dom.test 

LAN 

WLAN 

192.168.1.0/24 

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.1 Zu diesen Unterlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Bezeichnung von Dateien und Verzeichnissen . . . . . . . . . . . . . . . . . 2 

1.3 Begriffserklärungen - Bereich Netzwerk . . . . . . . . . . . . . . . . . . . . . 2 

1.4 Begriffserklärungen - Telefonie . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2 OSI-Schichtenmodell 9 

2.1 Kategorisierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2 Protokollhierarchien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2.1 Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.4 Die einzelnen Schichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.4.1 Bitübertragungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.4.2 Sicherungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.4.3 Vermittlungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.4.4 Transportschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.4.5 Sitzungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.4.6 Darstellungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.4.7 Verarbeitungsschicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.5 Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.5.1 Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.6 Einordnungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.7 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.7.1 OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.7.2 Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3 LAN Hardware 17 

3.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

3.1.1 Ethernet-Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

3.1.2 Koaxialkabelbasierte Netze für 10 MBit . . . . . . . . . . . . . . . . 19 

3.1.3 Twisted-Pair-basierte Verkabelungen 10/100 Mbit . . . . . . . . . . . 20 

3.1.4 1000 Mbit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

3.1.5 Ethernet unter Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

3.2 Funk-Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

3.3 TokenRing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

3.4 Netzwerk-Interfaces von Linux . . . . . . . . . . . . . . . . . . . . . . . . . 26 

3.5 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

3.5.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

3

4 INHALTSVERZEICHNIS 

4 WAN Hardware 29 

4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

4.2 Leistung und Kosten der einzelnen Technologien . . . . . . . . . . . . . . . 30 

4.2.1 Leistung / Datendurchsatz . . . . . . . . . . . . . . . . . . . . . . . 30 

4.2.2 Kosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

4.3 Telefonnetze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 

4.3.1 Das klassische Telefonnetz . . . . . . . . . . . . . . . . . . . . . . . . 31 

4.3.2 Digitale Telefonnetze - ISDN . . . . . . . . . . . . . . . . . . . . . . 31 

4.3.3 Mobilfunknetze nach dem GSM-Standard . . . . . . . . . . . . . . . 32 

4.3.4 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

4.3.5 HSCSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

4.3.6 Mobilfunknetze der dritten Generation - UMTS . . . . . . . . . . . . 33 

4.4 ISDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

4.5 Modem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

4.6 ADSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

4.6.1 Designüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 

4.6.2 Übertragungsmethoden . . . . . . . . . . . . . . . . . . . . . . . . . 35 

4.6.3 Vorteile der neuen Technik . . . . . . . . . . . . . . . . . . . . . . . 36 

4.6.4 Benutzung unter Linux . . . . . . . . . . . . . . . . . . . . . . . . . 37 

4.7 ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

4.7.1 Die ATM-Zelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

4.8 FDDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

4.9 Mobilfunknetze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

4.9.1 GSM, HSCSD, GPRS und UMTS . . . . . . . . . . . . . . . . . . . 40 

4.10 Netzwerkadapter für Mobilfunknetze . . . . . . . . . . . . . . . . . . . . . . 41 

5 TCP-IP 43 

5.1 Schaffung von ”Inter-Nets” . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

5.2 Überblick über TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

5.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

5.4 Internet Protocol (IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

5.5 Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

5.5.1 IPv4-Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

5.5.2 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

5.5.3 Adressbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

5.5.4 Spezielle IP-Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . 50 

5.5.5 Private IP-Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

5.6 Der IP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

5.6.1 Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

5.7 IP-Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

5.7.1 Prinzip der IP-Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

5.7.2 Routing (Die Wege im Netz) . . . . . . . . . . . . . . . . . . . . . . 55 

5.7.3 Einfaches Hostrouting . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

5.7.4 Routingentscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

5.7.5 Subnetting und Supernetting . . . . . . . . . . . . . . . . . . . . . . 58 

5.7.6 QoS-Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

5.8 Address Resolution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

5.8.1 ARP - Hilfsprotokoll des IP . . . . . . . . . . . . . . . . . . . . . . . 61 

5.8.2 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

INHALTSVERZEICHNIS 5 

5.8.3 ARP unter Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

5.8.4 Eingebaute Sicherheitslücken . . . . . . . . . . . . . . . . . . . . . . 66 

5.8.5 Gefahrenabwehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

5.8.6 ARP und doppelte IP-Adressen . . . . . . . . . . . . . . . . . . . . . 69 

5.8.7 Proxy-ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

5.8.8 Probleme durch Proxy-ARP . . . . . . . . . . . . . . . . . . . . . . . 71 

5.9 ICMP - Internet Control Message Protocol . . . . . . . . . . . . . . . . . . 72 

5.10 Domain-Name-Service (DNS) . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

5.11 Transmission Control Protocol (TCP) . . . . . . . . . . . . . . . . . . . . . 75 

5.12 User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . . . . . . . . . . 77 

5.13 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

5.14 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

5.14.1 Internets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

5.14.2 Internet Protokoll / Header . . . . . . . . . . . . . . . . . . . . . . . 78 

5.14.3 IP-Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

5.14.4 Fragmentierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

5.14.5 IP-Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

5.14.6 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

6 Linux im Netzwerk 81 

6.1 IP-Konfiguration unter Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 81 

6.1.1 Die traditionellen Tools . . . . . . . . . . . . . . . . . . . . . . . . . 81 

6.1.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 

6.1.3 Next Generation IP-Config . . . . . . . . . . . . . . . . . . . . . . . 83 

6.1.4 Das Kommando ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

6.1.5 Erste Schritte mit ip . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

6.2 Weitergehende Anwendungen von IProute2 . . . . . . . . . . . . . . . . . . 86 

6.2.1 Weitere Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 

6.2.2 Routing Policy Database . . . . . . . . . . . . . . . . . . . . . . . . 88 

6.2.3 Generelle 2-Wege-Routen . . . . . . . . . . . . . . . . . . . . . . . . 89 

6.2.4 Dienste-basiertes Routing . . . . . . . . . . . . . . . . . . . . . . . . 91 

6.3 Überprüfung der Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . 91 

6.4 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 

6.4.1 IP-Konfiguration und Erreichbarkeit . . . . . . . . . . . . . . . . . . 91 

6.4.2 Datenverkehr zählen . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 

7 DHCP 93 

7.1 Automatische IP-Zuweisung . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

7.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 

7.3 DHCP-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 

7.3.1 DHCP-Standardoptionen . . . . . . . . . . . . . . . . . . . . . . . . 97 

7.3.2 DHCP-DNS-Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . 98 

7.4 Benutzerdefinierte Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 

7.5 Die Verwendung von Vendor-Code-Identifiern . . . . . . . . . . . . . . . . . 100 

7.6 DHCP-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

7.7 DHCP mit LDAP-Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 

7.8 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 

7.8.1 DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106


8 DNS 107 

8.1 Einstieg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 

8.1.1 Enstehungsgeschichte . . . . . . . . . . . . . . . . . . . . . . . . . . 107 

8.1.2 DNS - Das virtuelle IP-Telefonbuch . . . . . . . . . . . . . . . . . . 109 

8.1.3 Regeln für die Namensgebung . . . . . . . . . . . . . . . . . . . . . . 109 

8.1.4 Registrieren und Verwalten von Domains . . . . . . . . . . . . . . . 110 

8.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 

8.2.1 Nameserver und Zuständigkeiten . . . . . . . . . . . . . . . . . . . . 111 

8.2.2 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 

8.2.3 Primärer und sekundäre Nameserver . . . . . . . . . . . . . . . . . . 113 

8.3 DNS-Server mit Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 

8.3.1 Der Dämon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 

8.3.2 Die DNS-Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 

8.3.3 Starten und Anhalten des Nameservers . . . . . . . . . . . . . . . . 117 

8.3.4 Slave-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 

8.3.5 Delegation einer Subdomain . . . . . . . . . . . . . . . . . . . . . . . 118 

8.4 Dynamische Updates der Zonendateien . . . . . . . . . . . . . . . . . . . . . 119 

8.4.1 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 

8.5 DNS bekommt neue Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . 121 

8.5.1 ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 

8.5.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 

8.5.3 DNS als Bannerfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 

8.6 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 

8.6.1 Rechnernamen im Internet . . . . . . . . . . . . . . . . . . . . . . . 123 

8.6.2 Domain Name Service (DNS) . . . . . . . . . . . . . . . . . . . . . . 124 

8.6.3 DNS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 

9 Webserver 125 

9.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 

9.2 HTTP-Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 

9.3 Was ist ein Webserver? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 

9.4 Apache 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 

9.4.1 Erweiterte Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . 127 

9.5 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 

9.5.1 Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 

9.5.2 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

9.5.3 User-WWW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

9.6 Webserver Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 

9.6.1 Die Benutzer-Homepage - mod userdir . . . . . . . . . . . . . . . . . 131 

9.6.2 URL-Umschreiber mod rewrite . . . . . . . . . . . . . . . . . . . . . 131 

9.6.3 Zugriffskontrollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 

9.6.4 Kompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 

9.6.5 Das Web-DAV Modul . . . . . . . . . . . . . . . . . . . . . . . . . . 133 

9.6.6 Vrituelle Webserver . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 

9.7 SSL (Secure Socket Layer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 

9.7.1 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

9.7.2 Zertifikate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

9.7.3 Zertifikate erzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 

9.7.4 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137


9.8 CGI (-Modul) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

9.9 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 

9.9.1 Das Apache-PHP-Modul . . . . . . . . . . . . . . . . . . . . . . . . . 139 

9.10 SSI (Server Side Includes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

9.11 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 


9.13 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 


9.15 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 


9.17 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

10 Mail 145 

10.1 SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

10.1.1 E-Mail-Adresse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 

10.1.2 Versenden einer E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . 147 

10.1.3 Mail-Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 

10.1.4 E-Mail Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

10.1.5 Open-Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

10.1.6 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

10.2 sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 

10.3 exim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 

10.4 POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 

10.5 IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 

10.6 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

10.6.1 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 

11 Fileserver 157 

11.1 Unix-Netzwerkdateisystem - NFS . . . . . . . . . . . . . . . . . . . . . . . . 157 

11.1.1 NFS im Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

11.1.2 NFS und Portmapper . . . . . . . . . . . . . . . . . . . . . . . . . . 159 

11.1.3 NFS-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

11.1.4 NFS-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 

11.1.5 NFS und (Un)Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . 161 

11.2 Andrew Filesystem (AFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

11.2.1 Die Clientseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

11.3 File Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

11.3.1 Dateiarchiv - FTP-Server . . . . . . . . . . . . . . . . . . . . . . . . 166 

11.3.2 FTP-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

11.4 Das Minimal-FTP (TFTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 

11.5 Weitere Fileserver-Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

11.6 Network Block Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 

11.7 NBDs im Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 

11.7.1 Erste Versuche mit NBD . . . . . . . . . . . . . . . . . . . . . . . . 171 

11.7.2 NBD und Filesysteme . . . . . . . . . . . . . . . . . . . . . . . . . . 172 

11.7.3 DNBD - eine spezialisierte Alternative . . . . . . . . . . . . . . . . . 173 

11.8 Spezielle Blockdevice-Erweiterungen . . . . . . . . . . . . . . . . . . . . . . 175


12 Samba 177 

12.1 Samba - Brücke zwischen Microsoft- und Unix-Welt . . . . . . . . . . . . . 177 

12.1.1 Einsatzgebiete von Samba . . . . . . . . . . . . . . . . . . . . . . . . 177 

12.2 Erste Versuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 

12.2.1 Windows-Server - Linux-Client . . . . . . . . . . . . . . . . . . . . . 178 

12.2.2 Linux-Server - Windows-Client . . . . . . . . . . . . . . . . . . . . . 180 

12.3 Weitergehende Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 181 

12.3.1 Homeverzeichnisse für Windows und Linux . . . . . . . . . . . . . . 183 

12.3.2 Druckerfreigaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 

12.3.3 Nachrichtendienst auf Linux-Clients . . . . . . . . . . . . . . . . . . 184 

12.4 Die zentrale Samba-Konfigurationsdatei . . . . . . . . . . . . . . . . . . . . 184 

12.4.1 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 

12.4.2 Wichtige Optionen in der Sektion [global] . . . . . . . . . . . . . . . 185 

12.4.3 Wichtige Optionen der anderen Abschnitte . . . . . . . . . . . . . . 186 

12.4.4 Virtuelle Samba-Server . . . . . . . . . . . . . . . . . . . . . . . . . 187 

12.5 Controller-Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

12.5.1 Der Windows Namensdienst . . . . . . . . . . . . . . . . . . . . . . . 187 

12.5.2 NetBIOS Namen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 

12.5.3 Der Nameserver (WINS) . . . . . . . . . . . . . . . . . . . . . . . . . 190 

12.6 Samba als PDC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 

12.6.1 Benutzerprofile und Logon-Skripten . . . . . . . . . . . . . . . . . . 192 

12.7 Samba und LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 

12.7.1 Konfiguration des LDAP-Servers . . . . . . . . . . . . . . . . . . . . 195 

12.7.2 Die neue Samba-Konfiguration . . . . . . . . . . . . . . . . . . . . . 195 

12.7.3 Die IDEALX-Skripten . . . . . . . . . . . . . . . . . . . . . . . . . . 197 

12.7.4 Fazit von Samba-LDAP-Aktionen . . . . . . . . . . . . . . . . . . . 202 

13 Ressourcenverwaltung 203 


13.2 NIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 

13.2.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 

13.2.2 NIS-Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 

13.2.3 NIS-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

13.2.4 NIS-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

13.3 Hierarchische Datenbank: LDAP . . . . . . . . . . . . . . . . . . . . . . . . 204 

13.3.1 Intro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 

13.3.2 Was kann mit LDAP abgebildet werden . . . . . . . . . . . . . . . . 205 

13.3.3 Das Datenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 

13.3.4 Das Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 

13.4 LDAP praktisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 

13.4.1 Server- und Clientprogramme unter Linux . . . . . . . . . . . . . . . 209 

13.4.2 Eine einfache Beispielkonfiguration . . . . . . . . . . . . . . . . . . . 210 

13.4.3 Absicherung durch SSL . . . . . . . . . . . . . . . . . . . . . . . . . 213 

14 Drucken im Netz 219 


14.1.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 

14.1.2 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 

14.2 CUPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220


14.2.1 Client-Server-Architektur . . . . . . . . . . . . . . . . . . . . . . . . 221 

14.2.2 IPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 

14.2.3 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

14.2.4 Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

14.2.5 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

14.3 Alternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 

15 Wichtige Netzwerkkommandos 225 

15.1 Offene Dateien und Netzwerkverbindungen . . . . . . . . . . . . . . . . . . 225 

15.2 netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 

15.3 Systemprogramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 

15.3.1 Dämonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 

15.4 Netzwerkkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 

15.4.1 Netzwerktests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 

15.4.2 Netzwerküberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . 229 

16 Netzwerküberwachung 

16.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

231 

231 

16.2 SNMP - Das Simple Network Mangement Protocol . . . . . . . . . . . . . . 

16.2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

231 

231 

16.3 Die Datendefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 

16.3.1 Der SNMP-Namensraum und die Management Information Bases . . 233 

16.3.2 Die SNMP-Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 

16.3.3 Der Kommunikations-Code der Agenten . . . . . . . . . . . . . . . . 234 

16.4 SNMP-Implementierungen unter Linux . . . . . . . . . . . . . . . . . . . . . 235 

16.5 Kommandos zur Datenbeschaffung . . . . . . . . . . . . . . . . . . . . . . . 235 

16.6 Konfiguration des UCD-SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 236 

16.6.1 Der Kopf definiert die Zugriffs-Policies . . . . . . . . . . . . . . . . . 236 

16.6.2 Parameter der ”Enterprise”-Erweiterungen . . . . . . . . . . . . . . 237 

16.6.3 Erweiterung durch externe Skripten und Programme . . . . . . . . . 237 

16.7 Überwachung weiterer Parameter . . . . . . . . . . . . . . . . . . . . . . . . 238 

16.7.1 Weitergehende Ergänzungen . . . . . . . . . . . . . . . . . . . . . . . 239 

16.7.2 Parameter der Host-Ressource-Erweiterungen . . . . . . . . . . . . . 240 

16.8 MRTG als Frontend zur Anzeige von Zeitreihen . . . . . . . . . . . . . . . . 241 

16.9 Einige abschließende Worte zu SNMP . . . . . . . . . . . . . . . . . . . . . 242 

16.10Weiterführende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 

17 Systemsicherheit 245 

17.1 Generelle Überlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

17.2 Sicherheit auf dem Rechner . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

17.2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

17.2.2 Passwörter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 

17.2.3 Der Admin-Account . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

17.2.4 /etc/passwd und /etc/shadow . . . . . . . . . . . . . . . . . . . . . . 246 

17.2.5 Locken oder ausloggen . . . . . . . . . . . . . . . . . . . . . . . . . . 246 

17.2.6 Setuid und Verzeichnisse . . . . . . . . . . . . . . . . . . . . . . . . . 246 

17.2.7 Setuid und Mounting . . . . . . . . . . . . . . . . . . . . . . . . . . 247 

17.2.8 Browser, CGI / Java-Applet und Binaries, per Mail . . . . . . . . . 247 

17.2.9 Physikalischer Zugriff . . . . . . . . . . . . . . . . . . . . . . . . . . 247 

17.3 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247


17.4 Sicherheit im Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 

17.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 

17.4.2 Gesicherte Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . 248 

17.4.3 ssh und scp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 

17.4.4 Der Intenet-”Super”-Daemon (x)inetd . . . . . . . . . . . . . . . . . 249 

17.4.5 xhost + und das unsichtbare Fenster . . . . . . . . . . . . . . . . . . 250 

17.4.6 .rhosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 

17.4.7 

Überprüfung der Netzwerksicherheit eigener und anderer Rechner . . 250 

17.4.8 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 

17.5 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 

17.5.1 Secure Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 

18 Sicheres IP 253 

18.1 Sicherheitsprobleme des derzeitigen IP-Standards . . . . . . . . . . . . . . . 253 

18.1.1 Intro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 

18.1.2 Offener Datentransport . . . . . . . . . . . . . . . . . . . . . . . . . 253 

18.1.3 Absicherung - Lösungsansätze . . . . . . . . . . . . . . . . . . . . . . 255 

18.2 VPNs - Sichere Netze über das Internet . . . . . . . . . . . . . . . . . . . . 257 

18.3 CIPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 

18.3.1 Idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 

18.3.2 Aufsetzen von CIPE . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 

18.4 IPsec-Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

18.5 IPsec praktisch - FreeSWAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 

18.5.1 Konfigurationsmöglichkeiten von IPsec . . . . . . . . . . . . . . . . . 263 

18.5.2 Einrichtung von IPsec unter Linux . . . . . . . . . . . . . . . . . . . 264 

18.5.3 Einschaltbare Optionen . . . . . . . . . . . . . . . . . . . . . . . . . 265 

18.5.4 Konfiguration von IPsec-Verbindungen . . . . . . . . . . . . . . . . . 266 

18.6 Kommerzielle VPN-Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

18.6.1 Cisco-VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 

18.6.2 Verwendung der Cisco-Tools . . . . . . . . . . . . . . . . . . . . . . . 270 

18.6.3 Einsatzszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272 

18.6.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 

18.7 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 

19 Firewall 275 

19.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 

19.2 Ein- und Austragen von chains und Filter-Regeln . . . . . . . . . . . . . . . 276 

19.2.1 Pakete genauer spezifizieren . . . . . . . . . . . . . . . . . . . . . . . 276 

19.2.2 ”Match Extensions” und Erweiterbarkeit . . . . . . . . . . . . . . . 277 

19.3 von ”masquerading” und ”packet mangling” . . . . . . . . . . . . . . . . . . 279 

19.3.1 Network Address Translation . . . . . . . . . . . . . . . . . . . . . . 279 

19.3.2 packet mangling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 

19.4 connection tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 

19.5 Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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”-Projekt 2 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 wis- 

1 beispielsweise per Mail an dirk@goe.net 

2 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 3dB 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, 0dBm 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.


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. UDP- 

Ports. 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-Super- 

Daemon (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 Unix- 

Systemen. 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.


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 Zweidraht- 

Kupferschnittstelle 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 Telefonie- 

Netzwerk. 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.


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-Band- 

Signalisierung 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 

6 

5 

4 

3 

2 

1 

Application 

Presentation 

Session 

Transport 

Network 

Data link 

Physical 

ftp,http,smtp,pop3 

A 

TCP, UDP, SPX, Appleshare 

IP, IPX, Appletalk 

N 

Ethernet-, ATM-Switch 

Ethernet, TokenRing, ISDN 

Application 

Presentation 

Session 

Transport 

Network 

Data link 

Physical 

Host A Host B 

Real Connection 

A User-Application 

Virtual Connection 

Flow of Data from A to B 

N Network-Protocol 

Abbildung 2.1: OSI-Schichtenmodell 

Name of Unit 

Packet 

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. 

Frame 

Bit

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 OSI- 

Modells 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. 

# Schicht Layer 

(engl.) 

7 Anwendungs- application 

- 

6 Darstellungs- presentation 

- 

5 Kommunikationssteuer 

Orientiert Aufgabe Prot. 

Anwen-dungs- Verbindung zwischen 

Benutzern 

und deren Tätigkeiten 

Anwendungs- Datenformat des 

Informationsaustausches 

session - Anwendungs- Verbindung zwischen 

Prozessen 

auf verschiedenen 

Rechnern 

4 Transport- transport - Transport- Zusammensetzung 

der Nachrichten 

3 Vermittlungs- network - Transport- Adressierung 

der Nachrichten 

zwischen Rechnern 

2 Sicherungs- data link - Transport- Beseitigung 

Übertraguns- 

von 

fehlern 

Störungen 

durch 

1 Bitübertraphysical - Transport- Betrieb der Netzgungskarten 

Tabelle 2.1: Das OSI-Modell mit Beispiel FTP als TCP/IP-Protokoll 

FTP 

TCP 

TCP 

IP


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 

2 z.B. für die Paketdurchleitung; da kaum ein Anbieter jede End-zu-Endverbindung im eigenen Netz 

realisieren kann

2.5. KONZEPTE 13 

2.4.4 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 Weise 3 . 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 Terminalemulation 4 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.


Diese Hardwarekomponenten können wie Hosts mit mindestens zwei Interfaces aufgefaßt 

werden. Sie sollen sich wie ein Host 5 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 

Host A Eth-HUB Router Switch Host B 

2.7 Aufgaben 

2.7.1 OSI 

Abbildung 2.2: Weg eines Paketes durch OSI-Schichten 

1. Worin unterscheiden sich das OSI- und TCP-Schichtenmodell? 

6 Carrier Sense Multiple Access with Collision Detection bzw. Collision Avoidance 

Schicht 

7 

6 

5 

4 

3 

2 

1


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 

Application 

Presentation 

Session 

Transport 

Network 

Data Link 

IEEE 802.3 

reference model 

Upper-layer 

protocols 

MAC-Client 

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 Length/Type Data Pad FCS 

7 1 6 6 4 46 - 1500 4 

Field length in bytes 

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-IP- 

Adressen 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 

TERM 

50Ohm 

max. 30 Stationen pro Segment max. 100 Stationen pro Segment 

PC 1 

CHEAPER-NET T-Connector 

2,5m 

PC 2 

TERM 

50Ohm TERM 

50Ohm 

WS 1 WS 2 WS 3 

10Base2 max. 4 Repeater 

Repeater 

10Base5 

185m 

MAUI 

500m 

Abbildung 3.3: Regeln in BNC-Netzen 

YELLOW-CABLE 

TERM 

50Ohm 

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


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 “Cross- 

Connenct-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 1000Mbit 

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 Data Pad FCS 

7 1 6 6 4 46 - 1500 4 

Field length in bytes 

Extension 

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 Interface- 

Geschwindigkeiten, 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 Via- 

Rhine, 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.


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-Sublayer- 

Protokoll 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 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 

5

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. 6Mbit/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äle 1 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.


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:


Priorität Anwendung 

0 frei verfügbar, von den meisten Anwendungen verwendet 

1-3 frei verfügbar 

4 von Bridges verwendet 

5,6 reserviert, jedoch nicht verwendet 

7 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 



collisions:0 txqueuelen:100


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 





vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08 


inet6 addr: fe80::250:56ff:fec0:8/10 Scope:Link 






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 KAPITEL 4. WAN HARDWARE 

4.2 Leistung und Kosten der einzelnen Technologien 

4.2.1 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 Reichweite Knoten Durchsatz 

Funk-LAN einige 100m ca. 20 - 50 2 - 11 Mbits 

ADSL mehrere km - 0.5 - 7.6 Mbit 

ATM mehrere km ???? 2 - 622 Mbits 

Ethernet (TP) 100 m 2 - ... 10 - 1000 Mbits 

Ethernet (BNC) 185 m ca. 35 10 Mbits 

ISDN - - ¿ 64 Kbits 

loopback 0 1 ¿ 100 Mbits 

Modem - 2 0.3 - 56 Kbits 

GPRS/HSCSD mehrere km - 0.3 - 56 KBit 

UMTS mehrere km - 128 - 386 KBit 

Serieller Port 30 m 2 300 - 112000 Bits 

Tokenring 100 m 8 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 Zweidraht- 

Kupfer-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 31 

Medium Adapter Kabel Gebühren (ca. EUR) 

ATM 300 - 600 EUR 4/m (LWL) Grosskunde 

Parallelport 5 - 10 10 - 

Ethernet (TP 1000) 15 - 100 EUR 0.70/m - 

Ethernet (TP 100) 4 - 40 EUR 0.70/m - 

Ethernet (TP 10) – 0.70/m - 

Ethernet (BNC 10) – 0.20/m - 

Funk-LAN (2/11 Mbit) 100 - 200 EUR 500/AccessPoint - 

ISDN 100 - Telefongebühren 

Modem 80 - 200 - Telefongebühren 

GPRS 40 - 300 EUR - saftige Volumengebühr 

HSCSD 40 - 200 EUR - saftige Zeitgebühr 

UMTS 80 - 300 EUR - saftige Volumengebühr 

Serieller Port – 5 0 

TokenRing – 0.70/m - 

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. 

Übertragungs- Datenrate Datenrate Reichweite Verfügbarkeit 

methoden Upstream Downstream in Meter in Deutschland 

Analoge Modems 33.6 kbps 56 kbps etliche km verfügbar 

IDSN 128 kbps 128 kbps etliche km verfügbar 

Symmetrisches DSL 2048 kbps 2048 kbps 4000 verfügbar 

ADSL (DMT) 768 kbps 8 Mbps 6000 verfügbar 

ADSL (CAP) 64 kbps 1,54 Mbps 6000 verfügbar 

640 kbps 6,14 Mbps 4000 Testphase 

VDSL 640 kbps 13 Mbps 1500 Testphase 

1,6 bis 2,3 Mbps 52 Mbps 300 Testphase 

Kabelmodems 768 kbps 30 Mbps je nach Kabel 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


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 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. 

Ü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 Download- 

Kanal. 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 2GHz 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.


4.4 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 4kHz 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 35 

4.6.1 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 ADSL- 

Spezifikation - 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 Übertragungsmethoden 

4.6.2.1 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


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 

PPPoE 2 , 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 PPPoE- 

Protokoll 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.


• Feste Paketlänge: ATM nutzt zur Übertragung ausschließlich Pakete mit einer festen 

Länge von 53 Bytes. Diese kleinste unteilbare Übertragungseinheit wird daher ATM- 

Zelle 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 5Bytes 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 4 5 6 7 8 Bit 

Flow Control (GFC) 

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 ATM- 

Vermittlungsstellen 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 Bedeutung 

000 Benutzerzelle, keine Überlast festgestellt, SDU-Type=0 

001 Benutzerzelle, keine Überlast festgestellt, SDU-Type=1 

010 Benutzerzelle, Überlast festgestellt, SDU-Type=0 

011 Benutzerzelle, Überlast festgestellt, SDU-Type=1 

100 Segment-OAM-F5-Zelle 

101 End-to-End-OAM-F5-Zelle 

110 Reserviert für zukünftiges Lastmanagement 

111 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 CRC- 

Feld) 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


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. 

ATM over 

ADSL 

Router n 

TokenRing 

172.16.1.0/24 

Internet 

Ethernet 

1000Base-X 

ATM over 

ADSL 

#1 

192.168.1.0/24 

192.168.2.0/22 

#3 

Router 1 

#2 

Ethernet 803.11a 

10Base-T 

#2 

#1 

Router 2 

Ethernet 

100Base-T 

Abbildung 5.1: IP als Universalservice 

192.168.6.0/24 

#1 

FDDI Router 3 

192.168.10.0/24 

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 ISDN- 

Adapter 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 implementiert 1 aber z.B. nicht für Zwei- 

Draht-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-zu- 

Punkt-Verbindungen zwischen jeweils zwei dedizierten Interfaces 2 . Verschiedene physikali- 

1 Es existieren jeweils Standards für Koaxialkabel (10Base5 ThickEthernet/Yellow-Cable bzw. 10Base2 

für Cheapternet), TwistedPair-Kabel (4bzw. 8adrig), 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 

#2

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 Technologie 3 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 OSI- 

Referenzmodell 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 DNS DHCP 

Transmission 

Control P. (TCP) 

Internet Protocol (IP) 

ICMP / ARP 

User Datagram 

Protocol (UDP) 

Ethernet ATM FDDI Modem ISDN 

Abbildung 5.2: Der TCP/IP-Protokoll-Stapel 

Application 

Layer 

Transport 

Layer 

Internet 

Layer 

Network 

Layer 

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 IP- 

Adressen (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 Logik- 

Bausteinen analysiert werden und sehr schnell mit Netzmasken und Broadcastadressen zum 

Routing berechnet werden.


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 Schemata 

5 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 Header 6 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 an- 

4 48 

Obwohl das MAC-Adressierungsschema des Ethernets z.B. mit 2 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 Zustellver- 

merke 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-End- 

Zustellung 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-zu- 

Ende-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


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 Punkt- 

Dezimal-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 49 

5.5.3 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. 

Class 

A 0 

B 

C 

D 

E 

1 0 

1 1 0 

11 1 0 

11 11 

8 bits 8 bits 8 bits 8 bits 

network 

net 

work 

net 

work 

host host host 

network 

network network 

host host 

host 

multicast multicast multicast 

experi 

mental 

experi 

mental 

Abbildung 5.3: Adressbereiche des IPv4 

experi 

mental 

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önnen 8 . 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.


Bezeichnung Präfix Suffix Netze Hosts pro Netz 

Class A 7 bit 24 bit 128 16.777.216 

Class B 14 bit 16 bit 16.38 65.536 

Class C 21 bit 8bit 2.097.152 256 

5.5.4 Spezielle IP-Adressen 

Tabelle 5.1: Aufteilung der IP-Adressklassen 

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 Netzwerk 9 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-Host- 

Kommunikation 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 Beispiel Anzahl der Einsen 

Class A 10.0.0.0 8 

Class B 132.230.0.0 16 

Class C 192.168.20.0 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-Netz 10 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) reserviert 11 . 

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 

11 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.


• 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; Fragmentierung 

12 ; ”Verfallsdatum” 13 ; Länge des Pakets und die Prüfsumme. 

VERS. 

IPHL 

IDENTIFICATION 

TYPE OF SERV. TOTAL LENGTH 

D 

F 

M 

F 

SOURCE ADDRESS 

DESTINATION ADDRESS 

FRAGMENT OFFSET 

TIME TO LIVE PROTOCOL HEADER CHECKSUM 

Die einzelnen Header-Bestandteile: 

32 bit 

OPTIONS (ZERO OR MORE WORDS) 

Abbildung 5.4: IP Paket-Header 

• 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 IP- 

Header 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 nicht alle darunterliegenden physikalischen oder logischen Netze haben die gleichen Eigenschaften 

13 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


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 Beschreibung 

networkaddress 

Adresse des eigenen Teil-Netzes, Vergleich mit IP- 

Adresse gibt an, ob ein Datenpaket zum lokalen Netz 

gehört oder nicht 

subnet-mask Bitmaske zum Herausstanzen der Netzwerk- Adresse 

aus der IP-Adresse einer Maschine 

ip-address 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 Netzadresse 14 und die 

Broadcast-Adresse 15 hinzu, kommt man für ein Class-C-Netz, wie hier dargestellt, auf 256 

IP-Adressen (= 2 8 ). 

14 die kleinste Adresse im Teilnetz, dieses ist eine nicht vergebbare IP! 

15 die grösste Adresse im Teilnetz, auch diese IP sollte nicht für Rechner vergeben werden!


5.7.2 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 Genmask Flags Metric Ref Use Iface 

10.1.1.11 10.2.13.254 255.255.255.255 UGH 0 0 0 wlan0 

10.8.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 

10.2.13.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 

127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo 

0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 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-Proc- 

Interface 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


9 * heise2.f.de.plusline.net (213.83.57.57) 13.433 ms 13.599 ms 

10 * * 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 Netzmaske Router-IP Interface 

192.168.20.0 255.255.255.0 - Ethernet, TokenRing, ... 

127.0.0.1 255.0.0.0 - Loopback-Interface 

0.0.0.0 0.0.0.0 192.168.20.254 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.


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 Netzmaske 17 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 Netzmaske Gateway/Router Interface 

192.168.20.128 255.255.255.128 192.2.2.2 #1 

192.168.20.0 256.255.255.128 193.2.2.3 #1 

10.10.2.0 255.255.255.0 10.10.255.254 #2 

10.10.0.0 255.255.0.0 10.10.0.254 #3 

10.4.0.0 255.252.0.0 10.10.0.254 #4 

10.0.0.0 255.0.0.0 192.168.2.5 #1 

0.0.0.0 0.0.0.0 10.10.0.254 #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 

Zuordnung 18 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 

18 Auch wenn es Firmen gibt, die zu jeder IP-Adresse eine ungefähre bis genaue geografische Koordinate 

liefern können.


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 Bitmuster der Netzmaske Teilnetze Anzahl IP’s 

255.255.0.0 11111111.11111111.00000000.00000000 1 65.536 

255.255.128.0 11111111.11111111.10000000.00000000 2 32.768 

255.255.192.0 11111111.11111111.11000000.00000000 4 16.384 

255.255.224.0 11111111.11111111.11100000.00000000 8 8.192 

255.255.240.0 11111111.11111111.11110000.00000000 16 4.096 

255.255.248.0 11111111.11111111.11111000.00000000 32 2.048 

255.255.252.0 11111111.11111111.11111100.00000000 64 1.024 

255.255.254.0 11111111.11111111.11111110.00000000 128 512 

255.255.255.0 11111111.11111111.11111111.00000000 256 256 

Tabelle 5.6: Subnetting in ”Klasse-B-Netzwerken” 

derzeitigen IPv4-Adressraum von 2 32 (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” stehen 19 , 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


netmask 255.255.255.0 11111111.11111111.11111111.00000000 

netmask 255.255.252.0 11111111.11111111.11111100.00000000 

netmask 255.255.0.0 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-B- 

Netz 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 Netzadresse(n) Netzmaske Broadcastadresse(n) Zahl der IP’s 

1 134.76.0.0 255.255.0.0 134.76.255.255 65.536 

2 134.76.0.0 255.255.128.0 134.76.127.255 32.768 

134.76.128.0 255.255.128.0 134.76.255.255 32.768 

4 134.76.0.0 255.255.192.0 134.76.63.255 16.384 

134.76.64.0 255.255.192.0 134.76.127.255 16.384 

134.76.128.0 255.255.192.0 134.76.191.255 16.384 

134.76.192.0 255.255.192.0 134.76.255.255 16.384 

8 134.76.0.0 255.255.224.0 134.76.31.255 8.192 

134.76.32.0 255.255.224.0 134.76.63.255 8.192 

134.76.64.0 255.255.224.0 134.76.127.255 8.192 

134.76.96.0 255.255.224.0 134.76.159.255 8.192 

134.76.128.0 255.255.224.0 134.76.191.255 8.192 

134.76.160.0 255.255.224.0 134.76.191.255 8.192 

134.76.192.0 255.255.224.0 134.76.223.255 8.192 

134.76.224.0 255.255.224.0 134.76.255.255 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 muss 20 . 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.


Teilnetze Netzadresse(n) Netzmaske Broadcastadresse(n) Zahl der IP’s 

16 134.76.0.0 255.255.240.0 134.76.15.255 4.096 

134.76.16.0 255.255.240.0 134.76.31.255 4.096 

134.76.32.0 255.255.240.0 134.76.47.255 4.096 

134.76.48.0 255.255.240.0 134.76.63.255 4.096 

134.76.64.0 255.255.240.0 134.76.79.255 4.096 

134.76.80.0 255.255.240.0 134.76.95.255 4.096 

134.76.96.0 255.255.240.0 134.76.111.255 4.096 

134.76.112.0 255.255.240.0 134.76.127.255 4.096 

134.76.128.0 255.255.240.0 134.76.143.255 4.096 

134.76.144.0 255.255.240.0 134.76.159.255 4.096 

134.76.160.0 255.255.240.0 134.76.175.255 4.096 

134.76.176.0 255.255.240.0 134.76.191.255 4.096 

134.76.192.0 255.255.240.0 134.76.207.255 4.096 

134.76.208.0 255.255.240.0 134.76.223.255 4.096 

134.76.224.0 255.255.240.0 134.76.239.255 4.096 

134.76.240.0 255.255.240.0 134.76.255.255 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 61 

5.8 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 Netzwerk- 

Hardware 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 IP- 

Adressen 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 Ethernet- 

Rahmen markiert wird. Die beiden 8bit Felder zu Beginn der nächsten Zeile bestimmen die 

Anzahl der Bytes für die Hardware- und Protokolladressen, in diesem Fall 6Byte für die 

Ethernetadresse und 4 Byte für die IP-Nummer. Das sich anschließende ”Operation”-Feld


HADDR LENGHT 

32 bit 

HARDWARE ADDRESS TYPE PROTOCOL ADDRESS TYPE 

PADDR LENGHT 

SENDER HADDR (last 2 Byte) 

SENDER PROTOCOL ADDRESS (last 2 Byte) 

SENDER HARDWARE ADDRESS (first 4 Byte) 

TARGET HARDWARE ADDRESS (last 4 Byte) 

TARGET PROTOCOL ADDRESS (all 4 Byte) 

OPERATION 

SENDER PROTOCOL ADDRESS (first 2 Byte) 

TARGET HADDR (first 2 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 verwendet 

21 , 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 Linux- 

Rechner 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.


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 10.8.4.2 

A B 

00:01:AA 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 MAC- 

Adresse 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 Ethernet- 

Typ 0x08086 ein, damit der Schrei von allen vermeindlich betroffenen Knotenpunkten 

wahrgenommen wird. Dieses Rundschreiben ”Ich kenne die MAC-Adresse X, die IP- 

Adresse 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


in umgekehrter Richtung walten zu lassen, da die relevanten Daten beim Zielsystem 

bereits bekannt sind. 

10.8.4.1 10.8.4.2 

A B 

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: mtu 16436 qdisc noqueue 

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 

2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 

link/ether 00:e0:81:55:06:01 brd ff:ff:ff:ff:ff:ff 

3: eth1: mtu 1500 qdisc noop qlen 1000 

link/ether 00:e0:81:55:06:00 brd ff:ff:ff:ff:ff:ff 

4: sit0: 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 Tunnel- 

Interface (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 HWaddress Flags Mask Iface 

10.8.4.222 ether 00:03:47:B9:DE:36 C eth0 

10.8.4.204 ether 00:02:B3:C2:55:91 C eth0 

10.8.4.254 ether 00:0C:6E:15:03:0E C eth0 

mobile root # arp -d 10.8.4.204 



10.8.4.222 ether 00:03:47:B9:DE:36 C eth0 

10.8.4.204 (incomplete) eth0 

10.8.4.254 ether 00:0C:6E:15:03:0E C eth0




10.8.4.222 ether 00:03:47:B9:DE:36 C eth0 

10.8.4.204 ether 00:02:B3:C2:55:91 C eth0 

10.8.4.254 ether 00:0C:6E:15:03:0E C eth0 

mobile root # arp -s 10.8.4.204 00:11:22:33:44:55 



10.8.4.222 ether 00:03:47:B9:DE:36 C eth0 

10.8.4.204 ether 00:11:22:33:44:55 CM eth0 

10.8.4.254 ether 00:0C:6E:15:03:0E C eth0 

mobile root # ping 10.8.4.204 

PING 10.8.4.204 (10.8.4.204) 56(84) bytes of data. 

--- 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 


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 


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 



collisions:0 Sendewarteschlangenlänge:0 


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 



collisions:0 Sendewarteschlangenlänge:0 


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


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 

10.8.4.1 10.8.4.2 

A B 

ARP-Reply: 

"10.8.1.1 is at 00:b0:11:33..." 

00:b0:11:11:11:11 00:b0:11:22:22:22 

10.8.4.50 

P 

00:b0:11:33:33:33 

Abbildung 5.8: 

ARP-Reply: 

"10.8.1.1 is at 00:b0:11:33..." 

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 ARP- 

Reply, 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”


00:b0:11:11:11:11 00:b0:11:22:22:22 

10.8.4.1 10.8.4.2 


A B 


00:b0:11:11... 

00:b0:11:33... 

10.8.4.1 10.8.4.2 

10.8.4.50 

P 

00:b0:11:33:33:33 



00:b0:11:33:33:33 

00:b0:11:22:22:22 

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 ”Man- 

In-The-Middle” bezeichnet. 

00:b0:11:11:11:11 00:b0:11:22:22:22 

10.8.4.1 10.8.4.2 


A B 

Paketlaufzeit1 

Hop-Count: TTL-1 

10.8.4.1 10.8.4.2 

10.8.4.50 

P 

00:b0:11:33:33:33 


Paketlaufzeit2 

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


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


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 ARP- 

Cache 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.


5.8.7 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 IP- 

Adresse 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-


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 MAC- 

Adresse 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 Subnetz- 

Adressierungs-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 Routenwahl- 

Mechanismen 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 Subnetz- 

Masken 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 ARP- 

Sturm 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-


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 Media- 

Speed-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. 





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


Kürzel Bedeutung Kürzel Bedeutung 

gov governemental com Unternehmen (”commercial”) 

de Deutschland edu Ausbildungseinrichtung 

net Netzwerk org Organisation 

Tabelle 5.9: Die traditionellen Domänenendungen 

Kürzel Bedeutung Kürzel Bedeutung 

name Privatpersonen biz Unternehmungen 

eu Europa info Informational 

ws ”WebSite” int 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-Name- 

Service) 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) 75 

5.11 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 

TCP-H 

Length 

SOURCE PORT DESTINATION PORT 

unused 

CHECKSUM 

SEQUENCE NUMBER 

ACKNOWLEDGEMENT NUMBER 

U 

R 

G 

A 

C 

K 

P 

S 

H 

R 

S 

T 

S 

Y 

N 

32bit 

F 

I 

N 

OPTIONS (0 or more 32bit words) 

BEGINNING OF DATA 

(optional) 

WINDOW SIZE 

URGENT POINTER 

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 (Port- 

Nummern) 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”


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 Hea- 

Service Port-Nummer Service Portnummer 

ftp 21 pop3 110 

ssh 22 ntp 123 

telnet 23 rsync 873 

smtp 25 imaps 993 

http 80 pop3s 995 

ldap 389 ldaps 636 

Tabelle 5.11: TCP-basierte Standardservices 

ders sind für diverse Flags vorgesehen. Sie steuern das Verbindungsverhalten eines TCP- 

Datenkanals. 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 gesetzt 24 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 Sliding- 

24 Da das Verfahren möglichst schnell und effizient arbeiten soll, wurde bei früheren TCP- 

Implementationen 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 lang 25 . 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


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 Leitungs- 

Belastung 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. 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?


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 Next Hop 

135.46.56.0/22 Interface 0 (direkt) 

135.46.60.0/22 Interface 1 (direkt) 

192.53.40.2/23 Router 1 

87.23.16.0/20 Router 2 

0.0.0.0/0 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 Routern 1 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 


inet6 addr: fe80::240:c7ff:fe99:35ad/10 Scope:Link 





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 





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 83 

linux:~ # route -n 

Kernel IP Routentabelle 

Ziel Router Genmask Flags Metric Ref Use Iface 

10.8.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 

192.168.15.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 

169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1 

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 

0.0.0.0 192.168.15.1 0.0.0.0 UG 0 0 0 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 start 2 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.


• 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 85 

6.1.5 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: 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 


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: mtu 1500 qdisc noop qlen 1000 

link/ether 00:0c:6e:15:03:0e brd ff:ff:ff:ff:ff:ff 

4: sit0: mtu 1480 qdisc noqueue 

link/sit 0.0.0.0 brd 0.0.0.0 

11: tun0: 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 IP- 

Erfahrung 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 


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


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 


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: 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 


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 87 

6.2.1 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 1011352 0.0 

IpForwDatagrams 48960 0.0 

IpInUnknownProtos 3 0.0 

IpInDelivers 953958 0.0 

IpOutRequests 1255516 0.0 

IpReasmReqds 16824 0.0 

IpReasmOKs 8412 0.0 

IpFragOKs 2 0.0 

IcmpInErrors 5437 0.0 

IcmpInDestUnreachs 5 0.0 

IcmpInTimeExcds 222 0.0 

IcmpInParmProbs 4736 0.0 

IcmpInEchoReps 476 0.0 

IcmpInTimestamps 3 0.0 

IcmpOutErrors 26789 0.0 

IcmpOutTimeExcds 26313 0.0 

IcmpOutTimestamps 476 0.0 

TcpActiveOpens 1258 0.0 

TcpPassiveOpens 323 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 Data/Rate TX Data/Rate 

RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate 

lo 3905 0 3905 0 393392 0 393392 0 

0 0 0 0 0 0 0 0 

eth0 915949 0 1120K 0 158546K 0 996987K 0 

0 0 0 0 0 0 0 0 

tun0 9071 0 13359 0 3535K 0 1090K 0 

0 0 0 0 0 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


ESTAB 0 0 132.230.129.7:56946 132.230.1.142:ssh 

ESTAB 0 0 10.8.4.254:57051 10.8.4.205:microsoft-ds 

ESTAB 0 0 132.230.129.7:56687 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 IP- 

Pakete 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 lookup local 

32765: from 192.168.100.100 lookup SrcRouting 

32766: from all lookup main 

32767: from all lookup default 

Zum Schluss wird noch das schnelle Gateway als Standard Route in die Tabelle Source- 

Routing 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 Default- 

Route 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:~# ip route add 132.230.129.0/28 dev eth0 src 132.230.129.1 table Route1 

linux02:~# ip route add default via 132.230.129.15 table Route1 

linux02:~# ip route add 80.168.20.0/25 dev eth1 src 80.168.20.125 table Route2 

linux02:~# ip route add default via 80.168.20.126 table Route2 

Die Routing Rules legen fest, welche Tabelle für welche IP herangezogen wird.


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 Metrik 3 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 91 

6.2.4 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:~# iptables -A OUTPUT -i eth0 -t mangle -p tcp --dport 22 -j MARK \ 

--set-Mark 1 

linux02:~# echo 200 ssh >> /etc/iproute2/rt_tables 

linux02:~# ip rule add fwmark 1 table ssh 

linux02:~# 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 Rechnernamen 4 . Ping 5 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 Erfolg 6 , kann man mit dem Kommando tcpdump überprüfen, ob 

überhaupt Datenpakete auf dem Netzwerkinterface eintreffen und vom Kernel registriert 

werden. 

6.4 Aufgaben 

6.4.1 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! 

5 weitere Informationen kann man sich über den Aufruf der Manualseiten mit man ping anzeigen lassen. 

6 das meint eine Meldung wie ”100” packet loss”


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 IP- 

Zuweisung 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 

DHCP 1 , 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 Internet- 

Software-Consortium 2 entwickelte eine Beispielimplementation des DHCP und einiger an- 

derer 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 Netzen 3 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-Spezialadressen 4 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 Ethernet bzw. TokenRing 

4 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 

1 

Konfiguration 

festlegen 

2 

3 

Konfiguration 

annehmen 

4 

5 

Lease 

entfernen 

Server Client 

DHCPDISCOVER 

DHCPOFFER 

DHCPREQUEST 

DHCPACK 

DHCPRELEASE 

Beginn der 

Initialisierung 

Konfiguration 

wÃ¤hlen 

Initialisierung 

abgeschlossen 

Sauberes 

Beenden 

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 DE- 

CLINE 

• Der Client kann die erhaltene Adresse vor Ablauf zurückgeben und hierfür ein RE- 

LEASE 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 6Byte 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


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 IP- 

Verbindungen 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 Textfelder 

6 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 X- 

Terminalbetrieb nicht erforderlich sind. 

# -- global options -default-lease-time 

160000; 

max-lease-time 200000; 

use-host-decl-names on; 

ddns-update-style none; 



option domain-name-servers 192.168.2.22; 

option domain-name "test.site, test2.site"; 

option nis-domain "chnsmi20"; 

6 Variablentyp ”string”


option nis-servers 192.168.2.3; 

option log-servers 192.168.2.4; 

option netbios-name-servers 192.168.2.5; 


# range 192.168.2.50 192.168.2.62; 

} 

# -- client specific -group 

{ 

host test1 { 

hardware ethernet 00:80:48:C2:DD:6A; 


host test2 { 

hardware ethernet 00:E0:4C:39:10:21; 


} 

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-DHCP- 

Servers. 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 Update- 

Informationen 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; 

[ ... ] 


range dynamic-bootp 10.10.10.10 10.16.10.250; 

option subnet-mask 255.255.255.0; 


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. 


zone ’239.168.192.in-addr.arpa/IN’: deleting an rrset 


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


den Standard 7 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 

Konfigurationsdateien 8 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; 



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 DHCP- 

Server 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-PXE- 

Image 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 abgesehen 10 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


} 

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 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 Shell- 

Skript 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 sichdhcpcd 

ethN 11 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 Bedeutung 

-d Generieren von Debug-Output 

-i VCID Schicken eines Vendor Class Identifiers. Andere Möglichkeit 

Clients anstatt mit der MAC-Adresse auseinanderzuhalten. 

-k 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.


7.7 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 Masney 12 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 LDAP- 

Backend 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 LD- 

AP beschäftigt sich ein eigener Abschnitt des Skriptes. 13 Für das Beispiel existiere bereits 

12 http://www.newwave.net/ masneyb 

13 Wenn dieser Teil nicht in der aktuellen Ausgabe enthalten ist, kann dieser über http://goe.net beschafft 

werden.

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: 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: 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: 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: dhcpHost


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 LD- 

AP 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” verwalten 14 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 Aufgaben 

7.8.1 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 Deutschland 1 

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 Full-Qualified-Hostname Short-HostnamePv6 addresses 

::1 ipv6-localhost ipv6-loopback 

fe00::0 ipv6-localnet 

ff00::0 ipv6-mcastprefix 

ff02::1 ipv6-allnodes 

ff02::2 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 aphrodite 

10.8.4.206 athene.wg.site athene 

[ ... ] 

10.8.4.250 thetis.wg.site 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 Rechnername 2 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


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 Client- 

Programme 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 Netze 3 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 Aus- 

country generic 

de fr uk 

Toplevel 

Domains 

net mil org com edu 

Second Level 

gwdg Domains 

uni-freiburg 

goe kernel google 

ftp 

www www ftp www linux 

www ftp 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 Geforderte Zeiten in Sekunden 

refresh 10000 - 86400 

retry 1800 -28800 

expire 604800 - 3600000 

ttl 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 NSentry- 

Einträ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.


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 Sub- 

Domains 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 heraus 4 . 

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


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 Linux- 

Distributionen 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"; 

}; 


type master; 


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.


}; 


type master; 


}; 

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 Slave- 

Zonen 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


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 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) 

) 

IN NS ns.wg.site. 

IN MX 10 mail.wg.site. 

IN MX 20 mail-backup.wg.site. 

ns IN A 10.8.4.25 

nameserver IN CNAME ns 

$TTL 86400 ; 1 day 

mail IN A 10.8.4.21 

mail-backup IN A 10.8.4.22 

anphrodite IN A 10.8.4.203 

dionysos IN A 10.8.4.204 


demeter IN A 10.8.4.251 

hermes IN A 10.8.4.252 

IN HINFO "AMD Opteron" "Linux" 

IN TXT "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: 


@ 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. 

254 IN PTR ns.wg.site. 

$TTL 86400 ; 1 day 

21 IN PTR mail.wg.site. 

22 IN PTR mail-backup.wg.site. 

203 IN PTR aphrodite.wg.site.


204 IN PTR dionysos.wg.site. 


251 IN PTR demeter.wg.site. 

252 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 


serial 1 


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


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 2 31 −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 IN NS ns1.sub.wg.site. 

IN NS ns2.sub.wg.site. 

ns1.sub IN A 10.8.5.1 

ns2.sub IN A 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 119 

8.4 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.


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 128bit- 

Schlü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 121 

8.5 DNS bekommt neue Aufgaben 

8.5.1 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 SIP- 

Telefonanschlü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 IP- 

Pendant ”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 Toplevel- 

Domain 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.


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 IN A 10.8.4.203 

aphrodite-ipv6 IN AAAA 3ffe:701:10:200:22:feb5:3456 

dionysos IN A 10.8.4.204 

dionysos-ipv6 IN AAAA 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 IN PTR aphrodite-ipv6.wg.site. 

3457 IN PTR 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"; 

};


zone "falkag.de" in { 

type master; 


}; 

zone "doubleclick.net" in { 

type master; 


}; 

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 Aufgaben 

8.6.1 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


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, DE- 

LETE, 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 Performace- 

Optimierungen. 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"> 

 

 

Test-Seite 

 

 

Hauptüberschrift 

 

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? 127 

9.3 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.html 2 

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 zB.: Content-Type Text-html 

2 Wenn DocumentRoot auf ’/usr/local/httpd/htdocs’ gesetzt ist. Dazu später mehr.


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 Server- 

Features verfügbar sind. Optionen können im Konfiguration-, Container- und Verzeichnis- 

Kontext gesetzt werden. 

ExecCGI : 

Ausführbarkeit von CGI-Programmen 

Includes : 

Ausführung von ServerSideInclude-Befehlen (SSI) 

Indexes : 

Verzeichnislisting anzeigen

9.5. KONFIGURATION 129 

 

Options +Indexes -Includes 

 

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. 

 

Options Indexes Includes 

 

9.5.2 Module 

Abbildung 9.2: Options setzen 

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 DirektiveIfModule 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 Directory- 

Containers 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


 

UserDir public_html 

 

 

AllowOverride FileInfo AuthConfig Limit 

Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec 

 

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 Apache- 

Foundation 4 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 Code- 

Overhead 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 131 

9.6.1 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 Home- 

Verzeichnis 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.


 

AuthType Digest 

AuthName "privat" 

AuthDigestFile /srv/www/.htpasswd 

Require valid-user 

 

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. 

 

AuthType Digest 

AuthName "Mit MD5/Digest gesicherter Bereich" 

AuthDigestFile /srv/www/.htpasswd 


Require Group webadmins 

 

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. 

 

AuthType Basic 

AuthName "Mit BasicAuth nicht wirklich gesicherter Bereich" 

AuthUserFile /srv/www/.htpasswd 


 

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 

undAuthGroupFile, beziehungsweise im Fall der Digest AuthentifizierungAuthDigestFile 

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" 


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 


• 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 

 

Dav On 

ForceType text/plain 

 

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-Datei 8 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 

 

ServerName www.my-domain.site 

ServerAlias my-domain.site *.my-domain.site 

DocumentRoot /srv/www/my-content 

 

 

ServerName www.otherdomain.site 

DocumentRoot /srv/www/othercontent 

 

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 DNS- 

Server 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: 

 

ServerName www.my-first-domain.site 

DocumentRoot /srv/www/my-first-domain/htdocs 

 

 

ServerName www.my-second-domain.site 

DocumentRoot /srv/www/my-second-domain/htdocs 

 

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.



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 /etc/httpd/ssl.crt/server.crt 

SSLCertificateKeyFile /etc/httpd/ssl.key/server.key 

9.7.2 Zertifikate 

Zertifikate 10 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 (Common- 

Name) 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 So ist das Prinzip, in Wirklichkeit ist das Ganze ein bischen komplizierter. 

10 engl. certificates

9.8. CGI (-MODUL) 137 

CA.pl -newreq Certificate-Request. Erzeugt ein neues Certificate. Für ein Webserver- 

Certificate 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 manCA.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-basierten 11 virtuellen Host: 

Listen 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 

 

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 SSLCertificateKey- 

File 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 CGI- 

Programme 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.


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 setzen 12 und eine (oder mehrere) Dateiendungen definieren. Nur Dateien, die die 

eingetragene Endung haben und sich in einem Verzeichnis befinden, für dasExecCGI 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. MitAddHandler 

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/ /usr/local/httpd/cgi-bin/ 

AddHandler cgi-script .cgi 

 

Options +ExecCGI 

 

9.9 PHP 

Abbildung 9.5: mod cgi 

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.


 

AddType application/x-httpd-php .php 

AddType application/x-httpd-php .php4 

AddType application/x-httpd-php-source .phps 

 

 

 

 

. 

Abbildung 9.6: mod php 

print ’’’’.$titel.’’ ’’.$number.’’’’; 

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). 

 

AddHandler server-parsed .shtml 

AddType text/shtml .shtml 

Options +Include 

 

Abbildung 9.8: mod ssi 

SSI-Befehle werden innerhalb des HTML-Codes 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). 







viel zur breiten Akzeptanz des Internets beigetragen.

9.11. 

ÜBERBLICK 141 

 

 

... 

 

... 

 


Abbildung 9.9: SSI-Code 







ausliefert. 






z.B. urn:isbn:0-596-00962-3 





















überwachen kann. Mithilfe dieser Methode gibt es die Möglichkeit, den Weg zum Webserver




















ausliefert. 






z.B. urn:isbn:0-596-00962-3 

















werden, die Statusinformationen (Benutzereinträge, ...) zuordnen können. Dadurch

9.14. HTTP-KOMMUNIKATION 143 























ausliefert. 






z.B. urn:isbn:0-596-00962-3 












Optimierungen. So können jetzt im Gegensatz zur Version 1.0 mehrere Anfragen und Ant-


worten pro TCP-Verbindung gesendet werden. Für ein HTML-Dokument mit eingebetteten 













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 SMTP- 

Client baut über Netzwerk eine Verbindung zu dem SMTP-Server auf, um an diesen E- 

Mail zu übertragen. Das Übertragen einer E-Mail, inklusive der relevanten Daten, wird als 

Mailtransfer bezeichnet. Eine abgeschlossene Kommunikation per SMTP wird als SMTP- 

Sitzung 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 E- 

Mail ü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 Net- 

1 siehe Client-Server-Modell 

2 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 Netzwerk- 

Dienste. 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 (1993- 

1995) 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 E- 

Mail 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 Inbox 4 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 übermittelt 5 . 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. 

4 Im Deutschen oft einfach als Posteingang bezeichnet. 

5 Viele MUAs sind in der Lage, die Aufgabe eines SMTP-Clients selbst zu übernehmen.


Server: 220 golem.ehlers-schwichtenberg.info ESMTP Postfix 

Client: HELO schwichtenberg.net 

S: 250 golem.ehlers-schwichtenberg.info 

C: MAIL FROM: 

S: 250 Ok 

C: RCPT TO: 

S: 250 Ok 

C: DATA 

S: 354 End data with . 

C: 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 angezeigt 6 . 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: 

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 ; Tue, 9 Mar 2004 

21:05:52 +0100 (CET) 

Message-Id: 

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 zustellt 7 , muss die Zeile Return-Path: 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.


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 Outgoing- 

SMTP-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 SMTP- 

Servern 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.


vertrauen. 

Kommando Argument Beschreibung 

HELO Systemname Beginn, Name des sendenden Systems 

MAIL From: Absenderadresse Beginn der Übermittlung 

RCPT To: Empfängeradresse Adressat der E-Mail 

DATA Daten... Brieftext, Ende durch eine Zeile mit ”.” 

HELP Topic Hilfestellung 

VRFY Mailadresse Mailadresse verifizieren 

EXPN Mailadresse Mailadresse expandieren (z. B. Liste) 

RSET Senden abbrechen, Zurücksetzen 

NOOP nichts tun 

QUIT Verbindung beenden 

10.2 sendmail 

Tabelle 10.3: Grundsätzliche SMTP-Befehle 

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 


USER Name Das Argument identifiziert eine Mailbox 

PASS String Der String enthält ein Mailbox-spezifisches Passwort 

QUIT Beendet die Verbindung 

Tabelle 10.4: Kommandos im ”Authorization State” 


STAT Liefert die Anzahl der gespeicherten Mails und die Größe 

der Mailbox zurück (in Byte) 

LIST Nummer 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 

RETR Nummer Gibt die Mail mit der als Argument übergebenen Nummer 

aus 

DELE Nummer Löscht die Mail mit der übergebenen Nummer 

NOOP Bewirkt die Antwort ”+OK”. Dient zur Aufrechterhaltung 

der Verbindung, ohne daß ein Time-Out auftritt 

RSET Setzt die aktive Verbindung zurück. Noch nicht ausgeführte 

Änderungen werden verworfen 

QUIT Beendet die Verbindung und führt alle gespeicherten 

Änderungen aus 

10.4 POP 

Tabelle 10.5: Kommandos im ”Transaction State” 

Für den Transport bis zum Server mit dem E-Mail Postfach findet i.d.R. das SMTP- 

Protokoll 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 E- 

Mails 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...


+OK 

PASS password

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.


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 10.18.40.0/255.255.254.0(rw,async) 

/home *.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 port 

100000 2 tcp 111 portmapper 

100000 2 udp 111 portmapper 

100003 2 udp 2049 nfs 

100003 3 udp 2049 nfs 

100227 3 udp 2049 nfs_acl 

100003 2 tcp 2049 nfs 

100003 3 tcp 2049 nfs 

100227 3 tcp 2049 nfs_acl 

100024 1 udp 34607 status


100021 1 udp 34607 nlockmgr 

100021 3 udp 34607 nlockmgr 

100021 4 udp 34607 nlockmgr 

100024 1 tcp 32778 status 

100021 1 tcp 32778 nlockmgr 

100021 3 tcp 32778 nlockmgr 

100021 4 tcp 32778 nlockmgr 

100005 1 udp 783 mountd 

100005 1 tcp 786 mountd 

100005 2 udp 783 mountd 

100005 2 tcp 786 mountd 

100005 3 udp 783 mountd 

100005 3 tcp 786 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 Mount- 

Dienst 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 NFS- 

Version 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 Userspace- 

Dienst ausschließlich in den NFS-Protokollversionen 1 und 2 anbietet. Solche Maschinen 

wird man jedoch zunehmend seltener finden, da die Implementierung von NFS im Linux- 

Userspace 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 portmapper 

100000 2 udp 111 portmapper 

100021 1 udp 32768 nlockmgr 

100021 3 udp 32768 nlockmgr 

100021 4 udp 32768 nlockmgr 

100007 2 udp 803 ypbind 

100007 1 udp 803 ypbind 

100007 2 tcp 806 ypbind 

100007 1 tcp 806 ypbind 

100005 1 udp 829 mountd 

100005 2 udp 829 mountd 

100005 1 tcp 833 mountd 

100005 2 tcp 833 mountd 

100003 2 udp 2049 nfs 

100003 2 tcp 2049 nfs 

100011 1 udp 855 rquotad

11.1. UNIX-NETZWERKDATEISYSTEM - NFS 161 

100011 2 udp 855 rquotad 

100011 1 tcp 858 rquotad 

100011 2 tcp 858 rquotad 

11.1.3 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 172.19.100.0/255.255.255.0(ro) 

/opt/applix 172.19.100.0/255.255.255.0(ro) 

/tmp/users 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.


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 

dows 1 , 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 Beschreibung 

common Systemunabhängige Daten 

public Öffentliche Daten 

service Koordination und Konfiguration der Zelle 

sys type Systemspezifische Daten z.B. i586 linux 

usr Home-Verzeichnisse für Benutzer 

wsadmin 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 System- 

Gruppen 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 Beschreibung 

kpasswd wird benutzt um das AFS-Passwort zu ändern 

klog Erwerben eines Tokens 

tokens Überblick der gültigen Tokens 

pts kann Benutzer und Gruppen anzeigen und verwalten 

fs 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 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


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 Standard- 

UNIX 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 -flag 

Kommando Beschreibung 

fs help erklärt alle zur Verfügung stehenden Optionen 

fs lq zeigt definiertes Quota für ein Verzeichnis an 

fs la listet die gesetzten Rechte 

fs sa setzt Rechte für ein Verzeichnis 

fs q 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) 165 

Kürzel AFS-Recht Beschreibung 

a administer die ACLs ändern 

d delete Dateien und Verzeichnisse 

löschen oder verschieben 

i insert Neue Dateien und Verzeichnisse 

anlegen 

l lookup Inhalt des Verzeichnis kann 

aufgelistet werden und ein 

Wechsel in dieses Verzeichnis 

ist erlaubt 

r read Inhalt der Dateien lesen. Dazu 

gehört z.B. auch ls -l 

w write Ändern von Dateien 

k lock 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 Beschreibung 

all alle Berechtigungen (rlidwka) 

none keine Berechtigung 

read nur lesen (rl) 

write 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


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 Netzkernels 3 oder eines PXE-Bootimages 4 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) 167 

Kommando Funktion 

cd Ver- Verzeichnisse wechseln 

zeichnis 

mkdir Verzeichnis 

Verzeichnisse anlegen 

rmdir Verzeichnis 

Verzeichnisse löschen auf dem Zielrechner 

lcd Ver- Verzeichnis auf Arbeitsrechner wechseln 

zeichnis 

dir zeigt das Directory des Zielrechners an 

ldir zeigt das Directory des Arbeitsrechners an 

!Kommando aktiviert eine Shell auf dem Arbeitsrechner und führt Kommando 

aus 

put Da- kopiert Dateiname auf den Zielrechner 

teiname 

mput Dateiname(n) 

wie put, nur sind hier die Wildcards ** und ? erlaubt 

get Da- kopiert Dateiname vom Zielrechner auf den Arbeitsrechner 

teiname 

mget Dateiname(n) 

entspricht get mit Platzhaltern 

ascii schaltet auf den für den Transport von ASCII-Dateien notwendigen 

ASCII-Modus um, Voreinstellung von Mickey- 

FTP 

bin schaltet auf den für den Transport von binären Daten notwendigen 

Binärmodus um 

? oder help zeigt eine Liste der zur Verfügung stehenden Befehle an 

quit beendet FTP 

Tabelle 11.5: Einige wichtige FTP-Kommandos


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 Standalone- 

Betrieb 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 TFTP- 

Client 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 Netzwerk 

Client 

Anwendung 

VFS 

Dateisystem 

BlockgerÃ¤t 

ftp, scp, http 

LUFS 

NFS, SMB 

iSCSI, AoE, NBD 

Anwendung 

VFS 

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.


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 aufgebracht 5 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 aus


8388608 bytes (8,4 MB) copied, 0,038112 seconds, 220 MB/s 

real 0m0.046s 

user 0m0.008s 

sys 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 aus 

8388608 bytes (8,4 MB) copied, 0,034517 seconds, 243 MB/s 

real 0m0.040s 

user 0m0.008s 

sys 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 NBD- 

Server 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 nbd-export 

-rw------- 1 root root 270336 2006-04-03 12:39 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 Journaling- 

Dateisysteme 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.


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 IE- 

EE 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 Multicast- 

Kommunikation 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:~ # modprobe cowloop 

linux01:~ # cowdev -a /dev/nbd0 /tmp/nbd.cow 

/dev/cow/0 

linux01:~ # mkdir /mnt/nbd-rw && mount /dev/cow/0 /mnt/nbd-rw 

linux01:~ # 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


nur lesbares 

BlockgerÃ¤t 

copy-on-write 

BlockgerÃ¤t 

Dateisystem 

Lesen 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-On- 

Lö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 Unix- 

Dateien 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 Fehlermeldungsmbmnt 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 Unix- 

Rechtemuster 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 Windows- 

Freigaben 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


IM01OLYM D 0 Mon Nov 17 16:37:14 2003 

Mail D 0 Mon Sep 26 18:07:45 2005 

OpenOffice.org1.1 D 0 Wed Oct 20 09:44:31 2004 

PDFs D 0 Mon Jan 10 19:06:34 2005 

PostScripts D 0 Wed Mar 31 13:41:28 2004 

Slides D 0 Fri Sep 10 14:28:28 2004 

artikel D 0 Wed Dec 22 14:48:45 2004 

[ ... 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 

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 Adminserver 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


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 



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 


browseable = No 

valid users = @testgroup 

force group = testgroup 

path = /gruppenfreigabe 


force create mode = 0770 


force directory mode = 0770


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 



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 Linux- 

Client 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 185 

12.4.1 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.


• 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 Loopback- 

Interface 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 Linux- 

Dateibaum 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 oderwritable = 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 Single- 

Sign-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 Windows- 

Maschine 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.


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 189 

ID Bedeutung 

< 00 > NetBIOS Name eines Rechners (Freigabename einer Workstation) 

< 03 > Messenger Service Name - verwendet zum Empfangen und Übertragen 

von Nachrichten, sowohl für User- als auch Rechnernamen 

< 06 > Routing und Remote Access Service (RAS) - Name des Servers 

< 1B > Domain Masterbrowser Name - wird von Maschinen im Netz genutzt, 

um den Primary Domain Controller (PDC) einer Windows-Domain zu 

kontaktieren 

< 1F > Network Dynamic Data Exchange (NetDDE) Dienst 

< 20 > Server-Dienstname - Zugriffspunkte für freigegebene Dateien und Verzeichnisse 

< 21 > RAS-Client 

< BE > Network Monitor Agent 

< BF > 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 Master- 

Browser 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 Bedeutung 

< 1D > Masterbrowser-Name - wird vom Client benutzt, um auf den Masterbrowser 

zuzugreifen (je nach Netz lokaler Masterbrowser) 

< 1E > 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 Bedeutung 

< 00 > Zum Empfang von Browser-Broadcasts 

< 1C > Arbeitsgruppenname - wird vom Domain Controller registriert und 

enthält eine Liste von Computern, die sich unter dieser Gruppe registriert 

haben Internet Gruppe 

< 1E > Gleiche Bedeutung, wie bei Gruppenressourcen 

< 20 > Identifikation eine Gruppe von Rechnern für administrative Zwecke 

Tabelle 12.3: Domänennamen


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 WINS- 

Server (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 Windows- 

Rechnern. Sie kann auch von Samba verwendet werden und entspricht funktionell der von Linux 

bekannten Datei /etc/hosts. Der einzige Unterschied: Sie ordnet IP-Adressen NetBIOS- 

Namen 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 191 

12.6 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 Windows- 

Domä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


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 Client- 

Maschine 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 Linux- 

Accounts 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 


store dos attributes = Yes 



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




browsable = No 

Abbildung 12.6: Begrüßung in der neuen Domäne 

Ein Beispielskript für NT findet sich je nach eingesetzter Linux-Distribution im Samba- 

Doku-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 Client- 

Server-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 195 

12.7.1 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 /etc/openldap/schema/samba3.schema 

[ ... ] 

suffix "dc=my-domain,dc=site" 

rootdn "cn=Manager,dc=my-domain,dc=site" 

rootpw 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.


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 


inherit permissions = Yes 


[profiles] 

comment = Network Profiles Service 

path = %H 




store dos attributes = Yes 

[users] 

comment = All users 

path = /home 



[groups] 

comment = All groups 

path = /home/groups 



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.3 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/);


$_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, line 8. 

Diese läßt sich in den Griff bekommen durch das Einfügen zweier struktureller LDAP- 

Objektklassen 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


adding new entry: dc=my-domain,dc=site 

adding new entry: ou=user,dc=my-domain,dc=site 

adding new entry: ou=group,dc=my-domain,dc=site 

adding new entry: ou=computer,dc=my-domain,dc=site 

adding new entry: uid=Administrator,ou=user,dc=my-domain,dc=site 

adding new entry: uid=nobody,ou=user,dc=my-domain,dc=site 

adding new entry: cn=Domain Admins,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Domain Users,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Domain Guests,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Administrators,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Users,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Guests,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Power Users,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Account Operators,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Server Operators,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Print Operators,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Backup Operators,ou=group,dc=my-domain,dc=site 

adding new entry: cn=Replicator,ou=group,dc=my-domain,dc=site 

adding new entry: 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: 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 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


dn: ou=Idmap,dc=my-domain,dc=site 


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:


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 # ./smbldap-useradd.pl -m -a test1 

linux2:/var/lib/samba/sbin # ./smbldap-passwd.pl test1 

Changing password for test1 

New password : 

Retype new password : 

linux2:/var/lib/samba/sbin # ./smbldap-usermod.pl -u 0 Administrator 

linux2:/var/lib/samba/sbin # ./smbldap-passwd.pl Administrator 

Changing password for test1 

New password : 

Retype new password : 

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 test1 3 

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


Password last set: Tue, 23 Nov 2004 01:49:59 GMT 

Password can change: 0 

Password must change: Fri, 07 Jan 2005 01:49:59 GMT 

Last bad password : 0 

Bad password count : 0 

Logon hours : 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 Windows- 

Domä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 


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: 

13.2.3 NIS-Server 

13.2.4 NIS-Client 

Master-Datei Mapfile(s) 

/etc/hosts hosts.byname, hosts.byaddr 

/etc/networks networks.byname, networks.byaddr 

/etc/passwd passwd.byname, passwd.byuid 

/etc/group group.byname, group.bygid 

/etc/services services.byname, services.bynumber 

/etc/rpc rpc.byname, rpc.bynumber 

/etc/protocols protocols.byname, protocols.bynumber 

/etc/aliases mail.aliases 

Die Konfigurationsdatei für NIS ist yp.conf. 

# Syntax: 

# ypserver 

ypserver 134.76.60.23 

Tabelle 13.1: NIS-Maps 

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.


13.3.3 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 Bedeutung 

bin Daten im Binärformat, Bilder, Ausführbare Dateien 

ces CaseSensitive, Textfelder 

cis CaseInSensitive, Textfelder 

tel Telefonnummer 

dn 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 207 

Attribute Alias Syntax Beschreibung Beispiel 

CommonName cn cis Name eines Eintrages 

Sandra Buchfink 

surname sn cis Nachname 

Person 

einer Buchfink 

TelephoneNumber tel Telefonnummer 01-12345 

organizationalUnit ou cis Name einer Abteilung 

Informatik 

Organization o cis Name der Organisa- Universität Freitionburg 

Country c cis Name des Landes Deutschland, DE 

Owner dn Ausgezeichneter cn=Sandra Buch- 

Name des Einfink, o=Universität 

tragbesitzers Freiburg,c=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.


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 

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=... 

rdn: ou=devices 

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 209 

13.3.4 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


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 LDIF- 

Formats 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-Interface 1 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 /var/run/slapd/slapd.pid 

argsfile /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


/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 LDAP- 

Austauschformat 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 


cn: user 

userPassword: crypt 


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



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 


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 pam_nologin.so 

auth sufficient pam_ldap.so 

auth required pam_unix2.so use_first_pass # set_secrpc 

account required pam_unix2.so 

password required pam_pwcheck.so 

password required pam_ldap.so use_authtok 

password required pam_unix2.so use_first_pass use_authtok 

session required pam_unix2.so 

session required pam_limits.so 

session required pam_env.so 

session optional pam_mail.so 

Weiterhin muss nun noch dem Name Service Switch die alternative zu den klassischen 

Dateien passwd und shadow mitgeteilt werden: 

# /etc/nsswitch.conf


[ ... ] 

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


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 


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 []: 

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 


Enter PEM pass phrase: 

Check that the request matches the signature


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


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


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 


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 PostScript- 

Codes sorgt. Bei PostScript-fähigen Druckern ist der RIP im Drucker integriert, bei nicht- 

PostScript-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 CUPS- 

Server 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 Aufrufhttp://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. 

14.2.2 IPP 

Abbildung 14.1: Cupsdiagramm 

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 IPP- 

Server, 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. 


Die Kommunikation zwischen Client und Server erfolgt gemäß dem bekannten Request- 

Response-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 Browsing- 

Informationen 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 destination ports 

tcp 0:40.46 1234.test.local 210.24.30.216 3592 -> 2183 (64155) 

tcp 0:45.64 1234.test.local 210.24.30.216 3593 -> 2187 (64156) 

tcp 0:49.43 1234.test.local 210.24.30.216 3594 -> 2188 (64157) 

225

226 KAPITEL 15. WICHTIGE NETZWERKKOMMANDOS 

tcp 1:03.12 1234.test.local 210.24.30.216 3596 -> 2195 (64159) 

tcp 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: 

15.3 Systemprogramme 

15.3.1 Dämonen 

Buchstabe Bedeutung 

B BROADCAST 

L LOOPBACK 

M PROMISC 

O NOARP 

P POINTOPOINT 

R RUNNING 

U UP 

Tabelle 15.1: Bezeichner 

xinit, init, rinted, nfsd, smbd, nmbd, proftpd, httpd, dhcpd

15.4. NETZWERKKONFIGURATION 227 

15.4 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 




^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


ping sucht zunächst die richtige IP-Adresse zu dem angegebenen Rechnernamen heraus 1 

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 Routing- 

Endlosschleife 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 



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 229 

15 ar-goettingen1.g-win.dfn.de (188.1.88.74) 20.239 ms 20.192 ms 20.162 ms 

16 c12012-int.gwdg.de (134.76.249.201) 20.786 ms 20.738 ms 20.705 ms 

17 134.76.249.204 20.406 ms 20.352 ms 20.323 ms 

18 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


pathcost 0 age 0 max 20 hello 2 fdelay 15 


77:52 



77:52 



77:52 


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) 




25559 1/4/4 PTR [|domain] 




25560 NXDomain* 0/1/0 (141) 




25561* 1/2/2 (173) 


77:52 


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 


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 Stan- 

231

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 233 

MIB Informationen zu/über 

system Überwachtes Gerät, Standort, Eigentümer, Software, Uptime, Ansprechpartner 

... 

interfaces Eingebaute reale und virtuelle Netzwerkinterfaces: Mehrere bei 

Routern und Switches, meistens eines bei Rechnern, Druckern ... 

ip IP-Daten, wie Routingtabelle, Paketzähler ... 

tcp TCP-Daten, wie offene Verbindungen, Paketzähler 

udp UDP-Daten, wie offene Ports, Paketzähler 

snmp Statistiken und Zähler des SNMP-Agenten 

host 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..2ˆ32-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.1- 

Standard (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


”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 Net- 

SNMP aufsetzt und ein GTK-GUI verwendet. Mit mbrowser lassen sich auch die Standard- 

SNMP-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. Unix- 

Workstation 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 SMI- 

Hierarchie 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...] {} [ ...] 

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


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 aus- 

schließ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


liefert eine Ergebnisliste zurück, wobei die Ergebnisse die Shell-Variable des Rückgabewertes 

($?) repräsentieren: 

enterprises.ucdavis.extTable.extEntry.extResult.1 = 34 











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 UCD- 

SNMP-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 Text- 

Felder 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ür- 

Schrittanleitung ein Makefile, der Beispiel-Code einer SNMP-Applikation und eine Tutorial- 

MIB 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.


16.7.2 Parameter der Host-Ressource-Erweiterungen 

Wurden die SNMP-Bibliotheken und der Agent mit der Unterstützung für die HOST- 

RESOURCES-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] Second, map the security names into group names: 

group MyRWGroup v1 local 

group MyRWGroup v2c local 

group MyRWGroup usm local 

group MyROGroup v1 mynetwork 

group MyROGroup v2c mynetwork 

group 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 2 groups access to the 1 view with different 

# write permissions: 

# context sec.model sec.level match read write notif 

access MyROGroup "" any noauth exact all none none 

access MyRWGroup "" any noauth exact all all none 

# [E] System contact information 

syslocation Internet-AG Universitaet Goettingen 

syscontact 

# [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 temp1 



exec sensors /bin/sh /usr/share/snmp/sensors fan1 



exec empty /bin/echo 252 

exec empty /bin/echo 253

16.8. MRTG ALS FRONTEND ZUR ANZEIGE VON ZEITREIHEN 241 



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’ @ 

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


# 2048kBit leased line 

# ---------------- 

#Title[leased]: a 2048kBit leased line 

#PageTop[leased]: Our 2048kBit link to the rest of the internet 

#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 243 

OID Datentyp Beschreibung 

Standard-OIDs (MIB- 

II) 

system.sysDescr text Geräteinformation: Hersteller, Name des Modells, 

Version der SOftware o.ä. 

system.sysLocation text Aufstellungsort des Gerätes 

system.sysUpTime int Millisekunden seit dem Start des Agenten 

system.syscontact text Kontakt zum Admin des Gerätes 

system.sysName text Name der Maschine; üblicherweise der DNS- 

Name 

interfaces.ifNumber int Zahl der vorhandenen Netzwerkschnittstellen 

interfaces.ifTable table Array der verschiedenen Infos pro Schnittstelle 

(Name, Typ, Geschwindigkeit, MTU) 

at.atTable table ARP-Tabelle 

ip.ipforwarding int Bei Geräten mit mehreren Interfaces: 1, falls 

IP-Forwarding stattfindet, sonst 2 

ip.ipAddrTable table IP-Informationen der versch. Interfaces 

(Broadcast-, Routeradressen, Netzmasken und 

Metrik) 

icmp.* int Eine Menge von ICMP-Statistiken 

tcp.tcpConnTable table Liste der bestehenden TCP-Verbindungen mit 

Status 

udp.udpTable table Liste der offenen UDP-Sockets 

snmp.* int Eine Menge von SNMP-Statistiken 

OIDs der UCD-SNMP- 

MIB 

prTable.* table Tabelle der auf minimal und maximal laufende 

Instanzen zu überwachende Prozesse 

memory.memTotalReal int Menge des zur Verfügung stehenden Arbeitsspeichers 

extTable.* table Ausbaubare Spezial-MIB zur Ausführung von 

Programmen und Skripten 

laTable.* int Load Average Werte (1, 5, 15 Minuten Intervall) 

systemStats.* int Eine Menge systemspezifischer Variablen und 

Maximalwerte 

ucdExperimental.* Eintrag für die später beschriebene eigene 

MIB-Erweiterung 

Tabelle 16.2: Beispieldaten (OIDs) der Standard-MIBs


Kommando Bedeutung 

get-request Ermittele den Wert einer bestimmten Variablen 

get-next- Ermittele den Wert der nächsten Variablen ohne 

request ihren genauen Namen zu kennen 

get-bulk- Ermittele einen Block von Variablen (z.B. Tarequestbellen) 

response Anwort auf o.g. Requests 

set-request Speichere einen bestimmten Wert in eine Variable 

inform-request Referenz zu weiteren z.B. Proxy-Daten 

trap Antwort, ausgelöst durch einen Event-Trigger 

Tabelle 16.3: Das SNMP-Kommando-Set 

OID Bedeutung 

hrSystem Zahl der laufenden Prozesse und angemeldeten Benutzer 

hrStorage Speicher der verschiedensten Form, wie Real Memory, 

Swap, Memory Buffers 

hrDevice Liste verfügbarer Geräte, wie Drucker, Prozessor, 

Mainboardchipset 

hrSWRun Liste der laufenden Prozesse (wie ”ps”) 

hrSWRunPerf CPU-Verbrauch der laufenden Prozesse 

hrSWInstalled 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 247 

17.2.7 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


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 Sicherung Host2 

Anwendung S-HTTP, PGP, eCASH Anwendung 

Transport SOCKS, SSL Transport 

Netzwerk IPSec Netzwerk 

Datensicherung PAP, CHAP, PPTP 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 HTTP- 

Verbindungen 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 = stream 

protocol = tcp 

wait = no 

user = root 

server = /usr/sbin/proftpd 

server_args = -p 0 

only_from = 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.


17.4.5 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-IP- 

Protokolle 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 Feststellen des Betriebssystems im 

Class-B-Subnetz 

nmap -sP 172.16.1.0/24 Ping-Scan (Erreichbarkeit von Rechnern 

Class-C-Subnetz 

nmap -sT 172.16.1.1 Scan auf offene TCP-Ports der Maschine 

mit der IP 172.16.1.1 

nmap -sU www.goe.net Scan auf offene UDP-Ports der Maschine 

mit dem FQDN www.goe.net 

Tabelle 17.2: NMAP im Einsatz


17.4.8 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 (Remote- 

Login) mit dem Rechnernamen test.domain.local verbinden will und man die Benutzer- 

ID ”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 ver- 

253

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. 

b5 48 00 00 01 01 08 0a 11 df 06 9c 42 97 -@5H.... ..._..B. 

0040 29 0d 47 45 54 20 2f 73 65 61 72 63 68 3f 71 3d ).GET /search?q= 

0050 77 69 65 2b 68 61 63 6b 65 2b 69 63 68 2b 6d 65 wie+hacke+ich+me 

0060 69 6e 2b 6e 65 74 7a 26 69 65 3d 49 53 4f 2d 38 in+netz&ie=ISO-8 

0070 38 35 39 2d 31 26 68 6c 3d 64 65 26 6d 65 74 61 859-1&hl=de&meta 

0080 3d 20 48 54 54 50 2f 31 2e 31 0d 0a 55 73 65 72 = HTTP/1.1..User 

0090 2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f -Agent:Mozilla/ 

00a0 35 2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65 3b 5.0 (compatible; 

00b0 20 4b 6f 6e 71 75 65 72 6f 72 2f 33 3b 20 4c 69 Konqueror/3; Li 

00c0 6e 75 78 29 0d 0a 52 65 66 65 72 65 72 3a 20 68 nux)..Referer: h 

00d0 74 74 70 3a 2f 2f 77 77 77 2e 67 6f 6f 67 6c 65 ttp://www.google 

00e0 2e 64 65 2f 0d 0a 41 63 63 65 70 74 3a 20 74 65 .de/..Accept: te 

00f0 78 74 2f 2a 2c 20 69 6d 61 67 65 2f 6a 70 65 67 xt/*, image/jpeg 

0100 2c 20 69 6d 61 67 65 2f 70 6e 67 2c 20 69 6d 61 , image/ png,ima 

0110 67 65 2f 2a 2c 20 2a 2f 2a 0d 0a 41 63 63 65 70 ge/*, */*..Accep 

0120 74 2d 45 6e 63 6f 64 69 6e 67 3a 20 78 2d 67 7a t-Encodi ng:x-gz 

0130 69 70 2c 20 67 7a 69 70 2c 20 69 64 65 6e 74 69 ip, gzip ,identi 

0140 74 79 0d 0a 41 63 63 65 70 74 2d 43 68 61 72 73 ty..Accept-Chars 

0150 65 74 3a 20 69 73 6f 2d 38 38 35 39 2d 31 2c 20 et: iso-8859-1, 

0160 75 74 66 2d 38 3b 71 3d 30 2e 35 2c 20 2a 3b 71 utf-8;q= 0.5,*;q 

0170 3d 30 2e 35 0d 0a 41 63 63 65 70 74 2d 4c 61 6e =0.5..Accept-Lan

18.1. SICHERHEITSPROBLEME DES DERZEITIGEN IP-STANDARDS 255 

0180 67 75 61 67 65 3a 20 65 6e 0d 0a 48 6f 73 74 3a guage: en..Host: 

0190 20 77 77 77 2e 67 6f 6f 67 6c 65 2e 64 65 0d 0a www.google.de.. 

01a0 43 6f 6f 6b 69 65 3a 20 50 52 45 46 3d 49 44 3d Cookie:PREF=ID= 

01b0 35 66 35 31 34 38 31 33 30 35 35 64 62 62 38 32 5f514813055dbb82 

01c0 3a 4c 44 3d 64 65 3a 54 4d 3d 31 30 33 38 38 32 :LD=de:TM=103882 

01d0 37 31 37 30 3a 4c 4d 3d 31 30 33 38 38 32 37 31 7170:LM=10388271 

01e0 37 30 3a 53 3d 35 49 4b 57 55 36 38 68 50 58 73 70:S=5IKWU68hPXs 

01f0 38 53 59 7a 51 0d 0a 0d 0a 

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 Paketinhalt 1 , 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 Daten- 

prüfsumme


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 Network 2 ” 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. 

Left Subnet 

192.168.2.0/24 

Öffentliches 

unsicheres 

IP-Netzwerk 

202.38.21.24 62.137.15.134 

lisa.dyndns.org rainer.dyndns.org 

Internet 

Right Subnet 

192.168.4.0/24 

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 UDP- 

Paketen übertragen werden. Der Vorteil UDP als Transportprotokoll zu verwenden, liegt 

2 zu deutsch: Virtuelles Privates Netzwerk


in der leichten Unterscheidbarkeit verschiedener Endpunkte. Bei einer einfachen IP-zu-IP- 

Kapselung 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 





oder mittels des IP-Route2-Tools ip: 

ip addr show dev cipcb0 

9: cipcb0: 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 259 

18.3.2 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 Internet- 

Einwahl 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


# 

[ ... ] 

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 Discard- 

Port 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ämtlichen 3 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 

IP Header Authentication 

Header 

Next Header Payload Length RESERVED 

Security Parameters Index (SPI) 

Sequence Number Field 

Authentication Data (variable) 

32 bit 

Data (variable) 

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. 

IP Header Data (variable) 

Neuer 

IP Header 

Neuer 



Auth. 


Original IP-Datagramm 


authentifiziert 

Getunneltes IP-Datagramm 

Datagramm mit Auth-Header im Tunnelmodus 

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 MD5- 

Verfahren. 

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 ESP- 

Header 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.


Security Parameters Index (SPI) 

Sequence Number Field 

Payload Data (variable) 

Padding (0-255 byte) Pad Length 

Authentication Data (variable) 

32 bit 

Padding 

Next Header 

Abbildung 18.5: Aufbau eines ESP Paketes 


Neuer 


Neuer 



ESP 


Original IP-Datagramm 

Getunneltes IP-Datagramm 


verschlüsselt 

authentifiziert 

e 

n 

c 

r 

y 

p 

t 

e 

d 

Datagramm mit ESP im Tunnelmodus 

ESP 

Trail 

Abbildung 18.6: Einsatz des ESP im IP-Datagramm 

ESP 

Auth 

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 FreeSWAN- 

Projekt [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 

a 

u 

t 

h 

e 

n 

t 

i 

c 

a 

t 

e 

d

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ügt 4 , 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


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 Red- 

Hat 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 IP Security Protocol (FreeS/WAN IPSEC) 

02 --- IPSec options (FreeS/WAN) 

03 [*] IPSEC: IP-in-IP encapsulation (tunnel mode) 

04 [*] IPSEC: Authenticbation Header 

05 [*] HMAC-MD5 authentication algorithm 

06 [*] HMAC-SHA1 authentication algorithm 

07 [*] IPSEC: Encapsulating Security Payload 

08 [*] 3DES encryption algorithm 

09 [*] IPSEC: IP Compression 

10 [*] 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


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


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= 

GroupPwd= 

EnableISPConnect=0 

ISPConnectType=0 

ISPConnect= 

ISPCommand= 

Username= 

UserPassword= 

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,


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


*************** 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 

 

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 user führt letztendlich zu: 

Cisco Systems VPN Client Version 3.7 (Rel) 

Copyright (C) 1998-2002 Cisco Systems, Inc. All Rights Reserved.


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: 







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: 


Connection Entry: goemobile 






NAT passthrough is inactive 

Local LAN Access is enabled


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 routes. 

Secured Network Destination Netmask Bytes 

* 10.100.n.n 255.255.255.255 0 

* 0.0.0.0 0.0.0.0 157753 

Local Network Destination Netmask 

10.100.n.n 255.255.0.0 

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 ”rich- 

tige” 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 Hardware 7 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 Cisco- 

Client 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 prot opt source destination 

ACCEPT all -- anywhere 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:


”–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:


--->[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 -- minimize delay 

0100 -- maximize throughput 

0010 -- maximize reliability 

0001 -- minimize monetary cost 

0000 -- 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 allgemeine Bedeutung 

bezeichnet Pakete, die eine neue Verbindung aufbauen, bzw. die 

NEW zu einer Verbindung gehören, der bisher noch keine Pakete zugeordnet 

wurden. 

eine Verbindung gilt als ESTABLISHED, wenn in beide Richtun- 

ESTABLISHED 

gen mindestens ein Paket geflossen ist. 

auch diese Pakete bauen eine neue Verbindung auf, sind jedoch im 

RELATED Kontext zu einer existierenden Verbindung zu betrachten (FTP 

Datenverbindung, ICMP Fehlermeldung). 

INVALID 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 AS- 

SURED) 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


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 

Bandbreit, 19 

Bandbreite, 18 

BDC, 143 

Benutzer, 143, 189 

Benutzerkonto, 143 

Berkeley Internet Name Domain Software, 

84 

Betriebssystem, 8 

Binärzahl, 40 

BIND, 84 

Bind, 89 

Bitübertragungsschicht, 11 

Bouncer, 199 

Broadcast, 42 

CA, 106 

CA.pl, 106 

283 

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 

Defaultrouter, 43 

Delegation, 87, 88 

dhclient, 75 

DHCP, 64, 67, 95 

DHCP-Server, 19 

dhcpcd, 75 

Dienst, 83, 189 

Directory, 158 

Directory Service, 158 

Discrete Multi-Tone Modulation, 30 

Diskless X-Station, 2, 71 

Distinguished Name, 79 

DNS, 61, 64, 67, 83 

DocumentRoot, 105 

Domäne, 143 

Domain, 61, 85

284 INDEX 

Domain Name System, 83, 175 

Domain-Name-Service, 61 

Domaincontroller, 129 

Domainname, 91 

Dotted Quad Notation, 84 

Dotted-Quad-Notation, 40 

Drucker, 158, 187 

Druckerfreigabe, 129 

Dynamic Host Configuration Protocol, 48, 

64 

Dynamic Host Control Protocol, 3 

EC, 28 

Echo Cancellation, 28 

Email, 200 

Endsystem, 23 

ENUM, 97 

EPROM, 127 

ESP, 212 

Ethernet, 11, 13, 24, 35 

Exploit, 200 

exports, 124 

FDDI, 33 

Fehlerrate, 64 

Fiber Distributed Data Interface, 33 

Finish, 63 

Firewall, 199 

Flag, 63 

Flusskontrolle, 64 

FQDN, 61, 85, 89 

Fragment, 45 

Fragment Offset, 64 

Fragmentierung, 39 

Frequency Division Multiplexing, 28 

Frequenzspektrum, 18 

ftp, 199 

Full Qualified Domain Name, 61, 85 

Gateway, 71 

General Packet Radio Service, 26 

Generic Flow Control, 32 

GFC, 32 

Global Standard for Mobile Communication, 

26 

GMII, 16 

GPRS, 26 

groups, 157 

GSM, 26 

Header, 199 

High Speed Circuit Switched Data, 27 

Host, 23, 38 

host, 83 

HOST-RESOURCES-MIB, 182 

Hostname, 61, 71 

hosts, 157 

hosts.allow, 193 

hosts.deny, 193 

Hostteil, 51 

HSCSD, 27 

http, 199 

HTTP-Kommunikation, 200 

httpd, 101 

httpd.conf, 101 

HTTPS, 105 

ICMP, 40, 59 

imap, 111 

Imap4, 199 

inetd, 125, 193 

Internet, 38 

Internet Control Message Protocol, 40 

Internet-Protokoll, 38 

IP, 38, 59, 64, 192, 199 

IP Virtual Host, 104 

IP-Adressbereich, 41 

IP-Adresse, 37, 71, 83, 91, 158, 175 

IP-Adressraum, 46 

IP-Paket, 201 

IP-Stack, 199 

IPsec, 200 

IPX, 200 

ISDN, 11, 24 

Jam-Sequence, 14 

Kanalaufteilung, 18 

Kanalbündelung, 18 

Kernelmodul, 200 

Klartext, 199 

Koaxialkabel, 15 

Kollision, 14, 19 

Kommunikation, 46 

Konfigurationsdatei, 2 

LAN, 7, 36 

LDAP, 78, 147, 158 

LDAP-Server, 78 

ldapadd, 164, 166 

ldapdelete, 164

INDEX 285 

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 

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 INDEX 

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 

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 287 

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

Ein Mehrbenutzersystem in der Praxis Netzwerk Linux/Unix

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?